The Evolution of Kubernetes (Part 2): Neutral Governance, Cloud Co-optation, and the Age of AI

On July 21, 2015, Kubernetes 1.0 was officially launched at OSCON in Portland. That very day, Google made a decisive announcement: it would donate the Kubernetes trademark and project assets in their entirety to the newly formed Cloud Native Computing Foundation (CNCF) under the Linux Foundation.

At the time, this move was often interpreted as open-source idealism or a clever PR posture. Yet looking back across a decade, it stands as the most critical strategic gambit in cloud history—transforming a zero-sum battle over “whose orchestrator” would win into a shared reality: “everyone’s orchestrator.”

Part 1 examined how Kubernetes emerged victorious from the three-year container orchestration wars. Part 2 turns to the story of “what happened after winning”: how an ownerless community governed a global cloud standard, how the cloud hyperscalers shifted from resistance to co-optation, the persistent debates over complexity and repatriation, and the seismic shift ushered in by AI workloads after 2023.

1. The Politics of Donation: The CNCF and the Wisdom of Neutrality

To grasp the strategic intent behind this donation, the essential question is: what did Google actually surrender, and what did it receive in return?

On the surface, Google surrendered substantive ownership of the project—relinquishing trademarks, intellectual property, and governance to the foundation. In reality, Google bought something far more valuable: the wholehearted buy-in of the entire software industry.

During the fever pitch of the orchestration wars, neutrality was the ultimate anchor. AWS’s decision to launch EKS, Microsoft’s commitment to throw its core engineering muscle behind the project, and Docker’s eventual concession to integrate K8s into Docker Desktop all rested on a single prerequisite: the project they were investing in no longer belonged to a direct competitor.

Google traded ownership of an open-source project for architectural path dependency across the entire container ecosystem. Crucially, because that dependency was anchored in a neutral foundation, even Google enjoyed no special privileges.

The CNCF subsequently became the fastest-growing organization under the Linux Foundation umbrella. As its inaugural project, Kubernetes became the first to pass review and officially graduate on March 6, 2018, signaling that its production readiness, governance maturity, and adoption scale had set the industry benchmark.

According to official DevStats 10-year metrics, the CNCF ecosystem has expanded to roughly two hundred projects, engaging over 240,000 contributors and more than 7 million developers.

The costs and mechanics of neutrality were etched into the finest details. Once the trademark was transferred, even Google’s own GKE had to strictly adhere to community release cadences, unable to unilaterally dictate technical specifications.

Filling that vacuum were the CNCF Technical Oversight Committee (TOC) and the Certified Kubernetes Conformance Program. Any cloud provider wishing to use the Kubernetes trademark had to pass the exact same suite of end-to-end conformance tests.

This certification proved a masterstroke in open-source governance: it turned “compatibility” into an essential badge of quality, while rendering proprietary forks commercially untenable.

2. A Governance Experiment Without a Boss: SIGs, KEPs, and Release Culture

Donating the project to a foundation resolved the question of legal ownership, but everyday collaboration immediately faced an existential test: when primary contributors come from multinational corporations competing fiercely in the market, how do daily decisions actually get made?

Kubernetes answered with a three-tiered organizational architecture:

 Kubernetes Three-Tier Governance Structure

 +--------------------------------------------------------+
 | Steering Committee (7 Members, Annual Community Vote)  |
 | Governs charter, conflicts, and SIG leadership         |
 +--------------------------------------------------------+
                            |
                            v
 +--------------------------------------------------------+
 | SIGs (Special Interest Groups: Network, Node, etc.)    |
 | Domain-driven collaboration, public meetings & notes   |
 +--------------------------------------------------------+
                            |
                            v
 +--------------------------------------------------------+
 | KEP Process (Kubernetes Enhancement Proposals)         |
 | Motivation -> Risk Analysis -> Test Plan -> GA         |
 +--------------------------------------------------------+

The first tier is the Steering Committee. Governance proposals were finalized in 2017. Steered by an initial governance committee featuring cross-industry leaders such as Sarah Novotny and Brendan Burns, an elected community representation model was codified through the first community election completed in October 2017.

The committee focuses on defining community charters, arbitrating disputes, and overseeing elections—strictly upholding the maxim that “governors must also be governed” while consciously refraining from intervening in concrete technical architectures.

The second tier consists of SIGs (Special Interest Groups), which divide the project into dozens of domain-specific areas such as networking, storage, scheduling, node, and release engineering. All SIG meetings and meeting notes are entirely open to the public; an engineer’s contribution is credited to their domain expertise rather than their corporate employer.

The third tier is the KEP (Kubernetes Enhancement Proposal) process, formalized in early 2018. Any major feature or architectural overhaul must be documented through a proposal detailing motivation, alternatives, risk analysis, and a progressive graduation/test plan. Only after rigorous review by the relevant SIG can it be merged into the codebase.

Release engineering reflects another dimension of this maturity. In earlier years, a quarterly release cadence pushed global maintainers and users to exhaustion. After extending the support window to one year with v1.19 in 2020, the project formally shifted in April 2021 to a cadence of three releases per year.

Each release is managed by dozens of volunteers through a structured “shadow” apprentice program, ensuring institutional knowledge and release management expertise are passed down systematically across generations of contributors.

This decentralized governance successfully shepherded several monumental architectural refactorings and standardizations:

• v1.13 (December 2018): Promoted kubeadm and the CSI (Container Storage Interface) to GA, and designated CoreDNS as the default cluster DNS.
• v1.22 (August 2021): Pruned a vast collection of long-deprecated beta APIs, redefining the API lifecycle policy.
• v1.24 (May 2022): Completely removed dockershim, the legacy built-in Docker compatibility layer, from kubelet.
• v1.31 (August 2024): Concluded the multi-year effort to remove in-tree cloud provider code—purging roughly 1.5 million lines of vendor-specific code and shrinking the core binary footprint by nearly 40%.

This massive architectural spring cleaning offers tangible proof that “neutrality” was not merely a slogan, but a principle written directly into clean code.

3. The Cloud Co-optation: From Resistance to “Kubernetes-as-a-Service”

On the commercial front, what followed was an unprecedented “co-optation movement” in tech history.

Google drew first blood: it launched Google Container Engine in 2015 and rebranded it as Google Kubernetes Engine (GKE) in 2017, making K8s an explicit cloud product brand.

Red Hat executed the most decisive pivot: as early as June 2015, Red Hat scrapped the traditional PaaS architecture of OpenShift and rebuilt OpenShift 3 entirely atop Kubernetes and Docker. The rollout of OpenShift 4 in 2019 cemented it as a premier enterprise-grade Kubernetes platform.

Microsoft announced Azure Kubernetes Service (AKS) in October 2017. AWS, following mounting community pressure, announced Amazon EKS at re:Invent in November 2017, reaching general availability on June 5, 2018. With that, all three hyperscale public clouds had completed their managed Kubernetes fleets.

A wave of acquisitions swept through enterprise infrastructure next. Heptio, founded in 2016 by Kubernetes co-founders Joe Beda and Craig McLuckie, was swiftly acquired by VMware in late 2018, later merging with Pivotal to form the Tanzu portfolio. Meanwhile, Rancher Labs, a pioneer in multi-cluster management, was acquired by SUSE in 2020.

A clear commercial consensus emerged among industry giants: stop trying to reinvent proprietary orchestration standards; instead, invest in or acquire the innovation ecosystem built on top of Kubernetes.

Kubernetes had evolved into the “PCI bus” of the cloud era—no single vendor could leverage its control over the project to extract monopoly rents, yet every giant relied on it as a counterweight to its rivals.

The expansion of community gatherings mirrored this co-optation wave: the inaugural KubeCon in San Francisco in November 2015 drew just a few hundred attendees. By 2019, KubeCon North America in San Diego saw nearly 12,000 attendees, and KubeCon Europe in Amsterdam topped 10,500 in 2023. From intimate developer meetups to industry carnivals tens of thousands strong, Kubernetes had firmly anchored itself as the bedrock of modern infrastructure.

