# Kubernetes v1.36: Server-Side Sharded List and Watch

DevFeed: [Kubernetes v1.36: Server-Side Sharded List and Watch](<https://devfeed.tech/articles/kubernetes-v1-36-server-side-sharded-list-and-watch-4547.md>)

Original publisher: [Read original article](<https://kubernetes.io/blog/2026/05/06/kubernetes-v1-36-server-side-sharded-list-and-watch/>)

Author: Jeffrey Ying

Published: 2026-05-06T18:35:00Z

Content type: article

Language: en

Sources: [Kubernetes Blog](<https://devfeed.tech/sources/kubernetes-blog.md>)

Topics: [Kubernetes](<https://devfeed.tech/topics/kubernetes.md>), [Kubernetes v1.32](<https://devfeed.tech/topics/kubernetes-v1-32.md>), [API](<https://devfeed.tech/topics/api.md>), [servers](<https://devfeed.tech/topics/servers.md>)

Tags: [api](<https://devfeed.tech/tags/api.md>), [cpu](<https://devfeed.tech/tags/cpu.md>), [kubernetes](<https://devfeed.tech/tags/kubernetes.md>), [memory](<https://devfeed.tech/tags/memory.md>), [network](<https://devfeed.tech/tags/network.md>), [v1](<https://devfeed.tech/tags/v1.md>)

## AI overview

Kubernetes v1.36 introduces server-side sharded list and watch as an alpha feature. The API server filters high-cardinality resource events by deterministic hash ranges, reducing unnecessary CPU, memory, and network usage for horizontally scaled controllers.

## Source excerpt

As Kubernetes clusters grow to tens of thousands of nodes, controllers that watch high-cardinality resources like Pods face a scaling wall. Every replica of a horizontally scaled controller receives the full stream of events from the API server, paying the CPU, memory, and network cost to deserialize everything, only to discard the objects it is not responsible for. Scaling out the controller does not reduce per-replica cost; it multiplies it. Kubernetes v1.36 introduces server-side sharded list and watch as an alpha feature (KEP-5866). With this feature enabled, the API server filters events at the source so that each controller replica receives only the slice of the resource collection it owns. The problem with client-side sharding Some controllers, such as kube-state-metrics, already support horizontal sharding. Each replica is assigned a portion of the keyspace and discards objects that do not belong to it. While this works functionally, it does not reduce the volume of data flowing from the API server: N replicas x full event stream: every replica deserializes and processes every event, then throws away what it does not need. Network bandwidth scales with replicas, not with shard size. CPU spent on deserialization is wasted for the discarded fraction. Server-side sharded list and watch solves this by moving the filtering upstream into the API server. Each replica tells the API server which hash range it owns, and the API server only sends matching events. How it works The feature adds a shardSelector field to ListOptions. Clients specify a hash range using the shardRange() function: shardRange(object.metadata.uid, '0x0000000000000000', '0x8000000000000000') The API server computes a deterministic 64-bit FNV-1a hash of the specified field and returns only objects whose hash falls within the range [start, end). This applies to both list responses and watch event streams. The hash function produces the same result across all API server instances, so the feature is