☸️ Kubernetes Internals Series (1/3)
When I first started learning Kubernetes, I assumed Kubernetes was responsible for creating containers.
It isn't.
Kubernetes is an orchestration platform. It decides what should run, where it should run, and when it should be replaced—but it doesn't create containers itself.
That's the responsibility of the Container Runtime Interface (CRI).
Think of it like this:
🏢 Kubernetes = Project Manager
👷 Container Runtime = Worker
🤝 CRI = The communication bridge between them
What happens when you deploy a Pod?
kubectl apply
│
▼
API Server
│
▼
Scheduler selects a Node
│
▼
Kubelet
│
▼
CRI
│
▼
Container Runtime (containerd / CRI-O)
│
▼
OCI Runtime (runc)
│
▼
Container StartsStep-by-step
🔹 Apply a Deployment.
🔹 Scheduler selects a worker node.
🔹 Kubelet receives the Pod specification.
🔹 CRI forwards the request to the container runtime.
🔹 The runtime pulls the OCI image.
🔹 Linux namespaces and cgroups prepare the execution environment.
🔹 The container starts successfully.
Within seconds, your Pod is running.
Why does CRI matter?
Before Kubernetes adopted CRI, it relied heavily on Docker.
That made Kubernetes tightly coupled to a single runtime.
Today, thanks to CRI:
✔ Kubernetes supports multiple runtimes.
✔ Runtime implementations can evolve independently.
✔ Security and maintainability improve.
✔ New runtimes can integrate without changing Kubernetes itself.
Common Container Runtimes
• containerd (Most Kubernetes clusters)
• CRI-O
• Mirantis Container Runtime
One of the biggest takeaways for me was realizing that Kubernetes doesn't create containers—it delegates that responsibility through CRI.
Understanding this made troubleshooting startup failures and runtime issues much easier.
In Part 2, I'll explain how Kubernetes gives every Pod its own IP address and enables Pod-to-Pod communication using the Container Network Interface (CNI).
#Kubernetes #CRI #ContainerRuntime #CloudNative #DevOps #PlatformEngineering #Containers #Linux #AWS #AmazonEKS #Docker #OpenSource #CloudNative
🌐 Kubernetes Internals Series (Part 2/3)
One of the most common questions I hear is:
"How does every Pod get its own IP address?"
The answer is simple.
Kubernetes doesn't perform networking.
It defines the networking model.
The implementation is handled by the Container Network Interface (CNI).
Without a CNI plugin, your Pods can start—but they won't be able to communicate.
What happens when a Pod is created?
Pod Scheduled
│
▼
Kubelet
│
▼
CNI Plugin
│
┌──────────────┐
│ Assign IP │
│ Create veth │
│ Configure │
│ Routes │
│ Network Rules│
└──────────────┘
│
▼
Pod ReadyWhat does a CNI plugin actually do?
When Kubelet creates a Pod, it invokes the configured CNI plugin.
The plugin automatically:
✔ Creates the Pod's network interface
✔ Assigns an IP address
✔ Configures routing
✔ Connects the Pod to the cluster network
✔ Applies networking rules
Only after these steps does Kubernetes mark the Pod as Ready.
Popular CNI Plugins
🔹 Amazon VPC CNI
Native networking for Amazon EKS where Pods receive VPC IP addresses.
🔹 Calico
Widely used for advanced networking and Network Policies.
🔹 Cilium
Built on eBPF, providing high-performance networking, security, and observability.
🔹 Flannel
A lightweight overlay networking solution for simpler environments.
Why should engineers understand CNI?
Many production issues are actually networking issues.
Examples include:
• Pods cannot communicate.
• Services are unreachable.
• DNS resolution fails.
• Network Policies block traffic.
• Cross-node communication doesn't work.
Understanding CNI turns networking from a mystery into a predictable troubleshooting process.
In Part 3, I'll cover how Kubernetes provides persistent storage using the Container Storage Interface (CSI) and why your data survives even after Pods are recreated.
#Kubernetes #Networking #CNI #AmazonEKS #CloudNative #DevOps #PlatformEngineering #Linux #AWS #Cilium #Calico #Containers
💾 Kubernetes Internals Series (Part 3/3)
Containers are designed to be temporary.
Data isn't.
If a Pod is deleted, its writable filesystem disappears.
So how do databases, applications, and stateful workloads keep their data?
That's where the Container Storage Interface (CSI) comes in.
CSI provides a standard way for Kubernetes to work with different storage providers without needing provider-specific code inside Kubernetes.
The storage workflow
Deployment
│
▼
Pod Requests Storage
│
▼
PersistentVolumeClaim (PVC)
│
▼
StorageClass
│
▼
CSI Driver
│
▼
Cloud Storage
(EBS, Azure Disk,
Persistent Disk, etc.)
│
▼
Volume Attached
│
▼
Pod StartsWhat happens behind the scenes?
✔ The application requests storage using a PVC.
✔ Kubernetes matches the request with a StorageClass.
✔ The CSI driver provisions a volume.
✔ The storage provider creates the disk.
✔ The volume is attached to the worker node.
✔ Kubernetes mounts the volume inside the container.
Your application can now read and write persistent data.
Why CSI changed Kubernetes
Before CSI, adding support for every storage platform meant modifying Kubernetes itself.
Today:
✔ Storage vendors build their own CSI drivers.
✔ Kubernetes remains lightweight and extensible.
✔ New storage solutions can integrate without changing core Kubernetes.
Common CSI Drivers
• Amazon EBS CSI Driver
• Amazon EFS CSI Driver
• Azure Disk CSI Driver
• Azure File CSI Driver
• Google Persistent Disk CSI Driver
• Ceph CSI
• Longhorn
Understanding CSI helped me troubleshoot issues around:
• Pending PVCs
• Volume attachment failures
• StorageClass misconfigurations
• Multi-AZ storage behavior
• StatefulSet deployments
Kubernetes isn't just about Pods.
It's built on well-defined interfaces that separate compute, networking, and storage.
CRI manages containers.
CNI connects them.
CSI stores their data.
Once you understand these three building blocks, Kubernetes becomes much easier to reason about and troubleshoot.
#Kubernetes #CSI #Storage #CloudNative #DevOps #PlatformEngineering #AWS #AmazonEKS #Containers #StatefulSets #Linux