Skip to content

8.08 CNI in Kubernetes

Abstract

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

Kubernetes creates the Pod sandbox and network namespace, then the container runtime calls the configured CNI plugin to attach the Pod to the correct network.

In production, CNI is critical for Pod IP assignment, Pod-to-Pod communication, Services, DNS, and NetworkPolicy enforcement.

What is CNI?

CNI stands for Container Network Interface.

It defines a standard way for container runtimes to:

  • create Pod network connectivity
  • attach Pods to a network
  • assign IP addresses
  • configure routes
  • clean up networking when Pods are deleted

Note

Kubernetes does not directly implement Pod networking by itself. It depends on a CNI plugin.

Why Kubernetes Uses CNI

Before CNI, each container runtime or orchestrator could implement networking differently.

CNI standardizes how networking plugins work with runtimes like:

  • containerd
  • CRI-O

This allows Kubernetes to work with many network plugins without changing Kubernetes core code.

Success

CNI makes Kubernetes networking pluggable and vendor-neutral.

Kubernetes and Container Runtime Responsibility

In Kubernetes, the networking flow is:

Kubelet
   ↓
Container Runtime
   ↓
Creates Pod sandbox / network namespace
   ↓
Calls CNI plugin
   ↓
CNI configures Pod networking

Tip

The component that creates containers is also responsible for invoking the CNI plugin.

Where CNI is Configured

CNI uses two important directories:

Path Purpose
/opt/cni/bin Stores CNI plugin binaries
/etc/cni/net.d Stores CNI configuration files

Note

The container runtime reads /etc/cni/net.d to decide which CNI plugin configuration to use.

CNI Plugin Binaries

CNI plugins are executable files stored in:

/opt/cni/bin

View installed plugins:

ls /opt/cni/bin

Example output:

bridge
dhcp
flannel
host-local
ipvlan
loopback
macvlan
portmap
ptp
sample
tuning
vlan
weave-ipam
weave-net

Common plugins include:

  • bridge
  • flannel
  • DHCP
  • host-local
  • loopback
  • portmap

Example

Plugin binaries are executable programs that perform networking operations like creating interfaces, assigning IPs, and configuring routes.

CNI Configuration Directory

CNI configuration files are stored in:

/etc/cni/net.d

View CNI config files:

ls /etc/cni/net.d

Example output:

10-bridge.conflist

Warning

If multiple CNI config files exist, the container runtime usually selects the first file in alphabetical order.

Viewing CNI Options

View a CNI config file:

cat /etc/cni/net.d/10-bridge.conf

Example CNI bridge configuration:

{
  "cniVersion": "0.2.0",
  "name": "mynet",
  "type": "bridge",
  "bridge": "cni0",
  "isGateway": true,
  "ipMasq": true,
  "ipam": {
    "type": "host-local",
    "subnet": "10.22.0.0/16",
    "routes": [
      {
        "dst": "0.0.0.0/0"
      }
    ]
  }
}

CNI Config Breakdown

Field Meaning
cniVersion CNI specification version
name Network name
type Plugin type, such as bridge or flannel
bridge Linux bridge name
isGateway Assigns an IP to the bridge so it can act as a gateway
ipMasq Enables IP masquerading / NAT
ipam IP Address Management configuration
subnet Pod IP range
routes Routes added for Pod traffic

Tip

CNI configuration connects directly to Linux networking concepts: bridge, routing, NAT, IPAM, and namespaces.

Bridge Plugin

The bridge plugin creates or uses a Linux bridge.

Example:

"type": "bridge",
"bridge": "cni0"

This means:

  • use plugin type bridge
  • connect Pod interfaces to bridge cni0
  • allow Pods on the node to communicate through the bridge

Note

cni0 works like a virtual switch for Pods on a node.

isGateway

Example:

"isGateway": true

This assigns an IP address to the bridge interface.

Purpose:

  • bridge can act as a gateway
  • Pods can route traffic through it
  • traffic can leave the Pod network

Success

isGateway: true is useful when Pods need to reach destinations outside their local bridge network.

ipMasq

Example:

"ipMasq": true

This enables IP masquerading.

Purpose:

  • allows Pod traffic to leave the Pod subnet
  • hides Pod IP behind the node IP
  • uses NAT rules on the node

Warning

NAT behavior should be clearly understood in production because it affects source IP visibility and troubleshooting.

IPAM Configuration

IPAM stands for IP Address Management.

Example:

"ipam": {
  "type": "host-local",
  "subnet": "10.22.0.0/16"
}

This means:

  • IPs are managed locally on the node
  • Pods receive IPs from 10.22.0.0/16

Common IPAM types:

IPAM Type Description
host-local Manages IPs locally on the node
dhcp Gets IPs from an external DHCP server
plugin-specific Managed by CNI provider

Danger

