こんにちは。クラウドインフラの深淵へようこそ。
Kubernetes（k8s）の世界に足を踏み入れたばかりの皆さんは、おそらく「Podは使い捨てである」という教えを最初に受けたはずです。しかし、現場でシステムを動かすとなれば、必ず「消えては困るデータ」に直面します。データベースのレコード、ユーザーのアップロード画像、ログファイル……。
「Podが死んだらデータも消えるのか？」
この恐怖を克服し、コンテナに「永遠の記憶」を与える仕組みこそが、今回解説するPersistentVolume (PV) と PersistentVolumeClaim (PVC) です。
これをマスターすれば、あなたのインフラ構成管理は「ただのコンテナ実行環境」から「堅牢なプラットフォーム」へと進化します。私と一緒に、その本質を紐解いていきましょう。
—
1. コンテナの「宿命」とストレージの課題
Kubernetesの設計思想の根幹は「不変（Immutable）」と「エフェメラル（儚さ）」です。
Podはいつでも再起動され、別のノードへ移動します。標準的なコンテナ内のストレージは、Podが消えれば一緒に消滅します。これを「ステートレス（状態を持たない）」と呼びます。
しかし、現実は非情です。
- DBのデータが消えたら？ → 倒産です。
- ログが消えたら？ → 障害調査ができません。
そこで必要になるのが、「Podの寿命」と「データの寿命」を切り離す設計です。これを実現するのがKubernetesのストレージオーケストレーションです。
—
2. 三位一体の仕組み：PV, PVC, StorageClass の関係性
k8sのストレージを理解する最大のコツは、「役割の分離」を知ることです。
初心者の方が最も混乱する「PV」「PVC」「StorageClass」の関係を、レストランの予約に例えて図解します。
1. StorageClass（メニュー表）
- 「どんな種類のストレージがあるか」を定義します（例：高速なSSD、安価なHDD、クラウドのマネージドディスクなど）。
2. PersistentVolumeClaim (PVC)（注文書）
- 開発者が「5GBのSSDをください！」とリクエストするチケットです。
3. PersistentVolume (PV)（実体としての席）
- 実際に確保されたストレージの「実体」です。
なぜこんなに複雑なの？
それは、「開発者がインフラの詳細（どのAWS EBSを使うか、どのNFSを使うか等）を知らなくてもいいようにするため」です。
- 管理者の仕事： ストレージの裏側（StorageClass）を整える。
- 開発者の仕事： 「これくらいの容量が欲しい」という願い（PVC）を書くだけ。
この抽象化こそが、マルチクラウドやハイブリッドクラウドで「どこでも動くコード」を書くための極意です。
—
3. 【実践】動的プロビジョニングでストレージを自動生成する
昔は管理者が手動でPV（実体）を作っていましたが、現代のSREはそんな退屈なことはしません。「動的プロビジョニング」を使い、PVCが発行された瞬間にストレージを自動生成させます。
まずは、もっとも標準的な「Hello World」的な構成を見てみましょう。
ステップ1：StorageClass の確認
（多くのマネージド環境（EKS, GKE, Azure）ではデフォルトで用意されています）
デフォルトのストレージクラスを確認するコマンド
kubectl get storageclass
ステップ2：PVC（注文書）を作成する
開発者になったつもりで、ストレージを要求してみましょう。
apiVersion: v1
kind: PersistentVolumeClaim
metadata:
name: my-pvc
spec:
accessModes:
- ReadWriteOnce # 1つのノードから読み書き可能
resources:
requests:
storage: 1Gi # 1GBだけ欲しい！
storageClassName: standard # StorageClassの名前を指定
ステップ3：Podにマウントする
作成したPVCを、Podの特定のディレクトリに「合体」させます。
apiVersion: v1
kind: Pod
metadata:
name: storage-test-pod
spec:
containers:
- name: app-container
image: nginx
volumeMounts:
- mountPath: “/usr/share/nginx/html” # コンテナ内のこのパスを永続化
name: my-volume
volumes:
- name: my-volume
persistentVolumeClaim:
claimName: my-pvc # さっき作ったPVCの名前を指定
このPodをデプロイすると、Kubernetesは裏側でクラウドのディスクを切り出し、Podが起動するノードにアタッチし、コンテナの指定パスにマウントする……という複雑な作業を全自動で完結させます。これぞIaCの真髄です。
—
4. ステートフルアプリ（DB等）への応用：その先へ
ここまでは単体のPodの話でしたが、実際の現場ではMySQLやPostgreSQLといったデータベースを動かします。ここで登場するのが StatefulSet です。
通常のDeploymentと違い、StatefulSetは「0番目のPodにはこのディスク」「1番目のPodにはあのディスク」という風に、Podのアイデンティティとデータを紐付けて管理してくれます。
StatefulSetの一部（イメージ）
volumeClaimTemplates: # Podごとに個別のPVCを自動生成する魔法のテンプレート
- metadata:
name: data
spec:
accessModes: [ “ReadWriteOnce” ]
storageClassName: “premium-rwo”
resources:
requests:
storage: 10Gi
「データベースをコンテナで動かすのは怖い」と言われていた時代は終わりました。PV/PVCの仕組みを正しく理解し、冪等性を担保したコードを書けば、データベースの運用すらも自動化の恩恵に預かることができるのです。
—
最後に：エンジニアとしての視座
インフラ構成管理における「永続化」は、単なる技術的な設定ではありません。それは「変化し続けるコンテナの世界」において「変わらない価値（データ）」をどう守り抜くかという設計思想そのものです。
今日、あなたが書いた1つのPVC YAMLファイルは、将来の誰かが行う深夜の障害復旧を不要にするかもしれません。Podが何度死んでも、データがそこにあり続ける。その安心感こそが、我々SREが提供する最高の価値です。
まずは手元の環境（MinikubeやKind、クラウドのフリートライアル）で、Podを削除してもデータが残っている感動を味わってみてください。そこからあなたの伝説が始まります。
応援していますよ。頑張ってくださいね。