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 3 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 pre-installed. 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: