Outline:
? How to discover services in Kubernetes
? How to discover the services provided by pod
? How to use service discovery Services
? How to use the Kube-dns discovery service
? Kube-dns principle
? Composition
? 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 services in Kubernetes
Discover the services provided by the pod
First use the Nginx-deployment.yaml file to create a nginx deployment, the contents of the File:
First create two pods that run the Nginx service:
Created with the Kubectl create-f Nginx-deployment.yaml command, You get two pods that run Nginx Services. After the pod runs, look at their IP and access the Nginx service through Podip and Containerport within the k8s cluster:
Get pod IP:
Access Nginx services within the Cluster:
See here that many people will have the following questions:
1. Every time you get podip, you can't always change the program or configuration to access the service, how do you know Podip in advance?
2. Pod may be rebuilt in operation, IP changed how to solve?
3. How do I load balance in multiple pods?
These issues can be resolved using the k8s service.
Using Service discovery Services
below, Create a service for two nginx pods. Use the Nginx-service.yaml file to create the file with the following contents:
After creation, you still need to get the service cluster-ip, and then combine port to access the Nginx service.
The service can encapsulate the pod ip, and even if the pod is rebuilt, it can still access the services provided by the pod through a service. In addition, the service solves the problem of load balancing, you can access the service several times, and then through the Kubectl logs <pod name> to view the two Nginx Pod access logs to Confirm.
Get Ip:
Accessing the service within the Cluster:
While the service solves pod discovery and load balancing problems, there are similar problems: don't know the Service's IP in advance, or you need to change the program or Configuration. See if there is any feeling that the body is hollowed out?
Let's talk about how Kube-dns solves this Problem.
Using the Kube-dns Discovery service
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.
Someone might ask what to do if Kube-dns is not deployed in the cluster? It doesn't matter, actually the Kube-dns plugin is just a pod running under the Kube-system namespace and can be created 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 share, only a portion of the PPT is Intercepted.
Create the Kube-dns Pod from the Skydns-rc.yaml file, which contains four containers, which begins with a brief introduction to the main part of the file, which is described in more detail later.
In the first section, you can see that Kube-dns uses RC to manage pods, providing the most basic failure restart Functionality.
Create a Kube-dns Pod with 4 containers
Next is the first container, etcd, whose purpose is to save the DNS Rules.
The second container is kube2sky, and the function is 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 to allow other pods in the cluster to access the DNS query Service. Create a service from Skydns-svc.yaml as Follows:
After you create the Kube-dns pod and service, and the pod runs, you can access the Kube-dns service.
Create a pod below and access the Nginx service in that pod:
Wait for Kube-dns to run after creation
Create a new pod to access the Nginx service
Access the My-nginx service through the service name in the Curl-util pod:
As long as you know the name of the service you need to access, using the Kube-dns Discovery Service is as simple as that.
Although I appreciate the convenience of using Kube-dns Discovery service, I believe many people are also confused: how does Kube-dns work? With the Kube-dns plugin enabled in the cluster, how can you access the service by name?
2.
Kube-dns principle
Kube-dns composition
It has been learned that Kube-dns is made up of four containers, and the roles they play can be understood by the following Diagram.
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 restart the Kube2sky to re-write the DNS Rules.
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.
3. 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.
4.
Summary
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.
5.
Q&a
1. Q: If the company already has application access, then the existing non-access applications will not be able to access, because the service is found inside the k8s cluster, external inaccessible. The main is k8s in the Cluster service and the outside of the Cluster's own production domain access how to achieve, can be integrated in the kube-dns?
A: Two questions can be abstracted as k8s Intra-cluster and Out-of-cluster service connectivity issues, we say from two aspects:
first, In-cluster access to the cluster outside
This is a simple question, and the pod in the cluster inherits the DNS parsing rules on Node. So as long as node can access the service, The pod can also be accessed.
In addition, in version 1.4, k8s supports a externalname type of service that can be bound to a public domain name that provides access to the corresponding public network Service.
second, Out-of-cluster access within the cluster
1. The service can be set to the Nodeport type so that the service can be accessed through any Node's IP and service port. A scenario that is less suitable for external service than the Other.
2. The services within the cluster can be exposed externally through kube-proxy.
3. Customize the implementation of the reverse proxy in the cluster according to the actual Situation.
2. Q: I would like to ask the next ETCD this container can be omitted? K8s Cluster has ETCD can not be shared?
A: In theory, you can share Etcd. Consider the separation from the perspective of isolation, so that the Kube-dns service will not affect the stability of the entire k8s cluster. In addition, if you consider Kube-dns as a microservices, you should ensure that the internal components are not externally dependent and can be run independently.
Kubernetes How to implement service discovery with Kube-dns