基于 K8s 容器集群的容灾架构与方案-每日运维

作者：庄宇

在设计系统架构时，我们必须假设任何组件和任何基础设施可能会在任何时间失效，例如：自然灾害，电力中断，网络中断，错误的系统变更等。为了应对挑战，我们必须设计合适的容灾架构。

本文介绍如何以 K8s 集群（包括：ACK 集群，他云集群和本地 IDC K8s 集群）为基础，结合阿里云云产品（网络，数据库，中间件，可观测），设计容灾架构，构建一个“韧性”系统。

容灾目标

Recovery time objective（RTO）：

服务中断与服务恢复之间可接受的最大延迟时间。决定服务停机的可接受时长。

Recovery point objective（RPO）：

自上一个数据恢复点以来可接受的最大时间量。决定可接受的数据丢失或重建。

对于 RTO 和 RPO，数值越低代表停机时间和数据丢失越少，但是越低的 RTO 和 RPO 会导致资源成本和运维复杂性越高。因此，您需要根据工作负载的重要性，指定适当的 RTO 和 RPO。

容灾策略

上图中，描述的常见的 3 种容灾策略：备份与恢复、主备、双活，不同的容灾策略对应了不同的收益和成本。您需要综合分析业务的重要性、风险、可投入的成本等，以选择适合的容灾策略。

备份与恢复（Backup-Restore）

在系统运行时，备份应用和数据，在灾难发生时，在另一个地点恢复应用和数据，并切换业务流量。由于数据无法实时备份，在恢复数据时会有一定的数据丢失，同时如果数据量较大，恢复数据时间可能较长。

主备（Active-Standby）

在主备模式中，主 Location 处理所有的业务流量，备用 location 可以启动较少的应用实例节省成本，并周期发送测试流量以验证系统有效性。在灾难发生时，做数据库主备切换，扩容应用实例数，并切换业务流量。

双活（Active-Active）

在双活模式中，2 个 Location 启动相同的应用实例数，同时处理业务流量。在灾难发生时，做数据库主备切换，并切换业务流量。

容灾范围

多可用区（Multi-AZ）

阿里云地域（Region） [ 11] 包含多个可用区（AZ），可用区（AZ）是电力和网络互相独立的物理区域，对停电，断网等局部中断的容灾场景，可以使用多个可用区（AZ）设计容灾策略。由于可用区间的网络延时较短，可以更容易实现数据部分的容灾方案，包括数据库、缓存和消息等。

多地域（Multi-Region）

为了应对更大范围的灾难故障事件，这些事件可能会影响同地域（Region）的多个可用区（AZ），您可以使用多个地域（Region）设计容灾策略。但由于地域间更大网络延时，容灾方案复杂度和实现成本较高。

在选择多可用区（AZ）或者多地域（Region）容灾方案时，需要重点考虑有状态应用和依赖的云产品（例如：数据库、缓存和消息）是否支持多地域或者多可用区容灾。

方案示例

备份与恢复（Backup & Restore）

公共云跨可用区和跨地域备份与恢复

通过 ACK One 备份中心 [3 ] ，可以备份 ACK 集群中的应用，包括无状态应用和有状态应用，对有状态应用，在备份应用 YAML 的同时可以备份相关 Storage 数据。

ACK One 备份中心集成云产品云盘快照 [ 12] ，文件存储 NAS [13 ] ，对象存储 OSS [14 ] 和云备份 [15 ] ，分别支持应用 YAML，云盘 PV，文件系统 PV 的一键备份。

备份后，可以随时将应用和 Storage 数据，恢复到任意地域和可用区的 ACK 集群。

阿里云数据库服务的备份与恢复，可以参考相应数据产品的文档，例如：RDS MySQL 数据库备份恢复 [ 16] ，RDS 实例间数据迁移 [17 ] 。

混合云备份与恢复

通过 ACK One 注册集群 [ 4] ，可以将 IDC 自建或者非阿里云 K8s 集群，接入到阿里云 ACK 控制台。

接入 ACK One 注册集群后，通过 ACK One 备份中心，可以备份 IDC 自建和非阿里云 K8s 集群中的应用，包括无状态应用和有状态应用，对有状态应用，在备份应用 YAML 的同时可以备份相关 Storage 数据。

备份后，可以随时将应用（Deployment/Statefulset）和数据（PV/PVC），恢复到任意地域和可用区的 ACK 集群。

总结

备份恢复方案实施成本较低，但 RTO 和 RPO 相对较长，取决于数据量的大小和应用的复杂度。备份中心能够提供的全量备份+增量备份能力，减少 RTO 和 RPO 时间。

备份恢复作为容灾的兜底方案，重要性高，在系统运维的过程中，要保证备份的及时性和可恢复性。

另外，许多用户选择通过备份恢复功能实现应用的跨集群迁移，场景如下：

业务上云，将本地 IDC 集群中的应用，迁移到阿里云 ACK 集群中，参考 IDC 应用上云迁移 [ 18] 。

集群版本较老，版本升级有稳定性风险，可以先创建新版本集群，通过备份恢复将应用迁移到新版本集群运行，参考跨版本集群迁移 [ 19] 。

用户在收敛云账号或者组织调整时，需要跨账号集群接入 [ 20] 和跨集群迁移应用 [21 ] 。

多集群 Service

在应用迁移的过程中，由于应用的数量较多，需要分批迁移，同时应用间存在调用关系。此时，在网络打通的前提下，可以使用 ACK One 舰队多集群 Service [ 5] ，实现应用 Kubernetes Service 跨集群访问。如下图所示，ACK One 舰队多集群 Service，可以将 Cluster1 的 Applcation2 的 Kubernetes Service（包含 endpoints）注入到 Cluster2，Cluster2 上的 Application1 可以访问 Cluster1 上的 Application2。

在专线拉通的前提下，通过 ACK One 注册集群，IDC 和非阿里云的 K8s 集群也可以是用 ACK One 舰队多集群 Service。

单地域多可用区容灾

基于 DNS 流量分发

通过 ACK One GitOps 应用分发 [6 ] ，在 2 个 ACK 集群中部署应用，实现基于 Git 仓库的持续一致性部署。

通过全局流量管理（GTM） [22 ] 做 DNS 解析实现负载分发，并监控系统运行健康状态，自动触发容灾切换。

每个 AZ 内，通过 ACK Ingress [ 7] 实现 7 层流量管理。

备集群和主集群的应用版本相同，但备集群节点较少，应用副本较少，节省成本。

在主系统不可用时，全局流量管理（GTM）会将服务域名 DNS 解析到备用系统，完成主备切换。

由于流量的增长，备集群中 ACK HPA [8 ] 会扩容应用副本，进而触发 ACK Cluster Autocaler [9 ] 扩容集群节点。

阿里云中间件（消息，缓存）的跨可用区容灾，可参考相关文档，例如：云消息队列 RocketMQ 版实例规格 [ 23] ，云消息队列 Kafka 版实例规格 [ 24] ，云原生内存数据库 Tair 容灾方案 [ 25] 。

阿里云数据库服务的跨可用区容灾，可参考相关文档，例如：RDS MySQL 数据库搭建高可用架构 [ 26] 。

🔔 注意：

本方案基于 DNS 流量转发，由于 DNS 缓存，在灾难事件发生时，部分业务依然路由到主系统，造成一定的业务损失。

需要在 2 个集群中分别配置维护 7 层 ingress 规则，成本高。系统正常运行状态：

灾难事件发生，AZ 不可用时，系统主备切换，GTM 将流量切换到 AZ2，ACK Cluste2 的应用实例自动扩展，中间件和数据库多可用区高可用切换。

基于 ACK One 多集群网关

通过 ACK One GitOps 应用分发，在 2 个 ACK 集群中部署应用，实现基于 Git 仓库的持续一致性部署。

通过 ACK One 多集群网关 [ 10] ，定义标准 K8s Ingress 规则（YAML 格式），实现 7 层流量治理，实现流量的主备模式分发。多集群网关为跨可用区高可用。

备集群和主集群的应用版本相同，但备集群节点较少，应用副本较少，节省成本。可以发送特定 http header 的测试流量，多集群网关转发到备集群以验证工作状态。

