Service discovery and routing

A Kubernetes Service provides a stable abstraction over a changing set of backends. Selectors commonly connect a Service to Pods, and EndpointSlices represent endpoint information used by the networking implementation. A normal Service's DNS record typically resolves to its virtual service address, while a headless Service exposes endpoint addresses through DNS. These are different discovery contracts; a client that balances discovered endpoints must handle membership changes itself.

Start a routing design by writing what the client learns and who selects a backend. Is the client receiving a virtual address, a set of addresses, or a proxy endpoint that makes a later decision? Then list caches and failure detectors along that path. A service name that resolves successfully only proves something about naming; it does not prove the selected process is ready, authorized, or able to reach its own dependencies.

A readiness signal should answer whether a backend may receive new work under the service's contract. Making it depend on every distant dependency can remove all replicas during an upstream outage. Making it ignore a required local model can route work to a process that cannot serve it. Choose the signal from the application's actual recovery behavior and test it during startup, overload, and shutdown instead of treating any successful health URL as sufficient.

DNS time-to-live influences how long a resolver may cache an answer; it does not force an already established TCP connection to migrate. Connection pools, proxies, and client retry behavior introduce their own state. During retirement, stop advertising new availability, allow propagation, and bound existing work before termination. If requests can stream indefinitely, the policy needs a maximum stream age, a handoff, or a documented interruption behavior. Lowering a DNS TTL alone does not create such a protocol.

A conservative retirement budget can add a measured endpoint-propagation bound, a bound on admitted request duration, and a safety margin. This is valid only if the routing implementation eventually stops sending new work and the request-duration bound is real. Observe active requests and connection ages on the retiring instance. A fixed sleep can be a fallback, but it should have a reason that is testable in the deployed network.

When backends disappear, recalculate both total surviving capacity and the concentration of traffic. A fleet can remain reachable while the survivors overload, causing retries that increase demand again. Prefer explicit deadlines and bounded admission over indiscriminate retries. Track errors by selected backend and route version so a stale endpoint, a failing application, and an overloaded healthy survivor do not collapse into one opaque availability graph. The discovery plane and data plane should each have a recovery test.