最近几年，Kubernetes 成为许多人关注的焦点。事实上，有些公司发现 Kubernetes 能发挥巨大作用，但有些公司还未发现其价值，并在这个过程中将自己搞得“遍体鳞伤”。对我来说，我正处于中间位置。我打算做类似事情，并且做好了踩坑准备。在此之前，先让我们看看如何在 k8s 上部署一个简单的、类似于 PaaS 的平台。

1. 找到一个完美的类 PaaS 平台

那么，我们从哪里开始？肯定有一种简单方法能找到这样的东西，也许，我们从简单的 DuckDuckGo 搜索开始。

DuckDuckGo 搜索没啥用

显然，k8s 不是 PaaS。我想基于 k8s 构建一个 PaaS，当然不是把它当作一个 PaaS 来使用。

然后，我们在 HackerNews 上搜索一下。第一个查询找到一篇失效文章。此外，我在 GitHub 上偶然发现一个很棒的列表。

在进行更广泛的搜索后，我针对自己的应用场景列出一个可能的候选项目列表。

还有很多其他选择，我尝试过其中一些，还有一些是针对大企业的。

2. 我的应用场景

在 Quest Vault ，我们在 DigitalOcean droplet 上安装一个简单的 Wordpress 来运行我们的电商网站。尽管能通过运行一些简单的 bash 脚本实现部署，并在本地运行测试 / 过渡服务器的副本，但是，我想构建一个基于行业技术的平台，而不是一些 bash 脚本。编写这些 bash 脚本很有趣，并且拥有自己的部署技术栈也很简单，但是，我希望 Quest Vault 能拥有一个“豪华些”的东西，一个标准的、让我们不必为使用的工具操心的东西。

现在，我想在办公室运行 k3s 的 garbage server 上测试这些项目。K3s 有一个到 DigitalOcean droplet 的反向代理，而不是在互联网上访问。这意味着项目应该支持内部部署。

我还希望能完全抽象出 k8s。这意味着我不想处理太多的 yaml 或者一直部署 helm charts，我想多考虑下应用程序，并且通过 CLI 就可以做到。

简而言之：我想要的是，只要按一个按钮，它就工作。

我们的应用程序有很多活动组件，有些只是简单脚本，有些则是为游戏客户端提供通信的大型应用程序。不管是什么，我们的平台需要支持大量不同的应用程序类型。这通常意味着支持通过 Dockerfile 进行部署。

我们计划运行的大多数应用程序都与状态密切相关。以 Wordpress 为例，我们需要一个存储图片的地方。我们还有很多需要存储的应用内照片拍摄。我们需要一种方法使我们的应用程序具有某种形式的持久化。

我喜欢的项目很多，但是一个好项目和一个伟大项目的区别在于社区和行业的采用。拥有自己的 bash 脚本和在 GitHub 上有 3 个活动用户的项目几乎没有区别。如果你搞砸了，或者无论出于什么原因需要一些建议，你都希望能从一个活跃的社区获得帮助。

3. 项目清单速览

我的 Knative 经验有一个不错的开头！当读过关于它的文章后，我很高兴地得知：我能运行一个平台，谷歌在其平台内部就把它用于他们自己的类似 PaaS 的部署。考虑到谷歌创造了 k8s，这一定非常合适！它的安装过程比预期困难得多。

似乎没有什么简单方法来安装这个平台，而且，无法轻松地使用一个平台会是将来的一个风险。

OpenFaaS Cloud

安装非常简单！我很快就让这个平台运行了起来。它满足我的大多数需求，不过，它似乎更像是实现 OpenFaas 的一种有趣方式，而不是完全成熟的 PaaS 可选方案。我不知道如何将我们的用例放到这个特别的平台上。如果你正在搭配使用耦合度比较低的项目或比较小的功能，这是一个很好的选择！

Convox 看起来很棒！几名前 Heroku 工程师，在 k8s 上构建的一个平台。似乎完美！我想尝试一下，马上就开始在 DigitalOcean k8s 集群上部署它。开发体验非常棒！

然而，他们似乎并不支持平台的内部部署版本。此外，除一些早期采用者外，这个项目似乎没有一个非常大的社区。相比而言，这个项目不是很出名，最终我放弃它，去寻找另一种选择。

这是一个非常酷的项目。我喜欢它，一家小型的独立公司开发的一个创新型解决方案。安装起来很简单，而且他们的方法对 k8s 做了很好的抽象，但是他们也允许你通过经典的 k8s 方式来保持某种形式的控制，比如 yaml 文件。我真的很愿意用它，效果很好！

然而，我确实注意到，它的一些 CLI 还不是很完善，但是，我认为这只是些小瑕疵，并不能代表最终产品。

这个项目符合所有条件。一个真正容易使用的 CLI？是的。不再以任何方式与 k8s 交互？是的。使用 Dockerfile 进行部署？是的！它们还提供了大量其他平台没有实现或实现得很差的特性。来自 Rancher 的 Rio 似乎从他们活跃的社区得到了大量支持。

在 garbage server 上进行安装设置

我快速地为 k3s 实例设置好反向代理，并开始设置 Rio。

参照他们 GitHub 页面上的快速入门指南，这个过程变得超级简单：

curl-sfLhttps:riorunhttps:

这样就行。我超级激动，希望马上看一下，现有的基础设施能否同样轻松地迁移。

Rio 的默认安装允许你使用他们的 rDNS 服务 on-rio.io，这个服务很酷，但不需要把我的 garbage server 放在反向代理后面。我还没有使用 Linkerd 的经验，所以现在只是禁用它。使用命令 rio install --disable-feature rdns,letsencrypt,linkerd 重新安装后，我获得了想要的结果。

接下来，通过 kubectl 安装自定义的 ClusterDomain，这让我能使用 on-rio.io 之外的另一个域。最后，我安装了 dnsmasq，并创建了一个名为 app.rio 的假域名，我的应用程序会在这个域名上解析。这将让我能轻松地在 garbage server 上测试到应用程序的连接。

我还得想办法从 DigitalOcean droplet 连接到这个集群。我从 garbage server 上的 80 端口反向代理到 8080 端口上的 droplet。Rio 使用 80 端口安装了 Gloo 的 gateway-proxy。

最后一步，我设置了 nginx 配置，使其指向 Gloo 网关：

proxy_passhttp:

这有两件重要的地方需要注意，分别是 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 无法识别我要访问的是哪个服务。

这就是我寻找最合适的 Kubernetes PaaS 解决方案的冒险。