Azure Kubernetes Service で Azure Managed Lustre CSI ドライバーを使用する

この記事では、Azure Lustre CSI Driver for Kubernetes を使用して Azure Kubernetes Service (AKS) で Azure Managed Lustre を計画、インストール、および使用する方法について説明します。 このドライバーは、コンテナー サポート インターフェイス (CSI) の仕様に基づいています。

Azure Lustre CSI Driver for Kubernetes を使用して、AKS にデプロイされた Kubernetes コンテナーから永続ストレージ ボリュームとして Azure Managed Lustre ストレージにアクセスできます。

互換性のある Kubernetes バージョン

Azure Lustre CSI Driver for Kubernetes は、AKSと互換性があります。 他の Kubernetes のインストールは現在サポートされていません。

AKS Kubernetes バージョン 1.21 以降がサポートされています。 このサポートには、新しい AKS クラスターを作成するときに現在使用できるすべてのバージョンが含まれます。

互換性のある Lustre バージョン

Kubernetes 用 Azure Lustre CSI ドライバーは、Azure Managed Lustreと互換性があります。 他の Lustre インストールは現在サポートされていません。

Azure Lustre CSI ドライバーのバージョン

次のドライバー バージョンがサポートされています。

すべてのドライバー リリースとその変更ログの完全な一覧については、 Azure Lustre CSI ドライバーのリリース ページを参照してください。

前提条件

• アクティブなサブスクリプションが含まれる Azure アカウント。 無料でアカウントを作成できます。
• Azure CLI ツールがインストールされているターミナル環境。 「Azure CLI の使い始め」を参照してください。
• kubectl、ターミナル環境にインストールされている Kubernetes 管理ツールです。 「クイック スタート: Azure CLIを使用して Azure Kubernetes Service (AKS) クラスターをデプロイする」を参照してください。
• Azure Managed Lustre デプロイ。 Azure Managed Lustre の ドキュメントを参照してください。
• AKS クラスターと Azure Managed Lustre 仮想ネットワークの間のネットワーク接続。 構成オプションについては、以下の ネットワーク アーキテクチャの計画 を参照してください。

AKS デプロイを計画する

Azure Kubernetes Service をデプロイする場合、いくつかのオプションが AKS と Azure Managed Lustre の間の操作に影響します。

AKS で使用するネットワークの種類を決定する

AKS では複数のネットワーク モデルがサポートされており、それぞれ異なる機能とユース ケースが用意されています。 すべてのネットワーク モデルは Azure Lustre CSI Driver for Kubernetes で動作しますが、仮想ネットワークとクラスターのセットアップに関する要件は異なります。

特定の要件に適したネットワーク モデルの選択に関する包括的な情報については、 Azure Kubernetes Service CNI ネットワークの概要に関するページを参照してください。

Azure portal で AKS クラスターを作成すると、次のネットワーク オプションが表示されます。

推奨されるオプション:

Azure CNI オーバーレイ (推奨)

• ポッドに対して論理的に分離された CIDR 範囲を使用して VNet IP アドレス空間を節約する
• 最大クラスター スケール (ノードあたり 5,000 ノードと 250 ポッド) をサポート
• シンプルな IP アドレス管理
• ほとんどのシナリオに最適な選択肢

Azure CNI ポッド サブネット

• ポッドは完全な VNet 接続を取得し、プライベート IP アドレスを介して直接アクセスできます
• より大きな断片化されていない VNet IP アドレス空間が必要
• ポッド IP への直接外部アクセスが必要な場合は、これを選択します

従来のオプション (新しいデプロイには推奨されません):

Azure CNI ノード サブネット (レガシ)

• 制限付きスケールと非効率的な VNet IP の使用
• クラスターのマネージド VNet が特に必要な場合にのみお勧めします。AKS レガシ コンテナー ネットワーク インターフェイス (CNI) に関するページを参照してください。

Kubenet (廃止)

• 2028 年 3 月 31 日に廃止されます。 詳細については、「 AKS での Kubenet の使用」を参照してください。
• スケールが制限され、手動ルート管理が必要
• 提供終了日より前の Azure CNI オーバーレイへの移行を計画する

ネットワーク モデルの詳細については、 Azure Kubernetes Service CNI ネットワークの概要に関するページを参照してください。

