Service discovery locates a Service’s current network endpoint without hardcoding its cluster IP into application code. This keeps deployments portable across development, staging, and production environments. section 7.1.3
Kubernetes provides two discovery mechanisms:
- DNS works across the cluster. An application can address the Service by name, such as http://robohash-internal. section 7.1.3
- Environment variables expose a Service’s cluster IP and ports inside Pods in the same namespace. They are fast and have no dependency on an external DNS server. section 7.1.3
- Environment-variable discovery requires the Service to exist before the Pod is created, and changed values may require restarting the Deployment’s Pods. section 7.1.3
A Service supplies the stable cluster-local address that discovery resolves, while also routing traffic only to running Pods selected by its labels. Services can therefore connect independently scaling applications in a cluster. section 7.3 section 3.2.5
Calling an internal avatar service
A timeserver Deployment can set AVATAR_ENDPOINT to http://robohash-internal and have its application request that endpoint when serving /avatar. The same configuration can instead use ROBOHASH_INTERNAL_SERVICE_HOST when environment-variable discovery is appropriate.
