Kubernetes 架構：組件、控制流程與故障邊界

Kubernetes 架構由管理叢集狀態的控制平面，以及運行容器化工作負載的工作節點組成。用户通過 API 提交期望狀態，API Server 處理請求，controller、scheduler 和 kubelet 根據 API 中的狀態履行各自職責；容器執行環境則執行 kubelet 發來的 CRI 請求。它並不是一台“主服務器”按固定順序指揮所有組件的流水線。

本文解釋組件分工、從 API 到 Pod 的控制過程，以及怎樣區分不同故障邊界。依據是 Kubernetes 官方文檔，不是對特定雲服務內部網絡的實測。文章由觀測雲編輯部編寫；觀測雲的產品文檔僅用於説明採集路徑，不能代替 Kubernetes 機制證據。文中的三個實驗方案均未執行，沒有實測輸出或恢復時間。

若還不熟悉 Pod、聲明式管理以及 Kubernetes 的適用條件，可以先看 Kubernetes 是什麼。

邏輯架構不等於物理拓撲

官方組件文檔將叢集描述為控制平面與一個或多個工作節點。自建叢集可能由團隊管理各組件的部署、升級及恢復；託管服務則由供應商承擔其中一部分。組件可以共用機器，也可以跨機器或可用區分佈。

網絡、存儲和雲資源的連接方式取決於插件及部署形式。因此，本文討論的是邏輯職責，不把一個概念圖當作所有 EKS、GKE、AKS 或私有叢集的唯一物理路徑。責任分界仍應以實際服務文檔和合同為準。

控制平面：保存意圖並持續協調

API Server 是共享狀態的入口，不是完成所有任務的中央執行器。控制器反覆觀察狀態並請求變更，調度器和 kubelet 也通過 API 獨立工作。不能將這一過程理解成一個長同步函數。

etcd 也不是任何應用程式或組件都可以直接讀寫的通用業務數據庫。訪問權限、備份和恢復，應圍繞其保存叢集 API 狀態的職責單獨設計。

工作節點：把 Pod 聲明變成容器執行

容器執行環境文檔説明了 CRI 邊界。Docker Engine 本身不實現 CRI，內置 dockershim 已於 Kubernetes v1.24 移除。不要把某一種執行環境或 socket 路徑當作所有版本的永久默認值。

kubelet 只執行已經設定的探針。readiness 成功不代表數據一致性、外部依賴和整條用户旅程都正確；沒有設定應用程式探針時，Ready 更不能證明已經執行過業務檢查。

從 API 請求到運行中的 Pod

下面是提交 Deployment 後的概念過程，各組件的重試與協調可以異步發生，不是網絡包的精確順序。

1. 客户端通過 kubectl 或 API 提交工作負載聲明，API Server 處理請求。
2. 被接受的 API 狀態保存在 etcd；不是客户端繞過 API 直接寫 etcd。
3. 工作負載控制器觀察期望和實際狀態，按需調整 ReplicaSet 與 Pod 對象。
4. 調度器發現尚未分配節點的 Pod，根據資源請求、約束、策略和可用節點選擇放置位置。
5. 目標節點的 kubelet 觀察分配給自己的 Pod，通過 CRI 請求執行環境準備並運行容器。
6. kubelet 更新容器狀態及 Pod 條件，執行探針；其他組件和用户繼續通過 API 觀察狀態。

客户端 → kube-apiserver ↔ etcd（API 狀態）
                 ↑
       ┌─────────┼──────────┐
       │         │          │
   controller scheduler   kubelet
   觀察/寫入   觀察/綁定    觀察分配的 Pod/更新狀態
                            │
                            ▼
                   CRI 兼容執行環境 → 容器

這是一幅根據官方機制整理的邏輯圖，不是實驗抓包結果。排障時應把對象變化、事件、組件日誌、指標及執行層證據放到同一時間軸，不能只憑一次 status 截圖就認定某個組件有問題。

工作負載與訪問路徑要分層看

Deployment通過 ReplicaSet 管理 Pod 的聲明式更新；三個名字不是同一個對象的不同叫法。Service提供訪問抽象，EndpointSlice則表示後端端點及其條件。

有 endpoint 不等於請求成功，應用程式出現 5xx 也不等於控制平面故障。對象身份與時間必須對應，才能逐層驗證假設。

通信與安全邊界

控制平面與節點通信文檔區分了節點訪問 API，以及 API Server 訪問 kubelet、Pod 或 Service 的路徑。

• kubelet 和使用 Kubernetes API 的節點組件與 API Server 通信，需要認證、授權及傳輸保護。
• 容器執行環境通常通過本地 CRI 接收 kubelet 請求，不能據此認為執行環境直接 watch Kubernetes API。
• 登錄成功不等於擁有所有對象權限；認證和授權需要分別檢查。
• kubelet API、API Server 到節點的路徑、隧道及雲供應商連接方式，隨部署而變。
• 端口、證書、ServiceAccount、網絡策略及加固步驟，應使用目標版本的官方設定文檔。

