PersistentVolume（パーシステントボリューム）

英語表記: PersistentVolume

概要

PersistentVolume（PV）は、Kubernetes環境において、Podのライフサイクルとは独立してデータを永続的に保持するために利用されるクラスタリソースの定義です。これは、オーケストレーションシステムにおける「ストレージの永続化」という極めて重要な課題を解決するために設計されました。具体的には、外部のストレージシステム（NFS、クラウドストレージなど）を抽象化し、Kubernetesクラスタ内で一貫して利用可能にするための設定そのものを指します。PVは、Kubernetesアーキテクチャの「ストレージ/ネットワーク」層において、コンテナの揮発性（データが消える性質）を克服し、ステートフルなアプリケーションの運用を可能にするための基盤を提供しています。

詳細解説

KubernetesアーキテクチャにおけるPVの役割

PersistentVolumeは、私たちが現在見ている「オーケストレーション（Kubernetes）」の文脈、特に「Kubernetesアーキテクチャ」の「ストレージ/ネットワーク」層において、中心的な役割を果たします。ご存知の通り、コンテナは基本的に一時的（エフェメラル）な性質を持っています。Podが停止したり再起動したりすると、内部のデータは消えてしまいます。しかし、データベースやユーザーアップロードファイルなど、消えては困るデータも当然存在しますよね。

PVの目的は、このコンテナの揮発性（すぐに消えてしまう性質）と、データ永続性の要求との間のギャップを埋めることです。

PVは、Kubernetesクラスタ全体で利用可能な物理的なストレージリソース（容量、アクセスモードなど）を管理者が定義したものです。これは、クラスタの管理者側が「ここに100GBのNFSストレージがありますよ」「これはReadWriteOnce（読み書き可能、ただし1つのPodのみ）で使えますよ」と宣言する設計図のようなものだと考えると分かりやすいです。PV自体は特定のPodに紐づくものではなく、クラスタリソースとして独立して存在・管理されます。

PVとPVC：抽象化の仕組み

PVを理解する上で欠かせないのが、PersistentVolumeClaim（PVC：パーシステントボリュームクレーム）の存在です。この組み合わせこそが、「ストレージ/ネットワーク」の抽象化を実現する鍵だと私は考えています。

PVは、ストレージの実体（リソース）を表しますが、Podが直接PVを参照することは推奨されていません。なぜなら、Podの利用者は、どのストレージ技術（NFSなのか、AWS EBSなのか、GCP Persistent Diskなのか）が裏側で動いているかを知る必要がないからです。

1. PV（リソースの提供側）: クラスタ管理者が定義する、利用可能なストレージの特性（容量、種類、アクセスモード）。
2. PVC（リソースの要求側）: Podの利用者が定義する、必要なストレージの要求仕様（「10GB欲しい」「読み書き可能モードで使いたい」）。

利用者がPVCを作成すると、Kubernetesは、その要求（PVC）を満たすPVを探し、自動的にバインド（結合）します。このバインディングが成立することで、Podは特定のストレージ技術に依存することなく、要求した容量とアクセスモードを持つ永続ストレージを確保できます。この仕組みは本当にエレガントで、利用者に優しい設計思想の素晴らしさを感じますね。

動的プロビジョニングとライフサイクル

PVのプロビジョニング（準備）には、主に静的と動的の二つの方法があります。

• 静的プロビジョニング: 管理者が事前にPVを作成しておき、ユーザーのPVCがそれを要求する方式です。
• 動的プロビジョニング: 必要なPVがクラスタ内に存在しない場合、PVCの要求に応じてKubernetesが自動的に外部のクラウドプロバイダ（AWS, Azure, GCPなど）に新しいストレージリソースを作成させる機能です。これにより、管理者は事前に大量のPVを用意しておく必要がなくなり、ストレージ管理が非常に効率的になります。

PVのライフサイクルも重要です。Podが削除されても、PVとPVCのバインディングは残ります。PVCが削除されたとき、PVのデータは設定に応じて「保持（Retain）」「削除（Delete）」「リサイクル（Recycle）」のいずれかのポリシーで処理されます。特にデータベースなど重要なデータの場合、誤って消えないように「保持」ポリシーを設定することが多いです。

具体例・活用シーン

PersistentVolumeが最も活躍するのは、データ永続性が必須となるアプリケーションのデプロイ時です。オーケストレーション環境でミッションクリティカルなシステムを構築する際には欠かせない要素です。

• データベースの運用: MySQLやPostgreSQLなどのステートフルなデータベースをコンテナで運用する場合、データディレクトリをPVにマウントすることで、Podがクラッシュしたり、ノードが移動したりしてもデータが失われることはありません。これは、Kubernetesを本番環境で使うための絶対条件であり、ストレージの信頼性を担保します。
• ログ、キャッシュ、コンテンツ管理: Webサーバーのアクセスログや、ユーザーがアップロードした画像ファイルなど、コンテナの再起動後も残しておきたいコンテンツを格納するのに利用されます。特に複数のPodから同時に読み書きが必要な（ReadWriteMany）ファイル共有のシーンでPVが活用されます。
• メッセージキューシステムの永続化: RabbitMQやKafkaなどのメッセージキューシステムにおいて、キューのデータを永続化し、システム全体の信頼性を向上させるために利用されます。

アナロジー：賃貸マンションの駐車場

初心者の方にとって、PVとPVCの関係は少し複雑に感じられるかもしれません。ここで、身近なアナロジーを使って、オーケストレーションにおけるストレージの仕組みを理解してみましょう。

Kubernetesクラスタを巨大な賃貸マンションだと想像してください。そして、Podはそこに住む「住民」です。

1. PersistentVolume (PV) は「駐車場の区画」そのものです。
   • 管理会社（クラスタ管理者）が「敷地内に10区画の駐車場がある（PV）」と定義します。これは、ストレージ/ネットワークの物理リソースの宣言です。
   • 各区画には「サイズ（10GB, 50GB）」や「使用条件（軽自動車専用、または誰でもOK）」といった物理的な仕様が設定されています。
2. PersistentVolumeClaim (PVC) は「駐車場利用の申請書」です。
   • 住民（Podの利用者）は、「車を停めたいから、最低でも10GBのスペースが必要だ」