Managed Lustre ボリュームのトラブルシューティング

このページでは、Google Kubernetes Engine で Google Cloud Managed Lustre CSI ドライバを使用する際に発生する一般的な問題とエラーのトラブルシューティング手順について説明します。

このセクションのトラブルシューティング手順を行う前に、GKE から Managed Lustre に接続する際の 制限事項をご覧ください。

最小インスタンス容量の更新

Managed Lustre インスタンスの最小容量が 9,000 GiB に更新されました。Managed Lustre CSI ドライバを使用して 9, 000 GiB のインスタンスを作成するには、クラスタ バージョンを 1.34.0-gke.2285000 以降にアップグレードします。

動的にプロビジョニングされた Lustre インスタンスのパフォーマンス階層が正しくない

Lustre インスタンスを動的にプロビジョニングすると、API リクエストで指定された perUnitStorageThroughput の値に関係なく、PerUnitStorageThroughput の InvalidArgument エラーでインスタンスの作成が失敗します。 これは、1.33.4-gke.1036000 より前の GKE 1.33 バージョンに影響します。

回避策:

GKE クラスタをバージョン 1.33.4-gke.1036000 以降にアップグレードします。 Stable チャンネルを使用している場合、新しいバージョンはまだ利用できない可能性があります。この場合は、修正を含む Regular チャンネルまたは Rapid チャンネルのバージョンを手動で選択できます。

Managed Lustre 通信ポート

Managed Lustre CSI ドライバは、GKE クラスタ バージョンと既存の Managed Lustre 構成に応じて、Managed Lustre インスタンスとの通信に異なるポートを使用します。

  • デフォルト ポート（988）: バージョン 1.33.2-gke.4780000 以降を実行する新しい GKE クラスタの場合、ドライバはデフォルトで Lustre 通信にポート 988 を使用します。

  • 以前のポート（6988）: ドライバは、次のシナリオでポート 6988 を使用します。

    • 以前の GKE バージョン: GKE クラスタで 1.33.2-gke.4780000 より前のバージョンが実行されている場合、CSI ドライバを有効にするときに --enable-legacy-lustre-port フラグが必要です。このフラグを有効にすると、GKE ノードの gke-metadata-server とのポート競合を回避できます。
    • GKE をサポートする既存の Managed Lustre インスタンス: --gke-support-enabled フラグを使用して作成された既存の Managed Lustre インスタンスに接続する場合は、クラスタ バージョンに関係なく、CSI ドライバを有効にするときに --enable-legacy-lustre-port を含める必要があります。このフラグがないと、GKE クラスタは既存の Lustre インスタンスをマウントできません。

    以前のポートで CSI ドライバを有効にする方法について詳しくは、 Lustre 通信ポートをご覧ください。

ログクエリ

ログを確認するには、 ログ エクスプローラで次のクエリを実行します。

Managed Lustre CSI ドライバ ノードサーバーのログを返すには:

resource.type="k8s_container"
resource.labels.pod_name=~"lustre-csi-node*"

ボリューム プロビジョニングのトラブルシューティング

PersistentVolumeClaim（PVC）が Pending 状態のままで、20 ～ 30 分経過しても PersistentVolume（PV）が作成されない場合は、エラーが発生している可能性があります。

  1. PVC イベントを確認します。

    kubectl describe pvc PVC_NAME

  2. エラーが構成の問題または無効な引数を示している場合は、 StorageClass パラメータを確認します。

  3. PVC を再作成します。

  4. 問題が解決しない場合は、 Cloud カスタマーケアにお問い合わせください。

ボリューム マウントのトラブルシューティング

Pod がノードにスケジュールされると、ボリュームがマウントされます。失敗した場合は、Pod イベントと kubelet ログを確認します。

kubectl describe pod POD_NAME

CSI ドライバの有効化に関する問題

症状:

MountVolume.MountDevice failed for volume "yyy" : kubernetes.io/csi: attacher.MountDevice failed to create newCsiDriverClient: driver name lustre.csi.storage.gke.io not found in the list of registered CSI drivers

または

MountVolume.SetUp failed for volume "yyy" : kubernetes.io/csi: mounter.SetUpAt failed to get CSI client: driver name lustre.csi.storage.gke.io not found in the list of registered CSI drivers

原因: CSI ドライバが有効になっていないか、まだ実行されていません。

解決策:

  1. CSI ドライバが 有効になっていることを確認します。
  2. クラスタが最近スケーリングまたはアップグレードされた場合は、ドライバが機能するまで数分待ちます。
  3. エラーが解決しない場合は、lustre-csi-node ログで「Operation not permitted」を確認します。これは、ノード バージョンが古すぎて Managed Lustre をサポートできないことを示しています。この問題を解決するには、ノードプールをバージョン 1.33.2-gke.1111000 以降にアップグレードします。
  4. ログに「LNET_PORT mismatch」と表示されている場合は、ノードプールをアップグレードして、互換性のある Lustre カーネル モジュールがインストールされていることを確認します。

マウント ポイントがすでに存在する

症状:

MountVolume.MountDevice failed for volume "yyy" : rpc error: code = AlreadyExists
desc = A mountpoint with the same lustre filesystem name "yyy" already exists on
node "yyy". Please mount different lustre filesystems

原因: 同じファイル システム名の異なる Managed Lustre インスタンスから複数のボリュームを単一ノードにマウントすることはできません。

解決策: Managed Lustre インスタンスごとに一意のファイル システム名を使用します。

マウントに失敗しました: 該当するファイルまたはディレクトリがない

症状:

MountVolume.MountDevice failed for volume "yyy" : rpc error: code = Internal desc = Could not mount ... failed: No such file or directory

原因: 指定されたファイル システム名が正しくないか、存在しません。

解決策: StorageClass または PV 構成の fs_name が Managed Lustre インスタンスと一致していることを確認します。

マウントに失敗しました: 入出力エラー

症状:

MountVolume.MountDevice failed for volume "yyy" : rpc error: code = Internal desc = Could not mount ... failed: Input/output error

原因: クラスタが Managed Lustre インスタンスに接続できません。

解決策:

  1. Managed Lustre インスタンスの IP アドレスを確認します。
  2. GKE クラスタと Managed Lustre インスタンスが同じ VPC ネットワーク内にあるか、正しくピアリングされていることを確認します。

内部エラー

症状: rpc error: code = Internal desc = ...

解決策: エラーが解決しない場合は、Cloud カスタマーケアにお問い合わせください。

ボリュームのマウント解除のトラブルシューティング

症状:

UnmountVolume.TearDown failed for volume "yyy" : rpc error: code = Internal desc = ...

解決策:

  1. Pod を強制的に削除します。

    kubectl delete pod POD_NAME --force

  2. 問題が解決しない場合は、 Cloud カスタマーケアにお問い合わせください。

ボリュームの削除のトラブルシューティング

PVC を削除してから PV が「Released」状態のまま長時間（たとえば、 1 時間以上）経過している場合は、 Cloud カスタマーケアにお問い合わせください。

ボリュームの拡張のトラブルシューティング

PVC が ExternalExpanding でスタックする

症状: PVC のステータスが Resizing に変わらず、イベントに ExternalExpanding が表示されます。

原因: allowVolumeExpansion フィールドがないか、false に設定されている可能性があります。

解決策: StorageClass に allowVolumeExpansion: true が設定されていることを確認します。

kubectl get storageclass STORAGE_CLASS_NAME -o yaml

拡張に失敗しました: 引数が無効です

症状: VolumeResizeFailed: rpc error: code = InvalidArgument ...

原因: リクエストされたサイズが無効です（ステップサイズの倍数でない、上限を超えているなど）。

解決策: 有効な容量範囲を確認し、有効なサイズで PVC を更新します。

拡張に失敗しました: 内部エラー

症状: VolumeResizeFailed ... rpc error: code = Internal

解決策: PVC を再適用して拡張を再試行します。繰り返し失敗する場合は、 Cloud カスタマーケアにお問い合わせください。

期限を超過

症状: VolumeResizeFailed で DEADLINE_EXCEEDED が発生します。

原因: オペレーションに通常よりも時間がかかっていますが、まだ進行中の可能性があります。

解決策: オペレーションが完了するのを待ちます。リサイザーは自動的に再試行します。長時間（90 分以上など）スタックしたままの場合は、サポートにお問い合わせください。

割り当てを超過した

症状: 割り当ての上限に達したため、拡張に失敗します。

解決策: 割り当ての 増加をリクエストするか、 容量の増加をリクエストします。