将 Azure 托管 Lustre CSI 驱动程序与 Azure Kubernetes 服务 配合使用

在本文中，将学习如何使用 Azure Lustre CSI Driver for Kubernetes，在 Azure Kubernetes 服务 (AKS) 中规划、安装和使用 Azure Managed Lustre。 此驱动程序基于容器支持接口 （CSI） 规范。

可以使用 Azure Lustre CSI Driver for Kubernetes，从 AKS 中部署的 Kubernetes 容器访问 Azure Managed Lustre 存储，将其作为持久性存储卷。

兼容的 Kubernetes 版本

适用于 Kubernetes 的 Azure Lustre CSI 驱动程序与 AKS兼容。 目前不支持其他 Kubernetes 安装。

支持 AKS Kubernetes 版本 1.21 及更高版本。 此支持包括创建新 AKS 群集时当前可用的所有版本。

兼容的Lustre版本

Azure Lustre CSI Driver for Kubernetes 与 Azure Managed Lustre 兼容。 目前尚不支持其他 Lustre 安装方式。

Azure Lustre CSI 驱动程序版本

本文介绍的是 v0.4.0，即最新正式发布 (GA) 版本。 请使用带版本号的发布版本，而不是 main 分支进行生产部署。

从 v0.4.0 开始，驱动程序对 Ubuntu 22.04（Jammy）和 Ubuntu 24.04（Noble）使用单独的节点映像。 安装程序会部署这两个节点 DaemonSet。 Kubernetes 通过使用 kubernetes.azure.com/os-sku-effective 节点标签来调度相应的驱动程序 pod。

有关所有驱动程序版本及其更改日志的完整列表，请参阅 Azure Lustre CSI 驱动程序版本页。

先决条件

• 拥有有效订阅的 Azure 帐户。 创建试用帐户。
• 安装了 Azure CLI 工具的终端环境。 请参阅 Azure CLI 入门。
• kubectl，Kubernetes 管理工具，已安装在您的终端环境中。 请参阅 快速入门：使用 Azure CLI部署 Azure Kubernetes 服务（AKS）群集。
• Azure Managed Lustre 部署。 请参阅 Azure Managed Lustre 文档。
• AKS 群集与 Azure 托管 Lustre 虚拟网络之间的网络连接。 有关配置选项，请参阅下面的 网络体系结构规划 。

规划 AKS 部署

部署 Azure Kubernetes 服务时，多个选项会影响 AKS 和 Azure 托管 Lustre 之间的操作。

确定要用于 AKS 的网络类型

AKS 支持多个网络模型，每个模型具有不同的功能和用例。 所有网络模型都适用于适用于 Kubernetes 的 Azure Lustre CSI 驱动程序，但它们对虚拟网络和群集设置有不同的要求。

有关为特定要求选择合适的网络模型的综合信息，请参阅 Azure Kubernetes 服务 CNI 网络概述。

在 Azure 门户中创建 AKS 群集时，你将看到以下网络选项：

建议的选项：

Azure CNI 覆盖层（建议）

• 使用逻辑上独立的 CIDR 范围为 Pod 节省 VNet IP 地址空间。
• 支持最大群集规模（每个节点 5000 个节点和 250 个 Pod）
• 简单的 IP 地址管理
• 最适合大多数情景

Azure CNI Pod 子网

• Pod 获得完整的 VNet 连接，可以通过其专用 IP 地址直接访问
• 需要更大的非分段 VNet IP 地址空间
• 如果需要直接外部访问 Pod IP，请选择此选项

旧选项（不建议用于新部署）：

Azure CNI 节点子网（旧版，历史版本）

• VNet IP 的有限规模和低效使用
• 仅当特别需要群集的托管 VNet 时，才建议使用，请参阅 AKS 旧容器网络接口 （CNI）

Kubenet （停用）

• 2028年3月31日退休。 有关详细信息，请参阅 AKS 使用 Kubenet。
• 规模有限，需要手动路由管理
• 计划在停用日期之前迁移到 Azure CNI 覆盖层

有关网络模型的详细信息，请参阅 Azure Kubernetes 服务 CNI 网络概述。

确定 AKS 和 Azure Managed Lustre 互连的网络体系结构

Azure Managed Lustre 在专用虚拟网络中运行。 AKS 实例必须与 Azure 托管 Lustre 虚拟网络建立网络连接。 可通过两种常见方法在 Azure 托管 Lustre 和 AKS 之间配置网络：

• 在自己的虚拟网络中安装 AKS，并创建与 Azure Managed Lustre 虚拟网络的虚拟网络对等互连。
• 使用 AKS 中的“自带 Azure 虚拟网络” 选项，在 Azure Managed Lustre 虚拟网络的新子网中安装 AKS。

对等互连 AKS 和 Azure 托管 Lustre 虚拟网络

两个虚拟网络的对等互连选项的优点是将网络管理分为不同的特权角色。 对等互连还可以提供额外的灵活性，因为可以跨 Azure 订阅或区域进行实现。 虚拟网络对等互连需要两个网络之间的协调，以避免选择冲突的 IP 网络空间。

在 Azure Managed Lustre 虚拟网络中的子网中安装 AKS

在 AKS 中使用“自带 Azure 虚拟网络”功能在 Azure Managed Lustre 虚拟网络中安装 AKS 群集的选项在单独管理网络的应用场景中可能会很有利。 需要在 Azure Managed Lustre 虚拟网络中创建一个额外的子网，大小以满足您的 AKS 网络需求。

在 Azure 托管 Lustre 虚拟网络上预配 AKS 时，网络管理没有特权分离。 AKS 服务主体需要在 Azure 托管的 Lustre 虚拟网络上获得权限。

预配方法

Azure Lustre CSI 驱动程序支持两种预配方法：

动态预配（在 v0.3.0+中可用）

动态预配允许 CSI 驱动程序在持久卷声明创建时，按需自动创建 Azure 托管 Lustre 文件系统。

静态预配

静态预配使用现有的 Azure 托管 Lustre 文件系统。 此方法涉及：

• 创建引用现有 Lustre 群集的存储类
• 手动指定 Lustre 文件系统名称和 MGS IP 地址
• 适用于已有 Lustre 基础设施的场景

选择最适合用例的方法。 下面首先记录了动态预配，然后是静态预配说明。

动态预配

当创建持久卷声明时，动态资源调配会自动按需创建 Azure 托管 Lustre 文件系统。 此功能在 CSI 驱动程序版本 0.3.0 中可用。

动态预配的先决条件

权限

kubelet 标识需要以下权限：

• 对要在其中创建群集的资源组的读取和写入访问权限
• 如果需要，创建和管理子网的网络权限
• Azure 托管的 Lustre 服务权限

有关详细权限要求，请参阅 v0.4.0 驱动程序参数文档。

网络要求

• Azure 托管 Lustre 群集的现有虚拟网络和子网
• 群集子网中可用的足够 IP 地址
• 合适的网络安全组规则以允许 Lustre 流量

创建用于动态预配的 AKS 群集

如果尚未创建 AKS 群集，请创建群集部署。 请参阅 使用 Azure 门户部署 Azure Kubernetes 服务（AKS）群集。

创建用于动态资源配置的虚拟网络对等互连

AKS 虚拟网络是在 AKS 群集资源组的单独资源组中创建的。 通过前往 Azure 门户中的 AKS 群集，前往“属性”，然后查找基础结构资源组，可以查找此资源组的名称。 此资源组包含需要与 Azure 托管 Lustre 虚拟网络配对的虚拟网络。 它与模式 MC_<aks-rg-name>_aks-cluster-name_region 匹配。

要将 AKS 虚拟网络与 Azure Managed Lustre 虚拟网络进行对等互连，请参阅虚拟网络对等互连。

连接到 AKS 群集进行动态预配

1. 打开一个终端会话，访问 Azure CLI 工具并登录到 Azure 帐户：

   az login
   

2. 登录到 Azure 门户。

3. 找到你的 AKS 集群。 在“概述”窗格中，选择“连接”按钮，然后复制“下载群集凭据”的命令。

4. 在终端会话中，粘贴命令以下载凭据。 该命令类似于：

   az aks get-credentials --subscription <AKS_subscription_id> --resource_group <AKS_resource_group_name> --name <name_of_AKS>
   

