Kubernetes

PersistentVolume ぱーしすてんとぼりゅーむ

ストレージKubernetesPVCPodマウントクラウドストレージ

PersistentVolumeについて教えて

簡単に言うとこんな感じ！

Kubernetesでアプリが使えるストレージの「駐車スペース」みたいなものだよ！アプリ（Pod）は一時的に消えても、ここにデータを預けておけばちゃんと残り続けるんだ。コンテナが再起動されてもデータが消えない仕組みってこと！

PersistentVolumeとは

PersistentVolume（PV） とは、Kubernetesクラスター上でアプリケーションが利用できる永続的なストレージリソースのことです。通常、コンテナはその生存期間中だけデータを保持しますが、コンテナが停止・再起動・削除されるとデータも失われてしまいます。PVはその問題を解決するために設計された仕組みです。

PVはクラスター管理者（インフラ担当者）が事前に用意する「ストレージの器」であり、AWS EBS・Google Persistent Disk・NFS・Azure Diskといった実際のストレージインフラを抽象化して表現します。アプリ開発者はストレージの種類や設定を詳しく知らなくても、後述の PersistentVolumeClaim（PVC） を通じて安全にストレージを要求・利用できます。

ビジネス的な観点では、PVはデータベースのデータファイル・アップロードされたファイル・ログなど、「消えてはいけないデータ」を扱うすべてのシステムで必須の概念です。PVを正しく設計しないと、システム障害時にデータが丸ごと消えるリスクがあります。

PersistentVolumeの仕組みと構造

Kubernetesのストレージは「管理者が用意する側」と「アプリが使う側」を明確に分離しています。

登場人物	役割	担当者
PersistentVolume（PV）	ストレージリソースそのもの（駐車スペース）	クラスター管理者
PersistentVolumeClaim（PVC）	ストレージの利用申請（駐車券）	アプリ開発者
StorageClass	ストレージの種類・品質を定義（駐車場の等級）	クラスター管理者
Pod	実際にストレージを使うアプリ本体	アプリ開発者

PVのライフサイクル

PVには明確なライフサイクルがあり、状態（Phase）で管理されます。

Available（利用可能）
  ↓ PVCにバインド（割り当て）される
Bound（使用中）
  ↓ PVCが削除される
Released（解放済み・未クリーン）
  ↓ 再利用ポリシーに従って処理
Available または Deleted（終了）

アクセスモードの種類

アクセスモード	略称	説明	用途例
ReadWriteOnce	RWO	1つのNodeのみ読み書き可	DB、単一サーバー
ReadOnlyMany	ROX	複数Nodeから読み取りのみ可	共有設定ファイル
ReadWriteMany	RWX	複数Nodeから読み書き可	共有ファイルサーバー
ReadWriteOncePod	RWOP	1つのPodのみ読み書き可（v1.22以降）	排他制御が必要なDB

回収ポリシー（reclaimPolicy）

PVCが削除されたあと、PVをどう扱うかを決めるルールです。

ポリシー	動作	データ	用途
Retain	PVは残る（手動で回収）	保持される	本番DBなど重要データ
Delete	PVとストレージ両方削除	消える	開発・テスト環境
Recycle（非推奨）	データ消去後に再利用	消える	古い構成（現在非推奨）

歴史と背景

2014年 — Kubernetesプロジェクトがオープンソース化。当初はコンテナの「使い捨て」前提の設計で、永続ストレージの仕組みが不十分だった
2015年 — Kubernetes v1.0正式リリース。PersistentVolumeとPersistentVolumeClaimの概念が導入され、ステートフル（状態を持つ）アプリへの対応が始まる
2016年 — StorageClass が導入され、管理者が事前にPVを手動作成しなくても、PVCの要求に応じてストレージを自動作成できる「動的プロビジョニング」が実用化
2018年 — CSI（Container Storage Interface） が安定版に。AWS・Google・Azureなど各クラウドやストレージベンダーが統一インターフェースでドライバーを提供できるようになる
2020年 — CSIがデフォルト推奨となり、旧来のin-treeプラグイン（Kubernetes本体に組み込まれたストレージドライバー）から移行が進む
2022年〜 — ReadWriteOncePod（RWOP）アクセスモード追加など、より細かいアクセス制御が可能に

PV・PVC・StorageClassの関係と動的プロビジョニング

従来の「静的プロビジョニング」と、現在主流の「動的プロビジョニング」では、PVの作られ方が大きく異なります。

YAMLで見るPVとPVCの対応

# PersistentVolume（管理者が定義）
apiVersion: v1
kind: PersistentVolume
metadata:
  name: my-pv
spec:
  capacity:
    storage: 10Gi          # ストレージ容量
  accessModes:
    - ReadWriteOnce        # 1 Node から読み書き可
  reclaimPolicy: Retain    # PVC削除後もデータ保持
  storageClassName: ssd    # StorageClassの名前
  hostPath:
    path: /data/my-pv      # 実際のストレージパス（例）

---
# PersistentVolumeClaim（開発者が定義）
apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: my-pvc
spec:
  accessModes:
    - ReadWriteOnce
  resources:
    requests:
      storage: 10Gi        # 10GB を要求
  storageClassName: ssd    # 上のPVと一致 → 自動バインド

StatefulSetとの関係

StatefulSet（ステートフルセット）は、データベースのようにデータを持つアプリを管理するKubernetesのリソースです。StatefulSetは volumeClaimTemplates を使って、各Podに自動的にPVCを作成・割り当てる機能を持っています。MySQL・PostgreSQL・MongoDBなどのKubernetes上への展開では、StatefulSet + PVの組み合わせが定番です。