Kubernetes proposes its own network model "IP-per-pod", which can well meet the network requirements of the cluster system. It has the following four basic assumptions:
- Each Pod in the cluster will have a unique IP address.
- All containers in the Pod share this IP address.
- All Pods in the cluster belong to the same network segment.
- Pods can directly access another Pod based on IP address without the need for troublesome network address translation (NAT).
Because Pods have independent IP addresses, which are equivalent to a virtual machine, and are directly connected to each other, domain name resolution, load balancing, and service discovery can be easily implemented. Previous operation and maintenance experience can be used directly. Application management and migration are very friendly.
CNI defines a series of common interfaces for network plug-ins. As long as developers follow this specification, they can access Kubernetes, create virtual network cards for pods, assign IP addresses, set routing rules, and finally realize the "IP-per-pod" network model .
According to different implementation technologies, CNI plug-ins can be roughly divided into three types: "Overlay", "Route" and "Underlay".
The original meaning of Overlay is "coverage", which means that it builds a "logical network" that works on the real underlying network, packets the original Pod network data, sends it out through the underlying network, and then unpacks it at the destination. Because of this feature, it has low requirements on the underlying network and strong adaptability. The disadvantage is that there is additional transmission cost and low performance.
Route also works on the underlying network, but instead of encapsulating and unpacking, it uses the built-in routing function of the system to realize Pod cross-host communication. Its advantage is high performance, but it has a strong dependence on the underlying network. If the underlying network does not support it, it will not work.
Underlay is to directly use the underlying network to implement CNI, that is to say, the Pod and the host are in the same network, and the Pod and the host are equal. It has the strongest dependence on the underlying hardware and network, so it is not flexible enough, but it has the highest performance.
Flannel was originally a network plug-in in Overlay mode, using UDP and VXLAN technology, and later supported Route mode with Host-Gateway technology. Flannel is easy to use and is the most popular CNI plugin in Kubernetes, but its performance is not very good, so it is generally not recommended to be used in a production environment.
Calico is a network plug-in in Route mode. It uses BGP (Border Gateway Protocol) to maintain routing information. Its performance is better than Flannel, and it supports a variety of network strategies, with functions such as data encryption, security isolation, and traffic shaping.
Cilium is a relatively new network plug-in that supports both Overlay mode and Route mode. It is characterized by the deep use of Linux eBPF technology and operates network data at the kernel level, so it has high performance and can flexibly implement various functions. In 2021 it joined CNCF as an incubation project and is a very promising CNI plugin.
This article is a study note for Day 25 in July. The content comes from Geek Time "Kubernetes Introductory Practical Course". This course is recommended.