Managed Lustre CSI ドライバを使用して GKE の既存の Managed Lustre インスタンスにアクセスする

このガイドでは、Managed Lustre CSI ドライバを使用して既存の Managed Lustre インスタンスに接続する方法について説明します。これにより、既存の Managed Lustre インスタンスに、ステートフルワークロードのボリュームとして、制御された予測可能な方法でアクセスできます。

高性能ネットワーキングのマルチ NIC サポート

バージョン 1.35.2-gke.1842000 以降を実行する GKE クラスタの場合、Managed Lustre CSI ドライバはデフォルトで有効になっており、使用可能なすべてのネットワークインターフェースカード（NIC）を使用してスループットを向上させます。このサポートにより、TCP ストレージトラフィックをネットワークインターフェース全体に分散することで、帯域幅が集約されます。

マルチ NIC サポートを使用するには、ノードが次の要件を満たしている必要があります。

TCP 用の標準 NIC: ノードは、TCP ストレージトラフィックを処理するために、Google Virtual NIC（gVNIC）や VirtIO-Net などの標準 NIC を使用する必要があります。
同じ VPC: すべての標準 NIC は同じ VPC ネットワーク内に存在する必要があります。
RDMA に関する考慮事項: ノードに RDMA NIC を接続することもできますが、Managed Lustre CSI ドライバは TCP ストレージトラフィックに標準 NIC のみを使用します。

マルチ NIC サポートを無効にする場合は、Lustre のマルチ NIC を無効にするをご覧ください。

Lustre 通信ポート

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

デフォルトポート（推奨）: バージョン 1.33.2-gke.4780000 以降を実行する新しい GKE クラスタの場合、ドライバはデフォルトで Lustre 通信にポート 988 を使用します。
以前のポート: 次のシナリオでは、gcloud コマンドに --enable-legacy-lustre-port フラグを追加して、ポート 6988 を使用します。
- 以前の GKE バージョン: GKE クラスタで 1.33.2-gke.4780000 より前のバージョンが実行されている場合、--enable-legacy-lustre-port フラグにより、GKE ノードの gke-metadata-server とのポート競合を回避します。
- 既存の Lustre インスタンス: gke-support-enabled フラグを使用して作成された既存の Managed Lustre インスタンスに接続する場合は、クラスタバージョンに関係なく、gcloud コマンドに --enable-legacy-lustre-port を含める必要があります。このフラグがないと、GKE クラスタは既存の Lustre インスタンスをマウントできません。gke-support-enabled フラグについては、インスタンスを作成するのオプションフラグの説明をご覧ください。

新しいクラスタと既存のクラスタは、デフォルトのポート 988 または以前のポート 6988 を使用するように構成できます。

始める前に

作業を始める前に、次のタスクが完了していることを確認してください。

Google Cloud Managed Lustre API と Google Kubernetes Engine API を有効にします。

API を有効にする

このタスクに Google Cloud CLI を使用する場合は、gcloud CLI をインストールして初期化する。gcloud CLI をインストール済みの場合は、gcloud components update コマンドを実行して最新のバージョンを取得します。以前のバージョンの gcloud CLI では、このドキュメントのコマンドを実行できない場合があります。
注: gcloud CLI がすでにインストールされている場合には、必ず compute/region プロパティを設定してください。主にゾーンクラスタを使用する場合は、代わりに compute/zone を設定します。デフォルトのロケーションを設定することで、gcloud CLI のエラー（One of [--zone, --region] must be supplied: Please specify location など）を防止できます。クラスタのロケーションが設定したデフォルトと異なる場合は、特定のコマンドでロケーションの指定が必要になることがあります。

制限事項と要件については、Google Cloud Managed Lustre CSI ドライバについてをご覧ください。
Managed Lustre CSI ドライバを有効にしてください。Standard クラスタと Autopilot クラスタではデフォルトで無効になっています。

環境変数を設定する

次の環境変数を設定します。

export CLUSTER_NAME=CLUSTER_NAME
export PROJECT_ID=PROJECT_ID
export NETWORK_NAME=LUSTRE_NETWORK
export LOCATION=ZONE

次のように置き換えます。

CLUSTER_NAME: クラスタの名前。
PROJECT_ID: 実際の Google Cloud プロジェクト ID。
LUSTRE_NETWORK: GKE クラスタと Managed Lustre インスタンスの両方が存在する共有 Virtual Private Cloud ネットワーク。
ZONE: GKE クラスタの地理的なゾーン（例: us-central1-a）。

Managed Lustre CSI ドライバを構成する

このセクションでは、Managed Lustre CSI ドライバを有効または無効にする方法について説明します。

新しい GKE クラスタで Managed Lustre CSI ドライバを有効にする

以降のセクションでは、新しい GKE クラスタで Managed Lustre CSI ドライバを有効にする方法について説明します。

デフォルトポート `988` を使用する

バージョン 1.33.2-gke.4780000 以降を実行する新しい GKE クラスタを作成するときに Managed Lustre CSI ドライバを有効にするには、次のコマンドを実行します。

Autopilot

gcloud container clusters create-auto "${CLUSTER_NAME}" \
    --location=${LOCATION} \
    --network="${NETWORK_NAME}" \
    --cluster-version=${CLUSTER_VERSION} \
    --enable-lustre-csi-driver

Standard

gcloud container clusters create "${CLUSTER_NAME}" \
    --location=${LOCATION} \
    --network="${NETWORK_NAME}" \
    --cluster-version=${CLUSTER_VERSION} \
    --addons=LustreCsiDriver

以前のポート `6988` を使用する

1.33.2-gke.4780000 より前のバージョンを実行する新しい GKE クラスタを作成するときに Managed Lustre CSI ドライバを有効にするには、次のコマンドを実行します。

Autopilot

gcloud container clusters create-auto "${CLUSTER_NAME}" \
    --location=${LOCATION} \
    --network="${NETWORK_NAME}" \
    --cluster-version=${CLUSTER_VERSION} \
    --enable-lustre-csi-driver \
    --enable-legacy-lustre-port

Standard

gcloud container clusters create "${CLUSTER_NAME}" \
    --location=${LOCATION} \
    --network="${NETWORK_NAME}" \
    --cluster-version=${CLUSTER_VERSION} \
    --addons=LustreCsiDriver \
    --enable-legacy-lustre-port

既存の GKE クラスタで Managed Lustre CSI ドライバを有効にする

以降のセクションでは、既存の GKE クラスタで Managed Lustre CSI ドライバを有効にする方法について説明します。

デフォルトポート `988` を使用する

バージョン 1.33.2-gke.4780000 以降を実行する既存の GKE クラスタで Managed Lustre CSI ドライバを有効にするには、次のコマンドを実行します。

  gcloud container clusters update ${CLUSTER_NAME} \
      --location=${LOCATION} \
      --update-addons=LustreCsiDriver=ENABLED

以前のポート `6988` を使用する

既存の GKE クラスタで Managed Lustre CSI ドライバを有効にするには、--enable-legacy-lustre-port フラグを追加して、以前のポート 6988 を使用する必要がある場合があります。このフラグは、次のシナリオで必要です。

GKE クラスタが 1.33.2-gke.4780000 より前のバージョンで実行されている場合。
このクラスタを gke-support-enabled フラグを使用して作成された既存の Managed Lustre インスタンスに接続する場合。
```
gcloud container clusters update ${CLUSTER_NAME} \
    --location=${LOCATION} \
    --enable-legacy-lustre-port
```

既存のクラスタでノードのアップグレードが必要

既存のクラスタで Managed Lustre CSI ドライバを有効にすると、Managed Lustre クライアントに必要なカーネルモジュールを更新するためにノードの再作成がトリガーされることがあります。すぐに利用できるようにするには、ノードプールを手動でアップグレードすることをおすすめします。

リリースチャンネルの GKE クラスタは、スケジュールされたロールアウトに従ってアップグレードされます。メンテナンスの時間枠によっては、この処理に数週間かかることがあります。静的 GKE バージョンを使用している場合は、ノードプールを手動でアップグレードする必要があります。

ノードのアップグレードが完全に完了するまで、CSI ドライバ Pod が更新保留中のノードでクラッシュループする可能性があります。CSI ドライバ Pod ログに Operation not permitted エラーが表示された場合は、ノードのアップグレードまたは再作成が必要です。

