Comparing CNI plugins — Calico, Cilium, Flannel, Weave, and the choice matrix

The CNI plugin choice is the cluster’s most consequential networking decision. The plugin determines the dataplane (iptables, eBPF, overlay), the policy story (NetworkPolicy enforcement or not), the performance, and the operational maturity. This lesson walks the major plugins, the comparison matrix, and the operational decision framework.

The major CNI plugins

The five CNI plugins that dominate production:

The choice is rarely about the plugin itself; it is about the operational model the plugin supports.

Calico

Calico is the most mature production CNI for Kubernetes. Its dataplane options include:

• iptables: the legacy dataplane. Simple, well understood, but O(n) rules per Service.
• eBPF: the modern dataplane. Faster, lower overhead, but requires a recent kernel.
• IPIP: an IP-in-IP overlay for cross-subnet routing.
• VXLAN: a VXLAN overlay for clusters that cannot route pod CIDRs natively.
• BGP: a routed dataplane with no overlay.

The policy story is the strongest. Calico supports the standard Kubernetes NetworkPolicy resource and extends it with GlobalNetworkPolicy, NetworkSet, and ServiceAccount-based policies. The cluster operator can enforce policies at the pod, namespace, or cluster scope.

Calico’s operational maturity is the highest. The project has been running in production for over a decade, the documentation is comprehensive, and the support channels are active.

flowchart LR
    A[Pod] -->|veth| B[cali* interface]
    B --> C[Linux bridge or routing]
    C --> D[Felix: iptables/eBPF]
    D --> E[NetworkPolicy]
    E --> F[kube-system/calico-node]
    F --> G[BIRD: BGP]
    G --> H[Peer nodes]

Cilium

Cilium is the eBPF-native CNI. Its dataplane is exclusively eBPF; the iptables-based dataplane is deprecated. Cilium’s value proposition is performance: the eBPF dataplane is faster than iptables, especially for kube-proxy Service traffic.

Cilium’s policy story is the most expressive. It supports the standard NetworkPolicy and adds CiliumNetworkPolicy, which can match on FQDN, HTTP method, gRPC service, ICMP, and other Layer 7 attributes. Cluster-wide policies, identity-based policies, and DNS-aware policies are all supported.

Cilium’s operational maturity is growing rapidly. The project is the default CNI in major managed distributions (GKE, EKS); the documentation is substantial; the support is strong.

flowchart LR
    A[Pod] -->|veth| B[lxc* interface]
    B --> C[eBPF datapath]
    C --> D[Cilium agent]
    D --> E[Hubble: observability]
    D --> F[kube-system/cilium]
    F --> G[cilium-operator]

Flannel

Flannel is the simplest CNI. The dataplane is either VXLAN or host-gw. There is no native NetworkPolicy enforcement. A cluster that uses Flannel alone has no policy isolation between Pods.

Flannel’s operational simplicity is its virtue. The daemon is small, the configuration is minimal, and the failure modes are narrow. The cluster operator runs kube-flannel-ds as a DaemonSet and the Pod network works.

The production rule is: do not use Flannel alone in production. The lack of NetworkPolicy enforcement is a security gap. The cluster operator must chain Flannel with a policy plugin (Calico policy) or choose a CNI that enforces policy natively.

Weave

Weave is a mature CNI with a custom dataplane (sleeve) and a fast-rising mesh. Weave supports NetworkPolicy but is single-host (each Weave router runs on a node) and the policy engine is less expressive than Calico or Cilium.

Weave’s operational maturity is reasonable but the project has not kept pace with Cilium and Calico. The 1.x release train is less active than the alternatives.

Multus

Multus is a CNI plugin that delegates to other CNI plugins. Multus itself is the main plugin in the kubelet’s conflist; it reads the Pod’s network attachment definitions and invokes the appropriate sub-plugins. Multus is the canonical solution for multi-homed Pods (SR-IOV, DPDK, multiple interfaces).

Multus’s operational discipline is the standard multi-plugin discipline: the chain must be versioned, the delegate plugins must be documented, the failure modes must be tested.

The comparison matrix

The decision framework

The choice of CNI is driven by:

1. Security policy: if NetworkPolicy is required, the choice is Calico or Cilium. Flannel alone is rejected.
2. Performance: if kube-proxy replacement is desired, Cilium is the leader. Calico’s eBPF dataplane is comparable.
3. Existing infra: if BGP is already in the network, Calico fits. If eBPF is the future, Cilium fits.
4. Operational maturity: if the team is unfamiliar with eBPF, Calico’s iptables dataplane is the safer choice.
5. Managed control plane: if the cluster is on a managed distribution, the cluster operator must accept the CNI the cloud provides (GKE: Cilium, EKS: Cilium or AWS VPC CNI).

The production rule is to choose a CNI that supports the workload’s policy and performance requirements and that the operations team can run confidently for five years.

The operational discipline

The CNI choice’s operational discipline:

• Document the choice. The CNI is the cluster’s networking implementation; the documentation is the reference.
• Pin the CNI version. The CNI version is the cluster’s networking contract.
• Audit the choice at every release. A major version bump can change defaults.
• Test the CNI in staging. The CNI is critical infrastructure; promote through staging before production.
• Train the operations team on the CNI’s diagnostics. The CNI’s failure modes are unique.
• Plan the CNI’s exit. The CNI is the cluster’s most locked-in dependency.

Quiz

Production discipline

• The CNI choice is the cluster’s most consequential networking decision. The choice determines the dataplane, the policy story, and the operational model.
• Flannel alone is a security gap. A cluster running Flannel without a policy plugin has no NetworkPolicy enforcement.
• Calico is the safe choice for iptables practitioners. The documentation is comprehensive and the policy story is strong.
• Cilium is the right choice for eBPF and performance. The kube-proxy replacement is the performance leader.
• Multus is the right choice for multi-homed Pods. Multus delegates to other CNI plugins.
• Pin the CNI version. The CNI is the cluster’s networking contract.
• Train the operations team on the CNI’s diagnostics. The CNI’s failure modes are unique.
• Document the choice. The CNI is the cluster’s networking implementation; the documentation is the reference.