From Docker Containers to a Local Kubernetes Cluster

Imagine Docker already solved the hardest part of your day: this app runs the same way everywhere.

You build an image. You run a container. Laptop, server, cloud — same idea.

Then the next problem shows up. Not one container. Hundreds. Thousands. Some die. Some need more machines. Some need a load balancer. Some need to talk to each other across VMs.

Docker answered: how do I run a container?

Kubernetes answers: how do I manage a whole city of them?

The control panel and the worker nodes

When you deploy by hand, you pick a machine and run Docker there.

When you deploy with Kubernetes, you stop picking machines.

You write what you want in a YAML file. Kubernetes has a central control plane — think of it as the brain — and a bunch of machines it calls worker nodes. Those nodes can be physical machines or VMs.

You say, “I need this app.” The control plane decides where the containers should run, and how many, based on what is available.

That is the real shift: you declare the destination. Kubernetes chooses the road.

“I want 100 replicas”

Here is where it starts to feel intelligent.

You can tell Kubernetes: keep 100 replicas of this app alive.

It looks at the VMs it has. It packs as many as it can onto them. If it needs more capacity, it can work with the idea of scaling out. If even one replica fails, Kubernetes still knows the desired count is 100 — so it starts another one to close the gap.

Scale up. Scale down. Heal what broke. That self-healing story is why people reach for Kubernetes once containers alone are not enough.

Nodes, vCPUs, and what a cluster really is

A cluster is simply a group of nodes.

A node is a machine — physical or virtual — that can run your workloads.

Under the hood, every machine has a CPU chip with multiple cores. A VM can sit on one or more of those cores. People usually call that a vCPU when they talk about the VM’s share of compute.

kubectl is the CLI that talks to the cluster and manages it. One tool. One conversation with the whole group of nodes.

Practice like the exam will feel

If you are aiming for the CKA, remember the room you will sit in: a Linux shell, a browser for Kubernetes docs, and a clock that does not care how nervous you are. The exam is timed and tough.

So the best practice is not clicking through a pretty UI all day. It is living in the terminal.

A good habit is to make a small playground repo — call it k8-lab — and break things there on purpose until the commands feel boring.

On your laptop, tools like Docker Desktop and Rancher Desktop can spin up a local Kubernetes cluster. Since it is a playground, you can even use Reset cluster in Docker Desktop when you want a clean slate.

The file that tells kubectl who to call

Somewhere on your machine sits the central config:

~/.kube/config

That kubeconfig tells kubectl which cluster to talk to. With context commands — things like get-context and use-context — you can switch between clusters without rewriting your whole setup.

Every cluster has components behind the curtain: API server, scheduler, etcd, and more. The API server listens on the port written in that config. Different clusters, different API servers, different ports — same kubectl, different destinations.

Namespaces: folders inside the cluster

Inside a cluster, namespaces work a lot like folders.

Kubernetes itself often lives in kube-system. Your experiments usually land in default.

A popular practice is to split environments — staging, production, and so on — into different namespaces. Deploy to one without accidentally poking the other.

Pods: richer than a container

Docker runs a container.

Kubernetes runs a pod.

A pod wraps one or more containers and brings extras along — especially networking and storage. That is why Kubernetes feels “richer” than Docker alone. The container is still there. The pod is the unit Kubernetes schedules and manages.

Most of the time a pod has a single container. Sometimes it has multiple. Sometimes it has an init container that runs first — a short health-check or setup guest that finishes before the main containers start.

Want to put an nginx image into a pod quickly?

kubectl run nginx1 --image=nginx

Want more detail, including the pod’s IP?

kubectl get pods -o wide

That wide view is a reminder: a pod is not only a process. It has an address on the cluster network.

Where this chapter leaves you

Docker made the container portable.

Kubernetes made a fleet of containers manageable — with a control plane, worker nodes, desired replica counts, namespaces, and pods that carry networking and storage with them.

On your laptop, Rancher Desktop or Docker Desktop can give you a local cluster. In ~/.kube/config, you choose which cluster kubectl should trust. In a repo like k8-lab, you practice until the terminal feels like home — because that is closer to how the CKA will feel when the timer starts.