本文經(jīng)AI新媒體量子位（公眾號ID:QbitAI）授權(quán)轉(zhuǎn)載，轉(zhuǎn)載請聯(lián)系出處。

Kubernetes，作為Google在2014年發(fā)布的一個開源項目。

這是一個自動化部署、伸縮和操作應(yīng)用程序容器的開源平臺，可以做到快速提供給基礎(chǔ)架構(gòu)以真正的以容器為中心的開發(fā)環(huán)境。

畢竟在云原生風(fēng)靡的今天，容器將成為最重要的計算資源形式。

過去一年，要論Kubernetes的技術(shù)發(fā)展咋樣？

可能成熟與穩(wěn)定二詞最能概括。

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

再也不是熱衷于技術(shù)創(chuàng)新的初創(chuàng)型公司扎推聚集的時代。

關(guān)于這種格局變化，Rancher想必記憶猶新。

Rancher Labs由CloudStack之父梁勝創(chuàng)建，一直以來都算是最先扎入該領(lǐng)域的“排頭兵”。

其旗艦產(chǎn)品Rancher，作為一個開源的企業(yè)級Kubernetes管理平臺，率先實現(xiàn)了Kubernetes集群在混合云+本地數(shù)據(jù)中心的集中部署與管理，并已于2020年2月完成了中國本土化和國產(chǎn)化。

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

但如今，各家參與者都會將以容器為代表的云原生服務(wù)提升到核心服務(wù)的范疇。

當(dāng)然，這種變化還集中表現(xiàn)在參與者在認可云原生領(lǐng)域或者技術(shù)棧的同時，更多思考業(yè)務(wù)“落地”的問題。

例如應(yīng)用的運行、微服務(wù)的治理甚至是Kubernetes集群的管理與安全，還包括與新技術(shù)AI的結(jié)合等。

就此推斷，或許更加關(guān)注生態(tài)層面的創(chuàng)新，越發(fā)靈活適應(yīng)用戶需求變化，通過創(chuàng)新性的項目產(chǎn)品來解決云原生推廣或者落地過程中的諸多問題，可能才是企業(yè)決勝云原生戰(zhàn)事的關(guān)鍵。

此外談及云原生的落地問題，K8S多集群管理、容器邊緣部署包括與AI技術(shù)相結(jié)合等層面都是不容規(guī)避的難點。

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

從關(guān)注發(fā)展到應(yīng)對實戰(zhàn)：集群管理表示“有話要說”

如果我們的推斷還算靠譜，實戰(zhàn)云原生的關(guān)鍵之一可以聚焦為Kubernetes集群的管理。

就如同Rancher最早開始的產(chǎn)品定位一樣：聚焦多集群管理或者混合云、多云的多集群管理。

究竟何為多集群？

從實踐看，對于大部分剛開始使用云原生或者Kubernetes技術(shù)的企業(yè)來說，使用的就已經(jīng)不是單集群了，但此時更多被簡單定義為少量集群。

舉個例子，很多企業(yè)開發(fā)環(huán)境中有一個集群，生產(chǎn)環(huán)境中又有一個集群，這或許是剛開始上線的典型場景。

但伴隨業(yè)務(wù)發(fā)展體量擴大，容器平臺在企業(yè)內(nèi)部采納的程度變得越來越高，用戶就會隨之發(fā)現(xiàn)有更多應(yīng)用需要遷移到集群之上。

從單一數(shù)據(jù)中心部署過渡到多數(shù)據(jù)中心，甚至?xí)霈F(xiàn)多云場景，進而產(chǎn)生多集群管理的問題。

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

對于平臺建設(shè)團隊，多集群管理技術(shù)更多意味著如何能夠幫助屏蔽底層基礎(chǔ)設(shè)施的差異性，來提供一致性的認證授權(quán)，以及管理、運維能力。

而針對應(yīng)用團隊來說，更希望以一個統(tǒng)一且具備一致性的方式去部署和使用這些集群，能夠在不同的集群之上提供一個一致性的上層支撐能力。將監(jiān)控、告警、日志采集或者包括微服務(wù)治理在內(nèi)的種種應(yīng)用，更快速地部署到多個集群中是關(guān)鍵。

以金融用戶多活的數(shù)據(jù)中心為例，它是比較典型的兩地三中心的架構(gòu)，對于應(yīng)用團隊而言，他們的關(guān)注點更加集中在：是否能將一些核心業(yè)務(wù)系統(tǒng)快速一鍵部署到數(shù)據(jù)中心，來實現(xiàn)跨數(shù)據(jù)中心的容災(zāi)或者多活？

基于此，Rancher對自己的產(chǎn)品做了一些增強，包括多集群、多租戶的監(jiān)控功能以及單一應(yīng)用跨多Kubernetes集群的部署和管理等。

具體來說，在定義集群模板的基礎(chǔ)上，可以一鍵將應(yīng)用商店的應(yīng)用程序系統(tǒng)無縫部署到任意數(shù)量集群中的多個Project里。

談及安全，一直以來都是企業(yè)非常關(guān)注的問題，在容器集群管理的范疇亦不例外。

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

從容器平臺的安全性著眼，往往關(guān)注的就不僅僅是集群的安全本身

反而會更多地覆蓋到從應(yīng)用開發(fā)到最后交付容器化運行的整個生命周期的安全過程。

例如定向安全。

整個容器的鏡像怎么保證其中內(nèi)置的組件或者服務(wù)不存在一些安全漏洞，用戶對于這一點的關(guān)注還算比較常見。

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

比方說遵照安全基準(zhǔn)測試benchmark，關(guān)閉匿名訪問端口，各個組件之間使用雙向的TLS加密，判斷相關(guān)組件是不是以最小權(quán)限去啟動等。

