Azure Arc 在双节点 HCI 上启用Azure Kubernetes 服务 (AKS) 的可用性方案
适用于:Azure Stack HCI 版本 22H2
本文介绍在双节点 Azure Stack HCI 群集上部署 Kubernetes 群集的体系结构。 本文介绍了可能发生的各种故障方案、它们对群集的影响以及这些故障方案的可恢复性。
体系结构
传统的 Kubernetes 部署需要三台物理计算机来缓解单个故障。 此要求通常意味着总拥有成本 (TCO) 更高。 对于成本敏感型部署,可以在双节点 Azure Stack HCI 系统上部署已启用 Arc 的 AKS,如下所示,在可用性方面要进行一些权衡。 可用性方案及其对双节点 AKS 群集的影响中介绍了这些权衡。
有关 AKS 的体系结构、群集部署策略、可靠性注意事项和成本优化的详细信息,请参阅Azure Kubernetes 服务 (AKS) 基线体系结构。
术语
本文使用了以下术语:
术语 | 定义 |
---|---|
物理 HCI 主机 | 托管运行 Arc 启用的 AKS 所需的 VM 的物理 HCI 群集节点。 |
来宾 OS | 在控制平面虚拟机内运行的操作系统 (VM) 、负载均衡器 VM 或节点池 VM。 |
故障转移群集 | Azure Stack HCI 和 Windows Server 的故障转移群集提供支持 VM 和应用程序的高可用性的基础结构功能。 如果群集节点或服务发生故障,则托管在该节点上的 VM 或应用程序可以在称为 故障转移的过程中自动或手动传输到另一个可用节点。 |
工作负载群集 | 由 Azure Kubernetes 服务 (AKS) 部署的 Kubernetes 群集,用于托管容器化最终用户应用程序或工作负载,也称为目标群集。 |
管理群集 (AKS 主机) | 提供用于部署和管理一个或多个工作负载群集的核心业务流程机制和接口。 管理群集包含单个控制平面 VM。 |
负载均衡器 | 具有 API 服务器的负载均衡规则的单个专用 Linux VM。 |
API 服务器 | 启用与 Kubernetes 群集的交互,为 Windows Admin Center、PowerShell 模块和 kubectl 等管理工具提供交互。 |
CRUD | 创建、读取、更新和删除操作。 |
可用性方案及其对双节点 AKS 群集的影响
具有两个物理节点的 Azure Stack HCI 部署中的纵向缩减体系结构涉及一些可用性权衡。 本部分介绍以下故障模式和更新期间的节点行为:
更新
使用下表确定 Azure Stack HCI 和 AKS 更新对工作负载的潜在影响:
现有工作负载 | 工作负载群集上的 CRUD | 新的工作负载群集生命周期 | API 服务器可用性 |
---|---|---|---|
无中断 | 无中断 | 无中断 | 无中断 |
Cluster-Aware Azure Stack HCI 上的更新在重新启动之前将工作器节点实时迁移到另一个节点。 在此迁移过程中,应用程序不会中断。 | Cluster-Aware Azure Stack HCI 上的更新会将工作负载群集的控制平面 VM 实时迁移到另一个节点,然后再重新启动。 在更新期间,可以在不中断的情况下缩放现有工作负载。 | Cluster-Aware Azure Stack HCI 上的更新在重新启动之前将管理群集的控制平面 VM 实时迁移到另一个节点。 在更新期间,可以在不中断的情况下创建新工作负载。 | Cluster-Aware Azure Stack HCI 上的更新会将工作负载群集的控制平面 VM 实时迁移到另一个节点,然后再重新启动。 API 服务器群集在更新期间仍可用。 |
主机上的硬件故障
运行托管 Kubernetes 节点的 VM 的物理主机可能由于硬件问题而停止运行,或者可能变得网络分区。
使用下表确定主机硬件故障对工作负荷的潜在影响。
现有工作负载 | 工作负载群集上的 CRUD | 新的工作负载群集生命周期 | API 服务器可用性 |
---|---|---|---|
潜在中断 + 自动恢复 |
潜在中断 + 自动恢复 |
潜在中断 + 自动恢复 |
潜在中断 + 自动恢复 |
只要以下时间,现有工作负载即可继续运行,而不会中断: - 工作器节点位于不同的主机上。 - 应用程序定义了至少两个 podAntiAffinity 具有指定副本的副本。如果应用程序依赖于 API 服务器 (VIP) 的外部虚拟 IP 地址,则会发生中断。 |
如果工作负荷群集的控制平面 VM 驻留在已关闭的主机上,则工作负荷无法缩放。 添加新的工作器节点和缩放 Pod 将不起作用。 | 如果管理群集的控制平面 VM 驻留在发生故障的主机上,则无法创建新群集。 无法缩放现有群集。 | 如果工作负荷群集或负载均衡器 VM 的控制平面 VM 驻留在发生故障的主机上,则 API 服务器不可用。 |
如果工作器节点位于同一物理主机上,故障转移群集会故障转移幸存主机上的工作器节点。 如果未使用反相关性创建应用程序,Kubernetes 会将 Pod 移动到现有的工作器节点。 如果应用程序依赖于 API 服务器,并且工作负荷群集的控制平面 VM 或负载均衡器 VM 出现故障,则故障转移群集会将这些 VM 移动到幸存的主机,应用程序将恢复工作。 根据应用程序如何处理 API 服务器丢失的情况,可能会在新主机上重启 Pod。 |
故障转移群集将工作负荷群集的控制平面 VM 故障转移到正常运行的主机。 故障转移后,可以缩放工作负载。 | 故障转移群集故障转移正常主机上管理群集的控制平面 VM。 故障转移后,对新目标群集执行 CRUD 操作。 | 故障转移 群集故障转移正常主机上工作负荷群集的控制平面 VM。 故障转移后,API 服务器可用。 |
主机 OS 故障
运行托管 Kubernetes 节点的 VM 的物理主机在操作系统中可能存在软件问题并导致故障。
使用下表确定主机 OS 故障对工作负荷的潜在影响。
现有工作负载 | 工作负载群集上的 CRUD | 新的工作负载群集生命周期 | API 服务器可用性 |
---|---|---|---|
潜在中断 + 自动恢复 |
潜在中断 + 自动恢复 |
潜在中断 + 自动恢复 |
潜在中断 + 自动恢复 |
只要以下时间,现有工作负载即可继续运行,而不会中断: - 工作器节点位于不同的主机上。 - 应用程序定义了至少两个 podAntiAffinity 具有指定副本的副本。如果应用程序依赖于 API 服务器的外部 VIP,则会发生中断。 |
如果目标群集中的控制平面 VM 驻留在出现 OS 故障的主机上,则添加新的工作器节点和缩放 Pod 将不起作用。 | 如果管理群集的控制平面 VM 驻留在出现 OS 故障的主机上,则不会创建新群集,并且无法缩放现有群集。 | 如果控制平面 VM 驻留在出现 OS 故障的主机上,则 API 服务器将不可用。 |
如果工作器节点位于同一物理主机上,故障转移群集会故障转移幸存主机上的工作器节点。 如果未使用反相关性创建应用程序,Kubernetes 会将 Pod 移到现有工作器节点。 如果应用程序依赖于 API 服务器,并且工作负荷群集的控制平面 VM 或负载均衡器 VM 关闭,则故障转移群集会将这些 VM 移动到幸存的主机,应用程序将恢复。 根据应用程序如何处理 API 服务器丢失的情况,可能会在新主机上重启 Pod。 |
故障转移 群集故障转移正常主机上工作负荷群集的控制平面 VM。 故障转移后,可以缩放工作负载。 | 故障转移群集故障转移正常主机上管理群集的控制平面 VM。 故障转移后,新目标群集上的 CRUD 操作将正常工作。 | 故障转移群集重启正常主机上工作负荷群集的控制平面 VM。 之后,API 服务器可用。 |
管理平面 VM 故障
管理群集的控制平面 VM 可能会意外删除,启动磁盘可能损坏,或者管理群集的控制平面 VM 可能由于 OS 问题而无法启动。
使用下表确定管理群集的控制平面 VM 故障对工作负载的潜在影响。
现有工作负载 | 工作负载群集上的 CRUD | 新的工作负载群集生命周期 | API 服务器可用性 |
---|---|---|---|
无中断 |
中断 + 手动恢复 |
中断 + 手动恢复 |
无中断 |
如果管理群集 VM 发生故障,现有工作负载将继续运行。 | 无法添加工作器节点来缩放应用程序。 | 当管理群集关闭时,新工作负载创建不成功。 | 如果管理群集 VM 发生故障,API 服务器应保持可用。 |
不适用 | 如果故障转移群集可以从错误中恢复,它会尝试在不同的主机上重启管理平面 VM。 如果故障转移群集无法恢复 VM,则必须手动重新生成管理群集。 有关详细信息,请参阅 备份和还原工作负载群集。 | 如果故障转移群集可以从错误中恢复,它会尝试在不同的主机上重启管理平面 VM。 如果故障转移群集无法恢复 VM,则必须手动重新生成管理群集。 有关说明,请参阅 备份和还原工作负载群集。 | 不适用 |
控制平面 VM 故障
工作负荷群集的控制平面 VM 可能会意外删除,启动磁盘可能损坏,或者 VM 可能由于 OS 问题而无法启动。
使用下表确定工作负荷群集的控制平面 VM 故障对工作负载的潜在影响。
现有工作负载 | 工作负载群集上的 CRUD | 新的工作负载群集生命周期 | API 服务器可用性 |
---|---|---|---|
无中断 |
中断 + 手动恢复 |
无中断 |
中断 + 手动恢复 |
只要以下时间,现有工作负载即可继续运行,而不会中断: - 工作器节点位于不同的主机上。 - 应用程序定义了至少两个 podAntiAffinity 具有指定副本的副本。如果应用程序依赖于 API 服务器的外部 VIP,则会发生中断。 |
当控制平面 VM 处于故障状态时,无法缩放工作负荷。 添加新的工作器节点和缩放 Pod 将不起作用。 | 新工作负载创建成功。 | 当控制平面 VM 处于故障状态时,API 服务器不可用。 |
不适用 | 如果故障转移群集可以从错误中恢复,它会尝试重启其他主机上的控制平面 VM。 如果故障转移群集无法恢复 VM,则必须手动重新生成控制平面 VM。 有关说明,请参阅 备份和还原工作负载群集。 | 不适用 | 如果故障转移群集可以从错误中恢复,它会尝试重启其他主机上的控制平面 VM。 如果故障转移群集无法恢复 VM,则必须手动重新生成控制平面 VM。 有关说明,请参阅 备份和还原工作负载群集。 |
节点池 (辅助角色节点) VM 故障
托管 Kubernetes 节点的 VM 可能会意外删除,启动磁盘可能损坏,或者 VM 可能由于 OS 问题而无法启动。
使用下表确定 Kubernetes 节点池中 VM 故障对工作负载的潜在影响。
现有工作负载 | 工作负载群集上的 CRUD | 新的工作负载群集生命周期 | API 服务器可用性 |
---|---|---|---|
潜在中断 + 手动恢复 |
无中断 | 无中断 | 无中断 |
只要以下时间,现有工作负载即可继续运行,而不会中断: - 工作器节点位于不同的主机上。 - 应用程序定义了至少两个 podAntiAffinity 具有指定副本的副本。 |
可以添加工作器节点。 如果剩余节点具有足够的容量,Pod 计划将成功。 |
新工作负载创建成功。 | API 服务器在发生单个辅助角色 VM 故障时仍可用。 |
如果故障转移群集可以从错误中恢复,它会尝试重启其他主机上的控制平面 VM。 如果故障转移群集无法恢复 VM,则必须手动重新创建工作器节点。 | 不适用 | 不适用 | 不适用 |
负载均衡器 VM 故障
负载均衡器 VM 可能会意外删除,启动磁盘可能损坏,或者 VM 可能由于 OS 问题而无法启动。
使用下表确定负载均衡器 VM 故障对工作负载的潜在影响。
现有工作负载 | 工作负载群集上的 CRUD | 新的工作负载群集生命周期 | API 服务器可用性 |
---|---|---|---|
潜在中断 + 自动恢复 |
中断 + 手动恢复 |
无中断 |
中断 + 手动恢复 |
只要以下时间,现有工作负载即可继续运行,而不会中断: - 工作器节点位于不同的主机上。 - 应用程序定义了至少两个 podAntiAffinity 具有指定副本的副本。如果应用程序依赖于 API 服务器的外部 VIP,则会发生中断。 |
当负载均衡器 VM 处于故障状态时,无法缩放工作负载。 添加新的工作器节点和缩放 Pod 将不起作用。 | 工作负荷创建成功。 | 当负载均衡器 VM 关闭时,API 服务器仍然不可用。 |
如果故障转移群集可以从错误中恢复,它会尝试在不同的主机上重启负载均衡器 VM。 如果故障转移群集无法恢复 VM,则必须手动重新生成控制平面 VM。 有关说明,请参阅 备份和还原工作负载群集。 | 如果故障转移群集可以从错误中恢复,它会尝试在不同的主机上重启负载均衡器 VM。 如果故障转移群集无法恢复 VM,则必须手动重新生成控制平面 VM。 有关说明,请参阅 备份和还原工作负载群集。 | 不适用 | 如果故障转移群集可以从错误中恢复,它会尝试在不同的主机上重启负载均衡器 VM。 如果故障转移群集无法恢复 VM,则必须手动重新生成控制平面 VM。 有关说明,请参阅 备份和还原工作负载群集。 |