Service Discovery and Health Checks

Application instances can start, move and disappear during scaling or deployment. A caller needs a way to find the current destinations for a service without hard-coding every machine address. Service discovery supplies that location information.

Knowing an address and knowing an instance can serve the required operation are separate questions. Health signals help route work, but their design can also cause an outage if they remove every instance at once.

With client-side discovery, the caller obtains eligible endpoints and chooses one. With server-side discovery, a proxy or service endpoint receives the call and routes it. Both need an update and failure policy; clients may keep cached information during a transition.

Registration tells discovery that an instance exists. Removal or lease expiry marks an instance no longer eligible. A lease requires periodic renewal, so a paused process or network delay may look like failure. Discovery does not prove an endpoint is honest or the caller authorized.

Readiness asks whether an instance should receive this traffic. Liveness asks whether the process needs restart under its configured policy. A startup check can allow slow initialization before normal probing begins. Their exact platform semantics matter.

If a shared database fails, making every app’s liveness check fail can restart the entire fleet without repairing the database. A readiness policy may instead withdraw instances, but removing all destinations has its own user-visible consequence. Choose what is checked, thresholds and degraded operation deliberately.

Allow draining during shutdown: stop taking new work, finish or hand off admitted work under a deadline, then terminate. A discovery update does not automatically close every cached endpoint or live connection.

All options remain visible. Select one per scenario to build a decision record you can revise.

Kubernetes Services provide a stable way to reach selected workloads while endpoint membership changes. DNS names can expose that identity; readiness and EndpointSlices affect eligible endpoints under the platform’s rules. Consul is a service-registry option; cloud platforms offer their own discovery integrations.

A small deployment can use a reverse proxy with configured backends instead of adopting a registry and service mesh. A mesh can provide traffic policy and instrumentation but adds configuration and operating responsibility. Choose it for a demonstrated need.

Read Kubernetes Service documentation for the concrete routing model. Measure propagation, endpoint count, connection reuse, probe load and recovery behaviour. Follow DNS for cached names and failure handling for the later call.

A Sidecar can support local traffic policy but adds its own readiness and resource budget. Circuit Breaker gates calls; discovery still needs a policy for cached endpoints and draining.

Use a stable service identity and plan stale endpoints. Give each health signal a useful action, and connect discovery to safe call deadlines and instance draining.