ノードプールのアップグレード後、CPU ノードが Google Cloud コンソールまたは CLI 出力で GPU イメージを使用しているように見えることがあります。この動作は予期されたものです。GPU イメージは、CPU ノードで再利用され、Managed Lustre カーネルモジュールを安全にインストールします。GPU の使用料金は発生しません。

（省略可）マルチ NIC ノードプールを作成する

高性能ネットワーキングを使用するには、複数のネットワークインターフェースをサポートするインスタンスタイプでノードプールを作成する必要があります。マルチ NIC サポートは、バージョン 1.35.2-gke.1842000 以降を実行する GKE クラスタでデフォルトで有効になっています。セカンダリネットワークインターフェースがプライマリインターフェースと同じ VPC ネットワーク内にあることを確認してください。

次のコマンドを実行します。

gcloud container node-pools create NODE_POOL_NAME \
    --cluster=CLUSTER_NAME \
    --location=LOCATION \
    --machine-type=MACHINE_TYPE \
    --enable-gvnic \
    --additional-node-network network=NETWORK_NAME,subnetwork=SECONDARY_SUBNET

次のように置き換えます。

NODE_POOL_NAME: ノードプールの名前。
CLUSTER_NAME: クラスタの名前。
LOCATION: クラスタのリージョンまたはゾーン。
MACHINE_TYPE: ノードプールのマシンタイプ（a3-megagpu-8g など）。これは、高性能のマルチ NIC でよく使用されます。マルチ NIC は、任意のマシンタイプでサポートされています。
NETWORK_NAME: VPC ネットワーク名。
SECONDARY_SUBNET: セカンダリサブネットの名前。

Lustre でマルチ NIC を無効にする

高性能ワークロードにはマルチ NIC サポートが推奨されますが、特定のシナリオでは無効にすることが必要な場合があります。たとえば、Lustre トラフィックを使用可能なすべてのハードウェアインターフェースに分散したくない場合や、トラブルシューティングのために接続の問題を単一のネットワークパスに分離する必要がある場合などです。

注: 実行中のノードでマルチ NIC サポートを無効にする場合は、この変更を有効にするためにノードプールを再作成するか、手動でアップグレードする必要があります。

クラスタの場合

クラスタ全体の高性能ネットワーキングを無効にするには、クラスタの作成または更新時に --disable-multi-nic-lustre フラグを使用します。次に例を示します。

gcloud container clusters update CLUSTER_NAME \
    --location=LOCATION \
    --disable-multi-nic-lustre

次のように置き換えます。

CLUSTER_NAME: クラスタの名前。
LOCATION: クラスタのリージョンまたはゾーン。

ノードプールの場合

特定のノードプールの高性能ネットワーキングを無効にするには、ノードプールを更新して lustre.csi.storage.gke.io/multi-nic ラベルを false に設定します。

gcloud container node-pools update NODE_POOL_NAME \
--cluster=CLUSTER_NAME \
--zone=LOCATION \
--node-labels=lustre.csi.storage.gke.io/multi-nic=false

次のように置き換えます。

NODE_POOL_NAME: ノードプールの名前。
CLUSTER_NAME: クラスタの名前。
LOCATION: クラスタのゾーン。

Managed Lustre CSI ドライバを無効にする

既存の GKE クラスタで Managed Lustre CSI ドライバを無効にするには、Google Cloud CLI を使用します。

gcloud container clusters update ${CLUSTER_NAME} \
    --location=${LOCATION} \
    --update-addons=LustreCsiDriver=DISABLED

CSI ドライバが無効になると、GKE はノードを自動的に再作成し、Managed Lustre カーネルモジュールをアンインストールします。

Managed Lustre CSI ドライバを使用して既存の Managed Lustre インスタンスにアクセスする

GKE クラスタと同じネットワーク内に Managed Lustre インスタンスをすでにプロビジョニングしている場合は、次の手順に沿って、インスタンスを参照する PersistentVolume を静的にプロビジョニングできます。

以降のセクションでは、Managed Lustre CSI ドライバを使用して既存の Managed Lustre インスタンスにアクセスする一般的なプロセスについて説明します。

Managed Lustre インスタンスを参照する PersistentVolume を作成します。
PersistentVolumeClaim を使用して Volume にアクセスします。
ボリュームを消費する Pod を作成します。

PersistentVolume を作成する

