Day5：理解 Kubernetes 的運行與核心資源

17th鐵人賽

kenneth1003

2025-09-18 22:54:58

66 瀏覽

分享至

1. 前言

今天開始的連續三天，我想和大家聊聊 Kubernetes（K8S）。
在之前工作的公司做專案部署時，多少都會碰到些 k8s 的配置和管理後台，
我對這個技術一直都蠻有興趣的，我覺得它厲害的地方在於：

透過宣告式的方式定義服務
可以彈性地 Rollback 與 Scale
能清楚監控所有服務狀態
多個服務能共存在同一個 Cluster

當時的我認為，有種鄉巴佬進城，大開眼界的感覺，覺得這樣的部署模式非常現代化，如果我有機會打造自己的大型服務，我一定要玩玩看。
直到現在，有機會把 K8S 真正用在公司架構上時，所以我更有動機來深入了解它。如果我們能將現有的服務遷移到 k8s，可能能未我們帶來很多的好處：

提高彈性與穩定性
更一致的監控、擴展、日誌管理
滿足工程師對於乾淨架構的渴望（誤

所以今天的目標，就是為 K8S 打下基礎，來試圖喚醒我腦中殘存的 k8s 記憶，
試著重新理解它的架構、基本資源物件、以及如何實際部署服務。

2. Kubernetes 架構介紹

一句話總結：Control Plane（Master） 負責「決策 + 記錄狀態」，Worker Node 負責「真正跑工作」。
下面每節都有一個「小例子」幫你把流程連起來。

2.1 Master（Control Plane）與 Node

角色分工

Control Plane（又稱 Master Node）：整個叢集的「大腦」
- API Server：所有請求的入口（kubectl / controllers / kubelet 都會來這裡）。
  - 功能：認證、授權、資料驗證、把「期望狀態」寫進 etcd。
- Scheduler：幫「待排程的 Pod」挑一台最合適的 Node。
- Controller Manager：一群控制器的集合（Deployment、ReplicaSet、Node、EndpointSlice…），負責「持續對帳（Reconcile）」讓實際狀態逼近期望狀態。
Worker Node：叢集的「工作節點」
- 實際啟動容器（Pod）並提供計算、網路、儲存資源。
- 內含 kubelet、kube-proxy 與容器執行時（containerd/CRI-O）。

小例子：從 `kubectl apply` 到 Pod 跑起來

執行：kubectl apply -f deploy.yaml 後。
kubectl 呼叫 API Server，通過認證授權後，API Server 驗證 YAML 並把「期望狀態」寫到 etcd。
Controller Manager 中的 Deployment/ReplicaSet 控制器發現「需要 3 個 Pod」，建立 3 個 未排程的 Pod 物件。
Scheduler 監看（watch）到這些待排程的 Pod，根據資源與規則挑選合適的 Node，把 nodeName 寫回 Pod 規格。
目標 Node 上的 kubelet 監看到「有屬於我的 Pod」，透過 CRI 叫 containerd 拉 Image、建容器、掛卷(Volume)、設定網路。
Pod 就緒（Ready）後，服務拓撲（如 kube-proxy 的規則或 CNI 的資料面）更新，服務能導流到新 Pod。

2.2 etcd

定位：Kubernetes 的Source of Truth，分散式 key-value 資料庫。
特性：一致性為先（Raft 共識）、支援版本化、watch 變更、快照/壓縮（compaction）。
儲存內容：幾乎所有叢集狀態——Deployment、ReplicaSet、StatefulSet、DaemonSet、Pod、Service、ConfigMap、Secret、Endpoints/EndpointSlice、Node 資訊等。

小例子：副本數(Replicas) 自我修復

你有一個 Deployment 要求 replicas: 3，其中一個 Pod 當機。
流程：
1. kubelet 回報 Pod 失敗事件。
2. Controller Manager 監看到 etcd 裡的實際副本數只剩 2（期望=3，實際=2）。
3. Controller 建立一個新 Pod 物件，Scheduler 幫它挑一個 Node。
4. 新 Pod 啟動，etcd 的狀態更新回到 3/3，系統恢復一致。

