How EndpointSlices Supercharge Kubernetes Networking Scalability

Scalability Limits of the classic Endpoints API

The classic Endpoints API stores a single Endpoints object for each Service. This object contains the IP address and port of every Pod that backs the Service. Because the object is stored in etcd, it is subject to the default etcd object size limit of 1.5 MB. In practice this caps the number of tracked Pods to roughly 5,000 per Service.

When any Pod’s network endpoint changes, the entire Endpoints object is sent to every kube-proxy instance on each node. In a 3,000‑node cluster a single update would therefore transmit 1.5 MB × 3,000 ≈ 4.5 GB of data. A rolling update that replaces all Pods could exceed 22 TB of traffic, creating a serious scalability bottleneck.

EndpointSlice API – sharding endpoints

EndpointSlice addresses the bottleneck by partitioning endpoints into multiple smaller resources. By default each EndpointSlice holds up to 100 endpoints, but the limit can be changed with the --max-endpoints-per-slice flag on the kube-controller-manager:

kube-controller-manager --max-endpoints-per-slice=200

Because updates affect only the slice that contains the changed endpoint, the amount of data exchanged between the API server and kube-proxy is reduced by an order of magnitude. The sharding also bypasses the etcd size restriction, allowing services to scale beyond 100,000 network endpoints.

New capabilities enabled by EndpointSlices

Dual‑stack Services : the addressType field records whether an endpoint is IPv4 or IPv6, enabling a Service to expose both address families simultaneously (introduced as an alpha feature in Kubernetes v1.16).

Topology‑aware routing : each slice can store topology fields (e.g., zone, region). kube‑proxy can use these fields to prefer endpoints that reside in the same topology domain as the client, reducing cross‑zone traffic.

Endpoint subsets (ongoing work): kube‑proxy may watch only a subset of slices that match a particular topology, further cutting the volume of watch traffic.

Implications for the existing Endpoints API

The classic Endpoints API remains GA and will continue to be supported, but future enhancements will focus on truncating the object to avoid the scalability problems described above. New features such as dual‑stack and topology‑aware routing are being built on top of EndpointSlices, so applications that currently rely solely on Endpoints should add EndpointSlice support to benefit from the performance and feature improvements.

Original article: https://kubernetes.io/blog/2020/09/02/scaling-kubernetes-networking-with-endpointslices/