Kubernetes永続化ストレージ入門｜PV・PVC・StorageClassの設計と運用の落とし穴

Kubernetesでデータベースやファイルを扱うと、Podの再作成でデータが消える問題に必ず突き当たります。これを防ぐ仕組みが、PersistentVolume（PV）・PersistentVolumeClaim（PVC）・StorageClassによる永続化です。本記事は、この三層モデルの役割分担、ReadWriteOnceなどアクセスモードの選定、静的／動的プロビジョニングの使い分け、そしてAWS上でのEBS・EFS・FSxを使った実装まで、ステートフルアプリを運用する担当者の目線で整理します。あわせて、データ消失を招く設定ミスと、自前運用を見送るべき損益分岐も条件付きで示します。

まとめ：PV・PVC・StorageClassの役割と選定の勘所

Kubernetesの永続化は、ストレージの実体（PV）・利用要求（PVC）・供給方針（StorageClass）を分離することで成り立ちます。開発者はPVCで「必要な容量とアクセスモード」を宣言するだけでよく、実体の調達はStorageClassとCSIドライバが引き受けます。この分離があるため、AWSでもオンプレでも同じマニフェストで永続化を記述できるのが強みです。

選定の勘所は三点です。第一に、単一Podからの読み書きならReadWriteOnceのブロックストレージ、複数Podで共有するならReadWriteMany対応のファイルストレージを選ぶこと。第二に、本番では静的PVを手作りせず、StorageClassによる動的プロビジョニングに寄せること。第三に、reclaimPolicyの既定値を理解し、消えては困るデータをDeleteのまま運用しないことです。Kubernetesを導入すべきかの全体判断はコンテナオーケストレーションとは何かを整理した記事で扱っています。

コンテナの一時性とKubernetes永続化ストレージの必要性

Kubernetesのストレージ設計は、コンテナが「使い捨て」である前提から出発します。まずこの前提と、PVが何を解決するのかを押さえます。

コンテナの一時性とemptyDir・hostPathの構造的限界

Podのコンテナが書き込んだデータは、コンテナ層に置かれるためPodの再作成で失われます。Pod内で共有できるemptyDirもPodの寿命と一致して消え、ノードのディスクを直接使うhostPathはPodが別ノードへ再スケジュールされた瞬間に元データへ到達できなくなります。つまりステートフルなアプリで求められるのは、Podのライフサイクルから独立したストレージです。

この「独立したストレージ」を、特定のクラウドやハードウェアに縛られない形で扱う抽象化がPersistentVolumeです。

PV・PVC・StorageClassの三層モデルとバインドの流れ

永続化は三つのオブジェクトで表現します。PVはストレージの実体、PVCはアプリ側からの要求、StorageClassは要求を満たすPVを自動で用意する方針です。開発者はPVCに容量とアクセスモードを書き、コントロールプレーンが条件に合うPVを探して結び付けます。この結合をバインドと呼び、一度バインドしたPVCとPVは一対一で固定されます。

Kubernetesそのものの仕組みはKubernetesとは何かを初心者向けに解説した記事にまとまっているので、コンテナやPodの基礎を先に確認したい場合はそちらを参照してください。役割分担は下表のとおりです。

CSIドライバへの移行とin-treeプラグイン廃止の現在地

ストレージ実体との接続は、以前はKubernetes本体に各クラウドのコードを同梱するin-tree方式でした。現在はContainer Storage Interface（CSI）という外部ドライバ規格に一本化が進み、AWSのブロックストレージ向けin-treeプラグインは1.27系で本体から除かれ、CSIドライバ経由へ移行済みです（2026年時点）。新規に構成するなら、各ストレージのCSIドライバをクラスタへ入れる前提で設計します。

PVCのアクセスモードと動的プロビジョニング方式の選定の基準

永続化の設計で最初に決めるのは、どのアクセスモードで、静的と動的のどちらで供給するかです。ここを誤ると本番で詰みます。

ReadWriteOnce・ReadOnlyMany・ReadWriteManyの選び方

