network plugin is not ready: The kubelet cannot find a usable CNI configuration on the node

The node condition message network plugin is not ready: cni config uninitialized means the kubelet has no CNI configuration to work with, so the node stays NotReady and no pods can be networked on it.

Applies to: All Kubernetes versions

What it means

The kubelet checks for a CNI configuration file on the node and refuses to report Ready without one, because a node that cannot give pods network addresses cannot usefully run them. The message appears in the node's Ready condition and in the kubelet log. On a freshly built cluster this is entirely expected and transient: nodes come up NotReady until the CNI's DaemonSet runs and writes its configuration. It becomes a real problem when it persists, which means the plugin never ran on that node — often because its DaemonSet does not tolerate the very taint that a NotReady node carries, producing a deadlock where the plugin cannot start because the node is not ready and the node is not ready because the plugin has not started.

Most common causes

• No CNI plugin has been installed in the cluster yet. Normal immediately after cluster creation.
• The CNI DaemonSet does not tolerate the node's taints, so it is never scheduled there.
• The plugin's pod is crash-looping on that node.
• The CNI configuration directory is not where the kubelet expects it, because of a non-default kubelet configuration.
• The plugin's configuration file is present but invalid.
• A partially completed CNI upgrade that removed the old configuration without writing the new one.

How to diagnose it

1. Check the node's condition message: kubectl describe node NODE.
2. Look for the CNI configuration on the node: ls -l /etc/cni/net.d. An empty directory is the direct confirmation.
3. Check whether the CNI DaemonSet has a pod on that node: kubectl get pods -n kube-system -o wide | grep NODE.
4. If it has none, compare the DaemonSet's tolerations against the node's taints.
5. Read the plugin pod's logs if it is present but failing.
6. Check the kubelet's configured CNI paths: journalctl -u kubelet | grep -i cni.

How to fix it

1. Install a CNI plugin if the cluster has none. A cluster without one is not finished being built.
2. Add the tolerations the CNI DaemonSet needs so it can run on nodes that are not yet ready. Every mainstream plugin ships with these by default, so a missing toleration usually means the manifest was edited.
3. Fix the plugin's crash, using its own logs.
4. Point the kubelet at the correct CNI configuration directory, or write the configuration where the kubelet looks.
5. Complete or roll back an interrupted CNI upgrade.

Notes

A brand-new node showing this for a minute or two is normal. The condition is only meaningful if it persists, and the first thing to check when it does is whether the plugin's DaemonSet can tolerate an unready node at all.

Related

• FailedCreatePodSandBox — The runtime could not create the pod's network sandbox
• NotReady — The node is not accepting work

Sources

• Kubernetes documentation — Network Plugins
• Kubernetes documentation — Nodes: node status
• Kubernetes documentation — Cluster Networking