Kubernetes Without The Tears — A 7-Day Developer Journey

You’ve probably heard the name thrown around like it’s some mythical creature—“Kubernetes will scale your app,” “Kubernetes is the future,” “Kubernetes ate my weekend.” And yeah, it can be magical… but also a bit intimidating.

Instead of Kubernetes, you may have come across its other name, K8s. Sounds more like a summit you need to conquer than a technical term, it is short for Kubernetes. Actually come to think of it, it does sound right that it is a summit that you need to conquer.

Truth is, if you’re a developer who's just trying to get their containerized app running without getting buried under layers of YAML, kubelets, and head-scratching terminology, you’re in the right place. Kubernetes is a platform for managing containerized apps at scale - it is an orchestrator. Its core unit is called the Pod (sounds like a character out of a Star Wars movie but actually it is a wrapper around one or more containers).

This series is for developers. Not for infra people, not for people trying to run 18 clusters across 4 continents (mad respect to them), but for folks like you and me who just want to understand what’s going on, try it locally, and maybe even use it in real life without having to do a masters degree on DevOps.

What This Series Is

The way this series is designed is as a 7-day crash course in Kubernetes.

Here is how the content is split for each day:

• Knowledge
  Concepts and theory. In plain English. We’ll keep it light. No overexplaining. We’ll learn just enough to know what is going on under the hood without making your brain melt. Although, if you feel like watching a one hour video on any of the topics, who am I to stop you.

• Lab
  This is where we run stuff. We’ll spin up clusters, deploy pods, scale apps, and feel cool doing it. It’s like building Lego, but for containers. If you don’t know what any of that means, do not worry. We will get to that and will repeat them enough times that they feel like second nature.

No fluff. just enough to be dangerous.

Prerequisites

Unfortunately, Kubernetes is not for the complete newbie. You need to be comfortable with some stuff such as:

