本記事は、非エンジニアである筆者がKubernetesを学習する中でのアウトプット（備忘録）です。
なお、記事の執筆にあたり生成AIも活用し調査のうえ記載していますが、万が一誤りがあればご指摘いただけると幸いです。
前回は、Podという「住所不定の屋台」を管理する強力な助っ人、「ReplicaSet（現場監督）」と「Deployment（総司令官）」について学びました。
※前回の記事：【備忘】非エンジニアによるKubernetes学習アウトプット④（ReplicaSetとDeploymentについて）
おかげで、屋台（Pod）が潰れても自動で復活し、新しいメニュー（バージョン）への切り替えもスムーズに行えるようになりました。
これで完璧…と思いきや、まだ重大な問題が残されていたのです。
「屋台が火事で全焼したとき、金庫に入れておいた売上金や、大事な予約台帳はどうなるの？」
今回は、Kubernetesにおけるデータの保存場所、ストレージについて学びます。
1. Podは「使い捨て」のレンタルキッチン
これまで学んできた通り、Podは非常に儚い存在です。Deployment（総司令官）の指示一つで簡単に作られたり、壊されたりします。
これは、Podが「一日契約のレンタルキッチン」のようなものだからです。
レンタルキッチンでは、借りている間は自由に料理道具や材料を持ち込めますが、契約時間が終われば、全て片付けて空っぽの状態で返却しなければなりません。
次に借りる人は、また何もない綺麗な状態からスタートします。
Kubernetesの世界でも同じです。
Podが何らかの理由で停止・削除されると、そのPodの中に保存されていたデータは全て綺麗さっぱり消えてしまいます。
Webサイトの表示用データのような、どこからでも持ってこれるデータなら問題ありません。
しかし、以下のようなデータが消えては困ります。
- データベースのデータ: 顧客情報、商品情報、売上データなど
- ユーザーがアップロードしたファイル: プロフィール画像、ドキュメントなど
- アプリケーションのログ: エラーの原因を特定するための記録
これらを「レンタルキッチン（Pod）」の中に置きっぱなしにするのは、あまりにも危険です。
2. 解決策：外部の「貸し倉庫」を使おう
大切なデータを守るためには、Podの中ではなく、Podの外にある安全な場所にデータを保存する必要があります。
イメージとしては、レンタルキッチンの隣にある、頑丈な「専用の貸し倉庫」を契約するようなものです。
屋台（Pod）が営業中は、この貸し倉庫から材料を出したり、売上金をしまったりします。もし屋台が火事で全焼して新しい屋台に変わっても、貸し倉庫の契約はそのまま残るので、中のデータは無事というわけです。
Kubernetesでは、この「貸し倉庫」の仕組みを実現するために、2つの重要な要素が登場します。
① PersistentVolume (PV)：【物理的な貸し倉庫】
PersistentVolume（パーシステント・ボリューム、略してPV）は、実際のデータ保存場所そのものです。
「10GBのSSD倉庫」「100GBのHDD倉庫」「クラウド上の巨大倉庫」など、インフラ管理者が事前に用意してくれる、物理的なストレージ領域です。
② PersistentVolumeClaim (PVC)：【倉庫の利用申請書】
PersistentVolumeClaim（パーシステント・ボリューム・クレイム、略してPVC）は、屋台（Pod）の店主が出す「倉庫を使いたい！」という利用申請書です。
「データベース用に、そこそこ速くて10GBくらいの倉庫を貸してください！」といった要望をここに書きます。
※参考情報
【Kubernetes】PersistentVolume/PersistentVolumeClaim is 何
3. 図解：「申請書」と「倉庫」が繋がるまで
このPVとPVCがどのように連携してデータが守られるのか、図を見ながらイメージを固めましょう。
【利用の流れ】
- 準備（インフラ管理者）: 管理者が、様々なサイズや種類の「貸し倉庫（PV）」をいくつか用意しておきます。
- 申請（アプリ開発者）: 「屋台（Pod）」の設計図の中に、「利用申請書（PVC）」を含めます。「10GBの倉庫が必要！」と要望を出します。
- 仲介と紐付け（Kubernetes）: Kubernetesが仲介役となり、提出された申請書（PVC）の条件に合う空き倉庫（PV）を探し出し、両者をがっちりと紐付けます（これを「バインド」と呼びます）。
- 利用開始: 屋台（Pod）は、紐付けられた倉庫（PV）を、まるで自分のお店の一部であるかのように自由に使えるようになります。
※Pod（屋台）がPVC（利用申請書）を出すと、Kubernetesが適切なPV（貸し倉庫）と紐付けてくれるイメージ
この仕組みのおかげで、たとえ屋台（Pod）が新しくなっても、「同じ申請書（PVC）」を持っている限り、Kubernetesが「あ、君はあの倉庫の契約者だね」と判断し、自動的に同じ倉庫（PV）に繋ぎ直してくれます。これでデータは安泰です。
まとめ
- Podは使い捨ての「レンタルキッチン」。中身は消えてしまうので、大切なデータの保存には向かない。
- データを永続的に保存するには、外部の「貸し倉庫」が必要。
- PersistentVolume (PV) は、インフラ管理者が用意する「物理的な貸し倉庫」そのもの。
- PersistentVolumeClaim (PVC) は、アプリ開発者（Pod）が出す倉庫の「利用申請書」。
- Kubernetesが「申請書（PVC）」と「倉庫（PV）」を紐付けることで、Podが作り直されてもデータは守られる。
次回は、ネットワーキングについて学びます。