Azure Kubernetes 服务的区域复原建议（AKS）

区域复原是运行生产级 Kubernetes 群集的关键部分。 借助其核心的可伸缩性，Kubernetes 充分利用数据中心内的独立基础结构，并且仅在必要时预配新节点不会产生额外的成本。

本文介绍 Azure Kubernetes 服务（AKS）中区域复原的各种建议，包括如何：

• 使 AKS 群集组件区域具有复原能力
• 设计无状态应用程序
• 做出存储磁盘决策
• 测试可用性区域 （AZ） 复原能力

使 AKS 群集组件区域具有复原能力

以下部分提供了有关使 AKS 群集组件区域具有复原能力的主要决策点的指导，但它们并不详尽。 应根据特定的要求和约束考虑其他因素，并检查其他依赖项，以确保为区域复原配置它们。

创建区域冗余群集和节点池

AKS 允许在群集和节点池创建过程中选择多个 AZ。 在具有多个 AZ 的区域中创建群集时，控制平面会自动分散到该区域中的所有 AZ。 但是，节点池中的节点仅分布在选定的 AZ 中。 此方法可确保控制平面和节点分布在多个 AZ 之间，从而在发生 AZ 故障时提供复原能力。 可以使用 Azure 门户、Azure CLI 或 Azure 资源管理器模板配置 AZ。

以下示例演示如何使用 Azure CLI 创建包含三个节点的群集，该群集分布在三个 AZ 中：

az aks create --resource-group $RESOURCE_GROUP --name $CLUSTER_NAME --generate-ssh-keys --vm-set-type VirtualMachineScaleSets --load-balancer-sku standard --node-count 3 --zones 1 2 3

创建群集后，可以使用以下命令从标签中检索每个代理节点的区域和可用性区域：

kubectl describe nodes | grep -e "Name:" -e "topology.kubernetes.io/zone"

以下示例输出显示了每个代理节点的区域和可用性区域：

Name:       aks-nodepool1-28993262-vmss000000
            topology.kubernetes.io/zone=chinanorth3-1
Name:       aks-nodepool1-28993262-vmss000001
            topology.kubernetes.io/zone=chinanorth3-2
Name:       aks-nodepool1-28993262-vmss000002
            topology.kubernetes.io/zone=chinanorth3-3

有关详细信息，请参阅 Azure Kubernetes 服务（AKS）中的使用可用性区域。

确保 Pod 分布在 AZ 之间

从 Kubernetes 版本 1.33 开始，AKS 中的默认 Kube-Scheduler 配置为使用 MaxSkew 值 1， topology.kubernetes.io/zone 如下所示：

topologySpreadConstraints:
- maxSkew: 1
  topologyKey: "topology.kubernetes.io/zone"
  whenUnsatisfiable: ScheduleAnyway

此配置通过针对区域之间的单个 Pod 差异来偏离上游默认值。 因此，Pod 更均匀地分布在各个区域，从而减少区域性故障导致相应部署中断的可能性。

但是，如果部署具有特定的拓扑需求，可以通过在 Pod 规范中添加自己的默认值来替代上述默认值。可以使用基于zonehostname和标签的 Pod 拓扑分散约束，将 Pod 分散到区域中的 AZ 和 AZ 中的主机之间。

例如，假设你有一个四节点群集，其中三个 Pod 分别app: mypod-app位于node1其中， node2node3 如果希望尽可能多地将传入部署托管在不同的节点上，则可以使用类似于以下示例的清单：

apiVersion: v1
kind: Deployment
metadata:
  name: mypod-deployment
  labels:
    app: mypod-app
spec:
  replicas: 3
  selector:
    matchLabels:
      app: mypod-app
  template:
    metadata:
      labels:
        app: mypod-app
    spec:
      topologySpreadConstraints:
      - maxSkew: 1
        topologyKey: "kubernetes.io/hostname"
        whenUnsatisfiable: ScheduleAnyway
      containers:
      - name: pause
        image: registry.k8s.io/pause

有关配置 Pod 分发并了解其含义 MaxSkew的详细信息，请参阅 Kubernetes Pod 拓扑文档。

配置 AZ 感知网络

如果有为网络流量提供服务的 Pod，则应在多个 AZ 之间对流量进行负载均衡，以确保应用程序高度可用且可复原故障。 可以使用 Azure 负载均衡器 在 AKS 群集中的节点之间分配传入流量。

Azure 负载均衡器支持内部和外部负载均衡，并且可以将其配置为使用 标准 SKU 进行区域冗余负载均衡。 标准 SKU 是 AKS 中的默认 SKU，它支持 可用性区域 的区域复原，以确保应用程序不受区域故障的影响。 如果发生区域故障方案，区域冗余的标准 SKU 负载均衡器不会受到故障的影响，并且使部署能够继续为来自剩余区域的流量提供服务。 可以使用全局负载均衡器（例如 Front Door 或 流量管理器），也可以在区域 AKS 群集前面使用 跨区域负载均衡器 ，以确保应用程序不受区域故障的影响。 若要在 AKS 中创建标准 SKU 负载均衡器，请参阅 在 Azure Kubernetes 服务（AKS）中使用标准负载均衡器。

为了确保应用程序的网络流量能够复原到故障，应为 AKS 工作负载配置 AZ 感知网络。 Azure 提供支持 AZ 的各种网络服务：

• Azure VPN 网关：可以在 Azure AZ 中部署 VPN 和 ExpressRoute 网关，以便更好地实现虚拟网络网关的复原能力、可伸缩性和可用性。 有关详细信息，请参阅 在可用性区域中创建区域冗余的虚拟网络网关。
• Azure 应用程序网关 v2：Azure 应用程序网关为区域 L7 负载均衡器提供可用性区域支持。 有关详细信息，请参阅 使用 Azure 应用程序网关的直接 Web 流量。

设置区域冗余的异地复制容器注册表

若要确保容器映像高度可用且可复原故障，应设置区域冗余容器注册表。 Azure 容器注册表（ACR）高级 SKU 支持异地复制和可选的区域冗余。 这些功能提供可用性并减少区域作的延迟。

确保密钥和机密的可用性和冗余

Azure Key Vault 提供多层冗余，以确保密钥和机密仍可供应用程序使用，即使服务的各个组件发生故障，或者 Azure 区域或 AZ 不可用也是如此。 有关详细信息，请参阅 Azure Key Vault 可用性和冗余。

利用自动缩放功能

可以使用自动缩放功能提高 AKS 中的应用程序可用性和复原能力，从而帮助你实现以下目标：

• 根据 Pod 的 CPU 和内存使用率来纵向扩展或缩减资源利用率和成本效益。
• 在发生区域故障时添加更多节点或 Pod，从而提高容错和恢复能力。

可以使用 水平 Pod 自动缩放程序（HPA） 和 群集自动缩放程序 在 AKS 中实现自动缩放。 HPA 根据观察到的 CPU 使用率、内存利用率、自定义指标和其他服务的指标自动缩放部署中的 Pod 数。 群集自动缩放程序根据节点上运行的 Pod 的资源请求自动调整节点池中的节点数。 如果要同时使用这两个自动缩放程序，请确保启用了自动缩放程序的节点池跨多个区域。 如果节点池位于单个区域且该区域出现故障，则自动缩放程序无法跨区域缩放群集。

AKS Karpenter 提供程序预览功能可在 AKS 群集上使用 Karpenter 启用节点自动预配。 有关详细信息，请参阅 AKS Karpenter 提供程序功能概述。

AKS 的 Kubernetes 事件驱动自动缩放（KEDA） 加载项应用事件驱动的自动缩放功能，以便根据外部服务的指标缩放应用程序以满足需求。 有关详细信息，请参阅 在 Azure Kubernetes 服务（AKS）中安装 KEDA 加载项。

设计无状态应用程序

当应用程序 无状态时，应用程序逻辑和数据被分离，Pod 不会在其本地磁盘上存储任何持久性或会话数据。 此设计使应用程序可以轻松纵向扩展或缩减，而无需担心数据丢失。 无状态应用程序对故障更具复原能力，因为在发生节点故障时，可以在其他节点上轻松替换或重新计划这些故障。

使用 AKS 设计无状态应用程序时，应使用托管的 Azure 服务（例如 Azure 数据库、 Azure Redis 缓存或 Azure 存储 ）来存储应用程序数据。 使用这些服务可确保流量可以跨节点和区域移动，而不会造成数据丢失或影响用户体验的风险。 可以使用 Kubernetes 部署、服务和运行状况探测来管理无状态 Pod，并确保均匀分布到各个区域。

做出存储磁盘决策

根据应用程序需求选择正确的磁盘类型

Azure 为永久性存储提供两种类型的磁盘：本地冗余存储（LRS）和区域冗余存储（ZRS）。 LRS 在单个 AZ 中复制数据。 ZRS 跨区域中的多个 AZ 复制数据。 从 AKS 版本 1.29 开始，默认存储类使用 ZRS 磁盘进行持久存储。 有关详细信息，请参阅 AKS 内置存储类。

应用程序复制数据的方式可能会影响你选择的磁盘。 如果应用程序位于多个区域并从应用程序中复制数据，则可以在每个 AZ 中使用 LRS 磁盘实现复原能力，因为如果一个 AZ 出现故障，其他 AZ 将具有可用的最新数据。 如果应用程序层未处理此类复制，ZRS 磁盘是更好的选择，因为 Azure 处理存储层中的复制。

下表概述了每种磁盘类型的优缺点：

有关 LRS 和 ZRS 磁盘类型的详细信息，请参阅 Azure 存储冗余。 若要在 AKS 中预配存储磁盘，请参阅 在 Azure Kubernetes 服务（AKS）中预配 Azure 磁盘存储。

监视磁盘性能

为了确保 AKS 中存储磁盘的最佳性能和可用性，应监视关键指标，例如 IOPS、吞吐量和延迟。 这些指标可帮助你识别可能影响应用程序性能的任何问题或瓶颈。 如果发现任何一致的性能问题，可能需要重新考虑存储磁盘类型或大小。 可以使用 Azure Monitor 收集和可视化这些指标，并设置警报以通知你任何性能问题。

有关详细信息，请参阅 使用 Azure Monitor 监视 Azure Kubernetes 服务（AKS）。

测试 AZ 复原能力

方法 1：单个 AZ 中的 Cordon 和清空节点

测试 AKS 群集的 AZ 复原能力的方法之一是清空一个区域中的节点，并了解它如何影响流量，直到它故障转移到另一个区域。 此方法模拟一个实际方案，其中整个区域由于灾难或中断而不可用。 若要测试此方案，可以使用 kubectl drain 该命令从节点中正常逐出所有 Pod，并将其标记为不可计划。 然后，可以使用 Azure Monitor 或 Prometheus 等工具监视群集流量和性能。

下表概述了此方法的优缺点：

方法 2：使用 Azure Chaos Studio 模拟 AZ 故障

测试 AKS 群集的 AZ 复原能力的另一种方法是将故障注入群集，并使用 Azure Chaos Studio 观察对应用程序的影响。 Azure Chaos Studio 是一项服务，可用于在 Azure 资源和服务上创建和管理混沌试验。 可以使用 Chaos Studio 通过创建针对特定区域的故障注入试验来模拟 AZ 故障，并停止或重启该区域中的虚拟机（VM）。 然后，可以使用指标和日志来度量应用程序的可用性、延迟和错误率。

下表概述了此方法的优缺点：