Introduction

If a Kubernetes cluster seems unstable before a network plugin is installed, that is often expected behavior rather than a mysterious failure. A fresh control plane can start, but the cluster is not really complete until a Container Network Interface, or CNI, plugin is present and the nodes can establish pod networking.

Without pod networking, several core components remain degraded. Nodes may report NotReady, DNS pods may stay pending, and pods that require networking never move into a healthy running state.

What "Before Adding Networking" Usually Means

A Kubernetes installation does not include universal pod networking by itself. kubeadm init, for example, brings up control-plane components, but it expects you to install a CNI implementation such as Calico, Cilium, or Flannel afterward.

Until that happens, a cluster may show symptoms like:

• worker or control-plane nodes in NotReady
• 'coredns pods stuck in Pending'
• kubelet warnings about missing CNI configuration
• pods failing sandbox creation

Those symptoms are not separate stability bugs in most cases. They are the direct result of incomplete cluster networking.

Check the Actual Failure Signals

Start by asking the cluster what is failing:

kubectl get nodes
kubectl get pods -A
kubectl describe node <node-name>

If networking is the missing piece, you often see messages similar to "network plugin not ready" or errors indicating that no CNI configuration files were found under the node's CNI directory.

On a node, kubelet logs are often the fastest confirmation:

journalctl -u kubelet -n 100 --no-pager

Typical clues include sandbox creation failures or repeated retries to initialize networking.

Why the Cluster Looks Unstable

Kubernetes depends on pod-to-pod and pod-to-service communication for many system components. Even though the API server might be up, the cluster is not functionally healthy if pods cannot get network interfaces and routes.

For example:

• 'coredns needs a working network to run normally'
• application pods cannot communicate with services
• readiness probes fail if the network path is broken
• control loops keep retrying failed pod setups

That constant retry pattern makes the cluster look unstable, but the underlying cause is usually straightforward: the node runtime cannot create networked pod sandboxes yet.

Install a CNI Plugin and Recheck

The fix is to install a supported CNI plugin that matches the cluster's configuration. The exact manifest depends on your environment, but the verification pattern is always the same:

kubectl get pods -n kube-system
kubectl get nodes

After the CNI plugin is installed and its daemonset becomes healthy, nodes should move toward Ready, and core system pods should begin starting normally.

Do not treat a cluster as production-ready before this step. A "control plane is running" state is not the same as a healthy cluster.

Separate Expected Degradation from Real Stability Problems

There can still be true stability issues unrelated to networking, such as:

• insufficient CPU or memory on nodes
• broken container runtime configuration
• clock drift or certificate issues
• failing etcd on control-plane nodes

But you should not chase those first if the cluster does not even have pod networking. Install the CNI, wait for the expected components to settle, and then reassess anything that remains unhealthy.

That order matters because missing networking can mask or mimic other failures.

Common Pitfalls

• Assuming the cluster is fully operational immediately after control-plane bootstrap.
• Debugging coredns or application pods before confirming that a CNI plugin is installed and healthy.
• Treating NotReady nodes as proof of a broad cluster failure when kubelet is explicitly reporting missing pod networking.
• Mixing manifests or CIDR settings that do not match the chosen CNI plugin.

Summary

• A Kubernetes cluster commonly appears degraded before pod networking is installed.
• Missing CNI configuration often explains NotReady nodes and pending system pods.
• Check kubectl describe node and kubelet logs for direct networking-related errors.
• Install the correct CNI plugin before drawing conclusions about cluster stability.
• Re-evaluate the cluster only after networking is healthy, because many apparent failures disappear once pod networking exists.