Azure Kubernetes Service中临时 NVMe 数据磁盘的最佳做法（AKS）

临时 NVMe 数据磁盘提供高性能、低延迟的存储，非常适合在 Azure Kubernetes 服务 (AKS) 上运行的苛刻的工作负载。 许多新式应用程序（例如 AI/ML 训练、数据分析和高吞吐量数据库）都需要快速临时storage才能高效处理大量中间数据。 通过使用临时 NVMe 磁盘，可以显著提高应用程序响应能力和吞吐量，同时优化 AKS 群集中的成本和可伸缩性。

与远程磁盘相比，其性能会随着虚拟机（VM）大小的增加而提高，临时 NVMe 磁盘则无论 vCPU 数量如何，始终保持完整的性能。 这是因为它们以物理方式附加到 VM，无需依赖于远程磁盘控制器即可运行。 区别值得注意：

• 超级磁盘： 实现 400,000 IOPS 需要 112-vCPU VM（例如 ，Standard_E112ibds_v5）。
• Local NVMe： 8-vCPU VM（例如，Standard_L8s_v3）可以传递 400,000 IOPS。

这会导致等效 IOPS 性能的 vCPU 减少约 14 倍，从而大幅减少计算资源需求。

本文最佳实践文章重点介绍针对集群运维人员的存储注意事项。 本文内容：

高性能工作负载的常见场景

临时 NVMe 数据磁盘非常适合需要高吞吐量、低延迟和快速access临时数据或中间数据的工作负荷。 以下方案突出显示了本地 NVMe 磁盘提供最重要的优势：

高性能数据库（例如 PostgreSQL）

对于 PostgreSQL 等数据库（尤其是在高可用性（HA）或读取密集型部署中，本地 NVMe 磁盘可以显著提高事务吞吐量并减少查询延迟。 当用于临时表空间、预写日志（WAL）或缓存层时，NVMe 磁盘可帮助从持久性存储卸载 I/O，从而加速分析性和事务性负载。

最佳做法：

• 将 NVMe 支持的卷用于 PostgreSQL 临时目录和 WAL 日志，以最大程度地提高 IOPS 并将延迟降到最低。
• 对于 HA 场景，请确保持久性数据目录保留在持久存储上，同时使用 NVMe 处理非持久性高变动数据。
• 有关体系结构指南，请参阅 AKS 上的 PostgreSQL HA 。

AI 模型托管和推理（例如 KAITO）

提供 KAITO 等平台的 AI 模型受益于 NVMe 磁盘，以便快速加载模型、项目缓存和高吞吐量推理。 将模型存储为开放容器计划（OCI）工件并按需加载时，本地 NVMe 存储可确保最小的冷启动时间和高效的批处理。

最佳做法：

• 将 NVMe 支持的卷用于模型缓存目录，以加速模型拉取并减少推理延迟。
• 对于分布式推理，请确保每个节点有足够的 NVMe 容量来缓存常用模型。
• 与 Kubernetes 原生存储解决方案（例如，Azure 容器存储）集成，以便进行自动化管理和监控。
• 如需体系结构指导，请参阅 KAITO 模型作为 OCI 工件。

数据分析和 ETL 数据管道

处理大量中间数据的工作负载（如 Spark、Dask 或自定义 ETL 作业）可以使用 NVMe 磁盘用于 shuffle 存储、临时文件和暂存空间。 此方法可减少数据转换和聚合期间的瓶颈。

最佳做法：

• 将 Shuffle 目录和临时文件目录配置为使用 NVMe 驱动的存储。
• 立即清理临时数据，以最大化可用空间。

缓存层和键值存储

内存中数据库和缓存解决方案（例如 Redis、Memcached、RocksDB）可以将 NVMe 磁盘用作快速持久化层或溢出存储，从而在性能和稳定性之间提供平衡。

最佳做法：

• 将 NVMe 用于写入密集型缓存工作负载，其中持久性并不重要。
• 监视磁盘使用情况，以避免因节点重启而逐出或数据丢失。

高性能计算（HPC）和模拟

HPC 工作负载（包括基因组学、财务建模和科学模拟）通常需要快速access大型数据集和暂存空间才能获得中间结果。 NVMe 磁盘为这些方案提供必要的带宽和低延迟。

