Welcome to the NZRT Wiki Podcast. Today we’re looking at Services & DNS.

Let’s start with the basics. Inside a Kubernetes cluster, CoreDNS is the engine that handles automatic DNS resolution. That means when a service or a pod needs to find another service or pod by name, CoreDNS is the one doing the lookup behind the scenes.

Now, DNS names in the cluster follow a predictable pattern depending on what you’re trying to reach and where you’re reaching from. There are four main formats to know. First, if you’re looking up a service from within the same namespace, you can just use the service name on its own — short and simple. Second, if you’re crossing into a different namespace, you add the namespace after the service name, separated by a dot. Third, if you want the full, unambiguous address — what’s called a Fully Qualified Domain Name — you build it out as the service name, then the namespace, then the suffix “svc.cluster.local”. And fourth, pods themselves get a DNS name too, built from the pod’s IP address with dashes instead of dots, followed by the namespace and then “pod.cluster.local”. A real example of a fully qualified service name would look like: wordpress-service dot nzrt-prod dot svc dot cluster dot local.

Next up, testing DNS resolution. The wiki shows two ways to do this. The first approach launches a temporary debug pod using a minimal image called busybox, runs an nslookup command against the wordpress-service inside the nzrt-prod namespace, and then automatically removes itself when done. The second approach skips creating a new pod altogether — instead, you jump directly into a pod that’s already running and fire the nslookup from inside it, this time using the cross-namespace format with the namespace included in the name.

Now let’s talk about headless services, because these work a little differently. A normal service gives you a single stable IP address that load-balances traffic across your pods. A headless service, by contrast, has no cluster IP at all — and that’s intentional. When you query a headless service, you get back the actual IP addresses of the individual pods behind it. This is particularly useful for StatefulSets, where each pod needs its own stable, predictable DNS name.

In the Nextcloud example from the wiki, you’d have two pods addressable individually. The first would be nextcloud-0 dot nextcloud dot nzrt-prod dot svc dot cluster dot local, and the second would be nextcloud-1 with the same suffix. Each pod is reachable directly by name, which matters a lot for stateful applications where pod identity is important.

The configuration for a headless service is straightforward. You define it as a standard Kubernetes service, give it the name “nextcloud” in the nzrt-prod namespace, set the cluster IP field explicitly to the word “None” — that’s what makes it headless — point the selector at pods with the app label of nextcloud, and expose port 80.

Finally, if you ever need to inspect or troubleshoot the CoreDNS configuration itself, the wiki shows a command that retrieves the CoreDNS config map from the kube-system namespace and prints it out in full. This is handy if you’re chasing a DNS issue at the cluster level and need to see exactly how CoreDNS is configured.

For more context, the related topics in the wiki are Networking Overview, Services, and StatefulSets — worth reading alongside this one if you want the full picture.

That’s it for this episode of the NZRT Wiki Podcast. Thanks for listening.