Kubernetes Basics

Table of Contents +

So you’ve packed your app into a container. Nice. Running one container is easy:

You learned this with Containers and Docker. One command, and your app is up.
It runs the same on your laptop, on your friend’s machine, and on a server. That’s the whole point of a container.
For a small app, one container on one machine is totally fine.

But now imagine your app gets popular:

One machine can’t handle all the traffic anymore, so you need many copies running across many machines.
Some of those copies will crash at 3am. Someone has to restart them.
Traffic goes up during the day and down at night, so you want to add and remove copies automatically.
And when a request comes in, something has to decide which copy answers it.

Doing all of that by hand, across hundreds of containers on dozens of machines, is a nightmare. That’s exactly the mess Kubernetes was built to clean up. Let’s see how.

🎯 The Problem

Picture this. You’ve got fifty containers spread across ten servers. Now think about everything someone has to keep track of:

Who starts them? When a server boots up, somebody has to launch the right containers on it, in the right numbers.
Who restarts the crashed ones? Containers die. A bug, a memory spike, a server reboot. If nobody notices, your app is just down.
Who scales them? Black Friday hits and traffic triples. You need ten more copies, fast. Then at midnight you want to shut them down so you’re not paying for idle machines.
Who routes the traffic? A user’s request shows up. Which of the fifty copies should answer it? And what happens when one of those copies just died?

Now picture doing all of this by hand, with someone watching dashboards all night:

It doesn’t scale. One tired human can’t babysit hundreds of containers.
It’s slow. By the time you notice a crash and restart it, users are already angry.
It’s error-prone. You’ll fat-finger a command and take the whole thing down.

So the real question is: what if a system could do all this watching, restarting, and scaling for you, automatically? That system is Kubernetes.

⚓ What is Kubernetes

Let’s define it plainly. Kubernetes is a container orchestration system. It automatically deploys, scales, heals, and manages your containers across a whole group of machines.

That word “orchestration” is the key, so let’s unpack it:

Orchestration just means coordinating lots of moving pieces so they work together as one. Think of a conductor in front of an orchestra, telling each section when to play.
Your containers are the musicians. Kubernetes is the conductor. It makes sure the right ones are playing, in the right numbers, at the right time.
You don’t tell it every single step. You tell it what you want the end result to look like, and it figures out how to get there and keep it that way.

Here’s the mindset shift that makes Kubernetes click:

Old way: “Start this container on that server. Now start another one over there.” You give orders, one by one.
Kubernetes way: “I want five copies of my app running at all times.” That’s it. You describe the goal.
Then Kubernetes constantly compares what’s actually running to what you asked for. If four are running, it starts one more. If six are running, it kills one. This is called the desired state idea, and it’s the heart of how Kubernetes thinks.

Why people write 'k8s'

You’ll see Kubernetes written as “k8s” all over the place. It’s just shorthand: a “k”, then 8 letters, then an “s”. Same thing, fewer keystrokes.

🧩 Core Concepts

Kubernetes has its own vocabulary, and it sounds scary at first. But each word maps to a pretty simple idea. Let’s go through them one at a time.

Cluster is the whole thing. It’s the entire set of machines that Kubernetes manages, working together as one big computer. When people say “deploy to the cluster”, they mean this whole group.
Node is one machine inside the cluster. It can be a physical server or a virtual one in the cloud. A cluster is just a bunch of nodes. The nodes are where your actual containers run.
Pod is the smallest unit Kubernetes deals with. A pod wraps one container, or sometimes a few closely-related containers that need to live together. Kubernetes doesn’t manage bare containers directly, it manages pods. Think of a pod as a thin box around your container.
Deployment is where you state your wish. A deployment tells Kubernetes how many copies of a pod you want running, and which container goes inside them. Say “I want 5 copies” and the deployment makes sure 5 are always up.
Service is a stable address for reaching your pods. Pods come and go, so their individual addresses keep changing. A service gives you one fixed front door that always points to the healthy pods behind it.

Here’s the same thing in a table you can come back to:

Concept	What it is	In plain words
Cluster	The whole set of machines Kubernetes manages	The entire system, one big computer
Node	A single machine in the cluster	One server where containers actually run
Pod	The smallest unit; wraps one or a few containers	A thin box around your container
Deployment	States how many copies of a pod to run	Your wish: “keep 5 copies alive”
Service	A stable address to reach the pods	One fixed front door to your app

Now here’s how those pieces fit together. The cluster has a brain called the control plane, which is the part that makes all the decisions. It watches the nodes, and the nodes run your pods.

Read it top to bottom. The control plane sits on top and gives the orders. The nodes underneath do the work and run the pods. And the control plane keeps watching, scaling up when needed and restarting pods that die.

⚙️ What Kubernetes Does For You

Okay, so we know the pieces. Now let’s talk about the actual magic, the stuff that makes people put up with Kubernetes in the first place. Here’s what it handles on its own.

