先前提到 API Server、Scheduler 與 Controller Manager，但一直沒有深入探究 Kubernetes 怎麼記得自己目前有哪些 Deployment、Pod、Service、ConfigMap 與 Secret 的。

這篇就要來聊聊 etcd。它是 Control Plane 使用的 key-value 儲存資料庫，保存 Kubernetes API Server 的資料。

宣告、狀態與 etcd

Kubernetes object 會有兩個很重要的狀態：

• spec：我們希望它成為什麼樣子，也就是期望狀態。
• status：Kubernetes 元件持續回報與更新的實際狀態。

例如 Deployment 的 spec.replicas: 3 代表希望有三個 Pod；Deployment 的 status 則會反映目前是否已有三個可用 Pod、更新是否完成等結果。

kubectl apply 不是叫 Kubernetes 「立刻執行一段腳本」。它是透過 API Server 寫入一份期望狀態；之後 Controller 才會不斷比對期望與實際狀態，做出需要的動作。

API Server 是 etcd 的操作者

運作流程是這樣：

1. kubectl、CI/CD 或其他程式呼叫 Kubernetes API。
2. API Server 進行驗證、授權與 admission 等處理。
3. API Server 將 Kubernetes object 資料持久化到 etcd。
4. Controller、Scheduler、kubelet 與 kubectl 都透過 API Server 讀取、watch 或更新這些 object。

例如 kubelet 發現自己的 Pod 已經 Running，不會直接寫入 etcd；它會向 API Server 回報 Pod status，再由 API Server 持久化。這也是 API Server 為什麼是整個叢集的統一入口：它讓驗證、權限、審計與資料一致性不會被每個元件各自繞過。

etcd 裡有什麼？

這些 object 的 metadata、spec、status 與關聯資訊，讓 Kubernetes 能重建「目前叢集已宣告什麼、觀察到什麼、接下來需要做什麼」的全貌。

但 etcd 不是下列資料的保存位置：

• container image 本體：image 存在 registry 或 Node 的 Runtime cache。
• container log：通常在 Node 上產生，再由 logging 系統收集。
• 應用程式業務資料：應使用資料庫、物件儲存或適當的持久化儲存系統。

為什麼 etcd 能讓 Kubernetes 持續收斂狀態？

假設 Deployment 希望維持三個 Pod。這個期望會以 Deployment object 保存；ReplicaSet 與 Pod 的實際數量、狀態也會持續更新。Deployment Controller 與 ReplicaSet Controller 透過 API Server watch 這些變化：

text
期望：ReplicaSet 需要 3 個受自己控制的 Pod
目前：只剩 2 個受自己控制的 Pod
↓
ReplicaSet Controller 看見差異
↓
建立新的 Pod object
↓
Scheduler、kubelet 執行並回報狀態
↓
目前：受控制的 Pod 數回到 3

Pod 是否 Running、Ready 或 Available，則是另一層 status，以及 Probe／Deployment rollout 會判斷的資訊。

這就是前面一直提到的「收斂」：不是一次性執行完就結束，而是根據保存下來的期望與最新觀察結果，持續把差異縮小。

因此 kubectl apply 成功只表示 API Server 接受並保存了宣告，不代表應用一定已經 Ready。後續仍要查看 Deployment、Pod、Event 與 Probe 狀態，才能知道控制迴路有沒有真的完成。

Secret 與 etcd

Day 12 提到 Secret 的 data 是 Base64 編碼。Secret 也是 Kubernetes object，因此會透過 API Server 被保存到 etcd；Base64 不會因為資料進了 etcd 就突然變成加密。

叢集若要保護 etcd 中的敏感資料，必須額外設定 encryption at rest，並搭配 RBAC、備份保護、金鑰管理與最小權限。這也是為什麼不能把「我用了 Secret」當作成「資料從此絕對安全」。

為什麼 etcd 的高可用與備份很重要？

etcd 保存的是 Kubernetes Control Plane 的核心狀態。若資料遺失或不一致，叢集可能無法正確得知有哪些 Workload、權限與設定需要維持。

正式環境通常會考慮多顆 etcd、高可用拓撲、定期備份與還原演練。不過 etcd 維運與還原會直接影響整個叢集，所以實際上在操作時，還是得先與所有系統負責人溝通好，避免發生短暫意外異常問題。

還是有發生過 Velero 還原備份不順利的時候

今日結論

etcd 保存 Kubernetes API Server 的資料，讓 Kubernetes 能持續比較「我們宣告的狀態」與「目前觀察到的狀態」。API Server 是各元件存取這些資料的正式入口；Controller、Scheduler 與 kubelet 不需要直接讀寫 etcd。

至此，從 Control Plane、Worker Node、Pod、Deployment、Service、ConfigMap、Secret 到 etcd 的基礎鏈條已經串起來。後續再談資源、發布、儲存與入口流量時，就能理解這些 YAML 撰寫的概念，或是可以如何 debug。

參考資料

• Kubernetes：Kubernetes Components
• Kubernetes：Objects In Kubernetes
• Kubernetes：Operating etcd Clusters for Kubernetes
• Kubernetes：Encrypting Confidential Data at Rest