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

Hyperdisk ストレージプールを使用してストレージのパフォーマンスとコストを最適化する

Autopilot Standard

このページでは、Google Kubernetes Engine（GKE）クラスタで GKE Hyperdisk ストレージプールを使用して、ディスク間でストレージ容量、スループット、IOPS をプールして共有する方法について説明します。

概要

ストレージプールは物理ストレージデバイスを論理的にグループ化するため、リソースをセグメント化できます。これらのストレージプール内に Google Cloud Hyperdisk をプロビジョニングすると、Hyperdisk ストレージプールが作成されます。Hyperdisk ストレージプールでは、事前にプロビジョニングされた容量、スループット、IOPS を複数の GKE クラスタディスクで共有できます。

Hyperdisk ストレージプールを使用すると、ストレージリソースをより効率的かつ費用対効果の高い方法で管理できます。これにより、重複除去やシンプロビジョニングなどの効率的なテクノロジーを活用できます。

このガイドでは、us-east4-c ゾーンを使用して、Hyperdisk Balanced ストレージプールとその他のリソースを作成します。

計画上の考慮事項

Hyperdisk ストレージプールをプロビジョニングして使用する前に、次の要件と制限事項を考慮してください。

ストレージプールの作成と管理

次の要件と制限事項が適用されます。

Compute Engine Hyperdisk ストレージプールの制限事項がすべて適用されます。
Hyperdisk ストレージプールでディスクを作成する場合の制限事項がすべて適用されます。
作成する Hyperdisk ストレージプールのタイプによって、ストレージプールに作成できるディスクのタイプが決まります。Hyperdisk ストレージプールのタイプをご覧ください。

ブートディスクをストレージプールにプロビジョニングする

次の要件と制限事項が適用されます。

クラスタのノードロケーションとノードプールのノードロケーションが、ストレージプールのゾーンと完全に一致している必要があります。この制限は、ノード自動プロビジョニングが有効になっている場合は適用されません。ノード自動プロビジョニングでは、必要に応じて正しいゾーンにノードプールが自動的に作成されます。
Pod を実行しているマシンタイプが、Hyperdisk Balanced ディスクタイプのアタッチをサポートしている必要があります。Hyperdisk Throughput はブートディスクとしてサポートされていません。Hyperdisk マシンタイプのサポートに関するドキュメントをご覧ください。
ストレージプールのブートディスクは、手動で作成または更新したノードプールでのみプロビジョニングできます。
ノード自動プロビジョニングを使用してノードが自動的に作成される場合、それらのノードのブートディスクをストレージプール内に配置することはできません。

アタッチされたディスクをストレージプールにプロビジョニングする

次の要件と制限事項が適用されます。

アタッチされたディスクをストレージプールでプロビジョニングするには、GKE バージョンが 1.29.2-gke.1035000 以降でなければなりません。
Compute Engine Persistent Disk CSI ドライバが有効になっている必要があります。Compute Engine Persistent Disk ドライバは、新しい Autopilot クラスタと Standard クラスタでデフォルトで有効になっています。Autopilot クラスタでは、無効にしたり、編集することはできません。ドライバを有効にするには、既存のクラスタで Compute Engine Persistent Disk CSI ドライバを有効にするをご覧ください。
クラスタのノードロケーションとノードプールのノードロケーションの少なくとも 1 つにストレージプールが存在する必要があります。
ストレージプールにプロビジョニングできるのは、Hyperdisk Throughput と Hyperdisk Balanced のアタッチ済みディスクだけです。アタッチされたディスクのタイプは、ストレージプールのタイプと一致する必要があります。詳細については、Hyperdisk ストレージプールのタイプをご覧ください。
Pod を実行しているマシンタイプが、ストレージプールから使用しているディスクタイプのアタッチをサポートしている必要があります。詳細については、Hyperdisk マシンタイプのサポートをご覧ください。

割り当て

Hyperdisk ストレージプールを作成するときに、容量とパフォーマンスに合わせて標準プロビジョニングまたは大容量プロビジョニングを構成できます。容量、スループット、IOPS の割り当てを増やす場合は、関連する割り当てフィルタの割り当てを増やすようリクエストします。

詳細については、プロジェクトの割り当てを表示すると割り当ての引き上げをリクエストするをご覧ください。

Hyperdisk Balanced ストレージプールには、次の割り当てフィルタを使用します。

HDB-STORAGE-POOL-TOTAL-ADVANCED-CAPACITY-per-project-region: 高度な容量プロビジョニングで容量を増やします。
HDB-STORAGE-POOL-TOTAL-ADVANCED-IOPS-per-project-region: 高度なパフォーマンスのプロビジョニングで IOPS を増やします。
HDB-STORAGE-POOL-TOTAL-ADVANCED-THROUGHPUT-per-project-region: 高度なパフォーマンスのプロビジョニングでスループットを増やします。
HDB-TOTAL-GB-per-project-region: 標準容量のプロビジョニングで容量を増やします。
HDB-TOTAL-IOPS-per-project-region: 標準パフォーマンスのプロビジョニングで IOPS を増やします。
HDB-TOTAL-THROUGHPUT-per-project-region: 標準パフォーマンスのプロビジョニングでスループットを増やします。

Hyperdisk Throughput ストレージプールには、次の割り当てフィルタを使用します。

HDT-STORAGE-POOL-TOTAL-ADVANCED-CAPACITY-per-project-region: 高度な容量プロビジョニングで容量を増やします。
HDT-STORAGE-POOL-TOTAL-ADVANCED-THROUGHPUT-per-project-region: 高度なパフォーマンスのプロビジョニングでスループットを増やします。
HDT-TOTAL-GB-per-project-region: 標準容量のプロビジョニングで容量を増やします。
HDT-TOTAL-THROUGHPUT-per-project-region: 標準パフォーマンスのプロビジョニングでスループットを増やします。

たとえば、プロジェクトとリージョンごとに、高度な容量のプロビジョニングで Hyperdisk Balanced ストレージプールの合計容量を増やす場合は、次のフィルタの割り当ての引き上げをリクエストします。

hdb-storage-pool-total-advanced-capacity-per-project-region。

料金

料金の詳細については、Hyperdisk ストレージプールの料金をご覧ください。

始める前に

作業を始める前に、次のことを確認してください。

Google Kubernetes Engine API を有効にする。

Google Kubernetes Engine 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 など）を防止できます。

Hyperdisk Balanced ストレージプールの作成については、サポートされているリージョンとゾーンをご覧ください。

Hyperdisk ストレージプールを作成する

ブートディスクまたはアタッチ済みディスクをストレージプールにプロビジョニングする前に、Hyperdisk ストレージプールを作成します。詳細については、Hyperdisk ストレージプールを作成するをご覧ください。

ストレージプールは、サポートされているゾーンのいずれかに作成してください。

たとえば、次のコマンドを使用して、高度な容量と高度なパフォーマンスを備えた Hyperdisk Balanced ストレージプールを作成し、us-east4-c ゾーンに 10 TB の容量、10,000 IOPS、1,024 MBps のスループットをプロビジョニングします。

export PROJECT_ID=PROJECT_ID
export ZONE=us-east4-c
gcloud compute storage-pools create pool-$ZONE \
    --provisioned-capacity=10tb --storage-pool-type=hyperdisk-balanced \
    --zone=$ZONE --project=$PROJECT_ID --capacity-provisioning-type=advanced \
    --performance-provisioning-type=advanced --provisioned-iops=10000 \
    --provisioned-throughput=1024

PROJECT_ID は、実際の Google Cloud アカウントのプロジェクト ID に置き換えます。

ストレージプールのゾーンを調べる

ノード自動プロビジョニングが有効になっている Autopilot クラスタと Standard クラスタでは、クラスタのリージョン内の任意のゾーンにストレージプールを作成できます。ストレージプールを作成したゾーンにノードプールが存在しない場合、GKE クラスタオートスケーラーがそのゾーンに新しいノードプールをプロビジョニングするまで、Pod は Pending 状態のままになります。
ノード自動プロビジョニングを使用しない Standard クラスタの場合は、ストレージプールはゾーンリソースであるため、クラスタのデフォルトのノードゾーンにストレージプールを作成します。クラスタのノードゾーンは、--node-locations フラグで設定できます。
- ゾーンクラスタの場合、--node-locations を指定しないと、すべてのノードがクラスタのプライマリゾーンに作成されます。
- リージョンクラスタの場合、--node-locations を指定しないと、GKE はワーカーノードをリージョン内のランダムに選択された 3 つのゾーンに分散します。

