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

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 インスタンスへの復元はサポートされていません。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 を実行して最新のバージョンを取得する。
注: gcloud CLI がすでにインストールされている場合には、必ず compute/region と compute/zone のプロパティを設定してください。デフォルトの場所を設定することで、gcloud CLI のエラー（One of [--zone, --region] must be supplied: Please specify location など）を防止できます。

共有 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] ページに移動します。

Google Kubernetes Engine に移動
[ 作成] をクリックします。
Standard クラスタモードを選択し、[構成] をクリックします。
ニーズに合わせてクラスタを構成します。
ナビゲーションパネルの [クラスタ] の下の [機能] をクリックします。
[Filestore CSI ドライバを有効にする] チェックボックスをオンにします。
[作成] をクリックします。

共有 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 を、既存のクラスタの名前に置き換えます。

コンソール

Google Cloud コンソールで [Google Kubernetes Engine] ページに移動します。

Google Kubernetes Engine に移動
クラスタのリストで、変更するクラスタの名前をクリックします。
[機能] の [Filestore CSI ドライバ] フィールドの横にある [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 のメニューに移動します。

Google Kubernetes Engine に移動
クラスタのリストで、変更するクラスタの名前をクリックします。
[機能] の [Filestore CSI ドライバ] フィールドの横にある [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
---
kind: PersistentVolumeClaim
apiVersion: v1
metadata:
  name: podpvc
spec:
  accessModes:
    - ReadWriteMany
  storageClassName: ""
  volumeName: PV_NAME
  resources:
    requests:
      storage: 1Ti

preprov-filestore.yaml マニフェストファイルに基づいて PersistentVolumeClaim リソースと PersistentVolume リソースを作成するために、次のコマンドを実行します。
```
kubectl apply -f preprov-filestore.yaml
```

次に、Volume を消費する Deployment を作成するに進みます。

Filestore CSI ドライバを使用して Volume を作成する

次のセクションでは、GKE で Filestore CSI ドライバによって管理される Kubernetes Volume を使用する際の一般的なプロセスについて説明します。

StorageClass の作成
PersistentVolumeClaim を使用して Volume にアクセスする
Volume を消費する Pod を作成する

StorageClass を作成する

Filestore CSI ドライバを有効にすると、GKE は、Filestore インスタンスをプロビジョニングするために、以下の StorageClasses を自動でインストールします。

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: 1Ti

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

filestore-example-deployment.yaml マニフェストファイルに基づいて Deployment を作成するには、次のコマンドを実行します。
```
kubectl apply -f filestore-example-deployment.yaml
```
Deployment が正常に作成されたことを確認します。
```
kubectl get deployment
```
Filestore インスタンスのプロビジョニングが完了するまで、しばらく時間がかかることがあります。それまで、Deployment は READY ステータスを報告しません。進行状況は、次のコマンドを実行して、PVC のステータスをモニタリングすることで確認できます。
```
kubectl get pvc
```
Volume のプロビジョニングが完了したら、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 ネットワークを使用するクラスタを設定するには、次の手順を行います。

共有 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-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

クラスタ内のノード、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 インスタンスの共有名に変更します。
PersistentVolumeClaim 仕様を再デプロイします。volumeName で、ステップ 2 と同じ PersistentVolume 名を参照していることを確認します。
kubectl get pvc を実行して、PersistentVolumeClaim と PersistentVolume のバインディングステータスを確認します。
Pod 仕様を再デプロイし、Pod が Filestore 共有に再びアクセスできるようにします。

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

利点

要件

準備

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

gcloud

Console

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

gcloud

コンソール

Filestore CSI ドライバを無効にする

gcloud

Console

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

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

Filestore CSI ドライバを使用して Volume を作成する

StorageClass を作成する

PersistentVolumeClaim を使用して Volume にアクセスする

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

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

Filestore ボリュームで fsgroup を使用する

Filestore ボリュームを使用して IP アクセスルールを構成する

セキュリティ対策

推奨事項

共有 VPC で Filestore を使用する

共有 VPC を使用してクラスタを設定する。

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

Autopilot

Standard

共有 VPC で Filestore CSI ドライバを使用する場合に StorageClass を作成する

Filestore 単一共有ボリュームを再接続する

次のステップ