我们都遇到过这种情况：有人发现了一个bug，然而这不是一般的软件bug，甚至都不是通常意义上的bug，其本质上是人员的问题：盲目跟风的开发者。
一开始时这个bug很小，他只是在劝说团队采用新的技术，或者在项目里采用一个新的模块，但在不知不觉之间，到处都是奇怪的项目和天花乱坠的文档，声称只需要三步就能解决你的业务问题！然而，要想真的解决问题，似乎还需要花费更多的工夫。
我们都遇到过这种情况，而去年的类似情况之一就是一个名为Kubernetes的项目。有些公司和团队已经被Kubernetes淹没，有些公司还没有入坑。我处于中间地带，刚刚开始构建一个超级复杂的系统准备入坑。但在这之前，我想先介绍一下怎样在Kubernetes上部署一个简单的、类PaaS的平台。
寻找完美的类PaaS平台
从何处下手呢？一定有一个完美的方法，对不对？也许吧，我们先做一下搜索：
嗯……显然，k8s并不是PaaS。我想在PaaS之上构建PaaS，而不是把k8s当做PaaS使用。
那接下来该怎么办？先在HackerNews上研究一番吧！最后我找到了一篇不错的文章（https://hn.algolia.com/?dateRange=all&page=0&prefix=false&query=paas%20kubernetes&sort=byPopularity&type=story），还在GitHub上找到了一篇awesome-list（https://github.com/ramitsurana/awesome-kubernetes）。
经过一番仔细的搜索后，我列出了一些候选的项目：
●Knative
●OpenFaas Cloud
●Convox
●Garden
●Rio
还有许多其他的替代项目，一些项目我曾经尝试过，一些项目并不是太活跃，一些项目显然是给大型企业用的。
我的情况
我的情况是怎样的？我们需要在一个基本的DigitalOcean droplet上运行一个电商网站，上面只有一个简单的Wordpress。尽管只需要一个简单的bash脚本就可以把网站建起来，还能在本地建一台测试用的服务器，但我想做一个工业标准的平台，而不是简单的脚本。写脚本很有趣，自己做部署栈也很方便，但遵循标准、不需要自己考虑工具的事情，才是我真正想要的。
我的需求
我想先在一台k3s的垃圾服务器上测试一下这些项目。k3s有一个反向代理，指向DigitalOcean上的droplet，而不是直接在互联网上公开。也就是说，这些项目必须支持本地部署（on-premise deployment）。
另一个需求是，该项目必须完全从k8s中抽象出来。也就是说，我不想处理大量的yaml文件也不想一直部署helm charts，我想从我自己的应用程序的方面来思考，只需要通过命令行就可以完成一切工作。
用一句话总结就是：我希望只要按一个按钮就能完成一切工作。
我们的应用程序有许多可动的部分，一部分仅是简单的脚本，一部分是大型应用程序，给游戏客户端提供通讯功能。不管是什么应用程序，我们的平台需要支持大量不同类型的应用程序。通常这意味着需要支持通过Dockerfile进行部署。
我们打算运行的绝大多数应用程序都是有状态的。例如，Wordpress需要一个地方来保存图片。许多应用程序内部的图片也需要存储。因此，应用程序需要某种形式的持久存储。
许多项目都很好，但好项目和伟大项目的区别就是社区和行业的接受度。使用一个在GitHub上只有三个用户的项目，跟自己写bash脚本没有区别。万一你搞坏了什么东西，或者需要什么帮助，一个活跃的社区将是你的依靠。
项目一览
Knative
Knative最初给我的体验棒极了！看了Knative之后，我发现我可以运行一个跟Google自家用的PaaS一样的平台。考虑到k8s就是Google做的，那么Knative项目肯定是完美的！不过安装要比想像的难了一点。似乎没有太简单的方法来安装，而无法简单地尝试，在未来可能是一个风险。也许只有我这样想，也许我应该更深入地研究一下Knative，不过由于这点原因，我把目光转向了下一个候选。
OpenFaaS Cloud
安装非常容易！很快我就能运行这个平台了。它能满足我的大部分要求，但似乎它更侧重于实现OpenFaaS，本身并不是一个完整的PaaS。我不太明白如何利用这个平台解决我们的问题。如果你使用的是耦合性更小的项目，或者有许多小功能，那OpenFaaS绝对是最佳选择！也许以后我可以看看看，但现在我已经决定看看下一个候选。
Convox
Convox看上去非常好！它是由几名前Heroku工程师在k8s的基础上构建的。我在DigitalOpen的k8s集群上迅速部署了一下。开发者的体验非常棒！但是，似乎该项目并不支持本地部署。而且，该项目的社区似乎并不大，只有一些早期的使用者。该项目不太出名，所以我还是选择了其他项目。
Garden
这个项目非常酷。我喜欢它，是因为它由是一个独立的小公司开发的非常有创意的解决方案。设置非常简单，他们的方法论也是由k8s得出的非常好的抽象，但该项目还可以在某种形式上允许你用传统的方式控制k8s，比如yaml文件等。我非常喜欢这个实现，而且它工作得很好！尽管我注意到命令行界面有些粗糙，但这毕竟是小问题，而且最终可能会被解决。
不过我还是决定看看下一个（也是最后一个）项目。
Rio
这个项目能满足我的所有需求。易用的命令行界面，不需要与k8s交互，使用Dockerfile进行部署。还有一长串其他平台未能实现或实现得不太好的功能。Rio从Rancher中派生而来，似乎从Rancher活跃的社区中得到了许多支持。
在我的垃圾服务器上设置Rio
我迅速地设置好了通向我的k3s实例的反向代理，然后开始设置Rio。
根据他们的GitHub上的快速上手指南，设置非常简单：
这就好了！我迫不及待地想看看我们已有的基础设施是否能够同样容易地迁移到这个平台上。
Rio的默认安装允许你使用他们的rDNS服务（位于on-rio.io），这一点非常酷，但我放在反向代理后面的垃圾服务器并不需要。我也没用过Linkerd，所以暂时先禁用了该功能。使用 rio install --disable-feature rdns,letsencrypt,linkerd 语句重新安装，就得到了我需要的结果。
下一步，使用kubectl安装自定义的ClusterDomain，这样我就可以使用on-rio.io之外的域名了。我最终安装了dnsmasq，设置了一个假的域名app.rio供应用程序使用。通过它可以很容易地在垃圾服务器上测试应用程序的连通性。
我还要想个办法从我的DigitalOcean droplot上连接到这个集群。我的方法是从垃圾服务器的80端口反向代理到droplet的8080端口上。Rio采用80端口安装Gloo的gateway-proxy。
最后一步，设置nginx配置指向Gloo的网关：
此处的两个重点是proxy_http_version 1.1和proxy_set_header Host。
proxy_http_version非常重要，因为基于Envoy的Gloo并不支持在http__version 1.0上进行网管服务，只能使用1.1。否则会返回426 Upgrade Required错误。
Host头很重要，因为需要实现PublicDomain。添加PublicDomain时的重点是要匹配server_name或代理的Host头，否则Gloo无法识别要连接哪个服务。
