What Is a Container Network Interface (CNI)?
A Container Network Interface (CNI) is a standardized framework for configuring network interfaces in Linux containers. It defines how container runtimes, such as containerd or CRI-O, should invoke network plugins to attach a pod to a network, assign IP addresses, and configure routing. CNI itself does not provide networking, it specifies how plugins should integrate with orchestration systems like Kubernetes.
When a pod is created, the container runtime calls a CNI plugin with commands such as ADD, DEL, or CHECK. The plugin then configures the network interface inside the container namespace, assigns an IP address, and updates routing rules. This modular design allows Kubernetes to support multiple networking implementations without changing core components.
Common Kubernetes CNI network models, described in more detail in this article:
- Encapsulated (overlay) networks (e.g., VXLAN, IP-in-IP)
- Unencapsulated (routed / BGP) networks
- eBPF-based networking models
- Cloud-provider and managed Kubernetes CNIs
This is part of a series of articles about Kubernetes networking.
In this article:
- Kubernetes Networking Explained
- Why Kubernetes CNI?
- What Network Models Are Used in CNI?
- Enterprise Kubernetes Networking with Calico
Kubernetes Networking Explained
Kubernetes is an open-source container orchestration platform developed by Google. It is used for managing and automating application container deployments across multiple machine clusters. Kubernetes allows you to operate, schedule, monitor, and maintain containerized workloads.
Kubernetes can also be used for networking, which lets administrators move workloads between different cloud infrastructures, including public, private, and hybrid clouds. Kubernetes allows developers to quickly package and deploy applications using their preferred infrastructure, which is useful for developing new versions.
These capabilities also extend to Kubernetes multi cluster environments, where workloads and networking policies span multiple clusters across different regions or cloud providers.
With Kubernetes networking, Kubernetes components can communicate with different applications and with each other. Kubernetes differs from other networking platforms in that it has a flat network structure, which means that host ports don’t have to be mapped to container ports. It allows you to run a distributed system, with machines being shared between applications without the need for dynamic port allocation.
Because CNI plugins control how pods connect, isolate, and route traffic, the choice of plugin has a direct impact on container security, shaping how network policies, segmentation, and east-west traffic controls are enforced across the cluster.
Initially, containers (pods) don’t have a network interface. To create a network interface for a container, the container runtime sends an ADD command to the CNI plugin (the runtime can call the plugin with commands like ADD, DEL, and CHECK). Once the new network interface is created, a JSON payload passes the details of what needs to be added to the CNI.
Why Kubernetes CNI?
Both Linux container and container networking technology are continuing to evolve to meet the needs of applications running in various environments. CNI is an initiative of the Cloud-Native Computing Foundation (CNCF), which specifies the configuration of Linux container network interfaces.
CNI was created to make networking solutions integratable with a range of container orchestration systems and runtimes. Instead of making the networking solutions pluggable, it defines a common interface standard for both the networking and container execution layers.
CNI focuses on the connectivity of container networks and the removal of allocated resources upon the termination of containers. This focus makes CNI specifications simple and allows them to be widely adopted. The CNI GitHub project provides more information about the CNI specifications, including the third-party plugins and runtimes that use it.
The Need for Different Kubernetes Network Plugins
CNI has a multitude of supported plugins, with major container orchestration frameworks like Kubernetes having implemented it. Plugins address various container networking functions and must conform to CNI standards defined by the CNI specification.
CNI offers specifications for multiple plugins because networking is complex, and user needs may differ. It is essential to choose the right plugins for your project and use case.
What Network Models Are Used in CNI?
CNI networks can be implemented using an encapsulated or unencapsulated network model. XLAN is an example of an encapsulated model, while Border Gateway Protocol (BGP) is an example of an unencapsulated model.
1. Encapsulated Networks
This model encapsulates a logical Layer 2 network over an existing Layer 3 network topology, which covers multiple Kubernetes nodes. Layer 2 network is isolated so there is no need for routing distribution. The overhead cost is minimal, while providing improved processing and larger IP packages—the overlay encapsulation generates an IP header that provides the IP package.
UDP ports distribute encapsulation data between workers in Kubernetes, translating information from the network control plane to reach the MAC addresses. Examples of common encapsulation network models include VXLAN and Internet Protocol Security (IPsec).
Put simply, this model provides a bridge that connects Kubernetes workers and pods. Within pods, the element managing communication is Docker, or another container engine. It is applied to use cases that prefer a Layer 2 bridge, as it is sensitive to Kubernetes worker latencies in Layer 3. For data centers in separate geographic locations, it is important to minimize the latencies between them in order to prevent network segmentation.
Examples of CNI network providers that follow this network model include Canal, Flannel, and Weave.
2. Unencapsulated Networks
This model provides a Layer 3 network for routing packets between containers. There is no isolated Layer 2 network or overhead, but this is at the expense of Kubernetes workers, which must manage any required route distribution. A network protocol is implemented to connect Kubernetes workers and use BGP to distribute routing information to pods. Within pods, the component managing communication with workloads is Docker or another container engine.
This model involves extending a network router between Kubernetes workers—this router provides information on how to reach the pods. Unencapsulated networks are suited to use cases that prefer a routed Layer 3 network. Routes for Kubernetes workers are dynamically updated at the operating system level, reducing latency.
Examples of providers that use an unencapsulated network model include Romana and Calico.
3. CNI and eBPF-Based Networking
eBPF (extended Berkeley Packet Filter) is a Linux kernel technology that allows programs to run in response to events such as network packets, system calls, and tracepoints—without changing kernel code. In container networking, eBPF enables dynamic packet processing and traffic control directly in the kernel, making it faster and more flexible than traditional iptables- or IPVS-based approaches.
Modern CNI implementations are increasingly adopting eBPF as their default data plane. Unlike overlay or underlay models that rely on static configuration or routing protocols like BGP, eBPF can dynamically inspect, filter, and route traffic with lower overhead and higher visibility. It can enforce network policies, monitor packet flows, and manage NAT, all without leaving kernel space.
One key benefit of eBPF-based CNIs is performance. Since packet processing happens in the kernel, latency is reduced and CPU usage is minimized. eBPF also enables fine-grained observability, allowing tools to collect detailed metrics and trace traffic paths across services and pods without intrusive instrumentation.
Because of its flexibility and efficiency, eBPF is well-suited for Kubernetes clusters requiring high throughput, fine-grained security policies, or real-time observability. As Kubernetes scales, eBPF offers a more scalable and programmable alternative to traditional networking stacks.
4. Cloud-Provider and Managed Kubernetes CNIs
Cloud providers offer their own CNI plugins, tailored to work seamlessly with their managed Kubernetes services. These CNIs are optimized for the underlying cloud infrastructure, providing better integration with native networking, security, and monitoring tools.
Let’s review how major cloud providers address Kubernetes CNIs:
- Amazon VPC CNI integrates Kubernetes pods directly into the Amazon Virtual Private Cloud (VPC). Each pod gets an IP address from the VPC subnet, allowing it to communicate natively with other AWS resources without NAT. This model ensures low latency and high throughput but is limited by VPC IP address availability.
- Azure CNI assigns IPs to pods from a virtual network (VNet) subnet, enabling direct access to Azure services. It supports advanced features like network security groups (NSGs) and user-defined routes (UDRs), which can be applied at the pod level. This integration allows enterprises to enforce consistent security policies across virtual machines and containers.
- Google Kubernetes Engine (GKE) uses GKE native networking (formerly VPC-native) with Container-Optimized OS, giving each pod a unique IP within the Google Cloud VPC. It supports alias IPs and integrates with Google Cloud Firewall and routing policies. GKE also allows switching to custom CNIs like Calico for policy enforcement or network segmentation.
Enterprise Kubernetes Networking with Calico
Calico’s flexible modular architecture supports a wide range of deployment options, so you can select the best networking approach for your specific environment and needs. This includes the ability to run with a variety of CNI and IPAM plugins, and underlying network types, in non-overlay or overlay modes, with or without BGP.
Calico’s flexible modular architecture for networking includes the following.
- Calico CNI network plugin – Connects pods to the host network namespace’s L3 routing using a pair of virtual ethernet devices (veth pair).
- Calico CNI IPAM plugin – Allocates IP addresses for pods out of one or more configurable IP address ranges, dynamically allocating small blocks of IPs per node as required.
- Overlay network modes – Calico provides both VXLAN or IP-in-IP overlay networks, including cross-subnet only modes.
- Non-overlay network modes – Calico can provide non-overlay networks running on top of any underlying L2 network, or an L3 network that is either a public cloud network with appropriate cloud provider integration, or a BGP capable network (typically an on-prem network with standard Top-of-Rack routers).
- Network policy enforcement – Calico’s network policy enforcement engine implements the full range of Kubernetes Network Policy features, plus the extended features of Calico Network Policy.
In addition to providing both network and IPAM plugins, Calico also integrates with a number of other third-party CNI plugins and cloud provider integrations, including Amazon VPC CNI, Azure CNI, Azure cloud provider, Google cloud provider, host local IPAM, and Flannel.
Next steps:
