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

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

將Kubernetes分解為構建塊

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

組件有兩種核心類型：

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

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

管理工作負載

Kubernetes工作節點具有嵌套的組件層。在基礎層是容器本身。

集群及其組件

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

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

每個節點都運行一個稱為kublet的代理，該代理用于在容器中運行容器，而一個kube-proxy用于管理網絡規則。

管理集群

工作節點管理容器，Kubernetes控制平面對集群進行全局決策。

控制平面及其組件

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

• 內存存儲(etcd)：這是所有集群數據的后端存儲。雖然可以使用其他后備存儲etcd運行Kubernetes集群，但默認情況下是開源分布式鍵值存儲。
• 調度程序(kube-scheduler)：調度程序負責將新創建的Pod分配給適當的節點。
• API前端(kube-apiserver)：這是開發人員可以與Kubernetes進行交互的網關，以部署服務，獲取指標，檢查日志等。

控制器管理器(kube-controller-manager)：監控集群并進行必要的更改，以使集群保持所需的狀態，例如擴展節點，為每個復制控制器維護正確的Pod數量以及創建新的命名空間。

控制平面做出決策以確保集群正常運行，并抽象化這些決策，讓開發者不必擔心它們。它的功能非常復雜，系統的用戶需要了解控制平面的邏輯約束，而又不會陷入細節上。

使用控制器和模板

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

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

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

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

模板剖析

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

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

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

• 環境變量
• 密碼位置
• 容器應掛載以供使用的任何數據卷
• 每個容器或Pod允許使用多少CPU和內存
• 容器應運行的特定命令
• 而這樣的例子還有很多

匯集全部

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

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

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

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

總結

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