In the context of the Certified Kubernetes Administrator (CKA) exam, the Container Network Interface (CNI) is a pivotal standard that defines how plugins configure network interfaces for Linux containers. Kubernetes does not implement networking natively; it relies on CNI plugins to handle Pod conn…In the context of the Certified Kubernetes Administrator (CKA) exam, the Container Network Interface (CNI) is a pivotal standard that defines how plugins configure network interfaces for Linux containers. Kubernetes does not implement networking natively; it relies on CNI plugins to handle Pod connectivity and IP management.
The system is composed of two primary file system locations on every node:
1. **CNI Binaries (`/opt/cni/bin`):** This directory houses the executable files. These include base plugins (like `bridge`, `loopback`, and `host-local`) and third-party provider plugins (like `calico`, `flannel`, or `weave`). These binaries perform the actual work of plumbing the network interfaces.
2. **CNI Configuration (`/etc/cni/net.d`):** The Kubelet inspects this directory to identify which plugin to execute. It reads configuration files (usually `.conf` or `.conflist`) that define the `type` of plugin, the subnet ranges, and IP Address Management (IPAM) details. If multiple files exist, the Kubelet typically uses the one that comes first lexicographically.
**The Workflow:**
When the Kubelet creates a Pod, it reads the config from `/etc/cni/net.d`, finds the corresponding binary in `/opt/cni/bin`, and executes it with the `ADD` command. This assigns an IP address to the Pod and attaches it to the cluster network. Conversely, when a Pod is terminated, the `DEL` command is invoked to clean up the network namespace and release the IP address.
For the CKA exam, you must be able to locate these directories to troubleshoot issues where Pods remain in a `ContainerCreating` state due to missing binaries or malformed configuration files.
CNI Plugins and Configuration Guide
What is CNI? CNI (Container Network Interface) is a set of standards and specifications used to configure network interfaces in Linux containers. Kubernetes does not implement a native network solution for Pod-to-Pod communication across nodes; instead, it relies on third-party plugins compliant with the CNI specification (such as Calico, Flannel, Weave Net, or Cilium) to handle networking tasks.
Why is it Important? In the context of the CKA exam and real-world clusters, CNI is the glue that allows the cluster to function. Without a functioning CNI plugin: 1. Nodes will remain in a NotReady state. 2. Pods will remain in a Pending state because they cannot differ IP addresses. 3. The Kubernetes networking model (flat network where every Pod has a unique IP) cannot be enforced.
How it Works When the Kubelet service starts on a node or when a Pod is scheduled, the Kubelet performs the following actions: 1. Identify Configuration: It looks into the default configuration directory, usually /etc/cni/net.d/, to find configuration files (.conf, .json, or .conflist). 2. Select Plugin: It reads the configuration file to determine which plugin to use (defined by the "type" field in the JSON). 3. Execute Binary: It invokes the corresponding executable binary located in the binary directory, usually /opt/cni/bin/, to set up the network namespace and interface for the Pod.
Exam Tips: Answering Questions on CNI plugins and configuration During the CKA exam, you may face troubleshooting scenarios where a node is broken or Pods cannot communicate. Follow these steps:
1. Check Node Status: If a node is NotReady, describe it using kubectl describe node <node-name>. If you see an error stating "NetworkPluginNotReady" or "cni config uninitialized", the CNI is likely missing or misconfigured.
2. Locate CNI Configurations: Navigate to /etc/cni/net.d/. The Kubelet uses the file that comes first lexicographically (alphabetical order). Action: Cat the file to identify the plugin name (e.g., "type": "calico").
3. Verify CNI Binaries: Navigate to /opt/cni/bin/. Ensure that the binary corresponding to the "type" found in the config file actually exists there. If the config asks for 'flannel' but the binary is missing, networking will fail.
4. Installing/Repairing CNI: If asked to install a network plugin, you will usually be provided with a link to the YAML manifest (e.g., for Weave or Calico). You must apply this manifest using kubectl apply -f <url>. Remember: Only install one CNI plugin per cluster unless specifically instructed otherwise, as multiple plugins can conflict.
5. Configuring Kubelet: Rarely, the CNI directories might be non-standard. Check the Kubelet service configuration (often in /var/lib/kubelet/config.yaml or the systemd service file) for the flags --cni-conf-dir and --cni-bin-dir to confirm where Kubelet is looking.