EndpointSlice
Does ZopNight manage 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.
Rules that fire on EndpointSlice
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.
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.