k8s之Controller Manager


一、Controller Manager簡介

Controller Manager作為集群內部的管理控制中心,負責集群內的NodePodEndpointNamespaceServiceAccountResourceQuota的管理,

每個Controller通過API Server提供的接口實時監控整個集群的每個資源對象的當前狀態,當發生各種故障導致系統狀態發生變化時,會嘗試將系統狀態修復到“期望狀態”。例如:當某個Node意外宕機時,Controller Manager會及時發現並執行自動化修復流程,確保集群始終處於預期的工作狀態。

幾乎每種特定資源都有特定的Controller維護管理以保持預期狀態,而Controller Manager的職責便是把所有的Controller聚合起來,提供基礎設施降低 Controller 的實現復雜度啟動和維持 Controller 的正常運行

從比較高維度的視角看,Controller Manager 主要提供了一個分發事件的能力,而不同的 Controller 只需要注冊對應的 Handler 來等待接收和處理事件。

 

二、Controller Manager含有的controller種類

Controller Manager聚合的種類較多,包含:

Replication Controller

Node Controller

CronJob Controller

Daemon Controller

Deployment Controller

Endpoint Controller

Garbage Collector

Namespace Controller

Job Controller

Pod AutoScaler

RelicaSet

Service Controller

ServiceAccount Controller

StatefulSet Controller

Volume Controller

Resource quota Controller

 

三、需要選主

K8s中的control-plane包括了apiservercontroller-managerscheduleretcd,當搭建高可用集群時就會涉及到部分組件的選主問題。etcd是整個集群所有狀態信息的存儲,涉及數據的讀寫和多個etcd之間數據的同步,對數據的一致性要求嚴格,所以使用較復雜的raft算法來選擇用於提交數據的主節點。而apiserver作為集群入口,本身是無狀態的web服務器,多個apiserver服務之間直接負載請求並不需要做選主。Controller-ManagerScheduler作為任務類型的組件,比如controller-manager內置的k8s各種資源對象的控制器實時的watch apiserver獲取對象最新的變化事件做期望狀態和實際狀態調整,調度器watch未綁定節點的pod做節點選擇,顯然多個這些任務同時工作是完全沒有必要的,所以controller-managerscheduler也是需要選主的,但是選主邏輯和etcd不一樣的,這里只需要保證從多個controller-managerscheduler之間選出一個進入工作狀態即可,而無需考慮它們之間的數據一致和同步。他們是基於etcd集群上的分布式鎖實現領導者選舉機制,搶先獲取鎖的實例被稱為leader.

 

四、一些特性

4.1 Replication Controller

只有當Pod的重啟策略是Always的時候(RestartPolicy=Always),副本控制器才會管理該Pod的操作(創建、銷毀、重啟等)。

RC中的Pod模板就像一個模具,模具制造出來的東西一旦離開模具,它們之間就再沒關系了。一旦Pod被創建,無論模板如何變化,也不會影響到已經創建的Pod

Pod可以通過修改label來脫離RC的管控,該方法可以用於將Pod從集群中遷移,數據修復等調試。

刪除一個RC不會影響它所創建的Pod,如果要刪除Pod需要將RC的副本數屬性設置為0

不要越過RC創建Pod,因為RC可以實現自動化控制Pod,提高容災能力。

 

4.2 ResourceQuota Controller

k8s配額管理是通過Admission Control(准入控制)來控制的;

Admission Control提供兩種配額約束方式:LimitRangerResourceQuota

LimitRanger作用於PodContainer

ResourceQuota作用於Namespace上,限定一個Namespace里的各類資源的使用總額。

 

4.3 Endpoint Controller

Endpoints表示了一個Service對應的所有Pod副本的訪問地址,而Endpoints Controller負責生成和維護所有Endpoints對象的控制器。它負責監聽Service和對應的Pod副本的變化。

如果監測到Service被刪除,則刪除和該Service同名的Endpoints對象;

如果監測到新的Service被創建或修改,則根據該Service信息獲得相關的Pod列表,然后創建或更新Service對應的Endpoints對象。

如果監測到Pod的事件,則更新它對應的ServiceEndpoints對象。

kube-proxy進程獲取每個ServiceEndpoints,實現Service的負載均衡功能。

 

 

參考:https://blog.csdn.net/huwh_/article/details/75675761(幾種常用的控制器)


免責聲明!

本站轉載的文章為個人學習借鑒使用,本站對版權不負任何法律責任。如果侵犯了您的隱私權益,請聯系本站郵箱yoyou2525@163.com刪除。



 
粵ICP備18138465號   © 2018-2025 CODEPRJ.COM