前言

在 K8s 的世界中，所有元件都會活在 Cluster 這個單位裡。一個 Cluster 可以被分為 Control Plane 和 Data Plane 兩個部分，其中 Data Plane 包含多個 worker nodes，而所有服務和伺服器都以 pod 為單位在 node 內執行。K8s 作為一個容器編排工具，Cluster 中負責管理調度容器的角色是 Control Plane。為了保持高可用性，在正式環境中的 Control Plane 通常也會像 data plane 一樣，需要分散在多台電腦上執行，以確保高容錯和高可用性。

Control Plane 控制平面

Control plane 通常會跑在指定機器上，不會讓其他容器使用該機器的資源。為實現高可用性（HA）以避免單點故障，可部署多個 control plane 實例。詳細的高可用性配置可參考 kubeadm 官方文件。以下是在 Control Plane 裡面運作的各種元件，以及他們的職責：

• API Server：向 workload 暴露 K8s API，是 workload 與 control plane 的溝通橋樑，負責處理所有與集群的互動請求。
  • 定義各種 resource 的新增、刪除和修改方式
  • 使用 RESTful API 進行操作
  • 唯一可直接操作 Etcd 的元件
• Etcd：一種 NoSQL 資料庫，以 key-value 格式儲存整個 Cluster 的狀態。
  • 讓 controller 們可以根據設定現狀，比對與目標設定之間的差異
  • 因為紀錄了各個版本的狀態設定，使 cluster 能快速回滾（rollback）
  • 詳細互動過程可以參考： Kubernetes:kube-apiserver 和 etcd 的交互
    
• Controller Manager：在 control plane 中負責執行、管理所有 controller 的 process
  • Controller：職責是讓 cluster 的當前狀態（current state）與期望狀態（desired state）相同
  • Control via API Server：如 Job controller 會指示 API server 在 cluster 中建立新的 pods。例如：ReplicaSet Controller、Job Controller
  • Direct control：當 controller 需與 cluster 外部資源互動時，先從 API server 獲取外部資源的期望狀態，再直接與外部資源溝通，使其符合期望狀態。例如：Ingress Controller（需與外部的反向代理或負載平衡器互動）、External DNS Controller（需與外部 DNS 提供者互動）

Helm chart 中的 CRD controller 不會由 Controller Manager 管理。Controller Manager 僅負責 K8s 原生的 controllerHelm chart 中的 CRD controller 不會由 Controller Manager 管理。Controller Manager 僅負責 K8s 原生的 controller

• Cloud Controller Manager：管理需與 Cloud Provider 互動的物件。有 cloud provider 的情境通常是「Control Plane」放在雲端時；地端 K8s 則不會有 cloud-controller-manager。
• Scheduler：檢查是否有 pod 需要建立，並根據可用資源和設定，將適當的 Node 指派給新 pod 執行。會根據 node 狀態和 label selector 的指定進行指派。

Data Plane

介紹完 control plane 之後，我們也會需要知道 data plane 的各個元件是如何與 control plane 這個「大腦」進行溝通，來達到實際的運作。因此我們會在每個 Node 身上使用到以下三種 component，來執行 control plane 這個大腦所發出的指令：

• Kubelet：在 cluster 中每個 node 上執行的 agent，負責接收 API Server 的指令並回報狀態。對 pod 進行新增、刪除、修改、健康檢查和監控，由 c-advisor 收集這些資料。
• Kube-proxy：使 cluster 內的 pods 能互相連接和溝通，就像一個小型社交網路經理。我們在兩天後會針對網路架構進行深入的介紹。
  • 細節可參考：
    1. A Guide to the Kubernetes Networking Model
    2. 深入理解 Kubernetes 中的 kube-proxy
• Container Runtime：如 Docker 或 containerd，負責實際執行容器化應用，是整個系統運作上真正的主幹。CRI 深入介紹可以參考這篇文章：Journey From Containerization To Orchestration And Beyond

為什麼要使用 EKS？

在自建 K8s 環境時，Control Plane 的高可用性與維運作業（如 etcd 備份、API Server 負載均衡、憑證更新、版本升級）都是極為複雜且高風險的工作。但在 EKS 上，這些 Control Plane 元件（API Server、etcd、Controller Manager、Scheduler）都由 AWS 全託管，並自動維護高可用性的設置，代表我們可以省去繁瑣的運維成本，專注於 Data Plane 與應用層（Pod、Service、Deployment 等）的設計與優化。這也是多數團隊選擇 EKS 的核心原因之一。為降低管理成本，專案採用 EKS 的託管 Control Plane（畢竟誰想自己管理這麼複雜的東西呢）。如需自行建立 Control Plane，可參考以下文章：

1. Kubernetes 的架構與抉擇
2. Creating Highly Available Clusters with kubeadm
   

明天的文章，我們會繼續接著介紹 K8s 應用層的各種元件，像是 pod / deployment / service 等等。介紹完這些基本元件後，會再來介紹 K8s cluster 內的網路架構基礎。