你当前正在访问 Microsoft Azure Global Edition 技术文档网站。 如果需要访问由世纪互联运营的 Microsoft Azure 中国技术文档网站,请访问 https://docs.azure.cn。
Azure Kubernetes 服务 (AKS) 的区域复原注意事项
本文介绍 Azure Kubernetes 服务 (AKS) 中区域复原的各种注意事项,包括如何:
- 使 AKS 群集组件区域具有复原能力
- 部署无状态应用程序
- 做出存储磁盘决策
- 测试可用性区域复原能力
可用性区域复原能力是运行生产级 Kubernetes 群集的关键部分。 借助其核心的可伸缩性,Kubernetes 充分利用数据中心内的独立基础结构,并且仅在必要时预配新节点,不会产生额外的成本。
重要
只是纵向扩展或减少群集中的节点数不足以确保应用程序复原能力。 必须更深入地了解应用程序及其依赖项,以便更好地规划复原能力。 AKS 让你可以为群集和节点池设置可用性区域,以确保应用程序能够处理故障,并且即使整个区域出现故障,也能继续提供流量。
以下部分提供了有关使 AKS 群集组件区域具有复原能力的主要决策点的指导,但它们并不详尽。 应根据特定的要求和约束考虑其他因素,并检查其他依赖项,以确保为区域复原配置它们。
AKS 允许在群集和节点池创建过程中选择多个可用性区域。 创建具有多个可用性区域的群集时,控制平面分布在所选可用性区域中。 节点池中的节点也分布在所选可用性区域中。 此方法可确保控制平面和节点分布在多个可用性区域之间,从而在发生可用性区域故障时提供复原能力。 可以使用 Azure 门户、Azure CLI 或 Azure 资源管理器模板配置可用性区域。
以下示例演示如何使用 Azure CLI 创建包含三个节点的群集,该群集分布在三个可用性区域中:
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=eastus2-1
Name: aks-nodepool1-28993262-vmss000001
topology.kubernetes.io/zone=eastus2-2
Name: aks-nodepool1-28993262-vmss000002
topology.kubernetes.io/zone=eastus2-3
有关详细信息,请参阅在 Azure Kubernetes 服务 (AKS) 中使用可用性区域。
可以使用基于 zone
和 hostname
标签的 Pod 拓扑分布约束,将 Pod 分散到区域中的可用性区域和可用性区域中的节点之间。
例如,假设你有一个四节点群集,其中三个标记为 foo:bar
的 Pod 分别位于 node1
、node2
和 node3
。 如果希望传入的 Pod 与跨区域的现有 Pod 均匀分布,可以使用类似于以下示例的清单:
kind: Pod
apiVersion: v1
metadata:
name: mypod
labels:
foo: bar
spec:
topologySpreadConstraints:
- maxSkew: 1
topologyKey: "topology.kubernetes.io/zone"
whenUnsatisfiable: DoNotSchedule
labelSelector:
matchLabels:
foo: bar
containers:
- name: pause
image: registry.k8s.io/pause:3.1
有关详细信息,请参阅 Kubernetes Pod 拓扑分布约束。
如果有为网络流量提供服务的 Pod,则应在多个可用性区域之间对流量进行负载均衡,以确保应用程序高度可用且可以处理故障。 可以使用 Azure 负载均衡器在 AKS 群集中的节点之间分配传入流量。
Azure 负载均衡器支持内部和外部负载均衡,并且可以将其配置为使用标准 SKU 进行区域冗余负载均衡。 标准 SKU 是 AKS 中的默认 SKU,它利用可用性区域支持区域复原,以确保应用程序不受区域故障影响。 如果发生区域故障事件,区域冗余的标准 SKU 负载均衡器不会受到故障的影响,并且使部署能够继续为来自剩余区域的流量提供服务。 可以使用全局负载均衡器(例如 Front Door 或流量管理器),也可以使用区域 AKS 群集前跨区域负载均衡器,以确保应用程序不受区域故障的影响。 若要在 AKS 中创建标准 SKU 负载均衡器,请参阅在 Azure Kubernetes 服务 (AKS) 中使用标准负载均衡器。
为了确保应用程序的网络流量能够处理故障,应为 AKS 工作负载配置可用性区域感知网络。 Azure 提供支持可用性区域的各种网络服务:
- Azure VPN 网关:在 Azure 可用性区域中部署 VPN 和 ExpressRoute 网关,为虚拟网络网关提供更高的复原能力、可伸缩性和可用性。 有关详细信息,请参阅在可用性区域中创建区域冗余虚拟网络网关。
- Azure 应用程序网关 v2:Azure 应用程序网关为区域 L7 负载均衡器提供可用性区域支持。 有关详细信息,请参阅使用 Azure 应用程序网关定向 Web 流量。
- Azure Front Door:Azure Front Door 提供全局 L7 负载均衡器,并利用存在点 (POP) 或 Azure 内容分发网络 (CDN)。 有关详细信息,请参阅 Azure Front Door POP 位置。
重要
使用 Azure NAT 网关,可以在特定的可用性区域中创建 NAT 网关,或使用区域部署进行特定区域的隔离。 NAT 网关支持区域部署,但不支持区域冗余部署。 如果出站类型等于 NAT 网关,且 NAT 网关位于单个区域,这样的 AKS 群集配置可能会存在问题。 在这种情况下,如果托管 NAT 网关的区域出现故障,群集将失去出站连接。 有关详细信息,请参阅 NAT 网关和可用性区域。
若要确保容器映像高度可用且可复原故障,应设置区域冗余容器注册表。 Azure 容器注册表 (ACR) 高级 SKU 支持 异地复制和可选的区域冗余。 这些功能提供可用性,并减少区域操作的延迟。
Azure Key Vault 提供多层冗余功能,确保密钥和机密持续可供应用程序使用,即使服务的单个组件发生故障,或者 Azure 区域或可用性区域不可用时也是如此。 有关详细信息,请参阅 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 在单个可用性区域中复制数据。 ZRS 跨区域中的多个可用性区域复制数据。 从 AKS 版本 1.29 开始,默认存储类使用 ZRS 磁盘进行持久存储。 有关详细信息,请参阅 AKS 内置存储类。
应用程序复制数据的方式可能会影响你选择的磁盘。 如果应用程序位于多个区域,并从应用程序中复制数据,则可以在每个可用性区域中使用 LRS 磁盘实现复原能力,因为如果一个可用性区域出现故障,其他可用性区域具有可用的最新数据。 如果应用程序层不处理此类复制,ZRS 磁盘是更好的选择,因为 Azure 处理存储层中的复制。
下表概述了每种磁盘类型的优缺点:
磁盘类型 | 优点 | 缺点 |
---|---|---|
LRS | • 成本更低 • 支持所有磁盘大小和区域 • 易于使用和预配 |
• 低可用性和持久性 • 易受区域性故障影响 • 不支持区域或异地复制 |
ZRS | • 高可用性和持久性 • 更能抵御区域故障 • 支持区域复制,实现区域内部复原 |
• 成本更高 • 不支持所有磁盘大小和区域 • 需要额外的配置才能启用 |
有关 LRS 和 ZRS 磁盘类型的详细信息,请参阅 Azure 存储冗余。 若要在 AKS 中预配存储磁盘,请参阅在 Azure Kubernetes 服务 (AKS) 预配 Azure 磁盘存储。
为了确保 AKS 中存储磁盘的最佳性能和可用性,应监视关键指标,例如 IOPS、吞吐量和延迟。 这些指标可帮助你识别可能影响应用程序性能的任何问题或瓶颈。 如果发现任何一致性的性能问题,可能需要重新考虑存储磁盘类型或大小。 可以使用 Azure Monitor 收集和可视化这些指标,并设置警报,在出现任何性能问题时通知你。
有关详细信息,请参阅使用 Azure Monitor 监控 Azure Kubernetes 服务 (AKS)。
测试 AKS 群集的可用性区域复原能力的方法之一是清空一个区域中的节点,并了解它如何影响流量,直到它故障转移到另一个区域。 此方法模拟现实世界场景,其中整个区域由于灾难或中断而不可用。 若要测试此方案,可以使用 kubectl drain
命令从节点中正常逐出所有 Pod,并将其标记为不可计划。 然后,可以使用 Azure Monitor 或 Prometheus 等工具监视群集流量和性能。
下表概述了此方法的优缺点:
优点 | 缺点 |
---|---|
• 模拟现实故障场景并测试恢复过程 • 允许验证跨区域数据的可用性和持久性 • 帮助你识别群集配置或应用程序设计中的任何潜在问题或瓶颈 |
• 可能会导致用户服务的暂时中断或降级 • 需要手动干预和协调才能清空和还原节点 • 由于网络流量或存储复制增加,可能会产生额外的成本 |
测试 AKS 群集的可用性区域复原能力的另一种方法是将故障注入群集,并使用 Azure Chaos Studio 观察对应用程序的影响。 Azure Chaos Studio 是一项服务,可用于在 Azure 资源和服务上创建和管理混沌试验。 可以使用 Chaos Studio 通过创建针对特定区域的故障注入试验来模拟可用性区域故障,并停止或重启该区域中的虚拟机。 然后,可以使用指标和日志来度量应用程序的可用性、延迟和错误率。
下表概述了此方法的优缺点:
优点 | 缺点 |
---|---|
• 提供受控和自动化的方式来注入故障并监视结果 • 支持各种类型的故障和场景,例如网络延迟、CPU 压力、磁盘故障等。 • 与 Azure Monitor 和其他工具集成以收集和分析数据 |
• 可能需要额外的配置和设置来创建和运行试验 • 可能不会涵盖在实际中断期间可能发生的所有故障模式和边缘区域 • 对试验的范围和/或持续时间可能有限制 |
有关详细信息,请参阅什么是 Azure Chaos Studio?。
有关更多实现详细信息,请参阅区域冗余 AKS 群集和存储指南。