Container Networking Models Across Runtimes
Runtime choice determines which networking models, CNI integrations.
Container networking models depend on the runtime they run on. Choosing a runtime therefore means choosing more than isolation and performance. It also sets the limits on CNI integration, network access, and eBPF-based policy and observability. Teams get better results when they choose the runtime and networking stack together, rather than treating a distribution default as a settled architecture.
Why runtime choice is a networking decision, not just an isolation one
The EKS node-flapping incident illustrates how runtime architecture becomes a reliability problem. The request path went through three daemons, but no single component was slow enough to trigger a page. Delays accumulated across the layers and surfaced as kubelet timeouts against the CRI socket. The failure appeared at the node boundary. Understanding it required looking beneath that boundary at the runtime stack.
Most teams inherit that stack from their distribution and leave it alone as networking requirements change. But the runtime determines which network namespaces, kernel hooks, and CNI integration paths are available. A later need for stronger isolation or kernel-level traffic visibility can reveal a limit that was there from the start. Docker is also an obsolete Kubernetes baseline. Its integration was deprecated in v1.20 and removed in v1.24, so its networking model should not anchor a new Kubernetes design.
How the runtime stack is layered and where networking fits in it
High-level runtimes such as containerd and CRI-O manage images and snapshots and expose the CRI to the kubelet. Beneath them, low-level runtimes such as runc and crun turn an OCI specification into namespaces, cgroups, and a process tree. These are distinct jobs with different consequences. The upper tier manages the container lifecycle, while the lower tier creates the environment in which the process runs.
CNI plugins connect that lifecycle to network setup. The high-level runtime invokes them to create, configure, and remove container networking using the available kernel mechanisms. For ordinary host-kernel containers, the execution chain eventually reaches a low-level runtime asking Linux for namespaces and cgroups. Most of the networking differences come from above that point. This is why changing the CNI integration or introducing a sandbox has different consequences from replacing runc with crun.
What the dominant runtimes — containerd and CRI-O — actually make available to CNI plugins
containerd is the default in GKE, EKS, AKS, and most on-premises distributions, while CRI-O is the Red Hat-aligned default in OpenShift. Together, they cover nearly all production Kubernetes deployments. Their steady-state performance is close, but their scope differs. containerd is general-purpose and offers broad CNI compatibility, including bridge and overlay configurations. It makes fewer assumptions about how the surrounding platform will use containers.
CRI-O focuses exclusively on the Kubernetes CRI specification. That narrower remit gives it a smaller attack surface and stricter CRI compliance, without the extra functions of a general-purpose container manager. For standard Kubernetes networking, however, the two are close substitutes. Both support the same CNI plugins and expose the host-kernel environment those plugins expect. The choice is therefore less about gaining a networking model than about choosing the security posture and operational dependencies through which plugins are managed and patched.
Where the networking model breaks — sandboxed runtimes and their CNI constraints
gVisor and Kata Containers are built for a different threat model, including user-supplied code, AI agent environments, and workloads that are truly multi-tenant. Their stronger isolation changes the environment that applications and networking tools see. This is where the comparison stops being interchangeable. A sandbox does not merely add another setting to the containerd-versus-CRI-O decision. It introduces a boundary that some networking approaches cannot cross as expected.
gVisor intercepts system calls in userspace and reimplements a kernel subset in Go. That synthetic kernel does not expose all the attachment points that host-kernel tooling expects, so profiling tools that depend on perf events can fail and some eBPF CNI uses are blocked. Kata creates a different boundary through a microVM and its guest kernel. For trusted internal services, the marginal isolation benefit rarely justifies the added operational cost. For untrusted code, the sandbox is defensible, but its eBPF restrictions must be part of the design before deployment.
What bridge, host, and overlay networks offer each runtime — and where the trade-offs sit
Bridge networking adds latency overhead but is well suited to multi-tenant isolation. Host networking bypasses NAT for the lowest latency, but sacrifices network isolation. Overlay networking connects workloads through tunnels and pays a throughput cost for that encapsulation. With ordinary host-kernel containers on containerd or CRI-O, all three models are available, so workload needs can guide the choice.
Under gVisor, workloads that require direct host network access may fail or behave unexpectedly because the synthetic kernel does not behave identically to the host kernel. Kata's boundary is different but just as consequential. What a pod sees as its host is still a guest kernel, so the usual performance benefits of host networking do not fully apply. For inference pipelines that need the lowest possible inter-pod latency, the practical choice is containerd or CRI-O with host networking or a high-performance overlay, unless tenant isolation takes priority.
How eBPF fits into the runtime stack and which runtimes can use it fully
eBPF is a kernel primitive. CNI plugins and service meshes use it to build parts of their networking data plane, which is the path that handles traffic. Its usefulness depends on access to the right kernel attachment points. Selecting an eBPF-based stack assumes that the environment beneath it exposes the hooks its programs need.
With ordinary containers on containerd or CRI-O, those programs can use the host kernel's networking hooks. gVisor changes that relationship, so programs expecting Linux kernel functions, tracepoints, or XDP hooks can behave differently or fail. With Kata, the host and guest have separate visibility planes. Programs inside its guest kernel cannot see or affect host-level traffic, which limits how much tools such as Hubble can see across the node. Host-level functionality and visibility inside a sandbox are therefore not interchangeable, even when both are described as eBPF support.
The data plane and runtime need to be selected together. A team adopting Cilium for its full kernel-level policy and visibility capabilities is choosing a host-kernel runtime path, normally containerd or CRI-O without a sandbox boundary that removes those capabilities. The CNI name alone does not settle compatibility. Teams need to check which features work across the isolation boundary they use.
Cilium and Istio Ambient as the two serious eBPF-era networking options, and what runtime each assumes
Cilium Service Mesh and Istio Ambient Mode offer alternatives to putting an Envoy sidecar beside every pod. That architectural change is largely about cost and density, because per-pod proxy memory accumulates across a cluster. Istio Ambient reached general availability in 2024. Istio recommends ambient mode for new users, while Cilium makes kernel-level networking central to its approach.
Cilium combines SPIFFE identity for mTLS, L7 traffic policy, load balancing, and Hubble observability without adding a second control plane. It needs access to host-kernel eBPF hooks to offer its full capabilities. Ambient separates L4 handling in ztunnel from L7 handling in waypoint proxies, reducing memory overhead for L4-only setups. These approaches make different resource trade-offs. Cilium's kernel path uses less CPU per node for L4 work, while Ambient retains userspace waypoint overhead for L7 traffic.
For teams choosing between them, Cilium is the stronger fit when kernel-level policy is required and there is no existing Istio configuration investment. Ambient fits existing Istio configuration and multi-cluster federation needs. Scale can qualify that choice. Tests with very large pod counts found API server bottlenecks in Cilium's distributed control plane, while Ambient's centralized control plane was more stable, so the choice shifts at that scale. Neither design transfers to gVisor or Kata without significant constraints, so sandboxed workloads may need sidecars or application-layer mTLS instead.
How Youki and crun change the low-level runtime picture without changing the networking model
Replacing runc with crun or Youki changes the component that creates namespaces, cgroups, and the container process. It can improve cold-start performance and per-container overhead. It does not change the networking model. Under containerd or CRI-O, the CNI integration, eBPF hook surface, and service mesh configuration stay the same because the swap keeps the same networking boundary.
That transparency does not remove the operational cost of a less-mature component. Support considerations include Youki’s smaller community than runc or crun and troubleshooting that can require staff who can read Rust stack traces. Teams weighing a low-level runtime swap should judge it on cold-start performance, density, and how well they can run it. It is not a way to recover networking capabilities lost to sandbox isolation.
Runtime choice for AI and GPU workloads, where isolation and networking requirements conflict
Multi-tenant inference and customer-supplied code point toward gVisor or Kata, while low-latency networking and eBPF observability point toward ordinary containers on containerd or CRI-O. gVisor adds 18–35% latency overhead depending on system-call density, so the choice of isolation can have a large effect on how fast the system responds and how much the infrastructure costs. A platform cannot assume it will get the strongest sandbox boundary and unrestricted host-kernel networking from the same configuration.
Modal illustrates a deliberate choice in favor of isolation. Its platform uses gVisor-based sandboxing for compute isolation and TLS 1.3 for public APIs and encryption in transit, rather than relying on eBPF-based network policy for that security role. For a startup serving its own models rather than executing customer code, containerd with Cilium and host or optimized overlay networking is the practical choice. It provides full eBPF observability and low networking overhead without a microVM bootstrapping penalty.
Compliance adds another requirement to that choice. Providers including CoreWeave, Cerebrium, and Baseten hold SOC 2 attestations, and Cerebrium completed SOC 2 Type II on July 8, 2026. The scope still needs careful attention. CoreWeave's SOC 2 Type II coverage is product-specific and includes Bare Metal and CoreWeave Kubernetes Service. At the workload level, eBPF policy and Hubble observability can produce traffic logs and enforcement records for audits, while sandboxed teams without that visibility need equivalent evidence from another layer.
Making a deliberate runtime choice — a decision framework based on networking requirements
The decision framework starts with the workload's strongest requirement. Teams that need Cilium's full networking capabilities should choose the mesh and host-kernel runtime path together. Teams executing untrusted user code should prioritize gVisor or Kata and plan explicitly for reduced eBPF policy and visibility, with application-layer instrumentation where needed. Operational complexity belongs in that calculation too. Mixing sandboxed and standard runtimes in one cluster should require a strong reason because the heterogeneity adds work during incident response.
Once the isolation boundary and data plane are settled, cold-start-sensitive teams can evaluate crun or Youki beneath containerd or CRI-O. For FaaS patterns and inference with scale-to-zero, gains in startup and density can add up at scale while networking compatibility stays the same.
Teams that do not want to manage runtime selection, CNI integration, eBPF policy, and SOC 2-ready network controls can delegate that work to a platform layer. A well-designed PaaS can take on those infrastructure tasks so product engineers can focus on the application. What the platform guarantees still needs to match what the workload requires. As workloads evolve, the runtime choice should be revisited deliberately, rather than left for the next networking incident to expose.
