Kubernetes (k8s) is the most powerful container orchestration platform and the most over-recommended technology in web hosting. Most small projects do not need it. But understanding what it does — and when it becomes useful — is valuable even if you never run it in production.
What Kubernetes actually does
In one sentence: Kubernetes schedules containers across multiple servers and keeps them running.
Beyond that:
- Self-healing: if a container dies, k8s restarts it. If a node dies, k8s moves the workload.
- Service discovery: containers find each other by name, not IP address
- Load balancing: traffic distributes across all instances of a service
- Rolling updates: deploy new versions without downtime, roll back if broken
- Secret management: store passwords, API keys, TLS certs securely
- Resource management: CPU and memory limits enforced at the cluster level
The complexity tax
Kubernetes is not a tool you learn in an afternoon. The learning curve is steep:
- Concepts: Pods, Deployments, Services, Ingresses, ConfigMaps, Secrets, PersistentVolumes, StatefulSets, and 30+ more resource types
- Networking: CNI plugins (Calico, Cilium, Flannel), each with different capabilities
- Storage: CSI drivers, persistent volume claims, storage classes
- Security: RBAC, Pod Security Standards, network policies, image scanning
- Observability: Prometheus, Grafana, Loki, traces — all need to be set up
For a single-server WordPress site: Docker Compose is simpler, faster to set up, and easier to debug. You gain nothing from Kubernetes on a single node.
When Kubernetes makes sense
Kubernetes is worth it when:
- You run 3+ servers and need to schedule workloads across them
- You need zero-downtime deployments with automated rollbacks
- Your team has 5+ services that need to discover each other
- You are building a platform that other teams deploy to
- You need horizontal autoscaling (add more instances during traffic spikes)
It is not worth it for:
- A single WordPress site
- A hobby project that fits on one server
- Any project where you are the only developer and only operator
Learning Kubernetes: the minimal path
Start with a single-node cluster on your laptop:
# Install k3s — a lightweight k8s distribution
curl -sfL https://get.k3s.io | sh -
# Check it's running
sudo k3s kubectl get nodes
# Create your first deployment
cat << 'EOF' | sudo k3s kubectl apply -f -
apiVersion: apps/v1
kind: Deployment
metadata:
name: hello-world
spec:
replicas: 2
selector:
matchLabels:
app: hello
template:
metadata:
labels:
app: hello
spec:
containers:
- name: hello
image: nginx:alpine
ports:
- containerPort: 80
EOFk3s is a certified Kubernetes distribution that strips out cloud-provider integrations and runs well on a single node with 1 GB RAM. It is the best way to learn k8s without managing a full cluster.
Key concepts explained simply
Pod
The smallest deployable unit. A Pod is one or more containers that share a network namespace and storage. Think of it as a “logical host” for your app.
apiVersion: v1
kind: Pod
metadata:
name: my-app
spec:
containers:
- name: app
image: my-app:latest
ports:
- containerPort: 3000Deployment
Manages Pods. Declares “I want 3 copies of this Pod running at all times.” Handles rolling updates and rollbacks.
apiVersion: apps/v1
kind: Deployment
metadata:
name: my-app
spec:
replicas: 3
selector:
matchLabels:
app: my-app
template:
metadata:
labels:
app: my-app
spec:
containers:
- name: app
image: my-app:1.2.3Service
Gives a stable network identity to a set of Pods. Pods come and go (and change IPs), but a Service stays at one IP/DNS name.
apiVersion: v1
kind: Service
metadata:
name: my-app
spec:
selector:
app: my-app
ports:
- port: 80
targetPort: 3000Ingress
Routes external HTTP traffic to Services. Think of it as a reverse proxy configuration:
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
name: my-app
spec:
rules:
- host: app.example.com
http:
paths:
- path: /
pathType: Prefix
backend:
service:
name: my-app
port:
number: 80Helm: the package manager
Helm is to Kubernetes what apt is to Debian. It packages k8s manifests into “charts”:
# Install Helm
curl https://raw.githubusercontent.com/helm/helm/main/scripts/get-helm-3 | bash
# Add a chart repository
helm repo add bitnami https://charts.bitnami.com/bitnami
# Install WordPress (as an example)
helm install my-blog bitnami/wordpressHelm charts handle the tedious parts — connecting the database, setting up persistent storage, configuring ingress. But you are still running Kubernetes underneath, with all the complexity that implies.
The realistic timeline
| Week | What you learn |
|---|---|
| 1-2 | Pods, Deployments, Services — get an app running |
| 3-4 | ConfigMaps, Secrets, Ingress — configuration and routing |
| 5-6 | PersistentVolumes, StatefulSets — stateful workloads |
| 7-8 | Helm, monitoring, logging — production readiness |
| 9+ | RBAC, network policies, operators — advanced operations |
Count on 2-3 months of part-time learning before you are comfortable running production workloads. This is not a weekend project.
Alternatives to Kubernetes
If you need “containers on multiple servers” without k8s complexity:
- Docker Swarm: Built into Docker. Simpler, fewer features. Dead-end in terms of ecosystem, but works for basic orchestration.
- Nomad: HashiCorp’s orchestrator. Simpler than k8s, integrates with Consul and Vault. Good for mixed workloads (containers + binaries).
- CapRover / Dokku: Single-server PaaS. Git push to deploy. Great for personal projects.
- Coolify: Self-hosted Vercel/Netlify alternative. Manages deployment without requiring k8s knowledge.
When to learn Kubernetes
Learn Kubernetes when:
- You are looking for a job in DevOps or platform engineering
- Your project has outgrown a single server
- You want to understand the technology your cloud provider is selling you
Do not learn Kubernetes because a blog post said you should. Docker Compose and a VPS solve the same problems for 95% of small projects.