谷歌Kubernets搞叢集管理的方法

Kubernetes，作為Google在2014年釋出的一個開源專案。這是一個自動化部署、伸縮和操作應用程式容器的開源平臺，可以做到快速提供給基礎架構以真正的以容器為中心的開發環境。畢竟在雲原生風靡的今天，容器將成為最重要的計算資源形式。

過去一年，要論Kubernetes的技術發展咋樣？

可能成熟與穩定二詞最能概括。

其中值得提及的一點，越來越多的重量級玩家開始入局雲原生市場。

再也不是熱衷於技術創新的初創型公司扎推聚集的時代。

關於這種格局變化，Rancher想必記憶猶新。

Rancher Labs由CloudStack之父梁勝建立，一直以來都算是最先扎入該領域的“排頭兵”。

其旗艦產品Rancher，作為一個開源的企業級Kubernetes管理平臺，率先實現了Kubernetes叢集在混合雲+本地資料中心的集中部署與管理，並已於2020年2月完成了中國本土化和國產化。

對此，Rancher中國 CTO 江鵬感同身受，2017-2018年，那時更多的雲服務廠商將容器視為自身服務的一種，但並不是最核心的那一個。

但如今，各家參與者都會將以容器為代表的雲原生服務提升到核心服務的範疇。

當然，這種變化還集中表現在參與者在認可雲原生領域或者技術棧的同時，更多思考業務“落地”的問題。

例如應用的執行、微服務的治理甚至是Kubernetes叢集的管理與安全，還包括與新技術AI的結合等。

就此推斷，或許更加關注生態層面的創新，越發靈活適應使用者需求變化，透過創新性的專案產品來解決雲原生推廣或者落地過程中的諸多問題，可能才是企業決勝雲原生戰事的關鍵。

此外談及雲原生的落地問題，K8S多叢集管理、容器邊緣部署包括與AI技術相結合等層面都是不容規避的難點。

如果你在容器實踐過程中“犯了難”，不妨往下看看，或許可以在理念意識上消除部分疑惑。

從關注發展到應對實戰：叢集管理表示“有話要說”

如果我們的推斷還算靠譜，實戰雲原生的關鍵之一可以聚焦為Kubernetes叢集的管理。

就如同Rancher最早開始的產品定位一樣：聚焦多叢集管理或者混合雲、多雲的多叢集管理。

從實踐看，對於大部分剛開始使用雲原生或者Kubernetes技術的企業來說，使用的就已經不是單叢集了，但此時更多被簡單定義為少量叢集。

舉個例子，很多企業開發環境中有一個叢集，生產環境中又有一個叢集，這或許是剛開始上線的典型場景。

但伴隨業務發展體量擴大，容器平臺在企業內部採納的程度變得越來越高，使用者就會隨之發現有更多應用需要遷移到叢集之上。

從單一資料中心部署過渡到多資料中心，甚至會出現多雲場景，進而產生多叢集管理的問題。

江鵬進一步透露，多叢集管理中的“多”還不單單體現在叢集的量級，哪怕在不同團隊中，理念上也會存在不小的差異。

對於平臺建設團隊，多叢集管理技術更多意味著如何能夠幫助遮蔽底層基礎設施的差異性，來提供一致性的認證授權，以及管理、運維能力。

而針對應用團隊來說，更希望以一個統一且具備一致性的方式去部署和使用這些叢集，能夠在不同的叢集之上提供一個一致性的上層支撐能力。將監控、告警、日誌採集或者包括微服務治理在內的種種應用，更快速地部署到多個叢集中是關鍵。

以金融使用者多活的資料中心為例，它是比較典型的兩地三中心的架構，對於應用團隊而言，他們的關注點更加集中在：是否能將一些核心業務系統快速一鍵部署到資料中心，來實現跨資料中心的容災或者多活？

基於此，Rancher對自己的產品做了一些增強，包括多叢集、多租戶的監控功能以及單一應用跨多Kubernetes叢集的部署和管理等。

具體來說，在定義叢集模板的基礎上，可以一鍵將應用商店的應用程式系統無縫部署到任意數量叢集中的多個Project裡。

談及安全，一直以來都是企業非常關注的問題，在容器叢集管理的範疇亦不例外。

如果說從整個平臺安全形度考慮的話，我們一般討論安全問題，它一定是一個端到端的解決方案。

從容器平臺的安全性著眼，往往關注的就不僅僅是叢集的安全本身

反而會更多地覆蓋到從應用開發到最後交付容器化執行的整個生命週期的安全過程。

例如定向安全。

整個容器的映象怎麼保證其中內建的元件或者服務不存在一些安全漏洞，使用者對於這一點的關注還算比較常見。

如果涉及到叢集安全層面，是否符合業內的最佳推薦建議則變得重要起來。

比方說遵照安全基準測試benchmark，關閉匿名訪問埠，各個元件之間使用雙向的TLS加密，判斷相關元件是不是以最小許可權去啟動等。