使用临时 NVMe 数据磁盘检查 VM 大小

部分 Azure VM 大小提供本地高性能存储，直接附加到物理主机上，在这些 VM 大小上可以使用临时 NVMe 数据磁盘。 这些磁盘非常适合临时数据，例如缓存、暂存文件或中间处理，在解除分配或停止 VM 后不会持久保存。 NVMe 磁盘的数量和容量因 VM 大小和系列而异。

若要确定哪些 VM 大小支持临时 NVMe 数据磁盘及其配置，请参阅 Azure VM 文档和 AKS 支持的 VM 大小。 查找 VM 系列，例如 Lsv4 和 Ddsv6，这些系列专为高吞吐量、低延迟工作负荷而设计。

下表列出了示例 VM 大小及其 NVMe 磁盘配置：

对于需要 GPU 加速的 AI 工作负荷，请考虑 NC、ND 和 NV 系列中的 VM 大小。 除了强大的 GPU 之外，某些启用了 GPU 的 VM 大小（如 Standard_NC48ads_A100_v4 和 Standard_ND96isr_H100_v5）还提供本地 NVMe 存储。 这些 VM 适用于需要 GPU 和快速本地storage的 AI 训练、推理和其他计算密集型方案。

使用 NVMe 磁盘的示例 GPU VM 大小：

验证临时 NVMe 数据磁盘配置

为了确保使用临时 NVMe 数据磁盘预配 AKS 节点，可以使用Azure CLI和直接检查节点来验证配置。

选项 1：使用Azure CLI检查 NVMe 磁盘配置

可以使用Azure CLI通过以下示例命令检查 VM 大小和附加的 NVMe 磁盘。

# Modify location and VM size if needed
locationName="chinanorth3"
vmSize="Standard_L8s_v4"
az vm list-skus --resource-type virtualMachines --location $locationName \
  --query "[?name=='$vmSize'].{
    SkuName: name,
    NvmeDiskSizeInMiB: capabilities[?name=='NvmeDiskSizeInMiB'] | [0].value,
    NvmeSizePerDiskInMiB: capabilities[?name=='NvmeSizePerDiskInMiB'] | [0].value
  }" -o table

SkuName          NvmeDiskSizeInMiB    NvmeSizePerDiskInMiB
---------------  -------------------  ----------------------
Standard_L8s_v4  1830912              457728

选项 2：使用 lsblk 检查节点上的磁盘和挂载布局

登录到 AKS 节点：

kubectl get nodes

# Modify the node name from above list as needed
nodeName="aks-myworkload-22647054-vmss000000"

# Use your approach to login into the node.

kubectl debug "node/$nodeName" \
    --image=ubuntu \
    --profile=sysadmin -it \
    -- chroot /host /bin/bash

连接后，用 lsblk 列出块设备并识别 NVMe 磁盘：

lsblk -o NAME,HCTL,SIZE,MOUNTPOINT,MODEL

NAME        HCTL       SIZE MOUNTPOINT MODEL
sr0         0:0:0:2    750K            Virtual DVD-ROM
nvme0n1                110G            Microsoft NVMe Direct Disk v2

NVMe 磁盘通常显示为 nvme*n1 并在模型上配置 Microsoft NVMe Direct Disk*。 此结果确认 AKS 节点上存在和配置临时 NVMe 数据磁盘。

在工作负荷中使用临时 NVMe 数据磁盘

可通过多种方式在 AKS 工作负载中使用临时 NVMe 数据磁盘。 最常见的方法是：

emptyDir 卷

emptyDir 是使用节点本地存储的 Kubernetes 卷类型。 默认情况下，它使用 OS 磁盘上的 kubelet storage 路径，但你可以将其配置为使用本地 NVMe 磁盘，以提高吞吐量，降低临时数据的延迟。

若要备份具有本地 NVMe 磁盘的 emptyDir 卷，必须将 kubelet storage 路径配置为在节点初始化期间指向 NVMe 装入点。 这需要自定义节点启动脚本和仔细规划，因为配置在节点预配后是不可变的。

优点

