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 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
• 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>

---