5. 如果您的环境中没有 kubectl，请安装它：

   az aks install-cli
   

6. 验证当前上下文是否是刚安装凭据的 AKS 群集，以及是否可以连接到该群集：

   kubectl config current-context
   kubectl get deployments --all-namespaces=true
   

安装用于动态预配的驱动程序

若要安装适用于 Kubernetes 的 Azure Lustre CSI 驱动程序，请运行以下命令：

curl -sSL --fail https://raw.githubusercontent.com/kubernetes-sigs/azurelustre-csi-driver/v0.4.0/deploy/install-driver.sh | bash -s v0.4.0

有关相应的源和部署清单，请参阅 v0.4.0 版本。

为动态预配创建存储类

创建一个名为 storageclass_dynprov_lustre.yaml 的文件，并将以下 YAML 内容复制进去。 根据您的环境需要，编辑参数：

apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
  name: azurelustre-dynprov
provisioner: azurelustre.csi.azure.com
parameters:
  sku-name: "AMLFS-Durable-Premium-125"  # Choose appropriate SKU
  zone: "1"  # Specify zone if required for your SKU/location
  maintenance-day-of-week: "Sunday"
  maintenance-time-of-day-utc: "22:00"
  location: "chinanorth3"  # Optional: defaults to AKS cluster location
  resource-group: "my-resource-group"  # Optional: defaults to AKS cluster RG
  vnet-name: "my-vnet"  # Optional: defaults to AKS cluster VNET
  subnet-name: "my-subnet"  # Optional: defaults to AKS cluster subnet
reclaimPolicy: Delete  # Change to "Retain" to keep clusters after PVC deletion
volumeBindingMode: Immediate
---
# Optional: Resource quota to limit number of clusters
apiVersion: v1
kind: ResourceQuota
metadata:
  name: pvc-lustre-dynprov-quota
spec:
  hard:
    azurelustre-dynprov.storageclass.storage.k8s.io/persistentvolumeclaims: "1"

将存储类应用到 AKS 群集：

kubectl apply -f storageclass_dynprov_lustre.yaml

为动态预配创建永久性卷声明

请创建一个名为 pvc_storageclass_dynprov.yaml 的文件，并复制以下 YAML 内容到其中：

apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: pvc-lustre-dynprov
spec:
  accessModes:
    - ReadWriteMany
  storageClassName: azurelustre-dynprov
  resources:
    requests:
      storage: 48Ti  # Minimum size for AMLFS-Durable-Premium-125

将 PVC 应用到 AKS 集群：

kubectl apply -f pvc_storageclass_dynprov.yaml

监视集群创建

创建 Azure 托管 Lustre 群集可能需要 10 分钟或更多时间。 可以监视进度：

kubectl describe pvc pvc-lustre-dynprov

创建时，状态将显示 Pending 如下消息： Waiting for a volume to be created either by the external provisioner 'azurelustre.csi.azure.com'...

准备就绪后，它将具有Bound状态，并显示成功消息。

创建用于动态预配的 Pod

请创建一个名为 pod_echo_date_dynprov.yaml 的文件，并复制以下 YAML 内容到其中：

apiVersion: v1
kind: Pod
metadata:
  name: lustre-echo-date-dynprov
spec:
  containers:
  - image: mcr.microsoft.com/oss/nginx/nginx:1.15.5-alpine
    name: lustre-echo-date-dynprov
    command:
      - "/bin/sh"
      - "-c"
      - "while true; do echo $(date) >> /mnt/lustre/outfile; sleep 1; done"
    volumeMounts:
    - name: lustre-storage
      mountPath: /mnt/lustre
  volumes:
  - name: lustre-storage
    persistentVolumeClaim:
      claimName: pvc-lustre-dynprov

将 Pod 应用到 AKS 群集：

kubectl apply -f pod_echo_date_dynprov.yaml

验证动态预配

运行 Pod 后，可以验证动态创建的 Azure 托管 Lustre 文件系统是否已正确装载：

kubectl exec -it lustre-echo-date-dynprov -- df -h

您应该能看到 Azure 托管 Lustre 文件系统已装载在 /mnt/lustre。

清理动态资源

删除动态创建的资源：

kubectl delete pvc pvc-lustre-dynprov

如果存储类具有 reclaimPolicy: Delete，这也会删除 Azure 托管 Lustre 群集。 如果设置为 Retain“，则必须在不再需要时手动删除群集。

静态预配

静态预配允许通过手动创建必要的 Kubernetes 资源，在 AKS 群集中使用现有的 Azure 托管 Lustre 文件系统。

静态预配的先决条件

• 现有的 Azure Managed Lustre 文件系统。 有关创建 Azure 托管 Lustre 文件系统的详细信息，请参阅 创建 Azure 托管 Lustre 文件系统。
• Azure 托管 Lustre 群集中的 MGS IP 地址和内部文件系统名称

创建用于静态预配的 Azure 托管 Lustre 文件系统群集

如果尚未创建 Azure 托管 Lustre 文件系统群集，请立即创建群集。 有关说明，请参阅 使用 Azure 门户创建 Azure 托管 Lustre 文件系统。 静态预配需要现有的 Azure 托管 Lustre 文件系统。

创建用于静态预配的 AKS 群集

如果尚未创建 AKS 群集，请创建群集部署。 请参阅 使用 Azure 门户部署 Azure Kubernetes 服务（AKS）群集。

创建用于静态预配的虚拟网络对等互连

AKS 虚拟网络是在 AKS 群集资源组的单独资源组中创建的。 通过前往 Azure 门户中的 AKS 群集，前往“属性”，然后查找基础结构资源组，可以查找此资源组的名称。 此资源组包含需要与 Azure 托管 Lustre 虚拟网络配对的虚拟网络。 它与模式 MC_<aks-rg-name>_aks-cluster-name_region 匹配。

要将 AKS 虚拟网络与 Azure Managed Lustre 虚拟网络进行对等互连，请参阅虚拟网络对等互连。

连接到 AKS 群集进行静态预配

1. 打开一个终端会话，访问 Azure CLI 工具并登录到 Azure 帐户：

   az login
   

2. 登录到 Azure 门户。

3. 找到你的 AKS 集群。 在“概述”窗格中，选择“连接”按钮，然后复制“下载群集凭据”的命令。

4. 在终端会话中，粘贴命令以下载凭据。 该命令类似于：

   az aks get-credentials --subscription <AKS_subscription_id> --resource_group <AKS_resource_group_name> --name <name_of_AKS>
   

5. 如果您的环境中没有 kubectl，请安装它：

   az aks install-cli
   

6. 验证当前上下文是否是刚安装凭据的 AKS 群集，以及是否可以连接到该群集：

   kubectl config current-context
   kubectl get deployments --all-namespaces=true
   

安装用于静态预配的驱动程序

若要安装适用于 Kubernetes 的 Azure Lustre CSI 驱动程序，请运行以下命令：

curl -sSL --fail https://raw.githubusercontent.com/kubernetes-sigs/azurelustre-csi-driver/v0.4.0/deploy/install-driver.sh | bash -s v0.4.0

有关相应的源和部署清单，请参阅 v0.4.0 版本。

为静态预配创建并配置持久卷

要为现有 Azure Managed Lustre 文件系统创建持久性卷：

1. 从 v0.4.0 azurelustre-csi-driver 源中的 /docs/examples/ 文件夹中复制以下配置文件。

   • storageclass_existing_lustre.yaml
   • pvc_storageclass.yaml

   如果不想克隆整个存储库，可以单独下载每个文件。 打开以下每个链接，复制文件的内容，然后将内容粘贴到具有相同文件名的本地文件中。

   • storageclass_existing_lustre.yaml
   • pvc_storageclass.yaml

2. 在 storageclass_existing_lustre.yaml 文件中，更新 Lustre 群集的内部名称和 Lustre 管理服务 （MGS） IP 地址。

   

   这两个设置都显示在 Azure 门户的 Azure Managed Lustre 文件系统的“客户端连接”窗格中。

   

   进行以下更新：

   • 将 EXISTING_LUSTRE_FS_NAME 替换为您 Azure 托管 Lustre 文件系统中 Lustre 群集的系统分配的内部名称。 内部名称通常是 lustrefs。 内部名称不是在创建文件系统时为其指定的名称。

     建议的 mount 命令包括以下地址字符串中突出显示的名称。

     

   • 将 EXISTING_LUSTRE_IP_ADDRESS 替换为 MGS IP 地址。

