目錄
從 Kubernetes 資源控制到開放應用模型
我是一堆 Kubernetes 控制器。
你可能會疑惑爲什麼是一堆，因爲我不是一個人，我只是衆多控制器中的一員，你也可以把我看成是衆多控制器的集合。我的職責就是監控集羣內資源的實際狀態，一旦發現其與期望的狀態不相符，就採取行動使其符合期望狀態。
想當初，Kubernetes 老大哥創造我時，只是打算讓我用控制循環簡單維護下資源的狀態。但我後來的發展，遠遠超出了他的想象。
1. 控制循環
所謂控制循環就是一個用來調節系統狀態的週期性操作，在 Kubernetes 中也叫調諧循環（Reconcile Loop）。我的手下控制着很多種不同類型的資源，比如 Pod，Deployment，Service 等等。就拿 Deployment 來說吧，我的控制循環主要分爲三步：
- 從
API Server中獲取到所有屬於該 Deployment 的 Pod，然後統計一下它們的數量，即它們的實際狀態。- 檢查 Deployment 的
Replicas字段，看看期望狀態是多少個 Pod。- 將這兩個狀態做比較，如果期望狀態的 Pod 數量比實際狀態多，就創建新 Pod，多幾個就創建幾個新的；如果期望狀態的 Pod 數量比實際狀態少，就刪除舊 Pod，少幾個就刪除幾個舊的。
然而好景不長，我收到了 Kubernetes 掌門人（看大門的） API Server 的抱怨：“你訪問我的次數太頻繁了，非常消耗我的資源，我連上廁所的時間都沒有了！”
我仔細一想，當前的控制循環模式確實有這個缺陷——訪問 API Server 的次數太頻繁了，容易被老大反感。
所以我決定，找一個小弟。
2. Informer
這次我招的小弟叫 Informer，它分擔一部分我的任務，具體的做法是這樣的：由 Informer代替我去訪問 API Server，而我不管是查狀態還是對資源進行伸縮都和 Informer 進行交接。而且 Informer 不需要每次都去訪問 API Server，它只要在初始化的時候通過 LIST API 獲取所有資源的最新狀態，然後再通過 WATCH API 去監聽這些資源狀態的變化，整個過程被稱作 ListAndWatch。
而 Informer 也不傻，它也有一個助手叫 Reflector，上面所說的 ListAndWatch 事實上是由 Reflector 一手操辦的。
這一次，API Server 的壓力大大減輕了，因爲 Reflector 大部分時間都在 WATCH，並沒有通過 LIST 獲取所有狀態，這使 API Server 的壓力大大減少。我想這次掌門人應該不會再批評我了吧。
然而沒過幾天，掌門人又找我談話了：“你的手下每次來 WATCH 我，都要 WATCH 所有兄弟的狀態，依然很消耗我的資源啊！我就納悶了，你一次搞這麼多兄弟，你虎啊？”
我一想有道理啊，沒必要每次都 WATCH 所有兄弟的狀態，於是告訴 Informer：“以後再去 API Server 那裏 WATCH 狀態的時候，只查 WATCH 特定資源的狀態，不要一股腦兒全 WATCH。“
Informer 再把這個決策告訴 Reflector，事情就這麼愉快地決定了。
本以爲這次我會得到掌門人的誇獎，可沒過幾天安穩日子，它又來找我訴苦了：“兄弟，雖然你減輕了我的精神壓力，但我的財力有限啊，如果每個控制器都招一個小弟，那我得多發多少人的工資啊，你想想辦法。”
3. SharedInformer
經過和其他控制器的討論，我們決定這麼做：所有控制器聯合起來作爲一個整體來分配 Informer，針對每個（受多個控制器管理的）資源招一個 Informer 小弟，我們稱之爲 SharedInformer。你們可以理解爲共享 Informer，因爲有很多資源是受多個控制器管理的，比如 Pod 同時受 Deployment 和 StatefulSet 管理。這樣當多個控制器同時想查 Pod 的狀態時，只需要訪問一個 Informer 就行了。
但這又引來了新的問題，SharedInformer 無法同時給多個控制器提供信息，這就需要每個控制器自己排隊和重試。
爲了配合控制器更好地實現排隊和重試，SharedInformer 搞了一個 Delta FIFO Queue（增量先進先出隊列），每當資源被修改時，它的助手 Reflector 就會收到事件通知，並將對應的事件放入 Delta FIFO Queue 中。與此同時，SharedInformer 會不斷從 Delta FIFO Queue 中讀取事件，然後更新本地緩存的狀態。
這還不行，SharedInformer 除了更新本地緩存之外，還要想辦法將數據同步給各個控制器，爲了解決這個問題，它又搞了個工作隊列（Workqueue），一旦有資源被添加、修改或刪除，就會將相應的事件加入到工作隊列中。所有的控制器排隊進行讀取，一旦某個控制器發現這個事件與自己相關，就執行相應的操作。如果操作失敗，就將該事件放回隊列，等下次排到自己再試一次。如果操作成功，就將該事件從隊列中刪除。
現在這個工作模式得到了大家的一致好評。雖然單個 SharedInformer 的工作量增加了，但 Informer 的數量大大減少了，老大可以把省下來的資金拿出一小部分給 SharedInformer 漲工資啊，這樣大家都很開心。
4. CRD
全民 Kubernetes 時代到了。
隨着容器及其編排技術的普及，使用 Kubernetes 的用戶大量增長，用戶已經不滿足 Kubernetes 自帶的那些資源（Pod，Node，Service）了，大家都希望能根據具體的業務創建特定的資源，並且對這些資源的狀態維護還要遵循上面所說的那一套控制循環機制。
幸好最近掌門人做了一次升級，新增了一個插件叫 CRD（Custom Resource Definition），創建一個全新的資源實例，只需要經過以下兩步：
- 創建一個 CRD 資源（沒錯，CRD 也是一種資源類型），其中定義”自定義資源“的 API 組、API 版本和資源類型。這樣就會向 API Server 註冊該資源類型的 API。
- 指定上面定義的 API 組 和 API 版本，創建自定義資源。
當然，中間還要加入一些代碼讓 Kubernetes 認識自定義資源的各種參數。
到這一步就基本上完成了自定義資源的創建，但 Kubernetes 並不知道該資源所對應的業務邏輯，比如你的自定義資源是宿主機，那麼對應的業務邏輯就是創建一臺真正的宿主機出來。那麼怎樣實現它的業務邏輯呢？
5. 自定義控制器
Controller Manager 見多識廣，說：”這裏的每個控制器都是我的一部分，當初創造你們是因爲你們都屬於通用的控制器，大家都能用得上。而自定義資源需要根據具體的業務來實現，我們不可能知道每個用戶的具體業務是啥，自己一拍腦袋想出來的自定義資源，用戶也不一定用得上。我們可以讓用戶自己編寫自定義控制器，你們把之前使用的控制循環和 Informer 這些編碼模式總結一下，然後提供給用戶，讓他們按照同樣的方法編寫自己的控制器。“
Deployment 控制器一驚，要把自己的祕密告訴別人？那別人把自己取代了咋辦？趕忙問道：”那將來我豈不是很危險，沒有存在的餘地了？“
Controller Manager 趕忙解釋道：”不用擔心，雖然用戶可以編寫自定義控制器，但無論他們玩出什麼花樣，只要他們的業務跑在 Kubernetes 平臺上，就免不了要跑容器，最後還是會來求你們幫忙的，你要知道，控制器是可以層層遞進的，他們只不過是在你外面套了一層，最後還是要回到你這裏，請求你幫忙控制 Pod。“
這下大家都不慌了，決定就把自定義控制器這件事情交給用戶自己去處理，將選擇權留給用戶。
6. Operator
用戶自從獲得了編寫自定義控制器的權力之後，非常開心，有的用戶（CoreOS）爲了方便大家控制有狀態應用，開發出了一種特定的控制器模型叫 Operator，並開始在社區內推廣，得到了大家的一致好評。不可否認，Operator 這種模式是很聰明的，它把需要特定領域知識的應用單獨寫一個 Operator 控制器，將這種應用特定的操作知識編寫到軟件中，使其可以利用 Kubernetes 強大的抽象能力，達到正確運行和管理應用的目的。
以 ETCD Operator 爲例，假如你想手動擴展一個 ETCD 集羣，一般的做法是：
- 使用 ETCD 管理工具添加一個新成員。
- 爲這個成員所在的節點生成對應的啓動參數，並啓動它。
而 ETCD Operator 將這些特定於 etcd 的操作手法編寫到了它的控制循環中，你只需要通過修改自定義資源聲明集羣期望的成員數量，剩下的事情交給 Operator 就好了。
本以爲這是一個皆大歡喜的方案，但沒過多久，就有開發 Operator 的小哥來抱怨了：”我們有很多開發的小夥伴都是不懂運維那一套的，什麼高可用、容災根本不懂啊，現在讓我們將運維的操作知識編寫到軟件中，臣妾做不到啊。。“
這確實是個問題，這樣一來就把開發和運維的工作都塞到了開發手裏，既懂開發又懂運維的可不多啊，爲了照顧大家，還得繼續想辦法把開發和運維的工作拆分開來。
7. OAM
這時候阿里和微軟發力了，他們聯合發佈了一個開放應用模型，叫 Open Application Model （OAM）。這個模型就是爲了解決上面提到的問題，將開發和運維的職責解耦，不同的角色履行不同的職責，並形成一個統一的規範，如下圖所示：
這個規範告訴我們：
- 開發人員負責描述組件的功能，如何配置組件，以及運行需要多少資源
- 運維人員負責將相關組件組合成一個應用，並配置運行時參數和運維支撐能力，比如是否需要監控，是否需要彈性伸縮。
- 基礎設施工程師負責建立和維護應用的運行時環境（如底層系統）。
其中每一個團隊負責的事情都用對應的 CRD 來配置。
這樣一來，開發和運維人員的職責就被區分開來了，簡化了應用的組合和運維。它將應用的配置和運維特徵（如自動伸縮、流量監控）進行解耦，然後通過建模構成一個整體，避免了 Operator 這種模型帶來的大量冗餘。
自從用上了這個模型之後，運維和開發小哥表示現在他們的關係很融洽，沒事還能一起出去喝兩杯。
Kubernetes 控制器的工作原理解讀
Kubernetes 中運行了一系列控制器來確保集羣的當前狀態與期望狀態保持一致，它們就是 Kubernetes 的大腦。例如，ReplicaSet 控制器負責維護集羣中運行的 Pod 數量；Node 控制器負責監控節點的狀態，並在節點出現故障時及時做出響應。總而言之，在 Kubernetes 中，每個控制器只負責某種類型的特定資源。對於集羣管理員來說，瞭解每個控制器的角色分工至關重要，如有必要，你還需要深入瞭解控制器的工作原理。
本文我將會帶你深入瞭解 Kubernetes 控制器的內部結構、基本組件以及它的工作原理。本文使用的所有代碼都是從 Kubernetes 控制器的當前實現代碼中提取的，基於 Go 語言的 client-go 庫。
1. 控制器的模型
Kubernetes 官方文檔給出了控制器最完美的解釋：
In applications of robotics and automation, a control loop is a non-terminating loop that regulates the state of the system. In Kubernetes, a controller is a control loop that watches the shared state of the cluster through the API server and makes changes attempting to move the current state towards the desired state. Examples of controllers that ship with Kubernetes today are the replication controller, endpoints controller, namespace controller, and serviceaccounts controller.
翻譯：
在機器人設計和自動化的應用中，控制循環是一個用來調節系統狀態的非終止循環。而在 Kubernetes 中，控制器就是前面提到的控制循環，它通過 API Server 監控整個集羣的狀態，並確保集羣處於預期的工作狀態。Kubernetes 自帶的控制器有 ReplicaSet 控制器，Endpoint 控制器，Namespace 控制器和 Service Account 控制器等。
Kubernetes 控制器會監視資源的創建/更新/刪除事件，並觸發 Reconcile 函數作爲響應。整個調整過程被稱作 “Reconcile Loop”（調諧循環）或者 “Sync Loop”（同步循環）。Reconcile是一個使用 object（Resource 的實例）的命名空間和 object 名來調用的函數，使 object 的實際狀態與 object 的 Spec 中定義的狀態保持一致。調用完成後，Reconcile 會將 object 的狀態更新爲當前實際狀態。
什麼時候纔會觸發 Reconcile 函數呢？以 ReplicaSet 控制器爲例，當收到了一個關於 ReplicaSet 的事件或者關於 ReplicaSet 創建 Pod 的事件時，就會觸發 Reconcile 函數。
爲了降低複雜性，Kubernetes 將所有的控制器都打包到 kube-controller-manager 這個守護進程中。下面是控制器最簡單的實現方式：
for {
desired := getDesiredState()
current := getCurrentState()
makeChanges(desired, current)
}
2. 水平觸發的 API
Kubernetes 的 API 和控制器都是基於水平觸發的，可以促進系統的自我修復和週期協調。水平觸發這個概念來自硬件的中斷，中斷可以是水平觸發，也可以是邊緣觸發。
- 水平觸發 : 系統僅依賴於當前狀態。即使系統錯過了某個事件（可能因爲故障掛掉了），當它恢復時，依然可以通過查看信號的當前狀態來做出正確的響應。
- 邊緣觸發 : 系統不僅依賴於當前狀態，還依賴於過去的狀態。如果系統錯過了某個事件（“邊緣”），則必須重新查看該事件才能恢復系統。
Kubernetes 水平觸發的 API 實現方式是：監視系統的實際狀態，並與對象的 Spec 中定義的期望狀態進行對比，然後再調用 Reconcile 函數來調整實際狀態，使之與期望狀態相匹配。
注意
水平觸發的 API 也叫聲明式 API。
水平觸發的 API 有以下幾個特點：
Reconcile會跳過中間過程在Spec中聲明的值，直接作用於當前Spec中聲明的值。- 在觸發
Reconcile之前，控制器會併發處理多個事件，而不是串行處理每個事件。
舉兩個例子：
例 1：併發處理多個事件
用戶創建了 1000 個副本數的 ReplicaSet，然後 ReplicaSet 控制器會創建 1000 個 Pod，並維護 ReplicaSet 的 Status 字段。在水平觸發系統中，控制器會在觸發 Reconcile 之前併發更新所有 Pod（Reconcile 函數僅接收對象的 Namespace 和 Name 作爲參數），只需要更新 Status 字段 1 次。而在邊緣觸發系統中，控制器會串行響應每個 Pod 事件，這樣就會更新 Status 字段 1000 次。
例 2：跳過中間狀態
用戶修改了某個 Deployment 的鏡像，然後進行回滾。在回滾過程中發現容器陷入 crash 循環，需要增加內存限制。然後用戶更新了 Deployment 的內容，調整內存限制，重新開始回滾。在水平觸發系統中，控制器會立即停止上一次回滾動作，開始根據最新值進行回滾。而在邊緣觸發系統中，控制器必須等上一次回滾操作完成才能進行下一次回滾。
3. 控制器的內部結構
每個控制器內部都有兩個核心組件：Informer/SharedInformer 和 Workqueue。其中 Informer/SharedInformer 負責 watch Kubernetes 資源對象的狀態變化，然後將相關事件（evenets）發送到 Workqueue 中，最後再由控制器的 worker 從 Workqueue 中取出事件交給控制器處理程序進行處理。
注意
事件 = 動作（create, update 或 delete） + 資源的 key（以 namespace/name 的形式表示）
Informer
控制器的主要作用是 watch 資源對象的當前狀態和期望狀態，然後發送指令來調整當前狀態，使之更接近期望狀態。爲了獲得資源對象當前狀態的詳細信息，控制器需要向 API Server 發送請求。
但頻繁地調用 API Server 非常消耗集羣資源，因此爲了能夠多次 get 和 list 對象，Kubernetes 開發人員最終決定使用 client-go 庫提供的緩存機制。控制器並不需要頻繁調用 API Server，只有當資源對象被創建，修改或刪除時，才需要獲取相關事件。client-go 庫提供了 Listwatcher 接口用來獲得某種資源的全部 Object，緩存在內存中；然後，調用 Watch API 去 watch 這種資源，去維護這份緩存；最後就不再調用 Kubernetes 的任何 API：
lw := cache.NewListWatchFromClient(
client,
&v1.Pod{},
api.NamespaceAll,
fieldSelector)
上面的這些所有工作都是在 Informer 中完成的，Informer 的數據結構如下所示：
store, controller := cache.NewInformer {
&cache.ListWatch{},
&v1.Pod{},
resyncPeriod,
cache.ResourceEventHandlerFuncs{},
儘管 Informer 還沒有在 Kubernetes 的代碼中被廣泛使用（目前主要使用 SharedInformer，下文我會詳述），但如果你想編寫一個自定義的控制器，它仍然是一個必不可少的概念。
注意
你可以把 Informer 理解爲 API Server 與控制器之間的事件代理，把 Workqueue 理解爲存儲事件的數據結構。
下面是用於構造 Informer 的三種模式：
ListWatcher
ListWatcher 是對某個特定命名空間中某個特定資源的 list 和 watch 函數的集合。這樣做有助於控制器只專注於某種特定資源。fieldSelector 是一種過濾器，它用來縮小資源搜索的範圍，讓控制器只檢索匹配特定字段的資源。Listwatcher 的數據結構如下所示：
cache.ListWatch {
listFunc := func(options metav1.ListOptions) (runtime.Object, error) {
return client.Get().
Namespace(namespace).
Resource(resource).
VersionedParams(&options, metav1.ParameterCodec).
FieldsSelectorParam(fieldSelector).
Do().
Get()
}
watchFunc := func(options metav1.ListOptions) (watch.Interface, error) {
options.Watch = true
return client.Get().
Namespace(namespace).
Resource(resource).
VersionedParams(&options, metav1.ParameterCodec).
FieldsSelectorParam(fieldSelector).
Watch()
}
}
Resource Event Handler
Resource Event Handler 用來處理相關資源發生變化的事件：
type ResourceEventHandlerFuncs struct {
AddFunc func(obj interface{})
UpdateFunc func(oldObj, newObj interface{})
DeleteFunc func(obj interface{})
}
- AddFunc : 當資源創建時被調用
- UpdateFunc : 當已經存在的資源被修改時就會調用
UpdateFunc。oldObj表示資源的最近一次已知狀態。如果 Informer 向 API Server 重新同步，則不管資源有沒有發生更改，都會調用UpdateFunc。 - DeleteFunc : 當已經存在的資源被刪除時就會調用
DeleteFunc。該函數會獲取資源的最近一次已知狀態，如果無法獲取，就會得到一個類型爲DeletedFinalStateUnknown的對象。
ResyncPeriod
ResyncPeriod 用來設置控制器遍歷緩存中的資源以及執行 UpdateFunc 的頻率。這樣做可以週期性地驗證資源的當前狀態是否與期望狀態匹配。
如果控制器錯過了 update 操作或者上一次操作失敗了，ResyncPeriod 將會起到很大的彌補作用。如果你想編寫自定義控制器，不要把週期設置太短，否則系統負載會非常高。
SharedInformer
通過上文我們已經瞭解到，Informer 會將資源緩存在本地以供自己後續使用。但 Kubernetes 中運行了很多控制器，有很多資源需要管理，難免會出現以下這種重疊的情況：一個資源受到多個控制器管理。
爲了應對這種場景，可以通過 SharedInformer 來創建一份供多個控制器共享的緩存。這樣就不需要再重複緩存資源，也減少了系統的內存開銷。使用了 SharedInformer 之後，不管有多少個控制器同時讀取事件，SharedInformer 只會調用一個 Watch API 來 watch 上游的 API Server，大大降低了 API Server 的負載。實際上 kube-controller-manager 就是這麼工作的。
SharedInformer 提供 hooks 來接收添加、更新或刪除某個資源的事件通知。還提供了相關函數用於訪問共享緩存並確定何時啓用緩存，這樣可以減少與 API Server 的連接次數，降低 API Server 的重複序列化成本和控制器的重複反序列化成本。
lw := cache.NewListWatchFromClient(…)
sharedInformer := cache.NewSharedInformer(lw, &api.Pod{}, resyncPeriod)
Workqueue
由於 SharedInformer 提供的緩存是共享的，所以它無法跟蹤每個控制器，這就需要控制器自己實現排隊和重試機制。因此，大多數 Resource Event Handler 所做的工作只是將事件放入消費者工作隊列中。
每當資源被修改時，Resource Event Handler 就會放入一個 key 到 Workqueue 中。key 的表示形式爲 <resource_namespace>/<resource_name>，如果提供了 <resource_namespace>，key 的表示形式就是 <resource_name>。每個事件都以 key 作爲標識，因此每個消費者（控制器）都可以使用 workers 從 Workqueue 中讀取 key。所有的讀取動作都是串行的，這就保證了不會出現兩個 worker 同時讀取同一個 key 的情況。
Workqueue 在 client-go 庫中的位置爲 client-go/util/workqueue，支持的隊列類型包括延遲隊列，定時隊列和速率限制隊列。下面是速率限制隊列的一個示例：
queue :=
workqueue.NewRateLimitingQueue(workqueue.DefaultControllerRateLimiter())
Workqueue 提供了很多函數來處理 key，每個 key 在 Workqueue 中的生命週期如下圖所示：
如果處理事件失敗，控制器就會調用 AddRateLimited() 函數將事件的 key 放回 Workqueue 以供後續重試（如果重試次數沒有達到上限）。如果處理成功，控制器就會調用 Forget() 函數將事件的 key 從 Workqueue 中移除。注意：該函數僅僅只是讓 Workqueue 停止跟蹤事件歷史，如果想從 Workqueue 中完全移除事件，需要調用 Done() 函數。
現在我們知道，Workqueue 可以處理來自緩存的事件通知，但還有一個問題：控制器應該何時啓用 workers 來處理 Workqueue 中的事件呢？
控制器需要等到緩存完全同步到最新狀態才能開始處理 Workqueue 中的事件，主要有兩個原因：
- 在緩存完全同步之前，獲取的資源信息是不準確的。
- 對單個資源的多次快速更新將由緩存合併到最新版本中，因此控制器必須等到緩存變爲空閒狀態才能開始處理事件，不然只會把時間浪費在等待上。
這種做法的僞代碼如下：
controller.informer = cache.NewSharedInformer(...)
controller.queue = workqueue.NewRateLimitingQueue(workqueue.DefaultControllerRateLimiter())
controller.informer.Run(stopCh)
if !cache.WaitForCacheSync(stopCh, controller.HasSynched)
{
log.Errorf("Timed out waiting for caches to sync"))
}
// Now start processing
controller.runWorker()
所有處理流程如下所示：
參考鏈接: