Standing in the Shanghai venue in 2026, I found myself thinking about the days eight years ago when Dan Kohn and I organized the first KubeCon China.
In September 2026, KubeCon + CloudNativeCon returned to mainland China once again, back in Shanghai. The full name of the event has grown much longer than before: this time it also included the OpenInfra Summit and PyTorch Conference, with agent- and MCP-focused events running alongside.
The longer name is not a trivial detail. It is almost a microcosm of the technological shifts of the past few years: cloud native is no longer the only protagonist on stage, AI has pushed its way into the spotlight, and Kubernetes, OpenStack, and various cloud native projects are repositioning themselves within the AI technology stack.
For me, this return carried a more personal layer of meaning.
It All Started in Shanghai, 2018
The first KubeCon China was in 2018, also in Shanghai. Dan Kohn came to China back then to discuss and plan the event with us. Kubernetes was still expanding rapidly in those years; many people were hearing the term “Cloud Native” for the first time, and our hottest topics were containers, microservices, service mesh, and whether Kubernetes would become the data center operating system of the future.
More than 2,500 people attended that conference, a record for a first international KubeCon at the time. I still remember clearly how Dan looked on stage, in the venue, and at community events.
Dan later passed away from illness. Today, the KubeCon scholarship program is named after him. Seeing the Dan Kohn Scholarship again in Shanghai, I could not simply treat it as one more program name on the conference website. For me, it connects to a group of real people and to the earliest days of China’s cloud native community.
Eight years on, Kubernetes no longer needs to prove that it can run in production. It has long been part of the infrastructure. Yet the center of the technology world is shifting as well. The question of those years was “how do applications run on Kubernetes”; today the question has become “how does AI run more efficiently and more reliably on top of heterogeneous computing power”.
What I Saw at the HAMi Booth
This time I was mainly responsible for the HAMi booth. Besides meeting many old friends I had not seen in years, one immediate impression was that there were more international attendees than I expected.
At the HAMi booth in particular, my sense was that more than half of the visitors came from overseas. Of course, this is just one person’s observation at a single booth and does not represent the overall attendee mix of the conference. But it still says something: when it comes to GPU scheduling, sharing, and heterogeneous computing management, Chinese projects are drawing global developers who actively want to learn more.
The Todea team from Korea wrote a very detailed recap after the event, summarizing the shared theme of the conference as “recovering capacity from the same hardware”. That phrasing matches what I felt at the booth. The questions people asked about HAMi were no longer just “can Kubernetes recognize GPUs”, but how to partition GPUs, how to improve utilization, how to run training and inference in the same cluster, and how to manage different accelerators such as NVIDIA, Ascend, Cambricon, and Hygon.
This means the GPU has gone from being an add-on device to a first-class resource that the Kubernetes control plane must understand.
The Todea recap also documented several production cases. China Merchants Bank put training and inference on a shared Kubernetes foundation, raising average accelerator compute utilization from 35% to over 60%; INTSIG improved GPU utilization and reduced costs through GPU partitioning, bin-packing scheduling, affinity rules, and elastic scaling; and the case from Viettel in Vietnam was even more direct — under the same workloads and service levels, utilization per card rose from 13% to 59%.
These numbers come from each team’s presentations at the conference; the scenarios and measurement criteria are not identical, so they cannot be compared side by side directly. But together they point to one shift: the primary question of AI infrastructure is moving from “do we have GPUs” to “how much useful work are our existing GPUs actually doing”.
China’s Cloud Native Community Has Not Disappeared - It Has Sunk Beneath the Surface
If you only listen to social media, you might think cloud native in China has cooled off compared with a few years ago. Startup pitch decks have changed their labels, marketing budgets have flowed to large models and agents, and many people who used to work on cloud native have started studying inference, GPUs, vector databases, and AI platforms.
I am one of them. Over the past few years I have gradually shifted my focus to AI infrastructure, working on adapting GPUs to Kubernetes. Only after making that turn did I realize that this was not leaving cloud native — it was following cloud native deeper into computing resources.
The “State of Cloud Native Development in China” report released by the CNCF and SlashData during the conference painted a different picture. As of Q1 2026, China has about 1.75 million cloud native developers, of whom roughly 400,000 also work on AI development. The share of cloud native among Chinese backend developers has grown from 30% two years ago to 48%.
Another statistic feels distinctly Chinese: 48% of China’s industrial IoT developers are cloud native developers, above the global average of 42%. Manufacturing, telecommunications, energy, and hardware are the industries where Chinese developers are more concentrated; these systems often need to run for long periods and strongly favor private, controlled infrastructure. Cloud native in China has never simply meant public cloud — it increasingly lives in on-premises data centers, dedicated clouds, edge nodes, and industry platforms.
So I would rather put it this way: cloud native in China has not disappeared — it has sunk beneath the surface. It has gone from a novel concept to the default engineering approach for many systems, and internal developer platforms have hidden it even further. According to the report, 88% of backend developers worldwide already work in some form of standardized DevOps or platform environment. A developer may use a Kubernetes-based platform every day without ever needing to write a Dockerfile, configure container networking, or operate a cluster.
When infrastructure becomes invisible, its voice in public discourse grows quieter, while its responsibility in production systems only grows heavier.
Why the CNCF’s Presence in China Has Changed
This conference left me feeling that the CNCF’s presence in China has not simply grown stronger or weaker — its nature has changed.
KubeCon China 2018 had a very clear center: Kubernetes and the CNCF. At that time China was the world’s third-largest source of contributions to CNCF projects, and Chinese companies joining the foundation, donating projects, and becoming top contributors were the biggest news of the event.
In 2026, China remains the world’s second-largest source of contributors to CNCF projects. Code contributions have not disappeared, and Kubernetes has not lost its place in production. But this event needed to share a single stage with OpenInfra and PyTorch to fully express today’s technical demands. Infrastructure, container orchestration, model frameworks, and agent systems have been chained together into one story that no single foundation can tell alone.
This raises a question: now that cloud native has become the default foundation, can the CNCF keep defining the questions that the next generation of developers cares about most?
In China, this question is especially practical. Technology decisions at Chinese companies are increasingly shaped by heterogeneous chips, data compliance, private deployment, and local supply chains. Community members still contribute code, but the day-to-day connection between the foundation and local developers is harder to maintain than the contribution numbers in project repositories. A conference can bring one concentrated reunion; real presence comes from year-round local content, user case studies, maintainer growth, and cross-language collaboration.
If the CNCF only emphasizes that “Kubernetes still matters”, that is of course true, but it is no longer enough. What matters more is explaining clearly how Kubernetes takes on AI’s new workloads, and how Chinese developers and domestic hardware can genuinely enter global standards and upstream communities.
The AAIF Brings More Than Just a New Foundation
At the end of 2025, the Linux Foundation established the Agentic AI Foundation (AAIF), with Anthropic’s Model Context Protocol (MCP), Block’s goose, and OpenAI’s AGENTS.md among its first projects. In less than a year, a new open source narrative has taken shape around agent protocols, tool calling, context management, and collaboration standards.
The impact of the AAIF on the CNCF is not that agents will replace Kubernetes. What it is really competing for is developer attention, vendor budgets, and the entry point to standard-setting.
Ten years ago, a developer who wanted to help build the next generation of infrastructure most likely started with containers, Kubernetes, and cloud native. Today, a young developer is more likely to start with LLM APIs, MCP, agent frameworks, and AI coding tools. The first interface they care about is no longer the Kubernetes API, but how models call tools, how agents exchange context, and how to control permissions and costs.
That is also why this edition of the conference placed agent- and MCP-focused events in the same week as KubeCon. Agentic AI is forming its own community center, and its boundary with cloud native has not yet stabilized.
I do not believe the CNCF and the AAIF will end up in a zero-sum competition. The AAIF sits closer to the protocol layer and the developer entry point for agents, while the CNCF is better at governing long-running distributed systems. Once an agent truly enters production, it still runs into identity, isolation, networking, policy, observability, resilience, and multi-tenancy problems — precisely the problems the cloud native community has solved again and again over the past decade.
But cooperation will not happen by itself. Who defines the runtime unit of an agent, who manages state, who standardizes identity and telemetry data, and who owns the security boundary — these questions will all shape how future projects and foundations divide the work.
Agentic AI Is Rewiring Kubernetes in Return
We used to say that Kubernetes is a general-purpose orchestration platform. Agentic AI will force us to re-examine the words “general purpose”.
Traditional web service workloads are relatively stable: a Pod starts and keeps handling requests, and CPU and memory can roughly describe its resource needs. An agent, by contrast, may start suddenly, call several external tools, wait on model inference, save its context, and then go dormant or terminate. It resembles both a short-lived task and a stateful long-runner; it needs sandbox isolation, yet it must also access external systems on the user’s behalf.
This puts several new kinds of pressure on Kubernetes.
The first is the resource model. Training, inference, and agent workloads can no longer be described by “how many GPUs” alone. Video memory, compute ratios, interconnect topology, model caches, and domestic heterogeneous accelerators all need to enter scheduling decisions. HAMi and Dynamic Resource Allocation (DRA) address the layer of this pipeline closest to the device.
The second is the workload model. A single LLM inference replica may no longer be one Pod but a group of Pods coordinating across nodes. Prefill/decode disaggregation, gang scheduling, LeaderWorkerSet, and multi-cluster scheduling all show that the original Deployment abstraction is no longer sufficient to express AI systems.
The third is security and governance. An agent does not just respond to requests — it takes actions. It needs its own identity, fine-grained authorization, network egress control, tool-call auditing, and recoverable execution records. Simply stuffing each agent into a Pod does not automatically solve these problems, but Kubernetes’ ServiceAccounts, policy engines, sandbox runtimes, and observability stack provide a foundation that can keep evolving.
The CNCF and SlashData report also shows that AI developers follow a different cloud native maturity path. They first build data pipelines with Kubernetes, microservices, event-driven architecture, and observability tooling; then rely on immutable infrastructure to make training reproducible; and only after moving into production inference do they need service mesh, chaos engineering, and multi-cluster management more.
This ordering shows that AI is not just another new workload on top of cloud native. It is reordering the priorities of cloud native technology.
The Value of Community Is Still People
Technology trends can be summarized from reports and agendas, but the truly irreplaceable part of a conference remains the people.
This time I met many old friends I had not seen in years. Some still work on Kubernetes; some have moved on to gateways, large models, agents, or GPU chips; others have changed roles and companies several times over. We talked about past projects, and about the new problems each of us faces today.
I have come to believe more and more that a community is not a group of people who forever discuss the same technology. A real community is one where, after the technology cycle turns, those same people are still willing to come back with new questions.
In 2018, we believed Kubernetes would transform infrastructure. In 2026, we are judging whether Kubernetes can support AI’s transformation of software. The questions have changed, and so have the people, but the way of building trust through open source and collaborating across companies has not.
When Dan pushed to bring KubeCon to China, its greatest significance was never just hosting a conference. He helped build a bridge between Chinese developers and the global open source community. Today, that bridge needs to carry more than cloud native — it also needs to connect chips, models, inference systems, and agent protocols.
Conclusion
If I had to sum up KubeCon China 2026 in one sentence, I would say: cloud native has not left the stage — it is losing the center of the stage while becoming the foundation the entire stage stands on.
China’s cloud native community still has scale, production practice, and sustained upstream contributions; its participants have simply dispersed into AI infrastructure, heterogeneous computing, platform engineering, and agent systems. The challenge for the CNCF is to reconnect these new directions. The impact of the AAIF reminds everyone that the entry point for the next generation of open standards may have already shifted from container orchestration to the protocols between agents and tools.
For Kubernetes, this is both pressure and a second chance. It does not need to become an agent framework, nor own the entire AI technology stack. What it needs to do is turn GPUs, networking, identity, isolation, state, and observability into a reliable production foundation, so that AI workloads can run at scale the way microservices do today.
For me personally, this return to Shanghai felt like recalibrating my coordinates. Looking back, I can still vividly picture Dan planning the first conference with us; looking forward, I have already devoted more of my energy to combining GPUs with Kubernetes. The world changes fast, but as long as the community is still willing to reunite, discuss, and build together, the road from the past into the future is still there.
References
- KubeCon China 2026: Capacity Recovered From The Same Hardware - Todea
- The State of Cloud Native Development in China Report - CNCF
- KubeCon + CloudNativeCon, OpenInfra Summit and PyTorch Conference Unite in China to Scale AI - CNCF
- Linux Foundation Announces the Formation of the Agentic AI Foundation - Linux Foundation
- A look back at KubeCon + CloudNativeCon Shanghai 2018 - CNCF
- CNCF Statement on the Passing of Dan Kohn - CNCF