3. 若要创建存储类和永久性卷声明， kubectl 请运行以下命令：

   kubectl create -f storageclass_existing_lustre.yaml
   kubectl create -f pvc_storageclass.yaml
   

创建用于静态预配的 Pod

创建一个使用 PVC 来挂载 Azure 托管的 Lustre 文件系统的 Pod。

请创建一个名为 pod_echo_date.yaml 的文件，并复制以下 YAML 内容到其中：

apiVersion: v1
kind: Pod
metadata:
  name: lustre-echo-date
spec:
  containers:
  - image: mcr.microsoft.com/oss/nginx/nginx:1.15.5-alpine
    name: lustre-echo-date
    command:
      - "/bin/sh"
      - "-c"
      - "while true; do echo $(date) >> /mnt/lustre/outfile; sleep 1; done"
    volumeMounts:
    - name: lustre-storage
      mountPath: /mnt/lustre
  volumes:
  - name: lustre-storage
    persistentVolumeClaim:
      claimName: pvc-lustre

将 Pod 应用到 AKS 群集：

kubectl apply -f pod_echo_date.yaml

验证静态预配

运行 Pod 后，可以验证是否已正确装载 Azure 托管 Lustre 文件系统：

kubectl exec -it lustre-echo-date -- df -h

您应该能看到 Azure 托管 Lustre 文件系统已装载在 /mnt/lustre。

若要在写入期间查看控制台中的时间戳，请运行以下命令：

kubectl logs -f lustre-echo-date

清理静态资源

完成操作之后，清理资源：

kubectl delete pod lustre-echo-date
kubectl delete pvc pvc-lustre
kubectl delete storageclass azurelustre-static

升级 CSI 驱动程序

使用此过程将 Azure Lustre CSI 驱动程序从 v0.2.0 或更高版本升级到 v0.4.0。 如果群集运行的版本早于 v0.2.0，请在升级之前联系Azure支持部门。

准备升级

1. 检查每个节点的有效 OS SKU：

   kubectl get nodes -L kubernetes.azure.com/os-sku-effective
   

   要在其中运行 Azure Managed Lustre 工作负荷的节点池中的所有节点必须报告 Ubuntu2204 或 Ubuntu2404。 如果所需的节点缺少或不受支持的值，请不要继续。 AKS 管理此标签。 请勿手动更改。

2. 确认以下先决条件：

   • 你具有 cluster-admin 权限。
   • 运行 kubectl 的计算机可以访问 raw.githubusercontent.com。
   • 每个节点池都可以访问 mcr.microsoft.com 和 packages.microsoft.com。
   • 任何网络允许列表都包括位于amlfs-noble上的amlfs-jammy和packages.microsoft.com软件包存储库。 存储库 amlfs-noble 是 v0.4.0 中的新增功能。

3. 列出使用 Azure Lustre CSI 驱动程序的 PersistentVolumes：

   printf 'PV\tCLAIM\tSTATUS\tDELETING\n'
   kubectl get pv -o jsonpath='{range .items[?(@.spec.csi.driver=="azurelustre.csi.azure.com")]}{.metadata.name}{"\t"}{.spec.claimRef.namespace}{"/"}{.spec.claimRef.name}{"\t"}{.status.phase}{"\t"}{.metadata.deletionTimestamp}{"\n"}{end}'
   

   使用声明引用来统计每个已绑定的 Azure Lustre 声明，即使其 StorageClass 已不存在。

4. 列出使用 Azure Lustre CSI 驱动程序的存储类：

   kubectl get storageclass -o jsonpath='{range .items[?(@.provisioner=="azurelustre.csi.azure.com")]}{.metadata.name}{"\n"}{end}'
   

