DNS-based service discovery lets a Kubernetes workload call an internal Service by name instead of hardcoding a changing Pod IP. For example, a container can use http://robohash-internal, or include the namespace in a name such as robohash-internal.default. section 7.1.3
Use the technique when deploying independently managed internal services:
- Reach the Service from any namespace without creating ordering dependencies. section 7.1.3
- Expect a DNS lookup to be slightly slower than reading a constant environment variable, and cache results when appropriate. section 7.1.3
- Keep the endpoint configurable through an environment variable so the container can use a different path outside Kubernetes. section 7.1.3
Configure a Deployment
Set AVATAR_ENDPOINT to http://robohash-internal in the timeserver Deployment. The application reads that variable, requests /avatar from the internal service, and returns the image without knowing its Pod IP. section 7.1.3
Listing 7.4 Chapter07/7.1_InternalServices/timeserver-deploy-dns.yaml
apiVersion: apps/v1
kind: Deployment
metadata:
name: timeserver
spec:
replicas: 1
selector:
matchLabels:
pod: timeserver-pod
template:
metadata:
labels:
pod: timeserver-pod
spec:
containers:
- name: timeserver-container
image: docker.io/wdenniss/timeserver:5
env:
- name: AVATAR_ENDPOINT
value: http://robohash-internal #1
#1 Service discovery using DNS
This manifest shows DNS-based discovery configured through AVATAR_ENDPOINT. section 7.1.3
