通過借鑒他們在這一技術(shù)領(lǐng)域十年的經(jīng)驗(yàn),谷歌云平臺團(tuán)隊(duì)撰寫了一系列的文章分享其對容器的看法。谷歌的前兩篇文章提供了關(guān)于這個(gè)主題的總覽。這兩篇文章解釋了容器集群和他們所定義特征背后的邏輯。之后又向讀者展示了如何在Kubernetes上應(yīng)用這一切。
容器能夠帶來一系列的好處。包括更簡單的部署模型,快速可用性和微服務(wù)架構(gòu)理想的基礎(chǔ)設(shè)施層。像Docker之類的容器產(chǎn)品更關(guān)注于在單一計(jì)算機(jī)上操作。這就產(chǎn)生了協(xié)調(diào)多個(gè)容器的需求?;蛘哂酶呒壻Y深工程師和Kubernetes聯(lián)合創(chuàng)始人Joe Beda更喜歡的說法,“即興爵士樂表演”的管理需求,這個(gè)說法能夠更好地反映出容器管理對“實(shí)時(shí)條件和輸入”的反應(yīng)。
像Kubernetes這樣的容器集群提供了與集群管理、網(wǎng)絡(luò)和命名有關(guān)的服務(wù)。他們“創(chuàng)建了一個(gè)抽象的層次,讓開發(fā)人員和管理員可以將需要改進(jìn)的服務(wù)作為一個(gè)整體,改進(jìn)其行為和性能,而不是服務(wù)的某個(gè)容器組件或基礎(chǔ)設(shè)施資源”。
隨著容器數(shù)量的迅速增加,容器協(xié)調(diào)的需求也隨之迅速地變得顯而易見。谷歌就是個(gè)極端的例子,每秒要啟動(dòng)7000個(gè)容器,或每周要啟動(dòng)20億個(gè)。這就是對容器集群的需求。
除了其他的要求之外,谷歌構(gòu)建的容器集群還必須能夠做到在保持可用的狀態(tài)下完成更新,可擴(kuò)展并且便于操控和監(jiān)控。通過滿足這些要求,谷歌收益匪淺。首先,可以構(gòu)建有清晰的合約和邊界的微服務(wù)。然后,清晰的邊界讓小型工程團(tuán)隊(duì)能夠保持軟件的可管理和可擴(kuò)展。容器集群具有自愈能力和無摩擦的水平擴(kuò)展能力,并且有著高效的資源利用率。“集群運(yùn)維團(tuán)隊(duì)和應(yīng)用運(yùn)維團(tuán)隊(duì)角色” 的專業(yè)化能力是另一個(gè)隱含的好處。Joe Beda舉例提到,“GMail的運(yùn)維和開發(fā)團(tuán)隊(duì)很少需要與集群運(yùn)維團(tuán)隊(duì)直接對話”。開發(fā)人員可以將注意力集中在構(gòu)建服務(wù)上,而不需要考慮底層的基礎(chǔ)設(shè)施問題。
“優(yōu)秀容器集群的要素”
Joe還分享了“優(yōu)秀的容器集群管理器所需的要素”。包括動(dòng)態(tài)的容器配置,以集合方式思考以及集群內(nèi)的連接。
動(dòng)態(tài)容器配置就是在考慮容器應(yīng)該如何運(yùn)行以和運(yùn)行在何處的公開意向的前提下,找到一個(gè)可以運(yùn)行給定載荷的位置。這是一個(gè)背包問題的實(shí)例。每個(gè)容器都有其自身的限制,如何在有限的可用計(jì)算資源內(nèi)匹配各個(gè)容器呢?在安排給定的載荷時(shí),集群必須要考慮可用容量(如CPU、RAM等),特殊的硬件需求以及實(shí)時(shí)變化的條件(如故障、自動(dòng)擴(kuò)展等)。Kubernetes用Pod解決了這個(gè)問題:
Pod(和一群鯨魚(a pod of whales)或豌豆莢(pea pod)里的含義一樣)由一組相互關(guān)聯(lián)的共享容量的Docker容器構(gòu)成。Pod模型化為容器化環(huán)境下,特定于應(yīng)用程序的一個(gè)“邏輯宿主”。其中可能包含一個(gè)或多個(gè)相互關(guān)聯(lián)并緊密耦合的容器——在前容器(pre-container)世界,他們會(huì)執(zhí)行在同一個(gè)物理或虛擬主機(jī)上。
第二個(gè)要素是提供以集合方式思考的可能性。Kubernetes通過提供標(biāo)簽和復(fù)制控制器使其成為可能。每個(gè)Pod可以有一系列的標(biāo)簽,每個(gè)標(biāo)簽是一個(gè)鍵值對。Pod通過標(biāo)簽分組,例如根據(jù)應(yīng)用層級或地理位置。之后標(biāo)簽的使用可以有多種方式,例如由服務(wù)或復(fù)制控制器使用。復(fù)制控制器,顧名思義,用于保證大量的Pod拷貝能夠一直保持活動(dòng),從而為橫向擴(kuò)展活動(dòng)提供幫助。
Kubernetes標(biāo)簽,來自于文章“是什么造就了容器集群?”
成功的容器集群的第三個(gè)要素是通信。當(dāng)有多個(gè)容器,進(jìn)而有多個(gè)微服務(wù)存在時(shí),通信就成為了一個(gè)關(guān)鍵的組件。為了在無需知道它們各自的容器實(shí)際運(yùn)行位置的情況下,微服務(wù)之間也可以互相通信,好的容器集群應(yīng)該提供一個(gè)命名解析系統(tǒng)。命名解析系統(tǒng)在容器啟動(dòng)或遷移之后能夠立即了解到全部變化是十分重要的。Kubernetes在標(biāo)簽和Watch API模式的幫助下,提供了輕量級的服務(wù)發(fā)現(xiàn)方案。受Google Chubby論文的啟發(fā),該模式提供了一種從服務(wù)傳遞異步事件的方式。Kubernetes團(tuán)隊(duì)意識到并不是所有的客戶端都會(huì)為了使用這個(gè)API而重寫。因此Kubernetes提供服務(wù)代理的概念來處理這類場景。
[服務(wù)代理]是一個(gè)簡單的網(wǎng)絡(luò)負(fù)載均衡器/代理,以單一穩(wěn)定的IP/端口形式暴露在網(wǎng)絡(luò)中,可以幫助完成命名查詢。
簡而言之,谷歌云平臺團(tuán)隊(duì)將容器集群定義為:
一個(gè)動(dòng)態(tài)配置和管理容器的系統(tǒng),以Pod的形式組合在一起,連同所有的相互連接和通信渠道,運(yùn)行在節(jié)點(diǎn)之上。
谷歌向容器化的轉(zhuǎn)移開始于將cgroups(控制群組的簡寫)加入Linux內(nèi)核,以隔離一個(gè)進(jìn)程集合的資源使用。通過簡化容器技術(shù),Docker讓更大范圍的社區(qū)采用了容器技術(shù),從而使這種技術(shù)得以推廣。