liveBook · Manning

Container Network Interface

As explained in Acing the Certified Kubernetes Administrator Exam, Second Edition

The Container Network Interface (CNI) is a standard specification and plugin interface for configuring networking and network resources for containers.

The Container Network Interface (CNI) is a specification and library for configuring network interfaces in Linux containers. In Kubernetes, it provides a pluggable way to set up pod networking across nodes without tying the cluster to one network provider. section 2.3.2

When a pod is scheduled, the container runtime calls the CNI plugin. The plugin configures its network interface, IP address, and routes; it may also implement network policies. When the pod is removed, the plugin tears down those resources. This is why a missing or unhealthy CNI is a useful first check when pods cannot communicate. section 2.3.2 section 8.4

Keep these networking scopes separate:

  • The node CIDR belongs to the underlying network connecting cluster nodes. section 6.1
  • The CNI manages the pod CIDR, from which pods receive IP addresses. section 6.1
  • The API server configures and manages the separate Service CIDR. section 6.1

Inspect the installed plugin

Run `kubectl get pods -n kube-system` to look for networking components. On a kind cluster, `kubectl -n kube-system get ds kindnet` checks the Kindnet DaemonSet and its readiness. Inspect `/etc/cni/net.d/10-kindnet.conflist` on a node to see its plugin configuration. After installing Flannel in the practice cluster, `kubectl get po -A` shows whether its DaemonSet pods are running, and `kubectl get no` checks node readiness. section 2.3.2 section 6.5

{
    "cniVersion": "0.3.1",
    "name": "kindnet",
    "plugins": [
    {
        "type": "ptp",
        "ipMasq": false,
        "ipam": {
                     "type": "host-local",
                     "dataDir": "/run/cni-ipam-state",
                     "routes": [
                                  { "dst": "0.0.0.0/0" }
                     ],
                     "ranges": [
                                    [ { "subnet": "10.244.0.0/24" } ]
                     ]
        }
        ,
        "mtu": 65535
 },
 {
        "type": "portmap",
        "capabilities": {
                   "portMappings": true
        }
 }
 ]
}

The Kindnet configuration shows a concrete plugin chain: point-to-point networking with host-local IP address management and a route, followed by port mapping. section 2.3.2

Choose the plugin for the required behavior, not just because it starts successfully. Flannel and Calico are the CKA-focused options here; Calico supports Network Policies, while Flannel does not. Practice identifying the installed plugin, checking its status, and verifying node and pod readiness after a change. section 6.5 section 9.3.5

How Acing the Certified Kubernetes Administrator Exam, Second Edition covers it

How deep it goes
Explains plugin calls, interface setup and teardown, then shows configuration and readiness checks without detailing plugin implementation.
Examples
Uses Kindnet status and configuration, Flannel installation checks, and a Calico-versus-Flannel Network Policy distinction.
What it assumes
Builds on container bridge networking while defining CNI and distinguishing node, pod, and Service address ranges.
What you can do after
Operate/configure it by identifying a CNI plugin, inspecting its configuration, and checking readiness after installation.
How it connects
Connects CNI to container runtimes, pod CIDRs, overlay networking, DaemonSets, and Network Policies.

Related concepts

This explainer was generated by Manning's knowledge graph from the text of Acing the Certified Kubernetes Administrator Exam, Second Edition. The section links point to the parts of the book it draws on.