| 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系統，而不是Linux系統，甚至更多可能還不是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的成熟穩定，你又有什麼看法呢？