除此之外，叢集的執行安全還涉及到叢集更上層的應用執行時的一些配置，例如容器執行時runtime。

如果是在多租戶的場景中，不同的租戶之間如何去做網路隔離也會被考慮其中，甚至還會藉助一些專業安全廠商的技術支援。

儘管容器安全非常複雜，但安全管理不容忽視。

邊緣側場景下的叢集管理，難在何處？

其實容器技術用在邊緣側並不新鮮，對該論斷江鵬表示認可。

例如微軟的Azure，Azure IoT中心的配置是業界早已客觀存在的例項。

區別在於，Azure IoT中心是基於Docker容器技術，現階段可能還沒有使用類似Kubernetes的一些編排。

更重要的一點，容器技術天然可作為一種應用交付方式或者應用打包交付的方式存在。

也就是說，這種“天然”適合在類似於邊緣側這樣的大規模應用統一標準化部署。

這麼一總結就更加司空見慣。

儘管容器具有與生俱來的天然屬性，但部署管理的過程所面臨的問題卻並沒有在雲端、資料中心甚至是異構基礎設施上部署那麼簡單。

從直觀數量上看，邊緣側的叢集量級不再是傳統資料中心中幾十個或者是十幾個叢集的情況。

反而可能是幾千個或者上萬個，甚至是幾十萬個這樣一個叢集量級。

更重要的是，邊緣場景與傳統的雲端或者是資料中心場景，最大的區別在於，邊緣場景是一個非常多樣化或者碎片化的場景。

相對於資料中心來說，大家使用的是標準的X86伺服器以及統一儲存，Kubernetes可以提供一致性的API去支撐業務的標準化執行。

但在邊緣側，不管是業務場景使用裝置本身，還是使用的協議上都會存在很大區別。

“舉個簡單的例子，一些製造業客戶的生產線上會有很多windows系統，而不是 ，甚至更多可能還不是windows server。如果這些裝置透過一些協議去和產線上的其他裝置進行互動的話，難度可想而知。”

目前來看，還沒有一個統一的資料中心場景或者平臺推出，來形成大一統規範。

在邊緣場景中，使用者要去進行一些系統或是應用的容器化或者是雲原生改造，還需要有一個逐步適配、改造的過程。

但江鵬也坦承，將容器技術利用在邊緣側，確實是一個亟待發揚光大的趨勢與需求。

“我們已經看到將Docker引擎用在邊緣側，但在邊緣側要實現更強大的編排能力，是否將標準的Kubernetes的推到邊緣側，還亟待探討。”

據量子位瞭解，大部分投身容器的雲服務商還是更多選擇將標準的Kubernetes部署在邊緣側，以求有效管理；但Rancher例外，這也是K3s應時而出的原因。

降低使用者去部署和管理Kubernetes的複雜度，不再需要管理各種複雜的元件，開箱即用一鍵部署。

也不用費盡心力去維護像ETCD這種比較新的key-value資料。

從以上出發，降低資源消耗，讓使用者在低計算資源的裝置上也能夠去執行Kubernetes 叢集等，或許是K3s的優勢所在。

此外，最近官宣開源的Fleet，也正是Rancher以管理cattle的方式去管理部門的子叢集，確保海量Kubernetes叢集的集中管理優勢體驗。

“關注的著眼點不再是某一個叢集的應用部署情況，而是把叢集作為一個叢集組（cluster group），從一個更高維度去做管理。”

容器+AI ，究竟能夠做啥？

如今，無論是AI行業的專業廠商，還是實際AI訓練的場景應用，出現了越來越多將AI業務執行在容器之上的情況，此舉也逐漸成為探究業務落地的重要問題之一。

例如在AI模型的訓練中，大量訪問或者讀取的資料、圖片或者原始檔等註定了大規模算力的消耗，然而典型的大規模計算場景，正是容器所需要的。

但喜憂參半，AI在實際落地在容器場景中也多少存在挑戰。

比方說資源共享劃分的粒度。

如今Kubernetes 本身對於CPU資源的共享和排程的能力還不是太強。

江鵬表示，由於Nvidia官方並沒有像vGPU的實現，導致在標準的Kubernetes或者社群版的Kubernetes叢集之中，資源排程的粒度比較粗，資源的利用率不是太高。

另外在容器化場景中，可能對於模型訓練碎片化的小檔案、海量檔案處理的效能表現也不甚理想。

儘管如此，Gartner 在2019年釋出的一份關於AI的預測報告中依舊錶明瞭“態度”。

當企業CIO們將AI作為被思考的頭等大事兒時，對於Kubernetes的關鍵作用也不容小覷。

Gartner稱，Kubernetes將成為企業內部AI應用首選的執行環境和平臺。

容器和Serverless將使機器學習模型作為獨立的功能提供服務，從而以更低的開銷執行AI應用，足見Kubernetes+AI前景光明。

針對Kubernetes的成熟穩定，你又有什麼看法呢？

原文地址：