Why Kubernetes Exists
Docker solved the "it works on my machine" problem by packaging applications into containers. But running containers in production at scale revealed new problems: What happens when a container crashes? How do you distribute traffic across 50 container instances? How do you update your app with zero downtime? How do you scale automatically during traffic spikes?
Kubernetes (originally built by Google, now maintained by the CNCF) is the orchestration layer that solves these problems. You describe the desired state of your system in YAML files. Kubernetes continuously works to make actual state match desired state.
Kubernetes Architecture
Control Plane Components
- API Server: The front door — all kubectl commands and internal communication go through it
- Scheduler: Decides which node to place new Pods on (based on resources, affinity, taints)
- Controller Manager: Runs controllers that watch state and reconcile (ReplicaSet controller ensures N pods are running)
- etcd: The cluster's distributed key-value store — holds all cluster state (the single source of truth)
Worker Node Components
- kubelet: Agent on each node — communicates with control plane, manages Pods on the node
- kube-proxy: Manages network rules for routing traffic to Pods
- Container runtime: containerd or CRI-O — actually runs the containers
Core Kubernetes Objects
| Object | Purpose | Manages |
|---|---|---|
| Pod | Smallest deployable unit — wraps 1+ containers | Containers directly |
| Deployment | Declarative updates for Pods — rolling deploys | ReplicaSet → Pods |
| Service | Stable network endpoint for a set of Pods | Pod networking/DNS |
| ConfigMap | Non-secret configuration data | Config files, env vars |
| Secret | Sensitive configuration (passwords, tokens) | Base64-encoded data |
| Ingress | HTTP routing rules — hostname/path to Service | External HTTP traffic |
| PersistentVolume | Storage independent of Pod lifecycle | Disk storage |
| HorizontalPodAutoscaler | Auto-scales Pods based on CPU/memory/custom metrics | Deployment replicas |
| Namespace | Logical cluster partitioning | Resource isolation |
Deployment YAML Example
Kubernetes vs Docker Compose
| Property | Docker Compose | Kubernetes |
|---|---|---|
| Scope | Single host | Multi-node cluster |
| Self-healing | No | Yes — restarts crashed containers |
| Auto-scaling | No | Yes — HPA |
| Rolling updates | Manual | Automatic with zero downtime |
| Load balancing | Basic (via ports) | Native Service + Ingress |
| High availability | No | Yes — multi-node, redundant |
| Complexity | Low | High |
| Best for | Local development | Production at scale |
Start with Docker Compose for Development
Do not try to develop locally with Kubernetes — it is too heavy. Use Docker Compose for local development. Use Kubernetes for staging and production. Helm charts and kustomize can manage K8s YAML for different environments. minikube and kind run a local K8s cluster for testing K8s-specific features.
Kubernetes Is Not for Every App
Kubernetes has significant operational overhead — it requires K8s expertise, YAML proficiency, and ongoing maintenance. For small teams or early-stage products, managed platforms like Heroku, Railway, Render, or AWS App Runner offer similar benefits with far less complexity. Adopt Kubernetes when your scale or organizational structure genuinely requires it.
How We Research and Update This Guide
We test the underlying formula or workflow, compare outputs with reliable references, and revise examples whenever the page content changes.
- The workflow or formula is tested directly in the tool and compared against independent reference examples.
- Examples are kept practical so readers can verify the result without hidden assumptions.
- Pages are revised whenever the interface, calculation flow, or surrounding guidance materially changes.
Frequently Asked Questions — Kubernetes
Kubernetes (K8s) is a container orchestration platform — it automates the deployment, scaling, and management of containerised applications. Instead of manually running "docker run" on servers, you declare the desired state (I want 5 replicas of my API container) and Kubernetes makes it happen and keeps it that way. If a container crashes, K8s restarts it. If load spikes, K8s scales up. If a node fails, K8s reschedules workloads elsewhere.
A Pod is the smallest deployable unit in Kubernetes — not a container. A Pod wraps one or more containers that share network and storage. In practice, most Pods have one container. Containers in the same Pod communicate via localhost and share the same IP address. Pods are ephemeral — they are created and destroyed. You should never manage Pods directly; use higher-level abstractions like Deployments that manage Pods for you.
A Pod is a single instance of your container. A Deployment is a controller that manages a ReplicaSet of Pods. You tell the Deployment "I want 3 replicas of this Pod." The Deployment ensures 3 Pods are always running. If one crashes, the Deployment creates a replacement. Deployments also handle rolling updates — gradually replacing old Pods with new ones so there is no downtime during deployments.
ClusterIP (default): Service is only reachable within the cluster — no external access. NodePort: exposes the Service on each node's IP at a static port — accessible from outside the cluster but not production-grade. LoadBalancer: provisions a cloud load balancer (AWS ELB, GCP LB) — the standard way to expose services in production on cloud K8s. ExternalName: maps the Service to an external DNS name. Ingress: not a Service type but an HTTP routing layer — routes traffic to different Services based on hostname/path.
Docker Compose runs multi-container applications on a SINGLE host. It is perfect for local development. Kubernetes runs containers across a CLUSTER of multiple machines with automatic scheduling, self-healing, auto-scaling, rolling updates, and service discovery. Kubernetes is production-grade, multi-node, and cloud-native. Docker Compose is simpler but has no built-in high availability or scaling. For production workloads on multiple servers, Kubernetes is the standard.
Running Kubernetes yourself (self-hosted) requires managing the control plane (API server, etcd, scheduler, controller manager) — complex and operationally heavy. Managed Kubernetes services handle the control plane for you: AWS EKS, Google GKE, Azure AKS. You only manage worker nodes (or not, with serverless K8s like EKS Fargate). Managed K8s is the standard for production: you get automatic K8s version upgrades, HA control plane, and integration with cloud services (IAM, load balancers, storage).