The short answer
Quick answer: Kubernetes is a system for running containers across a group of machines. You tell it what you want, for example "run five copies of this container and expose them on port 443", and it works continuously to make that true. It decides which machine each container runs on, restarts containers that crash, replaces ones on failed machines, spreads network traffic across healthy copies, scales the number up and down, and rolls out new versions without downtime. Companies use it because it gives them one consistent, automated way to operate hundreds of services on any cloud or their own hardware.
The problem it solves
Running one container on one server is simple. Running hundreds of containers across dozens of servers raises questions immediately:
- Which server has room for this container?
- What happens when a container crashes at 3 a.m.?
- What happens when a whole server dies?
- How do containers find each other when their addresses keep changing?
- How do you update to a new version without an outage?
- How do you add capacity when traffic rises?
Doing this by hand, or with home-made scripts, does not scale. A container orchestrator automates it. Kubernetes, released by Google in 2014 and drawing on its experience running containers internally, became the standard. It is now maintained by the Cloud Native Computing Foundation. The name is often shortened to K8s.
The key idea: declare the desired state
Traditional operations are imperative: "start this container on that server". Kubernetes is declarative. You describe the end result in a file, and Kubernetes makes it happen and keeps it that way.
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: registry.example.com/web:1.4.2
ports:
- containerPort: 8080
resources:
requests: { cpu: "250m", memory: "256Mi" }
This says: three copies of this image should always be running. If one dies, Kubernetes starts another. If you change replicas to 10, it starts seven more. If you change the image tag, it rolls out the new version.
Underneath is a reconciliation loop: small programs called controllers constantly compare the desired state with the actual state and act to close any gap. A thermostat is the usual analogy. You set the temperature; it does whatever is needed to reach and hold it.
The main building blocks
| Object | What it is |
|---|---|
| Pod | The smallest unit: one or more containers that run together, share a network address and can share storage. Pods are disposable |
| Deployment | Manages a set of identical pods: how many, which version, how to update |
| Service | A stable name and virtual IP address in front of a changing set of pods, with load balancing between them |
| Ingress / Gateway | Routes HTTP traffic from outside the cluster to services, by hostname and path |
| ConfigMap and Secret | Configuration and sensitive values, kept separate from the image |
| Namespace | A way to divide a cluster between teams or environments |
| StatefulSet | Like a Deployment, for workloads that need stable identities and storage, such as databases |
| DaemonSet | Runs one pod on every node, for things like log collectors |
| Job / CronJob | Runs a task to completion, once or on a schedule |
| PersistentVolume | Storage that outlives any individual pod |
Pods are deliberately temporary. They come and go, and their IP addresses change. That is why you never address a pod directly. You address a Service, which always points at whichever healthy pods currently match its label selector.
How the cluster is organised
A cluster has two parts, described in the Kubernetes architecture documentation.
The control plane
| Component | Job |
|---|---|
| API server | The front door. Every command and every component talks to it |
| etcd | A consistent, replicated key-value store holding all cluster state. It uses the Raft algorithm; see how consensus algorithms work |
| Scheduler | Chooses a node for each new pod, based on available resources and constraints |
| Controller manager | Runs the reconciliation loops |
The worker nodes
| Component | Job |
|---|---|
| kubelet | An agent on every node that starts and monitors the containers assigned to it |
| Container runtime | Actually runs containers (commonly containerd) |
| kube-proxy / network plugin | Sets up networking so services and pods can reach each other |
What happens when you deploy
- You submit the file with
kubectl apply. - The API server validates it and stores it in etcd.
- The deployment controller notices that three pods should exist and none do, and creates three pod objects.
- The scheduler assigns each pod to a node with enough free capacity.
- The kubelet on each of those nodes pulls the image and starts the containers.
- The service starts sending traffic to pods that pass their readiness checks.
What you get
- Self-healing. Crashed containers are restarted. Pods on a failed node are recreated elsewhere. Pods that fail health checks stop receiving traffic.
- Scaling. Change a number, or let an autoscaler adjust it from CPU or other metrics. See how auto-scaling works.
- Rolling updates and rollbacks. New pods are brought up and old ones removed gradually. If the new version fails its checks, the rollout stops, and you can revert with one command. See blue-green and canary deployments.
- Service discovery and load balancing. Services get DNS names inside the cluster.
- Efficient use of machines. The scheduler packs workloads onto nodes according to their declared resource needs.
- Portability. The same definitions work on any conforming cluster, on any cloud or on your own servers.
- Extensibility. You can add your own resource types and controllers. This is how tools for databases, certificates and machine learning plug in.
Health checks deserve a mention. A liveness probe tells Kubernetes when to restart a container. A readiness probe tells it when a container can receive traffic. A startup probe covers slow-starting applications.
Why companies adopt it
- Standardisation. Every service is deployed, scaled and monitored the same way.
- A huge ecosystem. Monitoring, security, networking and deployment tools all integrate with it.
- Avoiding lock-in. It runs on every major cloud.
- Skills. It is widely known, which makes hiring and onboarding easier.
- Automation at scale. Operating thousands of containers by hand is not feasible.
The costs
Kubernetes is powerful and it is complex.
- A steep learning curve. There are many concepts, and many ways to misconfigure them.
- Operational overhead. Someone must upgrade the cluster, manage networking and security, and debug it.
- YAML sprawl. Real applications involve a lot of configuration.
- Easy to get security wrong. Permissions, network policies and secrets all need deliberate setup.
- Cost. Clusters often run with a lot of unused capacity.
Managed services such as Amazon EKS, Google GKE and Azure AKS run the control plane for you, which removes much of the burden but not all of it.
Do you need it?
| Your situation | Probably better |
|---|---|
| One application, a small team | A platform-as-a-service, or a managed container service |
| Occasional or event-driven workloads | Serverless; see what serverless really means |
| A handful of containers on one server | Docker Compose |
| Many services, several teams, a need for consistency and portability | Kubernetes |
A common mistake is adopting Kubernetes before having the problems it solves. It pays off when you have many services and a team able to run the platform.
Frequently asked questions
What is Kubernetes in simple terms?
A system that automatically runs and manages containers across many machines, keeping the number and version you asked for running at all times.
What is the difference between Docker and Kubernetes?
Docker builds and runs containers on a single machine. Kubernetes coordinates containers across a cluster of machines.
What is a pod?
The smallest deployable unit in Kubernetes: one or more containers that share a network address and are scheduled together.
Is Kubernetes only for large companies?
No, but its complexity is easier to justify at scale. Small teams are often better served by simpler managed platforms.
Conclusion
Kubernetes turns a group of machines into a single platform that you program with declarations: say what should be running, and controllers keep it running. That brings self-healing, scaling and safe rollouts as standard. The price is real complexity, so the question is not whether Kubernetes is good, but whether your situation has reached the point where it is worth it.
Related articles
- How Docker Containers Work (and How They Differ From VMs)
- How Auto-Scaling Handles Sudden Traffic Spikes
- How Consensus Algorithms Like Raft Keep Servers in Agreement
- How Blue-Green and Canary Deployments Reduce Risk
Sources and further reading
