通過借鑒他們在這一技術(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ù)得以推廣。