クラスタのデフォルトのノードゾーンを調べるには、次のコマンドを実行します。

gcloud container clusters describe CLUSTER_NAME  | yq '.locations'

CLUSTER_NAME は、ブートディスクまたはアタッチ済みディスクをプロビジョニングするときに作成するクラスタの名前に置き換えます。

GKE ブートディスクを Hyperdisk ストレージプールにプロビジョニングする

次のいずれかの操作を行うときに、GKE ブートディスクを Hyperdisk ストレージプールにプロビジョニングできます。

新しい GKE クラスタを作成する
新しいノードプールを作成する
既存のノードプールを更新する

クラスタを作成する

ストレージプールにブートディスクがプロビジョニングされた GKE クラスタを作成するには、次のコマンドを使用します。

gcloud container clusters create CLUSTER_NAME \
    --disk-type=DISK_TYPE --storage-pools=STORAGE_POOL,[...] \
    --node-locations=ZONE,[...] --machine-type=MACHINE_TYPE \
    --zone=ZONE

次のように置き換えます。

CLUSTER_NAME: 作成するクラスタの一意の名前。
DISK_TYPE: これを hyperdisk-balanced. に設定します。空白のままにすると、ディスクタイプはデフォルトで Hyperdisk Balanced になります。
STORAGE_POOL,[...]: クラスタのブートディスクがプロビジョニングされるストレージプールのリソースパス。カンマ区切りリストで指定します（例: projects/my-project/zones/us-east4-c/storagePools/pool-us-east4-c）。ストレージプールのリソースパスのゾーンが --node-locations のゾーンと一致していることを確認します。
ZONE,[...]: ノードフットプリントを複製するゾーンのカンマ区切りリスト。リージョンクラスタの場合は、代わりにリージョンを指定できます。すべてのゾーンが -location フラグ、--zone フラグ、または --region フラグで指定されたクラスタと同じリージョンに存在する必要があります。
MACHINE_TYPE: ノードに使用するサポート対象のマシンタイプ。
ZONE: クラスタを作成するゾーン。—region フラグを使用してリージョンクラスタを作成します。

ノードプールを作成する

ストレージプールにプロビジョニングされたブートディスクを使用して GKE ノードプールを作成するには、次のコマンドを使用します。

gcloud container node-pools create NODE_POOL_NAME \
    --disk-type=DISK_TYPE --storage-pools=STORAGE_POOL,[...] \
    --node-locations=ZONE,[...] --machine-type=MACHINE_TYPE \
    --zone=ZONE --cluster=CLUSTER_NAME

次のように置き換えます。

NODE_POOL_NAME: 作成するノードプールの一意の名前を指定します。
DISK_TYPE: これを hyperdisk-balanced. に設定します。空白のままにすると、ディスクタイプはデフォルトで Hyperdisk Balanced になります。
STORAGE_POOL,[...]: クラスタのブートディスクがプロビジョニングされるストレージプールのリソースパス。カンマ区切りリストで指定します（例: projects/my-project/zones/us-east4-c/storagePools/pool-us-east4-c）。ストレージプールのリソースパスのゾーンが --node-locations の値と一致していることを確認します。
ZONE,[...]: ノードフットプリントを複製するゾーンのカンマ区切りリスト。すべてのゾーンが -location フラグ、--zone フラグ、または --region フラグで指定されたクラスタと同じリージョンに存在する必要があります。
MACHINE_TYPE: ノードに使用するサポート対象のマシンタイプ。
ZONE: ノードプールを作成するゾーン。
CLUSTER_NAME: ノードプールを作成する既存のクラスタ。

ノードプールを更新する

update コマンドを使用して、ノードプール内のストレージプールを追加または置換できます。このコマンドを使用して、ノードプールからストレージプールを削除することはできません。

ブートディスクがストレージプールにプロビジョニングされるように GKE ノードプールを更新するには、次のコマンドを使用します。

gcloud container node-pools update NODE_POOL_NAME \
  --storage-pools=STORAGE_POOL,[...] \
  --zone=ZONE --cluster=CLUSTER_NAME

