国投瑞银 Kubernetes 双集群高可用架构设计实践

在数字化转型浪潮下，企业业务系统上云已成为各行业的普遍共识。对于金融行业而言，因需满足监管层面的安全与合规要求（如数据本地化存储、数据加密传输、基础设施资源可控等），私有云成为主流建设模式。​

Kubernetes 凭借其领先的市场占有率，已成为容器编排领域的事实标准。其具备适配公有云、私有云等多架构的能力，因而成为云平台搭建的首选技术栈。​

同时，金融企业对业务系统连续性有强制性要求（如分钟级 RPO）。作为基础支撑平台，云平台的高可用性保障至关重要，业界已有云平台宕机导致巨额经济损失的案例。因此，在平台架构设计阶段排查高可用隐患、防范类似风险，对金融私有云建设具有决定性意义。

Kubernetes 集群高可用部署架构设计

Kubernetes 官方提供两种高可用集群方案：基于堆叠（Stacked）控制平面节点的方案与基于外部 etcd 集群的方案，两者均属单集群架构。​

单集群高可用方案在单一机房环境下可有效保障可用性：单个控制平面节点（假设部署三个控制平面节点）或部分工作节点故障时，集群仍能正常运行。但当整个机房因不可抗因素无法访问时，该方案将导致集群整体不可用。​

为解决单机房部署高可用的局限性，可采用跨机房部署单集群的模式，即将节点均衡分布于多个机房（如图 1 所示）。

图1:  多机房单集群架构 

图示中，控制平面节点分布于三个机房，工作节点均匀部署在同城光纤互联的两个机房。此架构下，任一机房故障时，其余两地的控制平面节点可正常进行 Leader 选举，正常机房的工作节点在新 Leader 管理下保持运行，从而保障集群可用性。​

相较于多集群方案，单集群方案具有部署简单、运维成本低的优势。多集群模式下，基础服务配置、数据同步、全局负载均衡设计及跨集群服务通信等工作可能需要双倍的投入。​

但多集群架构具备集群级备份能力。例如，业界曾出现因集群升级导致业务长时间中断的案例，此类问题在多集群环境下可完全规避，当某一集群故障时，可快速将服务切换至其他集群，保障业务连续性。​

Kubernetes 多集群方案设计

多集群是指在多个 Kubernetes 集群上跨集群部署应用的策略，采用该模式可达成以下目标：

• 隔离性，集群间相互独立，故障不会跨集群蔓延，便于故障隔离。

• 可用性，集群间可相互备份，采用同城双活方案时可实现实时灾备。

• 可扩展性，突破单 Kubernetes 集群的节点、Pod 数量限制，通过横向扩展提升承载能力；同时，小规模集群的节点通信流量更低，管理难度更小。

结合企业需求（侧重隔离性与可用性）及现有基础设施条件（同城双机房光纤互联），采用双集群架构即可满足高可用要求（若无特别说明，下文所述"双集群"均指此多集群方案）。其架构如图 2 所示：

图2: 双机房双集群架构

图示中，在两个独立机房分别部署高可用 Kubernetes 集群，服务请求通过前端全局负载均衡转发至目标集群。

1. 双集群实现策略

根据应用需求与基础设施约束，双集群可采用多种实现策略，典型方式包括：

• 集群复制架构，完整应用栈（含所有服务及组件）在两个集群中对等部署，可以认为两个集群运行的是完全相同的应用副本。

• 按服务划分的集群架构，服务仅部署在两个集群中的一个，即单一服务在双集群中仅存在一个副本。

集群复制架构的优势在于实现简单：服务在双集群对等部署，全局负载均衡设计难度低，可任意选择后端集群分发请求。​

该架构具备冗余备份能力：某一集群故障时，全局负载均衡能够检测到集群故障，可自动将请求转发至正常集群，实现实时故障转移。​

但其存在两项局限：一是对服务无状态性要求严格，即使将状态数据存储于后端数据系统如数据库、缓存，仍需解决数据同步问题（为保障高可用，数据库与缓存通常也会进行独立部署），而许多项目第三方服务商的系统往往未充分验证此类场景；二是资源利用率低，多数应用单实例即可满足需求，冗余实例部署会造成资源浪费。

基于此，我们采用混合策略：对实时性要求高的服务采用复制模式部署于双集群；对实时性要求较低的服务采用单副本部署（毕竟机房整体不可用概率较低），故障时可快速在另一集群重建服务。

