We use analytics cookies.We use cookies to analyze site traffic and improve your experience.
Loading...
System Design and AI Engineering, by Roni Das. 984 interactive lessons.
Start LearningIntermediate · Kubernetes & Containers
The smallest deployable unit in Kubernetes: one or more containers sharing network and storage. Pods are ephemeral; if one dies, K8s creates a replacement.
In short
A Kubernetes Pod is the smallest deployable unit in Kubernetes: a wrapper around one or more containers that share the same network address and storage volumes and are always scheduled together onto a single node. Pods are disposable. When one dies, Kubernetes does not repair it, it creates a fresh replacement with a new IP.
In short
A Kubernetes Pod is the smallest deployable unit in Kubernetes: a wrapper around one or more containers that share the same network address and storage volumes and are always scheduled together onto a single node. Pods are disposable. When one dies, Kubernetes does not repair it, it creates a fresh replacement with a new IP.
Learn it in the course
This page is the free part.
₹1,111 in India$25 everywhere elseonce, for the whole course
The System Design course covers Kubernetes Pod across a run of lessons, not one page. These 4 alone are about 81 minutes of step-by-step reading, 1 of them with code you run in the browser, all with a quiz.
What a finite state machine is, DFA vs NFA, and how TCP and Kubernetes pods use one. Includes a type-safe state machine in code.
Firewall rules for Kubernetes pods, controlling which pods can communicate with each other.
Decoupling storage from pods so data survives container restarts, rescheduling, and failures.
Giving ephemeral containers access to persistent data through Kubernetes volume abstractions.
all part of
System Design Masterclass
770 lessons · about 287 hours · 18 free to read
₹1,111in India, by UPI
$25everywhere else, by PayPal
It is really nice and good Please join the course
You own this course
Continue with Finite State Machinepay once,
yours for life
You do not run a container directly in Kubernetes. You run a Pod, and the Pod runs the container. A Pod is a thin layer around one or more containers that tells the cluster: these containers belong together, schedule them on the same machine, and let them share a few things.
Most Pods hold exactly one container. The reason the Pod can hold more than one is the sidecar pattern: a main container plus a helper that does logging, a service mesh proxy, or config reloading. Every container in the same Pod shares one IP address, one set of ports, and any volumes you attach, so they can talk to each other over localhost.
A Pod is the unit of scheduling and the unit of replacement. Kubernetes never moves a running Pod to another node and never restarts a Pod in place when the node fails. It deletes the old Pod and creates a brand new one, with a new name and a new IP. That is why Pods are called ephemeral.
When you submit a Pod, the API server stores its spec in etcd. The scheduler picks a node that has enough CPU and memory and matches any rules you set, like node selectors or affinity. The kubelet on that node sees the assignment and asks the container runtime, usually containerd, to pull the images and start the containers.
Before your app containers start, the kubelet sets up the shared network namespace. A tiny pause container holds this namespace open so all the real containers could join it. The Pod gets one IP from the cluster network, and a CNI plugin like Calico or Cilium wires it up so any Pod can reach any other Pod directly, no NAT.
Each container can declare resource requests and limits. Requests drive scheduling decisions, limits get enforced at runtime, and a container that exceeds its memory limit is killed with an OOMKilled status. Liveness and readiness probes let the kubelet restart a stuck container or pull a not-ready Pod out of the load balancer rotation.
In practice you almost never create a bare Pod yourself. A bare Pod has no self-healing: if its node dies, the Pod is gone for good. Instead you create a Deployment, StatefulSet, or DaemonSet, and the controller creates and recreates Pods for you to match a desired count.
The big trade-off is that Pods are cattle, not pets. You cannot rely on a Pod's IP or name staying the same, so you put a Service in front of a set of Pods to get a stable address. You do not write important data to the Pod's local disk because it vanishes on restart, so you mount a PersistentVolume for anything that must survive.
Keep Pods small and single-purpose. Stuffing three unrelated apps into one Pod means they scale together, fail together, and get redeployed together, which is rarely what you want. Use multiple containers in one Pod only when they are tightly coupled and genuinely need to share localhost or a volume.
Say you run a web API. You create a Deployment that asks for 3 replicas. Kubernetes creates 3 Pods, each with your API container, spread across nodes. A Service named api groups them under one DNS name so callers hit api.default.svc.cluster.local without caring which Pod answers.
One night a node crashes. Two of your Pods die with it. Once the node stops reporting, Kubernetes marks its Pods as not ready, so the Service stops sending them traffic. A few minutes later (about five by default) those Pods are evicted, and the Deployment controller notices it has 1 Pod instead of 3 and creates 2 new Pods on healthy nodes. No human intervention, and users barely notice.
If you add a sidecar, say an Envoy proxy for a service mesh like Istio, it lives in the same Pod as your API container and shares its network. Your app sends traffic to localhost and the proxy handles encryption and routing, all inside the same Pod boundary.
Kubernetes
The Pod is Kubernetes' native primitive; every workload type, from Deployments to Jobs, ultimately produces Pods.
Google Kubernetes Engine
Google runs production Pods at massive scale; the design comes from Borg, Google's internal cluster manager that inspired Kubernetes.
Istio
Injects an Envoy sidecar container into each Pod so application traffic is proxied over localhost for mTLS and routing.
Amazon EKS
Schedules Pods onto EC2 or Fargate, where each Fargate task maps to a single isolated Pod.
A container is a single running process image. A Pod is the Kubernetes wrapper that schedules one or more containers together, gives them a shared IP and shared volumes, and is the smallest thing Kubernetes can deploy. You run Pods, and Pods run containers.
Yes. All containers in a Pod share the same network and can talk over localhost, plus any mounted volumes. This is used for the sidecar pattern, like a logging agent or a service mesh proxy. Most Pods still hold just one container.
Pods are ephemeral. Kubernetes does not repair a failed Pod, it deletes it and creates a fresh one, which gets a new IP from the cluster network. Because IPs are not stable, you put a Service in front of Pods to get a fixed address and DNS name.
Almost never. A bare Pod has no self-healing, so if its node dies it is gone permanently. Use a Deployment, StatefulSet, or DaemonSet, which create and recreate Pods automatically to keep the desired number running.
Not on the Pod's local disk, which is wiped when the Pod is recreated. Mount a PersistentVolume backed by network or cloud storage so the data outlives any single Pod.
Kubernetes
An orchestration platform that automates deploying, scaling, and managing containerized applications. K8s is the operating system for your cloud.
Container
A lightweight, isolated environment that packages an application with its dependencies. Shares the host OS kernel, unlike VMs. Starts in milliseconds.
Kubernetes Service
A stable network endpoint that load-balances traffic across a set of pods. Pods come and go, but the Service's IP and DNS name stay constant.
Docker
A platform for packaging applications into lightweight, portable containers. 'Works on my machine' becomes 'works everywhere.'
Kubernetes Deployment
A K8s resource that manages rolling updates and rollbacks for a set of pods. You declare the desired state and K8s converges to it.
Kubernetes Ingress
A K8s resource that manages external HTTP/HTTPS access to services inside the cluster. Routes traffic by hostname or URL path to different backend services.
This page explains the idea. The course covers it step by step, with diagrams. It is part of the System Design Masterclass course, which has 770 lessons. 18 of them are free to read. You pay once and keep it for life, with no subscription.
See the System Design Masterclass coursecourse 1
From absolute beginner to principal engineer, drawn step by step.
Asked about Kubernetes Pod in an interview?
Each question has why it is asked, a full answer, what the interviewer listens for, the follow-ups, the common mistakes and a diagram (268 diagrams in all). A PDF you keep, junior to staff level.
India: UPI, cards or netbanking through Razorpay. Elsewhere: card or PayPal. Download at once from My packs.
