Kubernetes 是甚麼：從控制循環理解容器編排

Kubernetes 是管理容器化工作負載和服務的開源平台。你聲明希望使用的應用程式映像、副本數量和訪問方式，Kubernetes 的控制組件持續觀察叢集，讓實際狀態接近期望狀態。容器運行應用程式，Kubernetes 則管理應用程式周圍的部署、調度和更新過程。

理解這層分工，比記住組件名稱更重要。Kubernetes 可以調度 Pod、替換失敗的工作負載實例、協調滾動更新，並通過 Service 為不斷變化的 Pod 提供訪問抽象；它不會替你構建源代碼，也不能保證訂單金額正確、所有網絡和存儲故障都能自動恢復。它同樣不指定唯一的日誌或監控後端。官方概述同時説明了這些能力與邊界。

本文面向需要理解控制循環、選擇工作負載類型或判斷是否採用 Kubernetes 的工程師。文章由觀測雲編輯部依據官方文檔編寫，決策表和排障順序是編輯整理的方法，不是 Kubernetes 項目的官方採用標準。下文的故障實驗尚未執行，沒有實測恢復時間或產品性能結論。

先分清四件事

• 映像、容器和 Pod 不同。 映像封裝應用程式及依賴，容器是基於映像運行的實例。Pod 是 Kubernetes 創建和管理的最小可部署計算單元，可以包含一個或多個緊密協作、共享網絡與存儲上下文的容器。
• 期望狀態不等於業務正確。 控制器可以按聲明維持三個 Pod，卻不能據此證明支付、權限判斷或數據庫寫入正確。
• 自愈有條件。 重啓和替換受策略、健康檢查及資源條件約束。不斷重啓並不能修好代碼缺陷。
• Service 不是可用性證明。 穩定的訪問入口仍需要可用後端、有效路由、健康依賴和正確的應用程式響應。

從控制循環理解 Kubernetes

Kubernetes API 中的對象表達運行意圖。對於同時包含這兩個字段的對象，spec 描述期望狀態，status 記錄組件報告的實際狀態。控制組件持續處理二者的差異，具體語義見對象模型。

用户或自動化聲明期望狀態
          ↓
Kubernetes API 對象（spec）
          ↓
控制器觀察並調整實際狀態
          ↓
工作負載控制器按需創建或替換 Pod
          ↓
調度器為尚未分配 Node 的 Pod 選擇節點
          ↓
kubelet 通過容器執行環境運行容器
          ↓
status、條件和事件反映當前進展
          └────────→ 繼續協調

應用程式和用户結果 → 指標、日誌、鏈路與請求檢查
              → 團隊修正代碼、設定、策略或聲明

上半部分是平台協調過程，下半部分是團隊判斷業務是否正確的證據路徑。它們相關，但不是同一件事。圖中箭頭表示邏輯關係，不是所有網絡調用的固定時序。

例如，一個 Deployment 聲明 replicas: 3，當前只有兩個符合要求的 Pod，控制器可以創建第三個。若新 Pod 拉不到映像，期望副本數仍是三個，但可用副本可能不足。Kubernetes 會暴露差異，不會替你猜測正確的映像地址。

這些組件獨立地重複協調，而不是中央程序依次執行完一串步驟就結束。如果聲明本身有誤，反覆重試也需要團隊修改聲明才能解決。

控制平面、節點和 Pod

官方組件文檔將叢集分為控制平面和工作節點。實際部署位置及託管責任可能不同，但組件職責可以這樣理解。

Pod 中的容器共同調度到同一節點。Pod 本身是臨時實體；需要替換時，控制器通常創建新的 Pod，而不是把同一個 Pod 身份搬到另一台機器。詳見 Pod 生命週期。

託管 Kubernetes 可以轉移部分控制平面運維工作，但工作負載、身份權限、網絡策略、數據保護、遙測和事故響應的責任仍需按具體服務與合同劃分。

按生命週期選擇工作負載

工作負載資源的差異，主要在於身份、完成條件和運行方式。

數據庫放進 StatefulSet，不代表已經有備份；Agent 的 DaemonSet 顯示可用，也不代表數據已經到達存儲。先明確身份、數據、放置和失敗要求，再選資源類型。

Service 放在哪一層

Service描述一組邏輯後端及訪問策略，後端通常是 Pod。Pod 地址隨替換變化，客户端仍可以通過 Service 訪問。

排查訪問失敗時，需要同時核對 selector、Pod 標籤、EndpointSlice、readiness、端口和網絡路徑。Service 存在不能證明 DNS、網絡策略、負載均衡、TLS、數據庫或外部 API 都正常，更不能證明 HTTP 200 中的業務內容正確。

還要區分“EndpointSlice 有地址”和“後端可以接收普通流量”。未就緒的 Pod 仍可能出現在 EndpointSlice；ready、serving、terminating 是不同條件，publishNotReadyAddresses: true 還會影響 ready 的表示。具體依據見 EndpointSlice 文檔。

平台自動化之後，團隊還要負責什麼

自愈文檔説明了重啓策略、工作負載替換及存儲恢復的邊界。Deployment 文檔也明確：更新停滯時平台報告狀態，不能假定它必然自動回滾代碼和數據。

平台收斂與業務成功要分別驗證