任何實驗記錄都應控制原始憑證的訪問，並在公開前去除 kubeconfig、token、證書私鑰、客户數據及內部地址。本篇不要求把這些資料複製到文章或截圖中。

高可用和故障域不是一回事

多個控制平面實例，不會自動讓業務具備高可用。kubeadm 高可用拓撲討論堆疊與外置 etcd；多可用區文檔討論副本如何跨故障域分佈。需要分別檢查：

Pending 不只意味着等待調度，也包括節點已經分配後的映像下載及容器準備。ResourceQuota超額則可能讓 API 以 403 Forbidden 拒絕創建，連待調度 Pod 都沒有。兩種情況的檢查入口不同。

這張表是調查起點，不是自動根因樹。同一症狀可以跨多個邊界出現；恢復時間和可用性承諾還需要合同或固定環境的測試支持。

用可觀測性連接這些層次

官方可觀測性文檔説明了指標、日誌及鏈路的作用；集中日誌也需要在容器生命週期之外設計收集與保留。

調查時先固定時間、叢集、namespace、工作負載、Pod UID 與節點，然後讀取對象狀態和 owner 關係，尋找協調差異。事件可以提示調度、拉映像或探針變化，但不是單獨的根因證明。再用相應組件的日誌與指標縮小範圍，最後檢查應用程式請求和用户結果是否隨修復恢復。

觀測雲的 Kubernetes 集成、Prometheus 自動發現及 ServiceMonitor / PodMonitor 支持字段可作為採集設定入口。它們説明產品公開支持的路徑，具體權限、版本、字段映射及限制仍須在目標環境驗證，不能視作任意叢集都已實測通過。

三個尚未執行的故障實驗

實驗旨在區分故障邊界，不用於比較供應商性能，也不能證明觀測雲自動定位了原因。三個方案都沒有執行結果、截圖或耗時記錄。

執行前的共同條件

使用一次性的非生產 kind 或同類叢集，固定 Kubernetes 補丁版本、kind、執行環境、CNI、宿主機系統與架構。對工作負載映像的來源和 digest、清單、資源限制與探針做版本管理。保存命令、原始輸出、退出碼、時間、對象 YAML、事件、組件證據及清理結果；公開副本應脱敏，再由另一位工程師復現。

實驗一：調度邊界

計劃提交要求不存在節點標籤或無法滿足約束的 Pod，收集 phase、條件、調度事件和可選節點資訊。修正後再次觀察綁定。要區分“還未選中節點”和“已選中節點但執行失敗”。本文沒有實際觀察 Pending 狀態、具體事件或綁定耗時。

實驗二：節點與執行環境邊界

計劃使用不存在的映像 digest 或 tag，收集容器狀態、事件、kubelet、執行環境及倉庫請求證據，再恢復已知可用映像。已完成調度不意味着已經拉取並運行映像。本文沒有實測 ErrImagePull、ImagePullBackOff 或其他具體狀態。

實驗三：readiness 與 EndpointSlice 邊界

計劃部署固定失敗的 readiness probe 與 Service，隨後修正探針。記錄 Pod Ready 條件、探針結果、selector、EndpointSlice 地址及 ready、serving、terminating，同時記錄 Service 的 publishNotReadyAddresses 與實際請求。

容器運行、Pod 就緒、地址存在、流量資格及業務響應是五種不同事實。未就緒 Pod 可以留在 EndpointSlice，開啓 publishNotReadyAddresses 時端點還可能被標記為 ready。本文沒有測得端點變化順序或恢復時間。

在原始輸出與第二次復現記錄齊備前，這些實驗只能作為待執行方法，不能改寫為“已測”“已驗證”或某產品的優勢證明。官方文檔支持機制解釋，實驗只能支持特定環境中實際觀察到的結果。

繼續學習與實施

定義和適用邊界見 Kubernetes 是什麼。深入設定應使用當前官方的架構、組件及目標版本的安裝、安全文檔。

若要評估觀測雲在生產環境中的監控路徑，可以參考Kubernetes 監控方案，再以一個測試叢集驗證對象、指標、日誌、權限與缺失數據。產品説明和概念解釋都不能替代這一步。

一手資料

2026 年 10 月 27 日按官方文檔復核技術機制，未執行上述實驗。

• Kubernetes 架構、組件與控制器
• Scheduler、Pod 生命週期和容器執行環境
• Deployment、Service、EndpointSlice與探針
• ResourceQuota、控制平面與節點通信
• 高可用拓撲、跨可用區運行、可觀測性
• CNCF Kubernetes 項目