This is an old revision of the document!
Learning Kubernetes: Why, What, and How — a guide to real understanding, not just memorized commands.
This script walks through three big questions. Why does Kubernetes exist? What are its core ideas? And how do you actually learn it hands-on?
Let's start with why.
Before Kubernetes, applications ran on a handful of big servers. If you needed more power, you bought bigger hardware. Then virtualization came along, letting one machine pretend to be many. But virtual machines are heavy, since each one carries a full operating system.
Around 2013, containers—popularized by Docker—made things lighter. A container packages an application together with everything it needs, so it runs the same way everywhere.
But containers alone don't solve everything. If a container crashes, who restarts it? If traffic spikes, who creates more copies, and who removes them later? If a server dies, who moves the containers somewhere else? How do hundreds of containers find each other and talk to each other? How do you roll out a new version without downtime? And how do you manage secrets and configuration consistently across many machines?
Doing all of this by hand doesn't scale. You need a system that treats a whole cluster of machines as one programmable unit, and constantly works to keep your application running the way you want.
That's where Kubernetes comes in, and it has a few defining strengths. First, it's declarative. You describe the end result you want—say, three copies of an app running—and Kubernetes figures out how to make that happen, continuously. Second, it's self-healing: it detects failures and fixes them automatically. Third, it's portable, running the same way on Amazon, Google, Microsoft's cloud, your own servers, or even your laptop, so you're not locked into one vendor. And finally, it's become the industry standard—it actually grew out of a system Google used internally called Borg—so most modern cloud tools are built assuming Kubernetes is underneath.
Here's the core idea to hold onto: Kubernetes is an orchestrator. Containers give you the packaging. Kubernetes gives you the management of many containers, across many machines.
Now let's talk about what Kubernetes actually is—the core concepts and the theory behind them. Understanding this deeply matters far more than memorizing configuration syntax.
The single most important idea in Kubernetes is the control loop, and it works just like a thermostat. You declare a desired state—say, three copies of an application running. Kubernetes observes the actual state of the cluster. A piece of software called a controller continuously compares the desired state to the actual state. If they differ, the controller takes action to bring them back in line. And this repeats, forever.
This pattern—declare, observe, compare, correct—shows up everywhere in Kubernetes. It's not just one feature; it's the whole architectural philosophy. Once this idea clicks, most of Kubernetes' behavior becomes predictable.
Next, the cluster architecture—essentially, what actually exists inside a Kubernetes system. A cluster is a set of machines called nodes, and those nodes split into two roles.
The first role is the control plane, which you can think of as the brain. It makes global decisions but doesn't run your actual application containers. Inside the control plane, the A P I server acts as the front door—every interaction, whether from a command line tool, other software, or a dashboard, goes through it. There's also “etcd,” a distributed database that holds the entire state of the cluster—think of it as the cluster's single source of truth. Then there's the scheduler, which decides which node a new workload should run on, based on resources and constraints. And the controller manager, which runs all those control loops we just talked about—for example, making sure the right number of copies of an application actually exist.
The second role is the worker nodes, which you can think of as the muscle—this is where your application actually runs. Each worker node has an agent called the kubelet, which talks to the A P I server and makes sure the right containers are running on that node. There's also a container runtime, the software that actually runs the containers. And kube-proxy, which handles the networking so traffic reaches the right place.
Now, the object model—essentially, the vocabulary of Kubernetes. Everything in Kubernetes is described as an object, written in a simple, human-readable configuration format, and stored in that etcd database we mentioned. It helps to learn these building blocks from smallest to largest.
The smallest unit is called a Pod. It's one or more closely related containers that share networking and storage. Containers are never scheduled directly in Kubernetes—pods are the basic unit that gets scheduled.
Next is the ReplicaSet, which makes sure a certain number of copies of a pod are always running. This is a direct example of that control loop idea applied to pod count.
Above that is the Deployment, which manages ReplicaSets and handles rolling out updates and rolling them back if something goes wrong. In practice, you'll almost always use Deployments rather than working with pods directly—it's the standard way to run most applications.
Then there's the Service, which gives you a stable network address in front of a group of pods that might change over time. This matters because pods are temporary—they get replaced and get new addresses constantly. Services solve the problem of reliably reaching your application despite that constant change.
There are also Config Maps and Secrets, which store configuration and sensitive information separately from your application code. This keeps you from having to rebuild your application just to change a setting.
Namespaces let you split one cluster into virtual sub-clusters, which is useful for separating teams or environments without needing entirely separate clusters.
For storage, there are Volumes, Persistent Volumes, and Persistent Volume Claims, which let storage outlive an individual pod. Since pods are temporary, this separates “storage that exists” from “an application that needs storage.”
StatefulSets are similar to Deployments, but designed for applications that need a stable identity and stable storage—think databases or message queues—things a standard Deployment doesn't guarantee.
DaemonSets make sure a pod runs on every node, or a selected group of nodes—commonly used for things like log collection or monitoring agents that need to run everywhere.
And Ingress defines rules for routing external web traffic into your Services, giving you things like routing based on the website address or path, and handling secure connections at the edge of the cluster.
A quick note on how Kubernetes objects relate to each other: they don't reference each other with hard-coded identifiers. Instead, they use labels—simple key-value tags—and selectors, which are essentially queries over those labels. A Service doesn't say “send traffic to this specific pod.” It says “send traffic to any pod tagged as the front end.” This loose coupling is exactly why pods can be destroyed and recreated constantly without breaking anything that depends on them.
On networking, Kubernetes assumes a simple, flat model. Every pod gets its own address. Pods can talk to any other pod without complicated address translation, regardless of which node they're on. And nodes can talk to any pod. This is called the Kubernetes networking model, and it's fulfilled underneath by a plug-in system called the Container Network Interface. You don't need to master the internals of that early on, but knowing this model exists explains why networking and name resolution just work across the cluster.
Now, let's get into how you actually learn Kubernetes hands-on. Theory only sticks when you pair it with practice, so here's a suggested path.
Before diving in, make sure you're comfortable with a few prerequisites: using the Linux command line, the basics of Docker—things like images, containers, and building them—basic configuration file syntax, and basic networking concepts like addresses, name resolution, and ports.
Once you're ready, set up a small local cluster rather than jumping straight to the cloud—this removes billing concerns and extra complexity while you're learning. Tools like Minikube or Kind, which runs Kubernetes inside Docker, both let you run a real cluster right on your laptop. You'll also want to install the command-line tool used to talk to the cluster's A P I server.
From there, work through hands-on exercises in order. Start by running a single pod directly from the command line, then inspect it to see its details and logs. Next, write a pod configuration file by hand, apply it, and then delete and recreate it to see the lifecycle in action. After that, create a Deployment, scale it up and down, and try manually killing a pod—you'll actually watch it get recreated automatically, which is where the control loop idea becomes real and visible. Then expose that Deployment through a Service, first internally and then externally, and notice why pod addresses alone weren't enough. Add a Config Map and a Secret, and mount them into a pod both as environment variables and as files. Try a rolling update by changing the application version, and then practice rolling it back. Add persistent storage to a pod and observe what happens to the data when the pod is deleted versus when the storage itself is deleted. Set up an entry point for external web traffic and route it based on the website address or path. Explore resource limits, and see what happens when an application exceeds them. And finally, look at a StatefulSet example, like a small database, to see stable naming and storage in action.
As you get comfortable, build up your day-to-day operational skills: the common commands for viewing resources, describing them, checking logs, executing commands inside containers, and forwarding ports for local testing. Learn to read cluster events to debug scheduling or crash issues. And understand the lifecycle a pod goes through—from pending, to running, to either succeeding or failing—along with the health checks Kubernetes uses to know if an application is alive and ready.
Once the basics are solid, you can move into more advanced territory. Helm acts like a package manager for Kubernetes, letting you template and package configurations. The Horizontal Pod Autoscaler automatically scales your application based on metrics—another example of that same control loop pattern. Role-based access control manages who can do what within the cluster. Observability tools help you monitor metrics and centralize logging. And a practice called GitOps applies the control loop idea to deployment itself, using a code repository as the source of truth for what should be running. Eventually, you'll want to try a managed cloud cluster, once the local concepts feel solid, to see how cloud features like load balancers and storage plug into the same object model.
Here's a mental model worth reinforcing every time you learn something new in Kubernetes. Ask yourself three questions. What desired state am I declaring? What actual state is being observed and compared against it? And what controller is reconciling the difference between them? If you can answer those three questions for Deployments, Services, storage claims, and autoscalers, you understand Kubernetes' actual design, not just its surface-level commands. Almost every advanced feature you'll encounter later is really just this same control loop pattern, applied to a new kind of desired state.
To sum it all up: the “why” is that containers alone can't reliably manage a distributed system. The “what” is the set of building blocks—pods, Deployments, Services, and the rest—along with the underlying theory of control loops and loose coupling. And the “how” is the practical path of running, exposing, configuring, and operating an application on a real cluster. Keep coming back to those three questions as you go deeper. It's easy to get lost in the details and lose sight of the “why” underneath it all.
A few notes on this conversion: the original document included two reference tables and used visual arrows, like “Pending, arrow, Running, arrow, Succeeded or Failed” — I've converted these into spoken sequences using “to” instead of arrows. Specific command-line syntax and exact flags were described in plain language rather than spoken character-by-character, since reciting punctuation-heavy commands aloud would be confusing to a listener; if you need the exact commands, they're best delivered as an accompanying visual or written handout rather than narration.