NODE_POOL_NAME: ストレージプールを使用するように更新する既存のノードプールの名前。
STORAGE_POOL,[...]: 既存のストレージプールのリソースパスのカンマ区切りリスト（例: projects/my-project/zones/us-east4-c/storagePools/pool-us-east4-c）。ストレージプールのリソースパスのゾーンが、更新するノードプールのゾーンと一致している必要があります。
ZONE: ノードプールが配置されているゾーン。
CLUSTER_NAME: このノードプールが属する GKE クラスタの名前。

この変更を行うにはノードを再作成する必要があります。これにより、実行中のワークロードが中断する可能性があります。この特定の変更について詳しくは、メンテナンスポリシーを尊重せずにノードのアップグレード戦略を使用してノードを再作成する手動変更の表で対応する行をご覧ください。ノードの更新の詳細については、ノードの更新による中断の計画をご覧ください。

GKE アタッチ済みディスクを Hyperdisk ストレージプールにプロビジョニングする

このセクションの内容:

ストレージプールにプロビジョニングされたディスクをアタッチして、新しい GKE クラスタを作成します。
Pod が PersistentVolumeClaim（PVC）を介してリクエストしたときに PersistentVolume（PV）を動的にプロビジョニングできるように、StorageClass を作成します。PV がストレージプールの共有リソースを使用するように、StorageClass の storage-pools パラメータを使用してストレージプールを指定します。その後、PVC でその StorageClass を使用して、Pod で使用される Hyperdisk Balanced ボリュームをプロビジョニングします。
PVC を作成して、GKE クラスタから Pod の PV（Hyperdisk ストレージの一部）をリクエストします。これにより、ストレージプールの共有リソースを利用できます。
PVC を使用する Deployment を作成して、Pod の再起動と再スケジューリング後もアプリケーションが永続ストレージにアクセスできるようにします。

GKE クラスタを作成する

始める前に、アタッチされたディスクのプロビジョニングに関する考慮事項を確認してください。

Autopilot

gcloud CLI を使用して Autopilot クラスタを作成するには、Autopilot クラスタを作成するをご覧ください。

例:

gcloud container clusters create-auto CLUSTER_NAME --region=REGION

次のように置き換えます。

CLUSTER_NAME: 作成するクラスタの一意の名前。
REGION: クラスタを作成するリージョン。

サポートされているマシンタイプを選択するには、Deployment を作成するときに cloud.google.com/compute-class: Performance nodeSelector を指定します。Performance コンピューティングクラスで使用可能な Compute Engine マシンシリーズのリストについては、サポートされているマシンシリーズをご覧ください。

Standard

gcloud CLI を使用して Standard ゾーンクラスタを作成するには、ゾーンクラスタの作成をご覧ください。

gcloud CLI を使用して Standard リージョンクラスタを作成するには、リージョンクラスタの作成をご覧ください。

例:

gcloud container clusters create CLUSTER_NAME --zone=ZONE --project=PROJECT_ID --machine-type=MACHINE_TYPE --disk-type="DISK_TYPE"

次のように置き換えます。

CLUSTER_NAME: 作成するクラスタの一意の名前。
ZONE: クラスタを作成するゾーン。—region フラグを使用してリージョンクラスタを作成します。
PROJECT_ID: Google Cloud アカウントのプロジェクト ID。
MACHINE_TYPE: ノードに使用するサポート対象のマシンタイプ。
DISK_TYPE: これを hyperdisk-balanced. に設定します。空白のままにすると、ディスクタイプはデフォルトで Hyperdisk Balanced になります。

StorageClass を作成する

Kubernetes で、ストレージプール内に PV を作成することを示すには、StorageClass を使用します。詳細については、StorageClass をご覧ください。

必要なスループットまたは IOPS レベルで新しい StorageClass を作成するには:

provisioner フィールドで pd.csi.storage.gke.io を使用します。
Hyperdisk Balanced ストレージタイプを指定します。
storage-pools パラメータに、使用する特定のストレージプールのリストを指定します。リスト内の各ストレージプールは projects/PROJECT_ID/zones/ZONE/storagePools/STORAGE_POOL_NAME. の形式で指定する必要があります。
必要に応じて、パフォーマンスパラメータ provisioned-throughput-on-create と provisioned-iops-on-create. を指定します。

