Testing Peer Discovery

We know that pairing a headless Service with a StatefulSet creates DNS SRV records for each StatefulSet Pod that matches the Service’s label selector. We already have a headless Service and three StatefulSet Pods running, so we should have three DNS SRV records – one for each Pod.

How DNS hostnames subdomains work with StatefulSets

All Kubernetes objects get a name within the cluster address space. We can specify a custom address space when we build our cluster, but most use the cluster.local DNS domain. Within this domain, Kubernetes constructs DNS subdomains as follows:

• <object-name>.<service-name>.<namespace>.svc.cluster.local

We currently have three Pods called tkb-sts-0, tkb-sts-1, and tkb-sts-2 in the default Namespace governed by the dullahan headless Service. This means the Pods will have the following fully qualified DNS names that are predictable and reliable:

• tkb-sts-0.dullahan.default.svc.cluster.local

• tkb-sts-1.dullahan.default.svc.cluster.local

• tkb-sts-2.dullahan.default.svc.cluster.local

It’s the job of the headless Service to register these Pods and their IPs against the dullahan.default.svc.cluster.local name.

We’ll test this by deploying a jump Pod with the dig utility preinstalled. We’ll then exec onto the Pod and use dig to query DNS for SRV records for the Service.

Use the following terminal to execute all the commands for this lesson.