Hello readers, and welcome back to vahidsec.com.
If you work with Kubernetes, you probably know the standard definitions: CRI runs containers, CNI handles the network, and CSI manages storage. But what actually happens under the hood? How does kubelet orchestrate these interfaces without everything falling apart?
Today, we are going beyond the surface. We are going to look at the "secrets" and hidden logic of CRI, CNI, and CSI that make Kubernetes the powerhouse it is.
Let's dive into the deep end.
CRI (Container Runtime Interface): The "Pause" Secret
Most people think the CRI just pulls an image and starts a container. While true, this misses the most crucial step of Pod creation: The Pod Sandbox.
The Hidden Logic: The Almighty pause Container
Before your application container (e.g., Nginx or a Node.js app) ever starts, the CRI instructs the runtime to create a "Pod Sandbox." In runtimes like containerd, this is done by launching a tiny, almost invisible container called the pause container.
Why? Because containers in a Pod need to share the same Network and IPC namespaces. The pause container's sole job is to hold these namespaces open. If your app container crashes and restarts, the network IP doesn't change because the pause container is still holding the network namespace alive. Kubelet communicates with the runtime via gRPC over Unix domain sockets (e.g., /run/containerd/containerd.sock).
The Deep-Dive Flow:
CNI (Container Network Interface): The IPAM and eBPF Illusion
CNI is famously known for giving Pods their IP addresses. However, a massive misconception is that CNI routes traffic during the lifecycle of the pod.
The Hidden Logic: CNI is a "One-and-Done" Executable
Kubelet only executes the CNI binary at two distinct moments: when a Pod is created and when it is deleted. It doesn't run continuously as a daemon for pod-to-pod routing.
When a Pod is created, CNI does two secret things:
- IPAM (IP Address Management): The main CNI plugin (like Calico or Flannel) actually calls another hidden binary (like host-local or dhcp) just to calculate and reserve the next available IP address.
- The Veth Pair: It creates a virtual ethernet (veth) cable. One end goes into the Pod's network namespace (the pause container we mentioned earlier), and the other end attaches to a bridge on the host node.
Modern Security Bonus: Today, tools like Cilium bypass traditional iptables routing entirely by injecting eBPF (Extended Berkeley Packet Filter) programs directly into the Linux kernel, enforcing network policies at the socket level before packets even hit the virtual network!
The Deep-Dive Flow:
Code snippet
CSI (Container Storage Interface): The "Split Brain" Architecture
When you request an AWS EBS volume or a GCP Persistent Disk, you might think the local kubelet simply reaches out to the cloud provider. It absolutely does not. Giving every node IAM permissions to create cloud disks would be a massive security risk.
The Hidden Logic: The Controller vs. Node Plugin Split
CSI is specifically designed with a split architecture to maintain security and performance:
- The CSI Controller (StatefulSet/Deployment): This runs centrally (often on control plane nodes or as a single leader-elected pod). It holds the highly privileged cloud credentials. It talks to the Cloud API to physically create the disk (Provision) and attach it to the target EC2/Compute instance (Attach).
- The CSI Node (DaemonSet): This runs on every worker node. It has zero cloud credentials. It only knows how to look at the local Linux block devices (/dev/xvdf), format them (e.g., mkfs.ext4), and mount them into the Pod's directory (Mount).
This separation of concerns is the secret to why Kubernetes storage is both flexible and secure.
The Deep-Dive Flow:
Code snippet
Conclusion
Understanding the interfaces as simple APIs is good, but understanding the mechanics—the pause container in CRI, the IPAM delegation and eBPF integration in CNI, and the Controller/Node separation in CSI—transforms you from a Kubernetes user into a Kubernetes architect.
These architectural decisions prioritize security, modularity, and resilience.
Keep exploring, keep securing, and stay tuned to vahidsec.com for more deep dives.