CNI
最后更新于
最后更新于
Originally launched by CoreOS, the Container Network Interface (CNI) has become the core of networking plugins for Kubernetes. At the heart of CNI lies a simple idea: the container runtime should first establish a network namespace (netns), then invoke the CNI plugin to configure the network for this netns, before finally starting the container's processes. Now under the wing of the Cloud Native Computing Foundation (CNCF), it has become the networking model primarily endorsed by the CNCF.
CNI plugins are split into two key components:
CNI Plugin, responsible for setting up the container's network, includes two basic interfaces:
Network configuration: AddNetwork(net_NetworkConfig, rt_RuntimeConf) (types.Result, error)
Network cleanup: DelNetwork(net_NetworkConfig, rt_RuntimeConf) error
IPAM Plugin, tasked with allocating IP addresses to the container. It typically implements host-local and DHCP options.
For Kubernetes Pods, the networking setup for containers within the Pod follows the network of the Pod's designated 'pause' container. The creation process involves:
kubelet first creates the 'pause' container, generating a network namespace,
then triggers the network CNI driver,
the CNI driver, based on the configuration, calls the specific CNI plugin,
the CNI plugin sets up the network for the 'pause' container,
and then all other containers in the Pod use the 'pause' container's network.
All CNI plugins support passing parameters through environment variables and standard input:
A selection of well-known CNI network plugins:
CNI also supports the concept of Plugin Chains, where a list of plugins is specified, and each is executed in turn by the Runtime. This is particularly useful for supporting features like port mapping and virtual machines. An example configuration method is outlined in the port mapping example section below.
The Bridge plugin, one of the simplest CNI network plugins, creates a network bridge on the Host before connecting the container netns via a veth pair.
Important: In Bridge mode, multi-host network communication requires additional host routing configuration or an overlay network. Tools like Flannel or Quagga for dynamic routing can be used to automate the process. An overlay network structure example:
Configuration example:
Testing network setup and teardown with cnitool:
The DHCP plugin is a primary IPAM plugin that assigns IP addresses to containers using DHCP. This plugin is also utilized in the macvlan setup.
To use the DHCP plugin, you first need to start a dhcp daemon:
Then configure the network to use dhcp as the IPAM plugin:
The host-local plugin is one of the most commonly used CNI IPAM plugins, designed to allocate IP addresses to containers.
IPv4 example:
IPv6 example:
The ptp (point-to-point) plugin establishes point-to-point connectivity between the container and the host using a veth pair.
Configuration example:
IPVLAN is similar to MACVLAN as it also virtualizes multiple network interfaces from a single host interface. A key difference is that all virtual interfaces share the same MAC address but have unique IP addresses.
IPVLAN supports two modes:
L2 mode works similarly to macvlan bridge mode, where the parent interface acts like a switch forwarding data to its child interfaces.
L3 mode functions more like a router, handling routing of packets between the various virtual networks and the host network.
Creating an ipvlan is straightforward:
The CNI configuration looks like:
It's important to note:
Containers cannot communicate with the host network under the ipvlan plugin.
The host interface (the master interface) cannot simultaneously serve as a master for both ipvlan and macvlan.
MACVLAN allows virtualization of multiple macvtap devices from a host interface, each with its own unique MAC address.
There are four modes for MACVLAN:
bridge mode allows data forwarding among children of the same master.
vepa mode requires external switch support for Hairpin mode.
private mode ensures isolation among MACVTAPs.
passthrough mode offloads data handling to hardware, liberating Host CPU resources.
The simple creation method for macvlan is:
The CNI configuration format:
Keep in mind:
macvlan requires many MAC addresses, one per virtual interface.
It cannot work with 802.11 (wireless) networks.
The host interface cannot serve as a master for both ipvlan and macvlan.
For further details and other networking solutions, including Flannel, Weave Net, Contiv, Calico, OVN, SR-IOV, Canal, kuryr-kubernetes, Cilium, CNI-Genie, and more, please visit the respective project pages.
CNI SPEC supports network configuration lists that include multiple network plugins to be executed by the Runtime in sequence. Note:
For ADD operations, the plugins are called in order; for DEL operations, the order is reversed.
For ADD operations, all but the last plugin need to append a prevResult to pass to the subsequent plugin.
The first plugin in the list must include an IPAM plugin.
An example illustrating the use of the bridge and portmap plugins.
First, configure the CNI network to use bridge+portmap plugins:
Set port mapping arguments with CAP_ARGS:
Test adding the network interface:
See added rules in iptables:
Finally, remove the network interface:
Other noteworthy projects include Canal, which combines Flannel and Calico, and CNI-Genie from Huawei PaaS, which supports multiple network plugins simultaneously.