4. The Reality of Adoption: Truths and Methodologies in the Metrics

Interpreting technology adoption data requires vigilance, because methodological criteria and survey framing often dictate wildly divergent conclusions.

In the CNCF 2023 Annual Survey, 84% of respondents reported they were “using or evaluating” Kubernetes, whereas the share explicitly running it in production was 66%. In the 2024 survey, that production adoption figure climbed further to approximately 80%.

Media headlines routinely flattened “84%” into “84% of enterprises run K8s in production,” glossing over an eighteen-percentage-point gulf between “evaluating” and “live in production.”

 CNCF Survey Adoption Metrics (Disambiguation)

 2023 Survey:
 [======================== 84% Total ===================]
 [============== 66% Production ==============] [18% Eval]

 2024 Survey:
 [======================== ~80% Production =============]

Even through the narrower lens of 66% to 80%, the broader takeaway remains undeniable: Kubernetes is no longer an emerging technology under trial; it has become the default backdrop of modern infrastructure.

The 2024 DORA Report similarly highlighted that a staggering 89% of organizations have adopted some form of Internal Developer Platform (IDP)—the overwhelming majority of which are architected on top of Kubernetes. The report also issued a caveat: the link between platform engineering and organizational performance is far more nuanced than conventional wisdom assumes.

When a technology matures into a utility-grade substrate, criticizing it feels as futile as criticizing TCP/IP: listeners nod in sympathetic agreement, and then turn right around to deploy their next workload onto it.

5. Critiques and Repatriation: Cracks in the Empire

Throughout its ten-year reign, critiques and pushback against Kubernetes have never ceased. Analyzing these perspectives reveals three primary battlegrounds:

1. Inherent Complexity and the Cost of Abstraction

A steep learning curve, runaway YAML sprawl, and grueling debugging chains—these grievances have dogged the project since the 1.0 era, and most remain valid.

Even the CNCF’s official blog acknowledged in 2023 that “Kubernetes storage is complex.”

The canonical example is the Ingress resource: the 1.0 era provided only a rudimentary L7 HTTP routing specification. When real-world deployments required header matching, weighted traffic splitting, or canary rollouts, controller vendors were forced to patch the gaps with proprietary annotation dialects, fracturing cross-cloud portability.

It took the community years of redesign to introduce the Gateway API (which achieved 1.0 GA in 2023) to steadily consolidate traffic management standards.

Yet the flip side of complexity is this: much of it is the engineering tax paid to deliver on the promise of consistent behavior across every underlying infrastructure.

2. “A Platform for Building Platforms”: Not the Endgame

Renowned former Google Developer Advocate Kelsey Hightower captured this ethos in a widely quoted tweet on November 27, 2017:

Kubernetes is a platform for building platforms. It’s a better place to start; not the endgame.

This insight catalyzed the modern platform engineering movement: organizations should not force application developers to confront raw Pods, CRDs, and labyrinthine networking rules. Instead, they should encapsulate Kubernetes beneath abstractions tailored to internal developer workflows.

Far from diminishing Kubernetes, Hightower’s critique reinforced its indispensability as the foundational bedrock of cloud computing.

3. Repatriation Narratives: Deconstructing the “Exit”

The most prominent rebellion in recent years was the “cloud exit” spearheaded by 37signals (the company behind Basecamp and HEY), announced in late 2022 and completed in 2023.

Led by DHH, this migration shifted their entire production workload from the public cloud back onto self-managed bare-metal hardware, slashing their annual cloud bill from roughly $3.2 million to$1.3 million. Crucially, 37signals did not deploy Kubernetes on their bare metal; they built Kamal, a lightweight open-source deployment tool, to manage containers directly.

Yet the technical boundary must be drawn clearly: 37signals rebelled against the premium pricing and soaring rental costs of public cloud hyperscalers, not the architectural premise of container orchestration.

Genuine cases of teams “abandoning Kubernetes” mostly involve organizations whose scale never warranted it in the first place, but who prematurely adopted sprawling clusters. This represents a pragmatic course correction from architectural over-engineering, not an unraveling of the industry standard.