5. 列出所有 PersistentVolumeClaims 并使用前面的存储类列表来标识未绑定Azure Lustre 声明：

   kubectl get pvc --all-namespaces -o custom-columns='NAMESPACE:.metadata.namespace,NAME:.metadata.name,STORAGECLASS:.spec.storageClassName,STATUS:.status.phase,VOLUME:.spec.volumeName,DELETING:.metadata.deletionTimestamp'
   

   将所有 Azure Lustre 声明统计在内，包括状态为 Pending 的声明。 如果 Azure Lustre PV 或 PVC 已设置删除时间戳，或者 Azure Lustre 卷正在创建或删除过程中，请不要继续。

6. 列出 Pod 及其引用的 PersistentVolumeClaims：

   kubectl get pods --all-namespaces -o jsonpath='{range .items[*]}{.metadata.namespace}{"\t"}{.metadata.name}{"\t"}{range .spec.volumes[?(@.persistentVolumeClaim)]}{.persistentVolumeClaim.claimName}{" "}{end}{"\n"}{end}'
   

7. 停止所有使用 Azure Managed Lustre 声明的工作负载。 将控制器缩放为零副本、暂停计划的工作负荷，并暂停重新创建 Pod 的任何部署或 GitOps 进程。

8. 重复上述 Pod 查询。 如果列出了引用 Azure Managed Lustre 声明的 Pod（包括处于 Terminating 状态的 Pod），请勿继续。

9. 列出 CSI 节点 Pod：

   kubectl get pods -n kube-system -l app=csi-azurelustre-node -o wide
   

   将 NODE 列与第一步中的节点列表进行比较。 除非计划运行 Azure Managed Lustre 工作负载的每个节点都具有一个处于 Running 状态的 CSI 节点 Pod，否则请勿继续。

10. 检查每个 CSI 节点 Pod 是否仍有残留的 Lustre 挂载：

    (
      set -e
      pods=$(kubectl get pods -n kube-system -l app=csi-azurelustre-node -o name)
      if [ -z "$pods" ]; then
        echo "No Azure Lustre CSI node pods found." >&2
        exit 1
      fi
      for pod in $pods; do
        echo "$pod"
        kubectl exec -n kube-system "$pod" -c azurelustre -- \
          sh -c 'grep " - lustre " /proc/self/mountinfo; status=$?; [ "$status" -eq 1 ]'
      done
    )
    

    该命令会显示各个 CSI 节点 Pod；如果发现 Lustre 挂载，或者无法检查某个 Pod，则会报错退出。 如果命令失败，请不要继续。

安装 v0.4.0

停止所有Azure Managed Lustre工作负荷后，运行版本固定的 v0.4.0 安装程序：

curl -sSL --fail https://raw.githubusercontent.com/kubernetes-sigs/azurelustre-csi-driver/v0.4.0/deploy/install-driver.sh | bash -s v0.4.0

在脚本 URL 和脚本参数中指定 v0.4.0 ，以便命令安装预期的版本，而不是不同于 main其他版本。

如果安装程序报告部署超时，请先执行 验证升级 中的检查，然后再重试安装程序。

验证升级

1. 等待控制器和节点守护程序集准备就绪：

   kubectl rollout status deployment/csi-azurelustre-controller -n kube-system --timeout=300s
   kubectl rollout status daemonset/csi-azurelustre-node-jammy -n kube-system --timeout=1800s
   kubectl rollout status daemonset/csi-azurelustre-node-noble -n kube-system --timeout=1800s
   

2. 确认每个节点 DaemonSet 具有预期的就绪 Pod 数：

   kubectl get daemonset -n kube-system csi-azurelustre-node-jammy csi-azurelustre-node-noble
   

   当群集中不包含该 Ubuntu 版本的节点池时，DaemonSet 的期望 Pod 数量可以为 0。 对于具有所需 Pod 的每个 DaemonSet， READY 必须相等 DESIRED。

3. 比较节点列表和 Pod 列表，以确认每个预期的节点都有一个 CSI 节点 Pod：

   kubectl get nodes -L kubernetes.azure.com/os-sku-effective
   kubectl get pods -n kube-system -l app=csi-azurelustre-node -o wide
   

   打算运行 Azure Managed Lustre 工作负载的每个节点都必须出现在 pod 列表的 NODE 列中。 没有 CSI 节点 Pod 的节点无法装载Azure Managed Lustre，即使两个 DaemonSets 报表都准备就绪。

