容器編排是指用于自動化，管理和調(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)行自己的部署，但是打包配置通常是一個好主意(特別是如果要交付的開源軟件可能是由不在團隊中的人直接部署和管理的)。

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

總結(jié)

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