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