在主系统不可用时，ACK One 多集群网关会自动将业务流量备用系统，完成主备切换。

由于流量的增长，备集群中 ACK HPA 会扩容应用副本，进而触发 ACK Cluster Autocaler 扩容集群节点。

阿里云数据库服务的跨可用区容灾，可参考相关文档，例如：RDS MySQL 数据库搭建高可用架构。

🔔 注意：

本方案为 HTTP 七层流量转发，配合 7 层健康检查，主备切换时相比 DNS 方案，大幅减低业务流量损失。

网关侧统一支持基于 Ingress 规则的流量治理，相比 DNS 方案，合并了四层负载均衡 SLB 和七层 Ingress 网关，降低系统复杂度和维护成本。

系统正常运行状态：

灾难事件发生，AZ 不可用时，系统主备切换，多集群网关（MSE 云原生网关）自动将流量切换到 AZ2 的 ACK Cluste2 中，应用实例自动扩展。

跨可用区双活

以上 2 个方案以主备模式为例，描述了系统架构。同样的架构，基于 DNS 流量分发和 ACK One 多集群网关也支持双活场景，可以配置流量分发比例（例如：50% : 50%），支持自动 failover 切换。在双活的场景下，每个集群中的应用副本数，需要根据流量分发比例确定，集群中需要配置弹性伸缩，以支持流量切换情况下的流量增长。

总结

单地域多可用区方案实现的成本较低，可以利用云产品（包括：网关，容器，中间件，数据库）多可用区部署和多可用区高可用，快速实现容灾，对业务改造较小。但此方案仅可应对单个可用区的灾难和故障，无法应对地域级的灾难故障。

单地域云+IDC 容灾方案

方案架构与单地域多可用区容灾方案类似，要点如下：

云上 VPC 与 IDC 建立专线连接，打通管控与数据通道。

通过 ACK One 注册集群接入 IDC 集群，使用阿里云强大可观测和安全能力，统一管理 IDC 集群和 ACK 集群。

通过 ACK One GitOps 应用分发，在 2 个集群中部署应用，实现基于 Git 仓库的持续一致性部署。

基于 DNS 流量分发（单地域云上和云下双活）

基于 ACK One 多集群网关（单地域云上和云下双活）

多地域容灾

如果业务规模大重要性高，服务的用户数量多范围广，单地域的容灾方案就无法满足业务高可用要求，这时需要多地域容灾方案。在多个地域独立部署业务系统，保证每个地域的业务系统具有单独闭环提供完整的服务能力。

通过全局流量管理（GTM）实现用户就近接入相应地域。

通过 ACK One GitOps 应用分发，在 2 个 ACK 集群中部署应用，实现基于 Git 仓库的持续一致性部署。

缓存多地域高可用方案，可以参考阿里云产品相关文档，例如：Tair 全球多话 [ 27] 。

数据库跨地域高可用方案，可以参考阿里数据库云产品相关文档，例如：云原生数据库 PolarDB MySQL 全球数据库 [ 28] 。

地域内，可以采用单地域多可用区容灾方案。

单元化多活部署

区别与前一方案，多地域单元化多活部署，需要设计分片规则对应用和数据进行分片，使得单元提供面向部分数据分片的完整服务能力，实现业务安全故障隔离，水平扩展，服务庞大的用户群体。一般分为中心单元（拥有所有用户数据）和多个子单元（分片后详细数据）。此种方式需要业务系统支持，自定义分流规则，数据拆分，单元间配合等，复杂度高。

总结

各种灾难事件会影响您业务的可用性，通过使用阿里云的相关云产品的容灾能力，可以减轻或者消除这些影响。首先，需要了解业务可用性需求，从而选择一个适当的容灾策略，然后，使用阿里云相关云产品，包括：容器（容器服务 Kubernetes 版 ACK [ 1] 和分布式云容器平台 ACK One [ 2] ）、消息、缓存、数据库等，设计容灾架构，快速达到您业务可用性要求的恢复时间目标 RTO 和恢复点目标 RPO。

基于 K8s 容器集群的容灾架构与方案

容灾目标