Spring Cloud Kubernetes discovery: choose API lookup or Service DNS

Use the simpler resolution contract

A dispatch API calls a pricing service by stable Kubernetes Service name. Standard DNS already resolves that name within the cluster; no Spring Cloud Kubernetes discovery starter is required just to call it. DiscoveryClient becomes useful when the application needs service metadata, filtered instances or a Spring abstraction that inspects Kubernetes objects.

Account for permissions and churn

API-based discovery needs appropriate service or endpoint read permissions and must cope with changing instances. DNS delegates that to Kubernetes networking. Neither choice excuses an unbounded HTTP call: set connection and response deadlines, and use failure policy for unavailable downstream services.

Test from inside the namespace

Deploy with the intended service account and namespace, resolve the Service name, then revoke API read permissions. DNS-only callers should still work. If using DiscoveryClient, assert the chosen metadata and namespace rules with multiple similarly named Services.

Implementation sketch

pricing:
  service-host: pricing-service
  connect-timeout: 2s
  response-timeout: 5s

Cost and verification

DNS calls avoid a discovery watch and extra API grants. API discovery can add metadata but costs permissions, watch traffic and more application behavior to test.

Common Mistakes

• Do not add API-based discovery only to resolve a stable Service name.
• Do not assume a short service name resolves across namespaces without a DNS rule.
• Do not let discovery success imply the downstream request cannot time out.

Read next

Spring Cloud Kubernetes config import: make source precedence explicit, Spring readiness: report an unavailable dependency without forcing liveness failure, Spring Cloud Circuit Breaker: make fallback obey the original data contract.