本文經AI新媒體量子位（公眾號ID:QbitAI）授權轉載，轉載請聯系出處。

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的成熟穩定，你又有什么看法呢？

附：采訪嘉賓簡介