XuHuaian,s Blog

Appearance

Istio 多集群管理 ​

1. 多集群的需求背景 ​

  • 统一管理： 希望在多个集群之间统一配置、统一安全策略，让服务间的访问可以跨集群进行，并且运维侧可以在一个维度上观察和管理所有服务。
  • 地理/可用区分布： 不同集群位于不同的可用区或不同的云提供商，需要通过服务网格将它们连接起来，提供跨集群的流量治理和高可用。
  • 隔离和弹性： 不同团队或业务线使用不同集群，但又希望它们能够互通，从而在需要时共享服务或相互调用。

2. Istio 多集群的部署模式 ​

Istio 官方文档中，常见的多集群部署模型主要有以下几种：

  1. 单控制平面 (Single Control Plane) + 多集群数据平面
    • 只有一个 Istio 控制平面（istiod），部署在一个集群里，管理其他集群里的 Sidecar 代理。
    • 其他集群中的工作负载需要能访问到该控制平面，通常要在各个集群之间打通网络或通过 Gateway 做控制面通信。
    • 好处：控制面只有一套，便于集中管理和统一配置。
    • 难点：集群间网络通信要求较高，对控制面 HA 也要特别考虑。
  2. 多控制平面 (Multiple Control Planes) + 联邦方式互联
    • 每个集群都有自己独立的 Istio 控制平面，但通过共享 Root CA 或者信任链来统一证书管理，并在各控制平面间同步或交换必要的服务发现信息。
    • 好处：控制面分散部署，更易于高可用；各集群相对独立，集群内出现问题不影响其它集群控制平面的正常运行。
    • 难点：需要在多个控制平面间协调服务发现和配置同步，管理相对复杂。
  3. Primary-Remote 模式
    • 常见于 Istio 文档中对于多集群（尤其是单网络或多网络场景）做的详细分类：
      • Primary Cluster：部署完整的 Istio 控制面和网关。
      • Remote Cluster：可以只部署数据平面（Sidecar），部分情况下只需有限的控制面组件。
    • 与“单控制平面 + 多数据平面”思路类似，只是文档里做了更细粒度的角色划分。
  4. Mesh Federation（网格联合）
    • 如果已经有多个独立的 Istio 网格（各自有自己的 CA、控制平面），可以通过网格联合的方式让它们之间互信，并且允许跨网格的流量路由。
    • 这种模式下，你可以把不同网格的网关通过配置方式对接起来，然后在流量进出时做主网格/副网格的寻址或路由映射。

3. 单网络 vs. 多网络 ​

Istio 在多集群场景下还会区分**单网络（Single Network）和多网络（Multi-Network）**两种情况：

  • 单网络：多个集群属于同一网络平面，Pod IP 在多个集群间可直接互相访问（IP 地址可路由），这时跨集群调用时 Sidecar 代理可以直接连接目标 Pod，无需额外的 Gateway。
  • 多网络：各集群 Pod IP 互不可达，需要借助 Istio Gateway（通常是 East-West Gateway）进行跨集群通信，把流量通过网关“打通”到另一个集群。这就需要在各个集群部署 East-West Gateway，并配置相互之间的 Service 发现和路由规则。

4. 核心要点：服务发现 & 证书信任 & 流量路由 ​

  1. 服务发现 (Service Discovery)
    • 多集群下，每个集群内运行不同服务。要让这些服务互相可见，需要 Istio 控制平面能够获知所有集群的服务信息。
    • 在“单控制平面”模式中，控制平面会从多个 Kubernetes API Server 抓取服务/endpoint 信息；
    • 在“多控制平面”模式中，各控制平面之间需要同步可跨集群访问的服务信息（或通过 Mesh Federation 互相暴露）。
  2. 证书信任 (mTLS 及 Root CA)
    • 要想让多个集群间能够使用 mTLS 通信，需要它们在同一个信任域（Trust Domain），或者通过共享 Root CA或者相互信任的方式达成。
    • 在多控制平面模式下，可以把各控制平面签发的证书都挂在同一个根 CA 下，或者在网格联合中设定互信策略。
  3. 流量路由 (Cross-Cluster Routing)
    • 如果是单网络，集群间 Pod 能直接通信，Istio 只需给 Sidecar 分发到目标 Pod 的 IP 信息即可；
    • 如果是多网络，需要通过网关进行跨网络访问，需要在 DestinationRule 和 ServiceEntry 等配置中声明跨集群服务的地址，或借助 Istio 提供的自动多集群配置能力来完成。

5. 一个简化示例：单控制平面，多集群部署 ​

下面以最常见的示例：单控制平面 + 多数据平面 + 多网络为例，简要介绍配置思路（逻辑简化，展示核心流程）。

  1. 集群 A（Primary）：
    • 部署 Istio 控制平面 (istiod)。
    • 部署网关 (istio-ingressgateway、istio-eastwestgateway)。
    • 配置访问权限，使得其他集群可以访问集群 A 的 istiod。
  2. 集群 B（Remote）：
    • 不必部署完整 istiod，但需要在本地安装 Istio Sidecar Injector、east-west gateway 等。
    • 配置让 Sidecar 可以向集群 A 的 istiod 注册，并获取配置、证书等。
    • 在集群 B 的 Kubernetes API server 中，通过 istioctl x create-remote-secret ... 之类的方式，把集群 B 的 API server 访问信息交给集群 A，以便 A 能够发现 B 中的服务和 endpoint。
  3. 证书管理：
    • 由集群 A 的 istiod 统一签发工作负载证书，集群 B 中的 Pod 启动时会通过 Envoy 向 istiod 申请证书，建立 mTLS 信任。
  4. 跨集群通信：
    • 由于是多网络，集群 A 的 Pod IP 无法直接访问集群 B 的 Pod IP，需要在东西向网关（East-West Gateway）上配置相互可达的地址或域名。
    • 当 A 中的服务需要调用 B 中的服务时，Envoy 会发现目标地址在另一个网络，然后将流量发送给 A 的 East-West Gateway，再通过网络互联到 B 的 East-West Gateway，最终路由到 B 的 Pod。

通过以上配置，在逻辑上你会看到跨集群的服务好像都在一个统一的网格中，每个服务都能够（在受控的范围内）互相调用，并且享有相同的安全策略和可观测性能力。

6. 管理与运维建议 ​

  1. 选择合适的部署模型
    • 如果想要更简单的集中式管理且网络环境支持，使用单控制平面是最 straightforward 的方案。
    • 如果对高可用要求极高，或集群间网络隔离明显，可以考虑每个集群独立部署控制平面，再通过共享 Root CA 或 Federation 方式互联。
  2. 关注网络连通
    • 多集群往往需要跨 VPC、跨地域或跨云商，所以要确保控制平面通信 (istiod <-> Sidecar) 端口、东西向网关 (East-West Gateway) 端口可达，并解决防火墙、路由等网络层面的问题。
  3. 统一证书和安全策略
    • 在多集群中，一定要明确 mTLS 策略和证书管理模式。是否使用同一个 Trust Domain？Root CA 如何共享？这样才能保证跨集群调用成功并实现安全加密。
  4. 服务命名冲突
    • 如果不同集群中出现相同的 Service 名（如 reviews.default.svc.cluster.local），需通过配置 Network、Trust Domain 等方式来区分集群来源，或使用Mirroring Name等方法进行避免。
  5. 监控与可观测性
    • 推荐在每个集群部署自己的可观测性后端（Prometheus、Grafana、Jaeger 等）或使用集中式观测平台。
    • 或者通过全局 Prometheus 拉取多个集群 Sidecar 指标进行统一展示。
    • Tracing 跨集群时，也需要网关和服务之间正确地传递 Trace Header。

本文作者：许怀安
创作时间：2025-04-09
版权声明：本博客所有文章除特别声明外，均采用BY-NC-SA许可协议。转载请禀明出处！

许怀安 | MIT License

Copyright © 2020-2025