We no longer ask “can Kubernetes run AI?” We ask: once AI is running, who manages it, and who is accountable for it?
My calendar has been packed with conferences lately. At the end of October I co-ran a HAMi GPU sharing workshop at ContainerDays Singapore 2026. For the upcoming COSCon'26 and KCD Hangzhou 2026, I reviewed part of the proposals. And tomorrow, November 10, KubeCon + CloudNativeCon North America 2026 opens in Salt Lake City.
Over the past decade I have attended many cloud native conferences and watched Kubernetes, service mesh, observability, GitOps, and platform engineering go from new ideas to the mainstream. But reading these agendas side by side this year, one feeling was stronger than ever: the cloud native stack we know is being handed a very different kind of work.
This post puts the four conferences together and shares what I see changing.
Four conferences, four angles
Start with the figure. Using the public agendas available on November 9, I roughly counted each conference’s focus by session title keywords.
ContainerDays Singapore brought the topic close to developers. Of 64 sessions, 22 had titles about agents and tooling: sandboxes for coding agents, fine-grained authorization for MCP tools, and how teams run evals, all on the same agenda.
KubeCon North America was the most direct. CNCF added a new AI Inference + Agentic track; 45 of the 174 sessions across the 11 topic tracks sit in it, about 26%. That doesn’t count DRA-based GPU sharing in the Platform Engineering track or AI-assisted troubleshooting in the Observability track.
COSCon'26 had the widest scope. Beyond agents, model distribution, and hardware isolation, it covers youth open source, RISC-V, and open source law. AI is not only reshaping infrastructure; it is seeping into open source collaboration, education, and community governance.
KCD Hangzhou was the most focused. Its three tracks, Agent Infra, AI Infra & LLM Serving, and AI Observability & Reliability, map almost exactly to the core questions of AI native infrastructure today: how agents run, how inference stays efficient, and how the system stays reliable. 22 of its 25 sessions had titles matching AI infrastructure keywords.
These numbers only describe agenda structure. They can’t rank conferences or measure year-over-year growth, since each event is positioned and categorized differently. But one thing is clear: AI has moved from being one application area at cloud native conferences to being the thread that organizes the agenda.
From deploying AI to running AI
AI/ML already showed up at KubeCon in 2023, and in 2024 and 2025 we talked a lot about running training and inference on Kubernetes. In 2026 the questions go much deeper: which instance should an inference request go to? How do we split GPUs and memory? How do we reuse the KV cache? What isolation does an agent need when it executes code? Where does a task resume after an interruption?
Kubernetes’ original abstractions (Pod, Deployment, Service, HPA) were built around stateless microservices: replica counts, resource requests, service discovery, failure recovery. AI workloads bring different requirements. Scheduling must consider device topology, memory capacity, sharing, and isolation, not just CPU and memory. In inference serving, prefill and decode have different compute profiles, KV cache placement affects routing, and model load time directly determines cold-start latency. High GPU utilization does not mean throughput, latency, and cost are optimal.
That is why DRA, HAMi, Kueue, Volcano, KServe, llm-d, and vLLM are worth following. They live at different layers: some manage devices, some orchestrate workloads, some manage inference requests. They are not substitutes for each other; together they are exploring the new control boundaries of AI infrastructure. In the CNCF 2025 annual survey, 66% of the responding organizations that host AI workloads use Kubernetes for some or all of their inference. Reusing the cloud native foundation is already a fact.
Put simply, we used to schedule containers and compute; now we also have to understand the execution semantics of models, requests, caches, and tasks. Kubernetes is not being replaced. The infrastructure on top of it is being redesigned.
Hand an on-call shift to an agent
If LLM serving changes how resources are used, agents may change even more.
Imagine you are on call and a service suddenly slows down. You ask an agent to read the logs, diff recent changes, and suggest a fix. If it misses a deploy from twenty minutes ago, its conclusion goes off track. That context normally lives scattered across the release system, the service catalog, and team chat. One SRE talk at KubeCon North America says in its abstract that missing context was the first wall they hit when bringing AI into troubleshooting.
Go one step further and let it run the rollback, and the question is no longer “is the answer right?” Whose identity does it use? Which environments can it roll back? Will a timeout retry run the rollback twice? If its suggestion contradicts the on-call engineer, who decides?
This reminds me of early cloud native. When we first put apps in containers, we thought running was enough. Then we discovered we also needed service discovery, configuration, identity, and observability. Agents are going through something similar, except their behavior is more dynamic and has direct side effects on external systems. That is why agent sandboxes, checkpoint/restore, tool authorization, and task traces keep showing up on the Singapore and Hangzhou agendas.
I believe an increasingly important field will emerge over the next few years: Agentic Runtime, runtime infrastructure for executing agent tasks. It needs clear boundaries across the task lifecycle, environment isolation, permission control, state recovery, and observability. That said, I don’t think we should rebuild everything. Containers, sandboxes, identity, network policy, and controllers remain highly reusable. The key is telling apart the problems that already have answers from those that genuinely need new abstractions.
Observability is in the same position. A trace tells you which tools an agent called and where it failed, but not necessarily whether the task met the user’s goal. Healthy infrastructure and a successful task are no longer the same thing. Reliability will need SRE, observability, model evaluation, and task auditing working together.
Tasks can be delegated, accountability cannot
The technology is changing, and so is how we work.
AI produces first drafts faster and faster, and many people feel they can do more at once. But if someone has to re-understand every change afterward, the team has only moved the queue from “waiting for someone to write” to “waiting for someone to review.” An agent can write tests for me, but I still need to know what they cover. It can produce a rollback command, but I still need to know which command affects users.
Open source maintainers feel this most concretely. The bar for opening a PR is dropping, but maintainers don’t get more hours. One PR with reproduction steps, a failing test, and a design rationale may be worth more than ten unverified generated PRs. We need to rethink how we measure a “useful contribution.”
The same goes for developer relations. At the Singapore workshop we had already designed the labs to run on a local kind cluster without real GPUs, yet some attendees still got stuck on dependency installs and OS differences. From the maintainer’s side the demo works; from the user’s side they may not have taken the first step. AI can generate more complete tutorials, but it can’t replace watching real developers use your project. I wrote up the details in What a GPU Workshop Reveals About the Developer Experience Gap in Cloud Native Infrastructure.
Open interfaces matter more than short-term hype
Looking at the four events together, different communities enter AI infrastructure from their own strengths. Singapore sits close to developer tooling and security. KubeCon North America extends Kubernetes through standards work such as DRA, the Gateway API Inference Extension, and the OpenTelemetry GenAI semantic conventions. The Chinese community shows deep low-level work on heterogeneous GPU compute, inference optimization, and agent sandboxes, and is actively contributing to these projects.
I don’t want to rank regions based on a few agendas. The more important question is whether these efforts can flow into one open ecosystem. A key reason cloud native succeeded over the past decade is that developers worldwide collaborated openly around Kubernetes and CNCF. If every model platform demands its own runtime, tool protocol, and resource management stack, AI could repeat the fragmentation of early cloud computing.
Three things I want to track next year
First, how inference teams measure the compute they save. GPU utilization is easy to show; I would rather see latency, failed retries, and cost measured together on the same real workload.
Second, whether agents can move from read-only checks to narrowly scoped write operations while leaving records someone else can pick up.
Third, whether open source projects start tracking the cost of verification and maintenance, for example how long it really takes from receiving a change to completing a meaningful review.
Summary
The four conferences send the same signal: cloud native is not obsolete, but the workloads it carries have changed. The focus is shifting from “deploying AI on Kubernetes” to “running and managing AI”: device allocation, inference routing, agent permissions and recovery, and task-level observability and evaluation are each growing new problems.
For engineers, the change is not only architectural. Tasks can be handed to agents, but acceptance criteria, permission boundaries, and incident handling must move from personal experience into agreements the whole team can inspect. A year from now, the simplest test of whether an AI workflow has really entered a team may still be the handoff: when the person who owns it is on vacation, can someone else read the records, understand what happened, and know at which step to stop it?
References
- CNCF Reveals KubeCon + CloudNativeCon North America 2026 Schedule - cncf.io
- KubeCon + CloudNativeCon North America 2026 Schedule - linuxfoundation.org
- ContainerDays Singapore 2026 Agenda - containerdays.io
- COSCon'26 Agenda - bagevent.com
- KCD Hangzhou 2026 - community.cncf.io
- KCD Hangzhou 2026 Agenda - sessionize.com
- Dynamic Resource Allocation - kubernetes.io
- Introducing Gateway API Inference Extension - kubernetes.io
- OpenTelemetry GenAI Semantic Conventions - github.com
- CNCF Annual Survey Report - cncf.io
- What I Saw at COSCon'25: The Real State of Open Source in China - jimmysong.io
