On the second afternoon of Open Source Summit Europe 2026 in Prague, I sat down for a Udienza interview with two people who see the whole CNCF landscape from the inside:
- Bob Killen, Director of Technical Program Management at the CNCF.
- Daniel Krook, Senior Director of Developer Experience at the CNCF. In his words, he and his team, Bob included, make sure the projects hosted by the CNCF “are happy, have what they need to thrive”: support, credits, docs and all the other benefits of being in the foundation.
With the CNCF team after the recording.
The conversation went from project numbers to the most concrete explanation I have heard of why AI agents stress Kubernetes. Below are the highlights. Quotes come from our recording and are lightly edited for clarity. The audio does not always make it clear which of the two was speaking, so where it is ambiguous I attribute the point to both.
About 230 projects, and growing every week
I opened by asking how big the CNCF has become. Daniel put it at about 230 hosted projects, with a few more voted in but still completing the process. They expected to pass 240 within a couple of weeks.
The breakdown they gave:
- About 40 graduated projects, the most mature level.
- About 40 incubating projects, which are “building momentum”.
- The rest in sandbox, plus a group of archived projects that were cycled out when they became less relevant or were replaced by something else.
Archiving is a healthy signal, not a failure. A foundation that never retires projects is not curating.
Who decides what is “good”: the TOC
I asked how they decide which projects have a good signal. The answer was that it is not the CNCF staff. It is the Technical Oversight Committee (TOC):
“It’s an elected group from the governing board, from the project maintainers, from the end users, that helps determine the criteria of what a project needs to go from sandbox to incubating, and incubating to graduated.”
The TOC has eleven members from different companies, each bringing “their unique insight into what makes a good project, what makes it healthy, and what it needs to become a dependable piece of critical infrastructure.”
This matters for the neutral governance theme of the week: the people who decide maturity are elected and spread across companies, not appointed by the biggest sponsor.
Best practices for every maintainer
My next question was what they would recommend to any maintainer. The answer pointed to the CNCF TAG Contributor Strategy, which publishes best practices and templates for:
- a strong code of conduct, and enforcing it,
- proper licensing,
- governance, so the project is transparent and people can see how to contribute and join,
- documentation.
There was also a practical tip I had not thought about. The sandbox application is a public GitHub issue in the cncf/sandbox repository. You can read the template, see what the TOC asks for (how a project relates to others, what problem it solves, how it fits the ecosystem) and study other projects’ applications before you ever apply. That makes it a free checklist for any open source project, CNCF or not.
Kubernetes as the AI operating system
When I asked what is most interesting right now, the answer was the shift that the CNCF has been describing all year: Kubernetes as the AI OS. Kubernetes has become the default base layer, and a wave of newer projects solves specific problems on top of it: routing, gateways, model serving, and splitting up hardware.
“There’s no one stack, but there’s a lot of projects solving particular areas within that logical stack.”
Because the landscape now lists around a thousand entries, the CNCF also collects reference architectures contributed by end-user members. Each one describes the end user’s stack, why they built it that way, and the decisions they made. If the landscape overwhelms you, those are the place to start.
Why agents break Kubernetes assumptions
This was the part of the interview I keep thinking about. The explanation was simple and numeric.
A human works at human speed: one request, wait for the answer, next request. With agents:
“One human makes one action, and that triggers 20 agents. So for each human request you have something like 20 agent requests.”
That changes the load profile completely. Then the latency problem:
“With a pod in Kubernetes, the guarantee of spinning one up is about one second. With agents, you’re looking for sub-200 millisecond response times. That doesn’t work too well when you only have a guarantee of one second for spinning up a pod.”
Kubernetes was not designed for that workload. The answer is a new set of projects that keep warm capacity and multiplex many agents onto it. Two were named:
- llm-d, for distributed LLM inference on Kubernetes. I covered it in llm-d at the CNCF.
- Agent Substrate, a runtime for large-scale agent deployments. According to its CNCF sandbox application, it multiplexes many agents onto a smaller pool of ready worker pods, checkpoints idle agents and resumes them in under a second, and supports microVM and gVisor isolation.
Isolating agents and giving them identity
The next topic was security. As they explained, recent sandbox reviews included several projects for isolating agents. One example is gVisor, which has isolated containers for years and is now being extended specifically to isolate agents.
I raised credentials and authentication, which keep coming up whenever agents act on behalf of users. Their examples:
- OpenShell (from NVIDIA), as a way of declaring what an agent can and cannot do.
- SPIFFE and SPIRE, the established CNCF projects for machine identity, which can tie a workload’s identity to the authenticated user who initiated the request.
This lines up with what I saw elsewhere in Prague: the AWS keynote on identity, policy, limits and audit, and the Edera, Coder and OpenBao conversations on isolation and secrets.
The future: more load, and better use of scarce hardware
Asked where this is heading, the comparison was with mobile phones. When phones became pervasive, communication became pervasive, then apps did, and load grew everywhere. AI will do the same: more load from more non-traditional clients, with much finer granularity in how that load is routed and how hardware is split.
“A lot of the interesting innovation at CNCF is this software layer over all this scarce hardware: making better use of these investments and meeting that agent load.”
The example was a project whose entire purpose is to slice GPUs and other devices and hand the right-sized share to whatever requests it. From the description, this matches HAMi, the heterogeneous GPU virtualisation project that the TOC accepted as incubating in July 2026. The idea is to look at an agent’s actual requirements and map it to the right slice of hardware, instead of giving every request a whole GPU.
KubeCon, KCDs and a global community
We also talked about how global the community has become. KubeCon now runs in Europe, North America, Japan, India and China. Both of them were enthusiastic about Kubernetes Community Days (KCDs): one day of material, run by the local community. Their advice: if you cannot get to a KubeCon, look for a KCD near you. If you want the current state of the world, go to KubeCon. The next one is KubeCon + CloudNativeCon North America in November.
Advice for people starting in cloud native
My last question was for people entering the industry now, when the amount of innovation can be overwhelming. The advice was refreshingly practical:
“You’ve got to get hands-on. Just pick something. It doesn’t matter if it’s the most popular. Find a problem you think this stuff is going to solve, maybe build some local inferencing on your machine, and try a couple of different options.”
And a warning I have seen play out many times in my own consulting work:
“A lot of people new to the space jump right into Kubernetes, or the tools running on top of it, without understanding the primitives, and that sets them up for failure downstream.”
Learn containers before Kubernetes, and Kubernetes before the platforms on top of it. Each layer makes sense only if you understand the one below.
What’s next at the CNCF
To close, I asked about the latest news. The picture they described is a full end-to-end AI stack forming on top of Kubernetes, with gaps being filled by open source projects now arriving at the CNCF: OpenShell, Agent Substrate and gVisor were all mentioned. The next step is to see which reference architectures emerge from teams running those stacks successfully.
My takeaways
- Agent load is a scheduling problem. Twenty requests per human action and a sub-200 ms budget do not fit a one-second pod startup. Plan for warm pools and multiplexing.
- Identity is the hard part of agent security. Isolation (gVisor, Kata, microVMs) is necessary, but tying each agent action to a real identity, with SPIFFE/SPIRE and policy, is what makes it auditable.
- GPU slicing is now mainstream. With HAMi in incubation and Kubernetes DRA maturing, “one request, one GPU” is a cost bug.
- Use the CNCF’s free material. The TAG Contributor Strategy templates and the public sandbox applications are a maintainer’s checklist.
The full conversation will be published as an episode on udienza.com. Thank you, Bob and Daniel, and thanks to the Linux Foundation and CNCF PR team for setting it up. For more CNCF context, see my KubeCon interview with CNCF CTO Chris Aniszczyk.
