Container Network Interface (CNI)

What it is

CNI (Container Network Interface) is a specification plus a set of Go libraries for wiring up network interfaces in Linux (and Windows) containers. It defines a plugin interface — a JSON config in, exec a binary, get network attachment out — that container runtimes and orchestrators call at pod/container creation and teardown time.

CNI itself does not provide networking. It's the contract. The actual packet-forwarding logic — routing, overlay encapsulation, policy enforcement — is implemented by CNI plugins: Calico, Cilium, Flannel, AWS VPC CNI, Azure CNI, and dozens of others. If you run Kubernetes, you are using CNI whether you know it or not; you just don't usually interact with the spec directly, you pick a plugin.

The repo also ships reference plugins (bridge, host-local IPAM, loopback, ptp, macvlan) that most production CNI plugins build on or vendor pieces from.

Who builds it and why

CNI originated at CoreOS for rkt, then got adopted by Kubernetes as its networking abstraction layer instead of building a bespoke one. It moved to CNCF and sits at incubating maturity. The 180 contributors are mostly engineers from companies that ship CNI plugins — Cisco, Isovalent, Tigera, cloud providers — because they need the spec to stay stable and interoperable across the ecosystem they depend on. Nobody adopts CNI for its own sake; they adopt it because Kubernetes requires it and every serious network plugin implements it.

Production readiness signal

Active commit history through December 2025, 180 contributors, CNCF incubating status — this is foundational infrastructure, not an experimental project. v1.3.0 as latest release indicates a slow-moving, deliberately conservative spec; breaking changes here would break every CNI plugin in existence, so the maintainers treat stability as the primary feature.

6047 GitHub stars is low for something this load-bearing, but that's expected — engineers star Calico or Cilium, not the underlying spec repo. Star count is not a useful signal for this project.

The real production signal isn't CNI itself, it's whether your chosen CNI plugin is production-ready. CNI the spec has been running in every Kubernetes cluster on earth for years.

Who should use this

• Kubernetes platform teams evaluating or building a CNI plugin
• Engineers building custom container runtimes who need a standard network plugin interface
• Anyone debugging low-level pod networking issues (understanding the spec helps you read ip a, ip route, and plugin logs intelligently)
• Vendors building network policy, service mesh data planes, or multi-cluster networking who need to hook into pod lifecycle events

Who should NOT use this

• Application teams — you will never touch this directly, you touch the CNI plugin your platform team chose
• Teams looking for a networking solution — CNI is the interface, not the implementation. Go pick Cilium, Calico, or your cloud's native CNI
• Anyone expecting built-in network policy, encryption, or observability — none of that exists at the CNI spec level, it's plugin-dependent
• Shops running Docker Swarm, Nomad without CNI integration, or non-container workloads — irrelevant to you

Alternatives

Not really applicable — CNI is the de facto standard interface for container networking on Kubernetes and most other orchestrators. The "alternatives" are the plugins that implement it:

• Calico — CNI plugin with strong network policy and BGP routing support.
• Cilium — eBPF-based CNI plugin, adds L7 policy and deep network observability.
• Kubenet (Kubernetes legacy, deprecated) — bare-bones non-CNI networking, being phased out; not a real alternative anymore.

Pricing

Fully open source, Apache-2.0. No paid tier, no commercial entity behind the spec itself. Costs show up downstream in whichever CNI plugin you deploy (some, like Cilium Enterprise or Calico Enterprise, have paid tiers — CNI itself does not).