DDocker & Kubernetes : Kubernetes DNS with Pods and Services

bogotobogo.com site search:

minikube

Let's start our minikube:

$ minikube start
minikube v1.0.0 on darwin (amd64)
Downloading Kubernetes v1.14.0 images in the background ...
Tip: Use 'minikube start -p ' to create a new cluster, or 'minikube delete' to delete this one.
Restarting existing virtualbox VM for "minikube" ...
Waiting for SSH access ...
"minikube" IP address is 192.168.99.100
Configuring Docker as the container runtime ...
Version of container runtime is 18.06.2-ce
Waiting for image downloads to complete ...
Preparing Kubernetes environment ...
Pulling images required by Kubernetes v1.14.0 ...
Relaunching Kubernetes v1.14.0 using kubeadm ... 
Waiting for pods: apiserver proxy etcd scheduler controller dns
Updating kube-proxy configuration ...
Verifying component health ......
kubectl is now configured to use "minikube"
Done! Thank you for using minikube!

Kube-DNS / CoreDNS

Kube-DNS and CoreDNS are two established DNS solutions for defining DNS naming rules and resolving pod and service DNS to their corresponding cluster IPs. While CoreDNS is a newer add-on that became a default DNS server as of Kubernetes v1.12, Kube-DNS may still be installed as a default DNS system by certain Kubernetes installer tools.

With DNS, Kubernetes services can be referenced by name that will correspond to any number of backend pods managed by the service. The naming scheme for DNS also follows a predictable pattern, making the addresses of various services more memorable.

Services can also be referenced not only via a Fully Qualified Domain Name (FQDN) but also via only the name of the service itself.

Let's check if the dns pod is running:

$ kubectl get pods -n kube-system
NAME                               READY     STATUS    RESTARTS   AGE
coredns-fb8b8dccf-6bfmc            1/1       Running   2          11d
coredns-fb8b8dccf-b8dj9            1/1       Running   3          11d
etcd-minikube                      1/1       Running   1          11d
kube-addon-manager-minikube        1/1       Running   1          11d
kube-apiserver-minikube            1/1       Running   1          11d
kube-controller-manager-minikube   1/1       Running   0          177m
kube-proxy-mtlqc                   1/1       Running   0          177m
kube-scheduler-minikube            1/1       Running   1          11d
storage-provisioner                1/1       Running   3          11d

deployment.yaml

apiVersion: apps/v1
kind: Deployment
metadata:
  name: test-deployment
spec:
  replicas: 3
  selector:
    matchLabels:
      app: test-pod
  template:
    metadata:
      labels:
        app: test-pod
    spec:
      containers:
      - name: python-http-server
        image: python:2.7
        command: ["/bin/bash"]
        args: ["-c", "echo \" Hello from $(hostname)\" > index.html; python -m SimpleHTTPServer 80"]
        ports:
        - name: http
          containerPort: 80

Let's create the deployment:

$ kubectl create -f deployment.yaml 
deployment.apps/test-deployment created

$ kubectl get deployments
NAME              READY     UP-TO-DATE   AVAILABLE   AGE
test-deployment   3/3       3            3           8m16s

$ kubectl get pods -o wide
NAME                               READY     STATUS    RESTARTS   AGE       IP            NODE       NOMINATED NODE   READINESS GATES
test-deployment-6b5bfb9876-9k2bd   1/1       Running   0          9m37s     172.17.0.9    minikube   <none>           <none>
test-deployment-6b5bfb9876-j6j7b   1/1       Running   0          9m37s     172.17.0.10   minikube   <none>           <none>
test-deployment-6b5bfb9876-r6v7q   1/1       Running   0          9m37s     172.17.0.8    minikube   <none>           <none>

service.yaml

We need to create a service that will discover the deployment's pods and distribute client requests among them. Below is a manifest for a service that will be assigned a ClusterIP.

Our service definition looks like this:

kind: Service
apiVersion: v1
metadata:
  name: test-service
spec:
  selector:
    app: test-pod
  ports:
  - protocol: TCP
    port: 4000
    targetPort: http

Note that the spec.selector field of the service should match the spec.template.metadata.labels of the pod created by the deployment.

Let's create the service:

$ kubectl create -f service.yaml
service/test-service created

$ kubectl get svc -o wide
NAME               TYPE        CLUSTER-IP       EXTERNAL-IP   PORT(S)        AGE       SELECTOR
kubernetes         ClusterIP   10.96.0.1        <none>        443/TCP        11d       <none>
test-service       ClusterIP   10.108.55.60     <none>        4000/TCP       47s       app=test-pod

Creating a client pod - curlpod.yaml

Now, we want to create a curl pod that will curl the service by its name. This way we don't need to know the IPs of the service's endpoints and be dependent on the ephemeral nature of Kubernetes pods since the pod is within the cluster.

client.yaml:

apiVersion: v1
kind: Pod
metadata:
  name: curlpod
spec:
  containers:
  - image: radial/busyboxplus:curl
    command:
      - sleep
      - "3600"
    imagePullPolicy: IfNotPresent
    name: curlcontainer
  restartPolicy: Always

Now, create the curl pod:

$ kubectl create -f curlpod.yaml
pod/curlpod created

$ kubectl get pods
NAME                               READY     STATUS    RESTARTS   AGE
curlpod                            1/1       Running   0          80s
...

$ kubectl get svc
NAME           TYPE        CLUSTER-IP     EXTERNAL-IP   PORT(S)    AGE
kubernetes     ClusterIP   10.96.0.1      <none>        443/TCP    11d
test-service   ClusterIP   10.108.55.60   <none>        4000/TCP   131m

Once the curl pod is created, check if we can find our test-service:

$ kubectl exec curlpod -- nslookup test-service
Server:    10.96.0.10
Address 1: 10.96.0.10 kube-dns.kube-system.svc.cluster.local

Name:      test-service
Address 1: 10.108.55.60 test-service.default.svc.cluster.local

Notice that we are using the name of the Service instead of its ClusterIP or IPs of pods created by the Deployment.

We can use a DNS name of the service ("test-service") because our Kubernetes cluster uses a Kube-DNS add-on that watches the Kubernetes API for new services and creates DNS records for each of them. If Kube-DNS is enabled across our cluster, then all pods can perform name resolution of services automatically.

We could have checked this way:

$ kubectl run curlpod2 --image=radial/busyboxplus:curl --rm -ti --restart=Never \
--command -- curl http://test-service:4000
 Hello from test-deployment-6b5bfb9876-r6v7q
pod "curlpod2" deleted

Both of the responses (whether nslookup or curl) above indicate that Kube-DNS has correctly resolved the service name to the service's ClusterIP and the service has successfully forwarded the client request to random backend pod picked in a round-robin fashion. In its turn, the selected pod returned its custom greeting, which we can see in the responses above.