第 2 課：Kubernetes 架構

程式碼區塊_1

Kube-apiserver 是無狀態的 — 它不儲存狀態，只讀取/寫入 etcd。這允許透過在負載平衡器後面運行多個 API 伺服器實例來進行水平擴展。

2.2。 etcd — 叢集記憶體

Kubernetes 中 etcd 的重要功能：

___HTMLTAG_70__HTMLTAG_71___強一致性：Raft 確保 etcd 叢集中的每個節點都同意該值 — 無「腦裂」 ___HTMLTAG_74__HTMLTAG_75___Watch API：客戶端（包括 kube-apiserver）可以監視關鍵變化－這是 Kubernetes 做出反應的核心機制 ___HTMLTAG_78__HTMLTAG_79___法定人數要求：需要多數 (⌊n/2⌋ + 1) 個活動節點才能使叢集運作。 With 3 etcd nodes, 1 node can be tolerated;有 5 個節點，可以承受失去 2 個節點 ___HTMLTAG_82__HTMLTAG_83___etcd v3：使用 etcd 3.5+ 的 Kubernetes 1.32，具有效能和基於租賃的改進 TTL

程式碼區塊_2

___HTMLTAG_87__HTMLTAG_88___重要說明：必須定期備份etcd資料。 Loss of etcd = loss of entire cluster state.在託管 Kubernetes 中，雲端供應商自行處理此問題。

2.3。 kube-scheduler — Pod 分配演算法

___HTMLTAG_93__HTMLTAG_94___kube-scheduler 負責決定哪個 Pod 會在哪個節點上運作。當您建立 Pod 時，kube-apiserver 會將 Pod 寫入 etcd，狀態為 Pending（尚未指派節點）。調度程序監視這些 Pod 並找到匹配的節點。

調度過程包含兩個步驟：

___HTMLTAG_102__HTMLTAG_103___過濾（謂詞）：消除不符合要求的節點－CPU/記憶體不足、Pod 不能容忍的污點節點、不匹配的節點選擇器、Pod 親和/反親和約束... ___HTMLTAG_106__HTMLTAG_107___評分（優先權）：根據許多標準對剩餘節點進行評分 — 使用資源最少的節點、已經擁有必要映像的節點（減少拉取時間）、均勻分配 Pod 副本的節點...

程式碼區塊_3

Kubernetes 1.32+ 支援 調度程序設定檔 — 允許使用不同的插件集配置多個調度設定文件，適用於同一叢集中的不同工作負載。

2.4。 kube-controller-manager — 控制迴圈

___HTMLTAG_117__HTMLTAG_118___kube-controller-manager 執行一組控制器 — 每個控制器都是一個控制循環，用於監視叢集的當前狀態並採取措施將其返回所需狀態。這是 協調循環模式 的實作 — Kubernetes 聲明模型的核心。

最重要的控制器：

___HTMLTAG_126__HTMLTAG_127___ReplicaSet Controller：確保 Pod 副本數量符合規格。如果 Pod 死亡，控制器會建立一個新 Pod。 ___HTMLTAG_130__HTMLTAG_131___部署控制器：管理部署的捲動更新，建立/刪除副本集 ___HTMLTAG_134__HTMLTAG_135___EndpointSlice 控制器：當 Pod 就緒/未就緒時更新 EndpointSlices（取代舊的 Endpoints 控制器 — Endpoints API 已棄用 K8s 1.33） ___HTMLTAG_138__HTMLTAG_139___命名空間控制器：刪除命名空間時清理資源 ___HTMLTAG_142__HTMLTAG_143___ServiceAccount 控制器：為每個新命名空間自動建立預設 ServiceAccount ___HTMLTAG_146__HTMLTAG_147___節點控制器：監控節點運作狀況、無法存取時污染節點、寬限期後驅逐 Pod ___HTMLTAG_150__HTMLTAG_151___作業控制器：管理批次作業，確保完成 ___HTMLTAG_154__HTMLTAG_155___CronJob 控制器：依據 cron 運算式排程作業

程式碼區塊_4

2.5。雲端控制器管理器

與 kube-controller-manager 分開，cloud-controller-manager包含與雲端提供者 API 整合的控制器：

___HTMLTAG_166__HTMLTAG_167___節點控制器：檢查雲端供應商以確認節點存在，取得雲端區域、實例類型等元資料 ___HTMLTAG_170__HTMLTAG_171___路由控制器：在雲端基礎架構中設定網路路由 ___HTMLTAG_174__HTMLTAG_175___服務控制器：建立服務類型 LoadBalancer 時建立/更新/刪除雲端負載平衡器

在本地或裸機使用時，不需要雲端控制器管理器。

3。工作節點組件

3.1。 kubelet — 每個節點的代理程式

___HTMLTAG_185__HTMLTAG_186___kubelet 是在每個工作節點上執行的代理程式。 kubelet 的工作是接收 PodSpec 並確保其中描述的容器正在運作且健康。

Kubelet 依照下列機制運作：