4. 确认每个 CSI 节点 Pod 都处于就绪状态，并使用预期的 v0.4.0 版本镜像：

   kubectl get pods -n kube-system -l app=csi-azurelustre-node -o wide
   kubectl get pods -n kube-system -l app=csi-azurelustre-node -o jsonpath='{range .items[*]}{.metadata.name}{"\t"}{.spec.nodeName}{"\t"}{.spec.containers[?(@.name=="azurelustre")].image}{"\n"}{end}'
   

   每个节点 Pod 都必须在 READY 列中显示 3/3，并在 STATUS 列中显示 Running。 就绪容器少于三个的 Pod 尚未准备好提供挂载服务。 Azure Lustre 容器映像必须以 v0.4.0-noble 或 v0.4.0-jammy 结尾。

重启工作负荷

使 Azure Managed Lustre 工作负载保持停止状态，直到每个所需的 CSI 节点 Pod 都已就绪。 然后重启工作负载，并验证某个有代表性的工作负载能否访问其 Azure Managed Lustre 挂载点：

kubectl exec -n <namespace> <pod-name> -- df -h <mount-path>

从不成功的升级中恢复

使用 v0.4.0 故障排除指南 和 v0.4.0 错误引用 更正安装失败。 然后从 Install v0.4.0 重新运行固定的安装程序。 如果无法完成安装，请联系Azure支持部门。 支持部门可能会指示你以特定于群集的恢复步骤重新安装以前工作的版本。

卸载驱动

在卸载驱动程序之前，请停止装载Azure Managed Lustre的每个工作负荷。

从与集群上已安装版本对应的本地克隆副本中运行卸载脚本。 运行该命令的计算机必须已安装 git 并有权访问 github.com。 以下示例卸载 v0.4.0：

git clone --branch v0.4.0 --depth 1 https://github.com/kubernetes-sigs/azurelustre-csi-driver.git
cd azurelustre-csi-driver
./deploy/uninstall-driver.sh

该脚本删除 CSI 控制器、节点守护程序集、 CSIDriver 对象和 RBAC 资源。 它不会删除 PersistentVolumes、PersistentVolumeClaims 或Azure Managed Lustre文件系统。

验证容器映像签名

Azure Lustre CSI 驱动程序对其容器映像进行签名，以允许用户验证其使用映像的完整性和来源。 签名使用公钥/私钥对，通过创建并添加到镜像的数字签名来证明微软构建了容器镜像。 本部分提供验证映像是否已由Microsoft签名的步骤。

了解 Kubernetes 系统组件中的映像安全性

Azure Lustre CSI 驱动程序使用的容器映像部署在命名空间中 kube-system ，该命名空间被视为 Kubernetes 中的受信任系统命名空间。 出于安全性和作原因，映像完整性策略通常不会在系统命名空间上强制执行，因为：

• 启动要求：系统组件（如 CSI 驱动程序）必须在策略强制实施系统（如 Gatekeeper 和 Ratify）可用之前启动。
• 受信任的组件：kube-system 中的映像是由受信任的提供程序管理的核心 Kubernetes 基础结构组件。
• 操作稳定性：针对策略实施组件本身执行的策略可能会影响集群的功能

但是，在部署之前，仍可以验证 CSI 驱动程序映像的完整性。

预部署映像验证

在部署 Azure Lustre CSI 驱动程序之前，可以使用Microsoft的公共签名证书验证容器映像的数字签名和真实性：

使用 Notation CLI 验证图像签名

1. 下载 Notation CLI：

   export NOTATION_VERSION=1.3.2
   curl -LO https://github.com/notaryproject/notation/releases/download/v$NOTATION_VERSION/notation_$NOTATION_VERSION\_linux_amd64.tar.gz
   sudo tar xvzf notation_$NOTATION_VERSION\_linux_amd64.tar.gz -C /usr/bin/ notation
   

2. 下载Microsoft签名公共证书：

   curl -sSL "https://www.microsoft.com/pkiops/certs/Microsoft%20Supply%20Chain%20RSA%20Root%20CA%202022.crt" -o msft_signing_cert.crt
   

3. 将证书添加到 notation CLI：

   notation cert add --type ca --store supplychain msft_signing_cert.crt
   

