本质是cni del调用失败导致veth残留，需先验证无主（查netns、桥接、nameif），再用ip link delete安全删除；根源在容器异常退出、cni超时或netns提前销毁，应升级cni插件、启用自动清理脚本并限制地址池。
容器频繁销毁后宿主机上残留大量 veth 接口（如 vethabc123、vethxyz789），本质是网络资源未被 cni 插件正确回收，而非网卡“太多”本身——它反映的是网络清理链路断裂，需从生命周期协同、cni 健壮性和系统兜底三方面入手。
确认残留是否真实存在
别只看 ifconfig 或 ip link list 的数量。先过滤出疑似残留的 veth：
- 执行 ip link show | grep -E "veth[0-9a-f]{6,}" | wc -l 统计当前 veth 总数
- 再查哪些 veth 实际已无对应容器：docker ps -q | xargs -I{} sh -c 'echo {}; docker inspect {} | jq -r ".[].NetworkSettings.Networks.bridge.EndpointID"' 2>/dev/null | sort | uniq -u | xargs -I{} ip link show {} 2>/dev/null | grep -q "veth" && echo "orphaned"（该命令粗筛无主 veth）
- 若输出大量 “orphaned”，说明清理失败已成常态，不是偶发问题
修复 CNI 清理失效的根本原因
veth 残留几乎总是 CNI DEL 调用失败所致。关键检查点：
- CNI_NETNS 是否提前销毁：容器退出时若 netns 被 kernel 提前回收（常见于快速启停或 OOM kill），CNI 插件无法进入该命名空间执行清理。可在容器启动时加 --net=container:other 复用网络栈，或改用 host 网络模式降低 netns 频次
- CNI 插件版本与超时设置：旧版 bridge 或 macvlan 插件在高并发销毁时易超时失败。升级到 CNI plugins v1.4+，并在 /etc/cni/net.d/xxx.conf 中显式配置 "exec-plugin": {"timeout": 10}
- Docker 与 CNI 通信完整性：检查 dockerd 日志是否有 "failed to call CNI plugin" 或 "DEL command failed"。若高频出现，说明 CNI 进程响应慢或崩溃，建议部署 CNI health check sidecar 或改用轻量级插件（如 tuning + portmap 组合替代完整 bridge）
启用自动清理与资源隔离
不依赖 CNI 单点可靠，需宿主机层主动干预：
- 定期清理孤儿 veth：写脚本定时执行 ip link | grep "veth.*state DOWN" | awk '{print $2}' | cut -d@ -f1 | xargs -r ip link delete（仅删 DOWN 状态且无命名空间关联的接口）
- 限制单节点最大 veth 数量：在 /etc/docker/daemon.json 中添加 "default-address-pools": [{"base":"172.20.0.0/16","size":24}]，缩小子网范围可间接控制单桥接网络下可分配 veth 上限（非直接限制数量，但能减少碎片）
- 隔离网络生命周期：对测试类短命容器，统一使用 --network none 或自定义 macvlan 网络（不走 bridge），避免 veth 创建；生产服务则固定使用自定义 bridge 网络并禁用默认 bridge
验证与长期防护
修复后持续观察是否复发：
- 用 watch -n 5 'ip -br link | grep veth | wc -l' 监控 veth 数量波动趋势
- 在容器退出后 10 秒内执行 ls /var/run/netns/，确认对应 netns 文件是否及时消失（若长期存在，说明容器进程僵死未释放 netns）
- 将 CNI DEL 调用日志接入 Loki 或 ELK，设置告警规则：连续 5 分钟 DEL 失败率 > 5% 即触发通知
