Filestore CSI ドライバは、Google Kubernetes Engine（GKE）で Filestore インスタンスを使用するための主要な方法です。Filestore CSI ドライバは、オープンソースの Google Cloud Filestore CSI ドライバを利用したフルマネージドのエクスペリエンスを提供します。
Filestore CSI ドライバのバージョンは、Kubernetes のマイナー バージョン番号に関連付けられています。Filestore CSI ドライバのバージョンは通常、Kubernetes マイナー バージョンがリリースされた時点で入手可能な最新のドライバです。クラスタが最新の GKE パッチにアップグレードされると、ドライバは自動的に更新されます。
利点
Filestore CSI ドライバには、次のような利点があります。
Kubernetes API（
kubectl）を使用してフルマネージド NFS ストレージにアクセスできます。GKE Filestore CSI ドライバを使用して、PersistentVolume を動的にプロビジョニングできます。
GKE Filestore CSI ドライバで、ボリューム スナップショットを使用できます。CSI ボリューム スナップショットは、Filestore バックアップの作成に使用できます。
Filestore バックアップでは、すべてのファイルデータとメタデータを含むファイル共有の差分コピーが作成され、インスタンスとは別に保存されます。このコピーは、新しい Filestore インスタンスに対してのみ復元できます。既存の Filestore インスタンスへの復元はサポートされていません。CSI volume snapshot API を使用して、ボリューム スナップショット クラスに
type:backupフィールドを追加することで Filestore バックアップをトリガーできます。GKE Filestore CSI ドライバで、ボリューム拡張を使用できます。ボリューム拡張を使用すると、ボリュームの容量をサイズ変更できます。
Kubernetes ワークロードで事前にプロビジョニングされた Filestore インスタンスを使用することで、既存の Filestore インスタンスにアクセスできます。StorageClass または Deployment を使用して Filestore インスタンスを動的に作成または削除し、Kubernetes ワークロードで使用することも可能です。
GKE 向け Filestore マルチシェアをサポートしています。この機能により、Filestore インスタンスを作成し、任意の数の GKE クラスタにまたがって、複数の小さな NFS にマウントされた PersistentVolume を同時に割り当てることができます。
要件
Filestore CSI ドライバを使用するには、サービスティアに適用される適切な GKE バージョン番号をクラスタで使用する必要があります。次のサービスティアのみがサポートされています。
- 基本 HDD（GKE バージョン 1.21 以降）
- 基本 SSD（GKE バージョン 1.21 以降）
- GKE バージョン 1.27 以降のゾーン（10 TiB～100 TiB）
- Enterprise（GKE バージョン 1.25 以降）
- Filestore のマルチシェア機能を使用するには、クラスタで GKE バージョン 1.25 以降を使用する必要があります。
Filestore CSI ドライバは、Linux を使用するクラスタでのみサポートされています。Windows Server ノードはサポートされていません。
Filestore の最小インスタンス サイズは、1 TiB 以上にします。最小インスタンス サイズは、選択した Filestore サービス階層によって異なります。詳細については、サービス階層をご覧ください。
Filestore は、Filestore インスタンス上で NFSv3 ファイル システム プロトコルを使用し、NFSv3 互換クライアントをサポートします。
準備
作業を始める前に、次のことを確認してください。
- Cloud Filestore API と Google Kubernetes Engine API を有効にします。 API を有効にする
- このタスクに Google Cloud CLI を使用する場合は、gcloud CLI をインストールして初期化する。すでに gcloud CLI をインストールしている場合は、
gcloud components updateを実行して最新のバージョンを取得する。
- 共有 VPC ネットワークで Filestore を使用する場合は、共有 VPC で Filestore を使用するの追加の設定手順をご覧ください。
新しいクラスタで Filestore CSI ドライバを有効にする
新しい Standard クラスタの作成時に Filestore CSI ドライバを有効にするには、Google Cloud CLI または Google Cloud コンソールで次の手順を行います。
gcloud
gcloud container clusters create CLUSTER_NAME \
--addons=GcpFilestoreCsiDriver \
--cluster-version=VERSION
以下を置き換えます。
CLUSTER_NAME: クラスタの名前。VERSION: GKE のバージョン番号。この機能を使用するには、サポートされているバージョン番号を選択する必要があります。詳しくは、[#requirements]をご覧ください。または、--release-channelフラグを使用してリリース チャンネルを指定することもできます。
Console
Google Cloud コンソールで [Google Kubernetes Engine] ページに移動します。
[add_box 作成] をクリックします。
Standard クラスタモードを選択し、[構成] をクリックします。
ニーズに合わせてクラスタを構成します。
ナビゲーション パネルの [クラスタ] の下の [機能] をクリックします。
[Filestore CSI ドライバを有効にする] チェックボックスをオンにします。
[Create（作成）] をクリックします。
共有 VPC ネットワークで Filestore を使用する場合は、共有 VPC を使用して新しいクラスタで Filestore CSI ドライバを有効にするをご覧ください。
Filestore CSI ドライバを有効にすると、ドライバとプロビジョナー名 filestore.csi.storage.gke.io を使用して、Kubernetes Volume でドライバを使用できます。
既存のクラスタで Filestore CSI ドライバを有効にする
既存のクラスタで Filestore CSI ドライバを有効にするには、Google Cloud CLI か Google Cloud Console を使用します。
既存のクラスタでドライバを有効にするには、次の手順を行います。
gcloud
gcloud container clusters update CLUSTER_NAME \
--update-addons=GcpFilestoreCsiDriver=ENABLED
CLUSTER_NAME を、既存のクラスタの名前に置き換えます。
Console
Google Cloud コンソールで [Google Kubernetes Engine] ページに移動します。
クラスタのリストで、変更するクラスタの名前をクリックします。
[機能] の [Filestore CSI ドライバ] フィールドの横にある edit [Filestore CSI ドライバを編集] をクリックします。
[Filestore CSI ドライバの有効化] チェックボックスをオンにします。
[Save Changes] をクリックします。
Filestore CSI ドライバを無効にする
既存の Autopilot または Standard クラスタで Filestore CSI ドライバを無効にするには、Google Cloud CLI または Google Cloud コンソールを使用します。
gcloud
gcloud container clusters update CLUSTER_NAME \
--update-addons=GcpFilestoreCsiDriver=DISABLED \
--region REGION
次の値を置き換えます。
CLUSTER_NAME: 既存のクラスタの名前。REGION: クラスタのリージョン（us-central1など）。
Console
Google Cloud コンソールで、Google Kubernetes Engine のメニューに移動します。
クラスタのリストで、変更するクラスタの名前をクリックします。
[機能] の [Filestore CSI ドライバ] フィールドの横にある edit [Filestore CSI ドライバを編集] をクリックします。
[Filestore CSI ドライバの有効化] チェックボックスをオフにします。
[Save Changes] をクリックします。
Filestore CSI ドライバを使用して既存の Filestore インスタンスにアクセスする
このセクションでは、Kubernetes Volume で、GKE の Filestore CSI ドライバを使用して既存の Filestore インスタンスにアクセスする一般的なプロセスについて説明します。
インスタンスにアクセスするための PersistentVolume と PersistentVolumeClaim を作成する
次の例に示すようなマニフェスト ファイルを作成し、
preprov-filestore.yamlという名前を付けます。apiVersion: v1 kind: PersistentVolume metadata: name: PV_NAME spec: storageClassName: "" capacity: storage: 1Ti accessModes: - ReadWriteMany persistentVolumeReclaimPolicy: Retain volumeMode: Filesystem csi: driver: filestore.csi.storage.gke.io volumeHandle: "modeInstance/FILESTORE_INSTANCE_LOCATION/FILESTORE_INSTANCE_NAME/FILESTORE_SHARE_NAME" volumeAttributes: ip: FILESTORE_INSTANCE_IP volume: FILESTORE_SHARE_NAME claimRef: name: PVC_NAME namespace: NAMESPACE --- kind: PersistentVolumeClaim apiVersion: v1 metadata: name: PVC_NAME namespace: NAMESPACE spec: accessModes: - ReadWriteMany storageClassName: "" resources: requests: storage: 1Tipreprov-filestore.yamlマニフェスト ファイルに基づいてPersistentVolumeClaimリソースとPersistentVolumeリソースを作成するために、次のコマンドを実行します。kubectl apply -f preprov-filestore.yaml
次に、Volume を消費する Deployment を作成するに進みます。
Filestore CSI ドライバを使用して Volume を作成する
次のセクションでは、GKE で Filestore CSI ドライバによって管理される Kubernetes Volume を使用する際の一般的なプロセスについて説明します。
StorageClass を作成する
Filestore CSI ドライバを有効にすると、GKE は、Filestore インスタンスをプロビジョニングするために、以下の StorageClass を自動でインストールします。
zonal-rwx、Filestore ゾーン階層を使用します。大容量の範囲（10 TiB～100 TiB）でのみ使用できます。enterprise-rwx。Filestore エンタープライズ ティアを使用して、各 Kubernetes PersistentVolume が Filestore インスタンスにマッピングされます。enterprise-multishare-rwx。Filestore エンタープライズ ティアを使用します。ここで、各 Kubernetes PersistentVolume は、特定の Filestore インスタンスの共有にマッピングされます。詳細については、GKE 向け Filestore マルチシェアをご覧ください。standard-rwx。Filestore 基本 HDD サービスティアを使用します。premium-rwx。Filestore 基本 SSD サービスティアを使用します。
各 StorageClass は、サポートされている GKE バージョン番号で実行されている GKE クラスタでのみ使用できます。各サービスティアに必要なサポート対象のバージョンのリストについては、要件をご覧ください。
インストールされている StorageClass の名前を確認するには、次のコマンドを実行します。
kubectl get sc
また、provisioner フィールドに filestore.csi.storage.gke.io を追加して、Filestore CSI ドライバを使用する別の StorageClass をインストールすることも可能です。
Filestore は、新しいインスタンスを作成するネットワークを認識する必要があります。自動インストールされるストレージ クラスは、GKE クラスタ用に作成されたデフォルトのネットワークを使用します。このネットワークを削除した場合、または別のネットワークを使用する場合は、次の手順に沿って新しい StorageClass を作成する必要があります。そうしないと、自動的にインストールされた StorageClass が機能しません。
次のマニフェストを
filestore-example-class.yamlとして保存します。apiVersion: storage.k8s.io/v1 kind: StorageClass metadata: name: filestore-example provisioner: filestore.csi.storage.gke.io volumeBindingMode: Immediate allowVolumeExpansion: true parameters: tier: standard network: defaultマニフェストの以下のパラメータ構成を検討します。
volumeBindingModeをImmediateに設定すると、ボリュームのプロビジョニングをすぐに開始できます。これが可能になるのは、Filestore インスタンスがどのゾーンからもアクセスできるためです。したがって、Compute Engine 永続ディスクとは異なり、GKE は Pod がスケジュールされているゾーンを認識する必要がありません。WaitForFirstConsumerに設定すると、GKE は Pod がスケジュールされて初めてプロビジョニングを開始します。 詳細については、VolumeBindingMode をご覧ください。- サポートされた任意の Filestore 階層を
tierパラメータ（BASIC_HDD、BASIC_SSD、ZONAL、ENTERPRISEなど）に指定できます。 networkパラメータは、デフォルト以外の VPC で Filestore インスタンスをプロビジョニングする際に使用できます。デフォルト以外の VPC には、特別なファイアウォール ルールを設定する必要があります。
filestore-example-class.yamlマニフェスト ファイルに基づいてStorageClassリソースを作成するには、次のコマンドを実行します。kubectl create -f filestore-example-class.yaml
共有 VPC ネットワークで Filestore を使用する場合は、共有 VPC で Filestore CSI ドライバを使用する場合の StorageClass の作成をご覧ください。
PersistentVolumeClaim を使用して Volume にアクセスする
Filestore CSI ドライバの StorageClass を参照する PersistentVolumeClaim リソースを作成できます。
プリインストールまたはカスタムの StorageClass を使用できます。
次のマニフェスト ファイルの例では、filestore-example という名前の StorageClass を参照する PersistentVolumeClaim を作成しています。
次のマニフェスト ファイルを
pvc-example.yamlとして保存します。kind: PersistentVolumeClaim apiVersion: v1 metadata: name: podpvc spec: accessModes: - ReadWriteMany storageClassName: filestore-example resources: requests: storage: 1Tipvc-example.yamlマニフェスト ファイルに基づいてPersistentVolumeClaimリソースを作成するには、次のコマンドを実行します。kubectl create -f pvc-example.yaml
Volume を消費する Deployment を作成する
次の Deployment マニフェストの例では、pvc-example.yaml という名前の PersistentVolume リソースを使用しています。
複数の Pod が同じ PersistentVolumeClaim リソースを共有できます。
次のマニフェストを
filestore-example-deployment.yamlとして保存します。apiVersion: apps/v1 kind: Deployment metadata: name: web-server-deployment labels: app: nginx spec: replicas: 3 selector: matchLabels: app: nginx template: metadata: labels: app: nginx spec: containers: - name: nginx image: nginx volumeMounts: - mountPath: /usr/share/nginx/html name: mypvc volumes: - name: mypvc persistentVolumeClaim: claimName: podpvc --- kind: PersistentVolumeClaim apiVersion: v1 metadata: name: podpvc spec: accessModes: - ReadWriteMany storageClassName: filestore-example resources: requests: storage: 1Tifilestore-example-deployment.yamlマニフェスト ファイルに基づいて Deployment を作成するには、次のコマンドを実行します。kubectl apply -f filestore-example-deployment.yamlDeployment が正常に作成されたことを確認します。
kubectl get deploymentFilestore インスタンスのプロビジョニングが完了するまで、しばらく時間がかかることがあります。それまで、Deployment は
READYステータスを報告しません。進行状況は、次のコマンドを実行して、PVC のステータスをモニタリングすることで確認できます。kubectl get pvcVolume のプロビジョニングが完了したら、PVC のステータスが
BOUNDになったことを確認してください。
Filestore インスタンスにラベルを付ける
ラベルを使用すると、関連するインスタンスをグループ化し、インスタンスに関するメタデータを格納できます。ラベルは、Filestore インスタンスを整理する際に役立つ Key-Value ペアです。各リソースにラベルを設定し、そのラベルに基づいてリソースをフィルタリングできます。
ラベルを指定するには、StorageClass.parameters で labels キーを使用します。Filestore インスタンスには、インスタンスが作成された PersistentVolumeClaim/PersistentVolume に関する情報を使用してラベル付けできます。カスタムラベルのキーと値は、ラベルの命名規則に従う必要があります。Filestore インスタンスにカスタムラベルを適用する方法については、Kubernetes のストレージ クラスの例をご覧ください。
Filestore ボリュームで fsgroup を使用する
Kubernetes は fsGroup を使用して、Pod の SecurityContext でユーザーがリクエストした fsGroup に合わせてボリュームの権限とオーナー権限を変更します。fsGroup は、Pod 内のすべてのコンテナに適用される補助グループです。Filestore CSI ドライバによってプロビジョニングされたボリュームに fsgroup を適用できます。
Filestore ボリュームを使用して IP アクセスルールを構成する
Filestore は、Volume の IP ベースのアクセス制御ルールをサポートしています。この機能は、バージョン 1.29.5 以降を実行している GKE クラスタで使用できます。
この機能を使用すると、管理者は、GKE を介して動的にプロビジョニングされた Filestore インスタンスにアクセスできる IP アドレス範囲を指定できます。これにより、特に GKE クラスタの IP 範囲が過剰に広範囲であり、不正なユーザーやアプリケーションに Filestore インスタンスが公開される可能性があるシナリオで、アクセスを承認済みクライアントのみに制限することでセキュリティが強化されます。
これらのルールは、Filestore API を介して直接構成することも、Volume の作成時に Filestore CSI ドライバを介して構成することもできます。選択した構成を JSON 形式で指定するには、nfs-export-options-on-create パラメータを使用して StorageClass に指定します。
次のマニフェストの例は、構成を指定する方法を示しています。
apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
name: filestore-example
provisioner: filestore.csi.storage.gke.io
volumeBindingMode: Immediate
allowVolumeExpansion: true
parameters:
tier: "enterprise"
nfs-export-options-on-create: '[
{
"accessMode": "READ_WRITE",
"ipRanges": [
"10.0.0.0/24"
],
"squashMode": "ROOT_SQUASH",
"anonUid": "1003",
"anonGid": "1003"
},
{
"accessMode": "READ_WRITE",
"ipRanges": [
"10.0.0.0/28"
],
"squashMode": "NO_ROOT_SQUASH"
}
]'
セキュリティ対策
Filestore IP アクセスルールを使用すると、GKE ワークロードの共有ファイル ストレージ権限の構成が簡略化されます。ただし、ファイルの所有権とアクセス権をどのように管理するかを理解するには、いくつかの重要なコンセプトを理解する必要があります。
NFS とユーザーのマッピング NFS（ネットワーク ファイル システム）は、Filestore で使用されるプロトコルです。これは、クライアント システム（GKE Pod）のユーザーを Filestore サーバーのユーザーにマッピングすることで機能します。サーバー上のファイルがユーザー ID 1003 によって所有されており、クライアントがユーザー ID 1003 で接続している場合、クライアントはファイルにアクセスできます。
ルート スカッシュと
anonUid:ルート スカッシュ
ROOT_SQUASHは、クライアントが完全な root 権限で Filestore インスタンスにアクセスできないようにするセキュリティ機能です。ルート スカッシュが有効になっている場合、クライアント システムの root ユーザーは、anonUid設定で指定された権限のないユーザーにマッピングされます。ルート スカッシュなし（
NO_ROOT_SQUASH）では、クライアントは完全な root 権限で Filestore インスタンスにアクセスできます。これは初期設定には便利ですが、通常の運用では安全性が低くなります。
初期設定と権限: デフォルトでは、新しい Filestore インスタンスはすべて root ユーザーが所有します。他のユーザーの権限を設定しないでルート スカッシュを有効にすると、アクセス権が失われます。そのため、他のユーザーとグループのアクセス権を最初に構成するには、
NO_ROOT_SQUASHを含む NFS エクスポート ルールが少なくとも 1 つ必要です。
推奨事項
- 初期設定: 常に 1 つ以上の NFS エクスポート ルールを使用して開始します。このルールでは、
READ_WRITE権限を持つ管理者範囲を指定し、NO_ROOT_SQUASHアクセスを許可します。このアクセス権を使用し必要に応じて、ディレクトリの作成、権限の設定、所有権の割り当てを行います。 - セキュリティ: ルート スカッシュ（
ROOT_SQUASH）を有効にしてセキュリティを強化します。Volume の作成後に変更できるのは、Filestore API を介したアクセスルールのみです。 - 共有アクセス: Pod セキュリティ コンテキストで
fsGroupを使用して、共有ボリュームのグループ所有権を管理します。設定がROOT_SQUASHモードと重複しないようにしてください。重複すると、Access deniedエラー メッセージが返されます。
共有 VPC で Filestore を使用する
このセクションでは、サービス プロジェクトから共有 VPC ネットワークで Filestore インスタンスを使用する方法について説明します。
共有 VPC を使用してクラスタを設定する。
共有 VPC ネットワークを使用するクラスタを設定するには、次の手順を行います。
- ホスト プロジェクトとサービス プロジェクトを作成します。
- ホスト プロジェクトとサービス プロジェクトの両方で Google Kubernetes Engine API を有効にします。
- ホスト プロジェクトで、ネットワークとサブネットを 1 つずつ作成します。
- ホスト プロジェクトで共有 VPC を有効にします。
- ホスト プロジェクトで、サービス プロジェクトの GKE サービス アカウントに
HostServiceAgentユーザーロール バインディングを付与します。 - 共有 VPC ネットワークでプライベート サービス アクセスを有効にします。
共有 VPC を使用する新しいクラスタで Filestore CSI ドライバを有効にする
共有 VPC を使用する新しいクラスタで Filestore CSI ドライバを有効にするには、次の手順を行います。
使用可能なサブネットとセカンダリ範囲を確認します。クラスタを作成する際には、クラスタの Pod と Service に使用するサブネットとセカンダリ IP アドレス範囲を指定する必要があります。
gcloud container subnets list-usable \ --project=SERVICE_PROJECT_ID \ --network-project=HOST_PROJECT_ID出力は次のようになります。
PROJECT REGION NETWORK SUBNET RANGE HOST_PROJECT_ID us-central1 shared-net tier-1 10.0.4.0/22 ┌──────────────────────┬───────────────┬─────────────────────────────┐ │ SECONDARY_RANGE_NAME │ IP_CIDR_RANGE │ STATUS │ ├──────────────────────┼───────────────┼─────────────────────────────┤ │ tier-1-pods │ 10.4.0.0/14 │ usable for pods or services │ │ tier-1-services │ 10.0.32.0/20 │ usable for pods or services │ └──────────────────────┴───────────────┴─────────────────────────────┘GKE クラスタを作成する。次の例は、gcloud CLI を使用して、共有 VPC 用に構成された Autopilot クラスタまたは Standard クラスタを作成する方法を示しています。次の例では、ネットワークと 2 つのサブネットを作成するの、ネットワーク、サブネット、範囲名を使用します。
Autopilot
gcloud container clusters create-auto tier-1-cluster \ --project=SERVICE_PROJECT_ID \ --region=COMPUTE_REGION \ --network=projects/HOST_PROJECT_ID/global/networks/NETWORK_NAME \ --subnetwork=projects/HOST_PROJECT_ID/regions/COMPUTE_REGION/subnetworks/SUBNET_NAME \ --cluster-secondary-range-name=tier-1-pods \ --services-secondary-range-name=tier-1-servicesStandard
gcloud container clusters create tier-1-cluster \ --project=SERVICE_PROJECT_ID \ --zone=COMPUTE_REGION \ --enable-ip-alias \ --network=projects/HOST_PROJECT_ID/global/networks/NETWORK_NAME \ --subnetwork=projects/HOST_PROJECT_ID/regions/COMPUTE_REGION/subnetworks/SUBNET_NAME \ --cluster-secondary-range-name=tier-1-pods \ --services-secondary-range-name=tier-1-services \ --addons=GcpFilestoreCsiDriverクラスタ内のノード、Pod、Service 間の通信を許可するファイアウォール ルールを作成します。次の例は、
my-shared-net-rule-2という名前のファイアウォール ルールを作成する方法を示します。gcloud compute firewall-rules create my-shared-net-rule-2 \ --project HOST_PROJECT_ID \ --network=NETWORK_NAME \ --allow=tcp,udp \ --direction=INGRESS \ --source-ranges=10.0.4.0/22,10.4.0.0/14,10.0.32.0/20この例では、ソース範囲の IP 値は、前のステップで使用可能なサブネットとセカンダリ範囲を確認した際に取得したものです。
共有 VPC で Filestore CSI ドライバを使用する場合に StorageClass を作成する
次の例は、共有 VPC で Filestore CSI ドライバを使用する場合に、StorageClass を作成する方法を示します。
cat <<EOF | kubectl apply -f -
apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
name: filestore-sharedvpc-example
provisioner: filestore.csi.storage.gke.io
parameters:
network: "projects/HOST_PROJECT_ID/global/networks/SHARED_VPC_NAME"
connect-mode: PRIVATE_SERVICE_ACCESS
reserved-ip-range: RESERVED_IP_RANGE_NAME
allowVolumeExpansion: true
EOF
以下を置き換えます。
HOST_PROJECT_ID: 共有 VPC ネットワークのホスト プロジェクトの ID または名前。SHARED_VPC_NAME: 前に作成した共有 VPC ネットワークの名前。RESERVED_IP_RANGE_NAME: Filestore インスタンスをプロビジョニングする特定の予約済み IP アドレス範囲の名前。このフィールドは省略可能です。予約済み IP アドレス範囲を指定する場合は、CIDR 値を直接指定するのではなく名前付きアドレス範囲を指定する必要があります。
バージョン 1.23 以降が実行されている GKE クラスタで Filestore マルチシェアに基づくボリュームをプロビジョニングする場合は、GKE 向け Filestore マルチシェアでストレージを最適化するをご覧ください。
Filestore 単一共有ボリュームを再接続する
基本 HDD、基本 SSD、エンタープライズ（単一共有）ティアで Filestore を使用している場合は、以下の手順で既存の Filestore インスタンスを GKE ワークロードに再接続できます。
特定のインスタンスに関する情報の取得の手順に沿って、事前にプロビジョニングされた Filestore インスタンスの詳細を確認します。
PersistentVolume 仕様を再デプロイします。
volumeAttributesフィールドで次のフィールドを変更して、ステップ 1 の Filestore インスタンスと同じ値を使用します。ip: 事前にプロビジョニングされた Filestore インスタンスの IP アドレスに変更します。volume: 事前にプロビジョニングされた Filestore インスタンスの共有名に変更します。claimRefで、ステップ 2 と同じ PersistentVolumeClaim を参照していることを確認します。
PersistentVolumeClaim 仕様を再デプロイします。
kubectl get pvcを実行して、PersistentVolumeClaim と PersistentVolume のバインディング ステータスを確認します。Pod 仕様を再デプロイし、Pod が Filestore 共有に再びアクセスできるようにします。
次のステップ
- ステートフル Filestore ワークロードを GKE にデプロイする方法を学習します。
- Filestore Enterprise インスタンスを複数の永続ボリュームと共有する方法を学習する。
- ボリューム拡張の使用方法を確認する。
- ボリューム スナップショットの使用方法を学習する。
- GitHub の CSI ドライバの詳細を確認する。