如何用谷歌Kubernets搞集群管理？Rancher中國CTO江鵬手把手分享

晶少 發(fā)自 凹非寺
量子位 報(bào)道 | 公眾號 QbitAI

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

究竟何為多集群？

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

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

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

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

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

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

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

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

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

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

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

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

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

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

例如定向安全。

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

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

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

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

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

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

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

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

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

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

更重要的一點(diǎn)，容器技術(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ù)中心中幾十個(gè)或者是十幾個(gè)集群的情況。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

附：采訪嘉賓簡介

— 完 —

量子位 QbitAI · 頭條號簽約

關(guān)注我們，第一時(shí)間獲知前沿科技動(dòng)態(tài)