KubeCon North America 2026 Recap: AI Inference, Agentic Workloads and What Actually Shipped

Every KubeCon produces a wall of press releases, and most platform teams cannot tell which items they can install on Monday and which are slideware. KubeCon North America 2026, held in Salt Lake City from November 9 to 12, was louder than usual because two new workload classes dominated the agenda: distributed LLM inference and long-running AI agents. Both now have open, CNCF-governed runtimes, and both change how you size clusters.

It matters now because the gap between “announced” and “production ready” is where platform budgets get wasted. Some of this week’s news is a 1.0 release with a stable API. Some is a Sandbox donation that is explicitly “ready for testing”. Some is a 2027 certification that does not exist yet.

You will leave with a verified ledger of what was announced, a clear split between generally available (GA), early and roadmap items, a reference stack, a decision table and a 90-day plan.

What this covers: verified KubeCon 2026 announcements with dates and sources, llm-d 1.0, Agent Substrate, gVisor and OpenShell, CNCF project graduations, AI conformance, the Kubernetes v1.38 timeline, trade-offs and a 90-day action plan for platform teams.

Context and Background

KubeCon + CloudNativeCon is the Cloud Native Computing Foundation (CNCF) flagship conference. The 2026 North American edition ran November 9 to 12 in Salt Lake City, Utah, with Monday given over to eleven co-located events, including Agentics Day: MCP + Agents, Cloud Native AI + Inference Day, ArgoCon, BackstageCon, CiliumCon, Observability Day and Platform Engineering Day, according to the CNCF’s week-in-Salt-Lake-City guide. The main conference ran Tuesday to Thursday, and the event has now concluded.

The programme was shaped months earlier. On August 10, 2026, the CNCF published the schedule and added a new AI Inference + Agentic track covering GPU scheduling, model serving, agentic workflows and observability, with vLLM, KServe, Ray and OpenTelemetry as featured projects. The same release cited the CNCF annual survey: 82% of container users run Kubernetes in production, and 66% of organisations hosting generative AI workloads use Kubernetes for some or all of their inference.

That second number explains the shape of the week. Kubernetes did not win AI inference by design; it won by default because that is where platform teams already had identity, networking, policy and GitOps. The cost has been friction. Pods are slow to create, GPUs are coarse-grained, and the default Service load balancer knows nothing about KV caches or token budgets. We covered the inference side of that friction in our deep dive on llm-d and prefill/decode disaggregation, and the scheduling side in Kubernetes 1.37 gang scheduling versus Volcano and Kueue.

Agents add a third kind of friction. An interactive agent session is mostly idle: it waits on a model, an external API or a human. Google’s open source team put the waiting share at 90% to 95% of a session in its November 5 announcement. A Pod per session wastes resources, while scale-to-zero serverless wakes too slowly. Agents also run untrusted, model-generated code, so isolation is not optional.

My thesis for this recap is narrow and testable. KubeCon 2026 did not produce one big launch. It produced the first credible open layering of the AI platform: accelerators and Dynamic Resource Allocation (DRA) at the bottom, an inference router above vLLM, an actor-based agent runtime on top, and conformance programmes trying to hold it together. Your job for the next 90 days is to adopt the mature layers and pilot the young ones, without confusing the two.

The Verified Ledger: KubeCon 2026 Announcements by Status

Direct answer: The verified KubeCon 2026 announcements fall into three tiers. Shipped: llm-d 1.0 (October 20), Agent Substrate 1.0, Solo.io’s GA enterprise Agent Substrate and kagent, the CKNE certification and KubeVirt’s graduation. Early: Sandbox donations of gVisor, OpenRL and OpenShell. Roadmap: Kubernetes v1.38 on December 16, 2026, and two AI certifications in 2027.

Figure 1: The KubeCon North America 2026 ledger. Items are grouped by what a platform team can actually run today, not by how loudly they were announced.

The figure sorts every item in this post into three columns. The left column holds things with a release number, a stable API or a GA label from the vendor. The middle column holds projects that exist and run but sit at CNCF Sandbox maturity or carry “ready for testing” language. The right column holds dated plans. Read any KubeCon coverage, including this one, by asking which column an item belongs in.

A note on method. Every item below links to a primary source: a CNCF press release, a project or vendor blog, or a named trade publication when no primary page was available. Dates are publication dates of those sources. Where a figure comes from a vendor and has not been independently reproduced, I say so.

Foundation-level news: graduations, incubations and the portfolio

On November 10 the CNCF published its annual milestones release. It states the portfolio now holds 231 projects, with 32 added over the past year, and puts the cloud native developer community at about 21.2 million. Eight companies joined as Platinum members over the year: Adyen, Broadcom, CoreWeave, CVS, HAProxy, NVIDIA, OVHcloud and Vultr.

The same release lists six graduations over the past year: Cloud Native Buildpacks, Karmada, Kubeflow, KubeVirt, NATS and OpenTelemetry. Five projects advanced to Incubating: CloudNativePG, K8gb, Meshery, Open Cluster Management and HAMi, the heterogeneous accelerator sharing and scheduling project. These are cumulative annual numbers, not all announced this week, so treat the list as a status snapshot rather than breaking news.

The one graduation announced at the show was KubeVirt. The CNCF’s November 10 KubeVirt release gives the history: created by Red Hat in 2016, accepted to Sandbox in September 2019, Incubating since April 2022. It reports 2,088 contributors from 520 organisations and names ByteDance, Cloudflare, CoreWeave and NVIDIA as production adopters. KubeVirt v1.9 brought GPU claims through DRA to beta, and confidential VM support is uneven by platform: IBM Secure Execution GA, AMD SEV and SEV-SNP beta, Intel TDX alpha and Arm CCA in development.

Graduation is a governance signal, not a feature release. It means the project passed a third-party security audit, has a formal steering committee and has demonstrated adoption. For a platform team weighing VM consolidation after licensing changes elsewhere, that is the bar procurement usually asks for. Our KubeVirt versus VMware vSphere migration analysis covers the architecture in depth.

Inference: llm-d 1.0 is the headline that actually shipped

llm-d is a Kubernetes-native distributed inference framework built on vLLM and the Kubernetes Gateway API Inference Extension. Its CNCF project page records Sandbox acceptance on March 12, 2026, and lists inference scheduling, prefix-cache-aware routing, prefill/decode disaggregation, hierarchical KV offloading and hardware-aware autoscaling, with support for NVIDIA, AMD, Intel and Google TPU accelerators.

Version 1.0 landed on October 20, 2026, three weeks before KubeCon, and was a centrepiece of the CNCF’s November 10 messaging. Techzine’s coverage and SiliconANGLE’s KubeCon report agree on the 1.0 additions: multi-tenant quality of service through priority and fairness flow control, router high availability with a hot standby, prefill and decode replicas managed and upgraded as one logical unit, a stable v1 configuration API, session-aware routing for multi-turn agents, and Responses API support.

Note what kind of release that is. Almost nothing on the list is a new inference trick; disaggregation and cache-aware routing existed before. The 1.0 work is Day 2 operations: upgrades, failover, tenancy and a configuration contract you can put in GitOps without fearing the next minor version. That is exactly what platform teams need before they let a router sit in front of revenue traffic.

The project also published performance claims, reported by Techzine: a run of a roughly 753-billion-parameter mixture-of-experts model peaking above 6.6 million output tokens per minute and supporting up to 3,000 concurrent coding agents without preemption. These are project-reported figures on project-chosen hardware and workloads. I have not seen an independent reproduction, so use them as evidence that the design scales, not as a capacity number for your cluster.

Agent runtimes: from Pods to actors

The most architecturally interesting news was about agents. On November 5, Google announced it is donating Agent Substrate and gVisor to the CNCF at Sandbox status, alongside OpenRL, and that Agent Substrate has reached 1.0. Agent Substrate is an actor-based control and data plane on Kubernetes. Actors hold per-session state; Workers are pre-warmed Pods in a shared WorkerPool. Google states a restore target under 500 milliseconds, using gVisor to checkpoint memory pages to tiered storage and restore them on another node.

On November 10, Solo.io, which co-maintains Agent Substrate with Google, made enterprise Agent Substrate and kagent generally available, naming OutSystems and Swissquote as production launch customers. The enterprise builds use agentgateway to enforce identity and policy on each actor’s ingress and egress.

NVIDIA’s OpenShell, a secure runtime for autonomous agents that governs file, network, credential and model-endpoint access, was listed by the CNCF as a new Sandbox project. Red Hat is integrating it into Red Hat AI and OpenShift sandboxed containers, according to SiliconANGLE. Separately, the CNCF milestones release lists KubeRay as a new contribution, and SiliconANGLE reports that Broadcom’s VM API project entered the CNCF Sandbox on November 9.

Standards and skills: conformance and certifications

The CNCF says the Kubernetes AI Conformance Program has reached 40 certified platforms, up from 31 reported in March 2026. The March update made Kubernetes v1.35 alignment mandatory, including stable in-place Pod resize and workload-aware scheduling, and added agentic workload validation. On October 29 the Kubernetes blog reported that AI Conformance has moved from a working group to a SIG Architecture subproject.

On skills, the CNCF launched the Certified Kubernetes Network Engineer (CKNE) with immediate availability: a 120-minute performance-based exam weighted 25% service networking and DNS, 25% network security and policy, 20% advanced traffic management, 15% CNI and 15% observability. Two further certifications, Kubernetes AI Associate (KAIA) and Certified Kubernetes Inference Engineer (CKIE), are planned for 2027 and do not exist yet.

The ledger in one table

Item	Who	Status at KubeCon	Date	Source
llm-d 1.0	llm-d project, CNCF Sandbox	Released, stable v1 config API	Oct 20, 2026	Techzine, CNCF
Agent Substrate 1.0	Google, Solo.io	Released, open source, donated to Sandbox	Nov 5, 2026	Google Open Source Blog
Enterprise Agent Substrate and kagent	Solo.io	GA, commercial	Nov 10, 2026	Cloud Native Now
gVisor, OpenRL	Google	Donated at Sandbox status	Nov 5, 2026	Google Open Source Blog
OpenShell	NVIDIA	New CNCF Sandbox project	Nov 10, 2026	CNCF
KubeVirt	CNCF	Graduated	Nov 10, 2026	CNCF
CKNE certification	CNCF, LF Education	Available now	Nov 10, 2026	CNCF
AI Conformance	CNCF, SIG Architecture	40 certified platforms	Nov 10, 2026	CNCF
Kubernetes v1.38	Kubernetes release team	Roadmap, code freeze Nov 17	Dec 16, 2026 target	kubernetes.dev
KAIA and CKIE	CNCF	Roadmap	2027	CNCF

Table 1: Verified announcements by status. “Released” means a versioned open source release; “GA” is the vendor’s own commercial label.

Walk-through: The AI Platform Stack That Emerged This Week

Individually, the announcements look like a list. Stacked, they describe a reference architecture for running inference and agents on Kubernetes, with an open project at nearly every layer. Figure 2 shows that stack and where each KubeCon item lands.

Figure 2: The open AI platform stack as of November 2026. Accelerators are exposed through DRA, batch and gang work goes through workload-aware scheduling, inference flows through the Gateway API Inference Extension and llm-d to vLLM, and agent sessions run as actors on a sandboxed worker pool.

Read the figure from the bottom. GPUs and other accelerators are exposed through Dynamic Resource Allocation, the structured replacement for opaque device-plugin counts; our DRA GPU scheduling guide explains the claim model. Sharing layers such as HAMi or NVIDIA MIG sit beside DRA. Above that, the scheduler places gangs of Pods for training and multi-node serving. The serving layer is vLLM behind llm-d. The agent layer is Agent Substrate on gVisor or microVMs, with OpenShell-style policy inside the sandbox. A gateway enforces identity on both inference and agent traffic, and OpenTelemetry observes all of it.

The inference request path, step by step

The most useful way to understand llm-d 1.0 is to follow one request. Figure 3 traces a multi-turn agent call through the stack.

Figure 3: A session-aware inference request. The endpoint picker scores replicas on cache locality and load, prefill runs on one pool, the KV cache moves to a decode replica, and tokens stream back through the gateway.

First, the client or agent sends a request to a Gateway API gateway. The Inference Extension hands routing to an endpoint picker, which in llm-d is a scheduler that scores candidate replicas. Scoring uses prefix-cache affinity, queue depth and, new in 1.0, session identity so that turn N+1 of a conversation lands near turn N’s cached context. Flow control then applies tenant priority and fairness before the request is admitted.

Second, a prefill replica processes the prompt. Prefill is compute-bound and runs in parallel across all prompt tokens. Its output, the key-value (KV) cache, is transferred to a decode replica. Decode is memory-bandwidth-bound and produces one token per step per sequence. Separating the two lets each pool use different parallelism and hardware.

Third, decode streams tokens back. If the KV cache does not fit in GPU memory, hierarchical offloading spills it to CPU memory or storage instead of evicting it. Brian Stevens of Red Hat summarised the benefit to SiliconANGLE as the ability to independently scale input processing and token production.

Why session-aware routing matters for agents is simple arithmetic. Assume, purely for illustration, an agent loop whose conversation grows to 40,000 tokens of context by turn ten, and each new turn adds 1,000 tokens. With cache-blind round-robin over eight replicas, a turn usually lands on a replica without that prefix and must recompute roughly 40,000 tokens of prefill. With session affinity and a warm cache it computes about 1,000. That is a 40x difference in prefill work for that turn. Real hit rates depend on cache capacity and eviction, but the shape explains why the 1.0 release prioritised it. Our post on inference SLOs, TTFT and goodput shows how that prefill saving shows up as time-to-first-token.

The agent actor model, with worked numbers

Agent Substrate’s actor model is the most important design idea from the week, because it rejects the obvious mapping of one agent to one Pod. Consider an illustrative fleet of 10,000 concurrent agent sessions. If each holds a dedicated Pod requesting 0.5 vCPU and 1 GiB of memory, the cluster reserves 5,000 vCPU and roughly 10 TiB of memory around the clock.

Google says agents spend 90% to 95% of a session waiting. If only 5% to 10% of sessions are executing at any instant, a warm worker pool of 500 to 1,000 slots, plus headroom for bursts, can serve the same fleet. Idle sessions live as snapshots in tiered storage, not as running Pods. Even with 2x burst headroom, that is 1,000 to 2,000 slots instead of 10,000 Pods, an 80% to 90% reduction in reserved compute. These are illustrative numbers; your duty cycle is the variable to measure first.

The control-plane effect matters as much as the cost. Ten thousand Pods means ten thousand objects in etcd, constant churn through the API server and ten thousand Pod IP addresses. Google’s post names etcd, kube-apiserver and subnet IP exhaustion as the bottlenecks that Pod-per-sandbox designs hit. Actors are placed into existing worker slots without creating Pod objects, so the Kubernetes control plane sees a stable pool.

The catch is restore latency. The design only works if a parked session wakes fast enough that users do not notice. Google targets under 500 milliseconds, against more than 20 seconds that it reports for typical serverless scale-to-zero. Treat 500 milliseconds as a vendor target; measure it on your storage tier before you design a user experience around it.

Isolation is now a layered decision

gVisor intercepts system calls in a user-space kernel, so untrusted model-generated code never talks directly to the host kernel. Agent Substrate also supports Cloud Hypervisor microVMs under the same API for workloads that need hardware virtualisation or custom kernel modules. OpenShell adds application-level policy inside the boundary: which files, networks, credentials and model endpoints an agent may touch.

These layers answer different questions. The sandbox answers “can this code escape to the host?” The policy runtime answers “is this agent allowed to call that endpoint with that credential?” Our comparison of Firecracker, gVisor, WebAssembly and container isolation for agent code covers the escape side. Identity is the other half; see our guide to agent identity and delegated authorization.

Kubernetes itself: v1.37 is current, v1.38 is next

No Kubernetes minor release shipped at KubeCon; the project releases on its own cadence. Kubernetes v1.37, “Garhwal”, was announced on August 26, 2026 with 67 enhancements: 16 stable, 23 beta and 27 alpha. Follow-up posts covered workload-aware scheduling, DRA updates and HPA scale-to-zero at beta.

The v1.38 release schedule targets Wednesday, December 16, 2026. Code and test freeze fall on November 16 AoE, the Monday after KubeCon, and docs freeze on December 3. If you need a feature in v1.38, its fate is decided by now. Do not plan around v1.38 features until the release blog confirms what graduated.

The end-user signal: Meta and GitOps at AI scale

The CNCF End User Case Study Contest went to Meta on November 11. According to the CNCF release, Meta’s Cloud Foundation team delivers applications across about 100 Kubernetes clusters supporting AI research and inference using Argo CD and Kargo, with Terraform kept for infrastructure only. Routine application deploys fell from more than four hours to minutes.

The lesson is not “use Argo”. It is that AI clusters fail on boring coupling: application releases waited on infrastructure release cycles. Separating the two lifecycles delivered the win, not any AI-specific tool.

Decision table: what to do with each announcement

Announcement	Maturity signal	Adopt now if	Pilot if	Wait if
llm-d 1.0	1.0, stable v1 config API, CNCF Sandbox	You run vLLM on 4+ replicas with shared prefixes	You serve one model on 1 to 3 replicas	You buy inference from a managed API only
Agent Substrate 1.0, open source	1.0, newly donated to Sandbox	Never straight to production without a pilot	You run thousands of mostly idle agent sessions	Your agents are batch jobs or few in number
Solo enterprise Agent Substrate and kagent	Vendor GA, named customers	You need support, air-gapped installs and SLAs now	You are evaluating vendors	You want a pure upstream stack
gVisor for agent code	Mature runtime, new to CNCF	Agents execute model-generated code	Syscall-heavy tools need benchmarking	Workloads need GPU passthrough inside the sandbox
OpenShell	New Sandbox	Not yet	You need per-agent file, network and credential policy	You lack a sandbox layer underneath
KubeVirt	Graduated	You are consolidating VMs onto Kubernetes	You need confidential VMs on Intel TDX or Arm CCA	Your VM estate depends on hypervisor features KubeVirt lacks
AI Conformance	40 certified platforms	You are choosing a managed Kubernetes for AI	You build your own distribution	Never ignore it in procurement

Table 2: Decision table for platform teams. Thresholds such as “4+ replicas” are rules of thumb, not measured cut-offs.

A 90-Day Action Plan for Platform Teams

The plan below assumes a typical platform team: a few Kubernetes clusters, some GPU nodes, at least one internal LLM workload and early agent experiments. It runs from mid-November 2026 to mid-February 2027, which conveniently straddles the Kubernetes v1.38 release.

Figure 4: The 90-day plan as three gated phases. Each phase ends with a measurable gate; failing a gate loops back rather than pushing forward.

Days 1 to 30: inventory and baseline

Start by measuring, because every decision in Table 2 depends on numbers you probably do not have. Record, per inference service: replica count, GPU type, requests per second, prompt and output length distributions, time to first token (TTFT) at p50 and p99, and the share of requests with a shared prefix. For agents, record session count, session length and the fraction of wall-clock time each session spends executing versus waiting.

The duty cycle is the single most important number from this week. Google’s 90% to 95% waiting figure is a general claim; your coding agent with long tool calls might be 60%, and a chat-style agent might be 98%. Instrument with OpenTelemetry spans around model calls and tool calls; our post on OpenTelemetry GenAI semantic conventions gives the attribute names.

Also in this phase, check whether your managed Kubernetes provider is on the AI Conformance list for your version, and read the Kubernetes v1.38 release notes when they land on December 16. Gate: you can state your prefix-sharing ratio and agent duty cycle with real data.

Days 31 to 60: pilot the inference router

If you run vLLM with four or more replicas and see meaningful prefix sharing, stand up llm-d 1.0 in a staging namespace in front of a copy of one production model. Keep the existing Service path live and mirror or split a small slice of traffic. Compare TTFT, inter-token latency, cache hit rate and GPU utilisation at equal load.

Test the Day 2 features the 1.0 release is selling. Kill the active router and confirm the hot standby takes over. Perform a rolling upgrade of a prefill/decode pair. Configure two tenants with different priorities and flood the low-priority one. If any of these fail in staging, you have found the issue cheaply. Our KServe vs Ray Serve vs BentoML decision record helps decide what stays the model-lifecycle layer above the router.

In parallel, if you have agent workloads, run Agent Substrate in a sandbox cluster. Measure actual restore latency on your storage class and the maximum actor activations per second before the controller saturates. Gate: llm-d beats the baseline on at least one target metric without regressing p99 TTFT, and actor restore stays inside your user-experience budget.

Days 61 to 90: decide, harden, document

Promote what passed. Put the llm-d configuration in Git under the v1 API, add alerts on cache hit rate and flow-control queue depth, and write a runbook for router failover. For agents, decide between upstream Agent Substrate with your own support model and a commercial distribution; that is a staffing decision as much as a technical one.

Harden isolation before widening agent access. Run agent code in gVisor or microVMs, apply default-deny egress, and issue each agent a scoped workload identity rather than a shared API key. Finally, write an architecture decision record per adopted layer so the next team knows why. Gate: every production change has an owner, a rollback path and an SLO.

Trade-offs, Gotchas, and What Goes Wrong

Sandbox is not a quality label. CNCF Sandbox means a project has been accepted for neutral governance, not that it is production ready. llm-d is a Sandbox project with a 1.0 release; Agent Substrate is a 1.0 release newly donated to Sandbox. Those are positive signals, but your support story is you, unless you buy one.

Vendor numbers are not your numbers. The llm-d throughput claims and the sub-500-millisecond restore target are published by the people who built the systems, on chosen models, hardware and workloads. Throughput depends on model architecture, quantisation, context length and output length. Benchmark on your traffic shape.

Cache affinity fights load balancing. Session-aware routing pins conversations to replicas that hold their cache. Under skewed traffic, a few hot replicas can queue while others idle. The scheduler balances cache score against load, but the weights matter, and a bad configuration can raise p99 latency while improving average throughput.

Disaggregation moves the bottleneck to the network. Prefill/decode separation transfers KV caches between Pods. For large models and long contexts that is gigabytes per request at high rates. Without RDMA-capable networking or careful placement, transfer time eats the gain. This is one reason the CKNE weighting toward traffic management and DNS is timely.

Actor snapshots expand the blast radius of storage. When session state lives in tiered storage, a slow or failed storage tier stalls every waking agent at once. Snapshots also contain whatever the agent held in memory, including secrets and user data, so encryption and retention policy must cover them.

The gVisor tax is real for some tools. User-space syscall interception adds overhead for syscall-heavy workloads such as compilers and package installs. GPU access from inside a gVisor sandbox has its own constraints. Profile your actual agent tools before standardising.

Release-train coupling. Kubernetes v1.38 arrives December 16, and managed providers trail upstream. Do not schedule an llm-d or DRA change that depends on a v1.38 feature until your provider offers that version.

Practical Recommendations

The overarching recommendation is to separate decisions by maturity. Adopt layers with a stable API and a support path. Pilot layers that are new to the CNCF. Ignore roadmap items until they ship. The conference made it easy to blur these, and blurring them is how teams end up rebuilding in six months.

For inference, llm-d 1.0 is the most production-relevant open release of the week, but only for teams operating vLLM at a scale where routing matters. If you run one or two replicas, a well-tuned vLLM deployment behind a normal Service is simpler and probably fine.

For agents, the actor model is the right mental model even if you do not adopt Agent Substrate. Stop designing one long-lived Pod per agent session. Measure the duty cycle, then size a warm pool to the active fraction.

For skills, the CKNE is available now and maps well onto the networking failure modes of disaggregated inference. KAIA and CKIE are 2027 plans; do not budget training around them yet.

Checklist:

[ ] Measure prefix-sharing ratio and agent duty cycle before buying anything.
[ ] Check your Kubernetes platform against the AI Conformance list for your version.
[ ] Pilot llm-d 1.0 in staging and test failover, rolling upgrades and tenant QoS.
[ ] Benchmark actor restore latency on your own storage class.
[ ] Run model-generated code in gVisor or microVMs with default-deny egress.
[ ] Give each agent a scoped workload identity, never a shared key.
[ ] Read the Kubernetes v1.38 release notes on December 16 before planning features.
[ ] Write an ADR for every layer you adopt.

Frequently Asked Questions

When and where was KubeCon North America 2026 held?

KubeCon + CloudNativeCon North America 2026 ran November 9 to 12, 2026, in Salt Lake City, Utah. Monday, November 9, was dedicated to eleven CNCF co-located events, including Agentics Day: MCP + Agents, Cloud Native AI + Inference Day, ArgoCon, BackstageCon and Platform Engineering Day. The main conference with keynotes, breakouts, maintainer tracks and the Solutions Showcase ran Tuesday to Thursday. The CNCF said session recordings would be published within about two weeks of the event, so expect them on the CNCF YouTube channel in late November.

What were the biggest KubeCon 2026 announcements?

The most consequential were in AI infrastructure. llm-d, the CNCF Sandbox distributed inference framework, had reached 1.0 on October 20 with production controls such as tenant QoS and router high availability. Google donated Agent Substrate, gVisor and OpenRL to the CNCF Sandbox, and Solo.io made enterprise Agent Substrate and kagent generally available. NVIDIA’s OpenShell joined the Sandbox. KubeVirt graduated, the CNCF launched the CKNE networking certification, and the AI Conformance Program reached 40 certified platforms.

Is llm-d production ready?

llm-d 1.0 is the project’s first release with a stable v1 configuration API and Day 2 operational features: router hot standby, coordinated upgrades of prefill and decode replicas, and priority and fairness flow control. That makes it reasonable to pilot for production. Remember that it is a CNCF Sandbox project, which signals neutral governance rather than a maturity audit. Commercial support is available through distributions from its founding companies. Benchmark it against your current vLLM setup on your own traffic before switching.

What is Agent Substrate and how is it different from running agents in Pods?

Agent Substrate is an open source, actor-based runtime on Kubernetes that reached 1.0 and was donated by Google to the CNCF Sandbox in November 2026. Each agent session is an actor holding state; execution happens in pre-warmed worker Pods shared across actors. Idle sessions are snapshotted to storage and restored, with a stated target under 500 milliseconds. This avoids keeping one Pod per idle session, which strains etcd, the API server and Pod IP space at large scale.

Which CNCF projects graduated in 2026?

The CNCF’s November 10, 2026 milestones release lists six graduations over the past year: Cloud Native Buildpacks, Karmada, Kubeflow, KubeVirt, NATS and OpenTelemetry. KubeVirt’s graduation was the one announced at KubeCon North America itself. The same release lists CloudNativePG, K8gb, Meshery, Open Cluster Management and HAMi as advancing to Incubating. Graduation requires a third-party security audit, a defined governance model and demonstrated production adoption, so it is a useful procurement signal.

When is the next Kubernetes release?

Kubernetes v1.38 targets Wednesday, December 16, 2026, according to the release team’s schedule on kubernetes.dev. Code and test freeze fall on November 16 (Anywhere on Earth) and docs freeze on December 3. The current release is v1.37 “Garhwal”, announced on August 26, 2026, with 67 enhancements. No Kubernetes minor release was launched at KubeCon, since releases follow their own fixed cadence of roughly three per year.

KubeCon North America 2026 Recap: AI Inference, Agentic Workloads and What Actually Shipped for Platform Teams