当采用双集群单副本策略时，需通过全局负载均衡将请求路由到服务所在集群，这里有两种实现方式：

• 强耦合模式：全局负载均衡需知晓服务部署的集群位置，这可以通过请求的项目路径特征进行路由选择。此模式下，新服务上线需同步更新负载均衡配置，两者耦合度较高，该模式易于实现，但是灵活度低，项目新增或项目在双集群之间切换都需要更新全局负载均衡配置。

• 松耦合模式：全局负载均衡无需感知服务部署的集群位置，可像复制架构一样随机分发请求，这需要打通集群间服务访问，以实现跨集群服务关联与统一管理，该模式更加灵活。

2. 多集群统一管理

多集群增强了集群的可用性和安全性，但同时也增加了管理的复杂性：

• 集群的控制面板需实现数据同步（如 DNS 数据），以支持跨集群的服务发现。

• 需建立集群之间的服务通信机制，保障跨集群的服务访问。

以下是多集群在统一管理的一些主流实现方式：

• Kubernetes Federation v2，以 CRD 插件形式集成于 K8s API，将 RBAC、Deployment 等资源定义为“联邦对象”，并自动同步到成员集群。

• 虚拟 Kubelet（Virtual Kubelet），通过伪装 kubelet，对接远程集群 API，将远程的集群节点映射到本地集群节点，对上层的应用透明。

• 通过 CNI 实现互联，Kubernetes 通过 CNI 扩展，实现多集群 CNI 实例聚合，采用隧道技术或直接路由方式实现 Pod IP 跨集群通信（如 CiliumMesh，不过它依赖于特定 CNI--Cilium，也有不依赖于 CNI 的实现如 Submariner）。

• 服务网格（Service Mesh）, 通过在 Pod 中注入 sidecar 实现网络流量的劫持，也可实现跨集群的服务发现、流量调度和安全通信。

鉴于我们的 Kubernetes 集群已基于安全和流量控制需求部署了 istio 服务网格，采用 istio 多集群方案也就成为一个自然的选择。

3. istio 多集群方案

istio 支持多种多集群模式，比如 primary-remote，多集群在单网络上共享 istio 控制平面；multi-primary 模式，各集群有自己的控制平面。

从高可用角度出发，我们选择了独立网络多主模式，该模式虽然配置复杂，但约束最小（如支持双集群配置相同的 Pod CIDR），架构图如图 3 所示。

图3: istio独立网络多主模式 

此模式下，istio 通过 Kubernetes API Server 获取所有集群的配置与端点信息，因此各 istiod 拥有所有集群中服务的相关信息；远程服务访问通过 eastwest-gateway 实现路由转发。

从服务调度的视角看，可以认为每个服务在各集群均完成了注册。当调用非本地服务时，请求将通过 eastwest-gateway 路由到对应服务所在的远程集群，这样可以实现服务层的跨集群访问。

在 istio 架构中，外部请求通过 Igress Gateway + Virtual Service 进入集群。如果在每个集群中都创建相应的 Virtual Service，外部请求可通过任一集群的 Igress Gateway 路由至目标服务（因 istio 已实现服务层的跨集群访问），从而实现我们上述中全局负载均衡的随机分发。

4. istio 双集群方案细化设计

在同城光纤互联的两个数据中心，我们分别构建一个高可用 Kubernetes 集群，并基于 istio 独立网络多主模式在服务网格。通过集群之间的认证与授权（基于公共的 CA 并暴露相应的服务，具体部署步骤请参考官网），实现跨集群的服务发现和安全通信。

为实现服务统一的对外访问，我们通过 Helm 脚本在双集群同步创建相应的 Virtual Service。这样使得全局负载均衡可将服务请求转发到任一集群的 ingress gateway，若服务不在本地，Virtual Service 可以通过本地 eastwest Gateway 转发到目标集群（如图 4 中的 Service A），从而实现服务路由对全局负载均衡透明。

图4:  istio 独立网络多主模式服务路由 

尽管跨集群访问存在额外的网络开销，但单集群跨机房的部署同样存在此类开销。在现有光纤链路场景和部署为非实时应用的场景下，这种开销可以忽略不计。

