⌂ Home

EndpointSlices

Every Service needs to know which Pods are healthy and ready to receive traffic. EndpointSlices are the directory that maps a Service name to real Pod IP addresses.

When you create a Service with a selector, Kubernetes automatically creates EndpointSlice objects that list the IP addresses and ports of every matching, ready Pod. Components like kube-proxy read these slices to program iptables/IPVS rules so traffic reaching the Service ClusterIP gets forwarded to healthy backends. EndpointSlices replaced the older, monolithic Endpoints object — they split large lists into chunks of 100, support partial updates, and carry topology metadata (zone, node) for smarter routing.

Core Model

Understand the Concept First

What is an EndpointSlice?

A Kubernetes API object (discovery.k8s.io/v1) that stores the IP addresses and ports of Pods backing a Service. Think of a Service as the published name and EndpointSlices as the phone book of healthy backends behind it. kube-proxy reads these to route traffic.

Who creates them?

For any Service with a selector, the EndpointSlice controller (in kube-controller-manager) creates and updates slices automatically as Pods start, stop, or fail probes. You can also create custom slices for external backends.

Chunked for scale (max 100)

Instead of one giant Endpoints object, backends are split into slices of up to 100 entries each. A Service with 350 Pods gets 4 slices — updates touch only the changed slice.

Efficient partial updates

Only the EndpointSlices that actually change are transmitted and reconciled, reducing load on the API server and watchers compared to full replacement.

Topology-aware routing

Each endpoint carries zone, nodeName, and optional hints so kube-proxy and service meshes can prefer same-zone traffic for lower latency.

Dual-stack native

IPv4 and IPv6 addresses get separate EndpointSlices per address family, enabling clean dual-stack networking without workarounds.

Visual Architecture

Interactive Flow Diagrams

EndpointSlice Structure Service selects Pods by labels; EndpointSlices list ready Pod IPs for kube-proxy and other consumers Service (ClusterIP) my-service:80 selector Label match app=myapp, tier=web Pods that match become endpoints owned by EndpointSlice my-service-abc12 endpoints[].addresses ports, conditions, hints routes to Pod 10.244.1.5 Pod 10.244.1.6 Pod 10.244.1.7 At a glance The Service defines selection; EndpointSlices materialize the live set of Pod IPs for dataplane programming. EndpointSlice Scaling Pattern Small Scale (< 100 endpoints) EndpointSlice my-service-abc123 Pod 1: 10.244.1.5:80 Pod 2: 10.244.1.6:80 ... up to 100 endpoints Large Scale (100+ endpoints) EndpointSlice 1 my-service-slice1 Pods 1-100 100 endpoints FULL EndpointSlice 2 my-service-slice2 Pods 101-200 100 endpoints FULL EndpointSlice 3 my-service-slice3 Pods 201-300 100 endpoints FULL EndpointSlice N my-service-sliceN Pods 301-... 45 endpoints PARTIAL Automatically scaled to multiple slices as service grows Benefits of EndpointSlices • Reduced API server load • Better scalability for large services
Hover over diagram elements for detailed tooltips. Click the buttons above to switch between different architectural views.
Lifecycle Flow

From Ready Pod to Routed Traffic

1

Pod starts and becomes Ready

A Pod is scheduled, passes readiness probes, and receives a cluster IP on the Pod network.

2

EndpointSlice controller detects the change

The built-in controller watches Pods and Services and reconciles when labels or readiness change.

3

Controller updates (or creates) EndpointSlice

Matching backends are added, removed, or moved to another slice when the 100-endpoint limit requires it.

4

kube-proxy reads updated EndpointSlice

The node-level proxy watches EndpointSlices for Services it must implement locally.

5

iptables/IPVS rules updated for traffic routing

Dataplane rules are rewritten so Service VIP traffic reaches the current set of Pod IPs.

This path is the same idea on every node: EndpointSlices are the source of truth kube-proxy uses to program forwarding rules.
YAML and Commands

Examples You Can Recognize Quickly

EndpointSlice YAML pattern
apiVersion: discovery.k8s.io/v1
kind: EndpointSlice
metadata:
  name: my-service-abc12
  labels:
    kubernetes.io/service-name: my-service
addressType: IPv4
endpoints:
  - addresses: ["10.244.1.5"]
    conditions:
      ready: true
ports:
  - name: http
    port: 80
    protocol: TCP
Useful inspection commands
kubectl get endpointslices
kubectl get endpointslices -A
kubectl describe endpointslice <name>
kubectl get endpointslice -o yaml
kubectl get svc my-service -o wide
Decision Guide

Endpoints vs EndpointSlices

Aspect Endpoints (legacy) EndpointSlices
Max size Unlimited in one object (grows unbounded) Up to 100 endpoints per slice; multiple slices per Service
Scalability Poor for very large backend sets Excellent; work is sharded across smaller objects
Update efficiency Full object replacement typical Partial updates per changed slice
Dual-stack No native dual-stack model Yes (IPv4 / IPv6 via addressType and addresses)
Topology No standard zone/node hints on Endpoints Yes (zone, node name, and other hints for consumers)
API core/v1 Endpoints discovery.k8s.io/v1 EndpointSlice
For standard Services, Kubernetes creates and manages EndpointSlices for you; you rarely hand-write them unless integrating external backends.
Use It Well

Practice and Real-World Thinking

Auto-managed for standard services

Let the controller own EndpointSlices for typical selector-based Services; verify with kubectl get endpointslices when debugging.

Custom slices for external services

Custom EndpointSlices (or mirrored endpoints) can represent backends outside the cluster while still fitting the Service model.

Monitor endpoint health

Watch EndpointSlice changes and conditions.ready to correlate rollout issues with missing or not-ready backends.