Day 1 - Kubernetes Without The Tears

Under The Hood

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 - managing everything across multiple airports.

    * The cluster is the entire airport - a complete, self-contained environment.

    * The control plane is the air traffic control tower - coordinating all operations but not directly handling planes.

    * Nodes are like terminals or concourses - each hosts multiple airplanes (pods) simultaneously, providing them with power, connectivity, and other resources.

    * The kubelet is the ground crew at each terminal, making sure planes are where they're supposed to be, handling their needs, and reporting back to the tower.

    * Pods are like airplanes - they carry the containers and ensure they're treated as one unit.

    * Containers are like the cargo or service modules within an airplane - they do the actual work (running your app).

    * Services are like the airport's passenger routing system - directing traffic to the right planes regardless of which gate they're at.

    * Deployments are like flight schedules - ensuring the right number of identical planes are operating at all times.

    * ConfigMaps/Secrets are like flight plans and security clearances - providing necessary configuration and sensitive information.

    * Persistent Volumes are like airport storage facilities - providing persistent storage that exists independently of any particular plane.

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.

So, enough chit chat. Let’s install K8s locally and spin up our first cluster.

Lab

Since you can’t have container orchestration without containers, we are going to use Docker. Hopefully, you already installed Docker as explained in the Docker article which you can find here:

We’ll use Docker, kubectl, and either kind or minikube. Here's what each one does, so you know what you're dealing with:

• Docker: This is the container engine. It runs the containers and is required by both kind and minikube under the hood. Hopefully, by this time, we are familiar with it and comfortable with what it does.

• kubectl: This is your command-line tool to talk to the cluster. Think of it as your remote control.

• kind (Kubernetes IN Docker): Spins up a full K8s cluster inside Docker containers. It's fast, lightweight, and great for scripting or automation. Recommended if you like minimal fuss and CLI-driven setups.

  💥 Mind blown — Kubernetes running inside Docker? It sounds odd at first, but here's what's happening: kind uses Docker containers to simulate actual machines (nodes). Then, it installs Kubernetes inside those containers to act like a mini cluster. So yes, you're running Kubernetes inside Docker, which then runs other containers. It's like container-ception—but it works great for local testing. And you thought Quantum Computing was weird.
• minikube: Spins up a single-node K8s cluster with some bells and whistles—like the Kubernetes Dashboard. Great if you prefer visuals or want a more complete local experience.

Having said all that, let’s do this step by step.

1. Install Docker if you have not already. For Windows, you need Docker Desktop - https://www.docker.com/products/docker-desktop/. Make sure that it is running and do not worry about running the Hub - we will get by without it for now.

2. You’re done. Docker Desktop includes Docker (yeah I know it is obvious but still), kubectl and a built-in single-node K8s cluster.

All you need to do now is to open Docker Desktop, and go to Settings → Kubernetes, enable K8s and let it install.

Once it is installed and Docker Desktop restarts, when you visit the same section and you should see that the cluster is running… but that doesn’t exactly scream “wow”.

Let’s do something about it.

Try this in your terminal.

kubectl get nodes
kubectl get pods --all-namespaces

and you will see your cluster’s node and all the system pods already running under the hood. OK, maybe it’s not flashy but it is real.

You want something more visual? Let’s see if we can get Kubernetes Dashboard going. It does not come with Docker Desktop, so let’s try to get there another way. Enter this command in your terminal:

kubectl proxy

Then go to this address in your browser:

http://localhost:8001/api/v1/namespaces/kubernetes-dashboard/services/https:kubernetes-dashboard:/proxy/

Chances are you won’t have the dashboard installed and you will get this message:

{
  "kind": "Status",
  "apiVersion": "v1",
  "metadata": {

  },
  "status": "Failure",
  "message": "services \"kubernetes-dashboard\" not found",
  "reason": "NotFound",
  "details": {
    "name": "kubernetes-dashboard",
    "kind": "services"
  },
  "code": 404
}

Which means I do not have the K8s Dashboard installed. So let’s correct that. Install it by running this command:

kubectl apply -f https://raw.githubusercontent.com/kubernetes/dashboard/v2.7.0/aio/deploy/recommended.yaml

Then, create a service account with cluster-admin rights so you can log in:

kubectl create serviceaccount dashboard-admin -n kubernetes-dashboard
kubectl create clusterrolebinding dashboard-admin --clusterrole=cluster-admin --serviceaccount=kubernetes-dashboard:dashboard-admin

Now start the proxy again:

kubectl proxy

And open this URL again in your browser:

http://localhost:8001/api/v1/namespaces/kubernetes-dashboard/services/https:kubernetes-dashboard:/proxy/

You should be prompted for a token. Grab it with:

kubectl -n kubernetes-dashboard create token dashboard-admin

Copy and paste that token in, and boom—dashboard access!

Now you can actually see what’s going on in your cluster. You’ve got visual proof that your cluster is alive and well.

We’ll do more tomorrow—but this is your first look behind the curtain. Your cluster is alive and well.

Pretty cool, huh?

What’s Next

That’s it for Day 1. We’ve got Kubernetes running locally, and more importantly, we actually know what it’s doing.

Tomorrow, we’ll start deploying real workloads and see pods, deployments, and services in action.

Good job. We’ve cleared the runway and ready to take off.