摘要：祈使式的腳本很難長期地對系統狀態進行自動維護。這些事件包括的創建消亡的更新例如標簽副本數量等。每當上述事件發生，這個事件所牽扯到的具體的對象就會被放入這個工作隊列中。

本期文章來自才云科技（Caicloud）CEO 張鑫的技術原創。
導言：
Kubernetes 是一個龐大的軟件系統，欲從源碼層精通 Kubernetes 的進階學習者往往會經歷 “Kubernetes：從入門到放棄” 的挫敗感。俗話說：擒賊先擒王，與其一開始就掉入 Kubernetes 廣闊的代碼海洋里迷失自己，不如先來了解一下 Kubernetes 軟件架構的核心設計模式與經典架構。其中，我們先從 Kubernetes 的聲明式設計模式與控制閉環講起。

“一切皆聲明”的軟件架構設計模式

Kubernetes 采用了“聲明式”（Declarative）的資源管理模式，該模式對資源的管理流程分為如下幾個明晰的步驟：

聲明（Declare）：用戶通過聲明式的配置文件（例如 YAML 文件）向 Kubernetes 告白自己希望達到的系統狀態（例如：運行擁有 5 個副本的 nginx 服務）。
觀測（Observe）：Kubernetes 會觀測到新的用戶聲明，并自動分析出需要執行的操作以達到用戶聲明的系統狀態（例如在集群中選取5個合適的節點，并在這 5 個節點上下載合適的 nginx 鏡像并啟動容器，以及配置相應的負載均衡策略等）。
行動（React）：Kubernetes 的控制組件負責具體執行這些指令，使得用戶聲明的系統狀態得以實現；在此過程中不需要任何人工的參與。
持續觀測與收斂（Feedback and Control Loop）：Kubernetes 的設計者深諳硬件故障、應用異常是大規模分布式系統的常態；因此，在用戶聲明的狀態通過上述步驟得以實現后，Kubernetes 仍會持續地、孜孜不倦地觀測系統的實時狀態。當遇到系統故障、容器退出等異常導致系統的當前狀態與最初的用戶初心不符時，Kubernetes 仍可以進行 24 x 7 的不間斷修復。例如，聲明的 5 個 nginx 實例如果在運行中有 2 個實例非正常退出，Kubernetes會觀測到此狀態并且自動選取另外合適的節點來運行新的 2 個 nginx 實例，保證總的 nginx 實例個數為 5。在此過程中，傳統需要運維人員人肉輪崗完成的工作，Kubernetes 全部以自動化來代替。

上述聲明式（Declarative）管理方法和 Declare – Observe – React 的控制閉環（Control Loop）體現了谷歌內部軟件系統的實踐精華，同時也是我們值得學習借鑒的一個軟件架構設計模式。與聲明式（Declarative）相對應的是祈使式（Imperative）的設計模式：在 Imperative 設計模式中，用戶需要指明一步一步的具體操作流程和指令（例如 Shell 腳本），而并非像聲明式模式一樣直接指明最終的想要達到的狀態。

具體來說，以運行 5 個 nginx 的實例為例，聲明式的語言配置片段大致如下：

replicas: 5
template:
spec:

containers:
- name: my-nginx
  image: caicloud/nginx:v1

而對應的祈使式腳本則可能需要如下的邏輯：

選擇合適的五臺機器作為運行的宿主機
分別獲取這些機器的 IP 地址，并進行 ssh 登錄
在 ssh 登陸后，判斷 docker 是否已經在宿主機上運行，如果沒有運行則要啟動 docker daemon
分別運行 docker run 命令來啟動 nginx 實例
判斷 docker run 是否成功，應用是否被正常啟動

Declare – Observe - React 的軟件設計模式有如下的好處：

簡單：聲明式的配置文件更貼近“人類語言”（例如 YAML），從上述例子中可以看出，相比于傳統的 imperative 設計模式，聲明式配置更加可讀和易于維護。

智能：聲明式配置只需指定用戶想要實現的目標（運行 5 個 nginx 實例），而軟件系統會自動識別出達到目標所需的實際操作并執行。

可靠：“Failure is the norm”，故障是軟件系統的常態；當系統或軟件在執行過程中遇到異常和故障時，祈使式的腳本往往就會異常退出，并需要人工干預進行校正。此外，即使系統在一開始被正確的配置好（例如 5 個 nginx 已經成功運行），在系統的運行過程中隨著時間的推移故障也隨時可能發生（例如機器故障導致 1 個 nginx 實例死亡）。祈使式的腳本很難長期地對系統狀態進行自動維護。然而，在 Declare-Observe-React 模式中，軟件系統會時刻“Observe”當前系統的實際狀態（actual state），并與用戶的配置“初心”（declared state）作對比；當發現偏差時則會智能地識別出需要進行的校正，并進行執行（react），例如重新選擇一個健康機器來運行一個新的 nginx 以替代之前的“先烈”。

如數家珍 Kubernetes 的經典控制閉環

俗話說，“說的總比做的容易”；英文亦有云：“Easier Said than Done”。聲明僅僅是聲明，而如何從聲明智能地轉化為一系列可執行操作，并持續地進行觀測、校正，則是由 Kubernetes 的控制閉環來完成。這些經典的閉環包括：