各 Hyperdisk タイプにはパフォーマンスのデフォルト値があります。これは、プロビジョニングされた初期ディスクサイズによって決まります。StorageClass の作成時に、Hyperdisk タイプに応じて次のパラメータを指定できます。これらのパラメータを省略すると、GKE は容量ベースのディスクタイプのデフォルトを使用します。

パラメータ	Hyperdisk のタイプ	使用法
`provisioned-throughput-on-create`	Hyperdisk Balanced、Hyperdisk Throughput	MiBps 単位のスループット値は「Mi」修飾子で表します。たとえば、必要なスループットが 250 MiBps の場合は、StorageClass の作成時に `"250Mi"` を指定します。
`provisioned-iops-on-create`	Hyperdisk Balanced、Hyperdisk IOPS	IOPS 値は修飾子なしで指定する必要があります。たとえば、7,000 IOPS が必要な場合は、StorageClass の作成時に `"7000"` を指定します。

スループットまたは IOPS の許容値については、Hyperdisk ボリュームのパフォーマンスレベルを計画するをご覧ください。

次のマニフェストを使用して、ストレージプール projects/my-project/zones/us-east4-c/storagePools/pool-us-east4-c に PV を動的にプロビジョニングするための StorageClass を storage-pools-sc という名前で作成して適用します。

kubectl apply -f - <<EOF
apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
  name: storage-pools-sc
provisioner: pd.csi.storage.gke.io
volumeBindingMode: WaitForFirstConsumer
allowVolumeExpansion: true
parameters:
  type: hyperdisk-balanced
  provisioned-throughput-on-create: "140Mi"
  provisioned-iops-on-create: "3000"
  storage-pools: projects/my-project/zones/us-east4-c/storagePools/pool-us-east4-c
EOF

この StorageClass で volumeBindingMode: WaitForFirstConsumer を使用すると、PVC を使用する Pod が作成されるまで、PVC のバインディングとプロビジョニングが延期されます。このアプローチにより、PV が早期にプロビジョニングされず、PV とそれを使用する Pod の間でゾーンが一致するようになります。ゾーンが一致しない場合、Pod は Pending 状態のままになります。

PersistentVolumeClaim（PVC）を作成する

作成した storage-pools-sc StorageClass を参照する PVC を作成します。

次のマニフェストを使用して、my-pvc という名前の PVC を作成し、Hyperdisk Balanced ボリュームのターゲットストレージ容量を 2,048 GiB にします。

kubectl apply -f - <<EOF
apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: my-pvc
spec:
  storageClassName: storage-pools-sc
  accessModes:
  - ReadWriteOnce
  resources:
    requests:
      storage: 2048Gi
EOF

PVC を使用する Deployment を作成する

ベストプラクティス:

PersistentVolume で Pod を使用する場合は、Deployment や StatefulSet などのワークロードコントローラを使用します。

Hyperdisk Balanced をサポートするマシンシリーズのノードプールに Pod をスケジュールできるようにするには、cloud.google.com/machine-family ノードセレクタを使用して Deployment を構成します。詳細については、Hyperdisk のマシンタイプのサポートをご覧ください。次の Deployment の例では、c3 マシンシリーズを使用します。

次のマニフェストを作成して適用し、前のセクションで作成した PVC を使用して Postgres ウェブサーバーをデプロイする Pod を構成します。

Autopilot

Autopilot クラスタで、cloud.google.com/compute-class: Performance nodeSelector を指定して Hyperdisk Balanced ボリュームをプロビジョニングします。詳細については、Pod 専用のノードをリクエストするをご覧ください。

kubectl apply -f - <<EOF
apiVersion: apps/v1
kind: Deployment
metadata:
  name: postgres
spec:
  selector:
    matchLabels:
      app: postgres
  template:
    metadata:
      labels:
        app: postgres
    spec:
      nodeSelector:
        cloud.google.com/machine-family: c3
        cloud.google.com/compute-class: Performance
      containers:
      - name: postgres
        image: postgres:14-alpine
        args: [ "sleep", "3600" ]
        volumeMounts:
        - name: sdk-volume
          mountPath: /usr/share/data/
      volumes:
      - name: sdk-volume
        persistentVolumeClaim:
          claimName: my-pvc
