Kubernetes network model principle

Leader:

Kubernetes seems to have become the most widely used orchestration tool for docker, so if you learn to use docker containers, you will inevitably use Kubernetes, but its network principles are still relatively obscure, so it is still necessary to specifically analyze Kubernetes. network principle.

Kubernetes network model composition

• Network communication between docker containers inside Pod [basic docker network theory]
• Communication between networks where Pods reside [basic docker network theory]
• Network communication between Pod and Service [Kubernetes network theory]
• Network communication between the outside world and Service [Kubernetes network theory]

Network communication between docker containers inside Pod

Kubernetes uses an “IP-per-pod” network model: each Pod is assigned an IP address, and the docker containers inside the Pod share the Pod’s network space, that is, they share the Pod’s network card and IP. The principle is based on docker’s “container network” model.

Communication between networks where Pods reside

Kubernetes “outsources” the bridge network of docker on each node host to flannel, and then collects the bridge network information on each node host through etcd, so the network between each node uses the same network Different IPs ensure the reliability of network communication. The principle is based on docker’s “bridge network” model.

Network communication between Pod and Service

In the Kubernetes system, Pod is unstable, and the IP address of Pod will change, so Kubernetes introduces the concept of Service. Service is an abstract entity. When Kubernetes creates a Service entity, it assigns a virtual IP to it. When the outside world needs to access the functions provided by the container in the Pod, it does not directly use the IP address and port of the Pod, but accesses the Service With this virtual IP and port, the Service forwards the request to the Pod behind it.

When Kubernetes creates a Service, it looks up the Pod according to the Service’s label selector (Label Selector), and creates an EndPoints object with the same name as the Service. When the address of the Pod changes, the EndPoints also change. When Service receives a request, it can find the corresponding Pod through EndPoints. Going deeper, Service is just a virtual concept, and what actually completes the request forwarding is the kube-proxy running on the node node. The virtual IP of Service is implemented by kube-proxy.

kube-proxy has two request forwarding modes: userspace mode and iptables mode. Before Kubernetes v1.1, the default is userspace mode, and after v1.2, the default is iptables mode.

Supplementary description of iptables mode:

When creating a Service, kube-proxy on all node nodes will create two levels of iptables rules, one level is created for Service, the purpose is to transfer the traffic of to the backend, and the other level is EndPoints are created to select Pods. When the value of service.spec.sessionAffinity is “ClientIP”, the algorithm for selecting a Pod in iptables mode is the same as that in userspace mode (selecting a Pod closer to the request source IP). When the service.spec.sessionAffinity value is “None”, Pods are chosen randomly, so if the chosen Pod does not respond, no attempt will be made to choose another Pod.

Network communication between the outside world and Service

①ClusterIP type, this type of Service will only get a virtual IP and port, and can only be accessed inside the Kubernetes cluster. This model is the default type.

②NodePort type, this type of Service will not only get a virtual IP and port, but Kubernetes will also allocate ports to it on all node nodes. The assigned port value can be specified via spec.ports[*].nodePort or assigned by Kubernetes in a configured range (30000-32767 by default). This kind of Service can be accessed from the Kubernetes cluster through the virtual IP:port, or from outside the cluster through the IP:nodePort of the Node node.

③LoadBalancer type, this type of Service will not only get a virtual IP and port, Kubernetes will also allocate ports for it on all Node nodes, and then enable load balancing for it. This kind of Service can be accessed from the Kubernetes cluster through the virtual IP:port, or from outside the cluster through the IP:nodePort of the node node, or through the IP of the load balancer.

Summary

An understanding of the Kubernetes network model will give you a deeper understanding of using services provided by third-party manufacturers, such as Alibaba Cloud and Huawei Cloud, which already fully support Kubernetes orchestration. It involves a lot of basic principles of Kubernetes. Looking back and thinking about it carefully, it is nothing more than changing.