2.3 Node 組件

kubelet（每台 Node 上的「執行經理」）

職責：
- 監看 API Server 上「屬於本機的 Pod」；若是 Static Pod 則直接由本機清單啟動。
- 透過 CRI 呼叫容器執行時（containerd/CRI-O）建立/刪除容器。
- 回報 Node 狀態、Pod 狀態（Ready、Liveness/Readiness/Startup Probes）。
- 逐出（Eviction）：資源壓力大時（如磁碟/記憶體不足）逐出低優先級 Pod。
常見排錯：
- 看 kubectl describe node <NODE> 的 Conditions。
- 讀 Pod 事件與 kubelet 日誌（不同平台差異）。

kube-proxy（每台 Node 上的「網路代理」）

職責：把進入 Service 的流量導到對應的後端 Pod。
運作模式：iptables 或 ipvs，在 Node 上安裝對應的轉送規則。
對應 Service 型別：
- ClusterIP：叢集內部虛擬 IP，僅內部可訪問。
- NodePort：在每個 Node 開一個高埠（預設 30000–32767）對外服務。
- LoadBalancer：在雲上要求雲廠商建立 L4 LB，外網可達。
（配角）CNI 外掛（如 Calico/Flannel/Cilium）：負責 Pod 網路與跨 Node 可達性（路由/封包轉發/網安政策）。

簡單 ASCII 架構圖

+------------------------ Control Plane ------------------------+
|  API Server  |  Scheduler  |  Controller Manager  |  etcd    |
+--------------------------------------------------------------+
                         | watch / update
               --------------------------------
               v                              v
    +-------------------+           +-------------------+
    |   Worker Node A   |           |   Worker Node B   |
    |  kubelet          |           |  kubelet          |
    |  kube-proxy       |           |  kube-proxy       |
    |  Pods (A1,A2,...) |           |  Pods (B1,B2,...) |
    +-------------------+           +-------------------+

常見實務建議

etcd：至少 3 節點、定期快照備份與 compaction；Control Plane 與 etcd 分離可提高可靠性。
Scheduler：善用 labels/affinity/taints 做拓撲分散與資源隔離。
kubelet：設定適當的 probes 與資源 Requests/Limits，避免誤判或 OOM 風險。
kube-proxy/CNI：在高流量場景選擇 ipvs；如需網安政策可考慮 Calico/Cilium。

3. 基本資源物件

Kubernetes 的強大來自於它的資源抽象化。最常見的核心物件有：

Pod：最小的運行單位，一個或多個容器的集合，通常由 Deployment 等控制器來管理。
Deployment：管理 Pod 的副本數與版本更新，支援滾動更新與回滾，適合長期服務。
Service：為 Pod 提供穩定的網路入口，讓內部或外部能夠存取服務。
ConfigMap / Secret：儲存應用程式設定與敏感資訊，讓設定與程式碼解耦。

4. 容器排程與資源管理

Kubernetes 不只是跑 Pod，更要控制「怎麼跑」：

ReplicaSet：確保有正確數量的 Pod 存活，是 Deployment 的底層基礎。
滾動更新：逐步替換舊版本 Pod，確保不中斷服務；可搭配回滾機制。
Requests / Limits：定義 CPU 與記憶體的需求與上限，避免單一服務耗盡資源；同時影響 Pod 的排程與效能。

5. 結語

今天我們打下了 Kubernetes 的基礎，先理解了整體架構（Master、Node、etcd、kubelet、kube-proxy），再進一步掌握了 基本資源物件（Pod、Deployment、Service、ConfigMap、Secret），讓我們對 K8s 的核心運作有了初步的概念。

原本還想補充一個使用 minikube 的實作範例，不過我還有太多的碗還沒洗、衣服還沒晾，就留待之後的時間再慢慢補上。接下來兩天還會持續探索更多 K8s 主題，那就先到這裡 🤣