容器网络命名空间不能实现跨物理机迁移，仅能单机仿真迁移中的网络行为，如ip重绑定、路由变更等；通过创建ns-src和ns-dst命名空间并配置veth pair与ip，可模拟源/目标机网络切换过程。
容器网络命名空间本身不能直接实现跨物理机的虚拟机迁移，它只提供单机内的网络隔离能力。但你可以用它来仿真迁移过程中的关键网络行为——比如网络拓扑切换、IP重绑定、路由变更、服务连通性验证等，这对理解真实迁移逻辑、测试迁移脚本或演练故障场景非常实用。
明确仿真边界：命名空间 ≠ 跨机通信
网络命名空间是 Linux 内核级隔离机制，作用范围严格限定在单台宿主机内。veth pair、bridge、iptables 规则等都跑在同一台机器上。因此：
- 你无法用纯命名空间方案让 ns1 中的容器直接和另一台物理机上的 ns2 通信；
- 所谓“跨物理机迁移仿真”，实质是：在一台机器上搭建多套独立网络环境（如 ns-src、ns-dst），模拟源机与目标机的网络状态，并手动触发“切换”动作（如解绑旧 IP、绑定新 IP、更新路由、重启服务）；
- 重点不是复现迁移工具链（如 CRIU 或 vMotion），而是复现迁移后网络层面的可观测变化和配置依赖。
构建双节点仿真环境（单机模拟）
用两个命名空间代表“源物理机”和“目标物理机”，再配一对 veth + bridge 模拟基础连通性：
- 创建命名空间：
ip netns add ns-src && ip netns add ns-dst； - 创建 veth 对并分配：
ip link add veth-src type veth peer name veth-dst，然后ip link set veth-src netns ns-src、ip link set veth-dst netns ns-dst； - 在各自命名空间中启用接口并配 IP：
ip netns exec ns-src ip addr add 10.10.1.2/24 dev veth-src && ip netns exec ns-src ip link set veth-src upip netns exec ns-dst ip addr add 10.10.1.3/24 dev veth-dst && ip netns exec ns-dst ip link set veth-dst up； - 此时
ns-src和ns-dst可互通（类似直连两台虚机），为后续“迁移”提供基线。
仿真迁移核心动作：网络态切换
真正的迁移不只是复制数据，更是网络身份的交接。以下操作可逐项验证迁移中常见问题：
- IP 地址漂移：在 ns-src 中停用 veth-src，再在 ns-dst 中为其配置相同 IP（如 10.10.1.2），观察服务是否可被原客户端继续访问；
-
路由表更新：在 ns-dst 中添加一条到原业务子网的静态路由（如
ip route add 192.168.5.0/24 via 10.10.1.2），模拟目标机接管源机后端服务； -
DNS 与服务发现切换：用
ns-dst启动一个同名服务（如 nginx 监听 80 端口），再修改本地/etc/hosts或 DNS stub resolver，验证客户端能否无感切到新实例； - 防火墙策略生效检查：在 ns-dst 中启用 iptables 限制入向连接，确认迁移后安全策略已就位。
结合真实迁移工具做闭环验证
若你实际使用 CRIU 做容器迁移，或用 ZMigrate 做虚机迁移，可在仿真环境中预演其依赖项：
- 确认目标命名空间已加载所需内核模块（如
veth、bridge、nf_nat）； - 提前在 ns-dst 中挂载好对应路径（如 /var/lib/docker、/mnt/data），避免迁移时因路径缺失失败；
- 用
ip netns exec ns-dst ss -tln检查端口监听状态，比对迁移前后是否一致； - 写一个简单脚本，在 ns-src 停服、ns-dst 启服后自动执行 curl 测试和延时探测，模拟健康检查逻辑。
不复杂但容易忽略。
