Artificial intelligence is not replacing Kubernetes networking; it is exposing where the familiar model is incomplete. The agenda for CiliumCon at KubeCon + CloudNativeCon North America 2026 makes that shift unusually concrete. The event is built around production problems such as enforcing policy on RDMA traffic, tracing packet loss in latency-sensitive inference, operating IPv6-only clusters, migrating a fleet-wide datapath, and applying runtime controls without modifying applications.
The important news is therefore larger than a conference program. Cilium’s community is treating AI infrastructure as a dataplane problem, not merely a scheduler or accelerator problem. That matters because platform teams have often approached GPU workloads by adding device plugins, specialized node pools, and queueing systems while leaving networking assumptions largely untouched. Distributed training and inference challenge that separation. They make bandwidth, tail latency, topology, isolation, and kernel-level visibility part of workload correctness.
The central thesis: AI workloads are forcing Kubernetes teams to promote the network dataplane from shared plumbing to a workload-aware control surface, and Cilium’s eBPF-based stack is becoming a focal point for that transition. The opportunity is significant, but operators should respond with careful measurement and staged adoption rather than assuming one technology eliminates every bottleneck.
Why the AI networking problem is different
Conventional stateless services usually tolerate some network variability. Requests can be retried, replicas can absorb load, and an occasional slow connection may appear as a modest increase in an application’s tail latency. Accelerated computing is less forgiving. A distributed training job can synchronize many workers; one delayed path may leave expensive GPUs idle. An inference service can move large model artifacts, communicate with remote storage, and distribute requests across specialized components. When the hardware is costly and utilization is closely watched, a network problem quickly becomes a capacity and economics problem.
RDMA makes the distinction sharper. It is designed to move data with low latency and reduced CPU involvement, attributes that are valuable for tightly coupled GPU workloads. Yet an optimized path can bypass assumptions embedded in ordinary container networking and policy. Teams need to know whether their isolation model applies consistently to the traffic that matters most, whether telemetry can explain degraded performance, and whether changes to the dataplane preserve the behavior of existing applications.
This is why the CiliumCon program’s attention to RDMA policy enforcement and inference debugging is notable. Those topics connect performance and security rather than presenting them as separate tracks. A high-throughput path that cannot be governed is an operational liability; a thoroughly controlled path that cannot meet workload latency is equally unusable.
eBPF offers a shared point of control
Cilium’s architectural argument starts in the Linux kernel. Its documentation describes how the datapath combines several eBPF attachment points. XDP can act early in packet reception; traffic-control hooks can enforce endpoint policy; socket-level hooks can observe TCP state and accelerate local communication; and an Envoy integration can apply layer-seven rules where deeper protocol awareness is required.
That matters because the kernel is one of the few places where networking, process context, and workload identity can be correlated without requiring every application to adopt a new sidecar or instrumentation library. Cilium maps traffic to identities and policies, Hubble provides network observability, and Tetragon extends the same broad eBPF foundation into process and runtime security. The products are distinct, but the shared approach creates the prospect of a consistent operating model across connectivity, visibility, and enforcement.
For AI platforms, consistency may be more valuable than any individual feature. Infrastructure teams already face fragmentation across GPU scheduling, model serving, storage, networking, and security. If the dataplane can expose useful signals and enforce policy near the kernel, platform owners gain a place to reason about workloads that may otherwise appear as opaque, high-volume flows.
Tetragon illustrates the runtime side of the argument. Its official overview says it can observe and react to process execution, system calls, file access, and network activity while remaining aware of Kubernetes constructs such as pods and namespaces. Filtering and enforcement occur in eBPF, which can reduce the cost of shipping every low-level event to userspace. For an inference service, that creates options beyond conventional network allow lists: a team can connect network identity with what a workload is actually doing on a node.
The dataplane is becoming part of AI capacity planning
GPU utilization is usually discussed through scheduler placement, batch size, model architecture, and accelerator availability. Networking now belongs in that calculation. If packet loss, congestion, or a poorly chosen path stalls synchronized workers, the nominal accelerator capacity is not the usable capacity. If observability cannot isolate the problem, operators may compensate by adding hardware rather than fixing transport behavior.
This changes the questions platform teams should ask. Instead of asking only whether a CNI can connect pods, they need to ask whether it can preserve latency objectives under realistic AI traffic, reveal the path of a degraded flow, enforce the required isolation, and support the kernel and hardware combinations deployed across the fleet. Multi-cluster designs raise another question: whether network identity and policy remain intelligible when jobs, data, and GPUs span failure domains or providers.
The CNCF’s broader infrastructure guidance for KubeCon 2026 reinforces this point. It frames GPU-intensive, inference, and agentic workloads as extensions of core infrastructure responsibilities: scaling, networking, storage, access, reliability, and cost control. That is a useful corrective to the idea that an AI platform is a separate island. Kubernetes teams do not get to abandon operational fundamentals simply because the payload is a model.
What platform teams should validate now
The conference agenda provides a signal, not a deployment blueprint. Organizations evaluating Cilium or extending an existing installation should build a workload-specific validation plan.
Measure the traffic that drives accelerator idle time
Start with an end-to-end baseline. Capture throughput, retransmissions, packet loss, connection setup time, and latency distributions alongside GPU utilization and job completion time. A network dashboard disconnected from workload outcomes will not show whether a change improves useful capacity. Tests should include contention, node failure, rescheduling, and the large transfers that occur during model loading or checkpoint operations.
Map policy to every relevant data path
Document which flows use standard pod networking, which use host networking, and which rely on specialized transports such as RDMA. Then verify enforcement experimentally. A policy that looks complete in YAML can still leave gaps if traffic follows a path that the expected hook does not see. Teams should test both allowed and denied behavior and retain evidence that controls remain active after upgrades.
Treat kernel compatibility as a platform requirement
eBPF capabilities depend on kernel features, configuration, drivers, and the behavior of the underlying cloud or operating-system image. Platform teams should publish a supported matrix rather than letting every cluster drift independently. Canary nodes, automated conformance checks, and rollback procedures are especially important when changing low-level networking on expensive production pools.
Separate observability value from telemetry volume
Kernel-level visibility can produce rich data, but collecting everything is not a strategy. Decide which events answer operational or security questions, filter close to the source where appropriate, and define retention based on incident needs. Hubble flow data, application traces, GPU metrics, and Tetragon runtime events should share identifiers or context that help responders move from a slow request to a network flow and then to a process.
Stage migrations around failure domains
The CiliumCon schedule includes a fleet-wide netkit migration and a large-scale CNI migration, which highlights a practical reality: dataplane replacement is an operational program. A safe sequence begins with representative noncritical clusters, advances through limited production pools, and expands only after upgrade, rollback, and observability procedures are proven. AI nodes should not be the first test merely because they motivate the project; their cost and sensitivity make them a late, deliberate stage.
What Cilium does not solve by itself
Cilium can provide important mechanisms, but it cannot choose an application’s communication pattern, guarantee that a physical fabric is uncongested, or repair a poor multi-cluster topology. It also does not remove the need for application-level traces and accelerator telemetry. Kernel signals explain a vital portion of the system, not the entire system.
There is also an organizational constraint. Networking, security, Kubernetes, and ML infrastructure teams may own different parts of the same path. A unified dataplane can still produce fragmented operations if alerts, policies, and change approvals remain isolated. The most effective adoption work will include shared service-level objectives and incident exercises, not just component installation.
Finally, sidecarless and kernel-based approaches shift expertise rather than eliminating it. Teams gain less per-workload machinery, but they assume responsibility for understanding kernel behavior, eBPF programs, CNI upgrades, and the interaction with managed Kubernetes services. That trade can be favorable at scale, provided it is explicit.
What changes next
The immediate impact of CiliumCon’s 2026 focus is that cloud-native networking roadmaps will increasingly be judged against AI-specific workloads. Features such as RDMA-aware policy, IPv6 scale, inference traffic debugging, sidecarless encryption, and multi-cluster connectivity will move from specialist concerns toward platform requirements for organizations building shared AI infrastructure.
The broader consequence is a tighter relationship between workload economics and the dataplane. When a few milliseconds of network delay can strand costly accelerators, observability is no longer merely a troubleshooting aid. It is part of capacity management. When fast paths risk escaping ordinary controls, runtime enforcement is no longer an optional security layer. It is part of making the platform usable.
Cilium is well positioned because it gives the ecosystem a common vocabulary based on eBPF, Kubernetes identity, and kernel-level enforcement. But the winning operational pattern will not be “install Cilium and declare the AI network solved.” It will be to connect dataplane signals to workload outcomes, test policy on every transport, standardize supported kernels, and migrate in measured stages.
That is the larger message behind the conference agenda: Kubernetes networking is being asked to understand the workloads it carries. AI infrastructure makes the cost of ignorance too high.
