Why Kubernetes: from Docker to orchestration
The problems that arise when you run containers at scale — and how Kubernetes solves them
Written by the RadarTrek editorial team · June 2026
Docker solves the "works on my machine" problem by packaging your app and its dependencies into a container. But Docker alone does not answer the harder questions: what happens when that container crashes at 3 am? How do you run ten copies of it across three machines and route traffic to all of them? How do you update your app with zero downtime? These are orchestration problems — and Kubernetes is the answer the industry converged on.
The problems with running containers manually
- No self-healing — If a container crashes, nothing automatically restarts it. You either notice or your users do.
- No scaling — To handle traffic spikes you manually start more containers on more machines and update your load balancer.
- No rolling updates — Updating your app means stopping the old container and starting the new one — causing downtime.
- No service discovery — Containers have dynamic IP addresses. Other services have to hard-code where to reach them.
- No resource management — Without limits, one misbehaving container can starve every other process on the machine.
What an orchestrator does
Kubernetes is an air traffic controller for containers
Pilots do not decide which runway to land on, how to sequence arrivals, or what to do if a runway closes — the control tower manages all of that. Kubernetes is the control tower for your containers. You declare the desired state ("I want 3 copies of my API, each with 512 MB RAM, always reachable on port 8080") and Kubernetes continuously works to make reality match that declaration. If a node fails, it reschedules pods elsewhere. If a pod crashes, it restarts it. If traffic drops, it scales down automatically.
Control plane vs worker nodes
- Control plane — The brain of the cluster. Runs the API server (everything talks through it), the scheduler (decides which node runs each pod), the controller manager (enforces desired state), and etcd (the cluster's source-of-truth key-value store).
- Worker nodes — The machines that actually run your containers. Each node runs a kubelet (agent that talks to the control plane), kube-proxy (manages networking rules), and a container runtime (containerd).
- kubectl — Your command-line tool. It talks to the API server and is how you inspect, create, update, and delete every resource in the cluster.
Managed Kubernetes: GKE, EKS, AKS
Running your own control plane is complex. Every major cloud provider offers managed Kubernetes where they operate the control plane for you — you pay for worker nodes and the provider handles upgrades, HA, and backups.
- GKE (Google Kubernetes Engine) — Google invented Kubernetes; GKE is the most mature managed offering. Autopilot mode removes even node management.
- EKS (Amazon Elastic Kubernetes Service) — Deep AWS integration. If your stack is already on AWS (RDS, S3, IAM), EKS is the natural choice.
- AKS (Azure Kubernetes Service) — Microsoft's offering. Strong choice for teams already in the Microsoft/GitHub ecosystem.
Start with a managed cluster
For learning, use a local cluster (kind or minikube) or a cloud provider's free tier. Do not self-host a control plane until you need to. The concepts and kubectl commands are identical regardless of where the cluster runs.
Try this
Install kubectl and kind (Kubernetes in Docker). Run `kind create cluster`. Then run `kubectl cluster-info` and `kubectl get nodes`. You now have a fully working Kubernetes cluster running on your laptop inside Docker containers.