What Is Kubernetes, and Why

Kubernetes is an open-source system for running containerized applications across a fleet of machines and keeping them running the way you asked, even as individual servers fail, traffic shifts, and new versions roll out underneath everything. It exists because containers solved one problem — packaging an application so it starts fast and runs identically everywhere — while creating another: once you have hundreds of containers spread across dozens of hosts, something has to decide which host runs which container, restart the ones that crash, route traffic only to the ones that are healthy, and roll out changes without an outage. This page traces where Kubernetes came from — over a decade of Google running everything on internal systems called Borg and Omega — the single idea, declarative desired state, that makes it behave the way it does, and why, out of a genuinely crowded field of competitors, it is the one every major cloud now ships as a first-class product.

The problem containers create once you have more than a few

☺ Like you're 10: One container on your laptop is easy to babysit by hand. A few hundred spread across dozens of machines is not — something has to decide where they run and notice when they die, without you watching every one of them.

Containers — covered in depth in DevOps's containers & orchestration lesson if you want the packaging story from the start — solve how an application starts and what it carries with it. They say nothing about where it runs or what happens when it stops running unexpectedly. The moment you have more containers than fit on one host, or more than one person can babysit by hand, five questions become unavoidable and have to be answered by something, continuously: which machine has room for this container right now? What happens to traffic pointed at a container that just crashed? How do you roll out v2 without dropping requests mid-swap? How does one container find another it depends on, when either might move hosts at any moment? Where do secrets and configuration live so they aren't baked into the image?

