多集群网格(Primary-Remote)

可视化演示

展示Primary-Remote多集群网格：网络拓扑、证书信任链与流量分发策略，通过交互理解跨集群服务治理与多区域容灾。

模式概述

你是一家餐饮集团的创始人。第一家店开在市中心，店长、后厨、收银共处一室，指挥起来特别顺。后来生意红火，你在三座城市各开了一家分店。问题来了：每家分店都配一个店长？三家店长凑一起开调度会，规则五花八门，你累得焦头烂额。更糟的是，每家店的菜谱、服务标准、会员系统各搞一套，顾客换了城市就像进了另一家店。于是你决定换个思路——总店只设一个管理班子，分店只配服务员，所有决策从总部统一发令。这就是 Primary-Remote 模式在现实生活中最早的雏形：集中决策，分散执行。

Istio 单集群网格就像“一家店”的运作：控制面组件 istiod 像店长一样负责所有规则决策，数据面 Envoy sidecar 则像服务员一样跟着每个业务容器处理请求。多集群网格要解决的是“跨店协作”问题——让三座城市的服务像在一家店里那样步调一致。Primary-Remote 模式的做法是：Primary 集群部署完整的 istiod 控制面，Remote 集群只运行数据面（Envoy sidecar），不装控制面。Remote 集群里的业务 Pod 通过网络，把配置请求和证书申请发回 Primary，由它统一决策、统一签发证书。

这种单控制面、多数据面的架构决定了网格的服务范围是所有集群的并集。用集合语言写出来：

与多 Primary 模式相比，Primary-Remote 只有一套控制面，运维成本低、配置一致性好；代价是高度依赖 Primary 的可用性与跨集群网络质量。就像你只保留总部的管理班子，三家分店共用一套规章、一本菜谱，顾客在任何一家都能点到同样水平的菜——这就是 Primary-Remote 用一套控制面“统治”所有集群的本质。

拓扑结构

把集团的组织结构图画出来：总部大楼里坐着董事会和人力资源部（控制面），各分店的员工散落在全城不同写字楼（数据面）。画面上有一条粗粗的专线从每座分店连回总部——这就是控制面与数据面之间的远程通道。地理上分离，逻辑上一个整体，这正是 Primary-Remote 网络拓扑最直观的样子。

Istio 在 Primary 集群内运行 istiod，由它承担服务发现、配置管理和证书签发三大职责。Remote 集群中不运行 istiod，但每个业务 Pod 都带一个 Envoy sidecar。sidecar 通过 Remote agent 机制，用 Kubernetes API 的 watch 能力连接 Primary 的 API Server，保持配置实时同步。二者在网络拓扑上形成“一个控制中心 + 多个数据平面”的星型结构——控制面只有一份，数据面却可以横向铺开，局部扩容无需触碰总部架构。

控制面与数据面的数量关系可以用非常简洁的式子表达：

通信通道上需要打通 Remote 到 Primary 的 15012（gRPC 配置下发）与 15017（webhook 校验）等端口。若两个集群之间需要互相访问业务流量，还要部署东西向网关（east-west gateway），负责接收来自其他集群的服务流量；南北向网关则对外暴露服务，像门店的大门迎接顾客。一张组织架构图画下去：总部一个房，底下无数工位，工位越加越多，总部不用换房——这就是 Primary-Remote 拓扑结构最大的红利。

证书信任链

集团给每位员工发工牌：写着姓名、部门、岗位。但分店保安怎么知道这张工牌是真的？工牌上盖了两个章——集团总印鉴和区域钢印。保安验证时，先看区域钢印能否用“区域验章仪”通过，再看总印鉴是否由集团总章验过。印鉴链通到底，人才放行。这套“总印→钢印→工牌”的验证逻辑，就是 Istio 证书信任链的日常原型。

Istio 中，身份认证正是靠一条三级证书链。根证书（Root CA）由外部 CA 或自签机构创建，是整个网格的信任锚点；Primary 生成中间证书（Intermediate CA），由根证书签发；每个 sidecar 的工作负载证书则由中间证书签发。Primary-Remote 模式下，Primary 作为 CA 给所有集群签发证书，Remote 不需要单独 CA。跨集群通信时，双方 sidecar 在 TLS 握手阶段互相出示证书，并沿证书链向上验证，验证过程是一个链式验签：

信任域（trustDomain）就是网格的“集团品牌名”，通常配置为形如 mycompany.com 的字符串。证书的 SAN（主体备用名）中写入服务身份，格式为 spiffe://<trustDomain>/ns/<namespace>/sa/<serviceAccount>。只要 trustDomain 一致，Primary 和 Remote 就能互认。分店员工出差到总部，保安只看工牌印鉴链，一串到底就放行；Primary-Remote 的 sidecar 也一样——证书链同根，跨集群也能像同集群一样互信，甚至无需额外配置白名单。

流量分发

集团设了一个总机台，所有客户来电先进总机。总机有一本“业务名录”，记录每家分店能接什么单、还能接多少；然后按繁忙程度把电话转给合适的分店。如果某家分店占线，总机自动转给别的分店——客户根本感觉不到换了一家。这个“总机 + 名录 + 转接”的组合拳，正是 Primary-Remote 流量分发策略的完整映射。

服务发现就是那本名录的维护。Remote 集群的 sidecar 会通过 API Server 与 Primary 同步一份“网格级服务名录”，每个集群里注册的服务都会出现在统一列表中。负载均衡则是收到请求后按权重从名录中挑选目标端点。当目标服务不在本集群时，sidecar 会把请求送到本集群的东西向网关，由网关转发到目标集群——这就是跨集群路由。故障转移，相当于分店占线后的大规模转单：当某地域所有端点都被标记为不健康时，流量自动转移到其他地域健康端点。权重分配规则通常按副本数配置，写成公式：

在容灾场景下，可以让主区域权重设为 80、备区域设为 20，平时备区域承接少量流量保持热备；主区域故障后把权重整体切到备区域。总机名册一更新，所有接线员立刻知道哪家分店还能接单；哪家停电，总机一键转接。客户嘴上说着“请稍等”，其实电话早被总机悄悄换到了另一座城市的分店——这就是流量分发策略的“无感接力”。

配置实践

开分公司前，总部行政会发来一个“开荒包”：一份办公大楼的房卡配置、一张集团工牌、一个集团的 VPN 账号。分公司的人照着手册插上电源、连上 VPN，就能看到总部下发的所有规章制度。把一个 Remote 集群接入 Primary，本质上也是发一个类似的“开荒包”。

这个开荒包里装的是三样凭证：kubeconfig（API Server 地址与访问凭据）、根证书（建链时的信任基座）、ServiceAccount 令牌（身份认证）。Primary 侧用 istioctl 生成一个 remote secret 写入 Remote 集群，之后 Remote 就能访问 Primary 的 API Server 和服务发现接口。操作步骤分四步走，核心流程如下：

Remote 集群的接入凭证集合可以形式化表示为：

配置实践的本质就是把这套“行政包”流程规范化、自动化。最佳实践建议用 cert-manager 管理证书轮换，定期检查 remote secret 是否过期；如果两个集群的 Pod 网段重叠，还需要配置 VPN 或云互联进行网络打通。开业包发放 → 照手册配置 → 专线一插 → 分店自动接入集团网络，新分店像 U 盘即插即用一样加入网格。

# 第一步：Primary 集群安装 istiod，profile=remote-pilot 表示暴露 API 便于 Remote 接入istioctl install --set profile=remote-pilot # 第二步：生成 Remote 集群的接入 Secret（包含 kubeconfig）istioctl x create-remote-secret --name=remote-cluster | kubectl apply -f - # 第三步：Remote 集群导入 Secret 并安装 remote profile（不装控制面）kubectl apply -f remote-secret.yamlistioctl install --set profile=remote # 第四步：给业务命名空间打标签，新 Pod 自动注入 sidecarkubectl label namespace app istio-injection=enabled

适用场景

有些生意只适合开一家店，有些生意必须广撒网。连锁餐饮的选址逻辑是：考察人流（流量分布）、评估抗风险（容灾）、核算管理成本（控制面开销）。Primary-Remote 的开店逻辑完全一致——不是所有场景都适合它，但在对的地方，它能发挥极大的杠杆效应。

适用场景从三方面考量。多区域容灾：核心服务至少部署在两个地域，任一地域故障可快速切换，这家店倒了还有别家顶着；混合云统一管理：公有云与自建机房各自是集群，用一套控制面统一治理，不必在两边各养一支运维团队；规模权衡：如果某个 Remote 集群与 Primary 之间的网络延迟超过几百毫秒，或业务团队强烈要求自治，此时更应考虑多 Primary 模式。从演进路径看，建议从单集群起步，先在同城增加 Remote 集群验证流程，再跨地域扩展；当集群数量与自治需求都上升时，再演进为多 Primary 网格。

多区域布局带来的可用性提升可以用一个简洁的概率模型刻画：