Pod CIDR must not overlap with node network, Service CIDR, VPN ranges, or enterprise networks.

Routes

Example:

"routes": [
  {
    "dst": "0.0.0.0/0"
  }
]

This adds a default route for Pod traffic.

Meaning:

Send unknown destinations through the configured gateway.

Note

Routes decide how Pods reach other Pods, Services, nodes, and external networks.

How Container Runtime Picks a CNI Plugin

The container runtime:

  1. reads config files from /etc/cni/net.d
  2. picks the active config
  3. checks the type field
  4. finds the matching binary in /opt/cni/bin
  5. executes the plugin

Example:

/etc/cni/net.d/10-bridge.conf
      ↓
"type": "bridge"
      ↓
/opt/cni/bin/bridge

Warning

If the config says type: bridge but /opt/cni/bin/bridge does not exist, Pod networking fails.

Multiple CNI Config Files

Example:

10-bridge.conflist
20-flannel.conflist

The runtime usually picks the first file alphabetically.

Failure

Multiple unintended CNI configs can cause the wrong plugin to be selected.

Best practice:

Keep only the intended active CNI config in /etc/cni/net.d

CNI ADD and DEL Operations

CNI plugins usually perform two main operations:

Operation Purpose
ADD Attach Pod to network
DEL Remove Pod from network

When a Pod starts:

Runtime calls CNI ADD

When a Pod is deleted:

Runtime calls CNI DEL

Note

Good cleanup prevents stale veth interfaces and IP allocation conflicts.

Common CNI Plugins

Plugin Use Case
Flannel Simple overlay networking
Calico Routing and NetworkPolicy
Cilium eBPF networking and security
Weave Net Overlay networking
VMware NSX Enterprise network integration
Bridge Basic local bridge networking

Tip

Choose the CNI plugin based on your production needs: performance, NetworkPolicy, encryption, cloud support, and observability.

Production Best Practices

Recommended

  • Use a supported and actively maintained CNI plugin
  • Validate CNI compatibility with your Kubernetes version
  • Keep only one intended active CNI config
  • Use non-overlapping Pod and Service CIDRs
  • Confirm NetworkPolicy support if security isolation is required
  • Monitor CNI Pods, logs, and metrics
  • Document CNI plugin version and network CIDRs
  • Test Pod-to-Pod communication across nodes

Do's

  • Check CNI binaries in /opt/cni/bin
  • Check CNI config in /etc/cni/net.d
  • Verify Pod IP assignment
  • Test same-node Pod communication
  • Test cross-node Pod communication
  • Check container runtime CNI settings
  • Use a NetworkPolicy-capable CNI for production isolation

Don'ts

  • Don't leave unused CNI configs in /etc/cni/net.d
  • Don't mix CNI plugins unless you understand chaining
  • Don't use overlapping CIDR ranges
  • Don't manually modify CNI-managed interfaces in production
  • Don't ignore CNI logs when Pods are stuck
  • Don't assume a cluster is ready before CNI is installed

Danger

Incorrect CNI configuration can break Pod creation, CoreDNS, Services, NetworkPolicy, and cross-node communication.

Troubleshooting Checklist

When CNI is not working, check:

  • Are plugin binaries present in /opt/cni/bin?
  • Is a valid config present in /etc/cni/net.d?
  • Are there multiple conflicting CNI configs?
  • Does the config type match an installed binary?
  • Are CNI Pods running in kube-system?
  • Are nodes in Ready state?
  • Do Pods receive IP addresses?
  • Can Pods communicate across nodes?
  • Are Pod CIDRs and Service CIDRs non-overlapping?
  • Are firewall rules blocking CNI traffic?

Useful Commands

Check CNI binaries:

ls /opt/cni/bin

Check CNI configs:

ls /etc/cni/net.d

View CNI config:

cat /etc/cni/net.d/10-bridge.conf

Check Pods and IPs:

kubectl get pods -A -o wide

Check CNI-related Pods:

kubectl get pods -n kube-system

Check node status:

kubectl get nodes

Check routes:

ip route

Check interfaces:

ip link
ip addr

CKA Exam Note

CKA Tip

If the exam asks you to deploy a network addon and does not specify the plugin, use any valid CNI solution allowed by the provided exam documentation.

Warning

Kubernetes documentation is intentionally vendor-neutral. It may not include exact third-party install commands. In the official exam, essential CNI deployment details will be provided when required.

Summary

Quote

  • CNI is the standard used for Kubernetes Pod networking
  • CNI binaries are stored in /opt/cni/bin
  • CNI configs are stored in /etc/cni/net.d
  • Container runtimes call CNI plugins after creating Pod namespaces
  • The selected config determines which plugin is used
  • CNI handles IP allocation, bridge setup, routing, NAT, and cleanup
  • Production clusters should use a supported CNI plugin with clear CIDR and security design