CNI 是 Kubernetes 中负责 Pod 网络配置的标准接口，由容器运行时调用插件实现 IP 分配、路由配置等；Docker 仅作为底层运行时，不参与跨节点或跨云路由，该能力由 Calico、Cilium 等 CNI 插件通过 BGP、VXLAN 或 eBPF 实现。
在 Kubernetes 集群中，Docker 本身不提供“虚拟路由技术”——它只负责单节点容器的网络接入（如 bridge、host 等模式），而跨云微服务互联的核心能力由 Kubernetes 的网络模型和 CNI 插件承担。Docker 在 K8s 中早已退为底层运行时之一（自 v1.24 起通过 CRI 接口调用），不再直接参与集群级路由决策。真正实现跨云高效互联的是：统一的 Pod 网络平面、Service 抽象、Ingress/EGRESS 控制，以及支持多集群通信的网络扩展方案。
明确角色分工：Docker 不管跨云，K8s 网络层才管
Docker 的 bridge 网络（如 docker0）仅作用于单台宿主机内部，无法跨节点，更无法跨云。Kubernetes 要求所有 Pod 拥有全集群可路由的 IP（即“扁平网络”），这必须依赖 CNI 插件（如 Calico、Cilium、Submariner）来实现。这些插件在每个节点上配置路由规则、BGP 宣告、VXLAN 隧道或 IPsec 加密通道，才是真正完成“虚拟路由”的组件。
换句话说：你不是“用 Docker 的虚拟路由”，而是“在 K8s 集群中部署兼容 Docker 运行时的容器，并由 CNI 提供跨云路由能力”。Docker 容器只是被调度的负载单元，不参与网络拓扑构建。
使用 Python 脚本下载 Docker 镜像并打包为 tar 文件。用户说“下载镜像”“拉取镜像”“pull xxx”“帮我下载 nginx 镜像”等时触发。支持 SOCKS5 代理直连（推荐）和国内镜像站加速两种模式。
跨云互联的三种主流落地方式
针对不同云环境（如 AWS + 阿里云 + 自建 IDC），推荐以下经过生产验证的路径：
-
方案一：CNI 原生多集群支持（推荐用于同构云）
使用 Calico 或 Cilium 启用 BGP 或 eBPF 跨集群模式。例如 Cilium Cluster Mesh 可将多个 K8s 集群的 Pod CIDR 注册到全局 kv 存储（etcd 或 CRD），自动同步路由与服务端点，无需修改应用代码。Service DNS（如svc-name.namespace.svc.cluster.local）在任意集群内均可解析并直连目标 Pod IP。 -
方案二：Submariner + Service Export/Import（适合异构云+混合云）
Submariner 是 CNCF 孵化项目，专为多集群设计。它在各集群间建立加密 VXLAN 隧道，在控制面注入自定义资源（如ServiceExport），将本地 Service 显式暴露给其他集群。其他集群通过ServiceImport获取 EndpointSlice，生成本地 ClusterIP 或 Headless Service，实现透明访问。 -
方案三：API 网关 + 服务发现兜底（低耦合，适合遗留系统）
当网络打通受限（如防火墙严格、无 VPC 对等权限）时，不依赖底层路由，改用逻辑层互联：各集群部署独立网关（如 Kong、Traefik），通过 Nacos / Consul / Eureka 实现跨集群服务注册；请求经公网或专线走 HTTPS，配合 JWT 鉴权与限流。虽增加跳数，但规避了网络策略冲突，运维边界清晰。
关键配置要点（避坑提醒）
无论选哪种方案，以下三点直接影响互通成功率：
-
Pod CIDR 规划必须全局唯一且不重叠：例如集群 A 用
10.244.0.0/16，集群 B 必须避开该段（如10.245.0.0/16）。重叠会导致路由混乱甚至黑洞流量。 -
Service 类型要匹配访问场景：跨集群调用应优先使用
ClusterIP（靠 CNI 直通）或ExternalName（DNS 重定向）；避免依赖NodePort或LoadBalancer，它们绑定宿主机端口，不具备跨云语义。 -
务必启用 NetworkPolicy 并显式放行跨集群流量：默认情况下，K8s 的 NetworkPolicy 默认允许所有出口（Egress），但某些安全强化集群会默认拒绝。需添加规则允许目标集群 Pod CIDR 和对应端口，例如：
- egress:
- to:
- ipBlock:
cidr: 10.245.0.0/16
ports:
- protocol: TCP
port: 8080
不需要 Docker 特定操作，但需确保运行时兼容
K8s 对容器运行时无强绑定。只要 Docker Engine（或 containerd）满足 CRI 接口规范，就能正常拉取镜像、启动容器。重点检查：
• 容器镜像使用多架构构建（linux/amd64,linux/arm64），适配不同云厂商的 CPU 类型；
• Java 微服务开启 JMX 远程调试或 Prometheus 指标端点时，确保容器内监听 0.0.0.0 而非 localhost；
• 若用 Spring Cloud Alibaba，Nacos 地址应配置为集群内可解析的 Service 名（如 nacos-headless.default.svc.cluster.local:8848），而非硬编码公网 IP。
