Kubernetes (K8s) is a system that manages containers at scale. If Docker is a way to package and run one container, Kubernetes is a way to run hundreds or thousands of containers across multiple servers — and keep them all healthy.

When you need Kubernetes

You don’t need Kubernetes for a blog or a small app. You need it when:

• You have multiple services that need to talk to each other
• You need to handle traffic spikes (auto-scaling)
• You need zero-downtime deployments
• You’re running on multiple servers and need to distribute workload
• You need self-healing (if a container crashes, restart it automatically)

If you’re running one app on one server, Docker Compose is enough. Kubernetes is for when things get bigger.

The core idea

Without Kubernetes:

• You SSH into servers and manually start containers
• If a container crashes, you notice (maybe) and restart it manually
• If traffic spikes, you manually add more containers
• Deploying a new version means stopping the old one and starting the new one (downtime)

With Kubernetes:

• You tell Kubernetes “I want 3 copies of my app running”
• Kubernetes figures out which servers to put them on
• If one crashes, Kubernetes restarts it automatically
• If traffic spikes, Kubernetes adds more copies
• Deploying means Kubernetes gradually replaces old containers with new ones (zero downtime)

Key concepts

Cluster — a set of machines (nodes) that Kubernetes manages.

Node — a single machine in the cluster. Can be a physical server or a VM.

Pod — the smallest unit in Kubernetes. Usually one container, sometimes a few tightly coupled containers.

Deployment — tells Kubernetes “run 3 copies of this container image.” Handles updates and rollbacks.

Service — a stable network address for a set of pods. Pods come and go, but the service address stays the same.

Namespace — a way to organize resources (like folders). Common: default, staging, production.

A simple example

# deployment.yaml
apiVersion: apps/v1
kind: Deployment
metadata:
  name: web-app
spec:
  replicas: 3
  selector:
    matchLabels:
      app: web
  template:
    metadata:
      labels:
        app: web
    spec:
      containers:
        - name: web
          image: my-app:1.0
          ports:
            - containerPort: 3000
---
apiVersion: v1
kind: Service
metadata:
  name: web-service
spec:
  selector:
    app: web
  ports:
    - port: 80
      targetPort: 3000
  type: LoadBalancer

kubectl apply -f deployment.yaml

This tells Kubernetes: “Run 3 copies of my-app:1.0, expose them on port 80, and load-balance traffic between them.”

What happens when things go wrong

Event	What Kubernetes does
Container crashes	Restarts it automatically
Node goes down	Moves pods to healthy nodes
Traffic spike	Scales up (if autoscaler is configured)
New version deployed	Gradually replaces old pods (rolling update)
New version is broken	Rolls back to the previous version

This self-healing is the main reason companies use Kubernetes.

Kubernetes vs. alternatives

Tool	Best for
Docker Compose	Single server, small projects
Kubernetes	Multi-server, production at scale
Docker Swarm	Simpler alternative to K8s (less popular)
AWS ECS	AWS-native container orchestration
Cloud Run / Fargate	Serverless containers (no cluster to manage)

If you’re just starting out, consider Cloud Run (Google), Fargate (AWS), or Azure Container Apps. They give you most of Kubernetes’ benefits without the complexity.

Managed Kubernetes

Running Kubernetes yourself is complex. Most teams use a managed service:

• EKS — Amazon Elastic Kubernetes Service
• GKE — Google Kubernetes Engine
• AKS — Azure Kubernetes Service

These handle the control plane (the Kubernetes brain) for you. You just manage your apps.

Common kubectl commands

kubectl get pods                    # List pods
kubectl get deployments             # List deployments
kubectl logs my-pod                 # View logs
kubectl exec -it my-pod -- bash     # Shell into a pod
kubectl apply -f deployment.yaml    # Deploy
kubectl scale deployment web --replicas=5  # Scale
kubectl rollout undo deployment web # Rollback

Full list: Kubernetes/kubectl cheat sheet

Do you need Kubernetes?

Probably yes if:

• You have 5+ microservices
• You need auto-scaling
• You need zero-downtime deployments
• Your team has DevOps experience

Probably no if:

• You have 1-2 services
• You’re a small team
• You don’t have dedicated DevOps
• A PaaS (Vercel, Railway, Render) would work fine

Kubernetes is powerful but complex. Don’t use it just because big companies do. Use it when you actually need what it offers.