如何選擇基於 Kubernetes 的 PaaS?

如何選擇基於 Kubernetes 的 PaaS?

作者 | Bram Dingelstad

頭圖 | CSDN 下載自視覺中國

出品 | CSDN(ID:CSDNnews)

我們都遇到過這種情況:有人發現了一個bug,然而這不是一般的軟件bug,甚至都不是通常意義上的bug,其本質上是人員的問題:盲目跟風的開發者。

一開始時這個bug很小,他只是在勸說團隊採用新的技術,或者在項目裡採用一個新的模塊,但在不知不覺之間,到處都是奇怪的項目和天花亂墜的文檔,聲稱只需要三步就能解決你的業務問題!然而,要想真的解決問題,似乎還需要花費更多的工夫。

我們都遇到過這種情況,而去年的類似情況之一就是一個名為Kubernetes的項目。有些公司和團隊已經被Kubernetes淹沒,有些公司還沒有入坑。我處於中間地帶,剛剛開始構建一個超級複雜的系統準備入坑。但在這之前,我想先介紹一下怎樣在Kubernetes上部署一個簡單的、類PaaS的平臺。

如何选择基于 Kubernetes 的 PaaS?

尋找完美的類PaaS平臺

從何處下手呢?一定有一個完美的方法,對不對?也許吧,我們先做一下搜索:

如何选择基于 Kubernetes 的 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

還有許多其他的替代項目,一些項目我曾經嘗試過,一些項目並不是太活躍,一些項目顯然是給大型企業用的。

如何选择基于 Kubernetes 的 PaaS?

我的情況

我的情況是怎樣的?我們需要在一個基本的DigitalOcean droplet上運行一個電商網站,上面只有一個簡單的Wordpress。儘管只需要一個簡單的bash腳本就可以把網站建起來,還能在本地建一臺測試用的服務器,但我想做一個工業標準的平臺,而不是簡單的腳本。寫腳本很有趣,自己做部署棧也很方便,但遵循標準、不需要自己考慮工具的事情,才是我真正想要的。

我的需求

我想先在一臺k3s的垃圾服務器上測試一下這些項目。k3s有一個反向代理,指向DigitalOcean上的droplet,而不是直接在互聯網上公開。也就是說,這些項目必須支持本地部署(on-premise deployment)。

另一個需求是,該項目必須完全從k8s中抽象出來。也就是說,我不想處理大量的yaml文件也不想一直部署helm charts,我想從我自己的應用程序的方面來思考,只需要通過命令行就可以完成一切工作。

用一句話總結就是:我希望只要按一個按鈕就能完成一切工作。

我們的應用程序有許多可動的部分,一部分僅是簡單的腳本,一部分是大型應用程序,給遊戲客戶端提供通訊功能。不管是什麼應用程序,我們的平臺需要支持大量不同類型的應用程序。通常這意味著需要支持通過Dockerfile進行部署。

我們打算運行的絕大多數應用程序都是有狀態的。例如,Wordpress需要一個地方來保存圖片。許多應用程序內部的圖片也需要存儲。因此,應用程序需要某種形式的持久存儲。

許多項目都很好,但好項目和偉大項目的區別就是社區和行業的接受度。使用一個在GitHub上只有三個用戶的項目,跟自己寫bash腳本沒有區別。萬一你搞壞了什麼東西,或者需要什麼幫助,一個活躍的社區將是你的依靠。

如何选择基于 Kubernetes 的 PaaS?

項目一覽

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活躍的社區中得到了許多支持。

如何选择基于 Kubernetes 的 PaaS?

在我的垃圾服務器上設置Rio

我迅速地設置好了通向我的k3s實例的反向代理,然後開始設置Rio。

根據他們的GitHub上的快速上手指南,設置非常簡單:

<code># Setting up the reverse proxy to k3s/<code><code>ssh -nNTL 6443:localhost:6443 droplet &/<code>
<code># Installing Rio/<code><code>curl -sfL https://get.rio.io | sh -/<code>
<code># Running the example project/<code><code>rio run https://github.com/rancher/rio-demo/<code>

這就好了!我迫不及待地想看看我們已有的基礎設施是否能夠同樣容易地遷移到這個平臺上。

Rio的默認安裝允許你使用他們的rDNS服務(位於on-rio.io),這一點非常酷,但我放在反向代理後面的垃圾服務器並不需要。我也沒用過Linkerd,所以暫時先禁用了該功能。使用 rio install --disable-feature rdns,letsencrypt,linkerd 語句重新安裝,就得到了我需要的結果。

下一步,使用kubectl安裝自定義的ClusterDomain,這樣我就可以使用on-rio.io之外的域名了。我最終安裝了dnsmasq,設置了一個假的域名app.rio供應用程序使用。通過它可以很容易地在垃圾服務器上測試應用程序的連通性。

<code>apiVersion: admin.rio.cattle.io/v1/<code><code>kind: ClusterDomain/<code><code>metadata:/<code><code> name: app.rio/<code><code>spec:/<code><code> httpPort: 80/<code>

我還要想個辦法從我的DigitalOcean droplot上連接到這個集群。我的方法是從垃圾服務器的80端口反向代理到droplet的8080端口上。Rio採用80端口安裝Gloo的gateway-proxy。

最後一步,設置nginx配置指向Gloo的網關:

<code>server {/<code><code> listen 80;/<code><code> server_name your.domain.name;/<code>
<code> location / {/<code><code> proxy_http_version 1.1;/<code><code> proxy_set_header Host $host;/<code><code> proxy_pass http://localhost:8080;/<code><code> }/<code><code>}/<code>

此處的兩個重點是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無法識別要連接哪個服務。

<code>rio domain register your.domain.name rio-demo/<code>

以上就是我探索基於Kubernetes的最合適的PaaS之旅。

原文:https://bram.dingelstad.xyz/blog/finding-the-right-paas-for-k8s/

本文為 CSDN 翻譯,轉載請註明來源出處。

如何选择基于 Kubernetes 的 PaaS?

☞開源激盪 30 年:從免費社區到價值數十億美元公司

☞理解 AI 最偉大的成就之一:卷積神經網絡的侷限性

☞GitHub 標星 10,000+,Apache 頂級項目 ShardingSphere 的開源之路

☞港科大鄭光廷院士問診未來,揭露 AI 最新應用與實踐

☞大促下的智能運維挑戰:阿里如何抗住“雙11貓晚”?

☞以太坊2.0中的Custody Game及MPC實現

☞很用心的為你寫了9道MySQL面試題,建議收藏!


分享到:


相關文章: