跨可用区容灾架构设计：TKE 多 AZ 部署保障业务连续性

摘要：

跨可用区部署是保障业务连续性的基础架构策略。本文介绍基于 TKE 构建多可用区容灾架构的设计方案，涵盖控制面高可用、工作负载分散调度和故障自动恢复等关键实践。

一、业务连续性对现代企业的重要性

在数字化时代，系统可用性直接关系到企业的营收和声誉。一次意外的服务中断可能导致用户流失、订单损失和品牌信任度下降。对于电商、金融、医疗等关键行业，几分钟的停机就可能造成难以估量的经济损失。因此，构建具备容灾能力的技术架构已成为企业基础设施建设的核心议题。

1.1 可用区——云原生的容灾基本单元

可用区是云数据中心的基本容灾单元。每个可用区拥有独立的电力、制冷和网络设施，单一可用区的故障不会波及其他可用区。通过在多个可用区部署应用实例，可以有效抵御单点故障带来的风险。腾讯云容器服务 TKE 标准集群原生支持跨可用区部署，为构建高可用的容器化应用提供了坚实的基础。

1.2 容灾层级的选择

在设计容灾架构时，需要根据业务的重要性和恢复目标来选择合适的策略。同城多可用区部署是最常见的高可用方案，能够在单个数据中心发生故障时保持服务不中断。这种方案的建设和运维成本相对较低，适合大多数业务场景。

对于要求更高的业务，可以考虑跨地域的多集群部署。通过在相距较远的不同地域各部署一套完整的系统，即使整个城市级别的基础设施出现问题，也能通过流量切换保证服务的持续可用。TKE 的注册集群功能支持统一管理腾讯云上集群、第三方服务商集群和自建机房集群，为实现跨地域容灾提供了管理工具。

二、TKE 多可用区集群架构

2.1 控制面的高可用设计

TKE 托管集群的控制面由腾讯云统一管理和维护，天然具备高可用能力。控制面组件分布在多个可用区中运行，即使某个可用区出现故障，其他可用区的副本仍能正常处理 API 请求。集群规格的选择直接影响控制面的承载能力，L500 及以上规格可支持数千个节点和上万个 Pod 的稳定运行。

在创建集群时，建议至少选择三个可用区进行 Master 和 Etcd 节点的部署。这样即使一个可用区完全不可用，剩余的多数派仍然能够维持 etcd 集群的正常运行，确保控制面的数据一致性。

2.2 工作节点的跨区分布

工作节点的跨可用区分布是实现容灾的关键环节。在 TKE 中添加节点时，可以选择不同的可用区进行部署。建议在每个可用区都部署足够数量的节点，确保任意一个可用区故障后，剩余容量仍能满足业务的最低运行需求。

apiVersion: apps/v1
kind: Deployment
metadata:
  name: web-service
spec:
  replicas: 6
  selector:
    matchLabels:
      app: web-service
  template:
    spec:
      topologySpreadConstraints:
      - maxSkew: 1
        topologyKey: topology.kubernetes.io/zone
        whenUnsatisfiable: DoNotSchedule
        labelSelector:
          matchLabels:
            app: web-service
      containers:
      - name: web
        image: nginx:1.25
        resources:
          requests:
            cpu: "250m"
            memory: "256Mi"

上述配置展示了如何通过拓扑分布约束来实现 Pod 在可用区之间的均匀分布。maxSkew 设置为 1 表示任意两个可用区之间的 Pod 数量差不超过 1，DoNotSchedule 策略确保新 Pod 只会被调度到满足分布要求的可用区中。

三、服务层面的容灾策略

3.1 负载均衡的跨区流量分发

当服务的后端 Pod 分布在多个可用区时，前端流量的均衡分发至关重要。腾讯云负载均衡 CLB 支持跨可用区挂载后端服务器，可以自动将请求分发到健康的 Pod 实例上。结合健康检查机制，当某个可用区的实例出现异常时，流量会自动转移到其他可用区的健康实例。

在服务定义中，可以通过设置外部流量策略来控制负载均衡的行为。Local 模式会将流量仅转发到本节点的 Pod，减少跨节点的网络跳数；Cluster 模式则允许流量被转发到集群中的任意 Pod，更好地利用所有可用区的容量。

3.2 有状态服务的跨区持久化

对于数据库等有状态服务，跨可用区部署需要特别考虑数据的持久化和一致性问题。腾讯云提供了多种支持跨可用区的存储服务。云硬盘 CBS 支持在可用区内的高可靠存储，而云数据库 TencentDB 则提供了跨可用区的自动主从切换能力。

在 Kubernetes 层面，StorageClass 可以配置为支持特定可用区的动态卷分配。当 Pod 被调度到某个可用区时，其关联的持久卷也会在同一可用区内创建，避免了跨区访问存储带来的延迟问题。

四、故障检测与自动恢复

4.1 节点故障自愈

TKE 提供了自研的故障检测和自愈能力。当某个节点因为硬件故障或网络中断而无法响应时，系统会自动检测到异常并将该节点标记为不可调度。运行在该节点上的 Pod 会被重新调度到其他健康的节点上，整个过程无需人工干预。

相比社区版的 NPD 节点问题检测器，TKE 的自研方案提供了更快的故障识别速度和更丰富的故障类型覆盖。配合弹性伸缩能力，当故障导致集群容量不足时，系统会自动创建新的节点补充资源缺口。

4.2 应用层的健康检查

除了基础设施层面的监控，应用层的健康检查同样重要。Kubernetes 支持存活检查和就绪检查两种健康检查方式。存活检查用于检测容器是否仍在正常运行，当检查失败时会自动重启容器。就绪检查则用于判断 Pod 是否准备好接收流量，未通过的 Pod 不会被加入服务的后端列表。

containers:
- name: api-server
  image: myapp/api:v2.0
  livenessProbe:
    httpGet:
      path: /healthz
      port: 8080
    initialDelaySeconds: 30
    periodSeconds: 10
    failureThreshold: 3
  readinessProbe:
    httpGet:
      path: /ready
      port: 8080
    initialDelaySeconds: 5
    periodSeconds: 5
    failureThreshold: 1

合理的探针配置能够在应用出现异常时快速做出反应，同时避免因短暂波动导致的误判。对于跨可用区部署的场景，建议适当延长初始延迟时间，给新启动的 Pod 足够的初始化窗口。

五、容灾演练与持续优化

构建容灾架构只是第一步，定期验证其有效性同样重要。建议制定常态化的故障演练计划，模拟可用区级别的故障场景，观察系统的自动恢复表现。通过演练可以发现潜在的配置问题和流程缺陷，持续完善容灾体系。

TKE 的监控告警功能为容灾状态的日常监控提供了有力工具。丰富的监控指标覆盖了集群、节点和服务各个层面，支持自定义告警策略。当跨可用区的 Pod 分布出现不均衡或某个可用区的节点大量下线时，运维团队能够及时收到告警并采取相应措施。

多云环境下的容灾还可以借助 TKE 的注册集群能力实现统一管理。无论是腾讯云上的标准集群，还是其他云服务商或自建数据中心的 Kubernetes 集群，都可以纳入同一个管理平台，实现跨云资源的统一调度和灾备切换。

一次可用区故障可能让你的业务停摆数小时甚至数天。TKE 多 AZ 部署和自动故障自愈能力，为你的业务构建"永远在线"的容灾防线 → https://cloud.tencent.com/product/tke