• 觀察 kube-apiserver 以接收指派給您的節點的 PodSpec
• 透過 CRI（容器執行時間介面） — 標準化 gRPC 介面
與執行時間容器通信
• 將節點狀態和 Pod 狀態回報給 API 伺服器
• 運作活躍/準備/啟動探針
• 安裝磁碟區、拉取映像、設定網路命名空間__HTMLTAG_203___
• 透過 cgroup v2 管理資源限制

程式碼區塊_5

3.2。 kube-proxy — 網路規則引擎（nftables 模式）

kube-代理模式的歷史：

___HTMLTAG_216__HTMLTAG_217___iptables 模式（舊版）：使用 iptables 規則鏈。問題：有數千個服務，iptables 規則非常大且更新緩慢 ___HTMLTAG_220__HTMLTAG_221___IPVS 模式：核心中的第 4 層負載平衡器。 IPVS 模式 在 Kubernetes 1.35 中已棄用 並將在未來刪除 ___HTMLTAG_226__HTMLTAG_227___nftables 模式（自 K8s 1.31 以來的當前預設值）：使用 nftables — 新的 Linux 框架來取代 iptables。更有效率、更容易調試、更好地支援現代核心

程式碼區塊_6

___HTMLTAG_231__HTMLTAG_232___注意：許多現代叢集使用Cilium等CNI外掛程式來完全取代kube-proxy（Cilium的kube-proxy取代使用eBPF），提供更好的效能和更高的可觀察性。

3.3。容器運行時 —containerd 2.0

容器運行時是實際建立和運行容器的元件。 Kubernetes 透過 CRI（容器執行時間介面）.

___HTMLTAG_241__HTMLTAG_242___為什麼不使用 Docker？ HTMLTAG_243__HTMLTAG_244

Docker Engine 在版本 1.24 中已從 Kubernetes 中刪除（dockershim 已刪除）。 Docker 本身並不會實作 CRI — Kubernetes 必須使用填充層 (dockershim) 進行橋接。相反：

___HTMLTAG_248__HTMLTAG_249___containerd：官方執行階段，從 Docker 專案分叉，本機 CRI 支援 ___HTMLTAG_252__HTMLTAG_253___CRI-O：更輕的運行時，專注於 Kubernetes 用例

___HTMLTAG_257__HTMLTAG_258___containerd 2.0（2024 年發布）帶來了重要改進：

• 對 cgroup v2 的本機支援（從 Kubernetes 1.36 開始需要）
• 使用 Sandbox API 改進了沙箱管理
• 更有效率的影像管理傳輸服務
• NRI（節點資源介面）插件，用於擴充自訂
• Zstd 影像壓縮支援 — 拉速顯著加快
• 使用 Windows 容器效果較好

程式碼區塊_7

3.4。 cgroup v2 — 現代資源管理

___HTMLTAG_279__HTMLTAG_280___cgroups（控制群組） 是一項 Linux 核心功能，用於限制、優先權和測量進程群組的資源使用情況。 Kubernetes 使用 cgroup 對 Pod 和容器強制執行 CPU/記憶體限制。

HTMLTAG_284__HTMLTAG_285___cgroup v1：舊版，每個資源都有自己的層次結構（cpu、記憶體、blkio...），複雜且有許多邊緣情況__HTMLTAG_287 ___HTMLTAG_288__HTMLTAG_289___cgroup v2：統一層次結構、單一 cgroup 樹、使用 memory.oom.group 改進記憶體管理、壓力失速資訊 (PSI)

___HTMLTAG_293__HTMLTAG_294___重要時間表：

• Kubernetes 1.25：cgroup v2 穩定
• Kubernetes 1.35：cgroup v1 已棄用___HTMLTAG_302__HTMLTAG_303___
• Kubernetes 1.36：cgroup v2 必需，cgroup v1已刪除
• Ubuntu 22.04+、RHEL 9+、Debian 11+ 預設使用 cgroup v2

程式碼區塊_8

4。 Pod 建立流程：從 kubectl 到容器

為了以實用的方式理解該架構，讓我們追蹤執行 kubectl apply -f pod.yaml:

時發生的流程

程式碼區塊_9

整個過程，從 kubectl apply 到容器實際運行，通常需要 2-10 秒，取決於映像是否已快取以及網路速度。

5。重要附加元件

5.1。 CoreDNS — 服務發現

___HTMLTAG_326__HTMLTAG_327___CoreDNS 是運行在叢集中的 DNS 伺服器，允許 Pod 透過網域名稱而不是 IP 來查找 Services 和其他 Pod：

命名空間 my-ns 中的
• Service my-svc 可以透過以下方式解析： my-svc.my-ns.svc.cluster.local___HTMLTAG_337__HTMLTAG_338___
• Pod 到 Pod DNS：pod-ip.namespace.pod.cluster.local___HTMLTAG_341__HTMLTAG_342___
• CoreDNS 是必要的 Kubernetes 附加元件 — 如果沒有 DNS，叢集就無法正常運作