除此之外，集群的運行安全還涉及到集群更上層的應(yīng)用運行時的一些配置，例如容器運行時runtime。

如果是在多租戶的場景中，不同的租戶之間如何去做網(wǎng)絡(luò)隔離也會被考慮其中，甚至還會借助一些專業(yè)安全廠商的技術(shù)支持。

盡管容器安全非常復(fù)雜，但安全管理不容忽視。

邊緣側(cè)場景下的集群管理，難在何處？

其實容器技術(shù)用在邊緣側(cè)并不新鮮，對該論斷江鵬表示認可。

例如微軟的Azure，Azure IoT中心的配置是業(yè)界早已客觀存在的實例。

區(qū)別在于，Azure IoT中心是基于Docker容器技術(shù)，現(xiàn)階段可能還沒有使用類似Kubernetes的一些編排。

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

也就是說，這種“天然”適合在類似于邊緣側(cè)這樣的大規(guī)模應(yīng)用統(tǒng)一標(biāo)準(zhǔn)化部署。

這么一總結(jié)就更加司空見慣。

盡管容器具有與生俱來的天然屬性，但部署管理的過程所面臨的問題卻并沒有在云端、數(shù)據(jù)中心甚至是異構(gòu)基礎(chǔ)設(shè)施上部署那么簡單。

從直觀數(shù)量上看，邊緣側(cè)的集群量級不再是傳統(tǒng)數(shù)據(jù)中心中幾十個或者是十幾個集群的情況。

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

更重要的是，邊緣場景與傳統(tǒng)的云端或者是數(shù)據(jù)中心場景，最大的區(qū)別在于，邊緣場景是一個非常多樣化或者碎片化的場景。

相對于數(shù)據(jù)中心來說，大家使用的是標(biāo)準(zhǔn)的X86服務(wù)器以及統(tǒng)一存儲，Kubernetes可以提供一致性的API去支撐業(yè)務(wù)的標(biāo)準(zhǔn)化運行。

但在邊緣側(cè)，不管是業(yè)務(wù)場景使用設(shè)備本身，還是使用的協(xié)議上都會存在很大區(qū)別。

“舉個簡單的例子，一些制造業(yè)客戶的生產(chǎn)線上會有很多windows系統(tǒng)，而不是Linux系統(tǒng)，甚至更多可能還不是windows server。如果這些設(shè)備通過一些協(xié)議去和產(chǎn)線上的其他設(shè)備進行交互的話，難度可想而知。”

那么究竟該如何管理這樣一個超大規(guī)模集群呢？

目前來看，還沒有一個統(tǒng)一的數(shù)據(jù)中心場景或者平臺推出，來形成大一統(tǒng)規(guī)范。

在邊緣場景中，用戶要去進行一些系統(tǒng)或是應(yīng)用的容器化或者是云原生改造，還需要有一個逐步適配、改造的過程。

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

“我們已經(jīng)看到將Docker引擎用在邊緣側(cè)，但在邊緣側(cè)要實現(xiàn)更強大的編排能力，是否將標(biāo)準(zhǔn)的Kubernetes的推到邊緣側(cè)，還亟待探討。”

據(jù)量子位了解，大部分投身容器的云服務(wù)商還是更多選擇將標(biāo)準(zhǔn)的Kubernetes部署在邊緣側(cè)，以求有效管理；但Rancher例外，這也是K3s應(yīng)時而出的原因。

降低用戶去部署和管理Kubernetes的復(fù)雜度，不再需要管理各種復(fù)雜的組件，開箱即用一鍵部署。

也不用費盡心力去維護像ETCD這種比較新的key-value數(shù)據(jù)。

從以上出發(fā)，降低資源消耗，讓用戶在低計算資源的設(shè)備上也能夠去運行Kubernetes 集群等，或許是K3s的優(yōu)勢所在。

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

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

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

如今，無論是AI行業(yè)的專業(yè)廠商，還是實際AI訓(xùn)練的場景應(yīng)用，出現(xiàn)了越來越多將AI業(yè)務(wù)運行在容器之上的情況，此舉也逐漸成為探究業(yè)務(wù)落地的重要問題之一。

例如在AI模型的訓(xùn)練中，大量訪問或者讀取的數(shù)據(jù)、圖片或者源文件等注定了大規(guī)模算力的消耗，然而典型的大規(guī)模計算場景，正是容器所需要的。

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

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

如今Kubernetes 本身對于CPU資源的共享和調(diào)度的能力還不是太強。

江鵬表示，由于Nvidia官方并沒有像vGPU的實現(xiàn)，導(dǎo)致在標(biāo)準(zhǔn)的Kubernetes或者社區(qū)版的Kubernetes集群之中，資源調(diào)度的粒度比較粗，資源的利用率不是太高。

另外在容器化場景中，可能對于模型訓(xùn)練碎片化的小文件、海量文件處理的性能表現(xiàn)也不甚理想。

盡管如此，Gartner 在2019年發(fā)布的一份關(guān)于AI的預(yù)測報告中依舊表明了“態(tài)度”。

當(dāng)企業(yè)CIO們將AI作為被思考的頭等大事兒時，對于Kubernetes的關(guān)鍵作用也不容小覷。

Gartner稱，Kubernetes將成為企業(yè)內(nèi)部AI應(yīng)用首選的運行環(huán)境和平臺。

容器和Serverless將使機器學(xué)習(xí)模型作為獨立的功能提供服務(wù)，從而以更低的開銷運行AI應(yīng)用，足見Kubernetes+AI前景光明。

針對Kubernetes的成熟穩(wěn)定，你又有什么看法呢？

附：采訪嘉賓簡介