# Kubernetes 1.36 moves controller sharding into the API server

> An alpha Kubernetes API lets horizontally sharded controllers request only their hash range for list and watch traffic instead of discarding events.

Canonical URL: https://www.devobs.io/news/news-kubernetes-server-side-sharded-watch-alpha/
By: Ines Costa
Published: 2026-09-06T11:58:54.646Z
Updated: 2026-09-06T11:58:54.646Z
Event date: 2026-05-06
Section: Infrastructure

A May 6 Kubernetes engineering post detailed server-side sharded list and watch, an alpha feature introduced with Kubernetes 1.36 when the release shipped on April 22. According to the [Kubernetes engineering post](https://kubernetes.io/blog/2026/05/06/kubernetes-v1-36-server-side-sharded-list-and-watch/), the API server can filter a resource collection so each controller replica receives only the slice it owns.

## Filtering moves upstream

With client-side sharding, every replica receives and deserializes the full event stream, then discards objects assigned to other replicas. Network and CPU costs therefore grow with the number of replicas. The alpha adds `shardSelector` to `ListOptions`, allowing a client to describe a hash range over either `object.metadata.uid` or `object.metadata.namespace`.

The API server calculates a deterministic 64-bit FNV-1a hash and applies the same selector to list results and watch events. A response that honored the selector includes `shardInfo` metadata, which lets a client verify that the server applied the requested partition. Multiple API server replicas calculate the same mapping.

## Shards need complete coverage

Controller authors can inject selectors into informer list options, but partition design remains their responsibility. Ranges must cover the intended keyspace without gaps, and ownership changes need a handoff strategy that avoids missing work. During a mixed-version rollout, clients should check `shardInfo` rather than assume every API server understands the alpha field.

A useful test deploys two replicas against a synthetic collection, records the UIDs each processes, and verifies that their union equals the unsharded result with no overlap. Then restart a replica and rebalance the ranges while resources change. This feature can remove duplicated transport and deserialization work for large controllers, but its alpha status calls for controlled experiments and explicit fallback to an ordinary full list and watch.

## Source references

- <https://kubernetes.io/blog/2026/05/06/kubernetes-v1-36-server-side-sharded-list-and-watch/>