How to fix NetworkUnavailable in Kubernetes

KubernetesINTERMEDIATEHIGHUpdated Dec 5, 2025· 185 views

NetworkUnavailable indicates the node's CNI is not properly configured. The scheduler prevents new pods from being scheduled on that node because pod networking cannot be established.

Quick fix

Fixes NetworkUnavailable

# Check all node conditions, focusing on NetworkUnavailable
kubectl describe nodes | grep -A 20 "Conditions:"

# Get a compact view of all nodes and their NetworkUnavailable status
kubectl get nodes -o jsonpath='{range .items[*]}{.metadata.name}{"\t"}{.status.conditions[?(@.type=="NetworkUnavailable")].status}{"\n"}{end}'

# Describe a specific problematic node
kubectl describe node <node-name>
  1. Verify the NetworkUnavailable condition
  2. Check if CNI plugin is deployed and running
  3. Examine CNI plugin pod logs
  4. Validate pod network CIDR configuration
kubernetes — error
# Check all node conditions, focusing on NetworkUnavailable
kubectl describe nodes | grep -A 20 "Conditions:"
# Get a compact view of all nodes and their NetworkUnavailable status
kubectl get nodes -o jsonpath='{range .items[*]}{.metadata.name}{"\t"}{.status.conditions[?(@.type=="NetworkUnavailable")].status}{"\n"}{end}'
# Describe a specific problematic node
kubectl describe node <node-name>
NetworkUnavailable

What this error means

The NetworkUnavailable node condition in Kubernetes indicates that the node's Container Network Interface (CNI) is not properly configured or has encountered a connectivity problem. When this condition is True, the Kubernetes scheduler prevents new pods from being allocated to that node because the node cannot provide networking capabilities. The NetworkUnavailable condition is typically managed by the CNI provider (such as Calico, Flannel, or Cilium) and reflects whether that provider can successfully configure container networking on the node. If the CNI cannot access the Kubernetes API Server, lacks proper permissions (RBAC), or encounters network configuration errors during startup, it will mark the node as unavailable. Unlike some other node conditions, NetworkUnavailable problems that occur at runtime may not always be reflected in the node condition status, making it essential to check both the condition and the CNI plugin logs.

Typical symptoms

  • Nodes show NetworkUnavailable=True in kubectl describe node output
  • New pods remain stuck in Pending state and never get scheduled to the node
  • Existing pods on the node may lose network connectivity or fail to start
  • CNI plugin pods (calico-node, flannel-ds, cilium-agent) fail to initialize or repeatedly restart
  • kubectl logs from CNI pods show API server connection errors or IP allocation failures
  • Network connectivity tests between the node and control plane succeed, but pod networking does not

Common causes

  1. CNI plugin not installed or deployed to the cluster yet - the most common cause after cluster initialization
  2. CNI plugin pods failing to start due to image pull errors, resource constraints, or missing RBAC permissions
  3. CNI plugin unable to contact the Kubernetes API Server due to network routing, firewall, or authentication issues
  4. Pod network CIDR conflicts with existing infrastructure (VPC subnets, VLANs, or service CIDR ranges)
  5. CNI configuration mismatch between cluster initialization parameters and CNI manifest deployment
  6. Cloud provider's route controller (CCM) failed to configure node routes
  7. Missing or misconfigured loopback interface on the node

How to fix "NetworkUnavailable"

1Verify the NetworkUnavailable condition

Start by confirming which nodes have the NetworkUnavailable condition:

bash
# Check all node conditions, focusing on NetworkUnavailable
kubectl describe nodes | grep -A 20 "Conditions:"

# Get a compact view of all nodes and their NetworkUnavailable status
kubectl get nodes -o jsonpath='{range .items[*]}{.metadata.name}{"\t"}{.status.conditions[?(@.type=="NetworkUnavailable")].status}{"\n"}{end}'

# Describe a specific problematic node
kubectl describe node <node-name>

Look for any node showing NetworkUnavailable True in the Conditions section.

2Check if CNI plugin is deployed and running

Verify that the CNI plugin pods are deployed and actively running:

bash
# List all CNI plugin pods
kubectl get pods -n kube-system -l k8s-app=calico-node
kubectl get pods -n kube-system -l k8s-app=flannel
kubectl get pods -n kube-system -l k8s-app=cilium

# Check the overall kube-system namespace for CNI-related pods
kubectl get pods -n kube-system | grep -E 'calico|flannel|cilium|canal'

If no CNI plugin is deployed, that is the root cause. Install the appropriate CNI plugin:

bash
kubectl apply -f https://raw.githubusercontent.com/projectcalico/calico/v3.26.1/manifests/tigera-operator.yaml
3Examine CNI plugin pod logs

