The Real Cost of Watching Everything Run a horizontally scaled controller across a large Kubernetes cluster—say, three replicas of a custom resource controller in a 5,000-node cluster. Each replica receives the entire event stream from the API server. It deserializes every Pod, every ConfigMap, every change, filters out 66% of them, and discards the rest. Multiply that waste by dozens of controllers and you're burning CPU and bandwidth on work that never had to happen. This is the scaling wall that Kubernetes operators hit, and Kubernetes v1.36 finally addresses it head-on with server-side sharded list and watch . Why Client-Side Sharding Isn't Enough Some controllers already implement horizontal sharding—tools like kube-state-metrics assign each replica a slice of the keyspace and discard irrelevant objects locally. Sounds reasonable until you map the actual costs: Deserialization waste : N replicas each deserialize the full event stream, even though (N-1) of them will throw away most of it.…