你当前正在访问 Microsoft Azure Global Edition 技术文档网站。 如果需要访问由世纪互联运营的 Microsoft Azure 中国技术文档网站，请访问 https://docs.azure.cn。
Azure 运营商关系 Kubernetes 中的资源放置
运营商关系实例部署在客户所在位置。 每个实例包含一个或多个裸机服务器机架。
当用户创建 Nexus Kubernetes 群集 (NKS) 时，他们会为构成 Kubernetes 控制平面以及一个或多个代理池的虚拟机 (VM) 指定计数和库存单位 (SKU)。 代理池是运行客户容器化网络功能的一组工作器节点。
Nexus 平台负责确定要在其上启动每个 NKS VM 的裸机服务器。
Nexus 平台如何计划 Nexus Kubernetes 群集 VM
Nexus 首先确定一组满足 NKS VM SKU 所有资源要求的潜在裸机服务器。 例如，如果用户为其代理池指定了 NC_G48_224_v1 VM SKU，则 Nexus 会收集具有 48 个 vCPU、224Gi RAM 等可用容量的裸机服务器。
然后，Nexus 检查正在调度的代理池或控制平面的 AvailabilityZones 字段。 如果此字段不为空，则 Nexus 会将潜在裸机服务器列表筛选为仅包含指定可用性区域（机架）中的服务器。 此行为是一种硬调度约束。 如果筛选列表中没有裸机服务器，则 Nexus 不会调度 NKS VM，并且群集无法预配。
一旦 Nexus 确定了要放置 NKS VM 的潜在裸机服务器列表，Nexus 就会在应用以下排序规则后选择其中一台裸机服务器：
优先选择可用性区域（机架）中的、不包含此 NKS 群集中的 NKS VM 的裸机服务器。 换言之，将 NKS 群集的 NKS VM 分布到各个可用性区域。
优先选择单个可用性区域（机架）中的、不包含同一 NKS 群集中的其他 NKS VM 的裸机服务器。 换言之，将 NKS 群集的 NKS VM 分布到可用性区域中的各个裸机服务器。
如果 NKS VM SKU 为
NC_G48_224_v1或NC_P46_224_v1，则优先选择已容装其他 NKS 群集中的NC_G48_224_v1或NC_P46_224_v1NKS VM 的裸机服务器。 换言之，将不同 NKS 群集中的超大 VM 分组到同一裸机服务器上。 此规则对超大 VM 进行“装箱”，以减少可用计算资源的碎片。
示例放置方案
以下部分重点介绍了 Nexus 用户在针对运营商关系环境创建 NKS 群集时应该预料到的行为。
提示：可以通过检查 NKS KubernetesCluster 资源的
nodes.bareMetalMachineId属性或查看 Azure 门户显示的 Kubernetes 群集节点中的“主机”列，来了解 NKS VM 已调度到哪个裸机服务器。
示例运营商关系环境的规格如下：
- 8 个机架，每个机架有 16 个裸机服务器
- 每个裸机服务器包含两个非统一内存访问 (NUMA) 单元
- 每个 NUMA 单元提供 48 个 CPU 和 224Gi RAM
空环境
由于空运营商关系环境具有给定的容量，我们创建了三个不同大小的 Nexus Kubernetes 群集。
NKS 群集的规格如下，对于本练习，我们假设用户按以下顺序创建三个群集：
群集 A
- 控制平面，
NC_G12_56_v1SKU，3 个 - 代理池 #1，
NC_P46_224_v1SKU，24 个 - 代理池 #2，
NC_G6_28_v1SKU，6 个
群集 B
- 控制平面，
NC_G24_112_v1SKU，5 个 - 代理池 #1，
NC_P46_224_v1SKU，48 个 - 代理池 #2，
NC_P22_112_v1SKU，24 个
群集 C
- 控制平面，
NC_G12_56_v1SKU，3 个 - 代理池 #1，
NC_P46_224_v1SKU，12 个，AvailabilityZones = [1,4]
下表汇总了用户在空的运营商关系环境中启动群集 A、B 和 C 后应会看到的内容。
| 群集 | 池 | SKU | 总计数 | 预期的机架数 | 实际机架数 | 每个机架上的预期 VM 数 | 每个机架上的实际 VM 数 |
|---|---|---|---|---|---|---|---|
| A | 控制平面 | NC_G12_56_v1 |
3 | 3 | 3 | 1 | 1 |
| A | 代理池 #1 | NC_P46_224_v1 |
24 | 8 | 8 | 3 | 3 |
| A | 代理池 #2 | NC_G6_28_v1 |
6 | 6 | 6 | 1 | 1 |
| B | 控制平面 | NC_G24_112_v1 |
5 | 5 | 5 | 1 | 1 |
| B | 代理池 #1 | NC_P46_224_v1 |
48 | 8 | 8 | 6 | 6 |
| B | 代理池 #2 | NC_P22_112_v1 |
24 | 8 | 8 | 3 | 3 |
| C | 控制平面 | NC_G12_56_v1 |
3 | 3 | 3 | 1 | 1 |
| C | 代理池 #1 | NC_P46_224_v1 |
12 | 2 | 2 | 6 | 6 |
有 8 个机架，因此每个池的 VM 分布在最多 8 个机架上。 具有 8 个以上 VM 的池需要在不同的裸机服务器上分布每个机架的多个 VM。
群集 C 代理池 #1 有 12 个 VM 限制在 AvailabilityZones [1, 4] 中，因此它在 12 个裸机服务器上有 12 个 VM，机架 1 和 4 中各有 6 个 VM。
来自不同群集的超大 VM (NC_P46_224_v1 SKU) 放置在相同的裸机服务器上（请参阅 Nexus 平台如何调度 Nexus Kubernetes 群集 VM 中的规则 #3）。
下面是将群集 A、B 和 C 部署到空环境后用户可能会看到的布局的可视化效果。
半满环境
我们现在运行一个在目标环境半满时启动另一个 NKS 群集的示例。 将群集 A、B、C 部署到目标环境后，目标环境处于半满状态。
群集 D 的规格如下：
- 控制平面，
NC_G24_112_v1SKU，5 个 - 代理池 #1，
NC_P46_224_v1SKU，24 个，AvailabilityZones = [7,8] - 代理池 #2，
NC_P22_112_v1SKU，24 个
下表汇总了用户在启动群集 A、B 和 C 后存在的半满运营商关系环境中启动群集 D 后应会看到的内容。
| 群集 | 池 | SKU | 总计数 | 预期的机架数 | 实际机架数 | 每个机架上的预期 VM 数 | 每个机架上的实际 VM 数 |
|---|---|---|---|---|---|---|---|
| D | 控制平面 | NC_G12_56_v1 |
5 | 5 | 5 | 1 | 1 |
| D | 代理池 #1 | NC_P46_224_v1 |
24 | 2 | 2 | 12 | 12 |
| D | 代理池 #2 | NC_P22_112_v1 |
24 | 8 | 8 | 3 | 3 |
群集 D 代理池 #1 有 12 个 VM 限制在 AvailabilityZones [7, 8] 中，因此它在 12 个裸机服务器上有 12 个 VM，机架 7 和 8 中各有 6 个 VM。 由于将不同群集中的超大 VM 分组到同一裸机服务器的排序规则，这些位于裸机服务器上的 VM 还容装了其他群集中的超大 VM。
如果群集 D 控制平面 VM 位于机架 7 或 8 上，则一个群集 D 代理池 #1 VM 可能与该群集 D 控制平面 VM 位于同一裸机服务器上。 此行为是由于代理池 #1“固定”到机架 7 和 8 所造成的。 这些机架中的容量约束导致调度程序将同一 NKS 群集中的控制平面 VM 和代理池 #1 VM 并置在一起。
群集 D 的代理池 #2 在每个机架（共 8 个）中的不同裸机服务器上有 3 个 VM。 容量约束是由于群集 D 的代理池 #1 固定到机架 7 和 8 上而造成的。 因此，群集 D 的代理池 #1 和代理池 #2 中的 VM 并置在机架 7 和 8 中的相同裸机服务器上。
下面是将群集 D 部署到目标环境后用户可能会看到的布局的可视化效果。
几乎填满的环境
在示例目标环境中，8 个机架中的 4 个已接近容量限制。 让我们尝试启动另一个 NKS 群集。
群集 E 的规格如下：
- 控制平面，
NC_G24_112_v1SKU，5 个 - 代理池 #1，
NC_P46_224_v1SKU，32 个
下表汇总了用户在将群集 E 启动到目标环境后应会看到的内容。
| 群集 | 池 | SKU | 总计数 | 预期的机架数 | 实际机架数 | 每个机架上的预期 VM 数 | 每个机架上的实际 VM 数 |
|---|---|---|---|---|---|---|---|
| E | 控制平面 | NC_G24_112_v1 |
5 | 5 | 5 | 1 | 1 |
| E | 代理池 #1 | NC_P46_224_v1 |
32 | 8 | 8 | 4 | 3、4 或 5 |
群集 E 的代理池 #1 将不均匀地分布在所有 8 个机架之间。 机架 7 和 8 将包含代理池 #1 中的 3 个 NKS VM，而不是预期的 4 个 NKS VM，因为在调度群集 A 到 D 后，这些机架中的超大 SKU VM 不再有容量。由于机架 7 和 8 没有更多容量可用于代理池 #1 中第四个超大 SKU，因此 5 个 NKS VM 将放置在两个利用率最低的机架上。 在本示例中，利用率最低的机架是机架 3 和 6。
下面是将群集 E 部署到目标环境后用户可能会看到的布局的可视化效果。
运行时升级期间的放置
自 2024 年 4 月（Network Cloud 2304.1 版本）起，运行时升级是使用逐机架策略执行的。 机架 1 中的所有裸机服务器一次性重建映像。 升级过程将暂停，直到所有裸机服务器成功重启并告知 Nexus 它们已准备好接收工作负载。
注意
可以指示运营商关系一次仅重建机架中部分裸机服务器的映像，但默认设置是同时重建机架中所有裸机服务器的映像。
为单个裸机服务器重建映像时，该裸机服务器上运行的所有工作负载（包括所有 NKS VM）都会断电并断开连接。 在 NKS VM 上运行的工作负载容器将依次断电和连接。 一分钟后无法访问这些工作负载容器，NKS 群集的 Kubernetes 控制平面会将相应的 Pod 标记为不正常。 如果 Pod 是部署或 StatefulSet 的成员，则 NKS 群集的 Kubernetes 控制平面会尝试启动替换 Pod，以将观察到的部署或 StatefulSet 副本计数恢复为所需的副本计数。
仅当剩余的正常 NKS VM 中为 Pod 提供可用容量时，新 Pod 才会启动。 自 2024 年 4 月（Network Cloud 2304.1 版本）起，不会创建新的 NKS VM 来替换正在重置映像的裸机服务器上的 NKS VM。
一旦裸机服务器成功重置映像并且能够接受新的 NKS VM，最初位于同一裸机服务器上的 NKS VM 将在最近重置映像的裸机服务器上重启。 然后，可以将工作负载容器调度到这些 NKS VM，从而有可能能够还原裸机服务器上的、在 NKS VM 上具有 Pod 的部署或 StatefulSet。
注意
此行为在用户看来可能就像 NKS VM 未从裸机服务器“移动”一样，但实际上，在最近重置映像的裸机服务器上启动了相同 NKS VM 的新实例，该实例保留了与重置映像之前相同的裸机服务器名称。
最佳做法
使用运营商关系时，请记得以下最佳做法。
- 避免为代理池指定
AvailabilityZones。 - 先启动较大的 NKS 群集，然后再启动较小的群集。
- 在减少 VM SKU 大小之前减少代理池的计数。
避免为代理池指定 AvailabilityZone
从上述放置方案中可以看出，为代理池指定 AvailabilityZones 是将同一 NKS 群集中的 NKS VM 最终放置在同一裸机服务器上的主要原因。 通过指定 AvailabilityZones，可以将代理池“固定”到一部分机架，从而限制这一部分机架中可用于放置其他 NKS 群集和同一 NKS 群集中其他代理池 VM 的潜在裸机服务器数量。
因此，我们的第一项最佳做法是避免为代理池指定 AvailabilityZones。 如果需要将代理池固定到可用性区域集，请使该集尽可能大，以最大程度地减少不平衡情况。
此项最佳做法的一种例外情况是代理池中只有两个或三个 VM。 可以考虑将该代理池的 AvailabilityZones 设置为 [1,3,5,7] 或 [0,2,4,6]，以提高运行时升级期间的可用性。
先启动较大的 NKS 群集，然后再启动较小的群集
自 2024 年 4 月（Network Cloud 2403.1 版本）起，NKS 群集将按照其创建顺序进行调度。 为了最有效地打包目标环境，我们建议在创建较小 NKS 群集之前创建较大的 NKS 群集。 同样，我们建议先调度较大的代理池，然后再调度较小的代理池。
此建议对于使用超大 NC_G48_224_v1 或 NC_P46_224_v1 SKU 的代理池非常重要。 使用这些超大 SKU VM 的最大计数来调度代理池会创建一组更大的裸机服务器，其他 NKS 群集的代理池中的其他超大 SKU VM 可以并置到这些服务器。
在减少 VM SKU 大小之前减少代理池的计数
如果在启动 NKS 群集或代理池时遇到容量约束，请在调整 VM SKU 大小之前减少代理池的计数。 例如，如果你尝试使用 VM SKU 大小为 NC_P46_224_v1、计数为 24 的代理池创建 NKS 群集，但由于资源不足而导致预配 NKS 群集失败，那么，你可能会忍不住使用 VM SKU 大小 NC_P36_168_v1，并继续使用计数 24。 但是，由于工作负载 VM 必须与裸机服务器上的单个 NUMA 单元相一致，因此相同的请求可能会导致发生类似的资源不足失败问题。 不要减少 VM SKU 大小，而是考虑将代理池的计数减少到 20。 与缩小 VM SKU 相比，请求更有可能符合目标环境的资源容量，并且整个部署将拥有更多的 CPU 核心。