手工执行22 的 ip 命令可以构造连通路径，但节点运行时还要重复地给新进程挂接网络，并在失败时回收地址、设备与路由。CNI 规范定义调用方与插件之间的配置、输入环境、输出和操作接口，不是一个指定必须使用 bridge 或 VXLAN 的数据面。

把意图、调用、对象串起来

调用方给插件网络配置、容器 ID、netns 路径和接口名，执行 ADD；插件/链式配置可能交给 IPAM 分配地址并创建 veth、bridge 连接、路由，再返回地址和接口信息。CHECK 用于适用版本的状态核对；DEL 释放自己创建的网络资源。命令成功也不能单独证明业务连通，应该把输出配置的 IP 对应到 namespace inode、内核网络对象及一次真实请求。各操作的幂等、失败恢复前提需要对选定插件的固定版本源码再验证，不对所有插件宣称绝对原子。

正常实验必须在专用 VM 固定 CNI spec、插件和 IPAM 版本，先建两个自有 netns，逐个执行 ADD/CHECK/DEL，前后读取 veth、地址租约、路由；异常例故意使第二步失败，再调用 DEL 并确认设备与 IP 真正释放，二次执行结果需可核对。不可对节点上已投入使用的 Pod 插件配置做故障注入。运行材料给出需要填写的变量与清理步骤；共用探针附件用作请求检查。

本机没有 CNI 插件、ip、节点 runtime；没有固定的插件实现源码可针对这一环境核查，因而只是官方 CNI 规范的 DOC_VERIFIED，真实调用与失败回滚 NOT_RUN。此前网络 33的一份静态 JSON 不能转为本篇 ADD 成功日志。

现象 核验对象 适用边界
ADD 返回 IP 实际 netns 设备/路由 不等于业务连通
CHECK 不支持 插件与 spec 版本 不可直接称为链路坏
DEL 后地址仍占用 IPAM 租约及自建网卡 需分层清理

练习

  1. 先预测同一容器 ID 重复 ADD 在所选插件版本下会怎样，先读该版本规范与源码，再在实验 netns 上记录设备与地址分配是否重复。
  2. 预测 ADD 后请求超时而 CHECK 报成功时可能缺什么；按监听、网络策略、路由与真实请求逐项排查，不把插件返回码当 HTTP 验收。

上一篇：23：bridge/端口/DNS；下一篇：25：跨主机网络。

系列总目录：从进程隔离到运行时与编排。

参考资料