Learn Kata Containers - Networking: CNI, virtio-net & Tap

#Introduction

Your Kata pod is already running, but have you ever asked: how does a Kata pod's networking work? With regular containers, CNI attaches a veth to the pod's network namespace on the host. With a microVM, there's no pod network namespace on the host — there's a VM. Networking has to get into the VM and connect to the application inside it.

Episode 7 dissects this path: from the CNI plugin on the host, through the tap device and virtio-net, to the interface inside the guest. Networking is the area that most often confuses people when first moving from runc to Kata — but once the architecture is understood, it all becomes logical.

#The Kata Pod Networking Flow

The journey of a packet leaving a Kata pod:

1. CNI (for example Cilium, Calico, or Flannel) is called to set up the pod's network.
2. CNI creates a tap device on the host and connects it to the CNI bridge.
3. Kata connects that tap to the microVM's virtio-net.
4. Inside the guest, virtio-net appears as a regular network interface (eth0).
5. The application in the guest uses eth0; outgoing packets travel virtio-net → tap → CNI bridge → CNI dataplane → network.

The key to understanding: CNI runs normally on the host, and the guest sees the virtio interface as a regular interface. The difference from regular containers: what shares networking with the host is the VM, not the container, so network isolation follows microVM isolation.

#CNI Integration on the Host

Kata doesn't replace CNI. It uses the CNI already present in the cluster — Cilium, Calico, Flannel, or others. From CNI's perspective, a Kata pod is just another pod that needs a network interface. What differs is the internal implementation: CNI connects a tap device, not a pod veth.

Because of this, most CNIs work without changes. Verify that CNI has set up the Kata pod's network correctly:

kubectl get pod kata-demo -o wide
crictl inspect <sandbox-id> | grep -A5 interfaces

crictl inspect <sandbox-id> displays sandbox details, including the assigned network interfaces. These interfaces will show the same pod IP you see from kubectl get pod -o wide.

#virtio-net Inside the Guest

Inside the microVM, networking is provided by virtio-net: the paravirtual device the VMM uses to provide networking to the guest. The guest doesn't talk directly to the host tap — it sees the virtio-net device as a NIC.

To see the interfaces inside the guest, enter it with kata-runtime exec (from episode 4):

kata-runtime list
sudo kata-runtime exec <sandbox-id> ip addr

kata-runtime exec <sandbox-id> ip addr shows the interfaces inside the guest — you'll see eth0 with the pod IP, and the lo loopback interface. From the application's perspective, nothing differs from a regular container.

#Multi-Interface

Kata supports multi-interface: a pod can have more than one interface, each provided by a different CNI plugin. A common example: one default interface for application traffic and one host-device interface for direct access to a physical NIC.

Multi-interface is provided by using several CNI plugins in a Multus configuration, or with Kata-specific annotations. At the concept level, each interface is a separate host tap + guest virtio-net pair.

#CNI Plugins: bridge, macvlan, host-device

The CNI plugin choice affects how the host interface is created:

• bridge: the default plugin — the tap connects to the CNI bridge, and the pod gets an IP from the CNI range. Simplest and most common.
• macvlan: the host interface is bridged directly to the pod with a separate MAC address. Good performance, but host-to-pod connectivity can be problematic and some cloud providers block it.
• host-device: passes a physical NIC directly to the pod. Suitable for workloads that need a specific NIC, but sacrifices network isolation from the host.

Most deployments use bridge — including through CNIs like Cilium and Calico, which manage their own bridge/internal datapath. macvlan and host-device are used for special cases, especially those involving performance and physical devices.

#Per-Pod Network Isolation Inside the VM

Network isolation in Kata works on two layers. First, at the CNI layer: every pod gets its own network namespace on the host. Second, at the guest layer: each microVM is a separate network entity with its own interfaces. The combination of the two means a Kata pod can't see another pod's interfaces or network namespaces on the same node.

For security, this is a big advantage: even if an attacker takes over the application inside the guest, they're trapped in their own guest network. The extension to NetworkPolicy and network security will be covered in episode 14.

#Experimental Options and disableNewNetns

For most workloads, the standard network behavior is enough. But there's an option you should be aware of because it appears in documentation and GitHub issues: disableNewNetns.

By default, Kata builds a separate network namespace for the pod inside the guest. The disable_new_netns option turns this behavior off — pods inside the guest directly use the guest network namespace. Its use cases: workloads that need direct access to guest interfaces, or applications that run their own network setup. This is an experimental option:

/etc/kata-containers/configuration.toml

[runtime]
# Disable the creation of a new network namespace for
# the sandbox inside the guest (experimental)
disable_new_netns = false

disable_new_netns = true will make the containers in a pod share the guest network namespace directly. Don't enable it without understanding the security consequences and without testing it in a lab — it changes the pod's network isolation model.

#Common Pitfalls

• Thinking CNI must be replaced: no — the same CNI is used for regular pods and Kata pods.
• Looking for the pod's veth on the host: a Kata pod doesn't have a veth; it has a host tap connected to the guest's virtio-net.
• macvlan that can't connect to the host: a built-in macvlan characteristic, not a Kata bug.
• Slow or failing DNS: make sure the cluster CoreDNS is reachable from the pod network — the DNS flow in a microVM is the same as in regular containers.

#Conclusion

What you should take away:

• CNI runs normally on the host; the microVM connects through a host tap and virtio-net.
• The guest sees the virtio-net interface as a regular interface (eth0).
• Common plugins: bridge, macvlan, host-device — bridge for most cases.
• Multi-interface is possible with separate tap + virtio-net pairs.
• Two-layer network isolation: CNI on the host, the guest as a separate entity.
• disableNewNetns is an experimental option — understand it before using it.

In the next episode, episode 8, we'll cover storage — how the rootfs image becomes virtio-blk, the role of virtio-fs for shared volumes, device passthrough with VFIO, and how emptyDir, PVC, and hostPath work inside the microVM. Data is the most important part of your workload, and understanding its path into the guest is key.