Controller Manager 是 Kubernetes 集群的自動化控制中心，裡面包含了 3X 多個 Controller ，有管理 Pod 相關的、網路相關的、儲存相關的等等。大多數的 Controller 工作模式都差不多，每個 Controller 都是一個 control loop ，負責通過 api-server 監聽其相對應的資源，根據對象狀態來決定接下來的動作，使其達到預期的狀態。

• Controller Manager 是集群的大腦，是確保集群動起來的關鍵。
• 作用是確保 Kubernetes 遵循聲明式系統規範，確保系統的真實狀態 (Actual State) 與用戶定義的期望狀態 (Desired State) 一致。
• Controller Manager 是多個 Controller 的組合，每個 Controller 事實上都是一個 control loop，負責監聽其管控對象，當對象發生變更時完成配置。
• Controller 配置失敗通常會觸發自動重試，整個集群會在 Controller 不斷重試的機制下，確保最終一致性 (Eventual Consistency)。

Controller 工作流程

Informer 的內部機制

Controller 的協同工作原理

常見的 Controller

1. 必須啟動的 Controller
   • EndpointController
   • ReplicationController
   • PodGCController
   • ResourceQuotaController
   • NamespaceController
   • ServiceAccountController
   • GarbageCollectorController
   • DaemonSetController
   • JobController
   • DeploymentController
   • ReplicaSetController
   • HPAController
   • DisruptionController
   • StatefulSetController
   • CronJobController
   • CSRSigningController
   • CSRApprovingController
   • TTLController
2. 默認啟動的可選 Controller ，可通過選項設置是否開啟
   • TokenController
   • NodeController
   • ServiceController
   • RouteController
   • PVBinderController
   • AttachDetachController
3. 默認禁止的可選 Controller ，可通過選項設置是否開啟
   • BootstrapSignerController
   • TokenCleanerController

Cloud Controller Manager

甚麼時候需要 cloud controller manager?

Cloud Controller Manager 自 Kubernetes 1.6 開始，從 kube-controller-manager 中分離出來，主要因為 Cloud Controller Manager 往往需要和企業的 Cloud 做深度結合，release cycle 跟 kubernetes 相對獨立。

與 kubernetes 核心管理組件一起升級是一件費時費力的事情。

通常 cloud controller manager 需要:

• 認證授權: 企業 cloud 往往需要認證訊息， kubernetes 要與 cloud API，需要獲取 cloud 系統裡的 Service Account。
• cloud controller manager 本身作為一個用戶泰的 component ，需要 kubernetes 中有正確的 RBAC 設置，獲取資源操作權限。
• 高可用: 需要通過 leader election 來確保 cloud controller manager 高可用。

Cloud Controller Manager 是從老版本的 API Server 分離出來的。

• kuber-apiserver 和 kube-controller-manager 中一定不能指定 cloud-provider，否則會加載內置的 cloud controller manager。
• kuberlet 要配置 –cloud-provider=external。

Cloud Controller Manager 主要支持：

• Node Controller: 訪問 cloud API ，來更新 node 狀態，在 cloud 刪除該節點以後，從 kubernetes 刪除 node。
• Route Controller: 在 cloud 環境配置路由。
• Service Controller: 負責配置為 loadbalancer 類型的服務配置 LB VIP。

需要客製的 Cloud Controller

• Ingress controller
• Service controller
• 自主研發的 controller
  • RBAC controller
  • Account Controller

高可用

在啟動時設置 --leader-elect=true 後，controller manager 會使用多節點選主的方式選擇主節點。只有主節點才會調用 StartControllers() 啟動所有 Controller ，而其他從節點則僅執行選主算法。

多節點選主的實現方法見 leaderelection.go。它實現了兩種資源鎖（Endpoint 或 ConfigMap，kube-controller-manager 和 cloud-controller-manager 都使用 Endpoint 鎖），通過更新資源的 Annotation（control-plane.alpha.kubernetes.io/leader），來確定 master slave 關係。

高性能

從 Kubernetes 1.7 開始，所有需要監控資源變化情況的調用均推薦使用 Informer。 Informer 提供了基於事件通知的只讀緩存機制，可以註冊資源變化的回調函數，並可以極大減少 API 的調用。

Informer 的使用方法可以參考 這裡。

Node Eviction

Node Controller 在節點異常後，會按照默認的速率（--node-eviction-rate=0.1，即每10秒一個節點的速率）進行 Node 的驅逐。 Node Controller 按照 Zone 將節點劃分為不同的組，再跟進 Zone 的狀態進行速率調整：

• Normal：所有節點都 Ready，默認速率驅逐。
• PartialDisruption：即超過33% 的節點 NotReady 的狀態。當異常節點比例大於 -unhealthy-zone-threshold=0.55 時開始減慢速率：
  • 小集群（即節點數量小於 -large-cluster-size-threshold=50）：停止驅逐
  • 大集群，減慢速率為 -secondary-node-eviction-rate=0.01
• FullDisruption：所有節點都 NotReady，返回使用默認速率驅逐。但當所有 Zone 都處在 FullDisruption 時，停止驅逐。

Leader Election 的工作機制

總結

每個 controller 都扮演著自己該負責的事情，這樣的每個 controller 之間的職責都分離的很乾淨，讚讚！

歡迎到我的 Facebook Alan 的筆記本 留言，順手給我個讚吧！你的讚將成為我持續更新的動力，感謝你的閱讀，讓我們一起學習成為更好的自己。

• ← Previous Post
• Next Post →