--- title: "Kubernetes永続化ストレージ入門｜PV・PVC・StorageClassの設計と運用の落とし穴" url: "https://www.issoh.co.jp/tech/details/15294/" published: 2026-07-17 updated: 2026-09-27 categories: ["Kubernetes・コンテナ"] publisher: "株式会社一創" --- # 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を導入すべきかの全体判断は[コンテナオーケストレーションとは何かを整理した記事](https://www.issoh.co.jp/column/details/13003/)で扱っています。 ## コンテナの一時性と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とは何かを初心者向けに解説した記事](https://www.issoh.co.jp/tech/details/2928/)にまとまっているので、コンテナやPodの基礎を先に確認したい場合はそちらを参照してください。役割分担は下表のとおりです。 | オブジェクト | 誰が書くか | 担う責務 | | ------------ | --------------- | ---------- | | PV | 管理者かProvisioner | 実体の容量と接続情報 | | PVC | アプリ開発者 | 容量とアクセス要求 | | StorageClass | 基盤担当者 | 動的供給の方針定義 | ### 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が実体を作りバインドする 既存のオンプレ資産を割り当てる、あるいは特定ディスクへ確実に固定したい一部のケースだけ、静的を併用します。なお、外部ストレージを用意できないオンプレミス環境でノードの内蔵ディスクを動的供給の元にしたい場合は、[Longhornのような分散ブロックストレージ](https://www.issoh.co.jp/tech/details/17254/)をStorageClassの供給元に据える選択肢もあります。ファイル共有やS3互換のオブジェクトまで同じ基盤で賄いたい場合は、[Rook CephによるKubernetes上の分散ストレージ構成](https://www.issoh.co.jp/tech/details/17287/)が候補になります。 ### reclaimPolicyとvolumeBindingModeの設定判断 StorageClassには、消したPVCの後始末を決める`reclaimPolicy`と、PVを確保するタイミングを決める`volumeBindingMode`があります。前者は`Retain`なら実体を残し、`Delete`なら実体ごと消す設定です。後者を`WaitForFirstConsumer`にすると、Podが載るノードやアベイラビリティゾーンが決まってからボリュームを作るため、ゾーン不一致でPodが起動しない事故を避けられます。動的プロビジョニングの既定は`Delete`のことが多く、この既定のまま業務データを預けるのは危険です。 ## AWS（EKS）でのKubernetes永続化ストレージのCSI実装 AWS（EKSを含む）でステートフルアプリを動かすとき、どのCSIドライバを選ぶかで可用性とコストが変わります。ブロックとファイルの適用条件を分けて設計します。実基盤の構築や移行を外部に任せたい場合は[AWS・Google Cloud・Azureのインフラ構築支援](https://www.issoh.co.jp/service/system/aws/)で、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で同じファイル群を読み書きする配信基盤や共有アップロード領域に向きます。ブロックより遅延が大きいので、トランザクション性能を要するデータベースの主データ置き場には選びません。用途で棲み分けるのが実務の要点です。 | サービス | 種別 | 主なアクセスモード | 向く用途 | | ---- | ---- | ------------- | ---------- | | EBS | ブロック | ReadWriteOnce | 単一DBの主データ | | EFS | ファイル | ReadWriteMany | 複数Podの共有領域 | | FSx | ファイル | 用途依存 | 高性能な共有基盤 | ### 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のリソース定義とPVを一組で扱う形に寄せるなら、[VeleroのCSIスナップショットとData Moverの使い分け](https://www.issoh.co.jp/tech/details/17263/)が判断材料になります。 ### 永続化ストレージの自前運用を見送りマネージドに寄せるべき場面 永続化を自前で組むべきかは、条件で割り切ります。結論から言えば、小〜中規模でデータベースが一つか二つしか無いなら、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の意味から仕組みまで初心者向けに解説](https://www.issoh.co.jp/tech/details/2928/)：本記事の前提となるコンテナ・Podの基礎を確認できます。 - [コンテナオーケストレーションとは？Kubernetesの役割と自社に必要かの判断を解説](https://www.issoh.co.jp/column/details/13003/)：そもそもKubernetesを導入すべきかの全体判断はこちらで整理しています。 - [オブジェクトストレージとは？仕組みとS3互換API・ブロックとの違いを実装視点で解説](https://www.issoh.co.jp/tech/details/13369/)：PVで扱うブロック／ファイルと、オブジェクトストレージの違いを補足できます。 - [Kubernetes監視・モニタリングの設計｜メトリクス・ログ・アラート閾値の実装判断](https://www.issoh.co.jp/tech/details/15303/)：Prometheusの保存領域設計とも関わる監視基盤の構成を扱っています。 --- 出典: [Kubernetes永続化ストレージ入門｜PV・PVC・StorageClassの設計と運用の落とし穴]()（株式会社一創）