Learn what Kubernetes is and what problem it solves, how it differs from Docker and Docker Compose, the core objects to know, and whether you really need it.
Kubernetes runs containers across a group of machines and keeps them running. You describe what you want. Five copies of this image, reachable at this address, with this much memory, and it works continuously to make reality match that description.
The word people use is declarative. You do not tell Kubernetes to start a container. You tell it what should be true, and controllers inside the cluster keep checking reality against that and correcting the difference. That single idea explains most of how Kubernetes behaves, including the parts that seem strange at first.
Running one container is easy. docker run and you are done.
The difficulty arrives with the questions that follow. What happens when the process crashes at 3am? When the machine it is on dies? When traffic triples and you need more copies, and where do they go? How do you deploy a new version without dropping requests? How does one service find another when addresses keep changing?
Every one of those has an answer without Kubernetes. The answers tend to be scripts, a load balancer someone configures by hand, a runbook, and a person who knows how it all fits together. Kubernetes replaces that with a system that does it continuously and identically whether you have three containers or three thousand.
An API runs three replicas. A node fails, taking one with it.
Without an orchestrator: your monitoring alerts, someone wakes up, starts a replacement somewhere, updates the load balancer, and confirms. Fifteen minutes if things go well.
With Kubernetes: a controller notices that observed state (two replicas) does not match desired state (three), schedules a replacement on a healthy node, and the Service starts routing to it once its readiness probe passes. Typically under a minute, with nobody involved.
Nothing here required intervention, and nothing behaves differently at 3am.
The most useful comparison, because most people arrive from Compose.
Compose is genuinely better for local development and for a single-server deployment. It is simpler, faster to write, and easier to reason about. The moment you need more than one machine, or zero-downtime deploys, or automatic scaling, Compose stops being enough, and that is precisely the boundary where Kubernetes starts being worth its complexity.
Docker and Kubernetes are not alternatives, incidentally. Docker builds the images; Kubernetes runs them across machines. Kubernetes stopped using Docker as its runtime in version 1.24, but images built with Docker work exactly as before, because they follow the OCI standard.
You can be productive knowing five things.
Cluster: the whole system: a control plane that makes decisions and worker nodes that run your containers.
Node: one machine, virtual or physical, that runs workloads.
Pod: the smallest unit Kubernetes schedules. Usually one container, occasionally a couple that must share a network namespace and lifecycle. Pods are disposable; they are created and destroyed constantly.
Deployment: declares how many identical Pods should exist and handles rolling updates and rollbacks. This is what you write for a stateless application.
Service: a stable name and address in front of a changing set of Pods. Pod IPs change constantly; Service addresses do not.
Put together: a Deployment keeps three Pods running across your Nodes, and a Service gives clients one address that reaches whichever Pods currently exist.
Delete one and watch what happens:
A replacement appears within seconds. Nobody asked for it. The Deployment simply observed that there were two Pods where three were wanted.
apiVersion: apps/v1
kind: Deployment
metadata:
name: web
spec:
replicas: 3
selector:
matchLabels:
app: web
template:
metadata:
labels:
app: web
spec:
containers:
- name: web
image: nginx:1.27
ports:
- containerPort: 80
---
apiVersion: v1
kind: Service
metadata:
name: web
spec:
selector:
app: web
ports:
- port: 80
targetPort: 80Entry point for all requests
Assigns pods to nodes
Reconciles desired state
Cloud Controller Manager
Integrates with cloud providers (AWS, GCP, Azure)
The control plane decides what should happen. The API server is the only way in, and everything, kubectl, controllers, the nodes themselves, talks to it. etcd stores cluster state. The scheduler picks nodes for new Pods. Controllers watch for differences between desired and actual state and act on them.
Worker nodes do the work. The kubelet on each node starts and monitors containers and reports back. kube-proxy programs the networking rules that make Services reachable.
The split matters because it explains failure behaviour. If the control plane goes down, running Pods keep running and keep serving traffic. You just cannot change anything or replace failed Pods. It is a management outage, not necessarily a service outage.
Worth asking honestly, because the answer is often no.
Probably not if you run a single application on one or two servers, your team is small and has no Kubernetes experience, you deploy a few times a month, or a managed platform like ECS, Cloud Run, App Runner or Fly.io covers what you need. Kubernetes is a real operational commitment. Upgrades, networking, storage, RBAC, and a steady stream of things to keep current.
Probably yes if you run many services that need to be deployed independently, you need zero-downtime deploys and autoscaling as a matter of routine, you are running across multiple environments or clouds and want one deployment model, or your team is already large enough for a platform function.
The honest failure mode is a small team adopting Kubernetes for a single application and then spending more time on the cluster than on the product. If you are unsure, start with something managed and move when you feel a specific limitation, not before.
You run kubectl delete pod on a Pod managed by a Deployment. Seconds later a new Pod with a different name is running. Why?
The Kubernetes control plane becomes unreachable. Existing Pods are healthy and serving traffic. What is the immediate impact?
Understand Kubernetes architecture: API server, etcd, scheduler, controller manager, kubelet and kube-proxy, and what happens when you run kubectl apply.
Compare ways to install Kubernetes: kind, Minikube, Docker Desktop, k3s, kubeadm and managed clusters, and pick the right one for learning or production.
Install Minikube, run minikube start, enable add-ons like ingress, reach services with minikube tunnel, and build images locally without a registry.