Azure Kubernetes 服务 (AKS) 的区域弹性建议

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

在本文中，你将了解 AKS 中的区域复原建议，包括如何：

• 使 AKS 群集组件区域具有复原能力。
• 为区域故障方案设计无状态应用程序。
• 选择存储冗余选项。
• 在区域性故障期间测试应用程序和平台行为。

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

以下部分介绍 AKS 中区域复原的关键决策点。 它们并不详尽。 还应验证依赖项的区域复原能力，例如数据存储、标识系统和外部服务。

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

AKS 允许在群集和节点池创建过程中选择多个 AZ。 在支持多个 AZ 的区域中，控制平面会自动分散到各个区域。 节点池节点分布在所选区域中。 此方法可确保控制平面和节点分布在多个 AZ 之间，从而在发生 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 的 topology.kubernetes.io/zone 值设为 1：

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

此配置的目标不超过区域之间的单个 Pod 差异，从而减少区域性故障导致部署中断的可能性。

如果您的部署有特定的拓扑需求，请在 Pod 规范中覆盖这些默认设置。您可以使用基于 zone 和 hostname 标签的 Pod 拓扑分布约束，将 Pod 分布到区域内的各个 AZ，以及各个 AZ 内的不同主机上。

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

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 拓扑文档。 例如，nodeTaintsPolicy: Honor 如何影响 Pod 分布。

配置 AZ 感知网络

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

Azure 负载均衡器同时支持内部和外部负载均衡，并且可以将其配置为使用 Standard SKU 进行区域冗余负载均衡。 标准 SKU 是 AKS 中的默认 SKU，它支持使用 availability zones 的区域复原，以确保应用程序不受区域故障的影响。 在发生区域故障的情况下，区域冗余标准 SKU 负载均衡器不会受到故障的影响，并使您的部署能够继续处理来自剩余区域的流量。 可以使用全局负载均衡器，例如 Front Door 或 Traffic Manager，或者，可以在区域 AKS 群集前面使用跨区域负载均衡器，以确保应用程序不受区域故障的影响。 若要在 AKS 中创建标准 SKU 负载均衡器，请参阅 在 Azure Kubernetes 服务 (AKS) 中使用标准负载均衡器。

为了确保应用程序的网络流量具备故障恢复能力，您应为 AKS 工作负载配置可用区（AZ）感知网络。 Azure提供各种支持 AZ 的网络服务：

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

设置区域冗余和地理复制的容器镜像库

为了确保容器镜像的高可用性和故障复原能力，您应该设置一个区域冗余的容器注册表。 Azure 容器注册表（ACR） Premium SKU 支持 地理复制 和可选的 区域冗余。 这些功能提供高可用性并降低区域业务的延迟。

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

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

使用自动缩放功能

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

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

可以使用 水平 Pod 自动缩放程序（HPA） 和 群集自动缩放程序 在 AKS 中实现自动缩放。 HPA 根据观察到的 CPU 使用率、内存利用率、自定义指标和其他服务的指标自动缩放部署中的 Pod 数。 群集自动缩放程序根据挂起的 Pod 和挂起 Pod 上的资源请求自动调整节点池中的节点数。

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

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

AKS 群集模式的区域缩放策略

对于区域感知的纵向扩展行为，请将节点池模型与计划程序约束和群集模式保持一致。

将群集自动缩放程序与可用性区域配合使用时，一种常见最佳做法是每个区域的一个节点池。 您可以将 --balance-similar-node-groups 设置为 True，以在扩容期间保持各可用区之间的节点分布均衡。

为什么这很重要：

• 集群自动扩缩器按节点池而非特定可用区中的放置来模拟调度。
• 在多区域节点池中，扩容时可能会将新节点添加到某个仍不满足严格拓扑分布约束的区域，导致 Pod 仍处于 Pending 状态。
• 虚拟机规模集使用最佳工作区域均衡。 在区域容量受限或区域不可用事件期间，资源分配可能会失败，并使节点池进入退避状态。
• 每个区域使用一个节点池可提高对特定于区域的缩放行为的控制。

集群自动扩缩器不感知可用区，可用区分配由底层虚拟机规模集而不是由 AKS 处理。 当在单个跨多个可用区的节点池上使用基于可用区的 Pod 拓扑分布约束 时，这一最佳实践显得尤为重要，因为过于严格的约束可能会导致 Pod 处于 Pending 状态，尤其是在容量受限的区域中或可用区发生故障时。

设计无状态应用程序

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

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

做出您的存储磁盘选择

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

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

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

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

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

监视磁盘性能

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

有关详细信息，请参阅使用 Azure Monitor 监控 Azure Kubernetes 服务 (AKS)。

测试 AZ 复原能力

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

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

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

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

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

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