A container, at its heart, is just an isolated process running on a host machine. Linux gives it isolation through two building blocks: namespaces (which give the process its own private view of things like network interfaces, process IDs, and mount points) and cgroups (which limit how much CPU, memory, and I/O it can consume). The network namespace is the one that matters here — when a container is created, Linux can give it a completely empty, private network stack: no interfaces, no routes, no IP address, nothing. It is a sealed room with no doors.

Someone has to open a door. That means: creating a virtual network interface inside the container’s namespace, connecting the other end of that interface to something on the host (usually a virtual bridge or switch), assigning an IP address to the container’s side, and adding routing rules so packets know where to go. This whole sequence is called network plumbing, and every container platform — Docker, Kubernetes, containerd, Podman — needs a consistent, repeatable way to do it every single time a container starts.

Two competing ideas emerged to standardize this plumbing: Docker built its own model called the Container Network Model (CNM), implemented through a library called libnetwork. Separately, CoreOS (the company behind rkt, an early Docker competitor) proposed a simpler, more minimal specification called the Container Network Interface (CNI). CNI was later donated to the Cloud Native Computing Foundation (CNCF) and became the networking standard used by Kubernetes and most of the container ecosystem outside Docker itself. Understanding both models — and how they differ — is the key to understanding this entire topic, because it explains why the question “what is CNI in Docker?” has a more nuanced answer than a simple one-line definition.

CNI stands for Container Network Interface. Despite the name, it is not a piece of software you install and run — it is a specification, a contract. It defines, in very precise terms, how a container runtime (the software that creates and manages containers) should talk to a network plugin (the software that actually sets up networking) so the two can work together no matter who wrote either side.

The contract is deliberately tiny. A CNI plugin is just an executable binary that understands four operations, delivered as commands with a JSON configuration piped into its standard input:

That’s it. Four verbs. Everything else — how the IP address is chosen, whether encryption is used, whether there is a firewall in front of the container — is left entirely up to whichever plugin implements those four verbs. This minimalism is exactly why CNI spread so widely: writing a new plugin is a small, well-defined task, so an entire ecosystem of networking vendors (Calico, Cilium, Flannel, Weave, AWS VPC CNI, Azure CNI, and dozens more) could all build compatible plugins independently, and any CNI-compatible runtime could use any of them interchangeably.

Classic Docker Engine — the docker run, docker network create world most people picture when they hear “Docker” — does not use CNI by default. Docker built and uses its own model, the Container Network Model (CNM), implemented by an internal library called libnetwork. When you run docker network create mynet or attach a container to the default bridge network, you are watching CNM in action, not CNI.

CNM organizes networking around three concepts instead of CNI’s four commands:

Docker ships built-in CNM drivers for common cases: bridge (the default, a private virtual switch on a single host), host (the container shares the host’s network stack directly, no isolation), overlay (a virtual network spanning multiple hosts, used by Docker Swarm), macvlan (gives a container its own MAC address on the physical network, as if it were a real device), and none (no networking at all). These drivers are conceptually similar in purpose to CNI plugins — they both “plumb” a container into a network — but they speak a completely different internal protocol and cannot be swapped for a CNI plugin without extra glue.

So where does the question “CNI in Docker” come from, if Docker Engine does not speak CNI? Three real situations explain it, and they are the reason this topic causes so much confusion online.

A working CNI installation is made of a handful of concrete pieces sitting on disk, not one monolithic program. Understanding each piece makes debugging real clusters dramatically easier.

Plugins are frequently chained. A single network configuration file can list several plugins that run in sequence, each one enriching the result of the previous one. A very common chain looks like: a main plugin (e.g. bridge or calico) creates the interface and wires it to the network, an IPAM plugin (e.g. host-local or whereabouts) hands out the IP address, and one or more meta plugins (e.g. portmap, bandwidth, tuning) apply extra behavior like port forwarding or traffic shaping on top.

