云原生时代怎么应对机房故障

林沐，腾讯云高级工程师，当前负责应用管理平台 TKE AppFabric 的应用高可用和故障自愈产品功能，在云原生、多活容灾、业务连续性等方面有丰富经验。

概述

过去几年大规模自研上云实践中，使用 K8s 按集群维度管理遇到一些问题。例如集群资源不足，需要用户手动更换集群；缺少按可用区维度，需要用户手动挑选多个集群组合；机房故障时缺少统一操作的入口，如批量切流、故障迁移。尽管业界内有按条带化规划集群、通过多集群调度组件部署的案例，但都缺少面向应用、屏蔽集群，聚焦多可用区高可用的容器编排。

TKE 应用管理平台（TKE AppFabric）的一个核心特征，就是通过 TAD（Tencent Application Definition）Yaml 声明，简化容器应用的多活容灾编排流程。业务只需按可用区（Availability Zone，AZ）维度声明期望的分布，无需关注集群概念。例如指定多 AZ 按等比例的部署方式，或者指定多 AZ 且单 AZ 占比不超过上限值的部署方式；流量入口支持多集群跨 AZ 访问，以及变更发布按 AZ 维度进行灰度等。

本文主要介绍，当面临风扇高温、光缆挖断、机房断电、自然灾害等可用区级别的大规模故障时，AppFabric 提供了哪些应对措施。

多活容灾能力的全景图

完整的多活容灾，包括了故障前的部署规范和巡检、故障时的处理，以及故障后的恢复。

我们先看下 AppFabric 的一个应用实例是怎么声明拓扑的。TAD Yaml 中，声明了期望的拓扑分布部署策略。例如，下面的部署策略，声明了该地域期望至少部署在2个 AZ，具体 AZ 根据各个 AZ 的资源库存实况选择（按容量打散），以及单 AZ 副本占比不要超过67%，当2个 AZ 的资源不足时允许调度到其他可用区。

AppFabric 根据部署策略声明，父集群调度器计算出拓扑分布，并下发到子集群，由各个子集群调度器创建具体的 pod。例如，上文部署策略的拓扑分布计算结果如下：期望的20个副本，被分配到两个可用区，广州三区分配10个副本，广州四区分配10个副本（单 AZ 实际占比都是50%，没有超过比例上限67%）。其中，在集群 cls-A 的11的副本中，广州三区分配10个副本，广州四区分配1个副本；在集群 cls-B 的9个副本中，广州四区分配全部9个副本。

AppFabric 是两层调度，第一层父集群负责拓扑分布计算，即分配到哪些 AZ 和每个 AZ 的副本数，以及对应到各个子集群的每个 AZ 副本数。第二层是子集群内的调度，根据父集群的拓扑结果，将 Pod 调度到不同 AZ 节点上。只有在应用实例的副本总数或者部署策略发生改变时，父集群的拓扑计算才会触发。这里是想传达一个信息，当故障发生时，直接销毁重建故障区的 Pod，由于子集群内的拓扑结果还没有改变，仍会尝试在该子集群内调度到故障区。后文会继续展开。

故障发生时，AppFabric 针对受影响的应用实例，会创建应用故障域（App Failure Domain，adomain）。每个应用实例的每个可用区，对应一个 adomain，表示该应用实例受故障区影响，之后的故障操作都围绕该 adomain 进行。故障基本操作包括三大类：流量降级、容量补偿、部署策略降级，以及对应的故障恢复操作。对业务来说，更好的方式是防患于未然，在故障前就做好容灾相关准备。

AppFabric 联合了周边团队，提供了一系列方案：

1）制定了《应用高可用部署标准》，从应用部署、容量管理、自愈管理、流量、实例配置、可观测等方面给出指引。

2）联动云产品稳定性管理平台（Cloud Stability Management，CSM），对 P0 级的高风险项进行巡检；以及对托管的应用实例，当故障发生时，授权 CSM 进行统一流量调度。

3）联动混沌平台，用户可以发起应用级别的可用区故障演练，在混沌平台发起故障注入，并在 AppFabric 执行故障处理流程。

4）联动环境通平台，根据 QA 要求，云产品需要在 DevCloud 网络环境测试后才能发布生产，DevCloud 网络环境提供了安全策略、网络隔离等特殊测试。

以下先介绍 AppFabric 提供的故障处理能力，之后介绍 AppFabric 如何和周边系统联动。

故障的连锁反应

以下先分析一个应用实例遇到AZ故障时，可能面临的问题，然后推导出对应的故障处理操作和恢复流程。流量、容量、分布，是故障发生时主要考虑的三要素。

故障有两种场景，一种是故障已经发生了，例如突发的自然灾害；另外一种是预警，从“潜在”受影响的角度进行处理，例如机房高温可能导致宕机。

1、设想一下，当一个机房高温时，某一个时刻，尽管可能只有部分机器实际受影响，但涉及业务之间的访问链路、机房的网络建设等复杂因素，要准确找出哪些机器受影响很困难。随着时间推移，故障可能在扩散蔓延，存在很大不确定性，例如个别服务进程频繁重启、依赖的第三方服务异常、网络质量时好时坏等。此时，可能想到要切流，按 AZ 维度，将故障区的流量统一禁用，包括北极星和 CLB，以及业务自建的名字服务。

2、随之面临第二个问题，故障区的流量禁用后会转移到正常区。如果正常区的容量没有做好冗余，会导致整个服务过载。主要是两种情况，第一种是多 AZ 副本的分布比例失衡，故障区恰好是占大头。第二种情况跟使用方式相关，HPA 计算平均负载的时候，是按全部副本进行统计的；当故障区的流量禁用后，尽管正常区高负载，但是平均负载仍是低负载，导致扩容失败。此时，可能想到要扩容，或者是将故障区副本迁移到正常区。

3、随之面临第三个问题，扩容或迁移后的拓扑分布要符合部署策略的声明。如果新的拓扑分布违背了部署策略，会导致调度器拓扑计算失败。例如，部署策略声明了指定广州三区和四区等比例部署。假如广州三区故障了需要扩容，根据等比例要求，需要同时分配到广州三区和四区；由于广州三区不能新增副本，导致计算失败。又例如，部署策略声明了默认可用区2 AZ 部署、且关闭可用区扩展。假如已分配到了广州三区和四区，当广州三区故障需要扩容，尽管广州五区有资源，根据声明不允许可用区扩展，没法使用广州五区。这属于部署策略没有考虑兼容故障场景。请注意，不能一刀切认为这种部署策略声明不合理，因为有些业务做了按 AZ 条带化，需要就近访问并指定具体可用区。

由以上分析可知，故障时的操作会牵一发动全身，需要谨慎。最好的应对方式是提前防范，减少故障时的操作。接下来，介绍 AppFabric 提供的故障处理操作。

故障处理的基本操作

故障大屏

当机房故障发生时，运维侧会提供受影响的初步 IP 列表，AppFabric 会匹配出对应的应用实例。考虑到故障扩散和实际影响的不确定性，处理预案是按该应用实例整个 AZ 故障的粒度对待，没有按 IP 粒度。下图展示了个人名下有权限的业务的影响范围，总览部分按“故障区有没有 Pod、这些 Pod 有没有流量”划分为三个维度展示：

1）应用实例在故障区存在 Pod 副本，且这些副本至少有一个 pod 在北极星/CLB Service 中路由未禁用（有流量）。

2）应用实例在故障区存在 Pod 副本，且这些副本在北极星/CLB Service 中路由都禁用，或者名下没有北极星/CLB service。

3）应用实例在故障区不存在 Pod 副本，可能是已将故障区的 Pod 迁移到正常区，但故障还没解除；或者是混沌平台发起的模拟 AZ 故障，恰好是本次故障区，需要由用户确认恢复。

实例明细部分每行对应一个 adomain 的影响，包括应用实例的基本信息、影响副本占比和分布、受影响的路由 Service 及其切流比例，以及可执行的故障操作等。

流量降级

流量降级，是指通过设置切流比例，降低故障 AZ 的 Pod 真实权重，真实权重=路由权重x切流比例。例如：当路由权重=100，切流比例=30%，则真实权重为100*30%=30；当切流比例=0%，则真实权重为100*0%=0，表示路由禁用。

可以筛选一批应用实例，将名下的所有北极星和 CLB Service，分别批量设置切流比例。

1）对一个应用实例，名下可能有多个北极星 Service 或者多个 CLB Service，会对同一类型的 Service 一起设置切流比例。如果单个 Service 有特殊要求，可以在 Service 详情页下单独设置。

2）将北极星和 CLB 分开操作的原因是，现网很多北极星服务下会关联多个工作负载，有其他工作负载备用，切流的时候可能会“激进”一点，例如切流比例1%。但是 CLB 服务下一般只有一个工作负载，以及考虑外网影响，切流的时候可能会“保守”一点，例如切流比例50%，然后再逐步下调直至禁用。

3）之后可以跳转到路由的详情页，查看实际同步情况。

容量补偿

容量补偿的语义，将故障区的容量补偿到正常区。具体细分为三种操作，满足不同场景需求。

扩容，在正常区扩容和故障区同等数量的副本

针对副本数是手动调节的场景，开启“故障自动补偿”后，会将故障区的 Pod 数量追加到副本数中，避免正常区 Pod 过载。例如，原始副本数是7，故障区副本数是2，开启“故障自动补偿”后，补偿后的副本数 = 原始副本数 + 故障区副本数 = 9。