• Containers (basic Docker knowledge is enough - but I’ve got you covered here: https://tjgokken.com/docker-basics)

• Command line (you can cd and ls your way around)

• YAML (if you’ve written a GitHub Actions file, you're golden)

We’ll be using:

• kubectl for talking to the cluster

• kind or minikube for running Kubernetes locally

• A terminal and your favorite text editor (yes, even Notepad++ works, we’re not judging, but I will be using Visual Studio Code)

What We’ll Build

Along the way, we’ll actually build something real. Not a “Hello World” pod, but a small app stack you can use.

We’ll cover:

• Pods, Deployments, and Services

• ConfigMaps and Secrets

• Probes and scaling

• RBAC and Helm

• Ingress and load balancing

And we’ll cap it off with a mini project that pulls it all together.

Can I Break Stuff?

Yes. You should. That’s the beauty of running everything locally—you can mess it up, delete the cluster, and spin up a new one faster than you can say “kubectl apply -f”.

Kickoff

We kind of talked about this, but let’s recap anyway.

Kubernetes—or K8s if you want to sound cool—sounds like a summit to be conquered. In a way it is, but in real life, it's actually a container orchestrator.

It means Kubernetes helps you handle multiple containers smoothly—making sure your apps are alive, kicking, and happy even if something tries to kill them (usually, our own bad code, aka bugs, aka features).

So, let’s go over some basic concepts again to refreshen our memory:

• Containers vs VMs: Containers are like lightweight virtual machines but quicker to spin up and easier to manage.

• What exactly is Kubernetes?: Think of Kubernetes as the genie in Aladdin for your containers - you never had a friend like it as it hires, fires, and even brings containers back from the dead.

• Why Kubernetes?: Because manual scaling, updates, and restarts suck and take a very long time.

• Basic K8s Architecture: Nodes, Pods, and something called a "Control Plane" (sounds scarier than it is).

• What Kubernetes Isn’t: A silver bullet. Or a JavaScript framework. It also is not MS Aspire - the only common property they share is orchestration and that’s about it.

Let’s break down what Kubernetes is, what it does, and why developers like us should care. We’ll unpack some core concepts—like clusters, nodes, and pods—without turning this into a sysadmin lecture.

Kubernetes Concepts

Let’s start with the basics. You’ve probably heard about containers and maybe even played around with Docker - certainly hope that you at least skimmed through the pre-requisite article for this course.

First, we have containers and these are lightweight, portable environments that package your app and everything it needs to run. They’re like tiny, disposable apartments for your code.

Now, imagine you have dozens—or hundreds—of these containers. Who’s going to manage them? Restart them when they crash? Scale them when traffic spikes? That’s where Kubernetes comes in.

Kubernetes is like an aviation system with an airport and a very very smart control tower.

You have planes constantly taking off, landing, or sitting at the gate. Kubernetes makes sure none of them crash, collide, or sit idle for too long. It is the whole system which handles scheduling, recovery, scaling, and routing—all so your app traffic doesn’t end up in a fiery mess on the tarmac. It schedules, heals, balances, and exposes your apps—all without you having to SSH into every machine like it’s 2009 or 1995 (they year when the first version of SSH (Secure Shell) appeared) .

A Kubernetes setup is called a cluster. Even if it’s just running on your laptop, Kubernetes still calls it a cluster because it sees everything in terms of coordination. The cluster has two key roles: the control plane (aka the boss) and the nodes (aka the workers). The control plane makes decisions. The nodes run your containers.

Inside those nodes are pods—which are like wrappers for your containers. But they’re more than just packaging.

Here’s how it works: nodes run pods, and pods run containers. A pod can have one container (most common) or sometimes a few if they absolutely need to share resources like storage or networking.

Think of a pod like a little life-support system. It keeps your container (or containers) alive, gives them their own network identity, and ensures they behave as a unit. Kubernetes doesn’t manage containers directly—it manages pods. That’s why this middle layer exists.

You’ll hear the term “pod” a lot, so it’s worth remembering: when something goes wrong or scales up in Kubernetes, it’s usually the pod doing the dance—not the raw container.

And no, the pod is not a Star Wars term but it still sounds cool.

On top of all that, keeping each node in check is something called a kubelet. Think of the kubelet as the local supervisor on every node. It talks to the control plane and says, "Hey, I’ve got the stuff you told me to run. It’s working. Or... actually no, something exploded." The kubelet makes sure the containers that should be running on that machine are actually running—and it reports back regularly.

I know I gave you a whole lot of terminology in a very short time, but keeping our airport analogy, this is how it all fits in:

• Kubernetes is the whole aviation system.

• The cluster is the entire airport.

• The control plane is the air traffic control tower.

• Nodes are the gates at the airport—they host the airplanes (pods), give them power and connectivity, and handle multiple at once.

• The kubelet is the ground crew at each gate, making sure the planes are where they’re supposed to be and reporting back to the tower.

• Pods are like the airplane—they carry the engines (containers), and make sure they’re treated as one unit.

• Containers are like airplane engines—they do the actual work (running your app).

At this point you may be wondering if all this effort really is worth it? But consider this: imagine trying to deploy a dozen microservices, across several machines, each with slightly different configs. One update breaks another. You try fixing it and end up breaking something else. We've all been there.

Kubernetes fixes that with built-in features like rolling updates, health checks, self-healing containers, and even autoscaling. When it works, it’s magic. When it doesn’t, well… Let’s hope this series can help.

Today’s Takeaway

Kubernetes is powerful, structured around clusters, pods, and control planes, and it exists to take the chaos out of managing containers. You don’t need to know everything today—but now you’ve got the basics. I personally like the airport analogy and I hope it helps you build a nice mental model too.

What’s Next

We’ll install Kubernetes locally using either kind or minikube and spin up our very first cluster. Nothing fancy - just enough to get things running so we can start messing with real deployments.

Oh, and a little footnote: I use Windows so everything I’ll be talking about is done in Windows.

Appendix: Where Does The Name Kubernetes Come From?

The name Kubernetes originates from the Ancient Greek word kubernḗtēs, meaning “helmsman” or “pilot” referring to its role in steering application containers.

So, where does the shorthand of K8s come from?

Just take a look at the word Kubernetes, and count the letters between K and s. Yup, there you go.