1. 導入：なぜPV/PVCによる抽象化が必要なのか
Kubernetesでステートフルなアプリケーションを運用する際、最も頭を悩ませるのが「ストレージの永続化」です。コンテナは本質的にエフェメラル（一時的）であり、Podが削除されると内部のデータも消滅します。従来、物理ストレージとアプリが密結合していると、クラウド移行や環境変更のたびにマニフェストを全書き換えする必要がありました。PV/PVCの仕組みを導入することで、インフラ層（ストレージの実体）とアプリケーション層（ストレージの要求）を分離し、環境に依存しない柔軟なデプロイメントが可能になります。
2. 基礎知識：PVとPVC、StorageClassの役割
この仕組みを理解するには、以下の3つのコンポーネントを覚える必要があります。
PersistentVolume (PV): クラスター内のストレージリソース。管理者がプロビジョニングした、あるいは動的に作成された物理ストレージの実体です。
PersistentVolumeClaim (PVC): アプリケーション側からの「ストレージを使いたい」という要求。容量やアクセスモードを指定します。
StorageClass: ストレージの「種類」を定義するテンプレート。これを指定することで、管理者が事前にPVを作成しなくても、PVCの要求に応じて自動的にストレージを割り当てる（動的プロビジョニング）ことが可能になります。
3. 実装/解決策：動的プロビジョニングの活用
実務では、毎回手動でPVを作成するのは非効率です。StorageClassを作成し、PVCがそれを参照するように設計するのが標準的です。これにより、開発者は「どのディスクを使っているか」を気にせず、PVCを作成するだけで永続領域を確保できます。
4. サンプルプログラム：PVCの定義とPodへのマウント
以下は、AWS EBSやGCP Persistent Diskなどの標準的なクラウド環境を想定した、動的プロビジョニング用のマニフェスト例です。
apiVersion: v1
kind: PersistentVolumeClaim
metadata:
name: my-app-pvc
spec:
accessModes:
- ReadWriteOnce # 単一ノードからの読み書きを許可
resources:
requests:
storage: 10Gi # 10GBの領域を要求
storageClassName: standard # 使用するStorageClassを指定
—
apiVersion: v1
kind: Pod
metadata:
name: my-app-pod
spec:
containers:
- name: my-app-container
image: nginx
volumeMounts:
- mountPath: “/usr/share/nginx/html” # コンテナ内のマウント先
name: storage-volume
volumes:
- name: storage-volume
persistentVolumeClaim:
claimName: my-app-pvc # 先ほど作成したPVCを指定
5. 応用・注意点：現場で陥りやすいトラブル
実務で運用する際、以下のポイントに注意してください。
1. Reclaim Policyの確認: PVの再利用ポリシー（Retain/Delete）を確認してください。Deleteに設定されていると、PVCを削除した瞬間に実ストレージ（クラウド上のディスク）まで削除されることがあります。本番環境では誤削除を防ぐためにRetainを選択することが多いです。
2. アクセスモードの制約: ReadWriteOnce（単一ノードのみ）が標準ですが、複数ノードからの同時書き込みが必要な場合は、ReadWriteManyに対応したストレージ（NFSやEFSなど）とStorageClassが必要です。
3. ゾーンの制約: クラウド環境において、PVは特定のゾーン（Availability Zone）に紐付くことが多いです。PodがPVと異なるゾーンにスケジューリングされるとマウントエラーになるため、NodeAffinityやゾーン意識の設定が必要です。
この抽象化層を適切に設計することで、インフラの変更に強い、ポータブルなアプリケーション基盤を構築しましょう。
コメント