Kubernetes controllers face scaling challenges as cluster sizes increase, particularly when watching high-cardinality resources. Client-side sharding, while functional, doesn't reduce the data volume from the API server, causing inefficiency. Server-side sharded list and watch, introduced in Kubernetes v1.36 as an alpha feature (KEP-5866), addresses this inefficiency. The API server filters events based on the controller's specified hash range, sending only relevant data to each replica. Controllers use informers to list and watch resources, incorporating the shardSelector through WithTweakListOptions. The shard selector is used to filter resources based on the object's metadata.uid or metadata.namespace. The API server returns a shardInfo field in the list response metadata to confirm if the shard selector was applied correctly. If absent, the client must handle the full, unfiltered collection, potentially resorting to client-side filtering. This feature requires enabling the ShardedListAndWatch feature gate. The Kubernetes community seeks feedback from controller authors and operators, especially those managing large clusters. This approach is designed to improve controller performance and scalability in demanding Kubernetes environments.