Shiv Bhosale · August 22, 2026

[WIP] Everything I know about Kubernetes

This is all that I know about Kubernetes so far. This is a work in progress and I will keep adding more things here over time.

Contents

Planes of Operation

I joined the Elastic Kubernetes Service at AWS in late 2024 and by then I was only familiar with the application layer of Kubernetes. As part of my induction to the team, the first concept that was drilled into me was the planes of operation: the control plane and the data plane. Here is a mental model that I use:

Control plane API server ×N replicas · all active kube-scheduler leader elected · 1 active controller-manager leader elected · 1 active etcd ×M replicas · raft leader the API server is the only bridge between the planes Data plane kubelet · kube-proxy node-1 kubelet · kube-proxy node-2 kubelet · kube-proxy node-3 ⋯ ×N
every node runs a kubelet and kube-proxy · the colored squares are your pods · drawing 3 of N nodes

The boxes in the diagram may feel unfamiliar to those without a Kubernetes background and that is alright. In the next few sections I will make this diagram a little more "explorable" in different ways and it will help readers grok Kubernetes.

The first section will be on "Pods", which is perhaps a concept that is easy to wrangle for those who are Kubernetes users.

Pods

A pod is the smallest deployable computation on Kubernetes. It's also valuable to understand what a pod is not. A binary doom.exe stored somewhere on cloud-storage or a hard-disk would be further away from the concept of a pod than that binary running on a pregnancy test kitnote"It's Pregnancy Test Doom!" (Foone Turing), from This Programmer Figured Out How to Play Doom on a Pregnancy Test, Popular Mechanics, 2020..

A pod captures how software is run. We'll dive deep into the internals of the pod later but for now here is the anatomy of a pod manifest:

1apiVersion: v1
2kind: Pod
what kind of object this is
3metadata:
4 name: doom
its name in etcd
5spec:
6 containers:
7 - name: doom
8 image: doom/doom:1.0
the software to run
9 command: ["/doom"]
how it starts
10 resources:
11 requests:
12 cpu: "2"
13 memory: 100Mi
the compute it needs
pod.yaml · hover any part of the spec to see what it does

Now let's watch kubectl apply -f pod.yaml actually happen. Step through it below: the top diagram lights up whichever component is doing something, and the terminal, audit log, and etcd tabs underneath all update in lockstep, since they are three views of the same one event stream.

Control plane API server ×N replicas · all active kube-scheduler leader elected · 1 active controller-manager leader elected · 1 active etcd ×M replicas · raft leader the API server is the only bridge between the planes Data plane kubelet · kube-proxy node-1 kubelet · kube-proxy node-2 kubelet · kube-proxy node-3 ⋯ ×N
every box starts dim · step through below to watch the request travel · hover or tap any component for what it does

            
timeuserverbURIprotocolstatus

no requests yet


          

Try it: step forward or backward and watch how the state across the terminal, API Server and etcd changes. Most Kubernetes users have only observed the Terminal tab.

Control Plane

More explanations will land in this section as the blog evolves over time.

Data Plane

Anatomy of a (EKS) Worker NodenoteIllustrated here with the EKS AL2023 AMI build, since its source is public: awslabs/amazon-eks-ami, which I maintain. The layering is generic to any Kubernetes worker node, EKS is just the concrete, inspectable example.

#whatwhy it's there

How Pods Run

kubelet syncLoop PLEG CRI client CRI · gRPC over a unix socket containerd CRI plugin content store snapshotter task service CNI plugin assigns the pod an IP and wires its veth pair containerd-shim-runc-v2 one per pod · stays alive as the container's parent runc runs, then exits (nothing left behind) Linux kernel namespaces cgroups veth overlayfs pod one set of namespaces, shared pause holds them open doom your container 10.244.1.7 one IP for the whole pod watch: pod assigned here RunPodSandbox pause image: already cached prepare rootfs start shim runc create clone(CLONE_NEWNET…) ADD attach veth, assign IP PullImage CreateContainer runc start container is running

Pod Networking on the Node

pod network namespace eth0 10.244.1.7/32 lo 127.0.0.1 default via 169.254.1.1 no host has this address veth pair connects the two namespaces namespace boundary host network namespace eni8f3a2b1c the host side of the pair tc qdisc bandwidth limits, eBPF conntrack tracks each connection policy routing a routing table per ENI DNAT Service IP → pod IP SNAT applied when leaving the VPC eth0 · eth1 — the ENIs the pod's IP is a secondary address on one of them VPC subnet other pods, other nodes, the internet beyond

Cite asShiv Bhosale, "Everything I know about Kubernetes", notes.shvbsle.in, 2026. notes.shvbsle.in/kubernetes

BibTeX
@misc{bhosale2026kubernetes,
  author = {Bhosale, Shiv},
  title  = {Everything I know about Kubernetes},
  year   = {2026},
  url    = {https://notes.shvbsle.in/kubernetes/}
}