このページの情報の一部またはすべては、S3NS の Trusted Cloud には適用されない場合があります。

このページは Cloud Translation API によって翻訳されました。

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

Autopilot Standard

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

始める前に

作業を始める前に、次のことを確認してください。

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

API を有効にする

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

制限事項と要件については、[CSI ドライバの概要] をご覧ください。
マネージド 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: 実際の Trusted Cloud by S3NS プロジェクト ID。
LUSTRE_NETWORK: GKE クラスタとマネージド Lustre インスタンスの両方が存在する共有 Virtual Private Cloud ネットワーク。
ZONE: GKE クラスタの地理的なゾーン（例: us-central1-a）。

マネージド Lustre CSI ドライバを構成する

このセクションでは、必要に応じてマネージド Lustre CSI ドライバを有効または無効にする方法について説明します。

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

新しい GKE クラスタを作成するときに Managed Lustre CSI ドライバを有効にするには、次の操作を行います。

Autopilot

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

標準

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

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

既存の GKE クラスタで Managed Lustre CSI ドライバを有効にするには、次のコマンドを使用します。

gcloud container clusters update ${CLUSTER_NAME} \
    --location=${LOCATION} \
    --enable-legacy-lustre-port

クラスタで Managed Lustre CSI ドライバを有効にすると、ノードが再作成され、Trusted Cloud コンソールまたは CLI 出力で CPU ノードが GPU イメージを使用しているように見えることがあります。次に例を示します。

config:
  imageType: COS_CONTAINERD
  nodeImageConfig:
    image: gke-1330-gke1552000-cos-121-18867-90-4-c-nvda

この動作は予期されたものです。GPU イメージは、CPU ノードで再利用され、Managed Lustre カーネルモジュールを安全にインストールします。GPU の使用量に対して過剰な請求が行われることはありません。

マネージド Lustre CSI ドライバを無効にする

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

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

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

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 インスタンス名、ファイルシステム、マウントポイントの各フィールドをメモしてください。

capacityGib: '18000'
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: 18000Gi
  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: Trusted Cloud by S3NS プロジェクト ID。
  - LOCATION: Lustre インスタンスのゾーンロケーション。マネージド Lustre CSI ドライバにサポートされているゾーンを指定する必要があります。
  - INSTANCE_NAME: Lustre インスタンスの名前。
- ip: Lustre インスタンスの IP アドレス。これは、前のコマンドの出力の mountPoint フィールドから取得します。
- filesystem: Managed Lustre インスタンスのファイルシステム名。
PersistentVolume オブジェクトでサポートされているフィールドの一覧については、マネージド Lustre CSI ドライバのリファレンスドキュメントをご覧ください。
次のコマンドを実行して PersistentVolume を作成します。
```
kubectl apply -f lustre-pv.yaml
```

PersistentVolumeClaim を使用してボリュームにアクセスする

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 をストレージサイズに置き換えます（例: 18000Gi）。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 ドキュメントのトラブルシューティングページをご覧ください。

クリーンアップ

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

Pod と PersistentVolumeClaim を削除します。

注: persistentVolumeReclaimPolicy が「Retain」の PersistentVolume を作成した場合、PersistentVolumeClaim を削除しても、PersistentVolume または基盤となるマネージド 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   18000Gi      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   18000Gi      RWX           Retain         Available                                   19m
```
PersistentVolume が不要になった場合は削除します。PersistentVolume が不要になった場合は、削除します。
```
kubectl delete pv lustre-pv
```
PersistentVolume を削除しても、基盤となる Managed Lustre インスタンスは削除されません。

次のステップ

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