k8s网络脱网故障本质是容器netns被篡改，需从netns隔离层切入修复：先排除cni崩溃等常规原因，再通过比对inode号、检查非法netns挂载、强制重建sandbox及kubelet恢复，并通过权限控制、流水线检查和内核保护机制防止复发。
这类故障本质是容器网络栈被破坏，不是单纯配置错误，需从 netns 隔离层切入修复，不能只靠重启或重调度。
确认是否为 netns 篡改引发的脱网
先排除常规原因（如 CNI 插件崩溃、节点失联、防火墙拦截），再聚焦 netns 异常：
- 在异常 Pod 所在节点上，用 pidof 或 ps aux | grep kubelet 找到该容器的 init 进程 PID
- 执行 ls -l /proc/
/ns/net ，比对输出的 inode 号与同节点其他正常容器是否一致；若明显不同或指向 net:[4026532712] 类孤立命名空间，大概率被篡改 - 运行 ip netns list —— 正常 K8s 节点不应有用户手动创建的 netns；若出现非 CNI 管理的命名空间（如 hack-ns、test1），说明有人误操作或脚本污染了 netns 环境
定位并清理非法 netns 挂载点
K8s 不管理独立 netns，但非法挂载会劫持容器网络路径：
- 检查挂载表：mount | grep netns，重点看是否有类似 netns test1 on /var/run/netns/test1 type nsfs 的条目
- 若存在，且该 netns 不属于 CNI（如不是 cni- 开头或 terway- 开头），执行 umount /var/run/netns/
卸载 - 删除残留目录：rm -f /var/run/netns/
- 注意：不要直接删 /var/run/netns/ 下的 CNI 相关 netns（如 cni-xxxx），否则会导致整个节点网络中断
恢复被破坏容器的网络栈
无法通过 kubectl delete pod 自愈，因为 kubelet 依赖底层 netns 正常才能重建：
- 进入异常容器所在节点，找到其 pause 容器 PID（通常为该 Pod 下第一个容器）
- 执行 nsenter -t
-n ip link show —— 若报错 Operation not permitted 或返回空，说明 netns 已损坏 - 强制重建网络命名空间：crictl stopp
→ crictl removep （使用 crictl 而非 docker 命令，适配 containerd） - 触发 kubelet 重建：systemctl restart kubelet（仅限单节点临时恢复，生产环境建议滚动驱逐）
防止再次发生的关键控制点
netns 篡改多源于运维误操作或不规范脚本，需从机制上封堵：
- 禁止普通用户执行 ip netns 和 nsenter —— 通过 sudoers 限制或移除对应二进制文件执行权限
- 在 CI/CD 流水线中加入检查项：mount | grep netns | grep -v 'cni\|terway'，非零退出即告警
- CNI 配置启用 protectKernelDefaults: true（Calico）或等效参数，阻止内核网络参数被随意修改
- 定期审计 /var/run/netns/ 目录内容，纳入 Prometheus + node_exporter 自定义指标监控
