The Kubernetes community spent 2025 building the infrastructure for running AI workloads. It arrives at KubeCon North America 2026 in Salt Lake City this week carrying a question the infrastructure cannot yet answer: when an AI agent inside a cluster takes a consequential action, can you prove which one did it?

That question — not the GPU scheduling debates, not the inference framework releases, not the sponsor announcements — is the organizing tension of this year's conference. It has no clean answer yet. The sessions, the hallway conversations, and the working-group side meetings that run alongside the main program this week will collectively map how far the cloud-native community thinks it can push toward one. For prior context on where the community stood at KubeCon Japan 2026 coverage six months ago, that inflection point is worth reviewing before reading what has changed since.

The conference runs November 9–12 at the Salt Palace Convention Center. The main program opens Tuesday. Monday is co-located day.

The Co-Located Day

The Cloud Native AI Inference Day is the headliner of this year's co-located programming — a new addition to the KubeCon North America schedule that reflects how much has changed in one year. Where previous years folded AI-adjacent sessions into existing tracks, this year's organizers gave inference and agentic workloads their own day before the main program opens.

The day's sessions cover the full stack: LLM serving, agent orchestration, observability for inference pipelines, and the protocol interoperability work happening at the edges of the cloud-native and AI tooling ecosystems. Projects represented include llm-d inference framework, KServe model server, the OpenTelemetry project, Model Context Protocol, and work from the CNCF AI Technical Group. The NVIDIA DSX OS AI Inference and Contributor Workshop also runs alongside the co-located programming.

Robotics + Physical AI on Kubernetes Day also runs Monday for teams exploring how the same scheduling and orchestration primitives that manage cloud workloads can extend to edge devices, robotic platforms, and physical AI deployments.

The conference's official schedule lists both co-located events in full.

The Identity Crisis

Every AI agent running inside a Kubernetes cluster needs an identity. Right now, it probably does not have one of its own.

The Kubernetes workload identity standard — SPIFFE identity standard and the SPIRE project, its reference implementation — works by assigning a cryptographic credential to a service account. That is the right architectural choice for the workloads SPIFFE was designed to serve: a database pod, a web server, an API gateway. Each of those services runs many instances, but those instances are functionally identical and interchangeable. When one takes an action, it does not matter which replica it was. What matters is what service took the action.

AI agents are not like that. An agent that has been running for six hours in one conversational context, that has accumulated tool call history, retrieval results, and intermediate reasoning across a long task, is not functionally identical to an agent that just started in a fresh context — even if both run from the same container image under the same service account. When an agent calls an external API, writes to a database, or takes any action with downstream consequences, the question of which specific agent instance did it is not incidental. It is the question.

The architectural mismatch runs deeper than configuration. Solo.io's August 2026 analysis of the problem characterized the gap as "a fundamental mismatch with agents' non-deterministic, context-dependent behavior" — a shorthand for the problem that the credential model assigns identity to a slot in an infrastructure topology, not to a running reasoning process with its own accumulated state.

The numbers that frame the stakes: According to NHI Management Group research, 72 percent of organizations now have more non-human identities than human ones in their environments, and that ratio is accelerating as AI agent deployments scale. A separate finding from Teleport found that 70 percent of organizations grant AI systems more access than humans in an equivalent role. The combination — more machine identities than human ones, most of them over-privileged, and a credential infrastructure that cannot distinguish individual agent instances — describes an audit and accountability gap that the cloud-native community has not yet closed.

Proposals being discussed at KubeCon this week include per-instance SPIFFE identities minted at agent startup and rotated at context boundaries, supplementary token formats carrying session-scoped identity alongside the workload credential, and tighter integration between agent orchestration frameworks and SPIFFE-aware service meshes. None of these has achieved consensus. That consensus work is happening in the hallways and working groups this week.

llm-d 1.0

The concrete milestone that arrived immediately before KubeCon is the v1.0 release of llm-d inference framework. Released on October 20 at PyTorch Conference North America, llm-d 1.0 represents the first production-stability release of the Kubernetes-native distributed LLM inference framework that joined the CNCF Sandbox in March 2026.

The project's co-maintenance model spans IBM Research, Red Hat, Google Cloud, CoreWeave, and NVIDIA — an unusually broad set of contributors for a project still in Sandbox. That breadth reflects how urgently each of those organizations wants a Kubernetes-native answer to the distributed inference coordination problem: how to route inference requests across a fleet of GPU-backed pods in a way that maximizes hardware utilization, respects KV-cache locality, and handles the statistical unpredictability of token generation latency.

IBM Research published llm-d benchmark results showing throughput gains on Qwen3-32B running across eight vLLM pods on sixteen H100 GPUs. The results are specific enough to give platform teams a baseline, but the more significant v1.0 signal is the stability commitment: production users can now depend on the API surface without expecting breaking changes in minor releases.

The comparison with KServe, the more established model-serving framework, is a live debate that multiple sessions will address this week. KServe is a broader framework covering model storage, versioning, and multi-framework serving; llm-d is narrower, optimized specifically for the LLM inference path, and built from the ground up with the Kubernetes scheduler as a first-class citizen rather than a deployment target to work around.

The Gateway Layer

The Gateway API Inference Extension reached general availability at v1.5.0 on April 19, 2026, and arrives at KubeCon North America as a production-ready component of the Kubernetes inference serving stack.

The extension adds two custom resource definitions — InferencePool and InferenceModel — to the Kubernetes API. InferencePool groups the pods that serve a given model family. InferenceModel represents a specific model with its deployment parameters and routing rules. Together, they give the Kubernetes control plane enough semantic context about inference workloads to make routing decisions that raw TCP/HTTP load balancers cannot make: preferring pods with the right model already loaded, routing around pods under memory pressure from large KV caches, and distributing load in ways that account for the token-generation characteristics of the specific model in use.

The Gateway Inference Extension v1.4.0 conformance work established the conformance framework that made v1.5.0's GA designation possible. Multiple implementations now pass the conformance suite, which means teams are no longer locked to a single gateway vendor to get the inference-aware routing behavior. The practical implication for the enterprise teams sending engineers to this week's conference: the routing layer is no longer experimental infrastructure. It is a component you can standardize on.

GPU Scheduling

The GPU scheduling landscape arriving at KubeCon North America 2026 looks different from what the community saw at KubeCon Japan in July. What was a two-way conversation between Kueue quota scheduler and Volcano scheduling framework is now a three-way contest, with NVIDIA KAI Scheduler — a CNCF Sandbox project optimized for AI workload gang scheduling — establishing itself as a serious alternative for teams whose workloads are predominantly LLM training and inference rather than general batch.

The core tension: Kueue was designed around resource quotas and admission control, which makes it well-suited for multi-tenant clusters where fair sharing is the primary scheduling objective. Volcano was designed around batch fairness and gang scheduling, which makes it well-suited for distributed training jobs that need all pods to start simultaneously or not at all. KAI Scheduler is narrower still, optimized for the specific scheduling requirements of AI inference workloads where GPU memory topology, KV-cache state, and model loading latency all affect scheduling quality in ways general-purpose schedulers do not model.

Workload-Aware Scheduling (WAS) is a fourth approach being discussed in sessions this week, addressing workload-specific placement signals that the other schedulers treat as opaque.

The integration that may matter most for practical adoption is not between competing schedulers but between scheduling and hardware allocation. Red Hat Build of Kueue 1.4 integrates with Dynamic Resource Allocation (DRA), which reached GA in Kubernetes 1.34 in August 2025. DRA changes how Kubernetes models specialized hardware: instead of treating GPUs as countable resources like CPU cores, DRA exposes hardware capabilities as structured attributes that the scheduler can query. A scheduler that understands DRA can make placement decisions based on GPU memory bandwidth, NVLink topology, or whether a specific device supports the precision formats a given model needs — not just whether a GPU is available.

The official KubeCon NA schedule includes multiple sessions on DRA, Kueue/DRA integration, and the KAI Scheduler's approach to AI-specific placement signals.

The Tuesday Keynote

The main conference opens Tuesday morning with the keynote. CNCF Executive Director Priyanka Sharma will open the program, followed by project milestone announcements, end-user case studies, and the first of several sessions that will directly address the AI agent identity problem in the main keynote track.

The conference's main keynote schedule is public. What is not yet public is which end-user case studies will make the stage — those are finalized by the program committee in the days before the conference opens and are worth monitoring for teams that want to understand how early production AI-on-Kubernetes deployments are actually structured.

Wednesday and Thursday

The main program's second and third days shift from milestone announcements toward deep-technical sessions and working-group outputs. The AI agent identity thread resurfaces across multiple tracks: service mesh sessions will cover the SPIFFE-for-agents proposals, security sessions will cover the audit and attribution gap, and platform engineering sessions will cover how teams are working around the gap today using logging, tracing, and application-level tagging as a substitute for cryptographic identity.

The conference's Wednesday schedule includes the Platform Engineering Day and Security Day tracks, both of which carry sessions directly relevant to the identity and attribution questions the community arrived with.

Thursday closes with the CNCF project lightning talks, which historically surface the emerging projects not yet prominent enough to anchor full sessions but worth tracking for the following year's program.

Sponsor Landscape

The KubeCon NA 2026 sponsor page lists the full sponsor roster. The Diamond tier includes AWS, Google Cloud, HAProxy Technologies, Microsoft Azure, Nutanix, Oracle, Red Hat, ScaleOps, and Solo.io. All nine have product announcements or session presence tied to the inference, identity, and scheduling themes running through the conference program.

The overlap between the Diamond sponsor list and the llm-d contributor list — Google Cloud, Red Hat, and NVIDIA's ecosystem presence through KAI Scheduler — reflects how much vendor-backed engineering effort has moved into CNCF projects over the past twelve months. The governance model that keeps those contributions inside CNCF's vendor-neutral framework while still moving fast enough to ship a v1.0 release is itself a topic of quiet conversation in the halls this week.

What to Watch

The sessions worth tracking for teams that cannot attend in person:

The SPIFFE-for-agents working group output, expected to publish draft requirements by end of week, will determine whether the existing SPIFFE/SPIRE architecture can be extended for AI agent instance identity or whether a new credential primitive is needed.

The KAI Scheduler vs. Kueue + DRA bake-off session, structured as a direct comparison with real workload benchmarks, will give platform teams their clearest picture yet of which scheduling approach fits which workload class.

The llm-d production case studies, contributed by early adopters who have been running pre-1.0 versions since the CNCF Sandbox acceptance in March, will offer the first independent data on where the framework performs as advertised and where it still needs work.

The Gateway API Inference Extension conformance update will clarify which gateway implementations have passed v1.5.0 conformance testing and which are still in progress — a practical guide for teams making vendor decisions now.

All of this will move fast. The official KubeCon NA schedule is the authoritative source for session times, room assignments, and any changes made after press time.

Frequently Asked Questions

What is KubeCon + CloudNativeCon North America 2026?

KubeCon + CloudNativeCon North America 2026 is the flagship annual conference of the Cloud Native Computing Foundation, the Linux Foundation-hosted organization that stewards Kubernetes and over 170 other cloud-native infrastructure projects. The conference brings together platform engineers, software developers, and enterprise architects to review project milestones, hear end-user case studies, and advance technical working groups. This year's edition runs November 9–12 at the Salt Palace Convention Center in Salt Lake City, with co-located specialty events on November 9 preceding the main program.

What is the AI Inference + Agentic track, and why is it new?

Cloud Native AI + Inference Day is a new co-located event added to KubeCon North America 2026's schedule in response to the volume and specificity of session proposals on LLM inference, agent orchestration, and AI observability that accumulated over the past year. Prior editions folded these topics into existing AI/ML or platform engineering tracks. The dedicated day reflects that inference serving, agentic workloads, and the protocol ecosystems that connect them — including MCP and A2A — now constitute a large enough specialized sub-community to warrant their own program and audience.

What is llm-d, and what is its current status?

llm-d is a Kubernetes-native distributed LLM inference framework co-maintained by IBM Research, Red Hat, Google Cloud, CoreWeave, and NVIDIA. It was accepted into the CNCF Sandbox in March 2026 and released v1.0 on October 20, 2026, at PyTorch Conference North America. The v1.0 release carries a production-stability commitment, meaning the API surface is stable for production deployment. Full project documentation and release notes are available on llm-d GitHub repository.

What is the SPIFFE/agent identity problem?

SPIFFE (Secure Production Identity Framework For Everyone) assigns cryptographic identities to Kubernetes workloads at the service account level. All pods running under a given service account share one SPIFFE identity. For traditional microservices — where individual pod instances are functionally interchangeable — this is architecturally appropriate. For AI agents, it is not: each agent instance may carry distinct conversational context, tool call history, and accumulated reasoning state, making the question of which specific instance took a consequential action meaningful in ways that the SPIFFE credential model cannot currently answer. The proposals being discussed at KubeCon 2026 include per-instance identity minting and session-scoped supplementary tokens.

What is the Gateway API Inference Extension?

The Gateway API Inference Extension is an official Kubernetes project that adds inference-aware routing capabilities to the Kubernetes Gateway API. It introduces two custom resource definitions — InferencePool and InferenceModel — that give the Kubernetes control plane semantic knowledge of LLM workloads: which pods serve which model families, what their memory and compute constraints are, and how to route requests in ways that account for KV-cache locality and model-loading latency. The extension reached general availability at v1.5.0 on April 19, 2026. Conformance requirements and implementation details are published on the Gateway API Inference Extension GitHub.

What is DRA and why does it matter for GPU scheduling?

Dynamic Resource Allocation (DRA) is a Kubernetes feature that changes how the scheduler models specialized hardware. Rather than treating GPUs as countable resources (like CPUs or memory), DRA exposes hardware as structured attribute sets that the scheduler can query at placement time. A scheduler that understands DRA can place workloads based on GPU memory bandwidth, NVLink topology, or precision format support — not just whether a device is available. DRA reached general availability in Kubernetes 1.34 in August 2025. The full specification is available in the Kubernetes DRA specification documentation. Its practical significance for AI workloads is that it makes GPU placement semantics visible to the control plane in a way that prior device plugin models did not.

KubeCon + CloudNativeCon North America 2026 runs November 9–12 at the Salt Palace Convention Center, Salt Lake City. Session recordings will be published to the CNCF YouTube channel following the conference.