Kubernetes (k8s) How to use Kube-dns to implement service discovery

Outline: How to discover services in KubernetesHow to discover how pod-provided services use the Service Discovery service to use the Kube-dns discovery service Kube-dns principleCompose domain name format configuration

Note: This share is based on the Kubernetes 1.2 version.

Let's start with a simple example. 1. How to discover service in Kubernetes

Discover pod-provided services

First create a Nginx deployment using the Nginx-deployment.yaml file, as shown in the figure:

First, create two pods that run the Nginx service:

Created using the Kubectl create-f nginx-deployment.yaml directive, which allows you to get two of the pods that run the Nginx service. Look at their IP after the pod is run and access the Nginx service through Podip and Containerport within the k8s cluster:

Get pod IP:

Access to Nginx services within the cluster:

See here believe a lot of people will have the following questions: Every time to get podip too pull, always can not manually change the program or configure to access the service, how to know in advance podip it. Pod may be rebuilt in operation, IP changed how to solve. How to achieve load balancing in multiple pods.

These problems can be solved using k8s service. using Service discovery Services

A service is created for two nginx pods below. Created using the Nginx-service.yaml file, the contents of the file are as follows:

After creation, you still need to obtain the cluster-ip of the service, and then combine port to access the Nginx service.

The service can encapsulate the pod IP, and even if the pod is rebuilt, the services provided by the pod can be accessed through service. In addition, the service also solves the problem of load balancing, you can access several service, and then through the Kubectl logs <pod name> to check two nginx Pod access logs to confirm.

Get IP:

Access Service within the cluster:

Although service solves the problem of pod discovery and load balancing, there is a similar problem: Do not know the service IP in advance, or need to change the program or configuration ah. See if there is any feeling of the body being hollowed out.

Next, let's talk about how Kube-dns solves the problem. using the Kube-dns Discovery service

Kube-dns can solve the service discovery problem, k8s the name of the service as a domain name into the Kube-dns, through the name of the service can access its services provided.

One might ask what to do if Kube-dns is not deployed in the cluster. It doesn't matter, actually the Kube-dns plug-in just runs the pod under the Kube-system namespace, and it's completely possible to create it manually. Can be in the k8s source code (v1.2) cluster/addons/ The DNS directory found two templates (Skydns-rc.yaml.in and skydns-svc.yaml.in) to create, a complete sample file for everyone to provide access after the end of the sharing, the PPT only part of the interception.

Creating Kube-dns Pod from the Skydns-rc.yaml file, which contains four containers, starts with a brief introduction to the main part of the file.

The first part can be seen Kube-dns use RC to manage pod, can provide the most basic failure restart function.

Create Kube-dns Pod, which contains 4 containers

Next is the first container etcd, which is used to save DNS rules.

The second container is Kube2sky to write DNS rules.

The third container is Skydns, which provides a DNS resolution service.

The last container is Healthz, which provides a health check function.

With pod, you also need to create a service so that other pods in the cluster can access the DNS Query service. The service is created through SKYDNS-SVC.YAML, which reads as follows:

After you create the Kube-dns pod and service, and the pod runs, you can access the Kube-dns service.

The following creates a pod and accesses the Nginx service in the pod:

Wait for Kube-dns to run after creation

Create a new pod and access the Nginx service through it

Access My-nginx service via service name in Curl-util pod:

As long as you know the name of the service you need to access, using the Kube-dns Discovery service is that simple.

Although a taste of the use of Kube-dns discovery Services convenience, but I believe that many people are also confused: Kube-dns exactly how to work. With the Kube-dns plug-in enabled in the cluster, how can you access the service by name? 2, Kube-dns principle Kube-dns Composition

It has been learned before that Kube-dns is made up of four containers, and the roles they play can be understood in the following diagram.

Among them: Skydns is an open source framework for service discovery, built on top of ETCD. The function is to provide a DNS query interface for the pod in the Kubernetes cluster. The project is hosted on Https://github.com/skynetservices/skydns Etcd is an open-source, distributed, key-value storage that functions like zookeeper. The function in Kube-dns is to store the various data that the SKYDNS needs, the writer is Kube2sky, and the reader is skydns. The project is hosted by HTTPS://GITHUB.COM/COREOS/ETCD. Kube2sky is an adapter implemented by k8s that invokes K8s's list and watch APIs by using a service called kubernetes (through Kubectl get Svc to view the service, which is created automatically by the cluster) to monitor k8s Changes to the service resources to modify the Skydns records in the ETCD. The code can be found in the cluster/addons/dns/kube2sky/directory of k8s Source (v1.2). Exec-healthz is a secondary container provided by k8s, 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 role in Kube-dns is to check the health status of the DNS Query service through the nslookup instruction, k8s Livenessprobe to understand health status by accessing the HTTP APIs provided by Exec-healthz, and to restart the container in the case of a failure. Its source code is located in Https://github.com/kubernetes/contrib/tree/master/exec-healthz. As you can see from the diagram, the pod query DNS is queried by Servicename.namespace subdomains, but in the previous example, only the service name was used. In fact, when we use only the service name, the default namespace defaults, and the My-nginx service in the above example is in the default namespace, so it works. On this point, the follow-up further in-depth introduction. In Skydns-rc.yaml, the livenessprobe is found in the Kube2sky container, and is intended to be rewritten to the DNS rule by restarting the Kube2sky.Domain name format

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

Where cluster_domain can be set with the Kubelet –cluster-domain=somedomain parameters, and also to ensure that the –domain parameter in the startup parameters of the Kube2sky container has the same value set. usually set to cluster.local. The complete domain name for the My-nginx service in the previous example is my-nginx.default.svc.cluster.local. See here, I believe many people will have questions, since the full domain name is such, then why in the pod only through the service name and namespace can access the service. Let's explain why. 3, Configuration Domain Name resolution configuration

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

Interested in the Internet can find some resolv.conf information to understand the specific meaning. The ability to access service through service names and namespace is due to the rules for search configuration. In the resolution domain name will be automatically spliced into a full domain name to query DNS.

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

Kube-dns can let the pod discover other service, how does pod discover Kube-dns automatically again. 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 in the previous mentioned Skydns-svc.yaml that Spec.clusterip has the same value configured. Typically, creating a service does not require that clusterip,k8s be assigned automatically, but Kube-dns is special and needs to be specified Clusterip to keep it consistent with nameserver in/etc/resolv.conf.

Modify the nameserver configuration also need to modify two places, one is kubelet –cluster-dns parameter, the other is Kube-dns service Clusterip. 4, Summary

Next, comb through the main contents of this article: in the k8s cluster, services are run in pod, the discovery of pod and the load balance between replicas are the problems we face. These two problems can be solved by service, but the Access service also needs the corresponding IP, so the problem of service discovery is introduced. Thanks to the Kube-dns plug-in, we can access the service in the cluster through the domain name to solve 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, it is easy to access the corresponding service in Pod by service name and namespace.

Link Address: Click Open link