Control Loop 在 Google 開發的三個容器管理系統中都擔任核心概念，Control Loop 就是一個迴圈，會檢查觀察狀態和期望狀態的一致性。

根據開放世界假設，系統假設外部環境是不可控且不斷變化的，因此外部的操作隨時可能影響系統狀態。為了應對這個假設， 系統通過持續觀察來保證狀態的正確性，不會因單一外部操作而失效。 比如說：用戶可以藉由 kubectl 終止 Pod，這時候 Controller 會檢測到 Pod 的數量跟期望狀態不服時，它會立即創建 Pod。

Control loop 是個 Level-based triggered，避免使用複雜的狀態機，這樣的設計減少了系統的複雜度，也降低了系統的脆弱性。

儘管 Control Loop 的概念在三代系統中都存在，但其實現方式有所不同：

Borg：Borgmaster 會負責維護整個系統的狀態，它會定期輪詢 Borglet 以獲取最近的狀態，並根據這些狀態做出排程決策，所以是基於觀察的決策，而不是基於預期。

Omega：Omega 沒有集中的狀態機，其邏輯分散在各個組件中。Control Loop 邏輯由各個組件自己實現。每個組件都有一個本地私有的資料副本，用於排程決策，而這個副本會頻繁地跟共享的儲存同步。 每個組件不斷地觀察狀態並做出決策，再嘗試將決策結果提交到共享狀態中。 由於是共享狀態，雖然靈活，但是需要處理多組件對同一筆狀態修改造成的衝突。

Kubernetes：Kubernetes 採用了一種折衷方案，在保持 Omega 分散式架構的靈活性和可擴展性的同時，也通過集中式的 API server 來強制執行系統級別的不變性、策略和資料轉換。Kubernetes 會持續檢查實際狀態以及預期狀態，這個迴圈稱為 Reconcile，當 Reconcile 觀察到不一致，會做出變動，把實際狀態朝向實際狀態前進。

• 跟 Omega 允許受信任的組件直接存取儲存不同，Kubernetes 強制所有組件必須透過集中式的 API Server 訪問儲存。
• 與 Omega 每個組件負責自己的邏輯不同，每個組件實作自己的 Controller，然後放在 Controller Manager，例如 ReplicationController 以及 NodeController。

以上資訊是從這幾篇論文整理出來關於 Control Loop 的演化過程。

Borg, Omega, Kubernetes[1]

Large-scale cluster management at Google with Borg [2]

Omega: flexible, scalable schedulers for large compute clusters [3]

[1]https://research.google/pubs/borg-omega-and-kubernetes/

[2]https://research.google/pubs/large-scale-cluster-management-at-google-with-borg/

[3]https://research.google/pubs/omega-flexible-scalable-schedulers-for-large-compute-clusters/