Install a CNI Plugin: Flannel or Calico

Original Prepium guide · Written for Kubernetes v1.35 and checked against the official documentation on 6 October 2026. Use a disposable practice cluster. Installing or swapping a network plugin affects every Pod, so practise on a fresh kubeadm cluster rather than one you care about.

What a CNI plugin actually does, and why "Pods talk" is not the same as "policies work"

Kubernetes defines the network model (every Pod gets its own cluster-wide IP and can reach every other Pod without NAT) but does not implement it. A Container Network Interface (CNI) plugin does. Picking one on the exam means checking two separate properties: does it give Pods connectivity, and does it enforce NetworkPolicy? The API server stores a NetworkPolicy either way.

kubelet ──CRI──→ container runtime ──reads──→ /etc/cni/net.d/*.conflist
                         └──exec ADD──→ /opt/cni/bin/<plugin> ──→ veth + IP inside the Pod netns
plugin agent (DaemonSet) ──→ routes/overlay between nodes  (+ policy engine, if it has one)

1. Inspect a cluster with no network yet (read-only)

kubectl get nodes
kubectl -n kube-system get pods -o wide | grep -i dns
kubectl -n kube-system get cm kubeadm-config -o yaml | grep -i subnet
kubectl get nodes -o jsonpath='{range .items[*]}{.metadata.name}{" "}{.spec.podCIDR}{"\n"}{end}'
ls /etc/cni/net.d /opt/cni/bin      # on a node

Since v1.24 the kubelet no longer manages CNI itself; the container runtime loads the plugin configuration (default directory /etc/cni/net.d) and runs plugin binaries (default /opt/cni/bin). On a CNI ADD call, the plugin creates or adjusts the Pod's interface inside its network namespace, usually delegating address assignment to an IPAM plugin. With an empty config directory, CoreDNS stays Pending, which the kubeadm guide calls expected, and the node's Ready condition message is the place to look for network errors.

2. Line the plugin's Pod range up with the cluster

The podSubnet you see above, and each node's spec.podCIDR carved from it, must agree with the range in the plugin's own config. The defaults differ by project:

• Flannel: the network value in its ConfigMap's flannel config should match the Pod network CIDR. Its docs assume 10.244.0.0/16; for anything else, download the manifest and edit it first.
• Calico (operator install): the sample Installation resource sets spec.calicoNetwork.ipPools[].cidr to 192.168.0.0/16; customise the downloaded file if your cluster uses another range.

Also keep the Pod range clear of your host networks; the kubeadm docs warn that overlap causes problems.

3. Check policy enforcement on the plugin's own docs

Kubernetes states that a NetworkPolicy without a controller implementing it has no effect. Flannel's README says the flanneld binary does not natively enforce NetworkPolicy; policy needs an add-on (its Helm chart has a netpol.enabled option, or you pair it with another project such as Calico). Calico's install docs describe installing both networking and network policy. Read the docs for the exact version you are offered, since features change. Then test rather than trust, in namespace prepium-tutorial:

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: lockdown-ingress
  namespace: prepium-tutorial
spec:
  podSelector: {}
  policyTypes:
  - Ingress

Run an nginx Pod and a busybox client, confirm wget -T 3 to the nginx Pod IP works, apply the policy, and repeat. On an enforcing plugin the second request times out; on a non-enforcing one it still succeeds.

4. Confirm the network is healthy

Watch the plugin's DaemonSet roll out on every node (for the Calico operator, kubectl get tigerastatus should show components AVAILABLE True). Then check that nodes are Ready, CoreDNS is Running, and new Pods get IPs inside the expected range.

Common mistakes

• Applying a second plugin on top of the first: /etc/cni/net.d ends up with competing configs. The kubeadm docs say to install only one Pod network per cluster.
• Keeping the plugin's default range when the cluster uses another: Pod IPs stop matching the cluster's podSubnet, which both projects' docs tell you to avoid.
• Judging policy support from kubectl get networkpolicy: the object exists even when nothing enforces it.
• Testing policy without a baseline: if traffic was already broken, a timeout proves nothing.

Cleanup: kubectl delete namespace prepium-tutorial; rebuild the practice cluster to try a different plugin. References: Network Plugins, Network Policies, Flannel README, Calico on-premises install. Next, try writing a NetworkPolicy or kubeadm init.