我們都遇到過這種情況：有人發(fā)現(xiàn)了一個bug，然而這不是一般的軟件bug，甚至都不是通常意義上的bug，其本質(zhì)上是人員的問題：盲目跟風(fēng)的開發(fā)者。
一開始時這個bug很小，他只是在勸說團隊采用新的技術(shù)，或者在項目里采用一個新的模塊，但在不知不覺之間，到處都是奇怪的項目和天花亂墜的文檔，聲稱只需要三步就能解決你的業(yè)務(wù)問題！然而，要想真的解決問題，似乎還需要花費更多的工夫。
我們都遇到過這種情況，而去年的類似情況之一就是一個名為Kubernetes的項目。有些公司和團隊已經(jīng)被Kubernetes淹沒，有些公司還沒有入坑。我處于中間地帶，剛剛開始構(gòu)建一個超級復(fù)雜的系統(tǒng)準(zhǔn)備入坑。但在這之前，我想先介紹一下怎樣在Kubernetes上部署一個簡單的、類PaaS的平臺。
尋找完美的類PaaS平臺
從何處下手呢？一定有一個完美的方法，對不對？也許吧，我們先做一下搜索：
嗯……顯然，k8s并不是PaaS。我想在PaaS之上構(gòu)建PaaS，而不是把k8s當(dāng)做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）。
經(jīng)過一番仔細的搜索后，我列出了一些候選的項目：
●Knative
●OpenFaas Cloud
●Convox
●Garden
●Rio
還有許多其他的替代項目，一些項目我曾經(jīng)嘗試過，一些項目并不是太活躍，一些項目顯然是給大型企業(yè)用的。
我的情況
我的情況是怎樣的？我們需要在一個基本的DigitalOcean droplet上運行一個電商網(wǎng)站，上面只有一個簡單的Wordpress。盡管只需要一個簡單的bash腳本就可以把網(wǎng)站建起來，還能在本地建一臺測試用的服務(wù)器，但我想做一個工業(yè)標(biāo)準(zhǔn)的平臺，而不是簡單的腳本。寫腳本很有趣，自己做部署棧也很方便，但遵循標(biāo)準(zhǔn)、不需要自己考慮工具的事情，才是我真正想要的。
我的需求
我想先在一臺k3s的垃圾服務(wù)器上測試一下這些項目。k3s有一個反向代理，指向DigitalOcean上的droplet，而不是直接在互聯(lián)網(wǎng)上公開。也就是說，這些項目必須支持本地部署（on-premise deployment）。
另一個需求是，該項目必須完全從k8s中抽象出來。也就是說，我不想處理大量的yaml文件也不想一直部署helm charts，我想從我自己的應(yīng)用程序的方面來思考，只需要通過命令行就可以完成一切工作。
用一句話總結(jié)就是：我希望只要按一個按鈕就能完成一切工作。
我們的應(yīng)用程序有許多可動的部分，一部分僅是簡單的腳本，一部分是大型應(yīng)用程序，給游戲客戶端提供通訊功能。不管是什么應(yīng)用程序，我們的平臺需要支持大量不同類型的應(yīng)用程序。通常這意味著需要支持通過Dockerfile進行部署。
我們打算運行的絕大多數(shù)應(yīng)用程序都是有狀態(tài)的。例如，Wordpress需要一個地方來保存圖片。許多應(yīng)用程序內(nèi)部的圖片也需要存儲。因此，應(yīng)用程序需要某種形式的持久存儲。
許多項目都很好，但好項目和偉大項目的區(qū)別就是社區(qū)和行業(yè)的接受度。使用一個在GitHub上只有三個用戶的項目，跟自己寫bash腳本沒有區(qū)別。萬一你搞壞了什么東西，或者需要什么幫助，一個活躍的社區(qū)將是你的依靠。
項目一覽
Knative
Knative最初給我的體驗棒極了！看了Knative之后，我發(fā)現(xiàn)我可以運行一個跟Google自家用的PaaS一樣的平臺?？紤]到k8s就是Google做的，那么Knative項目肯定是完美的！不過安裝要比想像的難了一點。似乎沒有太簡單的方法來安裝，而無法簡單地嘗試，在未來可能是一個風(fēng)險。也許只有我這樣想，也許我應(yīng)該更深入地研究一下Knative，不過由于這點原因，我把目光轉(zhuǎn)向了下一個候選。
OpenFaaS Cloud
安裝非常容易！很快我就能運行這個平臺了。它能滿足我的大部分要求，但似乎它更側(cè)重于實現(xiàn)OpenFaaS，本身并不是一個完整的PaaS。我不太明白如何利用這個平臺解決我們的問題。如果你使用的是耦合性更小的項目，或者有許多小功能，那OpenFaaS絕對是最佳選擇！也許以后我可以看看看，但現(xiàn)在我已經(jīng)決定看看下一個候選。
Convox
Convox看上去非常好！它是由幾名前Heroku工程師在k8s的基礎(chǔ)上構(gòu)建的。我在DigitalOpen的k8s集群上迅速部署了一下。開發(fā)者的體驗非常棒！但是，似乎該項目并不支持本地部署。而且，該項目的社區(qū)似乎并不大，只有一些早期的使用者。該項目不太出名，所以我還是選擇了其他項目。
Garden
這個項目非常酷。我喜歡它，是因為它由是一個獨立的小公司開發(fā)的非常有創(chuàng)意的解決方案。設(shè)置非常簡單，他們的方法論也是由k8s得出的非常好的抽象，但該項目還可以在某種形式上允許你用傳統(tǒng)的方式控制k8s，比如yaml文件等。我非常喜歡這個實現(xiàn)，而且它工作得很好！盡管我注意到命令行界面有些粗糙，但這畢竟是小問題，而且最終可能會被解決。
不過我還是決定看看下一個（也是最后一個）項目。
Rio
這個項目能滿足我的所有需求。易用的命令行界面，不需要與k8s交互，使用Dockerfile進行部署。還有一長串其他平臺未能實現(xiàn)或?qū)崿F(xiàn)得不太好的功能。Rio從Rancher中派生而來，似乎從Rancher活躍的社區(qū)中得到了許多支持。
在我的垃圾服務(wù)器上設(shè)置Rio
我迅速地設(shè)置好了通向我的k3s實例的反向代理，然后開始設(shè)置Rio。
根據(jù)他們的GitHub上的快速上手指南，設(shè)置非常簡單：
這就好了！我迫不及待地想看看我們已有的基礎(chǔ)設(shè)施是否能夠同樣容易地遷移到這個平臺上。
Rio的默認安裝允許你使用他們的rDNS服務(wù)（位于on-rio.io），這一點非?？幔曳旁诜聪虼砗竺娴睦?wù)器并不需要。我也沒用過Linkerd，所以暫時先禁用了該功能。使用 rio install --disable-feature rdns,letsencrypt,linkerd 語句重新安裝，就得到了我需要的結(jié)果。
下一步，使用kubectl安裝自定義的ClusterDomain，這樣我就可以使用on-rio.io之外的域名了。我最終安裝了dnsmasq，設(shè)置了一個假的域名app.rio供應(yīng)用程序使用。通過它可以很容易地在垃圾服務(wù)器上測試應(yīng)用程序的連通性。
我還要想個辦法從我的DigitalOcean droplot上連接到這個集群。我的方法是從垃圾服務(wù)器的80端口反向代理到droplet的8080端口上。Rio采用80端口安裝Gloo的gateway-proxy。
最后一步，設(shè)置nginx配置指向Gloo的網(wǎng)關(guān)：
此處的兩個重點是proxy_http_version 1.1和proxy_set_header Host。
proxy_http_version非常重要，因為基于Envoy的Gloo并不支持在http__version 1.0上進行網(wǎng)管服務(wù)，只能使用1.1。否則會返回426 Upgrade Required錯誤。
Host頭很重要，因為需要實現(xiàn)PublicDomain。添加PublicDomain時的重點是要匹配server_name或代理的Host頭，否則Gloo無法識別要連接哪個服務(wù)。
