Running one container is easy. Running a few thousand of them, across dozens of machines, while users expect the app to stay up no matter what, is a different problem entirely. Which container goes on which machine? What happens when one crashes at 3 a.m.? How do you roll out a new version without downtime? Kubernetes, usually shortened to K8s, is the open source system that answers all of those questions automatically: it deploys, scales, and manages containerized applications for you (Google Cloud).
Key Takeaways
Kubernetes is an open source container orchestration platform: it schedules containers onto machines, restarts failed ones, and scales apps up and down automatically.
It was announced by Google in June 2014, drew on the lessons of Google's internal systems Borg and Omega, and became the seed technology of the Cloud Native Computing Foundation (CNCF).
The core building blocks are simple: pods hold your containers, deployments keep the desired number running, and services give apps a stable address.
It does not replace Docker: Kubernetes manages containers, Docker (and runtimes like containerd) package and run them.
Adoption is massive: 82% of container users run Kubernetes in production, according to the CNCF's 2025 survey (CNCF).
Why "Kubernetes"? The Name and the Origin Story
The name comes from Ancient Greek κυβερνήτης (*kubernḗtēs*), meaning helmsman or pilot, the same root that gave us "cybernetics" and, through Latin, "governor" (Wikipedia). Google Cloud's own docs translate it as "captain." The idea is the same: a steady hand steering the ship. The abbreviation K8s simply counts the eight letters between the K and the s.
The backstory explains why it exists. Before Kubernetes, Google was already running enormous container workloads: when VP of infrastructure Eric Brewer announced the project in 2014, he said Google launched "more than 2 billion container instances" across its data centers *every week*, and that "everything at Google, from Search to Gmail, is packaged and run in a Linux container" (Virtualization Review). Running at that scale taught Google how to schedule, monitor, and heal container fleets, first with an internal system called Borg and later with Omega. Kubernetes was built as a lighter-weight version of those ideas, open sourced, and written in Go.
Kubernetes was announced by Google on June 6, 2014 (conceived by Joe Beda, Brendan Burns, and Craig McLuckie), reached version 1.0 in July 2015, and was offered as the seed technology of the Cloud Native Computing Foundation when the CNCF was formed in 2015 (Wikipedia). Today it is maintained on roughly a quarterly release cadence; the stable release shown in late September 2026 was 1.37.1.
The Problem It Solves: Containers at Scale
Docker, covered in our earlier explainer, solves the packaging problem: the app runs the same everywhere. Kubernetes solves the *operations* problem that appears the moment you have more than a handful of containers:
Scheduling. With 100 containers and 10 servers, which container lands on which server? Kubernetes watches available CPU and memory and places workloads where they fit, respecting constraints you set.
Self-healing. If a container crashes, Kubernetes restarts it. If a whole machine dies, it moves that machine's containers somewhere healthy. Nobody gets paged at 3 a.m. for a single dead container.
Scaling. Traffic spikes? Kubernetes adds more copies of your app, then removes them when traffic falls. You describe the *desired state* ("I want 5 copies of this app running") and Kubernetes works continuously to make reality match.
Updates without downtime. New version of the app? Kubernetes rolls it out gradually, checks each new copy is healthy before moving to the next, and can roll back if something breaks.
Service discovery and networking. Containers come and go constantly; Kubernetes gives your app a stable IP and DNS name so other services always know where to find it, and it load-balances traffic across the copies.
That "desired state" model is the mental shift. With old-fashioned servers you issue commands: run this, stop that. With Kubernetes you declare what the world should look like, and the system converges on it, healing and adjusting on its own.
Core Concepts: Pods, Deployments, Services
You only need three building blocks to understand 80% of Kubernetes.
A pod is the smallest deployable unit: one or more containers that share storage and network, and are always scheduled together. Think of a pod as a wrapper: you almost never run a lone container, you run a pod that holds it (Google Cloud).
A deployment is what keeps your app at the desired replica count and handles smooth updates. Tell it "run 5 copies of my web app," and it creates 5 pods, replaces any that die, and manages rolling upgrades so users never notice a deploy (Google Cloud).
A service provides a stable IP address and DNS name for your application, routing traffic to the currently healthy pods even as individual pods die and are recreated (Google Cloud).
Under the hood, these run on an architecture with two halves. The control plane (API server, the etcd database, the scheduler, and controllers) is the brain: it receives your desired state and makes decisions. The worker nodes are the muscle: each runs a kubelet agent, a container runtime, and kube-proxy, which execute the containers and wire up networking (Wikipedia).
Concept | What it does | Analogy |
|---|---|---|
Pod | Smallest unit; wraps one or more containers | A lunchbox holding your containers |
Deployment | Keeps the desired number of pods running; handles rolling updates | A manager who maintains staffing levels |
Service | Stable IP and DNS for apps whose pods constantly change | A phone number that follows you between devices |
Node | A worker machine that runs pods | A crew member on the ship |
Control plane | API server, etcd, scheduler; decides where things go | The captain's bridge |
Kubernetes vs Docker: Not Rivals
This is the most common confusion, and the official answer is clear: "Docker is not an alternative to Kubernetes" (Google Cloud). Docker is an open industry standard for *packaging and distributing* applications in containers. Kubernetes is for *managing* them once packaged. As Google Cloud puts it: once you start boxing up your applications, you need a way to manage them, and that is what Kubernetes does.
Kubernetes can even be used with or without Docker. For the actual low-level running of containers, it relies on dedicated runtimes, containerd and CRI-O. Support for Docker's own runtime layer (dockershim) was removed entirely in Kubernetes v1.24 back in May 2022, because maintaining it had become a heavy burden and newer runtimes support features like cgroups v2 and user namespaces (Kubernetes blog). Crucially, nothing changed for images: "the images produced from `docker build` will work with all CRI implementations," and you can still use Docker locally no matter which runtime your cluster uses.
If you are looking for containerized open source projects to experiment with, the short repo signal videos on RepoManiac regularly surface projects worth deploying to a small cluster.
Where It Runs: Managed Kubernetes
You can run Kubernetes anywhere: your laptop, bare-metal servers, any cloud. But operating the control plane yourself is real work, so most teams use a managed service. Amazon EKS is a typical example: it provisions and scales the control plane, including the API servers and the persistence layer, across multiple Availability Zones for high availability, automatically detects and replaces unhealthy control-plane nodes, and patches the control plane for you (AWS). For teams that want to skip servers entirely, there is Fargate, which "provides serverless compute for containers" and "removes the need to provision and manage servers" entirely (AWS). Google's GKE and Azure's AKS follow the same managed pattern.
The payoff: your team writes pods, deployments, and services, and someone else keeps the brain of the cluster alive.
The Adoption Story: Why Everyone Standardized on It
The numbers behind Kubernetes' rise are striking. The CNCF's 2025 annual survey, summarized under the headline "82% of container users running Kubernetes in production," shows orchestration has gone from experiment to default (CNCF). The year before, a survey of 689 IT professionals found 80% already running Kubernetes in production, with another 13% piloting or actively testing it (Cloud Native Now). The same survey reported the average organization now runs 2,341 containers, up from 1,140 just a year earlier, and 52% use containers to run most or all of their applications.
That growth explains why Kubernetes skills keep showing up in devops job postings, and why our explainer on how open source contributions can land you a tech job pairs well with learning a tool the industry has clearly standardized on.
Frequently Asked Questions
Is Kubernetes hard to learn?
The basics are approachable: you describe your app in YAML, apply it, and watch pods appear. Tools like minikube or kind let you run a whole cluster on your laptop for free. The depth comes later: networking, storage, security policies, and multi-cluster setups are where the real expertise lives. Start with pods and deployments, then grow.
Do I need to know Docker first?
It helps a lot. Kubernetes manages containers, so understanding images and the container lifecycle (our Docker explainer covers this) makes everything about pods and deployments click faster. You do not need to be a Docker expert, but you should know what an image is.
Is Kubernetes free?
The software is open source and free to run yourself. Costs appear in the infrastructure it runs on (servers or cloud VMs) and in managed control-plane fees if you use a service like EKS, GKE, or AKS. For learning, local options like minikube cost nothing.
When should I NOT use Kubernetes?
For a simple side project or a single server, Kubernetes is overkill: a plain Docker Compose setup is simpler and cheaper. Kubernetes earns its complexity when you have multiple services, need high availability, or want automated scaling and zero-downtime deploys. Start simple, adopt orchestration when the pain of managing things by hand appears.
The Bottom Line
Kubernetes took Google's hard-won lessons from running billions of containers a week and turned them into an open standard the whole industry could use. Describe the state you want, and it handles the scheduling, healing, scaling, and updates to keep it real. From an open source release in 2014 to 82% of container users running it in production, it won because the problem it solves, keeping distributed apps alive at scale, only gets more common. If you are comfortable with Docker, standing up a local cluster is the natural next step. That first `kubectl get pods` returning a healthy, self-healing fleet is usually the moment it clicks.
*Read this article in Indonesian: Kubernetes Dijelaskan: Apa Itu dan Mengapa Penting.*