Federating Clusters for Zero-Downtime Kubernetes：Linkerd 多集群实战解读

背景

在多区域（Multi-region）Kubernetes 部署中，运维团队最终都会面临一个尴尬的技术瓶颈：当某个集群完全宕机时，位于另一区域、运行着相同服务副本的集群往往形同虚设。这是因为缺乏底层连接机制，导致系统无法将这两个独立的集群视为一个整体。在这种架构下，故障转移（Failover）通常变成了一项繁琐的手动操作：恢复服务、重新指向 DNS，然后被动等待一段“理论上已具备容灾能力”的停机时间。

Linkerd 的多集群扩展（Multicluster Extension）旨在填补这一空白，它允许将多个集群中的服务呈现为一个单一的、经过负载均衡的端点。然而，官方文档往往忽略了平台工程中的一个现实：真正的生产环境极少只采用单一的多集群模式。

• 联邦模式（Federated）：服务在所有地方保持一致，拥有单一端点，支持自动故障转移。
• 镜像模式（Mirrored）：通过名称访问特定的远程服务。
• 混合需求：在实际场景中，团队通常需要同时使用这两种模式，甚至在同一组链路中混合使用。

本文基于 Hacker News 上的热门讨论，详细拆解了如何在三个 GKE（Google Kubernetes Engine）集群上，通过全网状（Full-mesh）链路拓扑，将 Linkerd 的三种多集群模式（Gateway、Flat、Federated）整合在一起。文章不仅涵盖了理论区分，还提供了一个包含混沌测试（Chaos Test，即主动摧毁整个集群以验证容灾能力）的完整脚本仓库，供读者克隆并在新的 GCP 项目中运行。

核心内容

1. Linkerd 多集群的三种模式及其区别

Linkerd 的多集群扩展支持三种主要模式，且它们并非互斥，而是可以通过标签（Label）在服务级别进行细粒度选择：

• 联邦模式（Federated）：

  • 机制：跨集群的服务被视为同一个实体，由 Linkerd 自动进行负载均衡。
  • 网络要求：需要真实的 Pod 到 Pod 的直接连通性（Flat Network）。
  • 适用场景：核心工作负载，要求高可用性和自动故障转移，无需客户端感知后端位置。

• 扁平镜像模式（Flat Mirrored）：

  • 机制：客户端通过显式的远程服务名称（如 api-west）访问远程集群中的服务。流量直接发送至远程 Pod。
  • 网络要求：需要真实的 Pod 到 Pod 的直接连通性。
  • 适用场景：客户端需要决定与哪个后端通信的场景，例如为了数据 locality（数据局部性）将请求保留在区域内。

• 网关镜像模式（Gateway Mirrored）：

  • 机制：服务通过 Linkerd 网关导出。其他集群通过网关 IP 访问该服务，无需直接连接远程 Pod。
  • 网络要求：仅需网关 IP 可达，不要求底层 Pod 网络互通。
  • 适用场景：跨非扁平网络（如不同 VPC 或未对等网络）访问服务，或用于隔离特定服务。

操作层面的关键区别：

• Gateway 模式：灵活性最高，适用于任何网络环境，只要网关 IP 可达即可。
• Flat 和 Federated 模式：依赖于底层的扁平网络（Flat Network），即 Pod 之间必须能够直接路由。

2. 多区域架构设计：GKE 集群设置

演示环境包含三个位于不同区域的 GKE 集群（West、East、North），它们之间通过全网状链路完全互联（共 6 个方向性链路）。三个演示服务分别展示了不同的模式：

• Frontend（联邦模式）：

  • 在三个集群中均运行。
  • 每个集群中的联邦 Frontend 服务对全部 9 个 Pod（3 副本 × 3 集群）进行负载均衡。
  • 容灾表现：当某个集群宕机时，剩余的 6 个 Pod 自动吸收所有流量，无需应用程序做任何更改。

• API（扁平镜像模式）：

  • 仅在 West 和 East 集群运行。
  • North 集群将其消费为 api-west 和 api-east。
  • 流量直接发送至远程 Pod，适用于需要客户端显式选择后端以优化数据局部性的场景。

• Analytics（网关镜像模式）：

  • 仅在 East 集群运行。
  • 通过 Linkerd 网关导出，West 和 North 集群通过 analytics-east-gw 访问。
  • 此模式证明了 Gateway 模式可以与 Flat 和 Federated 模式在同一链路中共存，且无需 East 集群的 Pod 网络对其他集群开放。

3. 部署前置条件与工具链

• 基础设施：GCP 账户（免费额度即可），三个标准 GKE 集群配合小型节点池。
• CLI 工具：
  • gcloud：已认证。
  • kubectl：v1.28+。
  • step：用于证书生成（brew install step）。
  • helm：v3。
• 时间成本：完整设置约需 30 分钟。

4. 实施步骤详解

Step 0: 配置环境 克隆仓库，从 env.example 复制 .env 文件。至少需要设置 GCP_PROJECT。脚本默认配置了三个区域（us-central1, us-east1, europe-west1），每个区域一个可用区，节点类型为 e2-medium，节点数为 1。所有脚本均使用 set -euo pipefail，确保变量缺失时立即报错，而非静默失败。

Step 1: 配置三个 GKE 集群与 VPC 对等 运行 ./scripts/01-infra.sh：

• 启用 Compute 和 Container API。
• 创建三个 VPC，使用不重叠的 Pod 和 Service CIDR（这是 VPC 对等的硬性要求）。
• 建立全网状 VPC 对等（West↔East, East↔North, North↔West），并启用 --export-custom-routes 和 --import-custom-routes，以确保 Pod CIDR 被正确通告，从而形成扁平网络。
• 创建三个 GKE Standard 集群，每个集群锁定在单个可用区。
• 成本优化提示：脚本将 --node-locations 锁定在单个可用区。若使用区域集群（Regional Cluster）且 --num-nodes=1，GKE 默认会在三个可用区各部署一个节点，导致成本三倍增加。锁定单可用区可确保每个集群仅消耗一个节点的成本。
• 预估成本：三个标准集群，每个集群一个 e2-medium 节点，每日总成本约 $10–15（含管理费、节点费和 East 集群的小型网关负载均衡器费用）。

Step 2: 安装 Linkerd 与共享信任锚 运行 ./scripts/02-linkerd-install.sh：

• 生成根 CA 证书和每个集群的签发者证书（Issuer Certificates）。
• 在所有三个集群上安装 Linkerd 控制平面。
• 安全最佳实践：使用共享根证书（Root CA）作为信任锚，实现跨集群 mTLS。每个集群拥有独立的签发者证书，若某集群证书泄露，可单独轮换而不影响其他集群。
• 资源优化：仅安装控制平面，未安装 Viz 插件，以降低资源占用和成本。

Step 3: 安装多集群组件并创建全网状链路 运行 ./scripts/03-multicluster-setup.sh：

• 创建六个方向性的链路（每对集群之间双向链接）。
• 配置完成后，每个集群均可消费来自其他集群的服务。

关键要点

• 模式非互斥：Linkerd 的多集群模式（Gateway、Flat、