← Software Engineering Studio
Plain-Language Explainer · DevOps

What Is Kubernetes?

Running one container is easy. Running hundreds of containers reliably, across many machines, is a full-time job for software — that job is what Kubernetes does.

The one-sentence version: you tell Kubernetes what you want running ("5 copies of this container, always"), and it continuously works to make that true — restarting crashed containers, moving them off failed machines, and scaling up or down — without a human babysitting each one.

Why does this need to exist?

A single Docker command can start one container on one machine easily enough. But a real production system might run dozens of different services, each needing multiple copies for reliability and to handle load, spread across many machines, with traffic routed correctly to healthy instances, updates rolled out without downtime, and automatic recovery when something fails. Doing all of that by hand, or with custom scripts, doesn't scale — Kubernetes is the standardized tool that handles it.

Core concepts, in order

Cluster
The full set of machines (nodes) Kubernetes manages together as one pool of compute resources.
Node
A single machine (physical or virtual) in the cluster that runs containers.
Pod
The smallest deployable unit — one or more containers that share networking and storage, scheduled together on the same node.
Deployment
Manages a set of identical Pods, handling scaling and rolling out updates without downtime.
Service
A stable network address/name for a group of Pods, so other components can reach them reliably even as individual Pods come and go.
Namespace
A way to divide one cluster into isolated virtual sub-clusters, commonly used to separate teams or environments (dev/staging/prod).

How Kubernetes Fits Into a Deployment Pipeline

Kubernetes usually sits at the end of a CI/CD pipeline — after code is built, tested, and packaged into a container image, Kubernetes is what actually runs and manages that image in production.

Declarative vs. imperative management

Kubernetes is fundamentally declarative: instead of issuing commands like "start this container," you write a configuration file describing the desired end state ("this deployment should have 5 replicas of this image, exposing port 8080"), and Kubernetes' control loop continuously compares that desired state against reality and takes whatever action is needed to close the gap. This is why Kubernetes can recover automatically from failures — it isn't running a one-time script, it's constantly re-checking and re-converging.

Scaling and load balancing

A Deployment can be scaled up or down (manually, or automatically via a Horizontal Pod Autoscaler reacting to CPU/memory/custom metrics), and a Service in front of it automatically load-balances traffic across all healthy Pods, so scaling doesn't require any change to how other parts of the system find and talk to it.

When Kubernetes is overkill

Kubernetes brings meaningful operational overhead: someone has to run, secure, and maintain the cluster itself (or pay a managed service to do it), and its configuration surface (YAML manifests, RBAC, networking policies) has a real learning curve. For a handful of services or a small team, simpler options — a single-server Docker Compose setup, or a fully-managed container platform that hides the orchestration layer — often deliver the needed reliability with far less operational burden.

Frequently asked questions

What does Kubernetes actually do?

Kubernetes automates running, scaling, and healing a fleet of containers across a cluster of machines. You describe the desired state ("I want 5 copies of this container running"), and Kubernetes continuously works to make reality match that description — restarting failed containers, moving them to healthy machines, and scaling up or down as needed, all without a human manually managing each container.

What is the difference between a Pod, a Deployment, and a Service in Kubernetes?

A Pod is the smallest deployable unit — one or more tightly coupled containers that run together. A Deployment manages a set of identical Pods, handling scaling and rolling updates (replacing old Pods with new ones without downtime). A Service gives a stable network address to a group of Pods, so other parts of the system can reach them reliably even as individual Pods are replaced.

Do I need Kubernetes for a small project?

Usually not. Kubernetes adds real operational complexity — it's worth it once you're running enough services, need automated scaling/healing across multiple machines, or need to standardize deployment across many teams. A small project with a handful of containers is often better served by simpler tools (a single Docker Compose file, or a managed container platform) until scale or complexity actually demands Kubernetes.

How is Kubernetes different from Docker?

Docker builds and runs individual containers on one machine. Kubernetes orchestrates many containers across many machines — deciding which machine runs which container, restarting failed ones, load-balancing traffic between them, and rolling out updates. They're complementary, not competing: Kubernetes commonly uses container images built by Docker (or another container build tool) as the unit it schedules and runs.

What does "self-healing" mean in Kubernetes?

If a container crashes, becomes unresponsive, or the machine it's running on fails, Kubernetes automatically detects this (via health checks) and takes corrective action — restarting the container or rescheduling it onto a healthy machine — to bring the actual running state back in line with the declared desired state, without a human needing to intervene.