Article for the service discovery Kubernetes
https://www.kubernetes.org.cn/7014.html
Kubernetes Service discovery is often a confusion of one of my themes. This paper is divided into two parts:
Background knowledge networks of
understanding Kubernetes service discovery
to understand service discovery, we must first understand the network of knowledge behind it. This part is relatively simple and obvious, if the reader familiar with this part, can skip directly read service discovery section.
Before the start there is a need to be reminded to do is order a detailed description of this process, the paper slightly longer.
Kubernetes network infrastructure
Prior to the beginning of the service of discovery, need to understand the following:
Kubernetes application running in the container, which is within the Pod.
Each Pod are attached to the same in a large flat IP network, the network is called Pod (typically VXLAN overlay network).
Each Pod has its own unique IP address, the IP address is routable in the Pod network.
The three factors combined, so that each application (application components and services) without going through a network NAT process and the like, can communicate directly.
Dynamic network
when the application horizontal expansion, will join the new network in the Pod Pod, a new Pod naturally accompanied by a new IP address; if the application is reduced in volume, the old Pod and IP will be deleted. This may seem confusing.
Scroll update and withdrawal of the application there is the same situation - including a new version of the new Pod, or remove the old version of the old Pod. The new Pod Pod will be added to the new IP network, the end of the old Pod will remove its existing IP.
If there are no other factors, each application services are required to monitor the network and manage a list of health Pod. This process can be very painful, in addition to write this logic in each application is very inefficient. Fortunately, Kubernetes with a target completion of this process --Service.
This object is called the Service is a bad idea, we have used this word to describe the process of the application or component.
Another thing to note: Kubernetes performs IP address management (IPAM) functions, the Pod network of used and available IP address tracking.
Service to bring stability
Kubernetes Service object to create a stable network endpoints before a group of Pod to provide services, and load distribution for those Pod.
It is completed within a set of objects placed before a Service Pod same work. For example, can provide a front-end Web Service in your front Pod, providing another before certification services Pod. Prior to the exercise of different responsibilities Pod should not use a single Service.
Client Service and Communication, Service is responsible for traffic load balancing to the Pod.
In the figure above, Pod bottom because of stretching, situation updates, failure to change, and these changes will be tracked Service. At the same time Service name, IP and port will not change.
Kubernetes Service resolved
Kubernetes Service can be understood as the front and back end of two parts:
Front: name, IP and port of the same part.
Rear: Pod set of selection criteria that meet specific tag.
The front end is stable and reliable, its name, IP and port will not change throughout the life cycle Service. Stability means that the front end without worrying about client DNS cache timeout issues.
The rear end is highly dynamic, wherein tag includes a set of selection criteria Pod meet, it will be accessible through the load balancing manner.
Where load balancing is a simple four-layer polling. It operates at the connection level, so all requests initiated in the same connection will enter with a Pod. Because 4 layers work, so for the first seven layers of stuff HTTP Cookie or the like can not be perceived.
Summary
application running in the container, in Kubernetes embodied in the form of Pod. All Pod Kubernetes cluster are in the same plane Pod network has its own IP address. This means that among all the Pod can be directly connected. However Pod is unstable, it may be created and destroyed due to various factors. Kubernetes provides a stable network endpoint, referred to as a-Service, the object in front of a group of similar Pod, provides a stable name, IP and port. The client is connected to the Service, Service to traffic load balancing to the Pod.
Next chat service discovery.
Depth understanding of Kubernetes service discovery
Service discovery actually consists of two functions:
1, the service registered
2, service discovery
Service Registration
Service registration process refers to the registration of a service registry service, so that other service discovery.
Kubernetes use DNS as a service registry.
To meet this need, each Kubernetes cluster will be in the form of kube-system name space with a Pod run DNS service, commonly referred to as cluster DNS.
Each Kubernetes service will be automatically registered in DNS cluster.
The registration process is as follows:
Service to submit a new way to define a POST API Server;
this will be released after a request needs authentication, authorization, and other admission policies inspection process;
Service to get a ClusterIP (virtual IP address), and save it to a data warehouse cluster ;
disseminate service configuration within a cluster;
cluster DNS service that creates the service, pursuant to create the necessary DNS a record.
The above procedure, the fifth step is the key. DNS cluster using CoreDNS, to Kubernetes run in the form of native applications. CoreDNS implements a controller, will listen API Server, if found to have the new Service object, you create a mapping from domain name to the Service's records ClusterIP. Such Service will not have to register itself with DNS, CoreDNS controller will focus on Service newly created object, and to achieve subsequent DNS process.
DNS name is registered in metadata.name, and ClusterIP by Kubernetes discretionary.
Other Pod After Service object is registered to the cluster in DNS, it can be run in a cluster discovered.
Endpoint objects
After the front-end Service successfully created and registered with the service registry (DNS), the rest is the back-end work. Pod includes a back-end list, Service Object Flow will be distributed to those Pod.
There is no doubt that this list needs to Pod is up to date.
Service object has a Label Selector field, which is a list of labels, in line with a list of conditions Pod will be incorporated into the service range of load balancing services. See the following figure:
Kubernetes automatically create Endpoints object for each Service. Responsibilities Endpoints object is to save a line with Service tag selector Pod standard list of these Pod will receive traffic from the Service.
The following figure, Service will choose two Pod, and also shows Endpoints Service of the object, the object contains two selection criteria in line with Service Pod of IP.
Later we will explain how to ClusterIP network traffic forwarded to the Pod IP process, but also references to Endpoints object.
Service Discovery
We assume a Kubernetes have two front-end application, my-app and your-app, my-app of Pod is a my-app-svc of Service object called cluster; before your-app Pod Service is your- app-svc.
The two Service objects corresponding DNS record is:
my-app-svc：10.0.0.10
your-app-svc：10.0.0.20
To use the service discovery function, each Pod needs to know the location of the cluster DNS in order to use it. Thus each Pod /etc/resolv.conf file in each container is configured to use the cluster analyzing DNS.
If my-app in the Pod want to connect to your-app in the Pod, you have to initiate a query for the domain name your-app-svc to the DNS server. They assume that the local DNS cache does not resolve this record, you need to make inquiries submitted to the cluster DNS server. You will get you-app-svc of ClusterIP (VIP).
There is a premise that my-app need to know the name of the target service.
At this point, my-app in the Pod has been a destination IP address, but this is just a virtual IP, before moving target Pod, some networks work to do.
The internet
After a Pod has been ClusterIP Service, we try to send traffic to the IP. However, the network ClusterIP located is called Service Network, this network a bit special - no route to it.
Because there is no route to find all container traffic that is sent to the address of the default gateway (called the bridge CBR0). The traffic will be forwarded to the card on the node where the Pod. Network stack node is also no route to reach the Service Network, it can only be sent to the default gateway. Default gateway routing node to the data packets will pass Node core - has changed here.
Review of the earlier content. First Configuration Service object is a full range of valid clusters, the other will comes Endpoints object again. We want to find their respective responsibilities in the process of the review.
Each Kubernetes node runs called kube-proxy system services. This is based on the Kubernetes Pod run native applications, the controller monitors the changes it implements the Service API Server, and accordingly create or IPVS iptables rules that inform nodes, target capture packets Service network, and forwarded to the Pod IP.
Interestingly, kube-proxy agent is not a general sense. It works, but is to create and manage iptables / IPVS rules. The named because it used in the past unserspace model agency.
Each new Service Configuration object, which contains its ClusterIP and Endpoints objects (which contains a list of health Pod), will be sent to kube-proxy process on each node. kube-proxy will be created or IPVS iptables rules, inform node capture targets for Service ClusterIP traffic, and forwarded to the corresponding Pod Endpoints based on the content of the object.
That is to say each time a node is a Service-core processing to the target network packet, the packet will be on the Header rewritten, changed the destination IP Service Endpoints object healthy Pod of IP.
iptables originally used is being replaced by IPVS (Kubernetes 1.11 into the stable). Long story short, a packet filter iptables is not designed for the load balance. IPVS a load balancer 4 is a layer, the performance and implementations better suited than iptables usage scenario.
to sum up
We need to digest a lot of content, brief review.
When you create a new Service object, you will get a virtual IP, is called ClusterIP. Service names and their ClusterIP be automatically registered to the DNS cluster, and will create the relevant objects used to hold Endpoints in line with the list of health conditions Pod label, Service objects to the list of forwarding traffic Pod.
At the same time all nodes in the cluster will configure the iptables / IPVS rules, monitoring goals for the flow ClusterIP and forwarded to the real Pod IP. This process is shown below:
Pod Pod a need to connect with other Service. First sent to the cluster DNS queries, the Service name resolves to ClusterIP, then send traffic to the located on the Service web ClusterIP. But not to the Service network routing, so Pod to send traffic to its default gateway. This behavior causes traffic is forwarded to the node where the NIC's Pod, then the default gateway nodes. In this operation, the node changes the target kernel IP packet Header is, steering health Pod.
Pod eventually all are on the same flat routable overlay network, the content of remaining very simple.
Author: Nigel Poulton
Source & Translator: pseudo-architect