graph TB
    RT["Container Runtime
(containerd / kubelet)"] -->|invokes with JSON config| MAIN["Main Plugin
e.g. Calico / Bridge"]
    MAIN --> IPAM["IPAM Plugin
e.g. host-local"]
    IPAM -->|assigns IP| MAIN
    MAIN --> META1["Meta Plugin
portmap"]
    META1 --> META2["Meta Plugin
bandwidth"]
    META2 --> NS["Container Network Namespace"]
    MAIN -.->|creates veth pair| BR["Host Bridge / Overlay"]
    BR --> HOSTNET["Host Network Stack"]
    

When the runtime decides a container needs networking, it does not open a persistent connection to a daemon — it simply executes the plugin binary as a short-lived process, exactly once per operation, and communicates with it through three channels: environment variables, standard input, and the exit code.

Because every step is stateless and process-based, CNI plugins are unusually easy to test in isolation — you can literally invoke one by hand from a shell with the right environment variables set, which is exactly how experienced engineers debug broken pod networking in production.

Zooming out from a single plugin call, here is the full lifecycle a container’s network identity moves through, from birth to death, in a CNI-managed environment such as Kubernetes.

sequenceDiagram
    participant U as Operator/Scheduler
    participant KB as Kubelet
    participant CR as containerd
    participant CNI as CNI Plugin
    participant NS as Pod Netns
    U->>KB: Schedule Pod on Node
    KB->>CR: Create sandbox (pause container)
    CR->>NS: Create empty network namespace
    KB->>CNI: ADD (via CRI networking call)
    CNI->>NS: Create veth pair, assign IP, set routes
    CNI-->>KB: Return interface + IP JSON
    KB->>CR: Start application containers in same netns
    Note over NS: Pod is now reachable
    U->>KB: Delete Pod
    KB->>CNI: DEL
    CNI->>NS: Remove veth, release IP, clean routes
    KB->>CR: Destroy sandbox
    

Notice a subtle but important detail: all containers inside one Kubernetes pod share a single network namespace, created once by a special lightweight “pause” or “sandbox” container. CNI’s ADD is only called once per pod, not once per container inside it — this is why every container in a pod can reach each other over localhost and shares the same IP address. Docker, running standalone, has no equivalent “pod” concept by default — each container normally gets its own namespace unless you explicitly ask it to share one with --network container:<name>.

Not all CNI plugins do the same job. They generally fall into a few families, and production clusters often run several together.

Given everything above, here is how CNI shows up in real, working infrastructure that includes Docker somewhere in the stack.

Because a CNI plugin runs with elevated privileges — it manipulates network namespaces and host routing tables — its security posture matters as much as any other cluster component. Several concerns deserve attention.

Privilege scope. CNI plugins typically need CAP_NET_ADMIN and similar Linux capabilities to create interfaces and modify routes. A compromised or malicious plugin binary effectively has host-level networking control, so plugin binaries should only ever be sourced from trusted, verified distributions and pinned to specific, checksummed versions.

Network policy enforcement. Plain connectivity plugins like early Flannel provide no isolation between pods by default — any pod can talk to any other pod. Plugins such as Calico and Cilium add a NetworkPolicy engine, letting operators define allow-lists of which pods, namespaces, or IP ranges may communicate, which is the container-world equivalent of firewall rules and is essential for any multi-tenant or regulated environment.

Encryption in transit. Overlay networks send container traffic across regular host networking, which may traverse untrusted segments. Options like WireGuard-based encryption (available in Calico and Cilium) or Weave Net’s built-in encrypted mesh protect data as it crosses between hosts.

Because CNI plugins run as short-lived, one-shot processes, traditional “check if the daemon is alive” monitoring does not directly apply — the plugin binary itself no longer exists moments after it runs. Observability instead focuses on three layers.

A healthy operational habit is to track pod network setup latency as a first-class SLO-adjacent metric — a rising trend in ADD call duration is often the earliest signal of IPAM exhaustion (running out of assignable addresses in a subnet) long before pods start failing outright.

Plan your IP space before you deploy. Pod CIDR, service CIDR, and node CIDR ranges must never overlap with each other or with any existing corporate network the cluster needs to reach — this single planning step prevents the majority of “mysteriously unreachable” incidents reported by teams new to CNI.

Match the plugin to the environment, not the hype. A cloud-native IPAM plugin that assigns real VPC addresses (like AWS VPC CNI) removes a layer of NAT overhead on cloud infrastructure but can exhaust the available IP pool faster on smaller subnets; an overlay plugin like Flannel is simpler to reason about but adds encapsulation overhead. Benchmark under realistic load rather than assuming.

Keep CNI binaries and cluster components in version lockstep. The CNI spec itself has evolved (notably from 0.x to 1.0.0), and mismatched plugin/runtime versions have historically caused ADD calls to silently fail or misinterpret configuration fields.