Shulou(Shulou.com)05/31 Report--

This article introduces you how to analyze the network principle of Kubernetes, the content is very detailed, interested friends can refer to, hope to be helpful to you.

1. Explanation of 1.1nouns in Linux Network Foundation

Network Namespace (Network Namespace): Linux introduces network namespaces into the network stack to isolate independent network protocol stacks into different command spaces and cannot communicate with each other. Docker uses this feature to achieve network isolation between non-containers.

Iptables/Netfilter:Netfilter is responsible for executing all kinds of hanging rules (filtering, modifying, discarding, etc.) in the kernel and running in kernel mode; Iptables mode is a process running in user mode, which is responsible for maintaining various rule tables of Netfilter in the kernel; by analyzing the network packets entering the host, the header data of the packets are extracted and analyzed to determine whether the online is a release or resistance mechanism. Because this method can directly analyze the packet header data, the information including hardware address (MAC), software address (IP), TCP, UDP, ICMP and other packets can be filtered and analyzed.

Veth device pair: Veth device pair is introduced to enable communication in different network namespaces.

Bridge (Bridge): a bridge is a layer 2 network device and is the simplest CNI network plug-in. It first creates a bridge in Host and then connects the bridge to container netns through veth pair. In addition, in Bridge mode, multi-host network communication requires additional configuration of host routing

Route (routing): the Linux system includes a complete routing function, and the IP layer uses a routing table to determine where to send or forward data.

Container Network Interface (CNI) is the container network specification initiated by CoreOS and is the basis of the Kubernetes network plug-in. The basic idea is that when Container Runtime creates the container, it first creates the network namespace, then calls the CNI plug-in to configure the network for the netns, and then starts the processes in the container.

2. Kubernetes network model

Kubernetes networks have an important basic design principle:

Each Pod has a unique IP

This Pod IP is shared by all containers within the Pod, and all other Pod can be routed to the Pod. Have you ever noticed that some "pause" containers are running on your Kubernetes node? They are called "sandboxie containers" (sandbox containers), and their only task is to retain and hold a network namespace (netns) that is shared by all containers within the Pod. In this way, even if a container dies and a new container is created to replace it, the Pod IP will not change. The great advantage of this IP-per-pod model is that there is no IP or port conflict between Pod and the underlying host. We don't have to worry about what port the application uses.

Once this is met, the only requirement for Kubernetes is that these Pod IP can be accessed by all other Pod, no matter which node those Pod are on.

2.1 intra-node communication

The first step is to ensure that Pod on the same node can communicate with each other, which can then be extended to cross-node communication, communication over the internet, and so on.

Kubernetes Node (root network namespace)

On each Kubernetes node (this scenario refers to the Linux machine), there is a root namespace (root is used as a benchmark, not a superuser)-root netns (root network namespace).

The main network interface eth0 is under this root netns.

Kubernetes Node (pod network namespace)

Similarly, each Pod has its own netns (network namespace), which connects to the root netns through a virtual Ethernet pair. This is basically a pair of pipes, one end in the root netns and the other in the netns of Pod.

We call the network interface on the Pod side eth0, so that Pod does not need to know the underlying host, it thinks it has its own root network device. The other end is named like vethxxx. You can use the ifconfig or ip a command to list all these interfaces on your node.

Kubernetes Node (linux network bridge)

All Pod on the node will complete this process. If these Pod want to communicate with each other, they will use linux's Ethernet bridge cbr0. Docker uses a similar bridge, called docker0. You can use the brctl show command to list all bridges.

Kubernetes Node (same node pod-to-pod communication)

Suppose a network packet is going from pod1 to pod2

It leaves from the eth0 port of netns in pod1 and enters root netns through vethxxx.

It is then passed to cbr0,cbr0 to use the ARP request to say "who owns the IP" to find the destination address.

Vethyyy says it has the IP, so the bridge knows where to forward the packet.

The packet arrives at vethyyy, crosses the pipe pair, and reaches the netns of pod2.

This is the process of communication between content devices on the same node. Of course, there are other ways, but this is undoubtedly the easiest way, and it is also the way adopted by Docker.

2.2 Communication between different nodes

As I mentioned earlier, Pod also needs to be reachable across nodes. Kubernetes doesn't care how to implement it. We can use L2 (ARP cross-node), L3 (IP routing cross-node, like a cloud provider's routing table), Overlay network, or even XGPush. It doesn't matter, as long as the traffic can reach the expected Pod of another node. Each node assigns a unique CIDR block (a range of IP addresses) to the Pod IPs, so each Pod has a unique IP and does not conflict with the Pod on other nodes.

In most cases, especially in the cloud environment, the cloud provider's routing table ensures that the packet reaches the correct destination. We can achieve the same goal by establishing the correct route on each node. Many other web plug-ins do this in their own way.

Here we have two nodes, similar to what we saw before. Each node has a different network namespace, network interface, and bridge.

Kubernetes Nodes with route table (cross node pod-to-pod communication)

Suppose a packet is going from pod1 to pod4 (on different nodes)

It leaves from the eth0 port of netns in pod1 and enters root netns through vethxxx.

It is then sent to cbr0,cbr0 to find the destination address by sending an ARP request.

No Pod on this node has the IP address of pod4. According to the route, the packet is transmitted from cbr0 to the main network interface eth0.

The source address of the packet is pod1 and the destination address is pod4, which leaves the node1 and enters the cable in this way.

The routing table contains routing settings for each node's CIDR block, which routes packets to nodes in the CIDR block that contain the IP of pod4.

So the packet arrives at eth0, the main network interface of node2. Now even if pod4 is not the IP of eth0, packets can still be forwarded to cbr0 because the node is configured with IP forwarding enabled. The routing table of the node looks for any route that matches the pod4 IP. It finds that cbr0 is the target address of the node's CIDR block. You can use the route-n command to list the routing table of the node, which will display the routes for cbr0, as follows:

The bridge receives the packet, sends an ARP request, and discovers that the destination IP belongs to vethyyy.

The packet crosses the pipe pair to reach the pod4.

About how to carry on the Kubernetes network principle analysis to share here, hoped that the above content can have the certain help to everybody, can learn more knowledge. If you think the article is good, you can share it for more people to see.

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.