基于 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）

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

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

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

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

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

混合云备份与恢复

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

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

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

总结

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

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

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

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

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

3. 用户在收敛云账号或者组织调整时，需要跨账号集群接入 [ 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 流量分发

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

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

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

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

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

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

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

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