What Is Kubernetes? A Plain-English Guide

01What problem does Kubernetes solve?

Your app runs in a handful of containers. On one server, that is easy. Then traffic grows and you need ten servers. Some containers crash at 3am and need restarting. You want to roll out an update without downtime, and roll it back fast if it breaks. You need to spread containers across machines so one failure does not take everything down.

Doing all of that by hand, restarting crashed containers, balancing them across servers, replacing dead machines, is a full-time babysitting job. Kubernetes automates it. You describe what you want ("keep five copies of this app running, spread across the cluster"), and Kubernetes makes it happen and keeps it that way, replacing anything that fails without waking anyone up.

02What does Kubernetes actually mean?

Kubernetes is a container orchestrator. Orchestration is the automated coordination of many containers: deciding which machine each one runs on, restarting the ones that fail, scaling them up and down with demand, and connecting them to each other and the outside world.

It started as an internal Google project called Borg, was open-sourced in 2014, and is now the flagship project of the Cloud Native Computing Foundation (CNCF) and the de facto standard for running containers at scale. The name is Greek for "helmsman," and "K8s" is just shorthand (a K, then eight letters, then an s).

03What are the building blocks? (containers, pods, nodes, clusters)

Kubernetes has its own vocabulary, but it is really just four nested ideas.

A Kubernetes cluster: a control plane managing worker nodes, which run pods, which contain your containers.

The nesting goes: containers live inside pods, pods run on nodes, and nodes are grouped into a cluster that a control planemanages. When people say they are "running Kubernetes," they mean they are operating a cluster.

04How does Kubernetes work?

The idea that makes Kubernetes tick is desired state.You do not give it step-by-step commands. You hand it a description of what you want, usually a YAML file, that says something like "run three copies of this app, expose it on this port." You apply that with a command (kubectl apply), and the control plane takes over.

The control plane is the brain. Its API server receives your request, the scheduler decides which nodes have room, and controllers constantly compare the real state of the cluster against your desired state. If you asked for three copies and one crashes, a controller notices the gap and starts a replacement. That constant reconciliation is why Kubernetes is called self-healing: it is always working to make reality match what you declared. Each worker node runs an agent (the kubelet) that starts and stops containers, plus networking (kube-proxy) and a container runtime that actually runs them.

05Docker vs Kubernetes: what is the difference?

This is the most common point of confusion, so it is worth being clear: Docker and Kubernetes are not rivals, they solve different parts of the same problem.

In practice they work together: you build your app into a container image (often with Docker), and Kubernetes takes that image and runs it at scale. A single container on your laptop does not need Kubernetes. A fleet of them serving production traffic is exactly what it is for.

06What are the benefits of Kubernetes?

The trade-off for all of this is real operational complexity, which is exactly why the next sections matter.

07What is managed Kubernetes (EKS, GKE, AKS)?

Running your own Kubernetes control plane, keeping etcd healthy, handling upgrades, is hard, specialized work. So most teams use managed Kubernetes, where a cloud provider runs the control plane for you and you just use the cluster. The three big options:

The usual advice is simple: use the managed Kubernetes that matches the cloud you are already on, rather than switching clouds for a slightly nicer experience. If you are on AWS, EKS is the pragmatic choice.

08Do you actually need Kubernetes yet?

The 2026 consensus among engineers has settled into a pragmatic stance. Kubernetes is the backbone of large production systems (by the CNCF's 2025 survey, around 70% of enterprises run it in production), but for a small team it often adds far more operational overhead than it is worth. A rough guide:

If you do adopt it, resist the urge to build an enterprise-grade platform on day one. Start with a minimum viable cluster and add complexity, service meshes, custom operators, multi-cluster, only when a real need demands it.