📦 1枚の図で理解するKubernetesボリュームの構造と原理

—

こんにちは！今日は、Kubernetesで最も重要な概念の一つである「ボリューム(Volume)」についてお話したいと思います。

Kubernetesを初めて触る時、最も混乱する部分が「コンテナが死んだら、私のデータはどうなるの？」という点ではないでしょうか。上記の図を一つずつ分解しながら、Kubernetesがどのようにデータを安全に保管し、コンテナ間で共有するのかを完璧に整理してご説明します。🚀

基本的にコンテナは「揮発性(Ephemeral)」です。コンテナ内部でファイルを作成して保存しても、コンテナが再起動されたり削除されたりすると、その中のデータも煙のように消えてしまいます。

しかし、データベースやログファイルのように消えてはいけないデータもありますよね？また、一つのPod内にある複数のコンテナがデータを共有する必要がある場合もあります。この時に登場するのが、まさにボリューム(Volume)です。

上記の図は、大きくPod内部と外部ストレージに分かれます。一つずつ見ていきましょう。

図の最も内側を見ると、Podという大きな箱の中にコンテナ1とコンテナ2があります。

ファイルシステム: 各コンテナは、それぞれ独立したファイルシステムを持っています。
Mount (マウント): ところが、図を見ると両方のコンテナが/my-pathというパスを矢印で中央のvolumesの円筒に接続していますよね？これがまさにマウントです。
データ共有: このようにすると、コンテナ1が/my-pathにファイルを書き込むと、コンテナ2も/my-pathから同じファイルを読み取ることができます。一つの屋根の下に二つの家族が冷蔵庫を共有するようなものです！ 🏠

Podの中央にあるvolumesは、実際にどこに保存されるのでしょうか？図の右側にある3つのボックスがその答えです。

📁 emptyDir (一時ストレージ)
名前の通り、最初は「空っぽの(empty)」ディレクトリです。
Podが作成される時に作られ、Podが削除されると一緒に削除されます。
用途: 主にキャッシュデータや、コンテナ間で一時的にデータを交換する際に使用します。高速で手軽ですが、永続的な保存には向きません！
💻 hostPath (ノード直接接続)
図の最も大きな枠であるKubernetes Nodeのファイルシステムを直接使用します。
Podがノードの特定のパス(例: /var/log)を直接参照する方式です。
用途: 主にモニタリングツールやシステム関連のコンテナがノードの状態を読み取る必要がある場合に使用します。セキュリティ上の注意が必要です！ ⚠️
☁️ Network Storage (ネットワークストレージ)
これがデータ永続保存の核心です。
図で矢印がKubernetes Nodeの外に出て、ストレージサービスの永続ディスクに接続されているのが見えますか？
AWS EBS、Azure Disk、NFSのような外部ストレージを接続します。
利点: Podが死んだり、ノードが故障してPodが別のノードに移動しても、データは安全に外部ストレージに残っているため、そのまま再接続して使用できます。🛡️

図の流れを一句で要約すると以下のようになります。

「コンテナ内部の/my-pathにデータを保存すると ➡️ Pod内部のvolumeを経由して ➡️ 実際のストレージ(emptyDir、hostPath、または外部ディスク)に記録される。」

この構造のおかげで、開発者はコンテナが死んでも生きても心配することなく、データを安全に管理し活用できるのです。

Kubernetesボリュームは複雑に見えますが、「コンテナとストレージを繋ぐ橋」と考えると簡単です。

この3つだけ覚えておけば、Kubernetesストレージの半分は理解したことになります！次回の投稿では、実際の構成ファイル(YAML)の書き方について扱います。👋

Comments