DevOps Dictionary

Kubernetes EndpointSlice is a Kubernetes API object that stores the network endpoints behind a Service in smaller, scalable groups called slices. It tells cluster components, such as kube-proxy and service mesh controllers, which Pod IPs and ports can receive traffic for a Service.

What Kubernetes EndpointSlice does

EndpointSlice helps Kubernetes route Service traffic without storing every backend endpoint in one large object. Each slice contains a subset of endpoints for a Service, along with metadata such as IP addresses, ports, protocol, readiness, and topology information.

This matters most in larger clusters. A Service with hundreds or thousands of Pods can create a large amount of endpoint data. EndpointSlice reduces the size of individual updates and makes endpoint tracking more efficient than the older Endpoints API.

How EndpointSlice works

When you create a Kubernetes Service, the EndpointSlice controller watches for matching Pods. For each matching Pod, it creates or updates EndpointSlice objects that represent the Service backends.

For example, a Service named api might point to 300 Pods. Instead of putting all 300 Pod IPs into one Endpoints object, Kubernetes can split them across several EndpointSlice objects, often with around 100 endpoints per slice by default.

Cluster components then watch EndpointSlice objects and use them to route traffic. kube-proxy, for example, uses this data to program iptables, IPVS, or other routing rules on each node.

Key fields in an EndpointSlice

• addressType: Defines the type of endpoint address, such as IPv4, IPv6, or FQDN.
• endpoints: Lists backend destinations, usually Pod IP addresses, and their conditions.
• ports: Defines the port name, number, and protocol used by the Service.
• conditions.ready: Shows whether an endpoint is ready to receive traffic.
• topology or zone data: Helps Kubernetes and controllers make zone-aware routing decisions when supported.
• Labels: Connect EndpointSlice objects to their Service, commonly through the kubernetes.io/service-name label.

EndpointSlice and Kubernetes Services

A Kubernetes Service gives clients a stable virtual IP and DNS name. EndpointSlice stores the actual backend destinations for that Service.

For example, clients may call http://checkout.default.svc.cluster.local. The Service keeps that DNS name stable, while EndpointSlice tracks the current Pod IPs for the checkout workload as Pods start, stop, fail readiness checks, or move to different nodes.

EndpointSlice versus Endpoints

EndpointSlice is the newer, more scalable replacement for the older Kubernetes Endpoints API.

• Endpoints: Stores all backend addresses for a Service in one object.
• EndpointSlice: Splits backend addresses into multiple smaller objects.

The older Endpoints API can become expensive to update in large Services because every change may require rewriting a large object. EndpointSlice limits the blast radius of updates by changing only the affected slice.

Most modern Kubernetes clusters use EndpointSlice by default. The Endpoints API still exists for compatibility, but new controllers and platform tooling should prefer EndpointSlice where possible.

Common use cases

• Service traffic routing: kube-proxy uses EndpointSlice data to send traffic to healthy Pods behind a Service.
• Large-scale workloads: Services with many replicas benefit from smaller endpoint updates.
• Readiness-aware routing: Pods that fail readiness checks can be marked as not ready and removed from normal traffic paths.
• Dual-stack networking: EndpointSlice supports IPv4 and IPv6 address types.
• Service mesh and ingress controllers: Controllers can watch EndpointSlice objects to discover Service backends.
• Custom controllers: Platform teams can inspect EndpointSlice objects when building automation around networking or traffic policy.

Simple example

Suppose you deploy a payments-api Deployment with 6 replicas and expose it with a Service:

• The Service provides a stable name, such as payments-api.default.svc.cluster.local.
• Each Pod gets its own IP address.
• Kubernetes creates EndpointSlice objects that list those Pod IPs and the target port.
• If one Pod fails its readiness probe, its endpoint condition changes, and traffic can stop going to that Pod.
• If the Deployment scales to 20 replicas, Kubernetes updates the EndpointSlice objects to include the new Pod IPs.

You normally do not create EndpointSlice objects by hand for standard Services. Kubernetes manages them for you. You may still inspect them during debugging.

How to inspect EndpointSlice objects

You can list EndpointSlice objects in a namespace with:

kubectl get endpointslices

To inspect the slices for a specific Service, filter by label:

kubectl get endpointslices -l kubernetes.io/service-name=payments-api

For more detail, describe one slice:

kubectl describe endpointslice payments-api-abcde

This can help you debug issues where a Service exists but traffic does not reach Pods. Common causes include selector mismatches, failing readiness probes, wrong target ports, or Pods running in a different namespace than expected.

Benefits

• Better scalability: Large Services are split into smaller slices instead of one large endpoint object.
• More efficient updates: Kubernetes can update only the slice that changed.
• Richer endpoint metadata: EndpointSlice includes readiness and address type data in a structured way.
• IPv6 and dual-stack support: It handles different address families more cleanly than the older Endpoints API.
• Useful for controllers: Networking, ingress, and service mesh components can watch slices for backend discovery.

Tradeoffs and limitations

• More objects to inspect: A large Service may have many EndpointSlice objects, which can make manual debugging more involved.
• Controller compatibility matters: Older tools may still read the Endpoints API instead of EndpointSlice.
• Not a traffic policy by itself: EndpointSlice stores backend data. It does not define routing rules, retries, load balancing strategy, or authentication.
• Usually managed automatically: Manual edits are uncommon and can be overwritten by Kubernetes controllers.

Related Kubernetes concepts

• Service: Provides a stable access point for a set of Pods.
• Pod: The workload instance that usually appears as an endpoint.
• Readiness probe: Controls whether a Pod should receive Service traffic.
• kube-proxy: Uses Service and EndpointSlice data to configure node-level traffic routing.
• Ingress: Routes external HTTP or HTTPS traffic to Services, which then use EndpointSlice-backed endpoints.

Operational notes for DevOps and platform teams

EndpointSlice is useful during incident response because it shows what Kubernetes thinks the actual Service backends are. If DNS resolves and the Service exists, but traffic still fails, check the related EndpointSlice objects.

When managing Kubernetes resources through infrastructure as code, make sure your workflow accounts for controller-managed objects. For example, you may define Deployments and Services with Terraform, as shown in this guide to deploying Kubernetes resources using Terraform, while letting Kubernetes create EndpointSlice objects automatically.

EndpointSlice behavior can also matter during upgrades. Changes in networking components, kube-proxy mode, ingress controllers, or service mesh versions can affect how endpoint data is consumed. For production clusters, plan upgrades carefully and test Service routing, as covered in these practical Kubernetes upgrade tips for startups.

When you should care about EndpointSlice

You should understand EndpointSlice if you operate Kubernetes clusters, debug Service connectivity, run large replicated workloads, or build controllers that need backend discovery.

For small applications, EndpointSlice often works quietly in the background. For larger clusters, it becomes a key part of Kubernetes networking performance and Service reliability.