Service discovery dynamically locates services in distributed systems, replacing hardcoded network addresses with a mechanism that adapts as service instances appear, disappear, or change IP addresses. section 10.0 section 10.6
In Kubernetes, a Service groups pods behind a stable logical name. Calling another service by that name establishes the connection and can optionally load-balance traffic across its instances. section 10.6
Choose the discovery approach according to the deployment environment:
- Use Kubernetes Services when Kubernetes provides the production environment and platform-level discovery is sufficient. section 10.6
- Use SmallRye Stork with Quarkus when an application-level abstraction or the ability to switch mechanisms is useful. section 10.6
- Select among Consul, DNS, Kubernetes, Knative, Eureka, composite, static-list, or custom Java mechanisms through Stork. section 10.6
Connecting through a Kubernetes Service
An application needing another service connects using that service's Kubernetes name rather than a pod IP. Kubernetes resolves the logical service and may distribute requests across the matching pods. section 10.6
Figure 10.16 Communication between pods via a Kubernetes service proxy
Shows communication between pods through a Kubernetes Service proxy, making the indirection between callers, service names, and service instances concrete. section 10.6
Service discovery is separate from MicroProfile at the stated point in time. Stork supports Kubernetes as well as alternatives such as Consul, but detailed Stork configuration is deferred when Kubernetes or OpenShift is the production target. section 10.0 section 10.6
