Recently, I have been working on PaaS content, and I have just come into contact with Kubernetes, which involves network coverage, that is, communication between cross-host containers. So a series of open source components have emerged, such as flannel, calico, weave, etc. Here are mainly Calico and Fannel.
Flannel principle
Flannel, a project developed by CoreOS, is probably the most direct and popular CNI plugin. It is one of the most mature examples of network architecture in container orchestration systems and is designed to enable better inter-container and inter-host networking. With the rise of the CNI concept, the Flannel CNI plugin is an early introduction.
Flannel is relatively easy to install and configure compared to other options. It is packaged as a single binary FlannelD, and many common Kubernetes cluster deployment tools and many Kubernetes distributions can install Flannel by default. Flannel can use the existing etcd cluster of the Kubernetes cluster to store its state information using the API, so it does not require a dedicated data store.
Flannel configures a Layer 3 IPv4 overlay network. It creates a large internal network that spans every node in the cluster. In this Overlay network, each node has a subnet that is used to assign IP addresses internally. When configuring a pod, the Docker bridge interface on each node assigns an address to each new container. Pods in the same host can communicate using Docker bridges, while pods on different hosts use flanneld to encapsulate their traffic in UDP packets so that they can be routed to the appropriate destination.
Flannel has several different types of backends that can be used for encapsulation and routing. The default and recommended approach is to use VXLAN because VXLAN performs better and requires less manual intervention.
Calico architecture
The calico includes the following important components: Felix, etcd, BGP Client, and BGP Route Reflector. The following are the explanations of each of these components.
Felix: Mainly responsible for routing configuration, ACLS rule configuration and delivery, it exists on each node.
etcd: Distributed key-value store, mainly responsible for network metadata consistency, ensuring the accuracy of Calico network state, can be shared with kubernetes;
BGPClient (BIRD) is mainly responsible for distributing the routing information written by Felix to the kernel to the current Calico network to ensure the effectiveness of communication between workloads.
BGPRoute Reflector (BIRD) is used in large-scale deployments, abandoning the mesh mode of interconnecting all nodes, and using one or more BGPRoute Reflectors to complete centralized routing and distribution.
The calico principle
As shown in the following diagram, the process is depicted from the source container through the source host, through the routing of the data center, and finally to the destination host and finally assigned to the destination container.
Contrast
From the above principle, it can be seen that flannel performs packet unpacking operations on the basis of routing forwarding, which wastes CPU computing resources. The chart below compares the performance of various open source network components found online. It can be seen that in terms of bandwidth and network latency, the performance of Calico and the host is similar.
|
Posted on 11/9/2020 11:23:01 AM
|
|
|
|
