Docker原生Plugin不适用于跨机房隔离，因其不支持跨主机状态同步、缺乏VXLAN/IPSec隧道能力、无法联动服务网格与RBAC，且已被官方弃用；生产级方案应采用CNI插件（如Cilium ClusterMesh）+ Kubernetes多集群管理 + 加密隧道强制策略。
在 Linux 上利用 Docker Plugin 扩展容器网络能力以支持跨机房自动化部署隔离，核心不是直接依赖 Docker 原生插件生态（如 legacy docker network plugin），而是通过 **与 Kubernetes 集成的 CNI 插件 + 容器运行时插件机制** 实现真正生产级的跨机房网络隔离与自动调度。Docker 自 20.10 起已将网络控制权逐步移交 CNI，原生 plugin 接口（如 NetworkDriver）仅适用于极简单机场景，无法满足跨机房所需的加密隧道、多子网策略、服务发现与故障自愈等要求。
为什么原生 Docker Plugin 不适合跨机房隔离
Docker 的 legacy plugin 架构（如通过 docker plugin install 安装的网络插件）存在明显局限：
- 不支持跨主机状态同步，无法维护全局 IPAM 或分布式 ACL 策略
- 缺乏对 VXLAN/Geneve/IPSec 隧道的原生封装能力，难以穿透不同机房的防火墙和 NAT
- 无法与主流服务网格（如 Istio）、RBAC 和多租户命名空间联动
- 官方已标记为“deprecated”，社区维护停滞，Kubernetes 生态全面转向 CNI
推荐路径：CNI 插件 + Kubernetes + 自动化编排
真正支撑跨机房隔离部署的是以下组合：
-
CNI 插件选择：使用具备跨机房能力的 CNI，例如：
• Calico with Typha + IPIP/BGP over GRE：支持 BGP 路由反射，在多个机房间同步路由表
• Cilium with ClusterMesh：基于 eBPF，原生支持跨集群服务发现、加密隧道（WireGuard）、L7 策略同步
• Antrea（VMware）+ Encap/NoEncap 模式：兼容 Open vSwitch，支持多集群 NetworkPolicy 同步 -
Kubernetes 多集群管理：用 Karmada 或 Cluster API 统一纳管多个机房的 K8s 集群，按 label（如
region=shanghai,region=beijing）自动分发工作负载 -
网络策略自动化：通过 Helm 或 GitOps（Argo CD）推送
NetworkPolicy和ClusterNetworkPolicy，实现“默认拒绝、显式放行”的跨机房通信控制
轻量替代方案：Docker Compose + 自定义 overlay 网络（仅限 PoC）
若暂不引入 Kubernetes，可在小规模跨机房测试中用 Docker 原生命令桥接基础能力：
- 在各机房边缘节点部署 consul 或 etcd 作为 KV 存储
- 使用
docker network create --driver overlay --opt encrypted --subnet=10.0.1.0/24 --gateway=10.0.1.1 --scope swarm创建加密 overlay 网络（需启用 Swarm mode） - 通过
docker stack deploy分发服务，并用placement constraints限定节点位置：deploy:<br> placement:<br> constraints:<br> - node.labels.region == beijing
- 注意：Swarm overlay 依赖 Gossip 协议，在高延迟、低带宽机房间易出现脑裂，不建议用于生产
关键隔离保障点（必须配置）
无论采用哪种方案，跨机房部署的网络隔离必须落实以下几项：
- 每个机房使用独立 CIDR 子网（如
10.10.1.0/24,10.10.2.0/24），避免 IP 冲突 - 所有跨机房流量强制走加密隧道（WireGuard / IPSec），禁用明文 IPIP 或 VXLAN
- 禁止容器使用
--network=host，确保命名空间隔离不被绕过 - 通过
iptables/nftables在宿主机层面限制非隧道端口入向（如只允许 UDP 51820/WireGuard、TCP 6443/K8s API） - 定期用
ip netns exec进入容器网络命名空间验证路由表和接口状态