6. The AI Era: A New Crown and a New Arena

As 2023 unfolded, the explosion of generative AI opened an entirely new chapter: Kubernetes rapidly cemented itself as the de facto substrate for massive-scale AI computing infrastructure.

The architectural rationale is crystal clear: the core requirements of modern AI training and inference clusters—scheduling heterogeneous accelerators (GPUs, TPUs), managing complex batch job lifecycles, and adapting to dynamic network topologies—align squarely with the strengths of the Kubernetes control plane.

In record time, the open-source community and cloud giants assembled a comprehensive, AI-native scheduling matrix:

 Kubernetes Modern AI Workload Ecosystem

 +------------------------------------------------------+
 | Workload Layer: PyTorch, Ray, vLLM, Training & LLMs  |
 +------------------------------------------------------+
                            |
                            v
 +------------------------------------------------------+
 | Orchestration & Serving: Kueue, Volcano, KServe      |
 +------------------------------------------------------+
                            |
                            v
 +------------------------------------------------------+
 | Kubernetes Core: Job API, DRA (Dynamic Resources)    |
 +------------------------------------------------------+
                            |
                            v
 +------------------------------------------------------+
 | Driver & Hardware Layer: NVIDIA GPU Operator, ASICs  |
 +------------------------------------------------------+

• Kueue: Delivers advanced hierarchical queueing, dynamic resource quotas, and fair sharing mechanisms, establishing itself as the primary solution for multi-tenant teams sharing scarce, high-cost GPU clusters.
• Volcano: Enhances distributed AI training with critical all-or-nothing (gang scheduling) capabilities, ensuring multi-node workloads launch only when all required resources are simultaneously allocated—preventing deadlocks and idling costly compute.
• KubeRay: Deeply integrates the Ray distributed computing framework into the Kubernetes ecosystem.
• KServe: Provides a standardized, highly scalable model inference serving plane (accepted into the CNCF as an Incubating project in 2025).
• NVIDIA GPU Operator: Encapsulates low-level GPU drivers, the Container Toolkit, and telemetry metrics directly into Kubernetes Custom Resource Definitions (CRDs).

History found its rhyme in 2025: at KubeCon Atlanta on November 11, 2025, the CNCF officially unveiled the Certified Kubernetes AI Conformance program.

Much as the 2015 software conformance program neutralized container fragmentation, the AI compute ecosystem established portability as a certified benchmark across clouds and accelerators via nine community test suites. Early conforming platforms included Gardener, OpenShift, and RKE2.

A decade ago, Kubernetes scheduled lightweight web pods. A decade later, it schedules high-performance GPU nodes carrying price tags in the hundreds of thousands of dollars.

The economic value of scheduled resources surged by orders of magnitude—yet the underlying declarative philosophy remains untouched.

7. Fact-Checking Enduring Narratives

To untangle the folklore and historical trivia accumulated across the community, the key fact-checking conclusions of this series are summarized below:

8. Conclusion: A Series of Contingent Choices

Looking back across the past decade, observers frequently drape Kubernetes’ success in an aura of “technological inevitability”—as if superior architecture alone guaranteed its sweeping victory.

Yet the granular reality of history was forged by a succession of high-risk, counterintuitive, and profoundly contingent choices:

• A rogue pitch on a Google commuter shuttle that greenlit the project’s inception;
• A seemingly self-sabotaging donation of open-source crown jewels to a neutral foundation;
• A meticulous, ostensibly cumbersome, yet radically fair governance structure that united fierce competitors;
• A strategic co-optation playbook that brought rivals onto a single shared playing field.

Architectural elegance was necessary, but the core engine sustaining Kubernetes’ decade-long reign was always the delicate equilibrium between open governance and commercial incentives.

For modern engineers crafting YAML, debugging reconciliation loops, and deploying operators each day, the value of understanding this history lies in recognizing that every API invocation and declarative manifest at our fingertips is more than mere code—it is the institutional crystallization of a decade of rivalry, compromise, and collective evolution.