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