Azure Arc 启用的 AKS 中的可用性集
可用性集 是相互具有弱反相关性关系的 VM 的逻辑组，以确保它们均匀分布在物理群集中的可用容错域中。 此上下文中的容错域是物理主机或一组物理主机。 通过使用可用性集，AKS Arc 可以提高 Kubernetes 工作负载的可用性和分发。 可用性集可以避免单节点故障可能导致多个 VM 出现故障或变得不平衡的情况。
概述
可用性集为 Azure 本地用户的 AKS 提供多项优势，例如：
- 通过避免在同一节点池或控制平面内多个 VM 发生故障或由于单个节点故障而变得不平衡的情况，从而提高应用程序的可用性和复原能力。
- 通过确保 VM 均匀分布在可用节点上，而不是集中在单个节点或一部分节点上，从而优化群集的资源使用情况和性能。
- 与正在寻找可靠且一致的本地 Kubernetes 体验的客户和合作伙伴的最佳做法和期望保持一致。
启用可用性集
使用 Azure 本地版本 23H2 上的 AKS，在创建节点池时默认启用可用性集功能。 在 Windows Server 上使用 AKS 时，可以通过在创建 AKS 群集时添加 -enableAvailabilitySet 参数来启用可用性集功能;例如 New-AksHciCluster -Name <name> -controlPlaneNodeCount 3 -osType Linux -kubernetesVersion $kubernetesVersion -enableAvailabilitySet。
可用性集在 Azure Arc 启用的 AKS 中的工作原理
创建新的 AKS Arc 群集时，AKS Arc 会自动创建可用性集，一个用于控制平面 VM，另一个用于 Kubernetes 群集中的每个节点池。 每个节点池都有自己的可用性集。 借助此布局，AKS Arc 可确保同一角色（控制平面或节点池）的 VM 永远不会位于同一物理主机上，并且它们分布在群集中的可用节点上。
创建可用性集并分配 VM 后，系统会自动将它们放置在相应的物理节点上。 如果节点发生故障，系统还会自动将 VM 故障转移到其他节点，并在节点恢复时重新平衡它们。 这样，无需手动干预即可实现 Kubernetes 工作负载的高可用性和最佳分发。
请考虑 Azure 本地版本 23H2 群集上的 AKS，其中包含两台物理主机、 主机 A 和 主机 B、三个控制平面 VM 和两个工作器节点 VM、 Nodepool1VM1 和 Nodepool1VM2。 为了确保 Kubernetes 应用程序的高可用性，节点池 VM 绝不能共享同一主机，除非其中一个主机暂时无法用于计划内维护或容量问题，这可能导致 VM（虚拟机）暂时放置在备用主机上。
在下图中，每个颜色表示反地缘组：
如果 主机 B 由于重新启动而关闭， 控制平面 VM2、 控制平面 VM3 和 Nodepool1VM2 故障转移到 主机 A ，如下图所示。 假设应用程序在 NodePoolVM1 中运行 Pod，则此重启不会影响应用程序：
在旧体系结构中，如果 主机 B 在重新启动后重新联机，则无法保证 VM 将从主机 A 移回主机 B（重新均衡），从而强制工作负荷保留在同一主机上，并创建单一故障点，如下图所示：
AKS Arc 的可用性集有助于在主机从临时中断恢复后重新平衡 VM。 在此示例中， ControlPlaneVM2、 ControlPlaneVM3 和 Nodepool1VM2 会自动移动到 主机 B，如下所示：
重要
AKS Arc 中的可用性集是一项仍在不断发展和改进的新功能。 我们尚不支持手动配置容错域或可用性集。 创建可用性集后，无法更改其容错域。 VM 在群集创建时分配给可用性集，并且无法迁移到其他可用性集。
添加或删除计算机
在主机删除方案中，主机不再被视为群集的一部分。 由于硬件问题而替换计算机时，通常会发生此删除，或者出于其他原因缩减 Azure 本地群集。 在节点中断期间，节点将保留在 Azure 本地群集的一部分，但显示为 “关闭”。
如果物理计算机（容错域）已从群集中永久删除，则不会修改可用性集配置以减少容错域的数量。 在此方案中，可用性集进入不正常状态。 建议重新部署 Kubernetes 群集，以便可用性集使用正确的容错域数进行更新。
将新的物理计算机（容错域）添加到群集时，可用性集配置会自动展开以包含新计算机。 但是，现有 VM 不会重新平衡以应用此新配置，因为它们已分配给可用性集。 建议重新部署 Kubernetes 群集，以便可用性集使用正确的容错域数进行更新。