ピュア・ナレッジ
Kubernetes 永続ボリュームとは？

Kubernetes 永続ボリュームとは？

※このページの内容が日本語である場合は、機械翻訳システムで翻訳したものです。

ステートフル・アプリケーションのストレージ管理は、コンテナ・オーケストレーションの重要な要素です。Kubernetes 永続ボリューム（PV）は、個々のポッドのライフサイクルから独立してストレージ・リソースを管理するメカニズムを提供することで、このニーズに対応する基本的な機能です。この記事では、Kubernetes 永続ボリュームの概念、その機能、Kubernetes クラスタで効果的に使用するためのベストプラクティスについて解説します。

Kubernetes 永続ボリュームとは？

Kubernetes 永続ボリューム（PV）は、基礎となるストレージ技術を抽象化する Kubernetes クラスタ内のストレージ・リソースです。ポッドのライフサイクルに縛られ、ポッドが終了すると消える一時ストレージとは異なり、PV は永続ストレージを管理してアプリケーションに割り当てる方法を提供します。これにより、データにアクセスするポッドが停止または再スケジュールされた場合でも、データはそのまま維持されます。

永続ボリュームを使用すると、次のようなメリットが得られます。

ストレージの抽象化：PV は、物理ストレージ（ローカル・ディスク、SAN、クラウド・ストレージなど）の詳細をポッドから隠します。ユーザーは、具体的な実装の詳細を知ることなく、ストレージをリクエストできます。
永続性：PV は、ポッドの再起動や再スケジュールにおいてもデータの永続性を保証します。一時的なログを保存するために一時的なストレージを使用する Web サーバー・ポッドを想像してみてください。ポッドが再起動すると、これらのログは失われます。一方、永続ストレージは、データベース・ポッドによって維持されるアプリケーション・データなどのデータを確実に維持します。
ポッドからのストレージの分離：この分離により、ストレージ・リソースに対する柔軟性と制御性が向上します。ポッドは、基盤となるストレージに影響を与えることなく、簡単にスケールアップまたはスケールダウンできます。

Kubernetes 永続ボリュームの主な機能

Kubernetes 永続ボリュームは、さまざまなストレージ・ニーズに柔軟に対応する、いくつかの主要な機能を提供します。

ストレージ・クラス

ストレージ・クラスは、クラスタ内で利用可能なストレージの異なる階層やカテゴリを定義するテンプレートのように動作します。性能（SSD vs. HDD など）、容量、耐久性、コストなどの特性を指定できます。これにより、管理者はアプリケーションの特定の要件にあわせたストレージをプロビジョニングできます。

アクセス・モード

アクセス・モードは、ポッドが PV によって提供されるストレージと対話する方法を定義します。一般的なモードの概要を以下に示します。

ReadWriteOnce（RWO）：読み取り／書き込み権限でボリュームをマウントできるのは、一度に 1 つのポッドのみです。これにより、プライマリ・データベースのレプリカなど、排他的な書き込みアクセスを必要とするアプリケーションのデータ整合性が確保されます。
ReadOnlyMany（ROX）：複数のポッドで同時にボリュームをマウントできますが、読み取り専用モードのみです。これは、アプリケーションが構成ファイルやログ・リポジトリなど、変更なしで共有データにアクセスする必要がある場合に便利です。
ReadWriteMany（RWX）：複数のポッドで、読み取り／書き込み権限でボリュームをマウントできます。このアクセス・モードは、複数のポッドが同時に書き込まれる場合にデータの不整合が生じる可能性があるため、慎重に使用する必要があります。共有キャッシュや共同編集ツールなどの特定のユースケースに最適です。

リクレイム・ポリシー

リクレイム・ポリシーは、PV がポッドにバインドされなくなった後の Kubernetes の処理方法を決定します。主なポリシーは、次のとおりです。

保持：PV はポッドのバインドを解除した後に PV も維持されるため、将来の使用や移行に備えて手動で管理できます。
リサイクル：Kubernetes は PV をリサイクルします。これには、通常、既存のデータを消去し、将来のポッド割り当てのためにストレージを利用可能にすることが含まれます。
削除：PV オブジェクトとその基盤となるストレージ・リソースは完全に削除されます。データ・リカバリができない可能性があるため、注意して使用してください。

ボリューム・プラグイン

Kubernetes は、ボリューム・プラグインを活用して、プラットフォームとさまざまなストレージ・プロバイダ間のギャップを埋めます。これらのプラグインにより、Kubernetes は、ローカル・ストレージ、NFS や iSCSI などのネットワーク接続ストレージ（NAS）ソリューション、AWS EBS や GCE Persistent Disk などのクラウド・プロバイダ固有のストレージ・サービスなど、多様なストレージ・バックエンドを理解し、対話することができます。このプラグイン・アーキテクチャは、ストレージ・ソリューションの選択と Kubernetes クラスタとの統合において、大きな柔軟性を提供します。

永続ボリュームのプロビジョニング

Kubernetes は、永続ボリューム（PV）のプロビジョニングに、静的プロビジョニングと動的プロビジョニングの 2 つの主要な方法を提供します。それぞれのアプローチは、さまざまなユースケースに対応し、明確な利点を提供します。

静的プロビジョニング

静的プロビジョニングでは、クラスタ管理者が PV を手動で作成し、構成します。このアプローチは、ストレージ構成をきめ細かく制御し、頻繁に変更されない、明確に定義されたストレージ要件のシナリオに適しています。PV を静的にプロビジョニングする手順は、以下のとおりです。

1 . ストレージの詳細を定義：ストレージ容量、アクセス・モード（ReadWriteOnce、ReadOnlyMany、ReadWriteMany）、リクレイム・ポリシー（保持、リサイクル、削除）、ボリューム・プラグインの詳細（NFS のサーバー・アドレスなど）を決定します。

2. YAML を使用して PV オブジェクトを作成：YAML マニフェスト・ファイルを使用して、PV 構成を定義します。NFS ストレージの活用例を以下に示します。

apiVersion: v1
 kind: PersistentVolume
 metadata:
   name: my-pv-nfs
 spec:
   capacity:
     storage: 10Gi
   accessModes:
     - ReadWriteOnce
   persistentVolumeReclaimPolicy: Retain
   nfs:
     path: /path/to/nfs/share
     server: nfs-server.example.com

name：PV の一意の名前
storage：希望するストレージ容量（例：10ギガバイトで10Gi）
accessModes：アプリケーションの要件に応じて、適切なアクセス・モードを選択
persistentVolumeReclaimPolicy：ポッドからの非バインド後に Kubernetes が PV を処理する方法を定義
nfs.path：NFS サーバー上の NFS 共有へのパス
nfs.server：NFS サーバーの IP アドレスまたはホスト名

3. YAML マニフェストを適用：kubectl apply -f コマンドを使用して、Kubernetes クラスタに PV オブジェクトを作成します。

動的プロビジョニング

動的プロビジョニングは、StorageClass を活用して PV 作成を自動化します。管理者は StorageClass を定義し、必要なストレージ特性を指定し、PersistentVolumeClaim（PVC）がストレージを要求すると、Kubernetes がオンデマンドで PV 作成を処理できるようにします。動的プロビジョニングを使用する方法は、以下のとおりです。

1. StorageClass の定義：StorageClass YAML マニフェストを作成し、プロビジョナー、ストレージ・タイプ（SSD、HDD など）、プロビジョナーに必要な追加パラメータを指定します。AWS EBS の例を以下に示します。

apiVersion: storage.k8s.io/v1
 kind: StorageClass
 metadata:
   name: standard-ebs
 provisioner: kubernetes.io/aws-ebs
 parameters:
   type: gp2

name：StorageClass の一意の名前
provisioner：ストレージ・プロビジョナー・プラグインの名前（例：AWS EBS の場合は kubernetes.io/aws-ebs）
parameters.type：プロビジョナー内のストレージタイプ（AWS EBS の汎用 SSD ボリュームタイプの gp2 など）

2. StorageClass マニフェストを適用：kubectl apply -f を使用して、クラスタ内に StorageClass オブジェクトを作成します。

ポッドへの永続ボリュームのバインド

PV をポッドにバインドすることで、アプリケーションは永続ストレージを活用できます。この結合は、通常、PersistentVolumeClaim（PVC）によって達成されます。

PVC は、ポッドによって送信されるストレージ要求として機能します。ポッドのストレージ要件を規定しています。

アクセス・モード：ポッドがストレージと対話する方法を定義（例：ReadWriteOnce、ReadOnlyMany、ReadWriteMany）
ストレージ容量：ポッドに必要なストレージ容量
StorageClassName（オプション）：動的プロビジョニングのために StorageClass を参照

PV をポッドに結合するには、主に 2 つの方法があります。

静的バインディング：静的バインディングでは、管理者は事前にプロビジョニングされた PV を明示的に参照する PVC を手動で作成します。PVC と PV は、PVC の要求を満たすために、一致するアクセス・モードや PV の十分なストレージ容量など、互換性のある属性を持つ必要があります。
動的バインディング：動的バインディングは、PV を活用して PV の自動作成を可能にします。StorageClass を参照する PVC を搭載したポッドがデプロイされると、Kubernetes は、PVC の要件を満たす適切な PV（StorageClass に基づいて既存または新規にプロビジョニングされたもの）を検索します。適切な PV が見つかると、Kubernetes は自動的に PV と PVC を結合します。

以下は、pvc-example という PVC を利用する pod-example という名前のポッドの例です。

apiVersion: v1
 kind: Pod
 metadata:
   name: pod-example
 spec:
   containers:
   - name: app
     image: nginx
     volumeMounts:
     - mountPath: "/usr/share/nginx/html"
       name: pvc-storage
   volumes:
   - name: pvc-storage
     persistentVolumeClaim:
       claimName: pvc-example

この例では、ポッドは pvc-example という名前の PVC をコンテナ内のパス /usr/share/nginx/html にマウントします。これにより、ポッドは、基盤となる PV に格納された永続データにアクセスし、管理することができます。

永続ボリュームの管理

Kubernetes クラスタの効率的でスケーラブルなストレージ使用率を維持するためには、永続ボリューム（PV）を効果的に管理する必要があります。PV 管理の主な側面には、次のようなものがあります。

1. 永続ボリュームのサイズ変更

Kubernetes v1.11 は、PV のサイズを変更する機能を導入しました。これにより、PV に割り当てられたストレージ容量を動的に調整し、アプリケーションのストレージ要件の増大に対応できます。

PV のサイズを変更するには、PVC のストレージ要求を更新します。PV を参照する PVC を編集し、PVC の YAML 仕様の resources.requests セクション内のストレージ値を変更します。例えば、PVC の名前を 20Gi に増やすには、YAML マニフェストを更新します。

apiVersion: v1
 kind: PersistentVolumeClaim
 metadata:
   name: pvc-example
 spec:
   resources:
     requests:
       storage: 20Gi

PVC のストレージ要求を更新すると、Kubernetes は PV 用にプロビジョニングされた基盤となるストレージのサイズを変更しようとします。PV のサイズ変更は通常、一方向操作（拡張ストレージ）です。PV のサイズを縮小することは、データ損失の懸念があるためサポートされていません。

2. 永続ボリュームの削除

PV を削除するには、現在どの PVC にも縛られていないことを確認してください。PVC で使用されている PV は、データの損失を防ぐために削除することはできません。PV を削除する方法は、次のとおりです。

kubectl delete pv pv-example

pv-example を削除したい PV の実際の名前に置き換えます。

3. 永続ボリュームの更新

PV オブジェクト内でコア・ストレージ容量を直接変更することはできませんが、ラベルや注釈など、PV の特定のメタデータ・フィールドを更新できます。これらのラベルや注釈は、クラスタ内の PV の整理、識別、管理に役立ちます。

Kubernetes 永続ボリュームのベストプラクティス

Kubernetes 永続ボリュームを最大限に活用するには、次のようなベストプラクティスに従う必要があります。

適切なストレージ・クラスを選択する：アプリケーションの性能と耐久性の要件にあったストレージ・クラスを選択できます。例えば、高性能アプリケーションには SSD でバックアップされたストレージを使用し、アーカイブには HDD でバックアップされたストレージを使用します。
アクセス・モードを正しく設定する：アプリケーションがストレージにアクセスする方法に基づいて、PV に適したアクセス・モードを選択します。例えば、共有ファイル・システムには RWX、シングルインスタンス・データベースには RWO を使用できます。
リクレイム・ポリシーを賢く実装する：データ・ライフサイクル管理戦略にあったリクレイム・ポリシーを設定します。削除前に手動で介入する必要がある重要なデータについては、保持ポリシーを使用します。
監視とログ：監視ツールとログ・ツールを活用して、PV の使用、性能、健全性を監視します。Prometheus や Grafana などのツールは、ストレージ・インフラに関する貴重な知見を提供します。
高度なデータ管理には Portworx を使用する。Kubernetes における高度なデータ管理と永続ストレージ・ソリューションには、ピュア・ストレージの Portworxの使用をご検討ください。Portworx は、高可用性、ディザスタ・リカバリ、バックアップなどの機能を提供し、コンテナ化されたアプリケーション向けに特別に設計されています。

まとめ

Kubernetes 永続ボリューム（PV）は、ステートフル・アプリケーションのストレージを管理するための基本的なメカニズムを提供します。PV を活用することで、Kubernetes クラスタ内のデータの永続性、高可用性、効率的なストレージ使用率を確保できます。ピュア・ストレージの Portworx のようなソリューションは、Kubernetes の永続ボリュームのメリットを直感的に活用できます。Portworx は、高可用性、ディザスタ・リカバリ、バックアップなどの機能を備え、効率性を向上させるために人工知能を使用します。コンテナ化されたアプリケーションに最適な Kubernetes 永続ストレージ・ソリューションです。