Self-healing. A pod crashes. Kubernetes notices, because the real count dropped below your desired count, and it starts a fresh one to replace it. You can lose a pod in the middle of the night and wake up to find it already back. Nobody got paged.
Auto-scaling. Traffic spikes, so Kubernetes adds more pods to handle the load. Traffic drops, so it removes the extra ones to save money. You set the rules once, like “scale when CPU goes above 70%”, and it follows them.
Rolling updates. You ship a new version of your app. Instead of taking everything down at once, Kubernetes swaps pods out a few at a time. Old version stays up while the new one comes online, so users never see downtime. And if the new version breaks, it can roll back.
Load balancing. When requests come in, the service spreads them across all the healthy pods so no single one gets overloaded. If a pod dies, the service quietly stops sending traffic to it.
Scheduling. When a new pod needs to run, Kubernetes picks which node to put it on. It looks at which nodes have free room and places the pod where it fits. You never have to choose the machine yourself.

The pattern behind all of it

Notice the common thread. Every one of these is Kubernetes comparing “what I want” to “what’s actually happening” and fixing the gap. Self-healing, scaling, updates, all of it is the same desired-state loop running over and over.

⚖️ Is It Always Worth It

Here’s the honest truth, because Kubernetes gets a lot of hype. It is genuinely powerful, but it is also genuinely complex. So it’s not the right tool for everything.

When Kubernetes is a great fit:

You’re running many services that all need to talk to each other, like a big system split into lots of small pieces.
You’re operating at real scale, with traffic big enough that you need automatic scaling and healing.
You’ve got a team that can learn it and look after it, because it’s not a learn-it-in-an-afternoon tool.

When Kubernetes is overkill:

You’ve got a tiny app with a handful of users. A single container on one server, or a simple hosting platform, will do the job with way less headache.
You’re a solo developer shipping a side project. The time you’d spend learning Kubernetes is time you could spend building your actual product.
You don’t have scaling pains yet. If nothing is crashing and nothing is overloaded, you don’t need a system built to fix crashes and overloads.

So the rule of thumb: reach for Kubernetes when the complexity of managing containers by hand starts hurting more than the complexity of Kubernetes itself. Until then, keep it simple.

⚠️ Common Mistakes and Misconceptions

A few ideas trip up almost everyone when they start. Let’s clear them out now so they don’t stick.

“Kubernetes runs my code directly.” It doesn’t. Kubernetes runs containers, and your code lives inside those containers. So you still have to package your app into a container image first. Kubernetes just orchestrates the containers, it doesn’t run raw code.
“Every app needs Kubernetes.” Nope. Most small apps are perfectly happy without it. Kubernetes earns its keep at scale, with many services and lots of traffic. For a simple site, it’s like buying a freight truck to carry your groceries.
“A pod and a container are the same thing.” Close, but not quite. A pod is a wrapper. Usually it holds one container, so they feel identical, but a pod can hold a few containers that need to run side by side. Kubernetes manages pods, not the containers directly.
“Kubernetes builds my containers for you.” It doesn’t build images. You build the image with something like Docker, push it somewhere Kubernetes can grab it, and then Kubernetes runs it. Building and running are two separate jobs.

🛠️ Design Challenge

Try this one on your own to test yourself.

Imagine Alex runs a photo-sharing app. It usually needs 3 copies running, but every weekend traffic doubles. One Saturday, two of the running copies crash at the same time. Walk through what Kubernetes does:

How does it notice the two crashed copies, and what does it do about them?
When weekend traffic doubles, what feature kicks in, and what does it create?
When a user uploads a photo, what makes sure the request reaches a healthy copy and not a dead one?

Write down which Kubernetes feature handles each part. If you can name self-healing, auto-scaling, and the service load balancing, you’ve got the core ideas down.

🧩 What You’ve Learned

You can now explain what Kubernetes is and why it exists. Here’s what you’ve picked up.

✅ Kubernetes is a container orchestration system that runs, scales, heals, and manages containers across many machines.
✅ A cluster is the whole set of machines, a node is one machine, and a pod is the smallest unit that wraps your container.
✅ A deployment states how many copies you want, and a service gives a stable address that load-balances across the pods.
✅ The control plane is the brain that watches everything and keeps the real state matching your desired state.
✅ It self-heals crashed pods, auto-scales with traffic, does rolling updates, balances load, and schedules pods onto nodes.
✅ It’s powerful but complex, so it’s worth it at scale and overkill for a tiny app.

Check Your Knowledge

Test what you learned. Pick an answer for each question, then click Check.

🚀 What’s Next?

You now know what Kubernetes does and the words people use to talk about it. To go deeper, build on the pieces around it.

Docker Basics covers containers themselves, the things Kubernetes actually runs. Get comfortable here first.
Infrastructure as Code shows how to describe your whole setup, including Kubernetes resources, in files you can version and reuse.

Once you’ve got those, the whole cloud-native world starts to fit together in your head.

Previous Docker Basics Next Serverless Computing

Share & Connect

Share on LinkedIn