To try the hands-on steps you will need Docker plus a local cluster tool, kind or minikube. Everything here is free.
To try the hands-on steps you will need Docker plus a local cluster tool, kind or minikube. Everything here is free.
Kubernetes runs many containers across many machines and keeps them healthy without you watching. You tell it what you want, three copies of this app, always running, and it makes that true and keeps it true. If a container dies, it starts a new one. If a machine dies, it moves the work. It is powerful and it is heavy, and a big part of learning it is knowing when you actually need it.
Who this is for: a college passout or career switcher who keeps seeing Kubernetes on job posts and wants the real mental model, not a wall of YAML they copy without understanding.
It is 3am and a server holding your app quietly dies. On a hand-run setup, the site is down until a human wakes up, notices, and restarts things. With Kubernetes, the app was running as three copies across three machines, the system noticed one vanish within seconds, and it started a replacement on a healthy machine before anyone woke up. Nobody was paged. That self-healing is the reason Kubernetes exists, and it is why large systems lean on it.
Part 8 taught you to package an app into a container. One container on one machine is easy. The hard problems start when you have many containers that must stay running, scale under load, survive machines failing, and find each other on the network. Kubernetes is the system that solves those problems. Here is the shape of a cluster before we name the parts.
The words you must know
Kubernetes has a reputation for jargon, but five words carry most of the meaning. Learn these and the documentation stops looking like a foreign language.
| Term | What it is |
|---|---|
| Pod | The smallest unit, one or more containers that run together |
| Node | A machine, virtual or physical, that runs pods |
| Deployment | A rule that keeps a set number of identical pods running |
| Service | A stable network address in front of changing pods |
| Cluster | The control plane plus all the nodes, working as one |
The one that trips people up is Service. Pods are disposable and each new pod gets a new IP address, so you cannot point traffic at a pod directly, it might be gone in a minute. A Service is a stable front door with a fixed address that always routes to whichever pods are currently alive. It is the answer to how does anything find my app when the pods keep changing.
Declare what you want, let Kubernetes keep it true
This is the single most important idea in Kubernetes, and it is what makes it different from running commands by hand. You do not tell Kubernetes start a container. You declare a desired state in a file, three copies of this image should always be running, and hand it over. Kubernetes constantly compares reality to your declaration and fixes any gap. A pod died and now there are two? It starts a third. You asked for five instead of three? It adds two. This never-ending compare-and-correct is called reconciliation.
You write that desired state as a YAML file called a manifest. Here is a Deployment that asks for three copies of the image you built in Part 8.
apiVersion: apps/v1
kind: Deployment
metadata:
name: web
spec:
replicas: 3
selector:
matchLabels:
app: web
template:
metadata:
labels:
app: web
spec:
containers:
- name: web
image: myapp:1.0
ports:
- containerPort: 3000The line that matters most is replicas: 3. That is your declaration. Everything else tells Kubernetes which image to run and how to label the pods so the Deployment can find and count them.
kubectl is your remote control for the cluster
You talk to a cluster with one command line tool, kubectl. You apply your manifest with it, then ask the cluster what is running. Watch the three pods come to life.
$ kubectl apply -f deployment.yaml
deployment.apps/web created
$ kubectl get pods
NAME READY STATUS RESTARTS AGE
web-7d9f8c6b5-2xk4p 1/1 Running 0 20s
web-7d9f8c6b5-8fj2n 1/1 Running 0 20s
web-7d9f8c6b5-q5m7r 1/1 Running 0 20sThree pods, all Running, zero restarts. Delete one with kubectl delete pod and within seconds a new one appears to replace it, because your declaration still says three. That is reconciliation working in front of you. Here are the commands you will lean on daily.
| Command | What it does |
|---|---|
kubectl apply -f file.yaml | Create or update from a manifest |
kubectl get pods | List pods and their status |
kubectl logs pod-name | Read a pod’s output |
kubectl describe pod name | Show detailed events for a pod |
kubectl scale --replicas=5 | Change how many copies run |
CrashLoopBackOff and how to read it
The moment you meet Kubernetes for real, you meet this status. A pod shows CrashLoopBackOff, and beginners panic because the name sounds catastrophic. It is not. It is Kubernetes being honest: the container keeps starting, crashing, and being restarted, and because it keeps failing, Kubernetes waits longer between each retry, the backoff. The status is a symptom, not the cause. The cause is in the logs.
You see a pod stuck restarting:
$ kubectl get podsNAME READY STATUS RESTARTSweb-7d9f8c6b5-2xk4p 0/1 CrashLoopBackOff 4The RESTARTS count climbing is the tell. Now read why it crashed, using
--previous to see the logs from the last failed start:$ kubectl logs web-7d9f8c6b5-2xk4p --previousError: connect ECONNREFUSED 10.0.0.5:5432There it is. The app cannot reach its database on the Postgres port, so it exits on startup, and Kubernetes dutifully restarts it into the same failure. The fix is the database connection, not anything in Kubernetes. If the logs are empty,
kubectl describe pod shows the events, which often reveal an out-of-memory kill or a failing health check instead.Getting traffic to your pods
Three running pods are useless if nothing can reach them, and this is where the Service from the glossary does its real work. Because pods come and go and each gets a fresh IP, you never send traffic to a pod directly. You create a Service, which holds a stable address and automatically forwards requests to whichever pods are currently healthy and labelled to match it. Add or remove pods and the Service keeps up on its own, with no config change.
There are a couple of Service types worth knowing early. A ClusterIP Service, the default, gives your app an address that only other things inside the cluster can reach, which is exactly what you want for an internal database or a backend other services call. A LoadBalancer Service asks the cloud to hand out a public address so the outside world can reach your app, which connects straight back to the load balancer idea from Part 6. So the request path from that part now has a name inside Kubernetes: a Service is the load balancer for your pods. When someone asks how does the internet reach a pod, the honest one line answer is through a Service, never directly. Get that idea and the networking half of Kubernetes stops being mysterious.
Rolling updates: new version, no downtime
Here is where declaring state pays off in a way that feels almost magical. You built version 2.0 of your image and want it live, but you cannot take the site down to swap it. Kubernetes handles this with a rolling update. You change the image line in your Deployment from myapp:1.0 to myapp:2.0 and apply the file. Kubernetes then replaces the old pods with new ones a few at a time, waiting for each new pod to report healthy before it retires an old one. Traffic keeps flowing to whichever pods are ready throughout, so users never see an outage.
And when a release goes wrong, the same mechanism runs in reverse. One command, kubectl rollout undo, tells Kubernetes to go back to the previous version, and it rolls the old pods back in the same safe, gradual way. This is a genuine advantage over hand-run deploys, where a bad release often means scrambling to rebuild the previous state under pressure. Here the previous state was never thrown away, so recovery is a single command. That safety net is a real reason teams accept the complexity of Kubernetes once they operate at scale, and it is worth seeing at least once even if your first job never needs it.
Most teams do not need Kubernetes
I will say plainly what a lot of tutorials will not. Most small projects should not run Kubernetes. It is built to solve the problems of many services across many machines: automatic scaling, self-healing, rolling updates at scale. If you have one app and modest traffic, a single container on a managed platform does the job with a fraction of the complexity. Kubernetes adds a control plane to run, networking to understand, and a large surface of things that can break. Adopt it when the pain of not having it, servers you babysit, 3am restarts, scaling you do by hand, is clearly bigger than the pain of running it.
For learning, though, it is absolutely worth your time, because employers ask about it and because the concepts, desired state and reconciliation, show up everywhere in modern infrastructure. Learn it on a tiny local cluster where the stakes are zero. Just do not assume every project you join should be on it. A senior engineer who can say we do not need Kubernetes for this yet is often saving the team months of avoidable complexity.
What is a Pod, and why not just deploy containers directly? Answer: a Pod is the smallest deployable unit in Kubernetes, wrapping one or more containers that share networking and storage and always run together on the same node. You do not manage pods by hand because they are disposable. You declare a Deployment, and it creates and replaces pods to match your desired replica count. Mention that pods get new IPs when recreated, which is why a Service exists, and you have shown the whole mental model in three sentences.
If your team runs Kubernetes, your daily reality is reading pod status and logs, not designing clusters. Being able to run
kubectl get pods, spot the one in CrashLoopBackOff, pull its logs with --previous, and say the app cannot reach the database, this is not a Kubernetes problem makes you useful immediately. Nobody expects a junior to architect the cluster. They expect you to navigate it calmly when a pod misbehaves, and that is a learnable, high-value skill.Free, about thirty minutes, all local. Install kind or minikube, which run a full Kubernetes cluster on your laptop, then apply a simple Deployment for the nginx image with three replicas. Run
kubectl get pods to see all three, then kubectl delete pod on one and watch a replacement appear within seconds. Finally run kubectl scale deployment web --replicas=5 and watch two more spin up. How to check you did it right: the pod count always returns to what you declared, no matter how many you delete. You just watched self-healing and scaling with your own eyes.Kubernetes questions beginners are scared to ask
Do I need to know Docker before Kubernetes?
Yes. Kubernetes runs containers, so the image, container, and port ideas from Part 8 are the foundation. Trying to learn Kubernetes without understanding a single container is like learning to conduct an orchestra before you can play one instrument. Get comfortable with Docker first.
Should I run my own cluster or use a managed one?
For real work, use a managed Kubernetes service from a cloud provider. Running the control plane yourself is a serious job, and managed services handle the hard, risky parts. For learning, a local cluster with kind or minikube is free and perfect, since the kubectl commands are identical.
What is a container runtime, and where did Docker go?
Kubernetes runs containers through a runtime, and since version 1.24 it uses runtimes like containerd directly rather than Docker itself. Your Docker-built images still run perfectly, because they follow a shared standard. You just do not need the Docker engine on the cluster nodes.
Is all that YAML really necessary?
It is the price of declaring everything as versioned files, which is also its strength. The whole desired state of your system lives in Git, reviewable and repeatable. Tools like Helm reduce the repetition once you need them, but start by writing plain manifests so you understand what they generate.
You now understand the system that runs containers at scale, and just as importantly, when to reach for it. Next up is Part 10 on Infrastructure as Code with Terraform, where you create the servers and networks themselves from files instead of clicking through a console.
New here? Start with Part 8 on Docker, which Kubernetes builds on, and Part 3 on the toolchain map. The Cloud for Beginners series pairs well for where clusters run.
References
Kubernetes concepts overview
Kubernetes Deployments
Kubernetes: Debug running pods
About The Author
DrJha