Introduction

On a Linux Kubernetes node, a pod is commonly connected to the host network by a veth pair. One end of the pair lives inside the pod network namespace as eth0, and the other end lives on the host side, often attached to a bridge or CNI-managed device. To see the relationship clearly, you need both the pod-side view and the host-side view on the same node.

Understand the Two Ends of the Link

A veth pair behaves like a virtual cable. Packets written to one end appear on the other end. In Kubernetes, the typical layout is:

• pod namespace side: eth0
• host namespace side: a veth... interface
• host attachment: bridge or CNI-managed routing device

The exact bridge name varies by CNI plugin, but the pod-side and host-side peer relationship is still visible through Linux networking tools.

Look at the Pod-Side Interface First

Start with the pod's own network namespace. From Kubernetes, you can at least inspect the pod-side IP and interface:

kubectl exec -n default my-pod -- ip addr
kubectl exec -n default my-pod -- ip route

That shows you the pod-side configuration, but not yet which host-side veth peer it connects to. For that, you need access to the node that runs the pod.

Enter the Pod Network Namespace from the Node

On the node, use your container runtime tools to find the pod sandbox process. With a CRI runtime, a common workflow is:

sudo crictl pods
sudo crictl inspectp <pod-sandbox-id>

From the inspect output, find the sandbox PID, then enter its network namespace:

sudo nsenter -t <sandbox-pid> -n ip link

In that output, look for something like eth0@if42. The if42 part is the host-side peer interface index.

That index is the key link between the pod and the host-side veth.

Match the Peer Index on the Host

Now inspect interfaces on the host itself:

ip link

Find the interface whose index matches the pod-side peer reference. If the pod namespace showed eth0@if42, look for host interface index 42. It will usually have a veth-style name.

For more detail, use:

ip -d link show
bridge link

bridge link is especially useful on bridge-based CNIs because it shows which bridge the host-side interface is attached to.

Example End-to-End Workflow

A practical sequence on the node looks like this:

1kubectl get pod -o wide -n default my-pod
2sudo crictl pods | grep my-pod
3sudo crictl inspectp <pod-sandbox-id> | grep -i pid
4sudo nsenter -t <sandbox-pid> -n ip link
5ip link
6bridge link

At that point you can usually map:

• pod name to node
• pod sandbox to namespace or PID
• pod eth0@ifNN to host interface index NN
• host interface to bridge or CNI path

That is the actual pod-to-veth relationship.

CNI Plugins Change the Host Topology

Not every cluster looks the same on the host side. For example:

• bridge-style setups often use cni0
• Calico may add routing and policy devices
• other CNIs may use overlays or plugin-specific interface naming

So do not memorize only one bridge name. Focus on namespace inspection, interface indices, and link metadata. Those remain useful even when the CNI differs.

Common Pitfalls

The biggest mistake is trying to solve the whole mapping from inside the pod alone. The pod can show its own eth0, but it cannot show you the host-side peer naming and topology.

Another issue is inspecting the wrong node. Pod network interfaces exist on the node where the pod is scheduled, so host-side commands must run there.

People also often assume all clusters expose the same bridge names. CNI implementations differ, so the veth pair is the stable concept, not one specific host device name.

Finally, remember that root or elevated privileges are usually needed for namespace inspection on the node. kubectl exec is only the starting point, not the complete diagnostic tool for this task.

Summary

• A pod is commonly connected to the host through a Linux veth pair.
• The pod side usually appears as eth0@ifNN inside the pod network namespace.
• The ifNN peer index can be matched to a host-side interface with ip link.
• Node-level tools such as crictl, nsenter, ip link, and bridge link are the practical way to trace the relationship.
• The exact host topology depends on the CNI plugin, but the namespace-and-peer workflow stays the same.