關于 Kubernetes中kube-controller-managerr的一些筆記

寫在前面

學習K8s，遇到整理記憶

大部分都是書里或者官網的東西

博文內容為kube-controller-manager的一些理論

涉及到常見控制器的一些說明

我想變成一棵樹. 開心時在秋天開花; 傷心時在春天落葉。 ——烽火戲諸侯《劍來》

Kubernetes 控制器管理器是一個守護進程，內嵌隨 Kubernetes 一起發布的核心控制回路。 控制回路是一個永不休止的循環(所以說K8S中的控制管理器是一個死循環)，用于調節系統狀態。

在 Kubernetes 中，每個控制器是一個控制回路，通過API 服務器監視集群的共享狀態， 并嘗試進行更改以將當前狀態轉為期望狀態。 目前，Kubernetes 自帶的控制器例子包括副本控制器、節點控制器、命名空間控制器和服務賬號控制器等。

Controller Manager 原理分析

Controller Manager作為集群內部的管理控制中心,當某個Node意外宕機時, Controller Manager會及時發現此故障并執行自動化修復流程,確保集群始終處于預期的工作狀態。

Controller Manager內部包含Replication Controller, Node Controller, ResourceQuota Controller, Namespace Controller, ServiceAccount Controller, Token Controller,Service Controller及Endpoint Controller等多個Controller,每種Controller都負責一種具體的控制流程,而Controller Manager正是這些Controller的核心管理者。

副本控制器(Replication Controller)

其實對這個有些模糊，RC資源現在用的已經很少了，不知道這里只是指RC還是說RS，deploy都是由Replication Controller控制的

Replication Controller的核心作用是確保在任何時候集群中一個RC所關聯的Pod副本數量保持預設值。

需要注意的一點是:

只有當Pod的重啟策略是Always時(RestartPolicy=Always), Replication Controller才會管理該Pod的操作(例如創建、銷毀、重啟等)

RC中的pod模板一旦創建完成，就和RC中的模板沒有任何關系。

Pod可以通過修改標簽來實現脫離RC的管控。可以用于

將Pod從集群中遷移、數據修復等調試

。

對于被遷移的Pod副本, RC會自動創建一個新的,副本替換被遷移的副本。需要注意的是,刪除一個RC不會影響它所創建的Pod,如果想刪除一個RC所控制的Pod,則需要將該RC的副本數(Replicas)屬性設置為0,這樣所有的Pod副本都會被自動刪除。

節點控制器(Node Controller)

kubelet進程在啟動時通過API Server向master注冊自身的節點信息,并定時向API Server匯報狀態信息, API Server接收到這些信息后,將這些信息更新到etcd中, etcd中存儲的節點信息包括節點健康狀況、節點資源、節點名稱、節點地址信息、操作系統版本、Docker版本、kubelet版本等。

節點健康狀況包含“就緒” (True) “未就緒” (False)和“未知" (Unknown)三種。

Node Controller通過API Server實時獲取Node的相關信息,實現管理和監控集群中的各個Node節點的相關控制功能, Node Controller的核心工作流程如圖。

Controller Manager在啟動時如果設置了-cluster-cidr參數,那么為每個沒有設置Spec.PodCIDR的Node節點生成一個CIDR地址,并用該CIDR地址設置節點的Spec.PodCIDR屬性,這樣做的目的是防止不同節點的CIDR地址發生沖突。

逐個讀取節點信息,多次嘗試修改nodestatusMap中的節點狀態信息,將該節點信息和Node Controller的nodeStatusMap中保存的節點信息做比較。

如果節點狀態為非“就緒”狀態,且系統指定了Cloud Provider,則Node Controller調用Cloud Provider查看節點,若發現節點故障,則刪除etcd中的節點信息,并刪除和該節點相關的Pod等資源的信息。

資源控制器(ResourceQuota Controller)

Kubernetes提供了資源配額管理( ResourceQuotaController),確保了指定的資源對象在任何時候都不會超量占用系統物理資源,導致整個系統運行紊亂甚至意外宕機,對整個集群的平穩運行和穩定性有非常重要的作用。