扩容，HPA只统计正常区、不包含故障区

针对副本数是自动调节的场景，开启“故障自动补偿”后，HPA 只使用正常区的负载来计算期望的副本数。由于副本数仍包括了故障区 Pod，所以 HPA 计算后实际副本数 = 正常区期望的副本数 + 故障区的副本数。

迁移，将故障区的副本销毁转移到正常区

上文提到，直接销毁重建故障区的 Pod，由于子集群内的拓扑结果还没有改变，仍会尝试在子集群内调度到故障区。如果期望故障区的副本转移到正常区，可以通过修改部署策略，声明规避故障区。

之后会触发父集群调度器拓扑计算，并进入滚动更新流程，逐步将故障区 Pod 转移到正常区。

部署策略降级

由上文的故障连锁反应可知，部署策略可能会限制扩容。所以在副本数开启“故障自动补偿”时，需要先预判当前部署策略是否会限制扩容。如果需要修改策略，通过模拟调度预测，给用户推荐能扩容的候选部署策略。

不同的部署策略，可能的候选部署策略如下：

故障恢复的确认

前面故障处理的每一个基本操作，本质上是改变应用实例的 TAD Yaml 声明，所以故障恢复本质上是恢复 TAD Yaml 声明。流量、容量、分布，这三个要素由于先后依赖关系，如果涉及多个操作，故障恢复确认的时候，针对不同业务特征要提前评估影响，控制好顺序。可以按副本数是手动调节还是自动调节来划分。

手动调节副本的业务

有状态的服务、或者手动注册路由的服务，一般会声明使用手动调节副本。故障恢复主要涉及流量回切并取消流量降级，以及部署策略的确认。建议的恢复顺序如下：

1）先回切流量，可以通过多次调大切流比例的方式，逐步灰度放量。确认正常后，取消掉流量降级。

2）确认部署策略是要保留当前的（故障过程修改后的）还是恢复到之前的。故障过程对部署策略进行降级，降级后的拓扑分布要比之前的宽松。如果恢复到降级前的部署策略，会导致拓扑分布结果发现变化，拓扑差异部分的 Pod 将被销毁重建。例如，故障前的部署策略是指定广州三区和四区等比例部署，故障时降级为按容量打散并扩容到了广州五区，部署策略确认恢复为故障前的，此时广州五区的 Pod 将被重调度到广州三区和四区。短期方式，建议这种类型的业务提前做好容量冗余，避免故障过程修改为降级的部署策略。长期方式，AppFabric 正在规划指定 Pod 缩容功能，用户可以先自定义先缩掉哪些 Pod，使得拓扑分布兼容降级前的部署策略。例如，故障前部署策略是按容量打散且非等比例分布，降级后是按容量打散且非等比例分布，可以先将非等比例部分 Pod 缩容，然后再恢复回降级前的部署策略。

3）确认故障恢复，删除应用故障域 adomain。

自动调节副本的业务

无状态服务，以及允许自动同步路由的服务，一般会声明使用自动调节副本。故障操作可能多了 HPA 容量补偿。建议的恢复顺序如下：

1）先回切流量，可以通过多次调大切流比例的方式，逐步灰度放量。确认正常后，取消掉流量降级。

2）如果故障区已经回切完全部流量，这时建议取消掉 HPA 容量补偿。如果故障区流量没有完全回切，则不建议取消 HPA 容量补偿，因为故障区副本会拉低整体平均负载，导致正常区过载但扩容不出来。

3）确认部署策略是要保留当前的（故障过程修改后的）还是恢复到之前的。如果恢复到降级前的部署策略，拓扑差异化部分的 Pod 将被销毁重建。这种重建日常弹性伸缩也会发生，理论上对业务没影响。

4）确认故障恢复，删除应用故障域 adomain。

《应用高可用部署标准》解读

《应用高可用部署标准》是《容器部署标准》的补充，主要侧重应用实例的高可用部分。按多活容灾的优先级，依次从应用部署、容量管理、自愈管理、流量、实例配置、可观测等方面给出指引。以下是部分内容。

AppFabric 的一个核心理念，就是将以上标准，固化到应用实例的部署声明中，减少业务的负担。例如，CSM 要求的容灾底线：1）非金融类的，要求多AZ部署，至少两个AZ，最大AZ比例不超过67%；2）金融类的，要求3AZ部署，最大AZ比例不超过50%。在 AppFabric 的部署策略声明中，只要简单配置即可实现。

不限于此，AppFabric 还提供了更严格、更灵活的部署策略，满足不同业务场景的需求。例如指定 AZ 等比例的部署策略，可以满足按 AZ 条带化的业务；模糊可用区按容量且可用区可扩展的部署策略，可以满足按地域容灾、对具体可用区没要求、资源分配优先的业务。

