kubernetes 的決策中樞 ◉‿◉

長這樣但沒有要講這張圖（欸）

先舉個🌰：

類似的對話應該不陌生，在上述的對話中，其實已經把 Control Plane 的組件角色大致說完了

• kube-apiserver：媽媽
  負責接收所有家庭成員的需求，並進行溝通
• kube-scheduler：爸爸
  處理決策和調度，若有新情況會調整計畫
• kube-controller-manager：哥哥
  確保代辦事項可以順利進行，並處理例外狀況

你呢？你的角色是誰？

你是做事的 Worker Node，這章節沒你什麼事情 (⁎⁍̴̛ᴗ⁍̴̛⁎)

ETCD呢？

不在這裡。
ETCD 是媽媽私人的小本本，只有他自己可以看，用來記載要執行的所有資訊。
什麼意思？
嗯... 家裡找不到東西的時候通常會怎麼辦？

問媽媽啊！

kube-apiserver

kube-apiserve 是 唯一 可以直接調用 ETCD 的元件

Kubernetes 的 API組件，負責接收所有（包含群集內部和來自外部的）請求。
Kubernetes 的元件之間沒有其他溝通方式（其他溝通方式背後也是透過 kube-apiserver 執行 ），一旦 kube-apiserver 故障，就等於完全失去對叢集的控制權，雖然已經部署的元件會繼續運行，但是所有的操作會全數失效，包含但不限於：資源的建立/更新/刪除、資源調度、自動擴充、監控。
為了避免這個狀況，kube-apiserver 支援橫向擴展，可以部署多個實體並分散在多個 Node 上，盡可能降低風險。

kube-scheduler

管理 Pod 的分配。會過濾現有的 Node 資源，尋找最適合部署的 Node。
決策方式大概分為兩階段：

1. 篩選 （Filtering）
   kube-scheduler 會根據一組預先設定好的過濾條件，篩選出所有可用的 Node。
   篩選條件包括（但不限於）：
   • 資源需求：檢查節點是否有足夠的 CPU、Ｍemory 等資源來滿足 Pod 的需求
   • Node 是否可用：確認節點是否被標記為不可用
   • 檢查 Affinity ＆ Anti-affinity 規則：確認 Pod 是否與其他應用程式相依或相斥
2. 擇優 （Scoring）
   kube-scheduler 會對預選階段篩選出的節點進行評分，根據優先級來選擇最合適的節點。
   依據包括：
   • 資源平衡：避免資源過度集中在某些 Node 上
   • Affinity 規則：選擇與其他 Pod 最接近的節點，最大降低延遲
   • 成本最小化：選擇最調度成本最低的 Node

kube-scheduler 只負責發號施令，實際執行的是 Worker Node 中的 kubelet

Controller Manager

由多種控制器組合而成 （雖然實際上大多由單一文件編譯），負責分配資源到 Node 上，並監控 Node 的狀態，是 Kubernetes 自動化和自我修復能力的核心。

當然，所有的操作都還是透過 kube-apiserver 執行

舉幾個比較核心的 controller：

• Node Controller
  監控 Worker Node 狀態，在 Node 故障時採取補救措施，如：將 Pod 遷移到其他可用的 Node 上
• Replication Controller
  確保有符合數量的可用 Pod 在運行，發現損壞會建立新的替代
• Endpoints Controller
  處理 Pods & Services 接口
  service：k8s 中的元件，把一個或多個 pod 兜在一起，將其釋出（expose）為單一個服務
• Service Account & Token Controllers
  為 namespace 建立預設帳戶 ＆ API token

其他還有 Deployment Controller、StatefulSet Controller、Job Controller 等組件... ... 所有的 controller 組件都只有一個共同的目標：讓這個 Cluster 依照設定保持穩定運行。

與 kube-apiserver 相同，controller manager也可以部署成多個 instance，不同的是，比起 kube-apiserver 可以各自獨立運行，controller manager 會透過選舉機制確保一次只有一個 instance 被使用，其他則是備用狀態。

ETCD

使用 key-value 的方式存值，儲存內容族繁不及備載，囊括所有（真的是所有）運行 Cluster 的必要資訊。

endpoints=https://127.0.0.1:2379 
cacert=/etc/kubernetes/pki/etcd/ca.crt
cert=/etc/kubernetes/pki/etcd/server.crt
key=/etc/kubernetes/pki/etcd/server.key
... ...

主要特性包含：一致性、高可用、安全（SSL/TLS驗證＆加密），也能建立 snapshot，便於備份和復原。

ETCD 使用 2379 Port

小結

介紹完 Control Plane 的主要組件，不難發現當中少了誰就一定會出大事，所以在實務上會執行各種策略去降低風險。除上述各組件採取的機制，也會採用部署多個 Control Plane （通常是 3 或 5）以保證它的高可用性。

Control Plane 的舊稱為 Master Node，不過這個標籤已棄用囉