Aggregate and deduplicate Kubernetes EndpointSlices before consuming endpoints

Bottom line: Review the complete Service-associated slice set before accepting an endpoint inventory. Give duplicate handling its own test case, including changes that arrive in a different order from the final state.

Source fact: documented behavior

The EndpointSlices documentation is the primary reference.

The EndpointSlice documentation groups a Service’s endpoints by IP family, protocol and port, so one Service can have several slices. An endpoint can appear in multiple slices while updates to separate objects reach a client watch or cache at different times. Kubernetes directs API clients to iterate every associated slice and produce a complete set of unique network endpoints.

What the source does not establish

This article concerns API aggregation and duplicate handling. It does not specify a universal endpoint identity key, choose application load balancing or replace the separate readiness and connection policy. Keep DNS discovery and the Endpoints-mirroring path outside this consumer test.

Applicability questions

• How does the consumer identify every slice associated with its Service?
• What address-family, protocol and port information must remain attached to an endpoint?
• How does the implementation handle overlapping entries during updates?
• Can the reviewer reconstruct the complete output from the retained input objects?

DSE recommendation: test the set rather than one convenient object

DSE recommends a consumer fixture with several Service-associated slices and a written expected endpoint set. Preserve each object’s identity and relevant endpoint attributes. Have the implementation owner define the uniqueness rule explicitly; do not silently collapse entries on an IP address alone without reviewing the remaining context.

Include an overlap period in the fixture. Put the same intended network endpoint in two input slices and write the expected unique output before exercising the consumer. Keep an endpoint with a different relevant port or protocol as a separate review case so duplicate removal does not hide a distinct destination.

Review updates as a sequence. Present an addition and removal in more than one approved order, retaining the intermediate inputs and observed outputs. Ask whether the implementation rebuilds or updates its aggregate correctly, and preserve an unexpected omission or duplicate as a defect to investigate. Avoid inferring completeness from the first object returned by a convenient inspection tool.

Keep the downstream decision visible. Pass the reconciled inventory to the application’s separately defined endpoint-acceptance process. Identify who owns readiness filtering, connection attempts and application membership. A reviewer should be able to approve the aggregation logic without accidentally approving every destination as usable or trusted.

Verification and evidence

Proposed verification, not performed: create a harmless local fixture modeled on the documented EndpointSlice structure, with two slices and one overlapping endpoint. Compare the consumer’s full output with the written expected set, preserving address-family, protocol and port context.

Exercise changed delivery orders, then remove the final occurrence of an endpoint in a separate case. Record input object revisions, the event sequence, consumer revision and actual output at each checkpoint. Use an authorized cluster exercise only after the fixture review. Report the observed aggregation behavior separately from application connectivity, readiness or failover results.

Official references

• EndpointSlices — Kubernetes.

Source review completed October 30, 2026. Recheck the official documentation and deployment-specific applicability before a production change.