CSM 风险巡检和统一调度

风险巡检和修复建议

尽管 AppFabric 提供了流量、容量、分布对应的故障处理基本操作，由前面的分析可知，故障发生时，这些操作有先后依赖、连锁反应。从业务稳定性出发，建议尽量减少故障时的操作。例如，故障前业务期望的拓扑分布是指定广州三区和四区等比例部署，故障时部署策略降级后尽快能扩容，但可能对上下游的其他服务造成影响。

CSM 要求托管的业务，在平时要维护好多AZ容灾和容量冗余，故障发生时只进行流量降级操作，因为容量补偿不一定来得及、或者新扩容的 Pod 不一定正常（例如，挂载了受故障蔓延影响的云盘），以及部署策略降级打破原来的拓扑分布可能带来其他影响。

CSM 对《应用高可用部署标准》中相关指标进行日常巡检，并周知业务修复，确保故障发生时的业务连续性。例如以下涉及多 AZ 容灾和容量冗余的风险项。

应用实例托管和故障调度

根据过往经验，出现机房大规模故障的时候，导致业务调度切换效率慢的原因有两个：

1）机房故障涉及的产品团队众多，各产品调度系统不统一，甚至有些产品没有调度系统。

2）各个产品上云后，互相依赖、循环依赖可能性增加，业务系统架构也相应变复杂，各产品需要有序调度才能快速恢复。调度系统是各个产品的共性需求，CSM（云产品稳定性管理 Cloud Stability Management）通过统一调度管控系统，来提升切换效率。

CSM 对托管的应用实例，故障发生时会进行统一调度切流，故障恢复后统一回切。

CSM 切流和回切，底层调用的是流量降级接口。由于 AppFabric 的故障基本操作都是声明式的，所以在 CSM 和 AppFabric 上进行流量降级，是先后覆盖的。

混沌模拟可用区故障演练

当实际故障发生时，针对受影响的应用实例，AppFabric 会创建对应的应用故障域 adomain，之后用户的故障操作都围绕该故障域进行。当故障恢复后，AppFabric 会自动删除该 adomain，只有那些遗留故障操作未取消的，才需要用户手动确认故障恢复并删除 adomain。

日常中通过混沌演练平台，可以发起模拟应用级别的故障域，演练 AZ 故障时的操作流程。混沌创建的 adomain，AppFabric 不会自动删除，由用户确认故障恢复后删除。

1）编排演练动作“故障域”，并执行。例如这里针对某个应用实例，编排了广州四区的“故障域”。执行该动作时，会创建相应的 adomain，模拟收到运维侧通知该应用实例受影响。

2）在 AppFabric 的故障大屏上，可以看到该应用实例并进行故障操作。

3）在编排中可以添加其他动作，注入故障，模拟 Pod 真实受影响。例如这里编排了广州四区的“故障域”和“Pod Failure"两个动作，“Pod Failure"表示容器宕机。

环境通 DevCloud 网络环境测试

根据QA要求，云产品需要在 DevCloud 网络环境测试后才能发布生产，DevCloud 网络环境提供了安全策略、网络隔离等特殊场景测试。环境通平台支持业务配置模板，将业务链路关联的多个应用实例打包部署到 AppFabric 的 DevCloud 网络环境。

之后用户可以在 DevCloud 平台配置应用实例的网络策略，实现业务全链路网络隔离的测试。

总结与展望

以上内容从屏蔽集群、聚焦多 AZ 高可用的视角，介绍了腾讯云 TKE AppFabric 如何简化容器应用的多活容灾编排。分析了故障时流量、容量、分布的连锁反应，阐述了 AppFabric 在面对可用区级别的大规模故障时提供的应对措施，包括流量降级、容量补偿、部署策略降级等通用操作，并介绍了如何通过《应用高可用部署标准》、CSM 风险巡检和统一调度、混沌模拟可用区故障演练以及环境通 DevCloud 网络环境测试来提升业务的容灾能力。

接下来，AppFabric 会继续完善故障场景和应对能力。

1）打磨用户体验：AppFabric 正在规划根据不同业务特征，推荐故障处理和恢复的流水线交互最佳实践，让用户的每一步操作能提前预知操作的影响和结果。进一步的，对符合《应用高可用部署标准》的应用实例，支持用户提前声明自愈策略，当故障发生时，自动处理。

2）扩展应用场景：机房故障发生的频次不高，日常更多遇到的是机房裁撤、机型腾挪、集群故障、Pod Pending 重调度等。AppFabric 正在完善这些场景的支持，通过自愈方式，让用户无感知。

参考资料

• TAD（Tencent Application Definition）：https://cloud.tencent.com/developer/article/2029518