このページでは、Kubernetes の PersistentVolumes および PersistentVolumeClaims の概要と、Google Kubernetes Engine(GKE)での使用について説明します。このページでは、Compute Engine の永続ディスクを使用したストレージについて重点的に説明します。
PersistentVolume
PersistentVolume
リソースは、クラスタ内の耐久性に優れたストレージの管理に使用されます。GKE では通常、PersistentVolume
には永続ディスクが使用されます。また、NFS など他のストレージ ソリューションも使用できます。Google Cloud 上の NFS ソリューションは、Filestore です。GKE クラスタの NFS PV ソリューションとして Filestore インスタンスを設定する方法については、Filestore ドキュメントの Google Kubernetes Engine クラスタからのファイル共有へのアクセスをご覧ください。
ストレージの選択肢のもう 1 つは、Cloud Volumes Service です。このプロダクトは、高度なデータ管理機能とスケーラビリティに優れたパフォーマンスを提供する、フルマネージド型のクラウドベースのデータ ストレージ サービスです。例については、Google Cloud の Cloud Volumes サービスをご覧ください。
Volumes とは異なり、PersistentVolume
のライフサイクルは Kubernetes によって管理されます。PersistentVolume
は動的にプロビジョニングすることが可能であるため、バックアップ ストレージの作成や削除を手動で行う必要はありません。
PersistentVolume
リソースは、Pod とは無関係に存在するクラスタ リソースです。このため、PersistentVolume
で表されるディスクとデータは、クラスタが変更される場合や、Pod が削除後に再作成される場合でも、存在し続けます。PersistentVolume
リソースは、PersistentVolumeClaims
によって動的にプロビジョニングすることも、クラスタ管理者が明示的に作成することもできます。
PersistentVolume
リソースの詳細については、Kubernetes のドキュメントをご覧ください。
PersistentVolumeClaims
PersistentVolumeClaim
は、PersistentVolume
リソースに対するリクエスト(要求)です。PersistentVolumeClaim
オブジェクトは、PersistentVolume
の特定のサイズ、アクセスモード、StorageClass
をリクエストします。リクエストを満たす PersistentVolume
が存在する場合やプロビジョニング可能な場合、PersistentVolumeClaim
はその PersistentVolume
にバインドされます。
ポッドは要求をボリュームとして使用します。クラスタは Claim を検査して、バインドされたボリュームを検出し、そのボリュームを Pod にマウントします。
PersistentVolumes
と PersistentVolumeClaims
を使用する場合、ポータビリティというメリットも得られます。PersistentVolume
は実際のバッキング ストレージのインターフェースであるため、さまざまなクラスタや環境で同じ Pod 仕様を簡単に使用できます。
StorageClass
gcePersistentDisk
などの Volume の実装は、StorageClass
リソースで構成されます。
GKE は、標準的な種類の永続ディスク(ext4)を使用するデフォルトの StorageClass
を作成します。PersistentVolumeClaim
で StorageClassName
が指定されていない場合は、デフォルトの StorageClass
が使用されます。デフォルトの StorageClass
は、独自のものに置き換えることができます。手順については、デフォルトの StorageClass を変更するをご覧ください。
独自の StorageClass
リソースを作成して、さまざまなストレージ クラスを記述できます。たとえば、クラスをサービス品質レベルやバックアップ ポリシーにマッピングできます。この概念は、他のストレージ システムでは「プロファイル」と呼ばれることもあります。
クラスタを Windows ノードプールとともに使用する場合、デフォルトの fstype(ext4)は Windows でサポートされていないため、StorageClass
を作成し、PersistentVolumeClaim
で StorageClassName
を指定する必要があります。Compute Engine 永続ディスクを使用している場合は、ファイル ストレージ タイプとして NTFS を使用する必要があります。
PersistentVolume の動的プロビジョニング
ほとんどの場合、PersistentVolume
オブジェクトを直接構成することや、Compute Engine の永続ディスクを作成する必要はありません。代わりに、PersistentVolumeClaim
を作成して、Kubernetes により自動で永続ディスクをプロビジョニングします。
次のマニフェストでは 30 ギガバイト(GiB)のディスクをリクエストし、単一のノードによる読み取り / 書き込みモードでマウントするようにアクセスモードを指定しています。
# pvc-demo.yaml
apiVersion: v1
kind: PersistentVolumeClaim
metadata:
name: pvc-demo
spec:
accessModes:
- ReadWriteOnce
resources:
requests:
storage: 30Gi
kubectl apply -f
pvc-demo.yaml
を使用してこの PersistentVolumeClaim
オブジェクトを作成すると、Kubernetes は対応する PersistentVolume
オブジェクトを動的に作成します。次の例は、作成された PersistentVolume
を示しています。
apiVersion: v1
kind: PersistentVolume
metadata:
name: pvc-cd3fd5e9-695a-11ea-a3da-42010a800003
uid: ced478c1-695a-11ea-a3da-42010a800003
annotations:
kubernetes.io/createdby: gce-pd-dynamic-provisioner
pv.kubernetes.io/bound-by-controller: "yes"
pv.kubernetes.io/provisioned-by: kubernetes.io/gce-pd
spec:
accessModes:
- ReadWriteOnce
capacity:
storage: 30Gi
claimRef:
apiVersion: v1
kind: PersistentVolumeClaim
name: pvc-demo
uid: cd3fd5e9-695a-11ea-a3da-42010a800003
gcePersistentDisk:
fsType: ext4
pdName: gke-cluster-1-pvc-cd3fd5e9-695a-11ea-a3da-42010a800003
nodeAffinity:
required:
nodeSelectorTerms:
- matchExpressions:
- key: topology.kubernetes.io/zone
operator: In
values:
- us-central1-c
- key: topology.kubernetes.io/region
operator: In
values:
- us-central1
persistentVolumeReclaimPolicy: Delete
storageClassName: standard
volumeMode: Filesystem
status:
phase: Bound
デフォルトのストレージ クラスがそのまま GKE で使用される場合、この PersistentVolume
には、新しい空の Compute Engine 永続ディスクが使用されます。Claim をボリュームとして使用する場合、このディスクが Pod で使用されます。Claim を削除すると、対応する PersistentVolume
オブジェクトとプロビジョニングされた Compute Engine の永続ディスクも削除されます。
動的にプロビジョニングされた永続ディスクが削除されないようにするには、PersistentVolume
リソースまたはその StorageClass
リソースの再利用ポリシーを Retain
に設定します。この場合、PersistentVolumeClaim を使用していなくても、永続ディスクが存在する限り永続ディスクの料金が発生します。再利用ポリシーの変更方法の例については、PersistentVolume の再利用ポリシーの変更と StorageClass リソースをご覧ください。
アクセスモード
PersistentVolume
リソースでは、次のアクセスモードがサポートされています。
- ReadWriteOnce: ボリュームを単一のノードで読み取り書き込み可能としてマウントできます。
- ReadOnlyMany: ボリュームを多数のノードで読み取り専用としてマウントできます。
- ReadWriteMany: ボリュームを多数のノードで読み取り書き込み可能としてマウントできます。Compute Engine の永続ディスクを使用する
PersistentVolume
リソースでは、このアクセスモードはサポートされていません。
Compute Engine の永続ディスクを ReadOnlyMany として使用する
永続ディスクは通常は ReadWriteOnce として使用され、ほとんどのアプリケーションでデフォルトのアクセスモードとなっています。Compute Engine の永続ディスクでは ReadOnlyMany モードもサポートされているため、同じアプリケーションで多数のアプリケーションや多数のレプリカが同じディスクを同時に使用できます。その例として、複数のレプリカ間での静的コンテンツの提供があります。
詳細については、複数のリーダーで使用する永続ディスクの作成方法の記事をご覧ください。
既存の永続ディスクを PersistentVolume として使用する
動的にプロビジョニングされる PersistentVolume
リソースは、作成時は空の状態です。既存の Compute Engine 永続ディスクにデータが格納されている場合は、対応する PersistentVolume
リソースを手動で作成してクラスタに導入できます。永続ディスクは、クラスタノードと同じゾーンに存在する必要があります。
詳細については、既存の永続ディスクを使用する永続ボリュームの作成方法をご覧ください。
Deployment と StatefulSet の比較
PersistentVolumeClaim
テンプレートや VolumeClaim
テンプレートは、それぞれ Deployments や StatefulSets など、上位レベルのコントローラで使用できます。
Deployment はステートレス アプリケーション用に設計されているため、Deployment のすべてのレプリカで同じ PersistentVolumeClaim
が共有されます。作成されたレプリカ Pod はそれぞれ同一であるため、この設定では ReadOnlyMany モードと ReadWriteMany モードのボリュームだけが動作します。
ReadWriteOnce ボリュームを使用するレプリカ 1 つしか存在しない Deployment は推奨されません。これは、デフォルトの Deployment 手順では、再作成時、2 つ目の Pod を作成した後、最初の Pod を停止するためです。ReadWriteOnce ボリュームがすでに使用されている場合、2 つ目の Pod が起動できず、2 つ目の Pod が起動していなければ、最初の Pod は削除されないため、Deployment がデッドロックで失敗する可能性があります。この場合は ReadWriteOnce ボリュームで StatefulSet を使用します。
レプリカごとに一意のボリュームが必要なステートフル アプリケーションを展開する場合は、StatefulSet を使用することを推奨します。StatefulSet で PersistentVolumeClaim テンプレートを使用することで、各レプリカ Pod に関連付けられた一意の PersistentVolumesClaims を使用して自動的にスケールアップできるアプリケーションを作成できます。
リージョン永続ディスク
リージョン永続ディスクは、同じリージョン内の 2 つのゾーン間でデータを複製するマルチゾーン リソースであり、ゾーン永続ディスクと同様に使用できます。ゾーン全体が停止した場合や、1 つのゾーン内の複数のクラスタノードがスケジュール不可になった場合、Kubernetes がこのボリュームを使用して他のゾーンにワークロードをフェイルオーバーできます。リージョン永続ディスクを使用して、GKE 上のステートフル ワークロード用の高可用性ソリューションを構築できます。プライマリ ゾーンとフェイルオーバー ゾーンの両方が、ワークロードを実行するのに十分なリソース容量で構成されていることを確認する必要があります。
リージョン SSD 永続ディスクは、高可用性とハイ パフォーマンスの両方が必要とされるデータベースなどのアプリケーションに適しています。詳細については、ブロック ストレージのパフォーマンスの比較をご覧ください。
リージョン永続ディスクは、ゾーン永続ディスクと同様に、必要に応じて動的にプロビジョニングすることも、クラスタ管理者が事前に手動でプロビジョニングすることもできます。リージョン永続ディスクを追加する方法については、リージョン永続ディスクのプロビジョニングをご覧ください。
永続ディスクのゾーン
ゾーン永続ディスクはゾーンリソースであり、リージョン永続ディスクはマルチゾーン リソースです。クラスタに永続ストレージを追加するとき、ゾーンが指定されない限り、GKE はディスクを単一のゾーンに割り当てます。その際、GKE はゾーンをランダムに選択します。永続ディスクがプロビジョニングされると、そのディスクを参照するすべての Pod が、ディスクと同じゾーンにスケジュールされます。
クラスタ内の永続ディスクを動的にプロビジョニングする場合は、StorageClass で WaitForFirstConsumer
ボリューム バインディング モードを設定することをおすすめします。この設定により、Kubernetes は Pod がスケジュールされているのと同じゾーンに永続ディスクをプロビジョニングします。反アフィニティやノードセレクタなどの Pod のスケジューリング制約が考慮されます。ゾーンの反アフィニティにより、StatefulSet Pod がゾーンとそれに対応するディスクに分散されます。
WaitForFirstConsumer
を設定するゾーン永続ディスクをプロビジョニングするための StorageClass
の例を、次に示します。
apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
name: slow
provisioner: kubernetes.io/gce-pd
parameters:
type: pd-standard
fstype: ext4
volumeBindingMode: WaitForFirstConsumer
リージョン永続ディスクの使用例については、リージョン永続ディスクのプロビジョニングをご覧ください。
次のステップ
- ステートフル アプリケーションをデプロイする場合に推奨される StatefulSet について学習する
- StatefulSet を使用してステートフル アプリケーションをデプロイする方法を学習する
- クラスタ内の永続ディスクの使用方法を学習する
- 複数のノードから読み取り可能なディスクの作成方法を学習する
- SSD でバックアップされる永続ディスクの作成方法を学習する
- リージョン永続ディスクをプロビジョニングする方法を学習する