前言

昨日的延伸問題：如何跟 k8s 叢集互動？

主要就是透過今天要講的 Control Plane Components 來達成

Control Plane Components

Control Plane 負責管理所有 Node Components,

主要由以下幾個元件組成：

kube-api-server

Control Plane 元件中, kube-api-server 負責處理所有來自客戶端服務發來的請求

屬於 Control Plane 對外的接口, 驗證所有客戶端的請求

然後交給對應的處理元件(例如：kube-scheduler)繼續處理

處理流程如下圖:

kube-scheduler

Control Plane 元件中, kube-scheduler 負責做分派任務給 Node 來執行

假設今天要新增一個 Container, kube-scheduler 會依序當下資源狀態,

決定要分派給哪個 Node 的 kubelet 做執行

處理流程如下圖：

kube-controller-manager

Control Plane 元件中, kube-controller-manager 負責偵測 k8s 叢集的狀態變化

其中可以分成以下幾種類別：

1 偵測 Node 關閉的狀態

2 偵測 Job 狀態： 察看 Job 物件中的一次性任務, 產生 Pod 去完成這個 Job

3 廣播端點狀態： 更新 cluster 中的 Service, Pod 狀態

4 Service Account & Token controllers: Create default accounts and API access tokens for new namespaces.

處理流程如下：

etcd

Control Plane 元件中, etcd 是一個 key-value 的儲存資料, 用來紀錄 k8s 叢集的運行狀態

kube-controller-manager 以及 kube-scheduler 都需要透過 etcd 維持運作

另外 etcd 屬於分散式存儲, 因此再一個 k8s 叢集中可以同時有多個 Control Plane 元件

cloud-controller-manager

Control Plane 元件中, cloud-controller-manager 是一個內嵌雲端規格操作的元件

cloud-controller-manager 讓 k8s 叢集可以連接到雲服務商的操作 api

用來隔離 k8s 元件操作與雲服務商的 api, 降低 k8s 元件與雲服務商的 api 的相依性

特別要注意的是, 如果 k8s 叢集運行的環境是本機電腦沒有連結到雲服務商(例如： minikube local),

則不會有這個元件

後記

一般的 k8s 叢集為了確保高可用性, 通常會有至少2個以上的 Control Plane 如下圖

其中 kube-api-server 與 etcd 都可以做平衡負載, 因為 etcd 是屬於分散式存儲

所以多個 Control Plane 仍然是共享一個叢集狀態