The History of Kubernetes, Part 1: Borg, the Orchestration Wars, and Docker

On June 6, 2014, the first commit—250 files and 47,501 lines of code—was pushed to GitHub. Four days later, Google Cloud Vice President Eric Brewer took the stage for a DockerCon 2014 keynote and introduced an open source project called Kubernetes to the world.

A decade later, Kubernetes had become widely regarded as the “operating system of the cloud.” According to the official DevStats tenth-anniversary figures, the project had attracted more than 88,000 contributors from over 8,000 companies. The CNCF (Cloud Native Computing Foundation) ecosystem had grown to roughly 200 projects and millions of cloud-native engineers.

Part 1 examines how Kubernetes reached that position: why Google chose to turn its Borg experience into an open source project, how Kubernetes defeated Mesos and Swarm within three years, and how its relationship with Docker moved from mutual reinforcement to separation.

1. Summer 2013: A Proposal Rejected Inside Google

The story begins with a product manager’s concern.

In the summer of 2013, Craig McLuckie, then a Google product manager and later a Kubernetes cofounder, recalled in an account of the project’s origins that he had noticed a troubling pattern: Google Compute Engine (GCE) customers were “renting lots of CPU but actually using very little of it.” The main reason was that they were running traditional virtual machines (VMs) in the cloud.

Inside Google, containers were already in widespread use. The company knew they could scale, move easily between environments, and make exceptionally efficient use of hardware. But the wider market lacked a mature platform for managing containers at scale.

Behind that concern lay a stark imbalance in the cloud market. AWS had started building its position years before Google, and enterprise workloads around the world were moving there quickly. Google would struggle to catch up through price cuts or copied features alone. If it could establish “containers use hardware more efficiently than virtual machines” as a new industry standard, however, Google could bring its strength in operating infrastructure at scale to bear.

In other words, Kubernetes was a strategic weapon from day one.

Google already had a management system refined over a decade: Borg, one of the company’s most important internal technologies. Since the mid-2000s, Borg had run hundreds of thousands of jobs across clusters of up to tens of thousands of machines each. By colocating jobs of different priorities over long periods, it pushed data center resource utilization to levels rarely seen in the industry.

When McLuckie first proposed creating an external, open source version of that system, he met blunt opposition:

“So let me get this straight. You want to make an external version of the Borg scheduler—one of our most important competitive advantages, something we don’t even talk about publicly. And then you want to open source it?”

The proposal was initially rejected. The turning point came during an ordinary shuttle commute: McLuckie persuaded Vice President Eric Brewer, who formulated the CAP theorem, and later secured approval from Urs Hölzle, Google’s top technical infrastructure executive.

2. Project Seven of Nine: A Name, a Tribute, and an Architectural Legacy

The project’s original internal codename was Project Seven of Nine, after Seven of Nine, a character from Star Trek. In the series, the Borg are a collective that assimilates other species. Seven of Nine was originally a human assimilated by the Borg; she later left the collective and joined the main cast.

Google’s internal system was also named Borg. Kubernetes was the Borg that left Google and opened up to the outside world.

The tribute appears in the project’s visual identity as well: the Kubernetes logo is a ship’s wheel with seven spokes. The project’s name comes from the Greek κυβερνήτης, meaning “helmsman,” and the community abbreviates it to K8s.

 Heritage from Borg and Omega to Kubernetes

 +-------------------------+  +-------------------------+
 | Borg (2000s)            |  | Omega (Research)        |
 | Proven at scale         |  | Shared state store      |
 | Monolithic controller   |  | Decentralized control   |
 +-------------------------+  +-------------------------+
              |                            |
              v                            v
 +------------------------------------------------------+
 | Kubernetes (Clean-room rewrite in Go)                |
 | Declarative API + Independent reconciliation loops   |
 +------------------------------------------------------+

One widespread misconception needs clearing up: Kubernetes was not a Go rewrite of Borg.

The 47,501 lines of code released on the first day came from a new, independent codebase. No Borg source code was copied directly. As the Google team summarized in its ACM paper, “Borg, Omega, and Kubernetes”, what the project inherited was fifteen years of architectural lessons:

• Borg proved that container orchestration at scale was possible, while exposing scalability limits in a centralized, monolithic scheduler.
• Its successor research project, Omega, demonstrated the flexibility of a shared state store with multiple controllers.

Together, those lessons laid the foundation for Kubernetes’ declarative API and reconciliation loops. Users declare the system’s desired state; multiple independent controllers then keep watching and reconcile the cluster’s actual state toward it.

Cofounders Joe Beda, Brendan Burns, and Craig McLuckie built this architecture with Google’s core engineering team, setting the standard for the open source expansion that followed.

⭐️3. What Would Google Gain by Sharing Borg’s Lessons?

The initial objection was reasonable: Borg was one of Google’s most important competitive advantages. Why share its design principles with everyone, including competitors?

The answer depends on where Google wanted to compete.

In the existing market, Google was playing catch-up. Cloud competition in 2013 centered on renting virtual machines. AWS had led for years, and customers had built systems around AWS-specific services such as EC2 and ELB. Moving elsewhere was costly. In a contest over price and features at that layer, the deeper customers were locked in, the stronger the leader’s position became.

Kubernetes added a cloud-independent abstraction above that layer. Once applications ran on K8s, customers worked with the K8s API. Which cloud lay underneath became less important:

• Applications could move among AWS, Google Cloud, and a company’s own data centers, weakening AWS’s lock-in.
• Cloud providers increasingly became places to host K8s, while the underlying compute capacity grew more interchangeable.

The people who understood the new layer best would define it. K8s inherited design lessons from Borg and Omega, and Google knew how to operate systems like it. Containers could pack more work onto machines, while efficient operation of infrastructure at scale was already Google’s strength. Shifting the contest to this layer gave the hardware-utilization advantage described earlier room to matter.

Google also moved first. GKE, Google’s managed Kubernetes service, became generally available in 2015. AWS did not announce EKS until late 2017.

Open source was essential to this strategy. If K8s had been a Google-only product, customers would merely have traded AWS lock-in for Google lock-in. Few would have accepted that. Only an open source project could persuade vendors beyond AWS to rally behind it.

Time was short, too. In 2013 and 2014, Docker swept through the developer community at extraordinary speed. Brendan Burns later recalled that Docker’s explosive popularity convinced the team that “an open source container orchestration system was bound to emerge.”

If Google did not help define that standard, Docker Inc. or the Apache Mesos camp would. Google was happy for Docker to define the single-machine container format, but it wanted a decisive voice in defining multi-machine orchestration and cluster management.

In hindsight, the move did change the rules: K8s became an industry standard, and even AWS eventually embraced it with EKS. Google Cloud did not overtake AWS as a result; AWS remains the cloud market leader. What Google gained was a way out of a structural disadvantage and influence as a standard setter.

4. The Orchestration Wars (2014–2017): Rival Camps and the Deciding Factors

When Kubernetes became open source, the distributed systems space already had formidable contenders.

 Orchestration War: Competing Paradigms (2014–2017)

 +------------------------------------------------------+
 | Apache Mesos + DC/OS (Mesosphere)                    |
 | Veteran enterprise player; massive scale at Twitter  |
 +------------------------------------------------------+

 +------------------------------------------------------+
 | Docker Swarm (Docker Inc.)                           |
 | Zero-config developer UX built into Docker engine    |
 +------------------------------------------------------+

 +------------------------------------------------------+
 | HashiCorp Nomad (HashiCorp)                          |
 | Pragmatic single binary; supports VMs and batch jobs |
 +------------------------------------------------------+

Each rival had a distinct advantage:

• Apache Mesos was the longest-established, academically rooted contender. It had been tested at scale by Twitter (across tens of thousands of nodes), Apple’s Siri, and Uber. Mesosphere built its “data center operating system” (DC/OS) around Mesos, and the platform was once seen as a likely industry standard.
• Docker Swarm excelled at developer experience. Bundled directly into Docker Engine with Docker 1.12 in July 2016, it let developers create a cluster with one command and very little setup.
• HashiCorp Nomad was the pragmatic, lightweight option. It ran as a single binary and could schedule virtual machines and batch jobs as well as containers, with low operational overhead as a central selling point.

Yet a contest expected to last much longer was effectively decided within three years. Three advantages drove Kubernetes’ victory:

1. Neutral Governance Lowered Competitive Barriers

On July 21, 2015, Kubernetes 1.0 was released. At the same time, Google announced that it would donate the project to the newly formed CNCF under the Linux Foundation.

Red Hat, IBM, Intel, VMware, Docker, and CoreOS were among the founding members. The move eased industry concerns: the foundation owned the project, so companies investing in K8s were building a shared industry asset that Google could not monopolize. By comparison, Swarm and Mesos remained tied to the interests of a single commercial company.

2. A Declarative API and Extensive Ways to Extend It

Kubernetes put a declarative model and self-healing controllers at its core. In 2017, Kubernetes 1.7 introduced CustomResourceDefinitions (CRDs), greatly expanding how the platform could be extended. Third-party developers could build capabilities directly on K8s, not merely use it.

Early on, containers were seen as suitable only for stateless applications. Managing a database in containers required complicated manual work. Helm became a standard package management tool. The Operator pattern, introduced by CoreOS, went further by encoding operational knowledge such as database failover, filling a crucial gap for core enterprise applications.

 API Extensibility: Turning Users into Builders

 +-------------------------------------------------+
 | Kubernetes Declarative Control Plane            |
 +-------------------------------------------------+
              |                         |
              v                         v
 +------------------------+  +---------------------+
 | Helm (Package Manager) |  | Operator SDK & CRDs |
 | Standard app packaging |  | Standard automation |
 +------------------------+  +---------------------+

3. An Industry Alliance Against Individual Contenders

The year 2017 marked an inflection point for the industry:

• October 2017 (DockerCon Europe): Docker announced native Kubernetes support alongside Swarm.
• November 2017 (AWS re:Invent): AWS, the cloud market leader, announced Amazon EKS, bringing the last major cloud provider into the K8s camp.
• December 2017 (KubeCon Austin): Microsoft, Oracle, VMware, and other major vendors announced Kubernetes support.

By the end of 2017, the outcome of the container orchestration wars was clear. The official installation tool kubeadm had substantially reduced the early setup burden, while mature scheduling at scale had earned trust across vendors.

5. The Rivals’ Twilight: Three Different Paths After Defeat

After the contest was settled, the three rivals followed very different paths:

Mesosphere: An Industry Pioneer That Pivoted Too Slowly

Once valued at nearly $1 billion, Mesosphere renamed itself D2iQ in 2019 and tried to become a Kubernetes distributor. But it had lost its early market advantage. In 2023, it sold its platform assets to Nutanix.

Docker Swarm: A Built-in Tool Pushed to the Margins

Swarm still exists, but it has receded into the background. Its selling point was simplicity compared with K8s, yet that advantage came under pressure from both ends. For single-machine and local development, one Docker Compose YAML file was enough. For clusters, lightweight K8s options such as k3s and kind—and even the K8s included in Docker Desktop—had become simple enough. Skills learned with K8s also carried into production.

For engineers who already knew K8s, learning Swarm as well offered little benefit.

HashiCorp Nomad: A Survivor That Stayed in Its Niche

Nomad positioned itself as a pragmatic way to avoid the substantial complexity of K8s, and leaned on tight integration with ecosystem tools such as Terraform and Vault. It showed that even after losing the contest to become the standard, a product could survive for years by deliberately serving a focused niche.

6. Kubernetes and Docker: From Mutual Reinforcement to Separation

In March 2013, Docker’s lightning talk at PyCon took the software world by storm. The next two years were Docker’s heyday: its valuation passed $1 billion in 2015, and “Docker” nearly became synonymous with containers.

Without the container revolution Docker ignited, Kubernetes would not have found the same market ready for it. Early on, the two amplified each other: Docker made packaging applications a pleasure for developers, while Kubernetes provided a way to manage them at scale.

 The Architectural Decoupling Timeline

 2015-07: Kubernetes 1.0 released with CNCF donation
    |
 2016-12: CRI in K8s 1.5; containerd donation announced
    |
 2020-12: Dockershim deprecation announced in K8s 1.20
    |
 2022-05: Dockershim completely removed in K8s 1.24
    v
 +------------------------------------------------------+
 | Kubelet -> CRI -> containerd / CRI-O -> OCI Runtime  |
 +------------------------------------------------------+

Once Kubernetes had established its leading position, the two began to decouple. Early versions of Kubelet invoked the Docker daemon directly, using a built-in adapter called dockershim to maintain compatibility.

Kubernetes 1.5 introduced the Container Runtime Interface (CRI) in 2016. That same month, Docker announced that it would separate its core component containerd and donate it to the CNCF. Kubernetes 1.20 announced dockershim’s deprecation in 2020, and version 1.24 removed it in 2022. Since then, Kubernetes nodes have communicated with containerd or CRI-O directly through CRI, without needing Docker Engine.

Docker Inc.’s central problem was a mismatch in its business model: the developer experience it did best was difficult to monetize, while Kubernetes, an open source common good, displaced the enterprise platform layer it hoped to charge for.

In November 2019, Docker sold its enterprise business to Mirantis and refocused on Docker Hub and Docker Desktop.

But saying “Docker lost completely” misses part of the story. Docker lost its ambition to become the operating system of the cloud, yet it still firmly occupies the daily starting point of developers worldwide. The Open Container Initiative (OCI) image format, which Docker helped lead and donated in its early years, is still in use. docker build remains a routine command in terminals across the industry.

7. Part 1 in Review

Looking back, Google’s willingness to let go was a prerequisite for Kubernetes’ victory. By placing the project with a neutral foundation, it gained the support of an entire industry.

Letting go also meant surrendering absolute control. How would a foundation made up of companies around the world, with no single owner, govern infrastructure that was about to carry the world’s computing workloads? And how would the major public cloud providers absorb it into their own platforms?

Part 2 explores that experiment in governing a neutral project, the criticism sparked by Kubernetes’ complexity, and its new role amid the AI wave.