Kubernetes' job description is right there in the word "orchestration." An orchestra doesn't need a conductor to make an individual instrument produce sound — that's the player's job, and in this analogy it's the container runtime's job (containerd, under the hood). It needs a conductor to decide who plays when, at what volume, and what happens the instant one musician skips a bar. Kubernetes is that conductor for containers: it decides placement (the scheduler), watches for failures and replaces what died (the kubelet plus controllers), gives every group of containers one stable address to be reached at (a Service), and rolls updates out gradually while watching for regressions (a Deployment's rolling-update strategy). None of that is optional once you're past a handful of containers — it's just a question of whether you build it yourself, badly, or adopt something that already has.

Where it came from: two decades of Google solving this internally first

☺ Like you're 10: Google didn't invent this problem for Kubernetes — they'd already been running nearly every one of their own services this way, on private systems called Borg and Omega, for more than a decade before Kubernetes ever became public.

Long before Kubernetes existed, Google had to solve the exact orchestration problem above at a scale almost nobody else operated at: hundreds of thousands of machines running search, Gmail, ads, and everything else, often on the same shared clusters. Their answer, running in production since the early 2000s, was an internal system called Borg — a central scheduler and cluster manager, publicly documented only in 2015 in the paper "Large-Scale Cluster Management at Google with Borg." Borg introduced, and battle-tested, most of the vocabulary Kubernetes still uses today: jobs made of tasks, priority and preemption, resource quotas, and a declarative configuration language rather than an imperative deploy script.

A 2013 paper described Omega, Google's next attempt — a redesign meant to fix Borg's biggest weakness, a single monolithic scheduler that became a bottleneck as the fleet grew, by moving toward a more decentralized, optimistic-concurrency approach where multiple schedulers could work against shared cluster state at once. Omega mostly never shipped as a replacement for Borg internally, but its ideas — not its code — fed directly into what came next.

In 2014, a small team at Google (Joe Beda, Brendan Burns, and Craig McLuckie are usually credited as its co-founders) open-sourced a brand-new system, written from scratch in Go rather than reusing Borg's C++ codebase, explicitly designed to run on any infrastructure — not just Google's own datacenters. It reached v1.0 in July 2015, the same moment Google donated it to help launch the newly formed Cloud Native Computing Foundation (CNCF) under the Linux Foundation — handing governance to a vendor-neutral body instead of keeping it a Google product. Kubernetes became the CNCF's first project to reach Graduated status, in March 2018. The name comes from the Greek κυβερνήτης (kybernḗtēs), "helmsman" — the same root as "governor" and "cybernetics" — which is why the project's logo is a seven-spoked ship's wheel, and why the community-standard abbreviation "K8s" simply counts the eight letters it replaces.

The one idea that explains almost everything else: declarative desired state

☺ Like you're 10: You don't tell Kubernetes the exact steps to fix a broken container — you tell it what "fixed" looks like, once, and something inside the cluster keeps checking and re-fixing it forever.

Most operations tooling before Kubernetes was imperative: you wrote the steps, in order, to get from here to there, and ran them by hand or on a schedule. Keeping three copies of a web server running with a script looks something like this — and it only handles the failure case you thought to write:

# imperative: you own every step, forever
while true; do
  for n in 1 2 3; do
    if ! docker inspect -f '{{.State.Running}}' "web-$n" 2>/dev/null | grep -q true; then
      docker run -d --name "web-$n" myapp:v3
    fi
  done
  sleep 5
done

Kubernetes is declarative instead: you submit a description of the end state you want, and the system's own machinery is responsible for reaching and then continuously maintaining it — including failure cases you never wrote code for, like the entire host disappearing.

# declarative: you own the description, not the steps
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: myapp:v3

kubectl apply -f deployment.yaml doesn't run those three replicas itself — it hands the description to the API server, which durably records it in etcd as desired state. From there, a controller does nothing but watch: compare desired state (three replicas) against actual state (however many are really running right now), and take the smallest action that closes the gap. Lose a node, and the gap reappears on its own; the controller notices on its very next pass and reschedules a replacement, with nobody paging anyone. This is the exact mechanism the object model page and the API & controller pattern page go on to formalize, and it's the same reconciliation idea platform engineering pushes one level further out, to Git, in PE's deep dive on Kubernetes as the platform substrate.

Why Kubernetes, out of a genuinely crowded field

☺ Like you're 10: Around 2014–2017 there were three serious contenders for "the" way to orchestrate containers — Kubernetes wasn't the obvious winner going in, and by 2017 the other two had mostly conceded.

Kubernetes didn't win by default. Docker Swarm, built directly into the Docker Engine, was genuinely the easiest of the three to start with — but its scheduling and extensibility were thin next to what large, complex deployments needed. Apache Mesos, paired with the Marathon framework, was already proven at enormous scale at companies like Twitter and Airbnb — but it was a general-purpose resource manager first, container orchestrator second, with more moving parts to operate than most teams wanted to take on. The period roughly 2014 through 2017 is often called the "orchestration wars," and Kubernetes came out of it as the clear default for a handful of concrete reasons, not just momentum:

• Vendor-neutral governance. CNCF stewardship meant no single company controlled the roadmap — which mattered enormously once AWS, Microsoft, and Google were each trying to sell competing managed container platforms and none of them wanted to cede the API to a rival.
• An API built to be extended. Custom Resource Definitions and admission webhooks let teams teach the same control loop entirely new nouns — "give me a database," "give me a certificate" — turning Kubernetes into a platform for building platforms rather than a fixed scheduler. See operators & CRDs.
• Competitors stopped competing and started shipping it. By 2017, even Docker Inc. had added native Kubernetes support to Docker Enterprise, and Mesosphere had added it to DC/OS — widely cited as the moment the orchestration wars effectively ended.
• One API, portable everywhere. Every major cloud now sells a managed control plane — EKS, GKE, AKS — that removes the hardest operational part of running Kubernetes yourself, while keeping the same API and the same YAML portable across all three. That's the one property no single cloud's proprietary scheduler, and no earlier contender, could offer.

See the CNCF project landscape for how Kubernetes' huge surrounding ecosystem — Prometheus, Helm, Argo, and dozens more — fits together, and multi-cluster & fleet management for what running more than one cluster of it actually looks like in practice.

What Kubernetes is not

☺ Like you're 10: Kubernetes runs containers reliably — it doesn't, by itself, give you a URL, a database, a CI pipeline, or good security, which is exactly why a whole ecosystem exists around it.

Kubernetes ships scheduling, self-healing, service discovery, and rollout primitives. It is not, by itself, a Platform-as-a-Service. A fresh cluster has no default ingress controller routing external traffic in, no CI/CD pipeline building or deploying anything, and no network policy restricting who can talk to whom — teams still choose and operate an ingress controller, a CNI plugin, an observability stack, and an RBAC and admission-control policy on top, each covered in its own deep-dive page later in this course. Nor is it a default choice for every team: running Kubernetes yourself carries real, ongoing operational weight — etcd backups, control-plane upgrades, node lifecycle — that a small application with steady, modest traffic frequently doesn't need at all.

This course follows Kubernetes through the CNCF's own certification ladder, starting at the associate level with KCNA and KCSA and moving up through the professional and specialist tiers — CKA, CKAD, and CKS — beginning at Kubernetes Certifications. If you're chasing the full Kubestronaut or Golden Kubestronaut track, the other nine CNCF certifications plus the Linux Foundation's LFCS live in the sibling Golden Astronaut course — this course does not duplicate that material, only points to it.