Comparison
Cluster DNSvsService discovery
Cluster DNS
you connect to a name rather than an address, and every workload in the cluster resolves it to whatever is currently healthy.
The in-cluster resolver that maps service names to virtual addresses, making service-to-service calls a hostname rather than a discovery problem. It is a hard dependency of nearly every request path, so a saturated or crash-looping DNS deployment presents as intermittent failures everywhere at once rather than as a DNS incident. Aggressive search-domain expansion also means one lookup can become five queries, which is why DNS is a surprisingly common source of tail latency.
Full entry →Service discovery
instances come and go constantly and callers never hold a stale address, because nobody is configured with one.
The mechanism by which a caller finds a currently-healthy instance of something whose addresses change all the time. On a container platform it is usually DNS plus a continuously-updated endpoint list maintained by the control plane, rather than anything the application does. The reason it is infrastructure rather than code is that the set of instances changes on every deploy, every scale event and every node replacement.
Full entry →