Kubernetes控制平面正在變成數據分發系統

當Kubernetes社區討論擴展性時，話題通常圍繞節點數、Pod數、集群規模，以及etcd能撐多久才會有人在會議上說"也許我們該拆分這東西"。

但v1.36版本引入的server-side sharded list and watch，指向了一個更隱蔽的問題：控制平面正在成為數據分發系統，難點不再只是存儲對象，而是如何向每個想要持續感知變化的客戶端推送數據。

這聽起來很無聊。但無聊的基礎設施原語，恰恰是架構真實需求的泄露口。

Kubernetes的強大很大程度上源于watch模型。控制器不會不斷詢問"發生了什么"，而是先list當前狀態，再watch變化。API server成為眾多小循環的協調點，這些循環試圖將現實推向期望狀態。

這個模型優雅，且無處不在。

部署控制器watch Deployments和ReplicaSets。自動擴縮容器watch工作負載和指標。策略引擎watch資源。GitOps控制器watch集群狀態。服務網格watch端點和配置。可觀測棧watch各種對象。自定義控制器watch。AI平臺控制器watch。

最終，集群里的"watchers"比"users"還多。

成熟的Kubernetes環境不只是工作負載的堆積，而是大量客戶端試圖在本地維護集群的心理模型。

我們仍稱之為Kubernetes API server，技術上正確，但不完整。

小規模時，它像API：發請求，得響應。大規模時，它更像帶強一致性預期、歷史狀態、授權檢查、扇出壓力和固執數據模型的共享事件分發系統。

這就是server-side sharded list/watch的意義所在。

簡單版本：服務器不再強制客戶端通過單一巨大流來list或watch大資源集，而是將工作拆分為分片。客戶端消費數據分區，系統更智能地分配負載。

具體實現細節不如功能背后的承認重要：大型Kubernetes集群在watch層存在數據規模問題。

不是"Kubernetes壞了"的問題。更像是"Kubernetes成功得太徹底，其協調模型現在承載了所有人的自動化習慣"的問題。

平臺工程時代讓控制器顯得很廉價。需要策略？加個控制器。需要同步？加個控制器。