Azure Kubernetes 服务（AKS）中临时 NVMe 数据磁盘的最佳实践

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

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

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

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

本最佳做法文章重点介绍群集操作员的存储注意事项。 本文内容：

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

临时 NVMe 数据磁盘非常适合需要高吞吐量、低延迟和快速访问临时或中间数据的工作负荷。 以下方案突出显示了本地 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 容器存储）集成，以便进行自动化管理和监视。
• 有关体系结构指南，请参阅作为 OCI 工件的 KAITO 模型。

数据分析和 ETL 管道

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

最佳做法：

• 将 shuffle 目录和临时目录配置为使用由 NVMe 支持的存储。
• 立即清理临时数据，以最大化可用空间。

缓存层和键值存储

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

最佳做法：

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

高性能计算（HPC）和模拟

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

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

在特定的 Azure 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 和快速本地存储的 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 卷类型，使用节点的本地存储。 通过 NVMe 磁盘提供支持时， emptyDir 为临时数据提供高吞吐量和低延迟。

若要使用此方法，请在 Pod 规范中定义卷 emptyDir 。默认情况下，它使用最快的可用存储（如果存在 NVMe）。

优点

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

缺点

• 如果 Pod 被重新调度到另一个节点，则数据会丢失。
• 没有数据持久性或复制。
• 限制为单个 NVMe 磁盘。

hostPath 卷

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

若要使用此方法，请在 Pod 规范中指定 NVMe 磁盘路径（例如， /mnt 或 /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 设备在预配时是如何分区的。 这可能会令人困惑，因为你无法访问其所有存储空间，特别是在许多仅配备一个 NVMe 磁盘的 VM 规格中。

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

# 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 磁盘大小输入。 这可以防止配置错误，并与产品文档保持一致，从而降低容量不可访问和出现升级问题的风险。