EOF

Standard

ノード自動プロビジョニングが有効になっていない Standard クラスタでは、Deployment を作成する前に、指定されたマシンシリーズのノードプールが稼働していることを確認してください。そうしないと、Pod のスケジューリングが失敗します。

kubectl apply -f - <<EOF
apiVersion: apps/v1
kind: Deployment
metadata:
  name: postgres
spec:
  selector:
    matchLabels:
      app: postgres
  template:
    metadata:
      labels:
        app: postgres
    spec:
      nodeSelector:
        cloud.google.com/machine-family: c3
      containers:
      - name: postgres
        image: postgres:14-alpine
        args: [ "sleep", "3600" ]
        volumeMounts:
        - name: sdk-volume
          mountPath: /usr/share/data/
      volumes:
      - name: sdk-volume
        persistentVolumeClaim:
          claimName: my-pvc
EOF

Deployment が正常に作成されたことを確認します。

  kubectl get deployment

Hyperdisk インスタンスのプロビジョニングが完了し、READY ステータスが表示されるまでに数分かかることがあります。

アタッチされたディスクがプロビジョニングされているかどうかを確認する

my-pvc という名前の PVC が PV に正常にバインドされているかどうかを確認します。

kubectl get pvc my-pvc

出力は次のようになります。


NAME          STATUS   VOLUME                                     CAPACITY   ACCESS MODES   STORAGECLASS       AGE
my-pvc        Bound    pvc-1ff52479-4c81-4481-aa1d-b21c8f8860c6   2Ti        RWO            storage-pools-sc   2m24s

StorageClass と PVC で指定されたようにボリュームがプロビジョニングされているかどうかを確認します。

gcloud compute storage-pools list-disks pool-us-east4-c --zone=us-east4-c

出力は次のようになります。

NAME                                      STATUS  PROVISIONED_IOPS  PROVISIONED_THROUGHPUT  SIZE_GB
pvc-1ff52479-4c81-4481-aa1d-b21c8f8860c6  READY   3000              140                     2048

ストレージプールにアタッチされたディスクのスナップショットの作成と復元

ストレージプール内外にディスクを移動することはできません。ストレージプール内外にディスクを移動するには、スナップショットからディスクを再作成します。詳細については、ディスクタイプを変更するをご覧ください。

このセクションの内容:

Pod にプロビジョニングされたディスクにテストファイルを書き込みます。
ボリュームのスナップショットを作成し、そのディスクからテストファイルを削除します。
同じストレージプール内の新しいディスクにスナップショットを復元して、削除されたデータを復元します。

テストファイルを作成する

テストファイルを作成して確認するには:

Postgres Deployment の Pod 名を取得します。

kubectl get pods -l app=postgres

出力は次のようになります。

NAME                         READY   STATUS    RESTARTS   AGE
postgres-78fc84c9ff-77vx6   1/1     Running   0          44s

Pod にテストファイル hello.txt を作成します。

kubectl exec postgres-78fc84c9ff-77vx6 \
  -- sh -c 'echo "Hello World!" > /usr/share/data/hello.txt'

テストファイルが作成されたことを確認します。

kubectl exec postgres-78fc84c9ff-77vx6 \
  -- sh -c 'cat /usr/share/data/hello.txt'
Hello World!

ボリュームスナップショットを作成してテストファイルを削除する

スナップショットを作成して確認するには:

ボリュームのスナップショットの取得方法と管理方法を指定する VolumeSnapshotClass を作成します。

kubectl apply -f - <<EOF
apiVersion: snapshot.storage.k8s.io/v1
kind: VolumeSnapshotClass
metadata:
  name: my-snapshotclass
driver: pd.csi.storage.gke.io
deletionPolicy: Delete
EOF

VolumeSnapshot を作成し、my-pvc PersistentVolumeClaim にバインドされているボリュームからスナップショットを取得します。

kubectl apply -f - <<EOF
apiVersion: snapshot.storage.k8s.io/v1
kind: VolumeSnapshot
metadata:
  name: my-snapshot
spec:
  volumeSnapshotClassName: my-snapshotclass
  source:
    persistentVolumeClaimName: my-pvc
EOF

ボリュームスナップショットコンテンツが作成されていることを確認します。

kubectl get volumesnapshotcontents

出力は次のようになります。

NAME                                               READYTOUSE   RESTORESIZE     DELETIONPOLICY   DRIVER                  VOLUMESNAPSHOTCLASS   VOLUMESNAPSHOT   VOLUMESNAPSHOTNAMESPACE   AGE
snapcontent-e778fde2-5f1c-4a42-a43d-7f9d41d093da   false        2199023255552   Delete           pd.csi.storage.gke.io   my-snapshotclass      my-snapshot      default                   33s

スナップショットが使用可能であることを確認します。

kubectl get volumesnapshot \
  -o custom-columns='NAME:.metadata.name,READY:.status.readyToUse'

出力は次のようになります。

NAME          READY
my-snapshot   true

Pod postgres-78fc84c9ff-77vx6 で作成された元のテストファイル hello.txt を削除します。
```
kubectl exec postgres-78fc84c9ff-77vx6 \
    -- sh -c 'rm /usr/share/data/hello.txt'
```

ボリュームスナップショットを復元する

ボリュームスナップショットとデータを復元するには、次の操作を行います。

スナップショットからデータを復元する新しい PVC を作成し、新しいボリュームが元のボリュームと同じストレージプール（storage-pools-sc）内にプロビジョニングされるようにします。次のマニフェストを適用します。

kubectl apply -f - <<EOF
apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: pvc-restore
spec:
  dataSource:
    name: my-snapshot
    kind: VolumeSnapshot
    apiGroup: snapshot.storage.k8s.io
  storageClassName: storage-pools-sc
  accessModes:
    - ReadWriteOnce
  resources:
    requests:
      storage: 2048Gi
EOF

ここで復元した PVC を使用するように、postgres という名前の既存の Deployment を更新します。次のマニフェストを適用します。

kubectl apply -f - <<EOF
apiVersion: apps/v1
kind: Deployment
metadata:
  name: postgres
spec:
  selector:
    matchLabels:
      app: postgres
  template:
    metadata:
      labels:
        app: postgres
    spec:
      nodeSelector:
        cloud.google.com/machine-family: c3
      containers:
      - name: postgres
        image: google/cloud-sdk:slim
        args: [ "sleep", "3600" ]
        volumeMounts:
        - name: sdk-volume
          mountPath: /usr/share/data/
      volumes:
      - name: sdk-volume
        persistentVolumeClaim:
          claimName: pvc-restore
EOF

postgres Deployment の一部として新しく作成された Pod の名前を取得します。

kubectl get pods -l app=postgres

出力は次のようになります。

NAME                         READY   STATUS        RESTARTS   AGE
postgres-59f89cfd8c-42qtj   1/1     Running       0          40s

スナップショットからボリュームを復元した後、以前に削除した hello.txt ファイルが新しい Pod（postgres-59f89cfd8c-42qtj）に存在することを確認します。
```
kubectl exec postgres-59f89cfd8c-42qtj \
 -- sh -c 'cat /usr/share/data/hello.txt'
Hello World!
```
これにより、スナップショットプロセスと復元プロセスが正常に完了し、スナップショットのデータが Pod からアクセス可能な新しい PV に復元されたことを確認できます。

スナップショットから作成されたボリュームがストレージプール内にあることを確認します。

kubectl get pvc pvc-restore

出力は次のようになります。

NAME          STATUS   VOLUME                                     CAPACITY   ACCESS MODES   STORAGECLASS       AGE
pvc-restore   Bound    pvc-b287c387-bc51-4100-a00e-b5241d411c82   2Ti        RWO            storage-pools-sc   2m24s

新しいボリュームが StorageClass と PVC で指定されたようにプロビジョニングされているかどうかを確認します。
```
gcloud compute storage-pools list-disks pool-us-east4-c --zone=us-east4-c
```
出力は次のようになります。ここで、同じストレージプールにプロビジョニングされた新しいボリューム pvc-b287c387-bc51-4100-a00e-b5241d411c82 を確認できます。
```
NAME                                      STATUS  PROVISIONED_IOPS  PROVISIONED_THROUGHPUT  SIZE_GB
pvc-1ff52479-4c81-4481-aa1d-b21c8f8860c6  READY   3000              140                     2048
pvc-b287c387-bc51-4100-a00e-b5241d411c82  READY   3000              140                     2048
```
復元されたボリュームは、プールの共有リソースと機能を利用できます。

既存のボリュームをストレージプールに移行する

スナップショットと復元を使用して、ストレージプール外に存在するボリュームをストレージプールに移行します。

次の条件を満たしていることを確認します。

新しい PVC pvc-restore は、storage-pools パラメータを指定する StorageClass を参照しており、このパラメータがボリュームの移動先のストレージプールを指している。
スナップショット作成の対象となるソース PV が、storage-pools パラメータを指定しない StorageClass を持つ PVC に関連付けられている。

スナップショットから新しいボリュームに復元したら、ソースの PVC と PV を削除できます。

クリーンアップ

Google Cloud アカウントに課金されないようにするには、このガイドで作成したストレージリソースを削除します。まず、ストレージプール内のすべてのディスクを削除してから、ストレージプールを削除します。

ブートディスクを削除する

ノードプールのスケールダウンでノードを削除するか、ノードプール全体を削除すると、関連付けられたブートディスクが自動的に削除されます。クラスタを削除して、クラスタ内のすべてのノードプールのブートディスクを自動的に削除することもできます。

詳しくは以下をご覧ください。

アタッチされたディスクを削除する

Hyperdisk ストレージプールにプロビジョニングされたアタッチ済みディスクを削除するには:

PVC を使用する Pod を削除します。
```
kubectl delete deployments postgres
```
Hyperdisk ストレージプールの StorageClass を使用する PVC を削除します。
```
kubectl delete pvc my-pvc
```
PVC pvc-1ff52479-4c81-4481-aa1d-b21c8f8860c6 が削除されたことを確認します。
```
gcloud compute storage-pools list-disks pool-us-east4-c --zone=us-east4-c
```

Hyperdisk ストレージプールを削除する

次のコマンドを使用して、Hyperdisk ストレージプールを削除します。

gcloud compute storage-pools delete pool-us-east4-c --zone=us-east4-c --project=my-project

次のステップ

GKE のストレージのトラブルシューティングを確認する。
GitHub の Persistent Disk CSI ドライバの詳細を確認する。

Hyperdisk ストレージ プールを使用してストレージのパフォーマンスとコストを最適化する

概要

計画上の考慮事項

ストレージ プールの作成と管理

ブートディスクをストレージ プールにプロビジョニングする

アタッチされたディスクをストレージ プールにプロビジョニングする

割り当て

料金

始める前に

Hyperdisk ストレージ プールを作成する

ストレージ プールのゾーンを調べる

GKE ブートディスクを Hyperdisk ストレージ プールにプロビジョニングする

クラスタを作成する

ノードプールを作成する

ノードプールを更新する

GKE アタッチ済みディスクを Hyperdisk ストレージ プールにプロビジョニングする

GKE クラスタを作成する

Autopilot

Standard

StorageClass を作成する

PersistentVolumeClaim（PVC）を作成する

PVC を使用する Deployment を作成する

Autopilot

Standard

アタッチされたディスクがプロビジョニングされているかどうかを確認する

ストレージ プールにアタッチされたディスクのスナップショットの作成と復元

テストファイルを作成する

ボリューム スナップショットを作成してテストファイルを削除する

ボリューム スナップショットを復元する

既存のボリュームをストレージ プールに移行する

クリーンアップ

ブートディスクを削除する

アタッチされたディスクを削除する

Hyperdisk ストレージ プールを削除する

次のステップ

Hyperdisk ストレージプールを使用してストレージのパフォーマンスとコストを最適化する

ストレージプールの作成と管理

ブートディスクをストレージプールにプロビジョニングする

アタッチされたディスクをストレージプールにプロビジョニングする

Hyperdisk ストレージプールを作成する

ストレージプールのゾーンを調べる

GKE ブートディスクを Hyperdisk ストレージプールにプロビジョニングする

GKE アタッチ済みディスクを Hyperdisk ストレージプールにプロビジョニングする

ストレージプールにアタッチされたディスクのスナップショットの作成と復元

ボリュームスナップショットを作成してテストファイルを削除する

ボリュームスナップショットを復元する

既存のボリュームをストレージプールに移行する

Hyperdisk ストレージプールを削除する