CNI network model of k8s

The background and purpose of k8s network model

As an orchestration engine, k8s manages containers and Pods distributed on different nodes. Pod, Service, and external components need a reliable way to find batches and communicate with each other. At this time, the k8s network is responsible for providing this guarantee. The following will introduce the following:

k8s network model;
Various network solutions implemented by k8s based on CNI;
Network Policy Network Policy;

How do the various entities in the cluster communicate under the k8s network model?

=》1.Communication between Pod Inner Containers

When a Pod is scheduled to a node, all containers in the Pod run on this node, and these containers share the same local file system, IPC, and network namespace.
There is no problem of port conflicts between different Pods, because each Pod has its own IP address. When a container uses lalhost, it means that the address space of the Pod to which the container belongs is used.
For example, PodA has two containers, container-AI and container-A2. Container-A1 listens on port 1234. When container-A2 connects to laltost:12324, it is actually accessing cntaine-Al. This will not conflict with PodB on the same node, even if the container-BI in PodB is listening on port 1234.

=》2.Communication between Pod

The Pod’s IP is visible to the cluster, that is, any other Pod and nodes in the cluster can directly communicate with the Pod through IP. This communication does not require any network address translation, tunneling or proxy technology. Pod uses Internet IP both internally and externally, which also means that standard naming services and discovery mechanisms, such as DNS, can be used directly.

=》3.Communication between Pod and Service

Pod can communicate directly through IP address, but the premise is that the Pod knows the other party's IP. In a Kabenete cluster, Pod may be frequently sold and created, which means that the IP of the Pod is not fixed. To solve this problem, Service provides an abstraction layer for accessing Pod. No matter how the back-end Pod changes, Service provides services as a stable front-end. At the same time, Serice also provides high availability and load balancing functions, and Service is responsible for forwarding requests to the correct Pod.

=》4. External access

Whether it is the Pod's IP or the Service's Cluster IP, they can only be seen in the Kubermetes cluster. These IPs are private to the world outside the cluster.
Kubermetes provides two ways for the outside world to communicate with Pod:

●[NodePort<->Service] Provide external services through the static port of the Cluster node. The outside can access the Service through <NodelP>:<NodePort> .
●【LodBalancer<->Service】Use the load balancer provided by the cloud provider to provide external services. The cloud prorider directs the load balancer traffic to the Service. Currently supported cloud providers include GCP, AWS, Azure, Aliyun, Tencent cloud, etc.

CNI (Container Network Interface) network model

=》CNI is a container network specification proposed by CoreOS. It uses a plug-in (Pugin) model to create a container network stack. The k8s network uses this CNI network model specification;

For a long time, k8s does not have a dedicated network module responsible for network configuration. It requires the user to have configured the network on the host.

Kubernetes requirements for the network:

One Pod has one IP, and the IP is unique in the global cluster environment;
All Pods can communicate directly with any other Pod;
The IP address obtained inside the Pod is the same as the IP address through which other Pod or nodes communicate with it;
Containers (including containers on the same host and containers on different hosts) can communicate with each other;
The container and all nodes in the cluster can also communicate directly;

k8s uses a network model based on a flat address space. Each Pod in the cluster has its own IP address. Pods can communicate directly without configuring NAT; in addition, containers in the same Pod share the Pod’s IP, which can Communicate via localhost;

The development direction of the k8s network is to integrate different network solutions through plug-ins, and CNI is the result of this effort. CNI only focuses on the solution of container network connection and the release of resources when the container is destroyed, and provides a framework. Therefore, CNI can support a large number of different network modes and is easy to implement. This network model is quite friendly to application developers and administrators. It is very convenient to migrate from traditional network to k8s. Each Pod can be regarded as an independent system, and the containers in the Pod can be regarded as different processes in the same system.

Advantages of CNI

The advantage of CNI is that it supports multiple container runtimes, not just Docker. CNI's plug-in model supports third-party plug-ins developed by different organizations and companies, which is very attractive to operation and maintenance personnel and can flexibly choose suitable network solutions.
There are many network solutions that support k8s, such as Flannel, Calico, Canal, Weave Net, etc. Because they all implement the CNI specification, no matter which solution the user chooses, the network model obtained is the same, that is, each Pod has an independent IP and can communicate directly.
The difference lies in the different underlying implementations of different schemes. Some are implemented using VxLAN-based Overlay, while others are Underay, which differ in performance. Then there is whether to support Network Policy.

Network Policy/Network Policy

Network Policy is a resource of k8s. Network Policy selects Pods through Label, and specifies how other Pods or the outside world communicate with these Pods.
By default, all Pods are non-isolated, that is, network traffic from any source can access Pods without any restrictions. When a Network Policy is defined for a Pod, only traffic allowed by the Policy can access the Pod.
However, not all Kubernetes network solutions support Network Policy. For example, Flannel does not support it, but Calico does. We will use Canal to demonstrate Network Poliy next. Canal is an interesting open source project. It uses Flannel to implement a Kubernetes cluster network and Calico to implement Network Poliy.

More view: https://kubernetes.io/zh/docs/concepts/services-networking/network-policies/

k8s network solution based on CNI network model

The network model is there, how to implement it next?

Network implementation steps=》https://blog.csdn.net/liukuan73/article/details/78883847

Various network solutions based on kubeadm installation:

Deploying Canal
Deploying Canal is very similar to deploying other Kubernetes network solutions. They both install the corresponding network solution through klee 4 after executing the kubeadm init initial Rsbenee cluster. In other words, there is no good way to directly switch to different networks Scheme, basically can only re-create the cluster.