Kubernetes 1.36 introduces an alpha feature called server-side sharded list and watch<\/strong>. That name sounds internal, but the problem it addresses is very real for large clusters: horizontally scaled controllers can waste a lot of CPU, memory, and network bandwidth processing events they will immediately discard.<\/p>\n This feature does not matter much for small clusters. It matters when the number of objects is high, the controllers are scaled out, and every replica is still receiving the full event stream from the API server.<\/p>\n Kubernetes controllers commonly use the list-then-watch pattern. They list the current state of resources, then watch for changes so they can keep their local cache in sync.<\/p>\n That model works well, but it becomes expensive at scale. If a controller has multiple replicas and each replica is responsible for only part of the workload, the API server may still send every replica the full stream of objects and events. Each replica then filters locally and discards what it does not own.<\/p>\n The result is waste:<\/p>\n In other words, adding more replicas may help distribute business logic, but it does not necessarily reduce the cost of watching Kubernetes resources.<\/p>\n Server-side sharded list and watch moves part of that filtering into the API server.<\/p>\n Instead of every controller replica receiving the full collection, each replica can request a specific shard. Kubernetes uses a For Kubernetes 1.36, the feature supports hashing fields such as The important part is simple: each replica receives less irrelevant data.<\/p>\n This is an API machinery feature, but operators should care because it targets one of the hidden costs of large Kubernetes clusters.<\/p>\n In a large environment, controllers that watch high-cardinality resources like Pods can become expensive even when they are well-written. If every replica receives everything, the control plane pays a repeated cost. Server-side sharding gives controller authors a way to reduce that cost closer to the source.<\/p>\n Potential benefits include:<\/p>\n This is especially relevant for projects that already shard work client-side, because they may be able to stop receiving data they were only going to discard.<\/p>\n This feature is alpha in Kubernetes 1.36 and disabled by default. That is important.<\/p>\n Alpha means it is not something to casually depend on for production behavior unless you are intentionally testing it and understand the risk. It requires enabling the The Kubernetes documentation notes that responses can include That fallback requirement is not a minor detail. Controller authors cannot assume every cluster they run against will support the feature.<\/p>\n Most everyday Kubernetes users do not need to change anything today.<\/p>\n The people who should pay attention are:<\/p>\n For those groups, this is worth testing early because it could influence future controller architecture.<\/p>\n Kubernetes keeps improving scalability not only through big visible features, but through lower-level changes that reduce control plane waste. Server-side sharded list and watch fits that pattern.<\/p>\n It recognizes that large clusters are not just \u201csmall clusters with more nodes.\u201d At scale, repeated streams, duplicated processing, and inefficient watches become real operational costs.<\/p>\n If this feature matures, it could make horizontally scaled controllers more efficient and make Kubernetes friendlier to very large environments.<\/p>\n Kubernetes 1.36 server-side sharded list and watch is not a feature most users will touch directly today. It is an alpha building block for controller authors and large-cluster operators.<\/p>\n The practical takeaway is this: Kubernetes is giving controllers a way to ask the API server for only the slice of the world they are responsible for. If it matures, that could make large clusters less wasteful and easier to scale.<\/p>\n Kubernetes 1.36 adds alpha server-side sharded list and watch, helping large controllers avoid processing event streams they do not own.<\/p>\n","protected":false},"author":1,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[33],"tags":[120,119,121,114,118,122],"class_list":["post-119","post","type-post","status-publish","format-standard","hentry","category-infrastructure","tag-api-server","tag-containers","tag-controllers","tag-devops","tag-kubernetes","tag-scalability"],"jetpack_featured_media_url":"","_links":{"self":[{"href":"https:\/\/cgh.mx\/index.php?rest_route=\/wp\/v2\/posts\/119","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/cgh.mx\/index.php?rest_route=\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/cgh.mx\/index.php?rest_route=\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/cgh.mx\/index.php?rest_route=\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/cgh.mx\/index.php?rest_route=%2Fwp%2Fv2%2Fcomments&post=119"}],"version-history":[{"count":1,"href":"https:\/\/cgh.mx\/index.php?rest_route=\/wp\/v2\/posts\/119\/revisions"}],"predecessor-version":[{"id":150,"href":"https:\/\/cgh.mx\/index.php?rest_route=\/wp\/v2\/posts\/119\/revisions\/150"}],"wp:attachment":[{"href":"https:\/\/cgh.mx\/index.php?rest_route=%2Fwp%2Fv2%2Fmedia&parent=119"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/cgh.mx\/index.php?rest_route=%2Fwp%2Fv2%2Fcategories&post=119"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/cgh.mx\/index.php?rest_route=%2Fwp%2Fv2%2Ftags&post=119"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}The problem: every replica sees too much<\/h2>\n
\n
What server-side sharding changes<\/h2>\n
shardSelector<\/code> in ListOptions<\/code> with a hash range expression. The API server evaluates the selector and sends only the objects whose metadata hash falls into that replica\u2019s assigned range.<\/p>\nobject.metadata.uid<\/code> and object.metadata.namespace<\/code>. The API server uses a deterministic 64-bit FNV-1a hash so the same object maps consistently to the same shard range.<\/p>\nWhy this matters for operators<\/h2>\n
\n
The alpha warning matters<\/h2>\n
ShardedListAndWatch<\/code> feature gate on the API server, and clients need to handle fallback cases.<\/p>\nshardInfo<\/code> metadata when the server honors the selector. If that information is absent, the client should assume the server did not apply the shard and be ready to handle the full result set.<\/p>\nWho should pay attention now<\/h2>\n
\n
Why this matters beyond one release<\/h2>\n
The practical takeaway<\/h2>\n
Sources<\/h2>\n
\n