当然，这只是理论模型，实际还要考虑跨区域同步延迟与数据一致性问题。选址对了，分店才不至于亏损。Primary-Remote 不是银弹，它是在“管理成本最低 + 容灾收益最大”之间找平衡——多区域布局如同多处下注，一家倒了，还有别家顶着。

落地验证

新分店开张，总部督导拿着检查单来验收：工牌能不能刷门禁（证书验证）、跨城电话通不通（跨集群调用）、数据报表能不能回传总部（监控可观测）。任何一项不过，开业延迟。多集群网格落地同样要靠检查单逐项验收，七分部署，三分验证。

部署流程按部就班：准备证书（自签根证书或 cert-manager 托管）→ 安装 Primary（profile=remote-pilot）→ 创建并导入 remote secret → 安装 Remote（profile=remote）→ 命名空间打标验证注入。功能验证最常用的是 bookinfo 示例：在 Primary 部署 productpage，在 Remote 部署 reviews，从 Primary 发起请求，观察 productpage 能否调用到远端 reviews——能通，说明服务发现、证书信任、东西向网关全链路 OK。验收标准在逻辑上是一个“全部通过才算通过”的合取式：

日常运维中，用 Prometheus 聚合两个集群的指标，重点监控 istiod 证书的到期时间、远程连接成功率、东西向网关的流量量级。排错时按顺序排查：先看 remote secret 是否过期，再看 trustDomain 是否一致，三看东西向网关 Pod 是否健康，四查 VirtualService 路由是否写对。督导在检查单上逐项打勾，全部 ✓ 之后才签字放行；多集群落地没有玄学，靠的是一张张清晰的检查清单和逐步验证的耐心。

AI 应用场景

Python 演示

import randomfrom collections import defaultdict  class PrimaryRegistry:    """Primary 集群的全局注册中心，维护本地与远端两份服务表"""     def __init__(self):        self._local_services = defaultdict(dict)        self._remote_services = defaultdict(dict)     def register_remote(self, cluster, service, replicas):        """Remote 调用此方法上报服务，相当于服务发现同步"""        self._remote_services[service][cluster] = replicas        print("[Primary] 已登记远端集群 {} 的服务 {}，副本 {} 个".format(cluster, service, replicas))     def register_local(self, service, replicas):        """Primary 本地服务直接登记"""        self._local_services[service]["primary"] = replicas     def candidates(self, service):        """返回该服务在所有集群的副本数表，作为路由依据"""        table = {}        table.update(self._local_services.get(service, {}))        table.update(self._remote_services.get(service, {}))        return table  class RemoteCluster:    """Remote 集群：本地只有数据面，服务信息上报到 Primary"""     def __init__(self, name, registry):        self.name = name        self.registry = registry        self._service_replicas = {}     def add_service(self, service, replicas):        """本地新增服务并上报 Primary"""        self._service_replicas[service] = replicas        self.registry.register_remote(self.name, service, replicas)  def pick_cluster(registry, service, rd=random.random):    """按副本数加权随机选择目标集群，模拟流量分发"""    table = registry.candidates(service)    total = sum(table.values())    if total <= 0:        return None    x = rd() * total    upto = 0.0    for cluster_name in sorted(table):        upto += table[cluster_name]        if x < upto:            return cluster_name    return None  def main():    registry = PrimaryRegistry()    registry.register_local("order-svc", 3)     beijing = RemoteCluster("beijing", registry)    beijing.add_service("order-svc", 4)     shanghai = RemoteCluster("shanghai", registry)    shanghai.add_service("order-svc", 2)     counts = defaultdict(int)    for _ in range(1000):        c = pick_cluster(registry, "order-svc")        counts[c] += 1    print("1000 次请求的分发结果：", dict(counts))  if __name__ == "__main__":    main()

1. class PrimaryRegistry:定义 Primary 集群的全局注册中心，同时维护本地与远端服务两张表。
2. def register_remote(self, cluster, service, replicas):Remote 集群上报服务的入口，相当于 mesh 级服务发现同步。
3. def candidates(self, service):把本地与远端服务表合并成一份路由候选表，对应跨集群统一服务名录。
4. def add_service(self, service, replicas):Remote 集群本地登记服务后立即调 register_remote 上报 Primary。
5. table = registry.candidates(service)取该服务的全部候选集群及其副本数，模拟从总机名录拉取可用分店。
6. x = rd() * total生成 0 到总权重之间的随机数，决定这次“电话”转给谁。
7. upto += table[cluster_name]累积权重，类似转盘抽奖按扇区面积落点，实现负载均衡。
8. counts[c] += 1统计 1000 次分发结果，直观验证权重比例是否符合预期。

常见误区

面试题