AKS と Azure Managed Lustre の相互接続性のネットワーク アーキテクチャを決定する

Azure Managed Lustre は、プライベート仮想ネットワーク内で動作します。 AKS インスタンスには、Azure Managed Lustre 仮想ネットワークへのネットワーク接続が必要です。 Azure Managed Lustre と AKS の間でネットワークを構成するには、次の 2 つの一般的な方法があります。

• 独自の仮想ネットワークに AKS をインストールし、Azure Managed Lustre 仮想ネットワークとの仮想ネットワーク ピアリングを作成します。
• AKS の Bring your own Azure virtual network オプションを使用して、Azure Managed Lustre 仮想ネットワーク上の新しいサブネットに AKS をインストールします。

AKS と Azure Managed Lustre 仮想ネットワークのピアリング

2 つの仮想ネットワークをピアリングするオプションには、ネットワークの管理を異なる特権ロールに分離する利点があります。 ピアリングは、Azure サブスクリプションまたはリージョン間で実装できるため、柔軟性を高めることもできます。 仮想ネットワーク ピアリングでは、競合する IP ネットワークスペースを選択しないように、2 つのネットワーク間の調整が必要です。

Azure Managed Lustre 仮想ネットワーク上のサブネットへの AKS のインストール

AKS で Bring your own Azure virtual network 機能を使用して Azure Managed Lustre 仮想ネットワークに AKS クラスターをインストールするオプションは、ネットワークが単独で管理されるシナリオで有利です。 Azure Managed Lustre 仮想ネットワークで、AKS ネットワークの要件を満たすようにサイズ設定された追加のサブネットを作成する必要があります。

Azure Managed Lustre 仮想ネットワークで AKS をプロビジョニングする場合、ネットワーク管理の特権の分離はありません。 AKS サービス プリンシパルには、Azure Managed Lustre 仮想ネットワークに対する特権が必要です。

プロビジョニング方法

Azure Lustre CSI ドライバーでは、次の 2 つのプロビジョニング方法がサポートされています。

動的プロビジョニング (v0.3.0 以降で利用可能)

動的プロビジョニングを使用すると、永続ボリューム要求が作成されたときに、CSI ドライバーが Azure Managed Lustre ファイル システムをオンデマンドで自動的に作成できます。

静的プロビジョニング

静的プロビジョニングでは、既存の Azure Managed Lustre ファイル システムが使用されます。 この方法には、次の処理が含まれます。

• 既存の Lustre クラスターを参照するストレージ クラスの作成
• Lustre ファイル システム名と MGS IP アドレスを手動で指定する
• 既存の Lustre インフラストラクチャがあるシナリオに適しています

ユース ケースに最適な方法を選択します。 動的プロビジョニングについては、最初に以下に説明し、その後に静的プロビジョニングの手順を示します。

動的プロビジョニング (パブリック プレビュー)

パブリック プレビューに関する通知: 動的プロビジョニング機能は現在パブリック プレビュー段階です。 一部の機能はサポートされていないか、機能が制限されている可能性があります。

動的プロビジョニングでは、永続ボリューム要求が作成されると、Azure Managed Lustre ファイル システムがオンデマンドで自動的に作成されます。 この機能は、CSI ドライバー バージョン 0.3.0 で利用可能になりました。

動的プロビジョニングの前提条件

Permissions

kubelet ID には、次のアクセス許可が必要です。

• クラスターが作成されるリソース グループへの読み取りと書き込みアクセス
• 必要に応じてサブネットを作成および管理するためのネットワークアクセス許可
• Azure マネージド Lustre サービスのアクセス許可

アクセス許可の詳細な要件については、 ドライバー パラメーターのドキュメントを参照してください。

ネットワークの要件

• Azure Managed Lustre クラスターの既存の仮想ネットワークとサブネット
• クラスターのサブネットで使用可能な十分な IP アドレス
• Lustre トラフィックを許可する適切なネットワーク セキュリティ グループ規則

動的プロビジョニング用の AKS クラスターを作成する

AKS クラスターをまだ作成していない場合は、クラスターデプロイを作成します。 Azure portalを使用して Azure Kubernetes Service (AKS) クラスターをデプロイする を参照してください。

動的プロビジョニング用の仮想ネットワーク ピアリングを作成する

