I was hunting down a packet loss issue on a node last week and noticed that the host’s bridge interface was flooded with veth pairs that didn’t belong to any running pod. It turns out that when your CNI plugin hits a snag during pod deletion, it occasionally leaves behind dangling virtual ethernet devices. This isn’t just clutter; it’s a slow leak that can eventually exhaust your interface index limit.

Why these ghosts stick around

Most CNI implementations rely on specific cleanup hooks that execute when the container runtime signals a termination. If the kubelet restarts or the network daemon crashes during that precise window, the cleanup script never runs. You’re left with an orphaned interface attached to the bridge, holding onto an IP address from your allocation pool.

ip -d link show | grep -B 1 veth | grep -v 'master' | awk '/^[0-9]+:/ {print $2}' | sed 's/://'

• Check the state of the interface with ip link to confirm if it has a master
• Verify if the peer index still exists in the host namespace
• Compare the remaining interfaces against the output of kubectl get pods -A -o wide

Cleaning up the mess safely

Before you start mass-deleting interfaces, check your CNI logs to see if a reconciliation loop is already underway. If you’ve got confirmed orphans, deleting them won’t impact your running pods, but it might freak out a monitoring tool if you aren’t careful. Keep an eye on your bridge stats afterward; sometimes the kernel keeps a reference count high until you reset the associated bridge port.

If you find yourself running this cleanup manually every few weeks, you’ve got a deeper issue with your CNI configuration or a flaky node agent. Next time, try bumping the log verbosity on your CNI binary; catching the race condition during teardown is way easier than auditing your entire cluster network state at 3 AM.