摘要：祈使式的腳本很難長期地對系統(tǒng)狀態(tài)進(jìn)行自動維護(hù)。這些事件包括的創(chuàng)建消亡的更新例如標(biāo)簽副本數(shù)量等。每當(dāng)上述事件發(fā)生，這個事件所牽扯到的具體的對象就會被放入這個工作隊列中。

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

“一切皆聲明”的軟件架構(gòu)設(shè)計模式

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

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

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

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

replicas: 5
template:
spec:

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

而對應(yīng)的祈使式腳本則可能需要如下的邏輯：

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

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

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

智能：聲明式配置只需指定用戶想要實現(xiàn)的目標(biāo)（運行 5 個 nginx 實例），而軟件系統(tǒng)會自動識別出達(dá)到目標(biāo)所需的實際操作并執(zhí)行。

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

如數(shù)家珍 Kubernetes 的經(jīng)典控制閉環(huán)

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

創(chuàng)建和銷毀 Pods 的控制閉環(huán)
驅(qū)逐、終止、重調(diào)度 Pods 的控制閉環(huán)
彈性伸縮一個服務(wù)的控制閉環(huán)
將 Pods 調(diào)度到 Nodes 上的控制閉環(huán)
創(chuàng)建、刪除、和重啟 Nodes 的控制閉環(huán)
刪除、重啟容器的控制閉環(huán)
控制資源消耗與分配的控制閉環(huán)

ReplicaSet控制閉環(huán)

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

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

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

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

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

ReplicaSetController 源碼分析

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

ReplicaSetController 的結(jié)構(gòu)體主要包含如下成員：
所有 ReplicaSet 對象的列表
所有 Pods 對象的列表
一個工作隊列用來循環(huán)處理需要更新的 ReplicaSet 對象
控制 ReplicaSet 觸發(fā)行動頻率的參數(shù) burstReplicas

創(chuàng)建一個 ReplicaSetController 由 NewReplicaSetController 函數(shù)完成，其具體的創(chuàng)建過程如下：

ReplicaSetController 工作流程
?

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

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

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

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

不論何種情況，我們可以看到 Kubernetes 都是自動地分別出所需要的操作并自動地進(jìn)行執(zhí)行，體現(xiàn)了自動化的優(yōu)勢。