このガイドでは、動的プロビジョニングを使用して、GKE で Managed Lustre CSI ドライバを基盤とする新しい Kubernetes Volume を作成する方法について説明します。Managed Lustre CSI ドライバを使用すると、Managed Lustre インスタンスを基盤とするストレージをオンデマンドで作成し、ステートフル ワークロードのボリュームとしてアクセスできます。
始める前に
作業を始める前に、次のタスクが完了していることを確認してください。
- Google Cloud Managed Lustre API と Google Kubernetes Engine API を有効にします。 API を有効にする
- このタスクに Google Cloud CLI を使用する場合は、gcloud CLI をインストールして初期化する。すでに gcloud CLI をインストールしている場合は、
gcloud components updateコマンドを実行して最新のバージョンを取得します。以前のバージョンの gcloud CLI では、このドキュメントのコマンドを実行できない場合があります。
- 制限事項と要件については、CSI ドライバの概要をご覧ください。
- Managed Lustre CSI ドライバを有効にしてください。Standard クラスタと Autopilot クラスタではデフォルトで無効になっています。
環境変数を設定する
次の環境変数を設定します。
export CLUSTER_NAME=CLUSTER_NAME
export PROJECT_ID=PROJECT_ID
export NETWORK_NAME=LUSTRE_NETWORK
export IP_RANGE_NAME=LUSTRE_IP_RANGE
export FIREWALL_RULE_NAME=LUSTRE_FIREWALL_RULE
export LOCATION=ZONE
export CLUSTER_VERSION=CLUSTER_VERSION
次のように置き換えます。
CLUSTER_NAME: クラスタの名前。PROJECT_ID: 実際の Google Cloud プロジェクト ID。LUSTRE_NETWORK: GKE クラスタと Managed Lustre インスタンスの両方が存在する共有 Virtual Private Cloud（VPC）ネットワーク。LUSTRE_IP_RANGE: Managed Lustre との VPC ネットワーク ピアリング用に作成された IP アドレス範囲の名前。LUSTRE_FIREWALL_RULE: IP アドレス範囲からの TCP トラフィックを許可するファイアウォール ルールの名前。ZONE: GKE クラスタの地理的なゾーン（例:us-central1-a）。CLUSTER_VERSION: GKE クラスタのバージョン。
VPC ネットワークを設定する
Managed Lustre インスタンスと GKE クラスタを作成するときに同じ VPC ネットワークを指定する必要があります。ピアリングされた VPC ネットワークを使用する場合は、Network Connectivity Center を介して接続する必要があります。
サービス ネットワーキングを有効にするには、次のコマンドを実行します。
gcloud services enable servicenetworking.googleapis.com \ --project=${PROJECT_ID}VPC ネットワークを作成します。
--mtuフラグを8896に設定すると、パフォーマンスが 10% 向上します。gcloud compute networks create ${NETWORK_NAME} \ --subnet-mode=auto --project=${PROJECT_ID} \ --mtu=8896IP アドレス範囲を作成します。
gcloud compute addresses create ${IP_RANGE_NAME} \ --global \ --purpose=VPC_PEERING \ --prefix-length=20 \ --description="Managed Lustre VPC Peering" \ --network=${NETWORK_NAME} \ --project=${PROJECT_ID}前の手順で作成した範囲に関連付けられた CIDR 範囲を取得します。
CIDR_RANGE=$( gcloud compute addresses describe ${IP_RANGE_NAME} \ --global \ --format="value[separator=/](address, prefixLength)" \ --project=${PROJECT_ID} )作成した IP アドレス範囲からの TCP トラフィックを許可するファイアウォール ルールを作成します。
gcloud compute firewall-rules create ${FIREWALL_RULE_NAME} \ --allow=tcp:988,tcp:6988 \ --network=${NETWORK_NAME} \ --source-ranges=${CIDR_RANGE} \ --project=${PROJECT_ID}プロジェクトのネットワーク ピアリングを設定するには、必要な IAM 権限（特に
compute.networkAdminロールまたはservicenetworking.networksAdminロール）があることを確認します。- Google Cloud コンソール > [IAM と管理] に移動し、プロジェクト オーナーのプリンシパルを検索します。
- 鉛筆アイコンをクリックし、[+ 別のロールを追加] をクリックします。
- [Compute ネットワーク管理者] または [サービス ネットワーキング管理者] を選択します。
- [保存] をクリックします。
ピアリングを接続します。
gcloud services vpc-peerings connect \ --network=${NETWORK_NAME} \ --project=${PROJECT_ID} \ --ranges=${IP_RANGE_NAME} \ --service=servicenetworking.googleapis.com
Managed Lustre CSI ドライバを構成する
このセクションでは、必要に応じて Managed Lustre CSI ドライバを有効または無効にする方法について説明します。
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フラグについては、インスタンスを作成するのオプション フラグの説明をご覧ください。
- 以前の GKE バージョン: GKE クラスタで
新しいクラスタと既存のクラスタは、デフォルトのポート 988 または以前のポート 6988 を使用するように構成できます。
新しい 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 バージョンを使用している場合は、ノードプールを手動でアップグレードする必要があります。
ノードプールのアップグレード後、CPU ノードがGoogle Cloud コンソールまたは CLI 出力で GPU イメージを使用しているように見えることがあります。例:
config:
imageType: COS_CONTAINERD
nodeImageConfig:
image: gke-1330-gke1552000-cos-121-18867-90-4-c-nvda
この動作は予期されたものです。GPU イメージは、CPU ノードで再利用され、Managed Lustre カーネル モジュールを安全にインストールします。GPU の使用料金は発生しません。
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 ドライバを使用して新しい Volume を作成する
次のセクションでは、GKE で Managed Lustre インスタンスを基盤とする Kubernetes Volume を作成する際の一般的なプロセスについて説明します。
StorageClass を作成する
Managed Lustre CSI ドライバが有効になっている場合、GKE は Managed Lustre インスタンスのプロビジョニング用に StorageClass を自動的に作成します。StorageClass は、Managed Lustre のパフォーマンス ティアに依存し、次のいずれかになります。
lustre-rwx-125mbps-per-tiblustre-rwx-250mbps-per-tiblustre-rwx-500mbps-per-tiblustre-rwx-1000mbps-per-tib
GKE には、サポートされている Managed Lustre のパフォーマンス ティアごとにデフォルトの StorageClass が用意されています。これにより、独自の StorageClass を定義することなく、組み込みの StorageClass を使用できるため、Managed Lustre インスタンスの動的プロビジョニングが簡素化されます。
ゾーンクラスタの場合、CSI ドライバはクラスタと同じゾーンに Managed Lustre インスタンスをプロビジョニングします。リージョン クラスタの場合、リージョン内のいずれかのゾーンにインスタンスをプロビジョニングします。
次の例は、特定のトポロジ要件を持つカスタム StorageClass を作成する方法を示しています。
次のマニフェストを
lustre-class.yamlという名前のファイルに保存します。apiVersion: storage.k8s.io/v1 kind: StorageClass metadata: name: lustre-class provisioner: lustre.csi.storage.gke.io volumeBindingMode: Immediate reclaimPolicy: Delete parameters: perUnitStorageThroughput: "1000" network: LUSTRE_NETWORK allowedTopologies: - matchLabelExpressions: - key: topology.gke.io/zone values: - us-central1-aStorageClass でサポートされているフィールドの一覧については、Managed Lustre CSI ドライバのリファレンス ドキュメントをご覧ください。
次のコマンドを実行して StorageClass を作成します。
kubectl apply -f lustre-class.yaml
PersistentVolumeClaim を使用して Volume にアクセスする
このセクションでは、Managed Lustre CSI ドライバの StorageClass を参照する PersistentVolumeClaim リソースの作成方法について説明します。
次のマニフェストを
lustre-pvc.yamlという名前のファイルに保存します。apiVersion: v1 kind: PersistentVolumeClaim metadata: name: lustre-pvc spec: accessModes: - ReadWriteMany resources: requests: storage: 9000Gi storageClassName: lustre-classPersistentVolumeClaim でサポートされているフィールドの一覧については、Managed Lustre CSI ドライバのリファレンス ドキュメントをご覧ください。
次のコマンドを実行して PersistentVolumeClaim を作成します。
kubectl apply -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.yamlPod が動作していることを確認します。Pod は、PersistentVolumeClaim がプロビジョニングされた後に実行されます。この処理が完了するまで数分かかることがあります。
kubectl get pods出力は次のようになります。
NAME READY STATUS RESTARTS AGE my-pod 1/1 Running 0 11s
Managed Lustre ボリュームで fsGroup を使用する
マウントされたファイル システムのルートレベル ディレクトリのグループ所有権を変更し、Pod の SecurityContext で指定されたユーザーがリクエストした fsGroup と一致させることができます。fsGroup は、マウントされた Managed Lustre ファイル システム全体の所有権を再帰的に変更しません。マウント ポイントのルート ディレクトリのみが影響を受けます。
トラブルシューティング
トラブルシューティングのガイダンスについては、Managed Lustre ドキュメントのトラブルシューティング ページをご覧ください。
クリーンアップ
Google Cloud アカウントに課金されないようにするには、このガイドで作成したストレージ リソースを削除します。
Pod と PersistentVolumeClaim を削除します。
kubectl delete pod my-pod kubectl delete pvc lustre-pvcPersistentVolume のステータスを確認します。
kubectl get pv出力は次のようになります。
No resources found基盤となる Managed Lustre インスタンスが完全に削除されるまでに数分かかることがあります。