PaaS 处置方案 k8s 找到最适合的 怎么为

最近几年，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 处置方案的冒险。