kubernetes v1.18: DNS resolution records for Pods

Question

The question is for pods DNS resolution in kubernetes. A statement from official doc here (choose v1.18 from top right dropdown list): https://kubernetes.io/docs/concepts/services-networking/dns-pod-service/#pods

Pods.

A/AAAA records

Any pods created by a Deployment or DaemonSet have the following DNS resolution available:

pod-ip-address.deployment-name.my-namespace.svc.cluster-domain.example.

Here is my kubernetes environments:

master $ kubectl version  
Client Version: version.Info{Major:"1", Minor:"18", GitVersion:"v1.18.0", GitCommit:"9e991415386e4cf155a24b1da15becaa390438d8", GitTreeState:"clean", BuildDate:"2020-03-25T14:58:59Z", GoVersion:"go1.13.8", Compiler:"gc", Platform:"linux/amd64"}  
Server Version: version.Info{Major:"1", Minor:"18", GitVersion:"v1.18.0", GitCommit:"9e991415386e4cf155a24b1da15becaa390438d8", GitTreeState:"clean", BuildDate:"2020-03-25T14:50:46Z", GoVersion:"go1.13.8", Compiler:"gc", Platform:"linux/amd64"}

After I create a simple deployment using kubectl create deploy nginx --image=nginx, then I create a busybox pod in test namespace to do nslookup like this:

kubectl create ns test

cat <<EOF | kubectl apply -n test -f -
apiVersion: v1
kind: Pod
metadata:
  name: busybox1
  labels:
    name: busybox
spec:
  containers:
  - image: busybox:1.28
    command:
      - sleep
      - "3600"
    name: busybox
EOF

Then I do nslookup like this, according to the offical doc pod-ip-address.deployment-name.my-namespace.svc.cluster-domain.example:

master $ kubectl get pods -o wide
NAME                    READY   STATUS    RESTARTS   AGE   IP           NODE     NOMINATED NODE   READINESS GATES
nginx-f89759699-h8cj9   1/1     Running   0          12m   10.244.1.4   node01   <none>           <none>

master $ kubectl get deploy -o wide
NAME    READY   UP-TO-DATE   AVAILABLE   AGE   CONTAINERS   IMAGES   SELECTOR
nginx   1/1     1            1           17m   nginx        nginx    app=nginx

master $ kubectl exec -it busybox1 -n test -- nslookup 10.244.1.4.nginx.default.svc.cluster.local
Server:    10.96.0.10
Address 1: 10.96.0.10 kube-dns.kube-system.svc.cluster.local

nslookup: can't resolve '10.244.1.4.nginx.default.svc.cluster.local'
command terminated with exit code 1

master $ kubectl exec -it busybox1 -n test -- nslookup 10-244-1-4.nginx.default.svc.cluster.local
Server:    10.96.0.10
Address 1: 10.96.0.10 kube-dns.kube-system.svc.cluster.local

nslookup: can't resolve '10-244-1-4.nginx.default.svc.cluster.local'
command terminated with exit code 1

Question 1:
Why nslookup for the name failed? Is there something I did wrong?

---

When I continue to explore the dns name for pods, I did this:

master $ kubectl exec -it busybox1 -n test -- nslookup 10-244-1-4.default.pod.cluster.local
Server:    10.96.0.10
Address 1: 10.96.0.10 kube-dns.kube-system.svc.cluster.local

Name:      10-244-1-4.default.pod.cluster.local
Address 1: 10.244.1.4
master $ kubectl exec -it busybox1 -n test -- nslookup 10-244-1-4.test.pod.cluster.local
Server:    10.96.0.10
Address 1: 10.96.0.10 kube-dns.kube-system.svc.cluster.local

Name:      10-244-1-4.test.pod.cluster.local
Address 1: 10.244.1.4

Questions 2:
Why nslookup 10-244-1-4.test.pod.cluster.local succeeded even the pod of 10.244.1.4 is in default namespace?

Answer 1

Regarding your first question, as far as I could check your assumptions are right, it seems like the documentation isn't accurate. The A/AAAA reference for pods is something new in the documentation (1.18). For that I highly encourage you to open an issue here so the developers can take a closer look into it.

I recommend you to refer to 1.17 documentation on that regard as it's to be reflecting the actual thing.

In 1.17 we can see this note:

Note: Because A or AAAA records are not created for Pod names, hostname is required for the Pod’s A or AAAA record to be created. A Pod with no hostname but with subdomain will only create the A or AAAA record for the headless service (default-subdomain.my-namespace.svc.cluster-domain.example), pointing to the Pod’s IP address. Also, Pod needs to become ready in order to have a record unless publishNotReadyAddresses=True is set on the Service.

As far as I could check this is still true on 1.18 despite of what the documentation is saying.

Regarding question two is going to the same direction and you can also open an issue but I personally don't see any practical reason for the usage of IP Based DNS names. These names are there for kubernetes internal use and using it isn't giving you any advantage.

The best scenario is to use service based dns names on Kubernetes. It's proven to be very reliable.