アクセスモードはPVCが要求する共有の仕方です。ReadWriteOnceは単一ノードからの読み書き、ReadOnlyManyは複数ノードからの読み取り専用、ReadWriteManyは複数ノードからの同時読み書きを表します。ブロックストレージは基本的にReadWriteOnceまで、複数Podで同時に書き込むならNFS系のファイルストレージが要ります。厳密に一つのPodへ占有させたい場合の選択肢が、1.29系でGAしたReadWriteOncePodです。

判断はデータの共有要件で決まります。単一のデータベースならReadWriteOnce、複数のWeb配信Podで同じ画像群を読むならReadWriteManyを選びます。

静的プロビジョニングと動的プロビジョニングの実務的な使い分け

静的プロビジョニングは、管理者があらかじめPVを手作りしてPVCとバインドさせる方式です。動的プロビジョニングは、PVCがStorageClassを指定すると、Provisionerがその都度PVを自動生成する方式です。本番運用は動的を基本にします。台数やボリュームが増えるほど手作りは破綻し、命名や容量の取り違えがデータ事故につながるためです。

1. StorageClassを一度定義する
2. PVCでそのクラス名と容量を宣言する
3. Provisionerが実体を作りバインドする

既存のオンプレ資産を割り当てる、あるいは特定ディスクへ確実に固定したい一部のケースだけ、静的を併用します。

reclaimPolicyとvolumeBindingModeの設定判断

StorageClassには、消したPVCの後始末を決めるreclaimPolicyと、PVを確保するタイミングを決めるvolumeBindingModeがあります。前者はRetainなら実体を残し、Deleteなら実体ごと消す設定です。後者をWaitForFirstConsumerにすると、Podが載るノードやアベイラビリティゾーンが決まってからボリュームを作るため、ゾーン不一致でPodが起動しない事故を避けられます。動的プロビジョニングの既定はDeleteのことが多く、この既定のまま業務データを預けるのは危険です。

AWS（EKS）でのKubernetes永続化ストレージのCSI実装

AWS（EKSを含む）でステートフルアプリを動かすとき、どのCSIドライバを選ぶかで可用性とコストが変わります。ブロックとファイルの適用条件を分けて設計します。実基盤の構築や移行を外部に任せたい場合はAWS・Google Cloud・Azureのインフラ構築支援で、CSI選定からEKSの運用設計まで相談が可能です。

Amazon EBS CSIドライバの適用条件と単一AZの制約

Amazon EBSはブロックストレージで、CSIドライバはebs.csi.aws.comとして動きます。低遅延で単一Podのデータベースに向く一方、EBSボリュームは一つのアベイラビリティゾーンに固定されます。別ゾーンのノードへPodが移るとボリュームに到達できないため、StorageClassをWaitForFirstConsumerにし、Podの配置とゾーンを揃える設計が前提です。アクセスモードはReadWriteOnceが基本です。

Amazon EFS CSIドライバによる複数AZ共有の構成

Amazon EFSはNFS互換のファイルストレージで、CSIドライバはefs.csi.aws.comです。複数のアベイラビリティゾーンから同時にマウントでき、ReadWriteManyを満たすため、複数Podで同じファイル群を読み書きする配信基盤や共有アップロード領域に向きます。ブロックより遅延が大きいので、トランザクション性能を要するデータベースの主データ置き場には選びません。用途で棲み分けるのが実務の要点です。

StatefulSetのvolumeClaimTemplatesでDBを永続化する構成

データベースのように各Podが固有のデータを持つ構成では、DeploymentではなくStatefulSetを使い、volumeClaimTemplatesでPodごとにPVCを自動生成します。これにより、Podが再作成されても同じ名前のPVCへ再びバインドされ、そのPodのデータが保たれます。レプリカ番号とPVCが一対一で対応するため、スケール時もデータの取り違えが起きません。ステートフルなミドルウェアを載せる際の基本形です。

Kubernetes永続化ストレージ運用の落とし穴と採用可否判断

ここが本記事の独自の視点です。永続化は「動いた」で終わらず、消えない・戻せる状態を作って初めて運用に耐えます。加えて、そもそもKubernetesで自前運用すべきかも見極めます。

Kubernetes永続化でデータ消失を招く設定ミスと回避策

実運用で事故が集中するのは、次の三つの設定です。いずれも初期構築時の見落としが本番で顕在化します。

