Google Borg to Kubernetes: Learning From an Internal System
also called Borg, Omega
Kubernetes was designed with a decade of Borg experience behind it, and its authors have been explicit about which Borg decisions they deliberately did not repeat.
The context
Google ran containerised workloads on Borg for roughly a decade before Kubernetes existed, then built Omega as an experiment in more flexible scheduling. Kubernetes, released in 2014, was informed by both — and the published accounts are unusually candid about what they chose not to carry forward.
What carried over
Declarative desired state with a reconciliation loop — you describe what should be running and a controller continuously converges reality towards it, rather than issuing imperative commands. This is the central idea, and it is why Kubernetes recovers from disruption without anyone intervening.
The pod as the scheduling unit, grouping co-located containers that share a network namespace and lifecycle.
Labels rather than hierarchy for grouping, so a workload can belong to many overlapping sets rather than one rigid tree.
Separation of the control plane from the workloads it manages.
What they deliberately changed
Borg was built for one organisation with one set of conventions. Kubernetes had to serve many organisations, so it is far more extensible — custom resources, admission controllers and operators — where Borg was opinionated.
The authors have also acknowledged complexity as the price. Borg's users worked inside a company with a shared platform team, shared conventions and shared tooling. Kubernetes users get flexibility and must supply the opinions themselves, which is exactly why platform engineering became a discipline.
The transferable lesson
Declarative reconciliation is the pattern worth taking, independent of Kubernetes. Describe the desired state, have a controller converge towards it continuously, and drift corrects itself. This is what GitOps applies to deployment and what infrastructure-as-code applies to provisioning.
And the caution: Kubernetes provides mechanism, not policy. An organisation adopting it inherits an enormous configuration surface with no opinions attached, and the value only materialises once someone supplies those opinions as a platform. Teams that adopt it expecting a product rather than a toolkit are the ones for whom it becomes a permanent tax.