Kubernetes (often abbreviated K8s) is an open-source system for automating the deployment, scaling, and management of containerized applications. Understanding why it exists — what problems it solves — makes its design much easier to understand.
The problem Kubernetes solves
Before Kubernetes, running many containerized services in production meant manually deciding which machine to run each container on, manually restarting containers that crashed, manually scaling up when traffic increased, and manually managing the network routing between services.
This was manageable at small scale but became a full-time job at any significant scale. Kubernetes automates this operational work. You declare what you want — "I need 5 replicas of my web service, each with 256MB of memory" — and Kubernetes makes it happen and keeps it happening.
Core concepts
Cluster: A Kubernetes cluster consists of a control plane (managing the cluster) and worker nodes (running your workloads). In managed Kubernetes services (GKE, EKS, AKS), the control plane is managed by the cloud provider.
Node: A single machine (physical or virtual) in the cluster where workloads run.
Pod: The smallest deployable unit in Kubernetes. A pod is one or more containers that share network and storage. Pods are ephemeral — they can be terminated and replaced at any time.
Deployment: Manages a set of identical pods. If a pod crashes, the Deployment ensures a replacement is started. If you want to run 5 copies of your web service, create a Deployment with replicas: 5.
Service: Provides stable network access to a set of pods. Pods have ephemeral IP addresses that change when pods are replaced. A Service provides a stable IP and DNS name, and routes traffic to healthy pods.
Namespace: A logical partition of the cluster, useful for organizing resources by team or application. Resources in different namespaces are isolated by default.
ConfigMap and Secret: ConfigMaps store non-sensitive configuration data (environment variables, config files). Secrets store sensitive data (passwords, API keys) in an encrypted form.
The declarative model
Kubernetes uses a declarative configuration model: you describe the desired state of your system, and Kubernetes continuously works to make the actual state match the desired state.
A Deployment definition looks like:
apiVersion: apps/v1
kind: Deployment
metadata:
name: web-app
spec:
replicas: 3
selector:
matchLabels:
app: web-app
template:
metadata:
labels:
app: web-app
spec:
containers:
- name: web
image: my-registry/web-app:v2.1
ports:
- containerPort: 8080
resources:
requests:
memory: "128Mi"
cpu: "100m"
limits:
memory: "256Mi"
cpu: "500m"
Apply this with kubectl apply -f deployment.yaml and Kubernetes ensures 3 pods running this container exist and remain running.
Scheduling
When a pod needs to run, the Kubernetes scheduler decides which node to place it on. The scheduler considers:
- Resource requests: How much CPU and memory does the pod need? Nodes without sufficient available capacity are excluded.
- Node affinity/taints: Constraints on which nodes can run a pod
- Spread constraints: Prefer to spread pods across nodes and availability zones for resilience
Resource requests are what the scheduler uses for placement decisions. Resource limits are enforced at runtime — a container exceeding its memory limit is killed and restarted.
Rolling updates and rollbacks
When you update a Deployment (typically by changing the container image version), Kubernetes performs a rolling update: it gradually replaces old pods with new ones. If the new pods fail their health checks, the rollout stops. You can roll back to the previous version with kubectl rollout undo.
Health checks
Kubernetes monitors pod health with two types of probes:
Liveness probe: Is the application alive? If this fails, Kubernetes restarts the container. Useful for detecting deadlocks.
Readiness probe: Is the application ready to receive traffic? If this fails, the pod is removed from the Service's endpoints. Useful for ensuring pods only receive traffic when they are ready.
When Kubernetes is worth the complexity
Kubernetes adds significant operational complexity. It is justified when:
- You have many services that need to run reliably in production
- You need automated scaling, rolling deployments, and self-healing
- Your team has (or will build) the expertise to operate it
For a small team with a simple application, managed platforms like Railway, Fly.io, or Cloud Run often provide the same practical benefits with far less complexity.
Summary
Kubernetes automates deployment, scaling, and management of containerized workloads across a cluster of machines. Key concepts are pods (running containers), Deployments (managing sets of pods), and Services (providing stable network access). It uses a declarative model: describe desired state and Kubernetes works to maintain it. It is powerful but complex — worth evaluating managed alternatives for smaller-scale applications.