AKS 仮想ネットワークは、AKS クラスターのリソース グループとは別のリソース グループに作成されます。 このリソース グループの名前は、Azure portal で AKS クラスターに移動し、[プロパティ]を し、インフラストラクチャ リソース グループを見つけることで確認できます。 このリソース グループには、Azure Managed Lustre 仮想ネットワークとペアにする必要がある仮想ネットワークが含まれています。 これは、パターン MC_<aks-rg-name>_<aks-cluster-name>_<region> と一致します。

AKS 仮想ネットワークを Azure Managed Lustre 仮想ネットワークとピアリングするには、仮想ネットワーク ピアリングの参照してください。

動的プロビジョニングのために AKS クラスターに接続する

1. Azure CLI ツールにアクセスしてターミナル セッションを開き、Azure アカウントにサインインします。

   az login
   

2. Azure portal にサインインします。

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 -skSL https://raw.githubusercontent.com/kubernetes-sigs/azurelustre-csi-driver/main/deploy/install-driver.sh | bash

ローカル インストールのサンプル コマンドを取得するには、「Kubernetes クラスターに Azure Lustre CSI ドライバーをインストールする」を参照してください。

動的プロビジョニング用のストレージ クラスを作成する

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: "eastus"  # 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

AKS クラスターに PVC を適用します。

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_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

ポッドを AKS クラスターに適用します。

kubectl apply -f pod_echo_date_dynprov.yaml

動的プロビジョニングを確認する

ポッドの実行後、動的に作成された Azure Managed Lustre ファイル システムが正しくマウントされていることを確認できます。

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

Azure Managed Lustre ファイル システムが /mnt/lustreにマウントされていることがわかります。

動的リソースをクリーンアップする

動的に作成されたリソースを削除するには:

kubectl delete pvc pvc-lustre-dynprov

ストレージ クラスに reclaimPolicy: Deleteがある場合は、Azure Managed Lustre クラスターも削除されます。 Retainに設定した場合は、不要になったらクラスターを手動で削除する必要があります。

静的プロビジョニング

静的プロビジョニングでは、必要な Kubernetes リソースを手動で作成することで、AKS クラスターで既存の Azure Managed Lustre ファイル システムを使用できます。

静的プロビジョニングの前提条件

• 既存の Azure Managed Lustre ファイル システム。 Azure Managed Lustre ファイル システムの作成の詳細については、「 Azure Managed Lustre ファイル システムの作成」を参照してください。
• Azure Managed Lustre クラスターからの MGS IP アドレスと内部ファイル システム名

静的プロビジョニング用の Azure Managed Lustre ファイル システム クラスターを作成する

Azure Managed Lustre ファイル システム クラスターをまだ作成していない場合は、ここでクラスターを作成します。 手順については、「Azure portalを使用して Azure Managed Lustre ファイル システムを作成する」を参照してください。 静的プロビジョニングには、既存の Azure Managed Lustre ファイル システムが必要です。

静的プロビジョニング用の AKS クラスターを作成する

AKS クラスターをまだ作成していない場合は、クラスターデプロイを作成します。 Azure portalを使用して Azure Kubernetes Service (AKS) クラスターをデプロイする を参照してください。

静的プロビジョニング用の仮想ネットワーク ピアリングを作成する

AKS 仮想ネットワークは、AKS クラスターのリソース グループとは別のリソース グループに作成されます。 このリソース グループの名前は、Azure portal で AKS クラスターに移動し、[プロパティ]を し、インフラストラクチャ リソース グループを見つけることで確認できます。 このリソース グループには、Azure Managed Lustre 仮想ネットワークとペアにする必要がある仮想ネットワークが含まれています。 これは、パターン MC_<aks-rg-name>_<aks-cluster-name>_<region> と一致します。

AKS 仮想ネットワークを Azure Managed Lustre 仮想ネットワークとピアリングするには、仮想ネットワーク ピアリングの参照してください。

静的プロビジョニングのために AKS クラスターに接続する

1. Azure CLI ツールにアクセスしてターミナル セッションを開き、Azure アカウントにサインインします。

   az login
   

2. Azure portal にサインインします。

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 -skSL https://raw.githubusercontent.com/kubernetes-sigs/azurelustre-csi-driver/main/deploy/install-driver.sh | bash

