怎樣為 k8s 找到最合適的 PaaS 解決方案？
最近幾年，Kubernetes 成為許多人關注的焦點。事實上，有些公司發現 Kubernetes 能發揮巨大作用，但有些公司還未發現其價值，并在這個過程中將自己搞得“遍體鱗傷”。對我來說，我正處于中間位置。我打算做類似事情，并且做好了踩坑準備。在此之前，先讓我們看看如何在 k8s 上部署一個簡單的、類似于 PaaS 的平臺。
1. 找到一個完美的類 PaaS 平臺
那么，我們從哪里開始？肯定有一種簡單方法能找到這樣的東西，也許，我們從簡單的 DuckDuckGo 搜索開始。
DuckDuckGo 搜索沒啥用
顯然，k8s 不是 PaaS。我想基于 k8s 構建一個 PaaS，當然不是把它當作一個 PaaS 來使用。
然后，我們在 HackerNews 上搜索一下。第一個查詢找到一篇失效文章。此外，我在 GitHub 上偶然發現一個很棒的列表。
https://github.com/ramitsurana/awesome-kubernetes
在進行更廣泛的搜索后，我針對自己的應用場景列出一個可能的候選項目列表。
- Knative
- OpenFaaS Cloud
- Convox
- Garden
- Rio
還有很多其他選擇，我嘗試過其中一些，還有一些是針對大企業的。
2. 我的應用場景
在 Quest Vault ，我們在 DigitalOcean droplet 上安裝一個簡單的 Wordpress 來運行我們的電商網站。盡管能通過運行一些簡單的 bash 腳本實現部署，并在本地運行測試 / 過渡服務器的副本，但是，我想構建一個基于行業技術的平臺，而不是一些 bash 腳本。編寫這些 bash 腳本很有趣，并且擁有自己的部署技術棧也很簡單，但是，我希望 Quest Vault 能擁有一個“豪華些”的東西，一個標準的、讓我們不必為使用的工具操心的東西。
https://questvault.net/
現在，我想在辦公室運行 k3s 的 garbage server 上測試這些項目。K3s 有一個到 DigitalOcean droplet 的反向代理，而不是在互聯網上訪問。這意味著項目應該支持內部部署。
https://k3s.io/
我還希望能完全抽象出 k8s。這意味著我不想處理太多的 yaml 或者一直部署 helm charts，我想多考慮下應用程序，并且通過 CLI 就可以做到。
簡而言之：我想要的是，只要按一個按鈕，它就工作。
我們的應用程序有很多活動組件，有些只是簡單腳本，有些則是為游戲客戶端提供通信的大型應用程序。不管是什么，我們的平臺需要支持大量不同的應用程序類型。這通常意味著支持通過 Dockerfile 進行部署。
我們計劃運行的大多數應用程序都與狀態密切相關。以 Wordpress 為例，我們需要一個存儲圖片的地方。我們還有很多需要存儲的應用內照片拍攝。我們需要一種方法使我們的應用程序具有某種形式的持久化。
我喜歡的項目很多，但是一個好項目和一個偉大項目的區別在于社區和行業的采用。擁有自己的 bash 腳本和在 GitHub 上有 3 個活動用戶的項目幾乎沒有區別。如果你搞砸了，或者無論出于什么原因需要一些建議，你都希望能從一個活躍的社區獲得幫助。
3. 項目清單速覽
Knative
我的 Knative 經驗有一個不錯的開頭！當讀過關于它的文章后，我很高興地得知：我能運行一個平臺，谷歌在其平臺內部就把它用于他們自己的類似 PaaS 的部署。考慮到谷歌創造了 k8s，這一定非常合適！它的安裝過程比預期困難得多。
https://knative.dev/docs/install/any-kubernetes-cluster/
似乎沒有什么簡單方法來安裝這個平臺，而且，無法輕松地使用一個平臺會是將來的一個風險。
OpenFaaS Cloud
安裝非常簡單！我很快就讓這個平臺運行了起來。它滿足我的大多數需求，不過，它似乎更像是實現 OpenFaas 的一種有趣方式，而不是完全成熟的 PaaS 可選方案。我不知道如何將我們的用例放到這個特別的平臺上。如果你正在搭配使用耦合度比較低的項目或比較小的功能，這是一個很好的選擇！
Convox
Convox 看起來很棒！幾名前 Heroku 工程師，在 k8s 上構建的一個平臺。似乎完美！我想嘗試一下，馬上就開始在 DigitalOcean k8s 集群上部署它。開發體驗非常棒！
然而，他們似乎并不支持平臺的內部部署版本。此外，除一些早期采用者外，這個項目似乎沒有一個非常大的社區。相比而言，這個項目不是很出名，最終我放棄它，去尋找另一種選擇。
Garden
這是一個非常酷的項目。我喜歡它，一家小型的獨立公司開發的一個創新型解決方案。安裝起來很簡單，而且他們的方法對 k8s 做了很好的抽象，但是他們也允許你通過經典的 k8s 方式來保持某種形式的控制，比如 yaml 文件。我真的很愿意用它，效果很好！
然而，我確實注意到，它的一些 CLI 還不是很完善，但是，我認為這只是些小瑕疵，并不能代表最終產品。
Rio
這個項目符合所有條件。一個真正容易使用的 CLI？是的。不再以任何方式與 k8s 交互？是的。使用 Dockerfile 進行部署？是的！它們還提供了大量其他平臺沒有實現或實現得很差的特性。來自 Rancher 的 Rio 似乎從他們活躍的社區得到了大量支持。
https://rancher.com/blog/2019/rio-revolutionizing-the-way-you-deploy-apps
在 garbage server 上進行安裝設置
我快速地為 k3s 實例設置好反向代理，并開始設置 Rio。
參照他們 GitHub 頁面上的快速入門指南，這個過程變得超級簡單：
- # Setting up the reverse proxy to k3s
- ssh -nNTL 6443:localhost:6443 droplet &
- # Installing Rio
- curl -sfL https://get.rio.io | sh -
- # Running the example project
- rio run https://github.com/rancher/rio-demo
這樣就行。我超級激動，希望馬上看一下，現有的基礎設施能否同樣輕松地遷移。
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 上測試到應用程序的連接。
- apiVersion: admin.rio.cattle.io/v1
- kind: ClusterDomain
- metadata:
- name: app.rio
- spec:
- httpPort: 80
我還得想辦法從 DigitalOcean droplet 連接到這個集群。我從 garbage server 上的 80 端口反向代理到 8080 端口上的 droplet。Rio 使用 80 端口安裝了 Gloo 的 gateway-proxy。
最后一步，我設置了 nginx 配置，使其指向 Gloo 網關：
- server {
- listen 80;
- server_name your.domain.name;
- location / {
- proxy_http_version 1.1;
- proxy_set_header Host $host;
- proxy_pass http://localhost:8080;
- }
- }
這有兩件重要的地方需要注意，分別是 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 無法識別我要訪問的是哪個服務。
- rio domain register your.domain.name rio-demo
這就是我尋找最合適的 Kubernetes PaaS 解決方案的冒險。
