當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成功得太徹底,其協調模型現在承載了所有人的自動化習慣"的問題。
平臺工程時代讓控制器顯得很廉價。需要策略?加個控制器。需要同步?加個控制器。
特別聲明:以上內容(如有圖片或視頻亦包括在內)為自媒體平臺“網易號”用戶上傳并發布,本平臺僅提供信息存儲服務。
Notice: The content above (including the pictures and videos if any) is uploaded and posted by a user of NetEase Hao, which is a social media platform and only provides information storage services.