• reclaimPolicyがDeleteのまま業務データを預け、PVC削除で実体まで消す
• ゾーン固定のブロックボリュームを跨ぎ、Podが起動不能になる
• スナップショットもバックアップも無く、誤操作から戻せない

回避の基本は、消えては困るボリュームのStorageClassをRetainにし、ゾーン整合をWaitForFirstConsumerで担保し、後述のスナップショットを定期取得することです。

ボリューム拡張・スナップショット・定期バックアップの運用実務

容量不足に備え、StorageClassでallowVolumeExpansionを有効にしておくと、PVCの要求容量を増やすだけでオンライン拡張できます。世代管理には、1.20系でGAしたVolumeSnapshotを使い、CSIドライバ側の機能でボリュームの時点コピーを取得します。ただしスナップショットは同一基盤内の複製であり、リージョン障害や誤削除に完全には備えられません。業務データは、スナップショットに加えて別リージョンやオブジェクトストレージへの論理バックアップを併用します。

永続化ストレージの自前運用を見送りマネージドに寄せるべき場面

永続化を自前で組むべきかは、条件で割り切ります。結論から言えば、小〜中規模でデータベースが一つか二つしか無いなら、Kubernetes上で永続化を作り込むより、Amazon RDSなどのマネージドデータベースに寄せた方が総コストは下がります。バックアップ・フェイルオーバー・パッチ適用を基盤側が引き受けるため、CSIやスナップショットの運用負荷を抱えずに済むからです。一方、同種のステートフルワークロードを多数動かし、環境間の再現性やコスト効率を突き詰める段階に来たら、PVCによる宣言的な永続化が効いてきます。「まだデータベースが数個」の段階でKubernetesの永続化に踏み込むのは過剰であり、この場合は採用しないという判断を明確に置きます。

よくある質問

Kubernetesの永続化ストレージについて、実装前によく挙がる疑問に答えます。

PVとPVCの違いは何ですか？

PV（PersistentVolume）はストレージの実体を表すオブジェクトで、容量や接続情報を持ちます。PVC（PersistentVolumeClaim）はアプリ側からの要求で、必要な容量とアクセスモードを宣言するものです。開発者はPVCだけを書き、条件に合うPVがコントロールプレーンによって割り当てられます。実体と要求を分けることで、基盤の違いを隠したまま同じマニフェストを使い回せます。

StorageClassは必ず必要ですか？

静的プロビジョニングだけなら、管理者がPVを手作りするためStorageClassは必須ではありません。ただし本番で台数が増えると手作りは現実的でなく、動的プロビジョニングが前提になります。動的供給にはStorageClassが要るため、実運用ではほぼ必ず定義することになります。

ReadWriteManyはどのストレージで使えますか？

複数ノードから同時に読み書きするReadWriteManyは、NFS互換のファイルストレージで満たせます。AWSではEFSが代表例です。EBSのようなブロックストレージは基本的にReadWriteOnceまでで、複数Podの同時書き込みには向きません。共有要件があるかどうかで選ぶストレージが変わります。

PVCを削除するとデータは消えますか？

StorageClassのreclaimPolicy次第です。DeleteならPVCの削除に連動して実体まで消え、Retainなら実体は残ります。動的プロビジョニングの既定はDeleteのことが多いため、消えては困るデータはRetainを明示的に指定して運用します。

データベースはKubernetesで永続化すべきですか？

データベースが一つか二つの小〜中規模では、Amazon RDSなどのマネージドに寄せた方がバックアップやフェイルオーバーの運用負荷が下がり、総コストで有利になりがちです。同種のステートフルワークロードを多数動かし、環境の再現性を重視する段階になって初めて、PVCによる永続化の投資対効果が見合ってきます。

関連記事

• Kubernetes（クーベネティス）とは？読み方・K8sの意味から仕組みまで初心者向けに解説：本記事の前提となるコンテナ・Podの基礎を確認できます。
• コンテナオーケストレーションとは？Kubernetesの役割と自社に必要かの判断を解説：そもそもKubernetesを導入すべきかの全体判断はこちらで整理しています。
• オブジェクトストレージとは？仕組みとS3互換API・ブロックとの違いを実装視点で解説：PVで扱うブロック／ファイルと、オブジェクトストレージの違いを補足できます。