mhKubernetesを使っていて最初に戸惑うポイントの1つが「Podの中でデータが保存されない」という問題です。この章ではその理由と、それを解決するための Volume、PersistentVolume（PV）、PersistentVolumeClaim（PVC）の考え方を学びます。
❓ なぜVolumeが必要なのか？
Kubernetesでは、Pod内のコンテナが一時的にデータを保存できますが、そのライフサイクルは非常に短いです。
例えば：
- Podが再起動されたら → データは消える
- 新しいPodに置き換えられたら → データは引き継がれない
つまり、アプリケーションのログ、DBデータ、ファイルアップロードなどを残したい場合、何らかの外部ストレージが必要になります。
ここで登場するのが Kubernetes の Volume です。
📦 Volumeとは？
KubernetesにおけるVolumeは、コンテナにマウントできるファイルの保存領域です。以下のような種類があります：
| Volumeタイプ | 説明 |
|---|---|
emptyDir | Podが動いている間だけの一時領域 |
hostPath | Node上のディレクトリをマウントする |
configMap/secret | 設定や機密データをファイルとして提供 |
persistentVolumeClaim | 外部ストレージをPodに接続する（後述） |
emptyDirやhostPathは簡単に使えますが、Podが再スケジュールされたらデータは失われます。
💾 PersistentVolume（PV）とPersistentVolumeClaim（PVC）
本格的に永続化するには、**PersistentVolume（PV）とPersistentVolumeClaim（PVC）**という仕組みを使います。
用語の整理：
| 用語 | 役割 |
|---|---|
| PV (PersistentVolume) | 管理者があらかじめ用意しておく「物理的なストレージ」リソース（NFS, AWS EBSなど） |
| PVC (PersistentVolumeClaim) | ユーザーが「ストレージを使いたい！」と要求する宣言 |
| Pod | PVCを通してPVにアクセスする |
ざっくり言うと、PVは「空いてる倉庫」、PVCは「これくらいの広さの倉庫がほしい」、Podは「そこに荷物を置く」感じです。
🔧 使い方の流れ（例）
- 管理者が PersistentVolume を用意（静的プロビジョニング）
- ユーザーが PersistentVolumeClaim を作成
- Kubernetesが適合するPVを探してPVCとバインド
- PodがそのPVCをVolumeとしてマウント
🧪 シンプルな例（YAML）
# PersistentVolumeClaimの例
apiVersion: v1
kind: PersistentVolumeClaim
metadata:
name: my-pvc
spec:
accessModes:
- ReadWriteOnce
resources:
requests:
storage: 1Gi# PodがPVCを使う例
apiVersion: v1
kind: Pod
metadata:
name: app-pod
spec:
containers:
- name: app
image: nginx
volumeMounts:
- mountPath: "/usr/share/nginx/html"
name: my-storage
volumes:
- name: my-storage
persistentVolumeClaim:
claimName: my-pvc📌 動的プロビジョニングとは？
クラウド環境では、StorageClass を使えば、PVCを書くだけで PV を自動的に作成できます（これを動的プロビジョニングと呼びます）。非常に便利なので、実運用ではこのパターンが主流です。
📋 まとめ
- Podの中のデータは基本的に永続化されない
- 永続化したいなら Volume + PersistentVolume + PersistentVolumeClaim を使う
- PVC = 倉庫のリクエスト／PV = 実際のストレージ
- 動的プロビジョニングを使えば、PVを自動で用意してくれる