Check the logs of the CNI plugin pods running on the problematic node:

bash
# For Calico
kubectl logs -n kube-system -l k8s-app=calico-node --tail=100

# For Flannel
kubectl logs -n kube-system -l app=flannel --tail=100

# For Cilium
kubectl logs -n kube-system -l k8s-app=cilium --tail=100

# Look for specific error patterns
kubectl logs -n kube-system -l k8s-app=calico-node 2>&1 | grep -i 'error\|failed\|refused\|unauthorized'

Common error patterns:
- "error accessing apiserver" - network/firewall issue
- "forbidden" or "unauthorized" - RBAC permission problem
- "no such file or directory" - missing CNI binary or configuration
- "IP allocation failure" - CIDR exhaustion or configuration mismatch

4Validate pod network CIDR configuration

Ensure the pod network CIDR is correctly configured and does not overlap with other network ranges:

bash
# Check the cluster's pod CIDR configuration
kubectl cluster-info dump | grep -i "pod-network-cidr\|cluster-cidr"

# Get pod CIDR assigned to each node
kubectl get nodes -o jsonpath='{range .items[*]}{.metadata.name}{"\t"}{.spec.podCIDR}{"\n"}{end}'

If a node has no podCIDR assigned, manually patch it:

bash
kubectl patch node <node-name> -p '{"spec":{"podCIDR":"10.244.X.0/24"}}'

Confirm that pod CIDR, service CIDR, and any VPC/infrastructure CIDR ranges do not overlap.

5Verify network connectivity and node routing

Test network connectivity between the problematic node and the control plane:

bash
# SSH into the node
ssh <node-ip>

# Check routes on the node
ip route show

# Check if the CNI binary exists on the node
ls -la /opt/cni/bin/

# Test connectivity to other nodes' pod networks
ping <pod-ip-from-another-node>

If routes are missing, the CNI plugin has not yet programmed them. Restart the CNI pod on that node to trigger route re-initialization.

6Restart CNI plugin pods and verify recovery

Force the CNI plugin pods to restart:

bash
# Delete CNI pods on the problematic node (DaemonSet will recreate them)
kubectl delete pods -n kube-system -l k8s-app=calico-node --field-selector spec.nodeName=<node-name>

# Watch for the pods to restart
kubectl get pods -n kube-system -w | grep -E 'calico|flannel|cilium'

# Once pods are Running, check the node condition again
kubectl describe node <node-name> | grep -A 5 "Conditions:"

After pod restart, the NetworkUnavailable condition should transition to False within a few seconds.

Advanced notes

NetworkUnavailable condition management varies by CNI plugin. Calico updates this condition actively during operation, while some CNI plugins only set it during initialization. If a node's condition remains False despite CNI problems, you may have a 'metadata bug' where the plugin cannot update the condition but pods cannot reach their IP addresses.

CNI plugins use different network models: Calico uses unencapsulated IP with BGP routing (requires TCP 179 or UDP 4789 for VXLAN), Flannel uses overlay networks with VXLAN/host-gw encapsulation, and Cilium uses eBPF for high-performance networking. CNI chaining is also possible (e.g., Cilium with Calico for network policies).

In cloud environments (AWS, GCP, Azure), the cloud controller manager (CCM) may also manage node routes. If CCM fails to create routes due to throttling or permissions, the node will be unable to send traffic to pod CIDRs on other nodes. Verify IAM/cloud permissions if running on managed Kubernetes.

When migrating between CNI plugins, use tools like Multus or perform a controlled live migration. Pod IPs will change during migration.

Frequently asked questions

What does "NetworkUnavailable" mean?
The NetworkUnavailable node condition in Kubernetes indicates that the node's Container Network Interface (CNI) is not properly configured or has encountered a connectivity problem. When this condition is True, the Kubernetes scheduler prevents new pods from being allocated to that node because the node cannot provide networking capabilities. The NetworkUnavailable condition is typically managed by the CNI provider (such as Calico, Flannel, or Cilium) and reflects whether that provider can successfully configure container networking on the node.
How do I fix "NetworkUnavailable"?
NetworkUnavailable indicates the node's CNI is not properly configured. The scheduler prevents new pods from being scheduled on that node because pod networking cannot be established.
What causes "NetworkUnavailable"?
CNI plugin not installed or deployed to the cluster yet - the most common cause after cluster initialization CNI plugin pods failing to start due to image pull errors, resource constraints, or missing RBAC permissions CNI plugin unable to contact the Kubernetes API Server due to network routing, firewall, or authentication issues
Is the "NetworkUnavailable" error serious?
Yes. This is a high-severity error that usually blocks work until it is fixed, but the steps above resolve it.

Official resources & further reading