Think of your Kubernetes cluster as a big apartment building. Each pod is an apartment. The CNI plugin is the plumbing and wiring that lets apartments talk to each other, get mail (ingress), and send packages out (egress). If you get this wrong, nothing works, and you'll be debugging network issues at 3 AM.
When you install a cluster, you *must* pick a CNI. It's not optional. The default varies by distribution, and it's a major operational choice. Here's why it matters:
* **Pod Networking Model:** How does a pod get an IP? Does it come from the node's network (host-local) or a central pool (like a real overlay network)? This defines your entire address plan.
* **Network Policies:** This is your firewall. Without a CNI that supports the Kubernetes NetworkPolicy API, you have zero isolation between pods. Any pod can talk to any other pod. Calico or Cilium are the usual choices here.
* **Performance & Complexity:** Some plugins are simple but limited (Flannel). Others are powerful but bring complexity (Cilium, with eBPF). The overhead matters at scale.
For example, a quick look at a common Flannel config shows its simplicity. It often uses a simple overlay like VXLAN:
```yaml
net-conf.json: |
{
"Network": "10.244.0.0/16",
"Backend": {
"Type": "vxlan"
}
}
```
Compare that to Cilium, which might use eBPF to handle network policies and routing at the kernel level, which is more efficient but requires a newer kernel. The wrong choice for your team's skill set or kernel version creates immediate technical debt.
Bottom line: Your CNI plugin decides your cluster's network reliability, security posture, and your ability to troubleshoot. Don't just accept the default. Choose based on your need for network policies, your team's operational comfort, and your performance requirements.
Build once, deploy everywhere