Testing Peer Discovery

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

How DNS hostnames subdomains work with StatefulSets

By default, Kubernetes places all objects within the cluster.local DNS subdomain. You can choose something different, but most lab environments use this domain, so we’ll assume it in this example. Within that domain, Kubernetes constructs DNS subdomains as follows:

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

• svc indicates the subdomain for objects behind a Service.

So far, you’ve got three Pods, called tkb-sts-0, tkb-sts-1, and tkb-sts-2, governed by the dullahan headless Service. This means the 3 Pods will have the following fully qualified DNS names:

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

To test this, you’ll deploy a jump-pod that has the DNS dig utility pre-installed. You’ll exec onto that Pod, and you’ll use dig to query DNS for SRV records in the dullahan.default.svc.cluster.local subdomain.

The following YAML is the jump-pod.yml file.