ローカル インストールのサンプル コマンドを取得するには、「Kubernetes クラスターに Azure Lustre CSI ドライバーをインストールする」を参照してください。

静的プロビジョニング用の永続ボリュームを作成して構成する

既存の Azure Managed Lustre ファイル システムの永続ボリュームを作成するには:

1. 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 Management Service (MGS) IP アドレスの内部名を更新します。

   

   どちらの設定も、Azure Portal の Azure Managed Lustre ファイル システムの [クライアント接続] ウィンドウに表示されます。

   

   次の更新を行います。

   • EXISTING_LUSTRE_FS_NAMEを、Azure Managed 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
   

静的プロビジョニング用のポッドを作成する

PVC を使用して Azure Managed Lustre ファイル システムをマウントするポッドを作成します。

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

ポッドを AKS クラスターに適用します。

kubectl apply -f pod_echo_date.yaml

静的プロビジョニングを確認する

ポッドの実行後、Azure Managed Lustre ファイル システムが正しくマウントされていることを確認できます。

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

Azure Managed 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

コンテナー イメージの署名を検証する

Azure Lustre CSI Driver は、コンテナー イメージに署名して、ユーザーが使用するイメージの整合性と配信元を確認できるようにします。 署名では、公開キーと秘密キーのペアを使用して、デジタル署名を作成してイメージに追加することで、Microsoft がコンテナー イメージを構築したことを証明します。 このセクションでは、イメージが Microsoft によって署名されたことを確認する手順について説明します。

Kubernetes システム コンポーネントのイメージ セキュリティについて

Azure Lustre CSI ドライバーによって使用されるコンテナー イメージは、Kubernetes の信頼されたシステム名前空間と見なされる kube-system 名前空間にデプロイされます。 セキュリティと運用上の理由から、イメージ整合性ポリシーは通常、次の理由でシステム名前空間に適用されません。

• ブートストラップの要件: 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. 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 controller image
   notation verify --allow-referrers-api mcr.microsoft.com/oss/v2/kubernetes-csi/azurelustre-csi:v0.3.0
   

   検証が成功した場合の出力は、次の例のようになります。

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

アプリケーション ワークロード イメージの整合性

運用環境でセキュリティを強化するには、AKS Image Integrity を有効にして、アプリケーション ワークロードのコンテナー イメージ署名を自動的に検証することを検討してください。 kube-system名前空間内の CSI ドライバー イメージは通常、ポリシーの適用から除外されますが、アプリケーション名前空間のイメージ整合性ポリシーを構成できます。

アプリケーション ワークロードのイメージ整合性ポリシーの実装の詳細については、 Azure Kubernetes Service (AKS) でのイメージの整合性に関するページを参照してください。

トラブルシューティング

Azure Lustre CSI ドライバーに関する問題のトラブルシューティングについては、GitHub リポジトリの CSI ドライバーのトラブルシューティング ガイド を参照してください。

一般的な問題は次のとおりです。

• AKS と Azure Managed Lustre の間のネットワーク接続の問題 - 仮想ネットワーク ピアリングまたはサブネットの構成を確認する
• 正しくない構成 - ストレージ クラスの構成で MGS IP アドレスとファイル システム名を再確認する
• ポッドのスケジュールの問題 - これが唯一サポートされている構成であるため、ノード プールに Ubuntu Linux OS SKU を使用していることを確認します
• アクセス許可の問題 - AKS サービス プリンシパルに Azure Managed Lustre 仮想ネットワークに対する適切なアクセス許可があることを確認する

動的プロビジョニングに特有の問題については:

• 認証/承認エラー - Azure Managed Lustre クラスターを作成するための kubelet ID アクセス許可を確認する
• SKU とゾーンの検証エラー - 指定された SKU がリージョンでサポートされており、ゾーンの構成が正しいことを確認します
• ネットワーク IP アドレスの可用性 - ターゲット サブネットで十分な IP アドレスが使用可能であることを確認する
• クォータの制限 - Azure Managed Lustre クラスターの Kubernetes リソース クォータと Azure サブスクリプション クォータの両方を確認する

その他のトラブルシューティング リソースについては、次を参照してください。

• Azure Managed Lustre のトラブルシューティング
• Azure Lustre CSI Driver GitHub リポジトリ

関連コンテンツ

• Azure Managed Lustre からデータをエクスポートするエクスポート ジョブを作成する