創建和銷毀 Pods 的控制閉環
驅逐、終止、重調度 Pods 的控制閉環
彈性伸縮一個服務的控制閉環
將 Pods 調度到 Nodes 上的控制閉環
創建、刪除、和重啟 Nodes 的控制閉環
刪除、重啟容器的控制閉環
控制資源消耗與分配的控制閉環

ReplicaSet控制閉環

我們先來研究創建和銷毀 Pods 的控制閉環。Kubernetes 早期版本的用戶會熟悉“Replication Controller”并容易與 ReplicaSet 造成混淆：兩者都是用來根據用戶的意愿（通過用戶聲明的配置文件）來保證某個應用（容器鏡像）運行指定數量的副本（例如保證 5 個 nginx 實例時刻運行在合適的機器節點上）。

而兩者的區別其實非常簡單：ReplicaSet 是新一代的 Replication Controller，Replication Controller 則應該退出歷史舞臺。原因是，ReplicaSet 能支持更靈活的標簽匹配規則，而 Replication Controller 只能支持標簽的 exact match 。因此，一個 Replication Controller 只能根據嚴格的字符串匹配來選擇“身背”某個標簽的 Pods 進行管理（例如管理背負著 app = nginx 的 Pods 進行控制）。

相比之下，長江后浪推前浪，新一代的 ReplicaSet 則可以利用數學中的集合論和操作來支持更靈活的匹配規則，例如 tier notin (frontend, backend)（具體可以參考 Kubernetes 官方文檔：https://kubernetes.io/docs/co...）。

然而，在 Kubernetes 的實際使用中，ReplicaSet 也屬于底層概念，由 Deployment 來管理；因此在實操層面，用戶在絕大多數情況下應該與 Deployment 打交道，通過創建 Deployment 來創建應用，而不應該直接創建 ReplicaSet；Deployment 會自動地創建并管理對應的底層 ReplicaSet，從而最終控制 Pods 的副本數量。

雖然如此，Pods 的生命周期和副本數量都是由 ReplicaSet 來具體實現的；因此下面我們剖析一下 ReplicaSetController 的代碼，來理解前述的 Kubernetes 的控制閉環是如何落實到代碼層面的。

ReplicaSetController 源碼分析

ReplicaSet 的控制邏輯主要位于 ReplicaSetController，其源碼位于：
https://github.com/kubernetes...

ReplicaSetController 的結構體主要包含如下成員：
所有 ReplicaSet 對象的列表
所有 Pods 對象的列表
一個工作隊列用來循環處理需要更新的 ReplicaSet 對象
控制 ReplicaSet 觸發行動頻率的參數 burstReplicas

創建一個 ReplicaSetController 由 NewReplicaSetController 函數完成，其具體的創建過程如下：

ReplicaSetController 工作流程
?

下面，我們按照 Declare – Observe - React 的控制流程來梳理 ReplicaSetController 的工作流程。

Declare
Kubernetes 將用戶在 YAML 配置中指定的應用副本數量等配置轉化為一個 extensions.ReplicaSet 結構體（其源代碼文件位于：Kubernetes/pkg/apis/extensions/types.go），主要包含 ReplicaSetSpec 和 ReplicaSetStatus 兩個成員結構體。其中的 ReplicaSetSpec 結構體中記錄了用戶 Declare 的配置信息， 例如用戶指定的副本數量（Replicas）、標簽選擇器（Selector）、用以創建應用副本所需的 Pod 模版（Template）等信息。

Observe
ReplicaSetController 通過多個 worker 線程來進行持續的 Pod 狀態觀測和校正。ReplicaSetController 維護一個工作隊列（work queue），工作隊列中的元素是需要被觀測、進而進行處理的一個個 ReplicaSet 對象。而什么樣的 ReplicaSet 會被放到這個工作隊列中呢？原來 ReplicaSetController 采用了事件驅動的設計模型（Event Driven），在 ReplicaSetController 被創建的時候就注冊了一系列的事件 callback 函數。這些事件包括 Pod 的創建、消亡、ReplicaSet 的更新（例如標簽、副本數量）等。每當上述事件發生，這個事件所牽扯到的具體的 ReplicaSet 對象就會被放入這個工作隊列中。因此，總結來說，Kubernetes 采用了 Event Driven 的設計模型實現了不間斷的 Observe 操作，并通過工作隊列實現了多線程不間斷的處理邏輯，如下圖所示：

如上圖所示：
ReplicaSetController 以 Run 函數為程序入口，啟動了多個 go routine，而每個go routing 中通過 worker 函數不間斷地通過 processNextWorkItem 函數來從工作隊列中獲取需要被觀測的 ReplicaSet 進行檢查。
檢查通過 syncReplicaSet 函數進行，其中包括判斷該 ReplicaSet 是否需要被同步，如果答案是肯定的，則進一步通過 manageReplicas 來完成同步或校驗。而實際觀測到的 ReplicaSet 的狀態也會被更新到 ReplicaSet 中的 ReplicaSetStatus 成員結構體中。
React
React 的邏輯盡在 manageReplicas 函數中，該函數首先判斷用戶指定的副本數量（ReplicaSet.Spec.Replicas）是否與當前的實際 Pod 副本數量保持一致，如果不一致：
若實際的 Pod 副本數量少于指定值，則通過 PodControlInterface 進行 Pod 的創建
若實際的 Pod 副本數量大于實際值，則通過 PodControlInterface 進行 Pod 的刪除

不論何種情況，我們可以看到 Kubernetes 都是自動地分別出所需要的操作并自動地進行執行，體現了自動化的優勢。