● Covered by 1 source · 1 reportMedium impact
Kubernetes v1.36 Introduces Server-Side Sharded List and Watch Feature
Kubernetes v1.36 has introduced an alpha feature called server-side sharded list and watch, which aims to improve scalability for controllers managing high-cardinality resources. This feature allows the API server to filter events before they reach each controller replica, significantly reducing resource overhead by ensuring that replicas only receive data relevant to them.
Key points
- Kubernetes v1.36 introduces server-side sharded list and watch as an alpha feature.
- API server filters events based on replicas' hash ranges.
- Reduces CPU, memory, and network costs for controllers.
Introduction to Server-Side Sharded List and Watch
Kubernetes v1.36 introduces a significant improvement aimed at enhancing the scalability of Kubernetes controllers, particularly for those managing a large number of resources. The server-side sharded list and watch feature, designated as KEP-5866, enables the API server to perform event filtering. This approach ensures that each controller replica only receives relevant events, addressing inefficiencies in resource utilization.
Challenges with Current Controller Scaling
Historically, scaling out controllers in Kubernetes has led to higher resource consumption. Each replica of a horizontally scaled controller processes the complete stream of events from the API server—regardless of necessity—leading to wasted CPU cycles, memory, and network bandwidth. Scaling the number of replicas heightens this inefficiency, which the new feature aims to mitigate.
How Server-Side Sharded List and Watch Works
With server-side sharded list and watch, replicas define specific hash ranges of the resource collection they manage. The API server computes a deterministic 64-bit hash value for specified fields (currently, object.metadata.uid and object.metadata.namespace) and filters the event stream accordingly. This mechanism enables replicas to process only the events of their interest, thus conserving resources.
Implementation Details and Client Integration
To utilize this feature, clients must specify a shardSelector in their ListOptions through the WithTweakListOptions method. The integration simplifies the workload of each controller while maintaining safe operation across multiple API server instances, making it a crucial enhancement for large-scale Kubernetes deployments.
✨ This summary was generated by AI from the outlets' reporting listed below. It is not independently verified and may contain errors — check the original sources. How BrevFeed works →
The daily brief
One email each morning: the day's tech stories, clustered across outlets and summarized. No account needed.
One email a day. Unsubscribe in one click, any time.
Today's brief
Spend a few minutes, get the whole day. Every topic's top stories in one hands-free rundown — listen, watch, or read the transcript.
▶ Play today's brief
New every morning, and the back catalogue is archived by date.
Primary sources
GitHub kubernetes/enhancements GitHub kubernetes/kube-state-metrics GitHub kubernetes/community GitHub kubernetes/website GitHub kubernetes/kubernetes CVE CVE-2025-19749.8 CRITICALReporting from
Kubernetes v1.36 has introduced an alpha feature called server-side sharded list and watch, which aims to improve scalability for controllers managing high-cardinality resources. This feature allows the API server to filter events before they reach each controller replica, significantly reducing resource overhead by ensuring that replicas only receive data relevant to them.