4. 检查表示法中的证书：

   notation cert ls
   

   命令的输出如以下示例所示：

   STORE TYPE  STORE NAME  CERTIFICATE 
   ca          supplychain msft_signing_cert.crt
   

5. 为 Azure Lustre CSI 驱动程序映像创建 trustpolicy 文件：

   创建名为 trustpolicy.json：

   {
       "version": "1.0",
       "trustPolicies": [
           {
               "name": "supplychain",
               "registryScopes": [ "*" ],
               "signatureVerification": {
                   "level" : "strict" 
               },
               "trustStores": [ "ca:supplychain" ],
               "trustedIdentities": [
                   "x509.subject: CN=Microsoft SCD Products RSA Signing,O=Microsoft Corporation,L=Redmond,ST=Washington,C=US"
               ]
           }
       ]
   }
   

6. 使用表示法验证 Azure Lustre CSI 驱动程序映像：

   notation policy import trustpolicy.json
   export NOTATION_EXPERIMENTAL=1
   
   # Verify the Jammy image used by the controller and Jammy node pods
   notation verify --allow-referrers-api mcr.microsoft.com/oss/v2/kubernetes-csi/azurelustre-csi:v0.4.0-jammy
   
   # Verify the Noble image used by Noble node pods
   notation verify --allow-referrers-api mcr.microsoft.com/oss/v2/kubernetes-csi/azurelustre-csi:v0.4.0-noble
   

   成功验证的输出如以下示例所示：

   Successfully verified signature for mcr.microsoft.com/oss/v2/kubernetes-csi/azurelustre-csi@sha256:a1b2c3d4e5f6789012345678901234567890abcdef1234567890abcdef123456
   

应用程序工作负荷映像完整性

为了增强生产环境中的安全性，请考虑启用 AKS 映像完整性来自动验证应用程序工作负载的容器映像签名。 虽然命名空间中的 kube-system CSI 驱动程序映像通常被排除在策略强制实施之外，但可以为应用程序命名空间配置映像完整性策略。

若要详细了解如何为应用程序工作负荷实现映像完整性策略，请参阅 Azure Kubernetes 服务（AKS）中的映像完整性。

Troubleshooting

若要排查 Azure Lustre CSI 驱动程序的问题，请参阅 GitHub 存储库中的 v0.4.0 CSI 驱动程序故障排除指南。

常见问题包括：

• 网络连接问题 - 检查 AKS 与 Azure Managed Lustre 之间的虚拟网络对等连接或子网配置。
• 配置不正确 - 验证存储类中的 MGS IP 地址和文件系统名称。
• Pod 计划问题 - 验证节点的有效 OS SKU 为 Ubuntu2204 或 Ubuntu2404。
• 在某个 AKS 节点上没有 v0.4.0 节点 Pod - 验证是否存在 kubernetes.azure.com/os-sku-effective 标签，以及该标签是否被 Jammy 或 Noble DaemonSet 匹配。
• DaemonSet 的所需 Pod 数为零 - 如果集群中没有适用于该 Ubuntu 版本的节点池，这种情况是正常的。
• 升级部署超时 - 重试前请检查 DaemonSet 状态、受影响的 Pod 事件以及 Azure Lustre 容器日志。
• 镜像拉取或 Lustre 客户端安装失败 - 验证节点到 packages.microsoft.com 和 mcr.microsoft.com 的出站连接。
• 权限问题 - 验证 AKS 标识是否具有所需的权限。

对于动态预配特定问题：

• 身份验证/授权错误 - 验证用于创建 Azure 托管 Lustre 群集的 kubelet 标识权限
• SKU 和区域验证错误 - 确保区域支持指定的 SKU，区域配置正确
• 网络 IP 地址可用性 - 确认目标子网中有足够的 IP 地址可用
• 配额限制 - 检查 Azure 托管 Lustre 群集的 Kubernetes 资源配额和 Azure 订阅配额

有关其他故障排除资源，请参阅：

• 排查 Azure Managed Lustre CSI 驱动程序扩展错误
• Azure 托管 Lustre 故障排除
• Azure Lustre CSI 驱动程序 GitHub 存储库

相关内容

• 创建导出作业以从 Azure Managed Lustre 导出数据