EndpointSlice: Splitting the Monolithic Endpoints List

WHY IT EXISTS: The original Kubernetes Endpoints API stored every pod IP backing a Service inside a single API object. When a Service scaled to thousands of pods, that object became enormous. Worse, any tiny change, such as one pod restarting and getting a new IP, forced every watcher, kube-proxy on every node, CoreDNS, and ingress controllers, to receive and process the entire object again. This created a quadratic scalability problem: more pods meant larger updates, and more nodes meant more watchers, amplifying control plane and network load. EndpointSlice was invented to break this bottleneck by sharding endpoint data across multiple smaller objects.

THE MENTAL MODEL: Imagine a restaurant with a single paper waiting list containing every guest's phone number. When one party is seated, the staff must reprint the entire list for every host station. EndpointSlice is like giving each host station a pager system divided into blocks of one hundred guests. When table fifty is ready, only that block is updated, so the other stations ignore the noise.

HOW IT WORKS: The EndpointSlice controller watches Services and Pods. For each Service, it divides matching Pod endpoints across multiple EndpointSlice objects. Each slice contains a subset of endpoints, their IP addresses, ports, and optional topology hints such as zone or node name. Network proxies and DNS providers watch only the slices relevant to the Services they handle. When the backing Pods change, the controller updates or replaces only the affected slices. This bounds the size of any single watch event and reduces memory pressure on API server clients.

WHEN TO USE IT: EndpointSlice is the default backend for Service endpoint propagation in modern Kubernetes clusters. You rely on it whenever you use kube-proxy, CoreDNS, or any ingress controller that consumes endpoint data. It becomes especially critical when you run Services with hundreds or thousands of endpoints, or when you operate large clusters where control plane efficiency matters. Custom controllers that need to route traffic directly to Pods should also consume EndpointSlices rather than the legacy Endpoints API.

WHEN NOT TO USE IT: Do not treat EndpointSlices as a general-purpose database for arbitrary network endpoints. They are not a place to manually inject external IPs or custom records; the EndpointSlice controller will overwrite manual changes during its next reconciliation loop. If you need to point a Service at an external IP, use ExternalName Services or Endpoints for manually managed cases, though even then custom Endpoints are discouraged. Additionally, if your cluster runs small Services with fewer than a hundred Pods, the legacy Endpoints object still works, though EndpointSlice is used regardless by modern components.

ONE CANONICAL EXAMPLE: Consider a microservice with a Deployment of three thousand replicas fronted by a ClusterIP Service. With the old Endpoints object, a rolling update that restarts one hundred pods generates one hundred full-object updates, each containing three thousand IP addresses, delivered to every node in the cluster. With EndpointSlice, those three thousand pods are spread across roughly thirty slices. Each pod restart updates only its containing slice, so each kube-proxy instance processes a tiny delta instead of the entire service directory. The control plane sends less data, the nodes use less CPU, and the update propagates faster.