Kubernetes的配額管理是通過Admission Control (準入控制)來控制的,Admission Control當前提供了兩種方式的配額約束，分別是LimitRanger與ResourceQuota。其中

LimitRanger作用于Pod和Container上,

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

如果在Pod定義中同時聲明了LimitRanger,則用戶通過API Server請求創建或修改資源時, Admission Control會計算當前配額的使用情況,如果不符合配額約束,則創建對象失敗。

對于定義了ResourceQuota的Namespace, ResourceQuota Controller組件則負責定期統計和生成該Namespace下的各類對象的資源使用總量,統計結果包括Pod, Service,RC、Secret和Persistent Volume等對象實例個數,以及該Namespace下所有Container實例所使用的資源量(目前包括CPU和內存),然后將這些統計結果寫入etcd的resourceQuotaStatusStorage目錄(resourceQuotas/status)中。

命名空間(Namespace Controller)

通過API Server可以創建新的Namespace并保存在etcd中, Namespace Controller定時通過API Server讀取這些Namespace信息。

Service Controller(服務控制器)與Endpoint Controller

Service, Endpoints與Pod的關系

Endpoints表示一個Service對應的所有Pod副本的訪問地址,而EndpointsController就是負責生成和維護所有Endpoints對象的控制器。

Endpoint Controller負責監聽Service和對應的Pod副本的變化

Endpoints對象是在哪里被使用的呢?

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

Service Controller的作用,它其實是屬于Kubernetes集群與外部的云平臺之間的一個接口控制器。

Service Controller監聽Service的變化,如果是一個LoadBalancer類型的Service (externalLoadBalancers-true),則Service Controller確保外部的云平臺上該Service對應的LoadBalancer實例被相應地創建、刪除及更新路由轉發表(根據Endpoints的條目)。

yaml 資源文件

相關啟動參數小伙伴可以移步官網查看：

https://kubernetes.io/zh/docs/reference/command-line-tools-reference/kube-controller-manager/