Managed Lustre インスタンスを見つけるには、次のコマンドを実行します。

gcloud lustre instances list \
    --project=${PROJECT_ID} \
    --location=${LOCATION}

出力は次のようになります。次のステップに進む前に、[Managed Lustre instance name]、[filesystem]、[mountPoint] の各フィールドをメモしてください。

capacityGib: '9000'
createTime: '2025-04-28T22:42:11.140825450Z'
filesystem: testlfs
gkeSupportEnabled: true
mountPoint: 10.90.1.4@tcp:/testlfs
name: projects/my-project/locations/us-central1-a/instances/my-lustre
network: projects/my-project/global/networks/default
perUnitStorageThroughput: '1000'
state: ACTIVE
updateTime: '2025-04-28T22:51:41.559098631Z'

次のマニフェストを lustre-pv.yaml という名前のファイルに保存します。
```
apiVersion: v1
kind: PersistentVolume
metadata:
  name: lustre-pv
spec:
  storageClassName: "STORAGE_CLASS_NAME"
  capacity:
    storage: 9000Gi
  accessModes:
    - ReadWriteMany
  persistentVolumeReclaimPolicy: Retain
  volumeMode: Filesystem
  claimRef:
    namespace: default
    name: lustre-pvc
  csi:
    driver: lustre.csi.storage.gke.io
    volumeHandle: "PROJECT_ID/LOCATION/INSTANCE_NAME"
    volumeAttributes:
      ip: IP_ADDRESS
      filesystem: FILESYSTEM
```
次のように置き換えます。
- storageClassName: StorageClass の名前。この値は空の文字列にできますが、PersistentVolumeClaim の仕様と一致する必要があります。
- volumeHandle: このボリュームの識別子。
  - PROJECT_ID: Google Cloud プロジェクト ID。
  - LOCATION: Lustre インスタンスのゾーンロケーション。Managed Lustre CSI ドライバにサポートされているゾーンを指定する必要があります。
  - INSTANCE_NAME: Lustre インスタンスの名前。
- ip: Lustre インスタンスの IP アドレス。これは、前のコマンドの出力の mountPoint フィールドから取得します。
- filesystem: Managed Lustre インスタンスのファイルシステム名。
PersistentVolume オブジェクトでサポートされているフィールドの一覧については、Managed Lustre CSI ドライバのリファレンスドキュメントをご覧ください。
次のコマンドを実行して PersistentVolume を作成します。
```
kubectl apply -f lustre-pv.yaml
```

PersistentVolumeClaim を使用して Volume にアクセスする

Managed Lustre CSI ドライバの StorageClass を参照する PersistentVolumeClaim リソースを作成できます。

次のマニフェストファイルは、前に作成した StorageClass を参照する ReadWriteMany アクセスモードで PersistentVolumeClaim を作成する方法の例を示しています。

次のマニフェストを lustre-pvc.yaml という名前のファイルに保存します。

kind: PersistentVolumeClaim
apiVersion: v1
metadata:
  name: lustre-pvc
spec:
  accessModes:
    - ReadWriteMany
  storageClassName: "STORAGE_CLASS_NAME"
  volumeName: lustre-pv
  resources:
    requests:
      storage: STORAGE_SIZE

STORAGE_SIZE をストレージサイズに置き換えます（例: 9000Gi）。PersistentVolume の仕様と一致している必要があります。

次のコマンドを実行して PersistentVolumeClaim を作成します。
```
kubectl create -f lustre-pvc.yaml
```

ボリュームを消費するワークロードを作成する

このセクションでは、前のセクションで作成した PersistentVolumeClaim リソースを消費する Pod を作成する方法について説明します。

複数の Pod が同じ PersistentVolumeClaim リソースを共有できます。

次のマニフェストを my-pod.yaml という名前のファイルに保存します。

apiVersion: v1
kind: Pod
metadata:
  name: my-pod
spec:
  containers:
  - name: nginx
    image: nginx
    volumeMounts:
      - name: lustre-volume
        mountPath: /data
  volumes:
  - name: lustre-volume
    persistentVolumeClaim:
      claimName: lustre-pvc

