Kubernetes EndpointSlices

 

EndpointSlices:

• a modern, scalable way to track which Pods back a Service and how to reach them
• split Service endpoints into small, scalable chunks (slices) that Kubernetes networking components can efficiently consume
• replace (and improve on) the older Endpoints object

The problem they solve

Originally, Kubernetes used a single Endpoints object per Service that listed all Pod IPs and ports.

This caused issues at scale:

• Large Services (hundreds/thousands of Pods) created huge objects
• Frequent updates caused API server and etcd pressure
• Harder to extend with metadata (zone, topology, readiness, etc.)

What EndpointSlices are

An EndpointSlice is:

• A Kubernetes API object (discovery.k8s.io/v1)
• Owned by a Service
• EndpointSlice objects are:
• Automatically managed by the Kubernetes control plane
• Created and updated by the EndpointSlice controller
• Generated based on:
• Service selectors
• Matching Pod IPs and readiness state
• They are derived state, not source-of-truth configuration.
• Your source-of-truth objects are:
• Deployment
• StatefulSet
• DaemonSet
• Service
• EndpointSlices are dynamically rebuilt from those.
• Contains a subset of endpoints (Pods or external IPs)
• Typically holds up to ~100 endpoints per slice (configurable)

So instead of:

Service → 1 big Endpoints object

We have:

Service → multiple EndpointSlice objects

What’s inside an EndpointSlice

An EndpointSlice includes:

• Endpoints
• IP addresses (IPv4 / IPv6)
• Ready / serving / terminating status
• Zone & node info
• Ports
• Name, port number, protocol
• AddressType
• IPv4, IPv6, or FQDN
• Labels
• Including kubernetes.io/service-name

Example (simplified):

apiVersion: discovery.k8s.io/v1

kind: EndpointSlice

metadata:

  name: my-service-abcde

  labels:

    kubernetes.io/service-name: my-service

  addressType: IPv4

ports:

- name: http

  port: 80

  protocol: TCP

endpoints:

- addresses:

  - 10.244.1.12

  conditions:

    ready: true

    serving: true

    terminating: false

How they’re used

• kube-proxy reads EndpointSlices to program iptables/IPVS rules
• CoreDNS uses them for Service DNS resolution
• Controllers watch them instead of Endpoints
• The old Endpoints object still exists for backward compatibility

Ingress → Service → EndpointSlice → Pod IPs

Since modern clusters use EndpointSlices by default, lacking access to them breaks:

• kubectl describe ingress
• kubectl describe service
• Some kubectl get ... -o wide outputs

Why EndpointSlices are better

✅ Scales much better

✅ Smaller, more frequent updates

✅ Topology-aware routing (zones, nodes)

✅ Supports dual-stack (IPv4 + IPv6)

✅ Extensible for future networking features

Relationship to Endpoints (important)

• Modern clusters use EndpointSlices by default
• Kubernetes still creates Endpoints objects unless disabled
• You should:
• Read EndpointSlices
• Avoid writing Endpoints directly in new tooling

When you’ll notice them (DevOps angle)

As a DevOps engineer, you’ll run into EndpointSlices when:

• Debugging Services with many Pods
• Investigating kube-proxy or networking issues
• Watching API load in large clusters
• Writing controllers or operators
• Tuning Service performance at scale

Useful command:

kubectl get endpointslices

kubectl describe endpointslice <name>

What Happens During a Cluster Upgrade?

Whether you:

• Upgrade control plane in-place
• Do blue/green node groups
• Rotate nodes

EndpointSlices will:

• Continue to be reconciled automatically
• Be regenerated if needed
• Update when pods move to new nodes
• Update when pod IPs change

You do not migrate them.

What Happens When Pods Move to New Nodes

If you're doing blue/green node groups:

• Pod gets rescheduled
• Pod gets new IP
• EndpointSlice controller updates the slice
• kube-proxy / CNI updates routing
• Traffic continues normally

No manual action required.

When Would EndpointSlices Matter?

Only if:

• You manually created custom EndpointSlices (very rare)
• You disabled the EndpointSlice controller (also rare)
• You are debugging networking issues post-upgrade

For normal EKS clusters → ignore them in upgrade inventory.

---