┌──[root@vms81.liruilongs.github.io]-[~/ansible/k8s-svc-create] └─$kubectl get pods kube-controller-manager-vms81.liruilongs.github.io -o yaml -n kube-system apiVersion: v1 kind: Pod metadata: annotations: kubernetes.io/config.hash: 49b7654103f80170bfe29d034f806256 kubernetes.io/config.mirror: 49b7654103f80170bfe29d034f806256 kubernetes.io/config.seen: "2021-12-14T23:02:32.958181106+08:00" kubernetes.io/config.source: file seccomp.security.alpha.kubernetes.io/pod: runtime/default creationTimestamp: "2021-12-14T15:02:33Z" labels: component: kube-controller-manager tier: control-plane name: kube-controller-manager-vms81.liruilongs.github.io namespace: kube-system ownerReferences: - apiVersion: v1 controller: true kind: Node name: vms81.liruilongs.github.io uid: b1e00933-c091-4a1f-b470-1418cbe5bc20 resourceVersion: "296478" uid: ac955a42-0c15-44f8-9217-cacc59c8f410 spec: containers: - command: - kube-controller-manager - --allocate-node-cidrs=true - --authentication-kubeconfig=/etc/kubernetes/controller-manager.conf - --authorization-kubeconfig=/etc/kubernetes/controller-manager.conf - --bind-address=127.0.0.1 - --client-ca-file=/etc/kubernetes/pki/ca.crt - --cluster-cidr=10.244.0.0/16 - --cluster-name=kubernetes - --cluster-signing-cert-file=/etc/kubernetes/pki/ca.crt - --cluster-signing-key-file=/etc/kubernetes/pki/ca.key - --controllers=*,bootstrapsigner,tokencleaner - --kubeconfig=/etc/kubernetes/controller-manager.conf - --leader-elect=true - --port=0 - --requestheader-client-ca-file=/etc/kubernetes/pki/front-proxy-ca.crt - --root-ca-file=/etc/kubernetes/pki/ca.crt - --service-account-private-key-file=/etc/kubernetes/pki/sa.key - --service-cluster-ip-range=10.96.0.0/12 - --use-service-account-credentials=true image: registry.aliyuncs.com/google_containers/kube-controller-manager:v1.22.2 imagePullPolicy: IfNotPresent livenessProbe: failureThreshold: 8 httpGet: host: 127.0.0.1 path: /healthz port: 10257 scheme: HTTPS initialDelaySeconds: 10 periodSeconds: 10 successThreshold: 1 timeoutSeconds: 15 name: kube-controller-manager resources: requests: cpu: 200m startupProbe: failureThreshold: 24 httpGet: host: 127.0.0.1 path: /healthz port: 10257 scheme: HTTPS initialDelaySeconds: 10 periodSeconds: 10 successThreshold: 1 timeoutSeconds: 15 terminationMessagePath: /dev/termination-log terminationMessagePolicy: File volumeMounts: - mountPath: /etc/ssl/certs name: ca-certs readOnly: true - mountPath: /etc/pki name: etc-pki readOnly: true - mountPath: /usr/libexec/kubernetes/kubelet-plugins/volume/exec name: flexvolume-dir - mountPath: /etc/kubernetes/pki name: k8s-certs readOnly: true - mountPath: /etc/kubernetes/controller-manager.conf name: kubeconfig readOnly: true dnsPolicy: ClusterFirst enableServiceLinks: true hostNetwork: true nodeName: vms81.liruilongs.github.io preemptionPolicy: PreemptLowerPriority priority: 2000001000 priorityClassName: system-node-critical restartPolicy: Always schedulerName: default-scheduler securityContext: seccompProfile: type: RuntimeDefault terminationGracePeriodSeconds: 30 tolerations: - effect: NoExecute operator: Exists volumes: - hostPath: path: /etc/ssl/certs type: DirectoryOrCreate name: ca-certs - hostPath: path: /etc/pki type: DirectoryOrCreate name: etc-pki - hostPath: path: /usr/libexec/kubernetes/kubelet-plugins/volume/exec type: DirectoryOrCreate name: flexvolume-dir - hostPath: path: /etc/kubernetes/pki type: DirectoryOrCreate name: k8s-certs - hostPath: path: /etc/kubernetes/controller-manager.conf type: FileOrCreate name: kubeconfig status: conditions: - lastProbeTime: null lastTransitionTime: "2021-12-20T00:28:14Z" status: "True" type: Initialized - lastProbeTime: null lastTransitionTime: "2021-12-21T13:10:56Z" status: "True" type: Ready - lastProbeTime: null lastTransitionTime: "2021-12-21T13:10:56Z" status: "True" type: ContainersReady - lastProbeTime: null lastTransitionTime: "2021-12-20T00:28:14Z" status: "True" type: PodScheduled containerStatuses: - containerID: docker://6af720a0409f3bb3ffd8ddd7995faf749c43145fea39f28ff54a235f4644385b image: registry.aliyuncs.com/google_containers/kube-controller-manager:v1.22.2 imageID: docker-pullable://registry.aliyuncs.com/google_containers/kube-controller-manager@sha256:91ccb477199cdb4c63fb0c8fcc39517a186505daf4ed52229904e6f9d09fd6f9 lastState: terminated: containerID: docker://5b5e8d4cc06d08ecd4d5940e3cdceb55728c410738698c14d144c454772cb17e exitCode: 255 finishedAt: "2021-12-21T13:10:04Z" reason: Error startedAt: "2021-12-21T00:31:52Z" name: kube-controller-manager ready: true restartCount: 19 started: true state: running: startedAt: "2021-12-21T13:10:32Z" hostIP: 192.168.26.81 phase: Running podIP: 192.168.26.81 podIPs: - ip: 192.168.26.81 qosClass: Burstable startTime: "2021-12-20T00:28:14Z"

Kubernetes

版權聲明：本文內容由網絡用戶投稿，版權歸原作者所有，本站不擁有其著作權，亦不承擔相應法律責任。如果您發現本站中有涉嫌抄襲或描述失實的內容，請聯系我們jiasou666@gmail.com 處理，核實后本網站將在24小時內刪除侵權內容。