• 易于使用和配置。
• 没有外部依赖项。
• 借助 NVMe 实现的高性能。

缺点

• 如果从节点中删除 Pod，则会删除数据。
• 没有数据持久性或复制。
• 限制为单个 NVMe 磁盘。

hostPath 卷

hostPath 将节点文件系统中的特定目录或磁盘装载到 Pod。 可以直接以 NVMe 装入点为目标。

若要使用此方法，请在 Pod 规范中指定 NVMe 磁盘路径（例如 /mnt/nvme0n1）。

优点

• 直接访问 NVMe 磁盘。
• 适用于高级方案（例如自定义格式设置、分区）。

缺点

• 紧密耦合于节点布局，缺乏可移植性。
• 如果未正确限制，则存在安全风险。
• 限制为单个 NVMe 磁盘。

临时 NVMe 数据磁盘和 OS 磁盘

在部署具有本地 NVMe 数据磁盘的 AKS 节点时，例如 Standard_D2ads_v6 VM 大小（单个 100 GiB NVMe 磁盘），并选择加入临时 OS 磁盘设置时，你可能会注意到，临时 OS 磁盘（例如 60 GiB）是从 NVMe 容量中预配的。 但是，未使用的 NVMe 空间（在此示例中，额外的 40 GiB）无法使用，并且在创建节点后没有支持的方式来访问或恢复访问该空间。

此行为是设计造成的，因为临时 OS 磁盘要求决定了 NVMe 设备在预配时是如何分区的。 它可能会令人困惑，因为你无法访问其所有的存储，尤其是许多 VM 的规格只配有一个 NVMe 磁盘。

使用以下示例验证此行为：

# Create Standard_D2ads_v6 (Single 100 GiB NVMe disk) node pool using ephemeral OS disk with 60 GiB capacity

az aks nodepool add \
    --resource-group $resourceGroup \
    --cluster-name $clusterName \
    --name $nodePoolName \
    --node-count 1 \
    --node-vm-size Standard_D2ads_v6 \
    --node-osdisk-type Ephemeral \
    --node-osdisk-size 60

kubectl debug "node/$nodeName" \
    --image=ubuntu \
    --profile=sysadmin -it \
    -- chroot /host /bin/bash

lsblk -o NAME,FSTYPE,LABEL,MOUNTPOINT,SIZE,VENDOR,MODEL
NAME         FSTYPE LABEL           MOUNTPOINT  SIZE VENDOR   MODEL
sr0                                             750K Msft     Virtual DVD-ROM
nvme0n1                                          60G          MSFT NVMe Accelerator v1.0
|-nvme0n1p1  ext4   cloudimg-rootfs /          59.9G
|-nvme0n1p14                                      4M
`-nvme0n1p15 vfat   UEFI            /boot/efi   106M

当您使用包含单个本地 NVMe 数据磁盘的 VM 规格并启用临时操作系统磁盘时，操作系统会占用整个 NVMe 磁盘，从而导致 Kubernetes 工作负载没有空间来预配持久性卷。 对于具有两个或多个本地 NVMe 数据磁盘的 VM 大小，一个磁盘用于临时操作系统，其他磁盘可用于为您的工作负载配置永久性卷。

当前限制

• 临时 OS 磁盘使用一个本地 NVMe 驱动器的一部分，其余部分仍不可访问。
• 在创建节点后，不支持访问或挂载未使用的 NVMe 空间。
• 无法在部署后更新或重新分区 NVMe 磁盘。

客户影响

• 与宣传的 VM 大小相比，可用 NVMe 容量减少。
• 无法完全使用高性能本地存储来支持工作负载。
• 升级或节点更换过程中的潜在混淆和不便。

建议

• 在配置 AKS 节点之前，应确定本地 NVMe 磁盘的预期用途，是用作操作系统磁盘还是 Kubernetes 工作负载存储。 创建节点后，临时 OS 磁盘配置是不可变的，因此提前规划可避免在要求发生更改时重新创建节点。

• 在 NVMe 支持的 VM 上使用临时 OS 磁盘创建 AKS 节点时，省略 OS 磁盘大小输入。 这可以防止配置错误，并与产品文档保持一致，从而降低容量不可访问和出现升级问题的风险。