次のコマンドを実行して、マニフェストをクラスタに適用します。
```
kubectl apply -f my-pod.yaml
```
Pod は、GKE が PersistentVolumeClaim をプロビジョニングするまで待機してから実行を開始します。完了までに数分かかることがあります。
Pod が実行されていることを確認するには、次のコマンドを使用します。
```
kubectl get pods
```
Pod が Running 状態になるまでに数分かかることがあります。

出力は次のようになります。
```
NAME           READY   STATUS    RESTARTS   AGE
my-pod         1/1     Running   0          11s
```

Managed Lustre ボリュームで fsGroup を使用する

マウントされたファイルシステムのルートレベルディレクトリのグループ所有権を変更し、Pod の SecurityContext で指定されたユーザーがリクエストした fsGroup と一致させることができます。

トラブルシューティング

トラブルシューティングのガイダンスについては、Managed Lustre ドキュメントのトラブルシューティングページをご覧ください。

クリーンアップ

Google Cloud アカウントに課金されないようにするには、このガイドで作成したストレージリソースを削除します。

Pod と PersistentVolumeClaim を削除します。

注: 「Retain」persistentVolumeReclaimPolicy で PersistentVolume を作成した場合、PersistentVolumeClaim を削除しても、PersistentVolume や基盤となる Managed Lustre インスタンスは削除されません。
```
kubectl delete pod my-pod
kubectl delete pvc lustre-pvc
```

PersistentVolume のステータスを確認します。Pod と PersistentVolumeClaim を削除すると、PersistentVolume は「Released」状態を報告します。

kubectl get pv

出力は次のようになります。

NAME        CAPACITY   ACCESS MODES   RECLAIM POLICY   STATUS     CLAIM                 STORAGECLASS   REASON   AGE
lustre-pv   9000Gi      RWX            Retain        Released   default/preprov-pvc                           2m28s

PersistentVolume を再利用します。PersistentVolume を再利用するには、クレーム参照（claimRef）を削除します。
```
kubectl patch pv lustre-pv --type json -p '[{"op": "remove", "path": "/spec/claimRef"}]'
```
PersistentVolume は「Available」ステータスを報告するようになり、新しい PersistentVolumeClaim にバインドする準備ができたことを示します。PersistentVolume のステータスを確認します。
```
kubectl get pv
```
出力は次のようになります。
```
NAME        CAPACITY   ACCESS MODES   RECLAIM POLICY   STATUS      CLAIM   STORAGECLASS   REASON   AGE
lustre-pv   9000Gi      RWX           Retain         Available                                   19m
```
PersistentVolume が不要になった場合は、削除します。PersistentVolume が不要になった場合は、削除します。
```
kubectl delete pv lustre-pv
```
PersistentVolume を削除しても、基盤となる Managed Lustre インスタンスは削除されません。

次のステップ

Managed Lustre のドキュメントを確認する。

Managed Lustre CSI ドライバを使用して GKE の既存の Managed Lustre インスタンスにアクセスする コレクションでコンテンツを整理 必要に応じて、コンテンツの保存と分類を行います。

高性能ネットワーキングのマルチ NIC サポート

Lustre 通信ポート

始める前に

環境変数を設定する

Managed Lustre CSI ドライバを構成する

新しい GKE クラスタで Managed Lustre CSI ドライバを有効にする

デフォルト ポート 988 を使用する

Autopilot

Standard

以前のポート 6988 を使用する

Autopilot

Standard

既存の GKE クラスタで Managed Lustre CSI ドライバを有効にする

デフォルト ポート 988 を使用する

以前のポート 6988 を使用する

既存のクラスタでノードのアップグレードが必要

（省略可）マルチ NIC ノードプールを作成する

Lustre でマルチ NIC を無効にする

クラスタの場合

ノードプールの場合

Managed Lustre CSI ドライバを無効にする

Managed Lustre CSI ドライバを使用して既存の Managed Lustre インスタンスにアクセスする

PersistentVolume を作成する

PersistentVolumeClaim を使用して Volume にアクセスする

ボリュームを消費するワークロードを作成する

Managed Lustre ボリュームで fsGroup を使用する

トラブルシューティング

クリーンアップ

次のステップ

Managed Lustre CSI ドライバを使用して GKE の既存の Managed Lustre インスタンスにアクセスする

デフォルトポート `988` を使用する

以前のポート `6988` を使用する

デフォルトポート `988` を使用する

以前のポート `6988` を使用する