What Is Kubernetes? Container Orchestration Explained
Learn what Kubernetes is and why it exists. Understand container orchestration, the problems K8s solves, core concepts, and how Kubernetes differs from Docker Compose.

Docker gives you a great way to package and run individual containers. Docker Compose lets you define multi-container applications on a single machine. But what happens when your application grows beyond one server? When you need zero-downtime deployments, automatic failover, and the ability to handle ten times the traffic at peak hours?
That's the problem Kubernetes was built to solve.
The Problem Kubernetes Solves
Imagine you're running a production API across five servers. With plain Docker, you'd need to manually docker run the right containers on each server, monitor which containers are healthy, restart crashed containers by hand, manually distribute new versions across all servers, figure out load balancing yourself, and scale up and down servers and containers manually during traffic spikes.
This is the "container management" problem. It scales badly. At two servers it's annoying; at twenty it's untenable; at two hundred it's impossible. Kubernetes automates all of it.
What Kubernetes Actually Does
Kubernetes (often abbreviated K8s) is a container orchestration platform. Given a set of desired states ("I want 3 replicas of my API running at all times, on port 80, with these environment variables"), Kubernetes:
- Finds available nodes (servers) to run containers on
- Starts the containers
- Monitors their health continuously
- Restarts failed containers automatically
- Redistributes containers when a node fails
- Scales the number of replicas up or down based on demand or manual instruction
- Rolls out new versions with zero downtime
- Rolls back to the previous version if something goes wrong
You tell Kubernetes what you want. It figures out how to make it happen.
Core Kubernetes Concepts
Node
A node is a worker machine — a physical or virtual server that runs containers. A Kubernetes cluster consists of multiple nodes.
Cluster
A cluster is the collection of nodes managed together by Kubernetes. It includes a control plane and one or more worker nodes.
Pod
A Pod is the smallest deployable unit in Kubernetes. A Pod wraps one or more containers that share the same network namespace (same IP address and port space) and the same storage volumes. Most Pods contain a single container. Pods are ephemeral — they can be created, killed, and replaced at any time.
Deployment
A Deployment manages a set of identical Pods. You tell it "I want 3 replicas of this Pod" and it creates and maintains exactly 3. If one crashes, it creates a replacement. If you update the container image, it rolls out the new version gradually.
Service
A Service is a stable network endpoint for a group of Pods. Since Pods come and go, their IP addresses change. A Service provides a consistent DNS name and IP that routes traffic to healthy Pods behind the scenes.
Namespace
A Namespace partitions a cluster into virtual sub-clusters. Common practice: development, staging, production namespaces in the same physical cluster, with different access controls for each.
ConfigMap and Secret
ConfigMap stores non-sensitive configuration as key-value pairs. Secret stores sensitive data (passwords, API keys) encoded as base64. Both are injected into Pods as environment variables or mounted as files.
Kubernetes vs Docker Compose
| Aspect | Docker Compose | Kubernetes |
|---|---|---|
| Scale | Single machine | Multiple nodes / clusters |
| Self-healing | No | Yes — restarts failed containers |
| Load balancing | Manual / basic | Built-in via Services |
| Rolling deployments | No | Yes — zero-downtime by default |
| Auto-scaling | No | Yes — HorizontalPodAutoscaler |
| Service discovery | DNS by service name | DNS by Service name |
| Configuration management | .env files | ConfigMaps + Secrets |
| Health checks | healthcheck | Liveness + readiness probes |
| Learning curve | Low | Moderate to high |
| Use case | Local dev, small single-server deployments | Production, multi-server, scale |
Kubernetes Architecture Overview
Kubernetes has two main components:
Control Plane
The "brain" of the cluster. Runs on dedicated nodes and manages the overall cluster state:
- API Server — the front door for all Kubernetes operations.
kubectlcommands talk to the API server - etcd — a distributed key-value store. The single source of truth for cluster state
- Scheduler — decides which node each new Pod runs on
- Controller Manager — runs controllers that watch for desired state vs actual state and reconcile them
Worker Nodes
The machines that run your application containers:
- kubelet — an agent on each node that talks to the control plane and manages Pods
- kube-proxy — maintains network rules on each node for Service routing
- Container Runtime — the engine that runs containers (containerd, CRI-O)
┌─────────────────────────────────────────────────┐
│ Control Plane │
│ API Server │ etcd │ Scheduler │ Controller Mgr │
└────────────────────────┬────────────────────────┘
│ manages
┌────────────────┼────────────────┐
↓ ↓ ↓
┌──────────────┐ ┌──────────────┐ ┌──────────────┐
│ Worker Node │ │ Worker Node │ │ Worker Node │
│ kubelet │ │ kubelet │ │ kubelet │
│ kube-proxy │ │ kube-proxy │ │ kube-proxy │
│ [Pod][Pod] │ │ [Pod][Pod] │ │ [Pod][Pod] │
└──────────────┘ └──────────────┘ └──────────────┘Kubernetes Resources Are Declared in YAML
Instead of imperative commands, Kubernetes uses declarative configuration — you write YAML files that describe the desired state, and Kubernetes reconciles reality to match:
apiVersion: apps/v1
kind: Deployment
metadata:
name: my-api
spec:
replicas: 3
selector:
matchLabels:
app: my-api
template:
metadata:
labels:
app: my-api
spec:
containers:
- name: api
image: myregistry/myapp:1.0
ports:
- containerPort: 3000Apply this file with:
kubectl apply -f deployment.yamlKubernetes creates 3 replicas of your API. If you change replicas: 3 to replicas: 5 and re-apply, Kubernetes adds 2 more. This is the reconciliation loop at the heart of Kubernetes.
Running Kubernetes Locally
For learning and development, you don't need a cloud cluster:
Docker Desktop: Enable Kubernetes in Settings → Kubernetes → Enable Kubernetes. This adds a single-node cluster using the same Docker daemon you're already running.
minikube:
minikube start
kubectl get nodeskind (Kubernetes IN Docker):
kind create cluster
kubectl cluster-infoPrevious: Lesson 5 — Docker Compose | Next: Lesson 7 — Kubernetes Architecture
Part of the Docker & Kubernetes Mastery course.
External references:
