top of page
Search

The Helmsman

Kubernetes began as a side project inside Google. A decade on it has become the closest thing computing has to a universal control plane — and the substrate on which artificial intelligence is being industrialised

Rows of blue 3D cubes with white Kubernetes logos, arranged in a grid on a futuristic blue background.

Somewhere in a data centre, a machine has just died. A power supply, a kernel panic, a clumsy technician: the cause hardly matters. What matters is what happens next, which is nothing. No pager sounds. No engineer is woken. Within seconds a piece of software notices that the world no longer matches the description it has been given, and sets about correcting the discrepancy. Replacement processes are started elsewhere. Traffic is redirected. By the time anyone looks at a dashboard, the incident has become a line in a log.


That software is called Kubernetes, and a good deal of the modern world now runs on top of it. Banks settle payments through it. Telecoms operators route mobile traffic with it. Retailers survive Black Friday because of it. Increasingly, the large language models that have absorbed so much of the world's capital expenditure are trained and served by it. According to the Cloud Native Computing Foundation (CNCF), the industry body that stewards the project, 82% of organisations using containers now run Kubernetes in production, up from 66% two years earlier; two-thirds of organisations running AI workloads use it to serve inference.


For a technology of such consequence, Kubernetes is remarkably little discussed outside the trade. It has no consumer face, no logo anyone would recognise, no charismatic founder-billionaire. It is plumbing. But plumbing is where the interesting economics usually hide, and the story of how a piece of infrastructure software escaped from Google, defeated better-funded rivals, and became a de facto standard is a case study in how technical architecture, corporate strategy and open-source governance can compound into something close to a natural monopoly — one that nobody, exactly, owns.


Assimilation

The prehistory begins with a problem peculiar to Google. By the mid-2000s the firm was operating computing fleets on a scale nobody had attempted, and doing so with commodity machines that failed constantly. Treating each server as a named pet to be tended individually was hopeless. What Google built instead, starting around 2003, was a system called Borg: a cluster manager that treated tens of thousands of machines as a single undifferentiated pool of compute, and to which engineers submitted work rather than provisioning servers. Borg decided where things ran. Engineers stopped caring.


Borg depended on a mechanism for packing many unrelated programs onto one machine without letting them interfere. Google engineers built it into the Linux kernel itself — the facility eventually known as control groups, or cgroups, contributed upstream in the mid-2000s and merged in 2008. Combined with Linux namespaces, which give a process a private view of the filesystem, network and process table, this produced the container: a way of isolating software that is far lighter than a virtual machine because it dispenses with the second operating system.


For years, containers remained specialist equipment. What changed that was Docker, released in 2013 by a struggling platform startup called dotCloud. Docker's contribution was not the isolation technology, which already existed, but the packaging and the ergonomics: a standard image format, a registry to share images, and a command that worked first time. Within a year, containers went from a Google secret to something any developer could try over lunch.


That created an obvious gap. Millions of engineers suddenly had containers and no idea how to run thousands of them. Google had spent a decade solving precisely that problem and could not open-source Borg, which was too entangled with Google's internal systems and, by many accounts, too idiosyncratic to be a gift. So a small group — Joe Beda, Brendan Burns and Craig McLuckie, joined by veterans of Borg and its experimental successor, Omega — proposed building a clean-room descendant in the open. The project went public in June 2014.


Its working name was Seven, after the Star Trek character Seven of Nine, a Borg drone severed from the collective; the joke survives in the seven spokes of the project's ship's-wheel logo. The name it shipped with was κυβερνήτης, kubernetes, Greek for helmsman or pilot — the same root that yields "governor" and "cybernetics". It was an unusually apt piece of branding. Kubernetes does not row. It steers.


Commoditising the Complement

Why would Google give this away? The answer is a familiar one in technology strategy: commoditise your complement.


By 2014, Amazon Web Services had a commanding lead in cloud computing, and that lead was defended less by superior technology than by gravity. Firms built their systems around Amazon's proprietary interfaces — its load balancers, its queues, its deployment tooling — and moving elsewhere meant rewriting all of it. The switching cost was the moat.


Kubernetes was an attack on that moat. If the industry adopted a common, vendor-neutral way to describe and run applications, then an application became portable in a way it had not been before, and the cloud providers would be pushed towards competing on price, reliability and hardware — a contest Google, with its formidable infrastructure and its lagging market share, was happy to have. Giving the software to a foundation rather than keeping it in-house was essential to the strategy: a Google-controlled Kubernetes would have been adopted by nobody who feared Google.


So in July 2015, when version 1.0 shipped at the O'Reilly Open Source Convention in Portland, Google simultaneously donated the project to a newly created body, the Cloud Native Computing Foundation, housed under the Linux Foundation. It was, in effect, a hostage exchange. Google surrendered control in return for legitimacy, and the industry accepted a Google design in return for a seat at the table.


The Orchestration Wars

Legitimacy did not confer victory. For two years, three camps fought over what came to be called container orchestration.


Docker, which owned the developer relationship, built Swarm — simpler than Kubernetes, and deliberately so, integrated directly into the tool engineers already had. Apache Mesos, born at the University of California, Berkeley and battle-tested at Twitter and Airbnb, came from the opposite direction: a genuine distributed-systems kernel, commercialised by Mesosphere, and more capable than either rival at running data workloads. Kubernetes sat awkwardly between them, harder than Swarm and less mature than Mesos.


It won on three things. The first was extensibility: an architecture that assumed from the outset that other people would need to plug in their own storage, networking and runtime implementations, which meant vendors could build businesses on Kubernetes rather than merely around it. The second was governance: an open, if occasionally baroque, structure of special-interest groups that let Red Hat, CoreOS, Huawei, IBM and eventually Microsoft accumulate real influence, which in turn made them advocates. Docker, by contrast, kept Swarm's fate tied to a single company's commercial fortunes.


The third was simply that everybody else preferred a shared standard to a Docker standard. Red Hat rebuilt its OpenShift product on Kubernetes in 2015. Microsoft hired Mr Burns in 2016. The capitulations came in 2017: at its own European conference in October, Docker announced it would ship Kubernetes alongside Swarm; the following month, Amazon — the vendor with the least to gain — announced a managed Kubernetes service of its own, which reached general availability the following June. Mesosphere added Kubernetes support, then renamed itself. In March 2018 Kubernetes became the first project to graduate from the CNCF. The war was over inside four years, which by the standards of infrastructure standards battles is indecent haste.


The Loop that Ate the World

To understand why Kubernetes enables systems rather than merely running them, it helps to look past the containers, which are the least interesting part, and at the control model underneath.


Most operational software before Kubernetes was imperative. An administrator, or a script, issued commands: install this, start that, add a server, remove a server. The trouble with commands is that they assume the issuer knows the current state of the world, and in a distributed system nobody does. Messages are lost, machines are slow, two scripts run at once. Imperative automation fails in ways that are difficult to reason about because failure leaves the system in a state no one anticipated.


Kubernetes inverts this. A user submits a declaration — a document describing what should be true — to a single API server, which stores it and does nothing else. The work is done by a population of small independent programs called controllers, each of which sits in a loop performing the same three steps forever: observe the actual state of some slice of the world, compare it with the declared state, take one step to close the gap. Repeat.


This sounds unremarkable and is in fact the whole trick. Because each controller re-derives its behaviour from current reality on every pass, it is indifferent to how the world got into its present condition. A missed message is corrected on the next iteration. A crashed controller resumes without needing to know what it was doing. An engineer who edits a document by hand at 3am is quietly overruled. Engineers describe this as level-triggered rather than edge-triggered logic: the system responds to the state of things, not to the event that changed them. It is the same principle as a thermostat, applied to global computing estates, and it is what makes the behaviour in the opening paragraph of this article unremarkable rather than miraculous.


The consequence that matters commercially is what happens when this pattern is made available to everyone else. Kubernetes exposes its own data model — pods, deployments, services — through a uniform API, and then allows anyone to add new object types of their own, called custom resources, served by the same API with the same authentication, the same access controls, the same audit log and the same tooling. Write a controller for your new object type and you have a system: a database platform, a machine-learning pipeline, a certificate authority, a fleet of physical routers, all managed by the same reconciliation logic and the same command-line tool.


This is the pattern the industry named the "operator", and it explains the shape of everything built since. Kubernetes is not a container platform that acquired extensions. It is a general-purpose engine for continuous reconciliation that happens to ship with container support as its first application. Kelsey Hightower, one of the project's most influential evangelists, put the point in a widely repeated formulation: Kubernetes is a platform for building platforms, not the finished article.


Two further design decisions compound the effect. Kubernetes defines interfaces rather than implementations — a container runtime interface, a network interface, a storage interface — so that the ecosystem can compete beneath the standard rather than forking it. And it identifies objects by arbitrary labels rather than names or addresses, so that relationships between components are expressed as queries over sets rather than fixed wiring. Both choices trade immediate simplicity for long-run composability, which is the trade every successful piece of infrastructure eventually has to make.


Out of this grew a practice called GitOps, in which the declared state of an entire estate lives in a version-control repository and a controller continuously reconciles production against it. Deployment ceases to be an action and becomes a property. Auditors like it; so, eventually, do regulators.


The Plumbing Business

Standards create markets, and the market that formed around Kubernetes has been lucrative for everyone except, arguably, the people who wrote it.


The cloud providers were the first beneficiaries. Running Kubernetes yourself is genuinely difficult — the control plane must be highly available, kept current against three releases a year, and secured against a large attack surface — and the obvious response was to pay someone else. Industry trackers reckon that roughly four in five Kubernetes users now consume it as a managed service, with Amazon's offering holding the largest share, followed by Google's and Microsoft's. The irony is exquisite: a project conceived partly to erode Amazon's advantage became a substantial Amazon product line.


The second beneficiary was Red Hat, whose OpenShift distribution turned an open-source kernel into an enterprise platform with support contracts attached — a business good enough that IBM agreed in 2018 to pay $34bn for the company, a deal that closed the following year and was widely read as a bet that hybrid infrastructure would be arbitrated by Kubernetes rather than by any cloud vendor. VMware bought Heptio, the startup founded by two of the three Kubernetes originators, in 2018. Mirantis took Docker's enterprise business off its hands in 2019. Estimates of the resulting market vary wildly: analysts put the Kubernetes platform market at roughly $3bn-4bn in 2026 and project it to double or more by the early 2030s, but figures several times larger circulate for the wider container economy, depending on whether one counts only the platform software or the services wrapped around it. That spread is usually a sign that analysts cannot agree on where a technology ends and the economy begins.


What none of these firms bought was control. Kubernetes releases continue on a three-times-a-year cadence set by a rotating volunteer release team. The v1.36 cycle, which ran for fifteen weeks between January and April 2026, drew contributions from 106 companies and 491 individuals; across the wider ecosystem the figures were 370 companies and more than 2,200 people. That diffusion is the project's principal asset and its principal source of friction. It is also fragile in an underappreciated way: in November 2025 the community announced that ingress-nginx, for years among the most widely deployed components in the ecosystem, would be retired — sustained for years by one or two volunteers working evenings, weighed down by accumulated technical debt, and, after a critical vulnerability the previous spring, no longer safe to leave unmaintained. Best-effort support ended as scheduled in March 2026 and the repository is now read-only. A great deal of critical infrastructure rests on the goodwill of a small number of unpaid people, a condition open source shares with volunteer fire brigades.


What it Runs Now

Three things are being asked of Kubernetes today that its designers did not plan for, and the way it has absorbed them says something about the durability of the underlying model.


The first is artificial intelligence. Training and serving large models is, from the scheduler's point of view, a hostile workload: jobs need many accelerators simultaneously or none at all, they care intensely about which physical devices they land on and how those devices are wired together, and the hardware is scarce enough that idle capacity is a scandal. Kubernetes' original model for accelerators — ask for an integer number of anonymous GPUs — was hopelessly crude, and teams papered over it with node labels and hand-written placement rules.


The answer, Dynamic Resource Allocation, reached general availability in Kubernetes 1.34 in August 2025 and inverts the model in the manner the project usually favours: hardware publishes a structured description of itself, workloads declare what they require, and the scheduler evaluates the match using an expression language. At KubeCon Europe in Amsterdam in March 2026, Nvidia donated its GPU driver for the new framework to the CNCF and Google did the same for its tensor-processing units, which effectively settled the question of whether accelerator scheduling would be a vendor-controlled layer or a common one. Against the risk of fragmentation the community reached for the same instrument that kept Kubernetes itself whole a decade earlier: a conformance programme. Launched at the end of 2025 and tightened at that Amsterdam conference, it obliges distributions claiming AI-readiness to demonstrate it against a shared, published set of requirements.

The second is a migration nobody predicted: virtual machines moving onto Kubernetes. Broadcom's acquisition of VMware — agreed in 2022 at $61bn, nearer $69bn including assumed debt, and completed in November 2023 — and the aggressive licensing that followed sent a large cohort of enterprises looking for exits. Many found KubeVirt, a project that runs conventional virtual machines as Kubernetes objects on the Linux kernel's own hypervisor, and its commercial packaging in OpenShift. The technical merit is real — a single control plane, one deployment pipeline, one set of policies for both containers and legacy virtual machines — but the appeal is chiefly negotiating leverage. Twenty-year-old workloads that will never be rewritten are now being managed by a reconciliation loop designed for stateless microservices.

The third is scope. Kubernetes has been pushed down to the edge, in cut-down distributions running on factory floors, retail sites and cell towers; outward into telecoms, where 5G network functions are packaged as containers; and inward into the enterprise as the foundation for internal developer platforms — the Backstage project, donated by Spotify to the CNCF, builds developer-facing portals atop this machinery. The pattern is consistent. Wherever there is a heterogeneous fleet that must be kept in a described state, the control loop turns out to be the right abstraction, and the container was merely the first thing it was pointed at.


The Bill

Enthusiasts should note that the CNCF's own survey now identifies the leading obstacle to adoption as cultural rather than technical: nearly half of respondents cite change within development teams, ahead of training, security and complexity. That is a mature technology's problem to have. It is not the only one.


Kubernetes makes overspending frictionless. Because resource requests are hard reservations, engineers set them generously to avoid being throttled, and no feedback loop connects that decision to the invoice. The result is clusters that appear full to the scheduler while the underlying machines idle. Cast AI's 2026 analysis of production clusters found workloads using 8% of the processor capacity they had reserved, a fifth of the memory, and — on the accelerators that increasingly dominate the bill — 5% of the GPU. Datadog's cost research reached the same conclusion by a different route as far back as 2024, attributing 83% of container spending to idle resources. An entire cost-optimisation industry now exists to sell the shovels back.


There is also a genre of confessional blog post, perennially popular, in which a startup founder recounts adopting Kubernetes, drowning, and returning to something simpler. The complaints are usually fair. Kubernetes is a distributed system, and operating a distributed system to run three web servers is a category error. A well-run cluster demands expertise that mid-sized firms find expensive and difficult to retain — hence, again, the flight to managed services. The counter-argument is not that Kubernetes is simple but that the complexity is intrinsic to the problem and was previously distributed across bespoke scripts, tribal knowledge and heroic on-call engineers, where it was invisible rather than absent.


Boring is the Point

The most telling statistic in the recent surveys is not the 82% but the composition of the remainder. Most organisations have stopped evaluating Kubernetes and started arguing about how to fund it, staff it and account for it. The technology has passed from the phase where it confers advantage into the phase where it confers nothing at all, and its absence merely costs you.


That is what winning looks like for infrastructure. Nobody boasts about their TCP/IP stack. The Linux kernel, which Kubernetes increasingly resembles in function and in governance, achieved the same invisibility a generation earlier, and for the same reasons: an extensible architecture, a diverse contributor base too broad for any single firm to capture, and a standard that was more valuable to everyone than any proprietary alternative could be to its owner.


The open question is whether the model bends. The workloads arriving now — enormous, hardware-hungry, latency-sensitive, coordinated across thousands of accelerators — look less like the web applications Kubernetes was built for than anything it has previously absorbed, and there is no guarantee that a design optimised for reconciling loosely coupled services will remain the right shape for training runs that must be scheduled as a single indivisible unit. So far the project has absorbed each new demand by generalising rather than by bolting on, which is the harder path and the one that has kept it coherent.


A helmsman does not choose the destination or provide the power. He merely ensures that the ship goes where it has been told to go, and keeps it there when the sea disagrees. It is unglamorous work, and it is why the ship arrives.


Sources

Comments

Rated 0 out of 5 stars.
No ratings yet
Add a rating
bottom of page