Kubernetes through Kube-dns Discovery Service

Kube-dns composition

Kube-dns can solve the service discovery problem, k8s registers the service name as a domain name into Kube-dns, and can access the services it provides through the name of the service.

Kube-dns of four components:

ETCD, which is used to save DNS rules.

kube2sky, the role is to write DNS rules.

skydns, provides DNS resolution services.

healthz, provides health check function.

which

Skydns is an open-source framework for service discovery, built on ETCD. The function is to provide a DNS query interface for pods in the k8s cluster. Project hosted in Https://github.com/skynetservices/skydns

ETCD is an open-source distributed Key-value store that functions like zookeeper. The function in Kube-dns is to store all kinds of data skydns need, write to Kube2sky, read by Skydns. The project is hosted in HTTPS://GITHUB.COM/COREOS/ETCD.

Kube2sky is an adaptation program implemented by K8s that calls K8s's list and watch APIs through a service named Kubernetes (which can be viewed by Kubectl get Svc and created automatically by the cluster) to listen for k8s Changes to the service resource, thereby modifying the Skydns record in the ETCD. The code can be found in the cluster/addons/dns/kube2sky/directory of the k8s source (v1.2).

Exec-healthz is a secondary container provided by k8s and is used in side car mode. The principle is to periodically execute the specified Linux instructions to determine the health status of the key containers in the current pod. The function in Kube-dns is to check the health status of the DNS Query service through the nslookup directive, k8s livenessprobe to understand the health state by accessing the HTTP APIs provided by Exec-healthz, and to restart the container in the event of a failure. Its source code is located in Https://github.com/kubernetes/contrib/tree/master/exec-healthz.

It can be found that the POD query DNS is queried by the servicename.namespace subdomain, but in the previous example only used the service name, what is the principle? In fact, when we use the service name only the default is namespace, and the My-nginx service in the example above is in the default namespace, so it works. In this regard, follow-up and further introduction.

Skydns-rc.yaml can be found in the Livenessprobe is set in the Kube2sky container, the intent should be to re-write the DNS rules by restarting Kube2sky

Domain name format

Next look at the Kube-dns supported domain name format, specifically for:<service_name>.<namespace>.svc.<cluster_domain>.

Where cluster_domain can be set using the--cluster-domain=somedomain parameter of Kubelet, and also ensure that the--domain parameter in the Kube2sky container's startup parameter sets the same value. Typically set to cluster.local. Then the full domain name of the My-nginx service in the previous example is my-nginx.default.svc.cluster.local. See here, I believe many people will have doubts, since the full domain name is this, then why in the pod only through the service name and namespace can access the service? Here are some explanations for why.

Configuration

Domain Name resolution configuration

In order to invoke other Service,kubelet in the pod, the domain name resolution configuration (/ETC/RESOLV.CONF) is automatically created in the container, as follows:

Interested can find some resolv.conf information on the Internet to understand the specific meaning. The service can be accessed through the service name and namespace because of the rules of the search configuration. When resolving the domain name, it will be automatically stitched into the full domain name to query DNS.

The Kubelet--cluster-domain parameter mentioned earlier is relative to the specific configuration of search. The--domain parameter of the Kube2sky container affects the domain name written to ETCD, Kube2sky gets the service name and namespace, and uses the--domain parameter to stitch the full domain name. This is why the two parameters remain consistent.

NS Related Configuration

Kube-dns can let pod discover other service, how does pod automatically discover Kube-dns? In the/etc/resolv.conf in the previous section, you can see nameserver, which tells the pod where to access the domain name resolution server.

Accordingly, you can see that the Spec.clusterip is configured with the same value in the previously mentioned Skydns-svc.yaml. In general, creating a service does not require that clusterip,k8s be assigned automatically, but Kube-dns is special and needs to be specified Clusterip to align with nameserver in/etc/resolv.conf.

Modify the nameserver configuration also need to modify two places, one is the--cluster-dns parameter of Kubelet, the other is Kube-dns service Clusterip.

Summarize

Next, re-comb the main content of this article.

In the k8s cluster, the service is running in the pod, and the discovery of pods and the load balancing between replicas are the problems we face.

These two issues can be addressed through the service, but access to the service also requires a corresponding IP, which introduces the issue of service discovery.

Thanks to the Kube-dns plugin, we can access the service within the cluster through the domain name, which solves the problem of service discovery.

In order for the container in the pod to use Kube-dns to resolve the domain name, k8s modifies the/etc/resolv.conf configuration of the container.

With the guarantee of the above mechanism, the service name and namespace can be easily accessed through the pod.

Kubernetes through Kube-dns Discovery Service