Environment variable discovery exposes an internal service endpoint through a variable that the workload consumes. Kubernetes generates service-related variables, while a custom variable such as AVATAR_ENDPOINT adds an application-friendly layer of indirection. section 7.1.3
Use this approach when a workload and its service share a namespace:
- Create the Service before creating the consuming Pods so the service variables are available. section 7.1.3
- Prefer a custom variable such as AVATAR_ENDPOINT to keep the application portable across Kubernetes, Docker Compose, and DNS-based lookup. section 7.1.3
- Expect fast string-based access without depending on Kubernetes DNS, but only within the same namespace. section 7.1.3
Injecting an internal endpoint
Set AVATAR_ENDPOINT to http://$(ROBOHASH_INTERNAL_SERVICE_HOST) in the Deployment, then have the application read that variable and append its request path. section 7.1.3
$ kubectl get pods NAME READY STATUS RESTARTS AGE robohash-6c96c64448-7fn24 1/1 Running 0 2d23h $ kubectl exec robohash-6c96c64448-7fn24 -- env ROBOHASH_INTERNAL_PORT_80_TCP_ADDR=10.63.243.43 ROBOHASH_INTERNAL_PORT_80_TCP=tcp://10.63.243.43:80 ROBOHASH_INTERNAL_PORT_80_TCP_PROTO=tcp ROBOHASH_INTERNAL_SERVICE_PORT=80 ROBOHASH_INTERNAL_PORT=tcp://10.63.243.43:80 ROBOHASH_INTERNAL_PORT_80_TCP_PORT=80 ROBOHASH_INTERNAL_SERVICE_HOST=10.63.243.43
Inspect a running Pod with kubectl exec and env to see the generated service host, port, and protocol variables. section 7.1.3
