Volume

このページでは、Kubernetes の Volume の概要と、Google Kubernetes Engine(GKE)での使用について説明します。

概要

アプリケーションがデータを書き込む場合にはコンテナ内のディスク上のファイルを使用するのが最も簡単ですが、この方法には欠点があります。なんらかの理由でコンテナがクラッシュするか停止すると、ファイルは失われます。また、コンテナ内のファイルは同じポッドで実行されている他のコンテナにアクセスできません。このような問題は、どちらも Kubernetes Volume の抽象化により解決できます。

概念的には、Volume とは Pod 内のすべてのコンテナにアクセス可能なディレクトリです。Pod 仕様で宣言された Volume ソースでは、ディレクトリの作成方法、使用するストレージ メディア、初期状態のディレクトリの内容が決定されます。Pod 仕様では、どの Volume を Pod に含めるか、およびコンテナが Volume をマウントするパスが指定されます。

エフェメラル Volume タイプは、自身を含む Pod と同じライフサイクルを持つボリュームです。これらのボリュームはポッド作成時に作成され、コンテナを再起動しても保持されます。Pod が終了されるか削除されると、Volume も同時に終了されるか削除されます。

他の Volume タイプは、Pod とは独立して存在する永続ストレージへのインターフェースです。一時ボリュームとは異なり、永続ストレージを利用するボリューム内のデータは、ポッドが削除されても保持されます。ボリュームはマウントが解除されるだけで、データは別のポッドに引き継がれます。永続ストレージ タイプのライフサイクル管理は、直接指定するのではなく PersistentVolume リソースを使用して行います。

ボリューム タイプ

ストレージの実装と初期状態の内容は Volume によって異なるため、用途に合わせて最適な Volume ソースを選択できます。一般的な Volume ソースには、次のようなものがあります。

emptyDir

Pod 内のコンテナが読み書き可能な空のディレクトリを提供するエフェメラル Volume タイプ。なんらかの理由で Pod がノードから削除されると、emptyDir のデータは完全に削除されます。emptyDir Volume は、ノードをバックアップするメディアに保存されます。このメディアは、環境に応じてディスク、SSD、またはネットワーク ストレージになります。emptyDirs は、スクラッチ空間で使用する場合や Pod 内の複数のコンテナ間でデータを共有する場合に便利です。

Linux ノードプールでコンテナを使用している場合、emptyDir.medium フィールドを Memory に設定して、Kubernetes に tmpfs(RAM バックアップ ファイル システム)をマウントするよう指示できます。ただし、これは Windows Server コンテナでサポートされていません。

ConfigMap

ConfigMap リソースは、Pod に構成データを挿入する方法を提供します。ConfigMap オブジェクトに格納されたデータは、ConfigMap タイプの Volume で参照され、Pod で実行されているファイルを介して使用されます。ConfigMap Volume 内のファイルは ConfigMap リソースで指定されます。

Secret

アプリケーションがパスワード、OAuth トークン、SSH 認証鍵などの機密データを使用できるようにします。

downwardAPI

アプリケーションが Downward API のデータを使用できるようにします。このデータには、アプリケーションが実行されている Pod やコンテナに関する情報が含まれています。たとえば、Pod の Namespace と IP アドレスを含む DownwardAPIVolumeFile をアプリケーションから使用できるように Pod を構成できます。

PersistentVolumeClaim

クラスタ オペレータが、アプリケーションで使用する永続ストレージをプロビジョニングできます。Pod が永続ストレージを利用する Volume をマウントする場合には PersistentVolumeClaim を使用します。

Volume タイプの完全なリストは Kubernetes Volume のドキュメントをご覧ください。

次のステップ