このガイドでは、GKE Filestore CSI ドライバがある Google Kubernetes Engine 向け Filestore マルチシェアを使用する方法について説明します。
始める前に
始める前に、Filestore の使用に必要な設定手順を済ませます。
GKE Filestore CSI ドライバを有効にします(GKE バージョン 1.23 以降)。
複数のアプリケーションで Filestore Multishares を使用する
このセクションでは、Filestore マルチ共有の StorageClass を使用して、Deployment と Statefulset の 2 つのアプリケーションをデプロイする方法を説明します。また、GKE で同じ基盤となる Filestore Enterprise インスタンス内ですべてのボリュームがビンパッキング(アプリケーションを GKE ノードに効率的にパックするプロセス)される仕組みについても説明します。
GKE に用意された StorageClass を使用するか、カスタム StorageClass を作成します。
GKE Filestore CSI ドライバを有効にすると、ユーザーは次の構成で GKE に用意されたマルチシェア StorageClass
enterprise-multishare-rwx
にアクセスできます。この StorageClass を参照すると、GKE Filestore CSI ドライバは、動的ボリューム プロビジョニングを使用して、GKE のワークロード需要に沿って、新しい Persistent Volume Claims(PVC)用の永続ボリューム(PV)を自動的に作成します。$ kubectl describe sc enterprise-multishare-rwx Name: enterprise-multishare-rwx IsDefaultClass: No Annotations: components.gke.io/component-name=filestorecsi,components.gke.io/component-version=0.7.2,components.gke.io/layer=addon Provisioner: filestore.csi.storage.gke.io Parameters: instance-storageclass-label=enterprise-multishare-rwx,multishare=true,tier=enterprise AllowVolumeExpansion: True MountOptions: <none> ReclaimPolicy: Delete VolumeBindingMode: WaitForFirstConsumer Events: <none>
ユーザーは、必要に応じてこのテンプレートに基づくカスタム StorageClass を作成できます。このとき、次の命名要件に留意します。
StorageClass 名は、有効な DNS サブドメイン名でなければなりません。
マルチ共有 StorageClass の名前はインスタンス ラベルとしても使用されるため、ラベルの命名ガイドラインに沿って行う必要があります。
同じ 1 つの PVC を使用する複数の Pod レプリカがある Deployment を作成します。
次のような YAML 構成ファイルを作成します。
cat <<EOF | kubectl apply -f - apiVersion: apps/v1 kind: Deployment metadata: name: web-server-multishare labels: app: nginx spec: replicas: 5 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: test-pvc-fs --- kind: PersistentVolumeClaim apiVersion: v1 metadata: name: test-pvc-fs spec: accessModes: - ReadWriteMany storageClassName: enterprise-multishare-rwx resources: requests: storage: 100Gi EOF
Pod レプリカを確認します。
a. コマンドラインから次のコマンドを実行して、PVC のステータスを確認します。
$ kubectl get pvc
次のようなレスポンスが表示されます。
NAME STATUS VOLUME CAPACITY ACCESS MODES STORAGECLASS AGE test-pvc-fs Bound pvc-056d769d-a709-4bb2-b6d3-0361871b27a2 100Gi RWX enterprise-multishare-rwx 35m
b. コマンドラインから次のコマンドを実行して、Pod のステータスを確認します。
$ kubectl get pod
次のようなレスポンスが表示されます。
NAME READY STATUS RESTARTS AGE web-server-multishare-76c9ffb4b5-2dhml 1/1 Running 0 35m web-server-multishare-76c9ffb4b5-7mtcb 1/1 Running 0 35m web-server-multishare-76c9ffb4b5-csdbd 1/1 Running 0 35m web-server-multishare-76c9ffb4b5-rgx82 1/1 Running 0 35m web-server-multishare-76c9ffb4b5-zjl27 1/1 Running 0 35m
レプリカをスケールします。
a. コマンドラインから次のコマンドを実行して、Deployment を編集します。
$ kubectl edit deployment web-server-multishare
b. コマンドラインでファイルが開きます。
spec.replicas
フィールドを見つけて、その値を10
に更新します。c. コマンドラインから次のコマンドを実行して、適用した変更を確認します。
$ kubectl get pod
次のようなレスポンスが表示されます。
NAME READY STATUS RESTARTS AGE web-server-multishare-76c9ffb4b5-2dhml 1/1 Running 0 36m web-server-multishare-76c9ffb4b5-5ctkf 1/1 Running 0 3s web-server-multishare-76c9ffb4b5-7mtcb 1/1 Running 0 36m web-server-multishare-76c9ffb4b5-8dwmw 1/1 Running 0 2s web-server-multishare-76c9ffb4b5-csdbd 1/1 Running 0 36m web-server-multishare-76c9ffb4b5-lndcq 1/1 Running 0 2s web-server-multishare-76c9ffb4b5-rgx82 1/1 Running 0 36m web-server-multishare-76c9ffb4b5-vtd6p 1/1 Running 0 3s web-server-multishare-76c9ffb4b5-xm49s 1/1 Running 0 3s web-server-multishare-76c9ffb4b5-zjl27 1/1 Running 0 36m
10 個の Pod が実行中であることを確認します。
d. コマンドラインで次のコマンドを実行します。
$ kubectl get deployment
次のようなレスポンスが表示されます。
NAME READY UP-TO-DATE AVAILABLE AGE web-server-multishare 10/10 10 10 36m
e. コマンドラインから次のコマンドを実行して、PVC の Bound ステータスを確認します。
$ kubectl get pvc
次のようなレスポンスが表示されます。
NAME STATUS VOLUME CAPACITY ACCESS MODES STORAGECLASS AGE test-pvc-fs Bound pvc-056d769d-a709-4bb2-b6d3-0361871b27a2 100Gi RWX enterprise-multishare-rwx 37m
f. コマンドラインから次のコマンドを実行して、Deployment を編集します。
$ kubectl edit deployment web-server-multishare
g. コマンドラインでファイルが開きます。
spec.replicas
フィールドを見つけて、その値を2
に更新します。h. コマンドラインから次のコマンドを実行して、適用した変更を確認します。
$ kubectl get pod
次のようなレスポンスが表示されます。
NAME READY STATUS RESTARTS AGE web-server-multishare-76c9ffb4b5-2dhml 1/1 Running 0 38m web-server-multishare-76c9ffb4b5-7mtcb 1/1 Running 0 38m
Statefulset をデプロイします。
基盤となる Filestore インスタンスを共有する 2 つ目のアプリケーションをデプロイします。
これを行うには、200 GiB の容量をプロビジョニングし、それが最初のアプリケーションと同じ基盤となる Filestore インスタンスを使用することを確認します。
次に、アプリケーションを、合計 900 GiB を使用する 9 つのレプリカ(それぞれ 100 GiB を使用する 9 つのレプリカ)にスケールし、インスタンスを共有することで GKE が同じ Filestore インスタンスを使用することを確認します。
次のような YAML 構成ファイルを作成します。
cat <<EOF | kubectl apply -f - apiVersion: apps/v1 kind: StatefulSet metadata: name: web spec: serviceName: "nginx" replicas: 2 selector: matchLabels: app: nginx template: metadata: labels: app: nginx spec: containers: - name: nginx image: k8s.gcr.io/nginx-slim:0.8 ports: - containerPort: 80 name: web volumeMounts: - name: test-pvc-multishare mountPath: /usr/share/nginx/html volumeClaimTemplates: - metadata: name: test-pvc-multishare spec: accessModes: [ "ReadWriteMany" ] storageClassName: enterprise-multishare-rwx resources: requests: storage: 100Gi EOF
Statefulset レプリカとボリュームを確認します。
コマンドラインで次のコマンドを実行します。
$ kubectl get pod
次のようなレスポンスが表示されます。
NAME READY STATUS RESTARTS AGE web-0 1/1 Running 0 4m48s web-1 1/1 Running 0 3m32s web-server-multishare-76c9ffb4b5-2dhml 1/1 Running 0 57m web-server-multishare-76c9ffb4b5-7mtcb 1/1 Running 0 57m
最初の 2 つの Pod は Statefulset に関連付けられています。後の 2 つの Pod は Deployment に関連付けられています。
コマンドラインで次のコマンドを実行します。
$ kubectl get statefulset
次のようなレスポンスが表示されます。
NAME READY AGE web 2/2 2m8s
コマンドラインで次のコマンドを実行します。
$ kubectl get pvc
次のようなレスポンスが表示されます。
NAME STATUS VOLUME CAPACITY ACCESS MODES STORAGECLASS AGE test-pvc-fs Bound pvc-056d769d-a709-4bb2-b6d3-0361871b27a2 100Gi RWX enterprise-multishare-rwx 54m test-pvc-multishare-web-0 Bound pvc-7aa21b5a-5343-4547-b7d7-414c16af15a7 100Gi RWX enterprise-multishare-rwx 114s test-pvc-multishare-web-1 Bound pvc-8b37cd6e-d764-4d38-80d7-d74228536cfe 100Gi RWX enterprise-multishare-rwx 38s
PVC
test-pvc-fs
は、Deploymentweb-server-multishare
に関連付けられています。PVC
test-pvc-multishare-web-0
とtest-pvc-multishare-web-1
は、Statefulset に関連付けられています。Statefulset レプリカをスケールします。
レプリカの数を 9 に増やします。カウントが増えると、対応する PVC が作成されます。
a. コマンドラインで次のコマンドを実行します。
$ kubectl edit statefulset web
b. コマンドラインでファイルが開きます。
spec.replicas
フィールドを見つけて、その値を9
に更新します。c. コマンドラインから次のコマンドを実行して、適用した変更を確認します。
$ kubectl get statefulset
次のようなレスポンスが表示されます。
NAME READY AGE web 9/9 13m
d. コマンドラインで次のコマンドを実行します。
$ kubectl get deployment
次のようなレスポンスが表示されます。
NAME READY UP-TO-DATE AVAILABLE AGE web-server-multishare 2/2 2 2 65m
e. コマンドラインで次のコマンドを実行します。
$ kubectl get pvc
次のようなレスポンスが表示されます。
NAME STATUS VOLUME CAPACITY ACCESS MODES STORAGECLASS AGE test-pvc-fs Bound pvc-056d769d-a709-4bb2-b6d3-0361871b27a2 100Gi RWX enterprise-multishare-rwx 65m test-pvc-multishare-web-0 Bound pvc-7aa21b5a-5343-4547-b7d7-414c16af15a7 100Gi RWX enterprise-multishare-rwx 13m test-pvc-multishare-web-1 Bound pvc-8b37cd6e-d764-4d38-80d7-d74228536cfe 100Gi RWX enterprise-multishare-rwx 12m test-pvc-multishare-web-2 Bound pvc-3fcbd132-939f-4364-807a-7c8ac6a3e64e 100Gi RWX enterprise-multishare-rwx 5m12s test-pvc-multishare-web-3 Bound pvc-5894afa5-2502-4ee7-9d5c-b7378cb85479 100Gi RWX enterprise-multishare-rwx 4m57s test-pvc-multishare-web-4 Bound pvc-ebbe452b-bc8f-4624-a830-a2094cce0d67 100Gi RWX enterprise-multishare-rwx 4m36s test-pvc-multishare-web-5 Bound pvc-5a73a698-d174-44cb-a3a1-e767966c3417 100Gi RWX enterprise-multishare-rwx 4m20s test-pvc-multishare-web-6 Bound pvc-102da6a9-2ca6-4f9e-9896-8fe14709db7a 100Gi RWX enterprise-multishare-rwx 3m55s test-pvc-multishare-web-7 Bound pvc-160e81cd-c5bf-4ae6-966e-518e8249e02d 100Gi RWX enterprise-multishare-rwx 3m38s test-pvc-multishare-web-8 Bound pvc-9b52d773-2e9a-40de-881c-dc06945ba3d7 100Gi RWX enterprise-multishare-rwx 118s
Filestore インスタンスの状態を確認します。
これで、2 つのレプリカ Pod がある Deployment、9 つのレプリカ Pod がある Statefulset、合計 10 個の PVC(それぞれのサイズは 100 GiB)が作成されました。すべてのボリュームは、1 つの Filestore マルチシェア インスタンスにまとめられます。
a. コマンドラインで次の
instances list
コマンドを実行します。$ gcloud beta filestore instances list --project=YOUR_PROJECT_ID --region=REGION
ここで
次のようなレスポンスが表示されます。
INSTANCE_NAME LOCATION TIER CAPACITY_GB FILE_SHARE_NAME IP_ADDRESS STATE CREATE_TIME fs-a767cef8-738e-4c8e-b70b-09cbb872d016 us-central1 ENTERPRISE 1024 N/A 10.192.53.2 READY 2022-06-21T21:15:30
b. コマンドラインで次の
instances describe
コマンドを実行します。$ gcloud filestore instances describe fs-a767cef8-738e-4c8e-b70b-09cbb872d016 --project=YOUR_PROJECT_ID --region=REGION capacityGb: '1024' capacityStepSizeGb: '256' createTime: '2022-06-21T21:15:30.464237089Z' labels: storage_gke_io_created-by: filestore_csi_storage_gke_io storage_gke_io_storage-class-id: enterprise-multishare-rwx maxCapacityGb: '10240' maxShareCount: '10' multiShareEnabled: true name: projects/YOUR_PROJECT_ID/locations/REGION/instances/fs-a767cef8-738e-4c8e-b70b-09cbb872d016 networks: - connectMode: DIRECT_PEERING ipAddresses: - 10.192.53.2 modes: - MODE_IPV4 network: csi-filestore-test-network reservedIpRange: 10.192.53.0/26 state: READY tier: ENTERPRISE
ここで
PVC を拡張して Filestore インスタンスを確認する
このセクションでは、既存の PVC を拡張して、Filestore インスタンスのサイズを確認する方法について説明します。
PVC を拡張します。
PVC(Filestore マルチシェア インスタンスの共有によって支えられる)は、最大 1 TiB まで大きくできます。これを確認するには、Pod でそれを使用しながら、Statefulset に関連付けられたボリュームの 1 つを拡張します。
コマンドラインから次のコマンドを実行して、レプリカ 0 の現在の PVC サイズを確認します。
$ kubectl get pvc test-pvc-multishare-web-0 -o json { "apiVersion": "v1", "kind": "PersistentVolumeClaim", "metadata": { "annotations": { "pv.kubernetes.io/bind-completed": "yes", "pv.kubernetes.io/bound-by-controller": "yes", "volume.beta.kubernetes.io/storage-provisioner": "filestore.csi.storage.gke.io", "volume.kubernetes.io/storage-provisioner": "filestore.csi.storage.gke.io" }, "creationTimestamp": "2022-06-21T22:07:42Z", "finalizers": [ "kubernetes.io/pvc-protection" ], "labels": { "app": "nginx" }, "name": "test-pvc-multishare-web-0", "namespace": "default", "resourceVersion": "48395", "uid": "7aa21b5a-5343-4547-b7d7-414c16af15a7" }, "spec": { "accessModes": [ "ReadWriteMany" ], "resources": { "requests": { "storage": "100Gi" } }, "storageClassName": "enterprise-multishare-rwx", "volumeMode": "Filesystem", "volumeName": "pvc-7aa21b5a-5343-4547-b7d7-414c16af15a7" }, "status": { "accessModes": [ "ReadWriteMany" ], "capacity": { "storage": "100Gi" }, "phase": "Bound" } }
コマンドラインから次のコマンドを実行して、サイズを 500 GiB に増やします。
$ kubectl edit pvc test-pvc-multishare-web-0
コマンドラインでファイルが開きます。
spec.resources.requests.storage
フィールドを見つけて、値を500Gi
に更新します。コマンドラインから次のコマンドを実行して、適用した変更を確認します。
$ kubectl get pvc test-pvc-multishare-web-0
次のようなレスポンスが表示されます。
NAME STATUS VOLUME CAPACITY ACCESS MODES STORAGECLASS AGE test-pvc-multishare-web-0 Bound pvc-7aa21b5a-5343-4547-b7d7-414c16af15a7 500Gi RWX enterprise-multishare-rwx 28m
Filestore CSI ドライバがリクエストを受け入れ、まず基盤となる Filestore インスタンスを拡張し、続いて PVC を支える共有を拡張します。
具体的には、Filestore CSI ドライバで、インスタンスが 1536 Gi に自動的に拡張され、500Gi の新しい共有サイズに対応しました。
コマンドラインから、次の
instances describe
コマンドを実行して Filestore インスタンスの容量を確認します。$ gcloud filestore instances describe fs-a767cef8-738e-4c8e-b70b-09cbb872d016 --project=YOUR_PROJECT_ID --region=REGION capacityGb: '1536' capacityStepSizeGb: '256' createTime: '2022-06-21T21:15:30.464237089Z' labels: storage_gke_io_created-by: filestore_csi_storage_gke_io storage_gke_io_storage-class-id: enterprise-multishare-rwx maxCapacityGb: '10240' maxShareCount: '10' multiShareEnabled: true name: projects/YOUR_PROJECT_ID/locations/us-central1/instances/fs-a767cef8-738e-4c8e-b70b-09cbb872d016 networks: - connectMode: DIRECT_PEERING ipAddresses: - 10.192.53.2 modes: - MODE_IPV4 network: csi-filestore-test-network reservedIpRange: 10.192.53.0/26 state: READY tier: ENTERPRISE
ここで
共有 VPC での動的プロビジョニング
GKE 用の Filestore CSI ドライバは、共有 VPC にあるサービス プロジェクトのボリュームの動的プロビジョニングをサポートしています。以下のセクションでは、Filestore CSI ドライバを使用して、共有 VPC ネットワークにあるサービス プロジェクトの Filestore マルチシェア インスタンスに、ボリュームを動的にプロビジョニングする方法を説明します。
共有 VPC ネットワークとプライベート サービス アクセスの設定手順を済ませます。
StorageClass を作成します。これは、共有 VPC 上の Filestore マルチシェア インスタンスによって支えられるボリュームを動的にプロビジョニングします。
次のコマンドを実行して、
StorageClass
リソースをデプロイします。cat <<EOF | kubectl apply -f - apiVersion: storage.k8s.io/v1 kind: StorageClass metadata: name: csi-filestore-multishare-sharedvpc provisioner: filestore.csi.storage.gke.io parameters: network: "projects/HOST_PROJECT_ID/global/networks/SHARED_VPC_NAME" connect-mode: PRIVATE_SERVICE_ACCESS tier: enterprise multishare: "true" allowVolumeExpansion: true EOF
ここで
HOST_PROJECT_ID は、共有 VPC ネットワークのホスト プロジェクトの ID または名前です。例:
my-host-project
SHARED_VPC_NAME: 共有 VPC ネットワークの名前。例:
my-shared-vpc
予約済み IP アドレス範囲内にリソースをデプロイする場合は、コマンドで使用されるパラメータに次の行を追加します。
reserved-ip-range: RESERVED_NAME
ここで、RESERVED_NAME は、Filestore インスタンスをプロビジョニングできる予約済み IP アドレス範囲の名前です。たとえば、
filestore-reserved-ip-range
のようにします。予約済み IP 範囲を指定する場合は、CIDR 値そのものではなく名前付きアドレス範囲を指定する必要があります。詳細については、IP アドレス範囲の割り当てまたは予約済み IP アドレス範囲の構成をご覧ください。Google Cloud コンソールを使用して予約済みの名前を作成する方法の例については、IP の割り振りを作成するをご覧ください。
Deployment を作成します。
次のコマンドを実行して
Deployment
リソースを作成します。cat <<EOF | kubectl apply -f - apiVersion: apps/v1 kind: Deployment metadata: name: web-server-multishare labels: app: nginx spec: replicas: 5 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: test-pvc-fs-sharedvpc --- kind: PersistentVolumeClaim apiVersion: v1 metadata: name: test-pvc-fs-sharedvpc spec: accessModes: - ReadWriteMany storageClassName: csi-filestore-multishare-sharedvpc resources: requests: storage: 100Gi EOF
CMEK 対応 Filestore インスタンス
CMEK 対応 Filestore マルチシェア インスタンスにホストされる GKE ボリュームを作成できます。このセクションでは、Filestore インスタンスの顧客管理の暗号鍵(CMEK)を設定する方法について説明します。
顧客管理の暗号鍵の詳細は、StorageClass で指定できます。この StorageClass を参照する Filestore CSI ドライバによって動的に作成されたインスタンスでは、CMEK が有効になります。
CMEK 対応 StorageClass を作成します。
a. 次のコマンドを実行します。
cat <<EOF | kubectl apply -f - apiVersion: storage.k8s.io/v1 kind: StorageClass metadata: name: csi-filestore-multishare-cmek provisioner: filestore.csi.storage.gke.io parameters: tier: enterprise multishare: "true" instance-encryption-kms-key: projects/KEY_PROJECT_ID/locations/REGION/keyRings/RING_NAME/cryptoKeys/KEY_NAME allowVolumeExpansion: true EOF
ここで
Deployment を作成します。
b. 次のコマンドを実行して
Deployment
リソースを作成します。cat <<EOF | kubectl apply -f - apiVersion: apps/v1 kind: Deployment metadata: name: web-server-multishare labels: app: nginx spec: replicas: 5 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: test-pvc-fs-cmek --- kind: PersistentVolumeClaim apiVersion: v1 metadata: name: test-pvc-fs-cmek spec: accessModes: - ReadWriteMany storageClassName: csi-filestore-multishare-cmek resources: requests: storage: 100Gi EOF
PVC を Filestore インスタンスにマッピングする
このセクションでは、PVC を Filestore インスタンスにマッピングする方法について説明します。
Filestore マルチシェア インスタンスでは、各 PVC が Filestore CSI ドライバによって Filestore インスタンスにホストされます。ボリュームをホストする基盤となる Filestore インスタンスの詳細と、Kubernetes ボリュームを表す共有は、Persistent Volume 仕様の volumeHandle
フィールドに取得されます。ボリューム ハンドルの形式は次のとおりです。
modeMultishare/<storageclass-prefix>/<project>/<region>/<filestore-instance-name>/<filestore-share-name>
次の kubectl
コマンドを使用すると、PVC、PV、Filestore インスタンス、Filestore 共有の間のマッピングを速やかに判断できます。
コマンドラインで次のコマンドを実行します。
$ kubectl get pv -o jsonpath='{range .items[*]}{"pv="}{.metadata.name}{",pvc="}{.spec.claimRef.name}{",volumeHandle="}{.spec.csi.volumeHandle}{"\n"}{end}'
次のようなレスポンスが表示されます。
pv=pvc-67ad9abd-f25e-4130-b7ca-64d28bd29525,pvc=test-pvc-multishare,volumeHandle=modeMultishare/csi-filestore-multishare-sharedvpc/YOUR_PROJECT_ID/us-central1/fs-2109f680-3f04-4ada-b4bc-2a1c7fc47b88/pvc_67ad9abd_f25e_4130_b7ca_64d28bd29525
pv=pvc-c80f4de0-9916-4957-b8ae-b21206650ac0,pvc=test-pvc-fs-sharedvpc,volumeHandle=modeMultishare/csi-filestore-multishare-sharedvpc/YOUR_PROJECT_ID/us-central1/fs-2109f680-3f04-4ada-b4bc-2a1c7fc47b88/pvc_c80f4de0_9916_4957_b8ae_b21206650ac0
ここで
- YOUR_PROJECT_ID は、使用しているプロジェクトの名前です。例:
my-project
クラスタ内の 2 つの永続ボリュームが、1 つの Filestore インスタンスでホストされていることがわかります。
次のステップ
- サービス プロジェクトの共有 VPC ネットワーク上にインスタンスを作成する。
- ブロック、ファイル、オブジェクト ストレージの相対的なメリットを比較する。
- Google Cloud の HPC ワークロード向けストレージ オプション。