このページでは、Kubernetes のボリュームの概要と、Google Kubernetes Engine（GKE）での使用について説明します。
概要
アプリケーションがデータを書き込む場合にはコンテナ内のディスク上のファイルを使用するのが最も簡単ですが、この方法には欠点があります。なんらかの理由でコンテナがクラッシュするか停止すると、ファイルは失われます。また、コンテナ内のファイルは同じ Pod で実行されている他のコンテナにアクセスできません。これらの問題は、どちらも Kubernetes Volume の抽象化により解決できます。
概念的には、ボリュームとは Pod 内のすべてのコンテナにアクセス可能なディレクトリです。Pod 仕様で宣言されたボリューム ソースでは、ディレクトリの作成方法、使用するストレージ メディア、初期状態のディレクトリの内容が決定されます。Pod 仕様では、どのボリュームを Pod に含めるか、およびコンテナがボリュームをマウントするパスが指定されます。
一時ボリューム タイプは、自身を含む Pod と同じライフサイクルを持つボリュームです。これらのボリュームは Pod 作成時に作成され、コンテナを再起動しても保持されます。Pod が終了されるか削除されると、ボリュームも同時に終了されるか削除されます。
他のボリューム タイプは、Pod とは独立して存在する永続ストレージへのインターフェースです。一時ボリュームとは異なり、永続ストレージを利用するボリューム内のデータは、Pod が削除されても保持されます。ボリュームはマウントが解除されるだけで、データは別の Pod に引き継がれます。永続ストレージ タイプのライフサイクル管理は、直接指定するのではなく PersistentVolume リソースを使用して行います。
ボリューム タイプ
ストレージの実装と初期状態の内容はボリュームによって異なるため、用途に合わせて最適なボリューム ソースを選択できます。一般的なボリューム ソースには、次のようなものがあります。
- emptyDir
- Pod 内のコンテナが読み書き可能な空のディレクトリを提供する一時ボリューム タイプ。なんらかの理由で Pod がノードから削除されると、emptyDir のデータは完全に削除されます。emptyDirs は、スクラッチ空間で使用する場合や Pod 内の複数のコンテナ間でデータを共有する場合に便利です。
Linux ノードプールでコンテナを使用している場合、emptyDir.medium フィールドを Memory に設定して、Kubernetes に tmpfs（RAM バックアップ ファイル システム）をマウントするよう指示できます。ただし、これは Windows Server コンテナでサポートされていません。
- configMap アプリケーションが構成データにアクセスできるようにします。
- configMap ボリューム内のファイルは ConfigMap リソースで指定されます。
- Secret
- アプリケーションがパスワード、OAuth トークン、SSH 認証鍵などの機密データを使用できるようにします。
- downwardAPI
- アプリケーションが Downward API のデータを使用できるようにします。このデータには、アプリケーションが実行されている Pod やコンテナに関する情報が含まれています。たとえば、Pod の名前空間と IP アドレスを含む DownwardAPIVolumeFile をアプリケーションから使用できるように Pod を構成できます。
- persistentVolumeClaim
- クラスタ オペレータが、アプリケーションで使用する永続ストレージをプロビジョニングできます。Pod が永続ストレージを利用するボリュームをマウントする場合には PersistentVolumeClaim を使用します。
ボリューム タイプの完全なリストは Kubernetes ボリュームのドキュメントをご覧ください。