容器編排是指用于自動化，管理和調(diào)度由各個容器定義的工作負(fù)載的工具和平臺。在容器編排領(lǐng)域有很多參與者，開源工具和專有工具，如Hashicorp的Nomad，Apache Mesos，AWS的ECS等等，當(dāng)然還有谷歌的Borg項目(Kubernetes就是從這個項目演變而來的)。每種技術(shù)都有其優(yōu)缺點，但是K​​ubernetes的日益普及和社區(qū)的強大支持已經(jīng)清楚地表明，Kubernetes目前是容器編排當(dāng)之無愧的領(lǐng)導(dǎo)者了。

在使用開源軟件時，Kubernetes具有明顯的優(yōu)勢。作為一個開源平臺，它可以在本地部署，并且在Kubernetes之上構(gòu)建其他開源軟件也很有意義。此外，作為最為活躍的開源生態(tài)之一，它有超過40000名的貢獻(xiàn)者，并且由于許多開發(fā)人員已經(jīng)熟悉Kubernetes，因此用戶可以更輕松地集成基于Kubernetes的開源解決方案。

將Kubernetes分解為構(gòu)建塊

分解Kubernetes的最簡單方法是查看容器編排的核心概念。有一些容器，用作基礎(chǔ)工作模塊，然后將各個組件構(gòu)建在彼此之上，以將系統(tǒng)捆綁在一起。

組件有兩種核心類型：

• 工作負(fù)載管理器：一種托管和運行容器的方法
• 集群管理器：代表集群決策的全局方法

在Kubernetes術(shù)語中，這些角色由工作節(jié)點和管理工作的控制平面(即Kubernetes組件)完成。

管理工作負(fù)載

Kubernetes工作節(jié)點具有嵌套的組件層。在基礎(chǔ)層是容器本身。

集群及其組件

從技術(shù)上講，容器在容器中運行，容器是Kubernetes集群中的原子對象類型。它們之間的關(guān)系如下：

• Pod：Pod定義了應(yīng)用程序的邏輯單元;它可以包含一個或多個容器，并且每個Pod都部署到一個節(jié)點上。
• 節(jié)點(Node)：這是在集群中充當(dāng)工作負(fù)載的虛擬機;Pod在節(jié)點上運行。
• 集群：由工作節(jié)點組成，由控制平面管理。

每個節(jié)點都運行一個稱為kublet的代理，該代理用于在容器中運行容器，而一個kube-proxy用于管理網(wǎng)絡(luò)規(guī)則。

管理集群

工作節(jié)點管理容器，Kubernetes控制平面對集群進(jìn)行全局決策。

控制平面及其組件

控制平面包含幾個基本組件：

• 內(nèi)存存儲(etcd)：這是所有集群數(shù)據(jù)的后端存儲。雖然可以使用其他后備存儲etcd運行Kubernetes集群，但默認(rèn)情況下是開源分布式鍵值存儲。
• 調(diào)度程序(kube-scheduler)：調(diào)度程序負(fù)責(zé)將新創(chuàng)建的Pod分配給適當(dāng)?shù)墓?jié)點。
• API前端(kube-apiserver)：這是開發(fā)人員可以與Kubernetes進(jìn)行交互的網(wǎng)關(guān)，以部署服務(wù)，獲取指標(biāo)，檢查日志等。

控制器管理器(kube-controller-manager)：監(jiān)控集群并進(jìn)行必要的更改，以使集群保持所需的狀態(tài)，例如擴展節(jié)點，為每個復(fù)制控制器維護(hù)正確的Pod數(shù)量以及創(chuàng)建新的命名空間。

控制平面做出決策以確保集群正常運行，并抽象化這些決策，讓開發(fā)者不必?fù)?dān)心它們。它的功能非常復(fù)雜，系統(tǒng)的用戶需要了解控制平面的邏輯約束，而又不會陷入細(xì)節(jié)上。

使用控制器和模板

集群的組件決定了集群如何進(jìn)行自我管理，但是開發(fā)者管理員如何告訴集群來運行軟件?這是控制器和模板發(fā)揮作用的地方。

控制器編排Pod，而Kubernetes則針對不同的用例使用不同類型的控制器。但是關(guān)鍵的是Jobs(用于一次性完成的作業(yè))和ReplicaSets(用于運行一組指定的提供服務(wù)的相同容器)。

像Kubernetes中的其他所有內(nèi)容一樣，這些概念構(gòu)成了更復(fù)雜的系統(tǒng)的構(gòu)建塊，這些系統(tǒng)允許開發(fā)者運行彈性服務(wù)。建議不要直接使用ReplicaSets，而應(yīng)該使用Deployments。部署代表用戶管理ReplicaSet，并允許滾動更新。Kubernetes部署可確保僅在更新某些Pod時將它們關(guān)閉，從而實現(xiàn)零停機時間部署。同樣，CronJobs管理作業(yè)，并用于運行計劃的和重復(fù)的流程。Kubernetes的許多層都允許更好的自定義，但是CronJobs和Deployments足以滿足大多數(shù)用例。

一旦知道選擇哪個控制器來運行服務(wù)，就需要使用模板對其進(jìn)行配置。

模板剖析

Kubernetes模板是一個YAML文件，用于定義容器運行所用的參數(shù)。就像任何形式的代碼配置一樣，它具有自己的特定格式和要求，需要學(xué)習(xí)很多東西。但慶幸的是，需要提供的信息與針對任何容器編排運行代碼相同：

• 告訴它如何命名應(yīng)用程序
• 告訴它在哪里尋找容器的鏡像(通常稱為容器注冊表)
• 告訴它要運行多少個實例(在上面的術(shù)語中，為ReplicaSets的數(shù)量)

配置的靈活性是Kubernetes的眾多優(yōu)勢之一。使用不同的資源和模板，還可以提供有關(guān)以下內(nèi)容的集群信息：

• 環(huán)境變量
• 密碼位置
• 容器應(yīng)掛載以供使用的任何數(shù)據(jù)卷
• 每個容器或Pod允許使用多少CPU和內(nèi)存
• 容器應(yīng)運行的特定命令
• 而這樣的例子還有很多

匯集全部

組合來自不同資源的模板，使用戶可以互操作Kubernetes中的組件，并根據(jù)自己的需求自定義它們。

在更大的生態(tài)系統(tǒng)中，開發(fā)者可以通過結(jié)合使用ConfigMap和Secrets的Jobs，services和Deployments來組合成一個應(yīng)用程序(在部署過程中)，所有這些操作都必須經(jīng)過精心策劃。

這些編排步驟的管理可以手動完成，也可以使用常見的軟件包管理選項之一來完成。雖然絕對有可能根據(jù)Kubernetes API進(jìn)行自己的部署，但是打包配置通常是一個好主意(特別是如果要交付的開源軟件可能是由不在團(tuán)隊中的人直接部署和管理的)。

Kubernetes首選的軟件包管理器是Helm。使用Helm并不需要花很多時間，它使你可以打包自己的軟件，以便在Kubernetes集群上輕松安裝。

總結(jié)

位于容器上面的許多層和擴展可能會使容器協(xié)編排難以理解。但是，一旦分解了各個部分并查看它們之間的相互作用，它實際上就非常清晰了。