Introduction

This Kubernetes error appears when the CNI bridge interface cni0 already has an address that does not match the subnet expected by the active network plugin. In practice, it is usually caused by stale node networking state after a reset, a plugin change, or partially cleaned cluster data. The reliable fix is to cordon the node, clear old CNI state, and let the plugin recreate interfaces.

Why the cni0 Address Mismatch Happens

Each CNI plugin allocates pod network ranges and programs bridge interfaces on every node. If a node keeps old bridge settings from a previous cluster or previous plugin configuration, kubelet asks CNI to attach a pod and CNI refuses because the existing bridge has a different subnet.

Typical root causes include:

• Rebuilding the cluster without fully deleting /var/lib/cni.
• Switching between Flannel, Calico, or another plugin without draining nodes.
• Restoring a VM snapshot that preserved old bridge devices.
• Running local networking tools that modified bridge routes.

You can confirm the mismatch quickly.

1ip addr show cni0
2ip route | grep -E 'cni|flannel|cali'
3ls -la /etc/cni/net.d
4ls -la /var/lib/cni
5kubectl get nodes -o wide

If cni0 is on one subnet and your plugin config requests another, new pods will stay in ContainerCreating with CNI setup errors.

Safe Recovery Procedure on One Node

Drain and isolate the node first. That protects workloads and avoids partial networking state while cleanup runs.

NODE_NAME="worker-1"
kubectl cordon "$NODE_NAME"
kubectl drain "$NODE_NAME" --ignore-daemonsets --delete-emptydir-data

Then remove stale CNI state and restart runtime services. Service names vary by distribution, so adjust for containerd or CRI-O.

1sudo systemctl stop kubelet
2sudo systemctl stop containerd
3
4sudo ip link delete cni0 2>/dev/null || true
5sudo ip link delete flannel.1 2>/dev/null || true
6sudo rm -rf /var/lib/cni/*
7sudo rm -rf /var/lib/kubelet/pods/*
8
9sudo systemctl start containerd
10sudo systemctl start kubelet

After kubelet returns, check that the plugin daemon recreated network state.

kubectl get pods -n kube-system -o wide
kubectl describe node "$NODE_NAME" | grep -i -E 'Ready|NetworkUnavailable'
kubectl uncordon "$NODE_NAME"

Do this node by node in production clusters to minimize disruption.

Preventing Repeat Incidents

Treat CNI data as cluster-specific. If you rebuild, clean node network artifacts before rejoining nodes. If you migrate plugins, run a planned maintenance path instead of in-place ad hoc edits.

A simple operational checklist helps:

1# Before node rejoin or plugin migration
2sudo systemctl stop kubelet containerd
3sudo rm -rf /etc/cni/net.d/*
4sudo rm -rf /var/lib/cni/*
5sudo ip link delete cni0 2>/dev/null || true
6sudo ip link delete flannel.1 2>/dev/null || true
7sudo systemctl start containerd kubelet

Also keep plugin manifests under version control and avoid manual one-off edits on nodes. The source of truth should be your cluster deployment configuration.

Operational Checklist for Teams

In shared environments, consistency matters more than one-time fixes. Store your node recovery commands in an internal runbook and include expected outputs for each validation step. Add alerts for repeated FailedCreatePodSandBox events so on-call responders catch drift before many workloads are affected. If you operate mixed Linux distributions, verify service names and paths per node pool and standardize images to reduce variation in CNI behavior.

Common Pitfalls

• Cleaning /etc/cni/net.d but forgetting /var/lib/cni, leaving stale IP allocations behind.
• Restarting kubelet without draining the node first, which disrupts active workloads.
• Deleting interfaces while the runtime is still writing network state, causing race conditions.
• Running mixed CNI manifests in the same cluster namespace during migration.
• Fixing one node manually but not documenting the root cause, which leads to repeated outages on new nodes.

Summary

• The error means the existing cni0 subnet conflicts with the current CNI plugin expectation.
• Drain and cordon before cleanup so workload impact stays controlled.
• Remove stale bridge interfaces and CNI state directories, then restart runtime and kubelet.
• Validate plugin pods and node readiness before uncordoning.
• Standardize rebuild and migration runbooks to prevent stale network artifacts.