Filestore CSI ドライバを使用して Filestore インスタンスにアクセスする


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 インスタンスへの復元はサポートされていません。Filestore バックアップは、ボリューム スナップショット クラスtype:backup フィールドを追加することで、CSI Volume Snapshot API を使用してトリガーできます。

  • GKE Filestore CSI ドライバで、ボリューム拡張を使用できます。ボリューム拡張を使用すると、ボリュームの容量を変更できます。

  • Kubernetes ワークロードで事前にプロビジョニングされた Filestore インスタンスを使用することで、既存の Filestore インスタンスにアクセスできます。StorageClassDeployment を使用して Filestore インスタンスを動的に作成または削除し、Kubernetes ワークロードで使用することも可能です。

  • GKE 向け Filestore マルチシェアをサポートしています。この機能により、Filestore インスタンスを作成し、任意の数の GKE クラスタにまたがって、複数の小さな NFS にマウントされた PersistentVolume を同時に割り当てることができます。

要件

  • Filestore CSI ドライバを使用するには、サービスティアに適用される適切な GKE バージョン番号をクラスタで使用する必要があります。次のサービスティアのみがサポートされています。

    • 基本 HDD(GKE バージョン 1.21 以降)
    • 基本 SSD(GKE バージョン 1.21 以降)
    • ゾーン(10 TiB~100 TiB)(GKE バージョン 1.27 以降)
    • 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 を実行して最新のバージョンを取得する。

新しいクラスタで 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 フラグを使用してリリース チャンネルを指定することもできます。

コンソール

  1. Google Cloud コンソールで Google Kubernetes Engine のページに移動します。

    Google Kubernetes Engine に移動

  2. [ 作成] をクリックします。

  3. Standard クラスタモードを選択し、[構成] をクリックします。

  4. ニーズに合わせてクラスタを構成します。

  5. ナビゲーション パネルで、[クラスタ] の下にある [機能] をクリックします。

  6. [Filestore CSI ドライバの有効化] チェックボックスをオンにします。

  7. [作成] をクリックします。

共有 VPC ネットワークで Filestore を使用する場合は、共有 VPC を使用して新しいクラスタで Filestore CSI ドライバを有効にするをご覧ください。

Filestore CSI ドライバを有効にすると、ドライバとプロビジョナー名 filestore.csi.storage.gke.io を使用して、Kubernetes Volume でドライバを使用できます。

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

既存のクラスタで Filestore CSI ドライバを有効にするには、Google Cloud CLI か Google Cloud コンソールを使用します。

既存のクラスタでドライバを有効にするには、次の手順を行います。

gcloud

gcloud container clusters update CLUSTER_NAME \
   --update-addons=GcpFilestoreCsiDriver=ENABLED

CLUSTER_NAME は、既存のクラスタの名前に置き換えます。

コンソール

  1. Google Cloud コンソールで Google Kubernetes Engine のページに移動します。

    Google Kubernetes Engine に移動

  2. クラスタのリストで、変更するクラスタの名前をクリックします。

  3. [機能] の [Filestore CSI ドライバ] フィールドの横にある [Filestore CSI ドライバの編集] をクリックします。

  4. [Filestore CSI ドライバの有効化] チェックボックスをオンにします。

  5. [変更を保存] をクリックします。

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 など)。

コンソール

  1. Google Cloud コンソールで、Google Kubernetes Engine のメニューに移動します。

    Google Kubernetes Engine に移動

  2. クラスタのリストで、変更するクラスタの名前をクリックします。

  3. [機能] の [Filestore CSI ドライバ] フィールドの横にある [Filestore CSI ドライバの編集] をクリックします。

  4. [Filestore CSI ドライバの有効化] チェックボックスをオフにします。

  5. [変更を保存] をクリックします。

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

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

インスタンスにアクセスするための PersistentVolume と PersistentVolumeClaim を作成する

  1. 次の例に示すようなマニフェスト ファイルを作成し、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
    ---
    kind: PersistentVolumeClaim
    apiVersion: v1
    metadata:
      name: podpvc
    spec:
      accessModes:
        - ReadWriteMany
      storageClassName: ""
      volumeName: PV_NAME
      resources:
        requests:
          storage: 1Ti
    
  2. preprov-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 を自動でインストールします。

各 StorageClass は、サポートされている GKE バージョン番号で実行されている GKE クラスタでのみ使用できます。各サービスティアに必要なサポート対象のバージョンのリストについては、要件をご覧ください。

インストールされている StorageClass の名前を確認するには、次のコマンドを実行します。

kubectl get sc

また、provisioner フィールドに filestore.csi.storage.gke.io を追加して、Filestore CSI ドライバを使用する別の StorageClass をインストールすることも可能です。

Filestore は、新しいインスタンスを作成するネットワークを認識する必要があります。自動的にインストールされる StorageClass は、GKE クラスタに作成されたデフォルトのネットワークを使用します。このネットワークを削除した場合、または別のネットワークを使用する場合は、次の手順で新しい StorageClass を作成する必要があります。そうしないと、自動的にインストールされた StorageClass が機能しません。

  1. 次のマニフェストを 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
    

    マニフェストの以下のパラメータ構成を検討します。

    • volumeBindingModeImmediate に設定すると、ボリュームのプロビジョニングをすぐに開始できます。これが可能になるのは、Filestore インスタンスがどのゾーンからもアクセスできるためです。したがって、Compute Engine 永続ディスクとは異なり、GKE は Pod がスケジュールされているゾーンを認識する必要がありません。WaitForFirstConsumer に設定すると、GKE は Pod がスケジュールされてからプロビジョニングを開始します。詳細については、VolumeBindingMode をご覧ください。
    • サポートされる任意の Filestore 階層tier パラメータBASIC_HDDBASIC_SSDZONALENTERPRISE など)に指定できます。
    • network パラメータは、デフォルト以外の VPC で Filestore インスタンスをプロビジョニングする際に使用できます。デフォルト以外の VPC には、特別なファイアウォール ルールを設定する必要があります。
  2. 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 を作成しています。

  1. 次のマニフェスト ファイルを pvc-example.yaml として保存します。

    kind: PersistentVolumeClaim
    apiVersion: v1
    metadata:
      name: podpvc
    spec:
      accessModes:
      - ReadWriteMany
      storageClassName: filestore-example
      resources:
        requests:
          storage: 1Ti
    
  2. pvc-example.yaml マニフェスト ファイルに基づいて PersistentVolume リソースを作成するには、次のコマンドを実行します。

    kubectl create -f pvc-example.yaml
    

Volume を消費する Deployment を作成する

次の Deployment マニフェストの例では、pvc-example.yaml という名前の PersistentVolume リソースを使用しています。

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

  1. 次のマニフェストを 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: 1Ti
    
  2. filestore-example-deployment.yaml マニフェスト ファイルに基づいて Deployment を作成するには、次のコマンドを実行します。

    kubectl apply -f filestore-example-deployment.yaml
    
  3. Deployment が正常に作成されたことを確認します。

    kubectl get deployment
    

    Filestore インスタンスのプロビジョニングが完了するまで、しばらく時間がかかることがあります。それまで、Deployment は READY ステータスを報告しません。進行状況は、次のコマンドを実行して、PVC のステータスをモニタリングすることで確認できます。

    kubectl get pvc
    

    Volume のプロビジョニングが完了すると、PVC が BOUND ステータスになります。

Filestore インスタンスにラベルを付ける

ラベルを使用すると、関連するインスタンスをグループ化し、インスタンスに関するメタデータを格納できます。ラベルは、Filestore インスタンスを整理する際に役立つ Key-Value ペアです。各リソースにラベルを設定し、そのラベルに基づいてリソースをフィルタリングできます。

ラベルを指定するには、StorageClass.parameterslabels キーを使用します。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 ネットワークを使用するクラスタを設定するには、次の手順を行います。

  1. ホスト プロジェクトとサービス プロジェクトを作成します
  2. ホスト プロジェクトとサービス プロジェクトの両方で Google Kubernetes Engine API を有効にします
  3. ホスト プロジェクトで、ネットワークとサブネットを 1 つずつ作成します
  4. ホスト プロジェクトで共有 VPC を有効にします
  5. ホスト プロジェクトで、サービス プロジェクトの GKE サービス アカウントに HostServiceAgent ユーザーロール バインディングを付与します。
  6. 共有 VPC ネットワークでプライベート サービス アクセスを有効にします

共有 VPC を使用する新しいクラスタで Filestore CSI ドライバを有効にする

共有 VPC を使用する新しいクラスタで Filestore CSI ドライバを有効にするには、次の操作を行います。

  1. 使用可能なサブネットとセカンダリ範囲を確認します。クラスタを作成する際には、クラスタの 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 │
    └──────────────────────┴───────────────┴─────────────────────────────┘
    
  2. 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-services
    

    Standard

    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
    
  3. クラスタ内のノード、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 ワークロードに再接続できます。

  1. 特定のインスタンスに関する情報の取得の手順に沿って、事前にプロビジョニングされた Filestore インスタンスの詳細を確認します。

  2. PersistentVolume 仕様を再デプロイします。volumeAttributes フィールドで次のフィールドを変更して、ステップ 1 の Filestore インスタンスと同じ値を使用します。

    • ip: 事前にプロビジョニングされた Filestore インスタンスの IP アドレスに変更します。
    • volume: 事前にプロビジョニングされた Filestore インスタンスの共有名に変更します。
  3. PersistentVolumeClaim 仕様を再デプロイします。volumeName で、ステップ 2 と同じ PersistentVolume 名を参照していることを確認します。

  4. kubectl get pvc を実行して、PersistentVolumeClaim と PersistentVolume のバインディング ステータスを確認します。

  5. Pod 仕様を再デプロイし、Pod が Filestore 共有に再びアクセスできるようにします。

次のステップ