Understanding Kubernetes CNI (Container Network Interface)

CNI (Container Network Interface) is the networking standard that Kubernetes uses to connect Pods to the network.

Think of it this way:

• Kubernetes knows when to create a Pod.
• containerd/runc knows how to create the container.
• CNI plugin knows how to connect that Pod to the network.

Without a CNI plugin, Pods can be created successfully, but they won’t be able to communicate with other Pods, Services, or external networks.

Why Does Kubernetes Need CNI?

Imagine a Kubernetes cluster with three worker nodes.

+-------------------+
| Worker Node 1     |
|  Pod A            |
|  Pod B            |
+-------------------+

+-------------------+
| Worker Node 2     |
|  Pod C            |
|  Pod D            |
+-------------------+

+-------------------+
| Worker Node 3     |
|  Pod E            |
+-------------------+

Kubernetes networking has a few important requirements:

• Every Pod must have its own unique IP address.
• Pods on different nodes must communicate directly.
• There should be no NAT between Pods.
• Kubernetes Services should be able to reach Pods.

Kubernetes itself does not implement networking.

Instead, it delegates networking to a CNI plugin.

How CNI Works

When you create a Pod, the workflow begins as follows:

kubectl apply

      │
      ▼
API Server

      │
      ▼
Scheduler

      │
      ▼
Worker Node

      │
      ▼
kubelet

The kubelet asks the container runtime to create the Pod.

kubelet
     │
     ▼
containerd

The container runtime creates the container.

Before the container starts, it invokes the configured CNI plugin.

containerd
     │
     ▼
CNI Plugin

The CNI plugin performs several networking tasks:

• Creates a network namespace.
• Creates a virtual Ethernet (veth) pair.
• Assigns an IP address to the Pod.
• Connects the Pod to the node’s network.
• Adds routing information.
• Configures iptables or eBPF rules if required.

Once networking is configured, the Pod starts running.

Networking Inside a Pod

Suppose a Pod receives the following IP address:

10.244.1.5

Inside the Pod, the network interface looks like this:

+--------------------+
| eth0               |
| 10.244.1.5         |
+--------------------+

On the worker node, one end of a virtual Ethernet pair remains attached to the host.

veth12345 -------- eth0 (Pod)

One end stays inside the Pod, while the other remains on the host. The CNI plugin connects the host-side interface to the node’s networking infrastructure.

How Different CNI Plugins Work

Every CNI plugin provides networking for Pods.

The primary difference between CNI plugins is how Pods communicate across different nodes.

Different plugins use different technologies, such as:

• VXLAN tunnels
• IP-in-IP encapsulation
• BGP routing
• eBPF
• Linux bridges

Popular CNI Plugins

1. Flannel

Flannel is one of the simplest and most beginner-friendly CNI plugins.

Technologies Used

• VXLAN
• Host Gateway (Host-GW)

Features

• ✅ Easy to install
• ✅ Lightweight
• ✅ Good performance
• ❌ Does not support Kubernetes Network Policies

Best For

• Learning Kubernetes
• Home labs
• Small clusters

2. Calico

Calico is one of the most widely used production networking solutions.

Technologies Used

• BGP
• VXLAN
• IP-in-IP
• eBPF

Features

• ✅ High performance
• ✅ Kubernetes Network Policies
• ✅ Highly scalable
• ✅ Enterprise ready

Best For

• Production Kubernetes clusters
• Enterprise deployments

3. Cilium

Cilium is a modern networking solution built around eBPF.

Technology Used

• eBPF

Features

• Very high performance
• Excellent observability
• Advanced security
• Built-in load balancing
• Network Policies

Best For

• Large Kubernetes deployments
• Security-focused environments

4. Weave Net

Weave Net uses mesh networking between nodes.

It is easy to install and supports:

• Encryption
• Network Policies

Although still available, it is less commonly used today.

5. Canal

Canal combines the strengths of two different projects.

Flannel
     +
Calico Policy

Why?

• Flannel provides simple networking.
• Calico provides powerful Network Policies.

Together they provide simple networking with policy support.

6. Antrea

Antrea is developed by VMware.

It uses:

• Open vSwitch (OVS)

It is particularly well suited for VMware environments.

7. Kube-router

Kube-router relies entirely on Linux kernel networking capabilities.

It uses:

• BGP
• IPVS

It is lightweight and suitable for production environments.

Comparison of Popular CNI Plugins

What is Flannel?

Flannel is one of the simplest CNI plugins available.

Its primary responsibility is enabling communication between Pods running on different worker nodes.

Example:

Node 1

Pod A
10.244.1.5

Node 2

Pod B
10.244.2.8

Without Flannel:

Pod A ----X----> Pod B

The worker nodes have no knowledge of each other’s Pod networks.

Flannel solves this problem by assigning every worker node its own unique Pod subnet and creating routes or tunnels between those subnets.

Example:

Node 1
Pod Subnet

10.244.1.0/24

Node 2
Pod Subnet

10.244.2.0/24

Each node owns its own subnet, and Pods receive IP addresses only from that subnet.

Flannel Using VXLAN (Default Backend)

Most Flannel installations use the VXLAN backend.

Node 1
10.244.1.0/24

      │
 VXLAN Tunnel
      │

Node 2
10.244.2.0/24

When Pod A sends traffic to Pod B, the process looks like this:

Pod A
10.244.1.5
      │
      ▼
flannel.1 interface
      │
Encapsulate packet
      │
UDP Packet
      │
Physical Network
      │
Node 2
      │
Decapsulate
      │
Pod B
10.244.2.8

The original Pod packet is encapsulated inside another packet, transported across the physical network, and then decapsulated on the destination node.

Flannel Backend Modes

Flannel supports multiple backend modes.

VXLAN (Default)

• Encapsulates traffic using VXLAN tunnels.
• Works in almost every environment.
• Requires no special network configuration.

Host-GW

• Uses normal Linux routing instead of tunnels.
• No encapsulation overhead.
• Requires all worker nodes to be on the same Layer 2 network.

WireGuard

• Encrypts Pod-to-Pod communication.
• Provides secure connectivity between nodes.

UDP

• Legacy encapsulation backend.
• Rarely used in modern Kubernetes deployments.

When Should You Use Flannel?

Flannel is an excellent choice when you need:

• A simple Kubernetes networking solution.
• A home lab.
• A learning environment.
• Small or medium-sized Kubernetes clusters.
• Minimal configuration and operational overhead.

If your production environment requires advanced security, micro-segmentation, or fine-grained Network Policies, consider using Calico or Cilium.

Summary

CNI is the standard interface Kubernetes uses to connect Pods to the network.

Flannel is a simple CNI plugin that enables Pod-to-Pod communication across worker nodes by assigning each node its own Pod subnet and connecting those subnets using routes or tunnels (typically VXLAN).