第四章：多云网络互联：VPC 对等连接、VPN 与专线、云原生网络方案（如 Cilium）

说实话，多云架构里最让人头疼的，不是资源怎么调度，而是网络怎么打通。

你想想看，业务在 AWS 上跑着，数据库在阿里云上，日志又扔到了腾讯云。它们之间怎么通信？直接暴露公网 IP？那安全审计第一个找你喝茶。

这一章，我就把多云网络互联的几种主流方案掰开揉碎了讲。从传统的 VPC 对等连接，到 VPN、专线，再到云原生的 Cilium。每种方案的坑，我都踩过不少。

4.1 VPC 对等连接：最直接的“拉根网线”

VPC 对等连接，说白了就是在两个 VPC 之间建立一条私网通道。它不经过公网，延迟低，带宽大。

我最早接触多云时，第一个想到的就是这个方案。因为配置简单，在 AWS 控制台点几下，两个 VPC 就能互相访问了。

核心要点：
  • 两个 VPC 的 CIDR 不能重叠。这是硬伤，一旦重叠，对等连接就废了。
  • 路由表要手动添加。对等连接建立后，不会自动帮你加路由。
  • 跨区域对等连接支持，但跨账号需要额外授权。

我在项目中遇到过一个问题：两个团队各自规划了 VPC，结果都用了 10.0.0.0/16。后来想打通网络，发现根本没法做对等连接。最后只能重建一个 VPC，迁移了所有资源。那叫一个痛苦。

避坑指南： 我曾经因为没检查 CIDR 重叠，直接在生产环境配了对等连接。结果路由冲突，导致部分服务中断了半小时。从那以后，我养成了一个习惯：在创建 VPC 之前，先拉个表格，把所有 VPC 的网段都登记清楚。

4.2 VPN 与专线：公网与私网的选择

当 VPC 对等连接搞不定时，就该 VPN 或专线上场了。

4.2.1 VPN：低成本但看天吃饭

VPN 走的是公网，成本低，部署快。但问题也很明显：公网不稳定，延迟抖动大。

我记得有一次，客户用 IPSec VPN 连接 AWS 和阿里云。平时延迟 5ms，一到晚高峰就飙到 200ms。业务方天天投诉，最后没办法，只能上专线。

我的建议： 如果业务对延迟不敏感，比如日志同步、离线计算，VPN 完全够用。但如果是实时交易、数据库主从同步，还是老老实实上专线吧。

4.2.2 专线：稳定但贵

专线是物理链路，不经过公网。延迟稳定，带宽有保障。但价格嘛，一个字：贵。

我做过一个对比，大家可以参考：

方案 延迟 成本 部署周期 适用场景
VPC 对等连接 1-2ms 低 分钟级 同云厂商、同区域
VPN 5-50ms 低 小时级 跨云、延迟不敏感
专线 1-3ms 高 周级 跨云、延迟敏感

嗯，这里要注意：专线不是买了就能用。你得跟运营商沟通，拉光纤到机房，还要配置边界网关协议（BGP）。我见过一个团队，专线通了但 BGP 没配好，结果流量还是走公网，白花了钱。

4.3 云原生网络方案：Cilium 的崛起

传统网络方案有个通病：它们是为物理网络设计的，对容器和微服务不够友好。

你想想看，Pod 的 IP 是动态的，随时可能漂移。你用 VPN 或专线去连一个 Pod？那路由表得写到崩溃。

这时候，云原生网络方案就派上用场了。我个人最推荐的是 Cilium。

4.3.1 Cilium 是什么？

Cilium 是一个基于 eBPF 的 CNI 插件。它不依赖传统的 iptables，而是直接在 Linux 内核里做网络策略和负载均衡。

说白了，它比传统方案快一个数量级。而且它原生支持 Kubernetes，能感知 Pod 的生命周期。

Cilium 的核心优势：
  • 性能高：eBPF 在内核态执行，绕过用户态，延迟极低。
  • 安全强：支持 L3/L4 到 L7 的网络策略，能精确控制 HTTP、gRPC 等协议。
  • 可观测：内置 Hubble，能实时看到每个 Pod 的网络流量。
  • 多云友好：支持 Cluster Mesh，能跨集群、跨云打通网络。

4.3.2 Cluster Mesh：多云网络的终极方案

Cluster Mesh 是 Cilium 的杀手锏。它能把多个 Kubernetes 集群连接成一个逻辑网络。

我在项目中用过一次：业务在 AWS 和阿里云各有一个集群，通过 Cluster Mesh 打通。Pod 之间可以直接用 ClusterIP 通信，完全感觉不到跨云的存在。

配置起来也不复杂，核心步骤就这几步：

# 1. 安装 Cilium，开启 Cluster Mesh
cilium install --set cluster.id=1 --set cluster.name=aws-cluster

# 2. 在另一个集群上同样安装，但 cluster.id 要不同
cilium install --set cluster.id=2 --set cluster.name=aliyun-cluster

# 3. 建立连接
cilium clustermesh enable
cilium clustermesh connect --destination-context=aliyun-cluster
小技巧： 配置 Cluster Mesh 时，记得检查两个集群的 Pod CIDR 和 Service CIDR 是否重叠。如果不重叠，可以直接用；如果重叠，需要启用 NAT 策略。我一般建议从一开始就规划好，避免后期折腾。

4.3.3 与传统方案的对比

我整理了一个对比表，方便大家选型：

维度 VPC 对等连接 VPN/专线 Cilium Cluster Mesh
适用场景 同云厂商、同区域 跨云、传统架构 跨云、Kubernetes 原生
延迟 低 中/低 极低
运维复杂度 低 中 中高
安全策略 依赖安全组 依赖 ACL L3-L7 精细控制
可观测性 弱 弱 强（Hubble）

看到这里你可能会问：那是不是所有场景都用 Cilium 就行了？

其实不是。Cilium 的学习曲线比较陡，而且对内核版本有要求（至少 4.19 以上）。如果你的团队对 eBPF 不熟悉，或者跑的是传统虚拟机，那 VPN 或专线可能更合适。

注意事项： 我曾经在一个 CentOS 7 的集群上部署 Cilium，结果内核版本太低，eBPF 功能不全。最后只能升级内核，折腾了两天。所以，用 Cilium 之前，先确认你的操作系统支持。

4.4 总结与选型建议

好了，这一章的内容差不多就这些。我最后给个总结性的建议：

  • 同云厂商、同区域：优先用 VPC 对等连接，简单高效。
  • 跨云、传统架构：预算充足上专线，预算有限用 VPN。
  • 跨云、Kubernetes 原生：直接上 Cilium Cluster Mesh，这是未来的趋势。

我个人现在做多云项目，只要涉及 Kubernetes，首选就是 Cilium。它虽然配置起来比 VPN 复杂，但一旦跑起来，那种丝滑的感觉，真的回不去了。

下一章，我们会聊聊多云环境下的服务发现与 DNS 解析。到时候见。

← 上一章 📖 返回目录 下一章 →