Controller Manager做爲集羣內部的管理控制中心,負責集羣內的Node、Pod副本、服務端點(Endpoint)、命名空間(Namespace)、服務帳號(ServiceAccount)、資源定額(ResourceQuota)的管理,當某個Node意外宕機時,Controller Manager會及時發現並執行自動化修復流程,確保集羣始終處於預期的工做狀態。
每一個Controller經過API Server提供的接口實時監控整個集羣的每一個資源對象的當前狀態,當發生各類故障致使系統狀態發生變化時,會嘗試將系統狀態修復到「指望狀態」。node
爲了區分,資源對象Replication Controller簡稱RC,而本文是指Controller Manager中的Replication Controller,稱爲副本控制器。副本控制器的做用即保證集羣中一個RC所關聯的Pod副本數始終保持預設值。json
只有當Pod的重啓策略是Always的時候(RestartPolicy=Always),副本控制器纔會管理該Pod的操做(建立、銷燬、重啓等)。
RC中的Pod模板就像一個模具,模具製造出來的東西一旦離開模具,它們之間就再不要緊了。一旦Pod被建立,不管模板如何變化,也不會影響到已經建立的Pod。
Pod能夠經過修改label來脫離RC的管控,該方法能夠用於將Pod從集羣中遷移,數據修復等調試。
刪除一個RC不會影響它所建立的Pod,若是要刪除Pod須要將RC的副本數屬性設置爲0。
不要越過RC建立Pod,由於RC能夠實現自動化控制Pod,提升容災能力。app
2.1. Replication Controller的職責負載均衡
確保集羣中有且僅有N個Pod實例,N是RC中定義的Pod副本數量。 經過調整RC中的spec.replicas屬性值來實現系統擴容或縮容。 經過改變RC中的Pod模板來實現系統的滾動升級。
2.2. Replication Controller使用場景
使用場景 說明 使用命令
從新調度 當發生節點故障或Pod被意外終止運行時,能夠從新調度保證集羣中仍然運行指定的副本數。
彈性伸縮 經過手動或自動擴容代理修復副本控制器的spec.replicas屬性,能夠實現彈性伸縮。 kubectl scale
滾動更新 建立一個新的RC文件,經過kubectl 命令或API執行,則會新增一個新的副本同時刪除舊的副本,當舊副本爲0時,刪除舊的RC。 kubectl rolling-updatefrontend
滾動升級,具體可參考kubectl rolling-update –help,官方文檔:https://kubernetes.io/docs/tasks/run-application/rolling-update-replication-controller/spa
[root@node5 ~]# kubectl rolling-update --help Perform a rolling update of the given ReplicationController. Replaces the specified replication controller with a new replication controller by updating one pod at a time to use the new PodTemplate. The new-controller.json must specify the same namespace as the existing replication controller and overwrite at least one (common) label in its replicaSelector. Usage: kubectl rolling-update OLD_CONTROLLER_NAME ([NEW_CONTROLLER_NAME] --image=NEW_CONTAINER_IMAGE | -f NEW_CONTROLLER_SPEC) [flags] Aliases: rolling-update, rollingupdate
Update pods of frontend-v1 using new replication controller data in frontend-v2.json.代理
kubectl rolling-update frontend-v1 -f frontend-v2.json
Update pods of frontend-v1 using JSON data passed into stdin.調試
cat frontend-v2.json | kubectl rolling-update frontend-v1 -f -
Update the pods of frontend-v1 to frontend-v2 by just changing the image, and switching the
name of the replication controller.code
kubectl rolling-update frontend-v1 frontend-v2 --image=image:v2
Update the pods of frontend by just changing the image, and keeping the old nameorm
kubectl rolling-update frontend --image=image:v2
kubelet在啓動時會經過API Server註冊自身的節點信息,並定時向API Server彙報狀態信息,API Server接收到信息後將信息更新到etcd中。
Node Controller經過API Server實時獲取Node的相關信息,實現管理和監控集羣中的各個Node節點的相關控制功能。流程以下
一、Controller Manager在啓動時若是設置了–cluster-cidr參數,那麼爲每一個沒有設置Spec.PodCIDR的Node節點生成一個CIDR地址,並用該CIDR地址設置節點的Spec.PodCIDR屬性,防止不一樣的節點的CIDR地址發生衝突。
二、具體流程見以上流程圖。
三、逐個讀取節點信息,若是節點狀態變成非「就緒」狀態,則將節點加入待刪除隊列,不然將節點從該隊列刪除。
資源配額管理確保指定的資源對象在任什麼時候候都不會超量佔用系統物理資源。
支持三個層次的資源配置管理:
1)容器級別:對CPU和Memory進行限制 2)Pod級別:對一個Pod內全部容器的可用資源進行限制 3)Namespace級別:包括 Pod數量 Replication Controller數量 Service數量 ResourceQuota數量 Secret數量 可持有的PV(Persistent Volume)數量
說明:
k8s配額管理是經過Admission Control(准入控制)來控制的; Admission Control提供兩種配額約束方式:LimitRanger和ResourceQuota; LimitRanger做用於Pod和Container; ResourceQuota做用於Namespace上,限定一個Namespace裏的各種資源的使用總額。
ResourceQuota Controller流程圖:
用戶經過API Server能夠建立新的Namespace並保存在etcd中,Namespace Controller定時經過API Server讀取這些Namespace信息。
若是Namespace被API標記爲優雅刪除(即設置刪除期限,DeletionTimestamp),則將該Namespace狀態設置爲「Terminating」,並保存到etcd中。同時Namespace Controller刪除該Namespace下的ServiceAccount、RC、Pod等資源對象。
Service、Endpoint、Pod的關係:
Endpoints表示了一個Service對應的全部Pod副本的訪問地址,而Endpoints Controller負責生成和維護全部Endpoints對象的控制器。它負責監聽Service和對應的Pod副本的變化。
若是監測到Service被刪除,則刪除和該Service同名的Endpoints對象; 若是監測到新的Service被建立或修改,則根據該Service信息得到相關的Pod列表,而後建立或更新Service對應的Endpoints對象。 若是監測到Pod的事件,則更新它對應的Service的Endpoints對象。
kube-proxy進程獲取每一個Service的Endpoints,實現Service的負載均衡功能。
Service Controller是屬於kubernetes集羣與外部的雲平臺之間的一個接口控制器。Service Controller監聽Service變化,若是是一個LoadBalancer類型的Service,則確保外部的雲平臺上對該Service對應的LoadBalancer實例被相應地建立、刪除及更新路由轉發表。