The subdomain field supplies the subdomain portion of a pod’s internal fully qualified domain name (FQDN). Together with the pod hostname, namespace, and cluster domain, it forms a name such as <hostname>.<subdomain>.<namespace>.svc.<cluster-domain>. section 8.1.2
For pods that must find one another, set the field to the name of a headless Service. An Indexed Job can then give each pod a predictable identity that peers can resolve through DNS. section 18.1.6
A working pod-to-pod setup combines:
- An Indexed Job, so completed pods receive indexed identities. section 18.1.6
- A headless Service with clusterIP set to None and a selector matching the Job’s pods. section 18.1.6
- A pod-template subdomain matching the headless Service name. section 18.1.6
Resolving an indexed Job pod
With subdomain: demo-service, pod comm-demo-0-mrvlp receives the FQDN comm-demo-0.demo-service.kiada.svc.cluster.local. Another pod can ping that name, or the shorter name comm-demo-0.demo-service. section 18.1.6
Listing 18.15 A Job manifest enabling pod-to-pod communication
apiVersion: batch/v1
kind: Job
metadata:
name: comm-demo #1
spec:
completionMode: Indexed #2
completions: 2 #3
parallelism: 2 #3
template:
spec:
subdomain: demo-service #4
restartPolicy: Never
containers:
- name: comm-demo
image: busybox
command: #5
- sleep #5
- "600" #5
Shows the Job template with completionMode: Indexed and subdomain: demo-service. section 18.1.6
