You have 10 containers running in production. One crashes at 2 AM. Another gets too much traffic and slows down. A third needs an update, but you cannot take the whole app offline.
Who restarts the crashed container? Who routes traffic away from the slow one? Who handles the update without downtime?
Kubernetes does all of that. Automatically.
This is the first article in the Kubernetes section of our Docker & Kubernetes Tutorial series. If you are new to containers, start with Docker Tutorial #1: What is Docker? first.
The Problem Kubernetes Solves
Docker is great for running containers. But running containers at scale is a different problem.
Imagine you have a web app that gets 10x more traffic on weekends. With Docker alone, you would need to:
- Manually start more containers to handle the load
- Manually distribute traffic across them
- Manually restart any container that crashes
- Manually handle rolling updates without downtime
That is not practical. And it does not scale.
Kubernetes automates all of this. It is a container orchestration platform — a system that manages the lifecycle of containers across multiple machines.
Kubernetes vs Docker
A common question: does Kubernetes replace Docker?
No. They do different things.
- Docker builds and runs containers on a single machine
- Kubernetes orchestrates containers across many machines
Most Kubernetes clusters use Docker (or another container runtime like containerd) to actually run the containers. Kubernetes sits on top and manages the bigger picture.
Docker: "Run this container on this machine"
Kubernetes: "Run 5 copies of this container, spread across 3 machines,
restart any that crash, and route traffic between them"
What is Kubernetes?
Kubernetes (often shortened to K8s — the 8 represents the 8 letters between K and s) is an open-source container orchestration system. It was originally built at Google based on their internal system called Borg, and released as open source in 2014.
Today it is the de facto standard for container orchestration. The CNCF Annual Cloud Native Survey (2025) reports that 82% of organizations running containers use Kubernetes in production.
The current stable version is Kubernetes 1.35 “Timbernetes”, released in December 2025 with 60 enhancements.
Kubernetes Architecture
A Kubernetes cluster has two types of machines: the control plane and worker nodes.
Kubernetes Cluster
├── Control Plane (the brain)
│ ├── kube-apiserver
│ ├── etcd
│ ├── kube-scheduler
│ └── kube-controller-manager
│
└── Worker Nodes (where apps run)
├── Node 1
│ ├── kubelet
│ ├── kube-proxy
│ └── container runtime (containerd)
├── Node 2
└── Node 3
The Control Plane
The control plane is the brain of the cluster. It manages the overall state of the system.
kube-apiserver
This is the front door of Kubernetes. Every command you run with kubectl goes through the API server. It validates requests and updates the cluster state.
etcd
A key-value store that holds all cluster data. Think of it as the database of Kubernetes — it stores the desired state and the actual state of every object in the cluster.
kube-scheduler
When a new Pod needs to run, the scheduler decides which worker node to place it on. It looks at available resources, constraints, and policies.
kube-controller-manager
Runs controller loops that watch the cluster state. If a Pod crashes, the ReplicaSet controller notices and starts a new one to replace it. This is how Kubernetes self-heals.
Worker Nodes
Worker nodes are the machines where your applications actually run.
kubelet
An agent that runs on every node. It communicates with the API server and ensures the containers described in Pod specs are running and healthy.
kube-proxy
Handles network routing on each node. It maintains network rules so Pods can communicate with each other and with external traffic.
Container Runtime
The software that actually runs containers. Kubernetes 1.35 uses containerd as the standard runtime (Docker’s runtime layer). Earlier versions also supported Docker directly, but that was deprecated in K8s 1.24.
Key Kubernetes Objects
Kubernetes works with declarative objects defined in YAML files. Here are the most important ones:
| Object | What it does |
|---|---|
| Pod | The smallest unit — one or more containers that share a network |
| Deployment | Manages a set of identical Pods, handles rolling updates |
| Service | Stable network endpoint for a group of Pods |
| ConfigMap | Stores non-sensitive configuration data |
| Secret | Stores sensitive data like passwords and API keys |
| Namespace | Virtual clusters for isolating resources |
| Ingress / HTTPRoute | Routes external HTTP traffic to Services |
The Declarative Model
Kubernetes uses a declarative approach. You describe the desired state, and Kubernetes figures out how to achieve it.
# You say: "I want 3 replicas of my app running at all times"
apiVersion: apps/v1
kind: Deployment
metadata:
name: myapp
spec:
replicas: 3
...
Kubernetes then continuously compares the desired state (what you declared) with the actual state (what is running). If they differ, it takes action to reconcile them.
This is different from imperative commands like “start this container now.” Declarative is more powerful because the system is always working to maintain your desired state — even after crashes, node failures, or restarts.
kubectl — The Kubernetes CLI
You interact with Kubernetes through kubectl (pronounced “kube-control” or “kube-cuddle”). It sends commands to the kube-apiserver.
# Check cluster info
kubectl cluster-info
# List all nodes
kubectl get nodes
# List all pods in all namespaces
kubectl get pods -A
# Get details about a specific pod
kubectl describe pod mypod
# Apply a YAML manifest
kubectl apply -f deployment.yaml
# Delete a resource
kubectl delete -f deployment.yaml
Why Kubernetes Wins
Kubernetes is complex. Why do organizations use it anyway?
Self-healing If a container crashes, Kubernetes restarts it automatically. If a node dies, Kubernetes reschedules the Pods on other nodes.
Horizontal scaling You can scale from 1 replica to 100 with one command — or automatically based on CPU usage.
Rolling updates Deploy a new version of your app with zero downtime. Kubernetes slowly replaces old Pods with new ones, checking health at each step.
Service discovery Pods get a stable DNS name automatically. Other services can find them by name, even as Pods are replaced.
Resource efficiency Kubernetes bins-packs containers onto nodes, using resources efficiently across your fleet.
K8s 1.35 “Timbernetes” Highlights
The December 2025 release includes 60 enhancements:
- In-place Pod Resize (GA) — resize CPU/memory without restarting containers
- VPA InPlaceOrRecreate mode (Beta) — Vertical Pod Autoscaler can use in-place resize
- AI-optimized scheduling — better scheduling for GPU/AI workloads
- ingress-nginx maintenance mode — Gateway API is now the recommended path for routing (covered in Kubernetes Tutorial #6)
When Should You Use Kubernetes?
Kubernetes is powerful, but it is also complex. It is not the right tool for every situation.
Use Kubernetes when:
- You have multiple services that need to scale independently
- You need zero-downtime deployments
- You run applications across multiple machines
- You need high availability and self-healing
Use Docker Compose instead when:
- You have a small app with 2-3 services
- You are running on a single server
- You do not need auto-scaling or self-healing
- You want simplicity over power
A good rule: if Docker Compose handles your needs, use it. If you outgrow it, Kubernetes is the next step.
Common Mistakes
Thinking Kubernetes replaces Docker
Kubernetes orchestrates containers. It still needs a container runtime (containerd, which powers Docker) to actually run them. Docker and Kubernetes work together.
Trying to learn Kubernetes before knowing Docker
Kubernetes builds directly on container concepts. If you do not understand images, containers, and Dockerfiles, Kubernetes will be very confusing. Complete the Docker tutorials first.
Using Kubernetes for a simple app
Running a single web app with a database? Docker Compose is simpler, faster to set up, and easier to maintain. Do not add Kubernetes complexity unless you need it.
What’s Next?
Now you understand what Kubernetes is and how its architecture works. The next step is to install it locally and run your first cluster.
Next: Kubernetes Tutorial #2: Installing Kubernetes Locally (minikube + kind)