# EndpointSlice

> EndpointSlices carry the pod addresses behind a Service in shards of up to 100 endpoints by default, replacing the single Endpoints object that rewrote itself on every pod change. ZopNight counts ready and not-ready endpoints per slice, joins in the owning Service's type and clusterIP, and flags slices empty beyond 5 minutes, skipping headless and ExternalName Services.

Source: https://zop.dev/integrations/kubernetes/endpointslice
Updated: 2026-08-19

---

An EndpointSlice carries the actual pod addresses behind a Service. It replaced the older Endpoints object for a scale reason: Endpoints packed every address into one object that had to be rewritten and re-broadcast on every pod change, which melted large clusters. Slices shard the list, with each holding up to 100 endpoints by default, so a single pod restart touches one small object instead of one enormous one.

## Built to shard what Endpoints could not

The 100-endpoint default (tunable via the controller's max-endpoints-per-slice setting) means a Service backed by 350 pods spreads across 4 slices, and churn in one shard leaves the other 3 untouched. For discovery purposes each slice records its owning Service's name, the address type, and two counts: ready endpoints and not-ready endpoints.

## An empty slice means traffic to nowhere

Zero ready plus zero not-ready endpoints is the signature of a Service whose selector matches nothing: every request routed there dies. The Service With No Endpoints rule (RC-1742 / RC-1842 / RC-1942, medium severity) fires on that signature, but only after the slice is at least 5 minutes old: fresh deploys, scale-from-zero events, and CrashLoop recoveries all pass through a legitimately empty moment, and without the dwell the rule alarmed on every rollout.

## The join that prevents false alarms

Two kinds of Service have no endpoints by design: headless Services (clusterIP None) and ExternalName Services. The slice object itself does not say which kind of Service owns it, so discovery joins in the owning Service's type and cluster IP during the same pass, and the empty-endpoints rule skips both kinds outright. The finding is also deliberately framed as a diagnosis, not a deletion: the dominant causes are a selector typo or a failing readiness probe on a live Service, and the fix belongs there.

```bash
kubectl get endpointslices -A -o custom-columns=NS:.metadata.namespace,NAME:.metadata.name,SERVICE:.metadata.labels.kubernetes\.io/service-name,ADDRESSTYPE:.addressType,ENDPOINTS:.endpoints[*].addresses[0]
```

## Reading slices during an incident

When a hostname stops answering, slice counts localize the failure in seconds: ready above 0 means routing is fine and the problem is downstream; all not-ready points at probes; empty points at the selector.