需注意的是，集群内的节点故障时，集群控制平面会检测到异常，并将节点上的服务调度到正常节点，实现异常服务的自动漂移。但集群间并无相应机制实现集群之间的服务异常自动漂移（控制平面仅管理本集群资源）。Istio 实现的仅是集群之间服务互通。

例如，如果图 4 中的 cluster 2 故障时，路由至 cluster 1 的 Service A 请求会失败（因实际服务位于 cluster 2）。因此，对于非复制模式部署的服务，集群故障时，我们需手动在正常集群重建服务，这通常通过 CI/CD 工具来实现。

5. 持续集成与部署

服务部署我们采用的 GitOps 持续部署平台 ArgoCD。尽管 ArgoCD 本身支持多集群管理，但为保障部署高可用，我们在每个 Kubernetes 集群独立部署 ArgoCD Server，专门负责本集群应用服务管理（如图 5 所示）。这样，当一个集群不可用时，不会影响其他集群的部署工作（需注意，ArgoCD 只是一个持续部署工具，即使它不可用，集群中已部署服务仍能正常运行，只是无法进行部署更新）。

图5:  ArgoCD高可用部署

我们的部署流程主要通过 Jenkins Pipeline 实现，包括创建 ArgoCD project, application, 应用与权限配置。每个 application 与 Git 仓库中的服务 Helm 脚本相关联；Helm 脚本库适配多集群部署，也就是说多个集群中的 ArgoCD 部署的同一个项目，对应的是 Git 中同一个部署脚本副本。Helm 脚本通过集群分支逻辑实现集群差异化部署（如在指定集群进行全量资源部署，非目标集群则仅部署 Virtual Service）。

用户也可以通过直接更新 Helm 脚本，或者 Jenkins Pipeline 更新 Helm 脚本触发部署变更（如版本升级，集群切换），Git 仓库配置的 ArgoCD Webhook，任何 Helm 脚本的更新会触发通知到 ArgoCD，ArgoCD 会立即把更新同步到集群中，确保集群状态与仓库配置保持一致。

基于 Helm 脚本的自动化编排，已实现基础设施层双集群架构对用户持续部署流程的透明化支撑。具体而言，用户在执行服务部署操作时，无需关注部署到哪个目标集群，除非用户需要进行项目级集群切换，而所有这些操作都可以通过 Jenkins 控制台即可完成。

6. 双集群服务部署策略

为简化双集群服务部署管理，我们制定了如下部署策略：

• 项目级部署：以项目为最小部署单元，禁止拆分部署，一个项目默认仅部署在一个集群）。

• 明确需实时高可用的项目（需严格验证服务无状态性），在双集群同步部署；其余项目均衡分布在双集群中的一个集群，实现资源均衡分布。

• 按复制模式为项目准备双集群配置（如命名空间，ArgoCD 项目，仓库存取权限，用户及权限等），这些可以通过 Jenkins Pipeline 标准化自动创建。

• 第三方通用软件系统（如 ArgoCD，Redis，Nacos），也需要采用异地高可用模式部署，可以在双集群外进行独立部署，也可以在双集群内部署（集群内也采用高可用模式），双集群内部署更便于管理，服务访问效率也高，但需解决跨集群数据同步问题（以免服务切换时丢失状态数据），由于在双集群各自独立部署，需限制它们为集群内访问（禁止 istio 跨集群服务打通）。

• 因此集群内各自部署方式实现相对比较复杂，尤其是数据同步，如果有条件，我们建议在集群外部署。

• 实时高可用的项目，如果服务依赖的第三方通用系统在集群内部署（因此被限制在集群内访问），也需要限制项目服务为集群内访问。

双集群高可用部署架构通过分布式冗余设计，满足金融行业合规标准中关于“两地三中心”灾备体系的数据存储与处理要求。该架构具备跨机房级故障的无缝切换能力，可将 RTO（恢复时间目标）压缩至行业基准阈值内，有效保障核心业务的持续运行。​

在系统迭代场景中，该架构支持基于灰度发布策略的安全升级流程：通过流量切分机制将业务负载引流至一个集群，在另外一个集群完成版本升级及功能验证后，再将流量回迁至已升级集群。此机制适用于集群版本迭代、组件更新及第三方通用服务升级等场景。

该架构的落地，不仅显著提升了业务连续性保障能力，为零中断运维目标提供了坚实支撑；同时，在集群系统版本迭代、第三方通用服务组件升级等场景中，大幅降低了操作风险，使维护团队能够具备更从容的应对空间。