このガイドでは、動的プロビジョニングを使用して、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を実行して最新のバージョンを取得する。
- 制限事項と要件については、CSI ドライバの概要をご覧ください。
- マネージド 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
次のように置き換えます。
CLUSTER_NAME: クラスタの名前。PROJECT_ID: 実際の Trusted Cloud by S3NS プロジェクト ID。LUSTRE_NETWORK: GKE クラスタとマネージド Lustre インスタンスの両方が存在する共有 Virtual Private Cloud（VPC）ネットワーク。LUSTRE_IP_RANGE: Managed Lustre との VPC ネットワーク ピアリング用に作成された IP アドレス範囲の名前。LUSTRE_FIREWALL_RULE: IP アドレス範囲からの TCP トラフィックを許可するファイアウォール ルールの名前。ZONE: GKE クラスタの地理的なゾーン（例:us-central1-a）。
VPC ネットワークを設定する
Managed Lustre インスタンスと GKE クラスタを作成するときに、同じ VPC ネットワークを指定する必要があります。
サービス ネットワーキングを有効にするには、次のコマンドを実行します。
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ロール）があることを確認します。- Trusted Cloud コンソール > [IAM と管理] に移動し、プロジェクト オーナーのプリンシパルを検索します。
- 鉛筆アイコンをクリックし、[+ 別のロールを追加] をクリックします。
- [Compute ネットワーク管理者] または [サービス ネットワーキング管理者] を選択します。
- [保存] をクリックします。
ピアリングを接続します。
gcloud services vpc-peerings connect \ --network=${NETWORK_NAME} \ --project=${PROJECT_ID} \ --ranges=${IP_RANGE_NAME} \ --service=servicenetworking.googleapis.com
マネージド 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
enable-legacy-lustre-port フラグが指定されている場合、CSI ドライバはポート 6988 を使用するように LNet（マネージド Lustre カーネル モジュールの仮想ネットワーク レイヤ）を構成します。このフラグは、GKE ノードの gke-metadata-server とのポート競合を回避するために必要です。
既存の GKE クラスタでマネージド Lustre CSI ドライバを有効にする
既存の GKE クラスタで Managed Lustre CSI ドライバを有効にするには、次のコマンドを使用します。
gcloud container clusters update ${CLUSTER_NAME} \
--location=${LOCATION} \
--enable-legacy-lustre-port
マネージド Lustre CSI ドライバを有効にすると、マネージド Lustre クライアントに必要なカーネル モジュールを更新するために、ノードの再作成がトリガーされることがあります。すぐに利用できるようにするには、ノードプールを手動でアップグレードすることをおすすめします。
リリース チャンネルの GKE クラスタは、スケジュールされたロールアウトに従ってアップグレードされます。これは、メンテナンス ウィンドウに応じて数週間かかることがあります。静的 GKE バージョンを使用している場合は、ノードプールを手動でアップグレードする必要があります。
ノードプールのアップグレード後、CPU ノードがTrusted Cloud コンソールまたは CLI 出力で 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 ドライバが無効になると、GKE はノードを自動的に再作成し、マネージド Lustre カーネル モジュールをアンインストールします。
マネージド Lustre CSI ドライバを使用して新しい Volume を作成する
次のセクションでは、GKE で Managed Lustre インスタンスを基盤とする Kubernetes Volume を作成する際の一般的なプロセスについて説明します。
StorageClass を作成する
Managed Lustre CSI ドライバが有効になっている場合、GKE は Managed Lustre インスタンスのプロビジョニング用に StorageClass を自動的に作成します。StorageClass は、Managed Lustre のパフォーマンス ティアに依存します。GKE で、次のいずれかです。
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 ドライバはクラスタと同じゾーンにマネージド 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: 18000Gi 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 ドキュメントのトラブルシューティング ページをご覧ください。
クリーンアップ
Trusted Cloud by S3NS アカウントに課金されないようにするには、このガイドで作成したストレージ リソースを削除します。
Pod と PersistentVolumeClaim を削除します。
kubectl delete pod my-pod kubectl delete pvc lustre-pvcPersistentVolume のステータスを確認します。
kubectl get pv出力は次のようになります。
No resources found基盤となる Managed Lustre インスタンスが完全に削除されるまでに数分かかることがあります。