下面是用於説明邊界的假設，不是實測結果。

因此，一次恢復確認至少需要平台證據與業務結果兩部分。前者包括 spec、status、條件、事件和 EndpointSlice，後者包括真實請求、業務不變量、日誌、鏈路、應用程式指標或用户體驗。

一個尚未執行的故障實驗

這個實驗計劃用於觀察：錯誤映像聲明怎樣造成期望與實際狀態的差異，恢復原映像後平台及請求結果如何變化。本文沒有運行或獨立復現此實驗，沒有可報告的輸出或恢復時間。

執行前應使用隔離的非生產叢集，並記錄 Kubernetes 精確補丁版本、kind 或同類工具版本、執行環境、宿主機系統及架構。所有映像使用不可變 digest，副本數和更新策略顯式寫入清單，保存清單校驗值、時間與命令版本。公開記錄不得包含憑證、kubeconfig、客户標識或內部地址。

實驗步驟如下，不能將預期當作結果：

1. 在隔離 namespace 中部署一個最小應用程式及 ClusterIP Service，用已核對的映像 digest，並定義包含預期響應內容的請求檢查。
2. 保存健康基線：清單、Deployment 狀態、Pod 條件、Service 與 EndpointSlice、事件、更新狀態、應用程式響應和退出碼。
3. 僅將 Deployment 映像改為故意不可用的測試引用，不同時改動探針、副本、selector 或 Service。
4. 記錄替代 Pod 無法就緒時的 Deployment、ReplicaSet、Pod 狀態與事件，以及實際請求結果。
5. 恢復原映像 digest，再記錄就緒狀態、EndpointSlice 與請求結果。不要預先認定請求必然中斷，舊的 Ready Pod 可能仍在服務。
6. 刪除實驗 namespace，確認叢集中沒有殘留資源或臨時憑證；需要保留的脱敏證據單獨存放。

常見的工作假設是出現 ErrImagePull 或 ImagePullBackOff，但倉庫策略、緩存、准入規則、執行環境和 Kubernetes 版本會影響具體表現，必須以實際記錄為準。

以下是擬使用的只讀採集命令，<recorded-pod-name> 需替換為當次記錄的 Pod 名稱：

kubectl -n k8s-definition-lab get deployment,replicaset,pod,service,endpointslice -o wide
kubectl -n k8s-definition-lab describe deployment demo
kubectl -n k8s-definition-lab describe pod <recorded-pod-name>
kubectl -n k8s-definition-lab get events --sort-by=.metadata.creationTimestamp
kubectl -n k8s-definition-lab rollout status deployment/demo --timeout=120s

這些命令不能證明業務正確。實驗還需要實際請求及預期響應、脱敏原始輸出，並由第二位工程師按相同輸入復現。若結果不同於假設，應報告差異。

為什麼仍然需要可觀測性

官方可觀測性文檔把組件與應用程式的指標、日誌和鏈路作為理解系統狀態的證據。組件能輸出信號，不等於叢集已經統一存儲、保留和關聯它們。

排障時可以分三層：叢集和節點證據用於判斷平台是否具備運行條件；對象和工作負載證據用於定位協調在哪裏受阻；應用程式和用户證據用於確認服務實際是否正確。Kubernetes 組件可以暴露 Prometheus 格式的指標，kube-state-metrics 提供對象狀態資訊，但端點權限、穩定性、採集與保留仍須設定。需要集中歷史日誌時，也必須將日誌保存到容器生命週期之外。

Pending 包括等待調度和調度後的映像下載，不能直接歸因於 scheduler。關聯三層證據時，應保留叢集、namespace、工作負載、Pod、容器、服務、環境、版本和 trace 上下文；不要為了關聯而採集憑證、個人資料或無限增長的用户標識。

是否值得采用 Kubernetes

下面是條件式決策表，不是打分排名。安全、數據恢復或責任歸屬的缺口，不能用其他項目的幾個“是”抵消。

當問題明確、資源模型合適、責任人到位，且關鍵安全與恢復條件可驗證時，再推進有界原型。若只增加控制平面、網絡、存儲和升級負擔，卻沒有解決實際問題，應比較更簡單的容器或應用程式平台。

部署地點也是選型的一部分。應逐項核對實際區域、可用區、數據路徑、流量費用、支持覆蓋和跨境要求。其他地區的服務説明，不能直接證明目標地區的可用性或合同條件；這些需要在具體供應商評估中確認。

下一步

理解組件後，可以繼續閲讀官方的組件、工作負載及 Service 文檔。

在觀測雲中實施採集時，先核對 Kubernetes 集成、Prometheus 自動發現與 ServiceMonitor / PodMonitor 支持字段。對象查看方式見容器基礎設施文檔。這些資料説明產品的設定路徑，不是所有環境都已驗證的證明。

需要評估商業監控方案時，再參考觀測雲 Kubernetes 監控，用自己的叢集核對權限、標籤、信號缺失、延遲和回滾。

資料依據

技術機制於 2026 年 10 月 27 日對照 Kubernetes 官方英文文檔複核；本文是文檔型指南，未運行上述實驗。

• Kubernetes 概述、對象和控制器
• Pod 生命週期、工作負載及 Deployment
• Service、EndpointSlice和探針
• 自愈邊界與可觀測性