5種類のKubernetesボリュームとその操作方法
: Kubernetes のボリュームとは何ですか？
このページを共有
Yifat Perry
Kubernetesボリュームとは
Kubernetesボリュームは、Kubernetesポッド内のコンテナからアクセスできるデータを含むディレクトリです。ディレクトリの場所、ディレクトリをサポートするストレージ メディア、およびその内容は、使用するボリュームのタイプによって異なります。
ポッド内のコンテナ内で実行されているプロセスには、以下で構成されるファイルシステムビューが表示されます：
- コンテナ イメージのコンテンツと一致するルート ファイル システム。
- コンテナにマウントされているボリューム（定義されている場合）。各ボリュームは、コンテナ ファイルシステム内の特定のパスにマウントされます。
ボリュームは、ポッド テンプレートの .spec.containers[*].volumeMounts フィールドで定義されます。ポッドごと、およびポッド内の各コンテナ イメージについて、マウントするボリュームとそのパス（パスはコンテナごとに異なる場合があります）を指定する必要があります。
Kubernetesにはいくつかの種類のボリュームがあります。最も重要なのは、Kubernetesノード上にローカルに格納され、Podが再起動すると削除されるエフェメラル ボリュームと、Podがシャットダウンしたあともデータを保持するKubernetes Persistent Volume （PV）です。
この記事の内容：
- Kubernetesボリュームのタイプ
- 永続的ボリューム
- エフェメラル ボリューム
- EmptyDir ボリューム
- Kubernetes hostPath ボリューム
- Kubernetes ボリューム ConfigMap
- Kubernetes ボリュームを格納するためのプラグイン
- NFS
- CSI
- Kubernetes volumeMountsとは？
- ポッドのデプロイによる Kubernetes ボリュームの作成
- NetApp Cloud Volumes ONTAPを使用したKubernetesボリュームの管理
5種類のKubernetesボリューム
Kubernetesはさまざまなボリュームをサポートしているため、各ポッドが複数のボリューム タイプを同時に使用できます。エフェメラル ボリュームはポッドの存続期間に縛られますが、永続的ボリュームはポッドの存続期間を超えて保持できます。つまり、Kubernetesはポッドが存在しなくなるとエフェメラル ボリュームを破棄し、永続的ボリュームのデータを保持します。
永続的ボリューム
Kubernetesは、ストレージ プロビジョニングと消費を抽象化するAPIを備えたPersistentVolumeサブシステムを提供します。PersistentVolume（PV）とPersistentVolumeClaim（PVC）という2つのAPIリソースと連携します。
PersistentVolume (PV)
PVは、クラスタ内に配置されるストレージ リソースです。管理者は手動でPVをプロビジョニングでき、Kubernetesはストレージ クラスを使用してPVを動的にプロビジョニングできます。PVもボリュームと同じくプラグインですが、そのライフサイクルはPVを使用するPodから独立しています。
PVは、iSCSI、NFS、クラウド プロバイダ ストレージ システムなど、ストレージ実装の詳細を取得するAPIオブジェクトとして機能します。ノードと同様の働きをしますが、コンピューティングではなくストレージ リソースを提供します。
PersistentVolumeClaim (PVC)
PVC は、ユーザーによって行われたストレージ要求です。ポッドと同じように機能しますが、ノード リソースではなく PV リソースを消費します。PVC は、ReadWriteOnce、ReadWriteMany、ReadOnlyMany などのサイズ アクセス モードを指定して、特定のストレージ リソースを要求できます。
PVCを使用すると、ユーザは抽象的なストレージ リソースを利用できますが、ユーザは通常、さまざまな問題に対してさまざまなプロパティを持つPVを必要とします。このため、クラスタ管理者は、多くの場合、サイズやアクセス モード以外の点でも異なるさまざまなPVを提供する必要があります。これは、StorageClassリソースを通じてユーザに実装の詳細を公開することなく行うことができます。
関連コンテンツ：Kubernetes PVCのガイドをお読みください
エフェメラル ボリューム
エフェメラル ボリュームでは、再起動後もデータは永続的に格納されません。これらのボリュームはPodの存続期間にバインドされており、Podと一緒に作成および削除されます。永続的ボリュームの可用性に制限されることなく、Podの停止と再起動が可能になります。
エフェメラル ボリュームは、導入や管理が簡単です。ポッド仕様でインラインで指定できます。エフェメラル ボリュームは、キャッシュ サービスなど、永続的なストレージを必要としないアプリケーションに最適です。
EmptyDir ボリューム
emptyDir ボリュームは、Kubernetes が Pod をノードに割り当てると作成されます。このボリュームのライフサイクルは、その特定のノードに存在する Pod のライフサイクルに関連付けられています。コンテナが再起動またはクラッシュしたときに emptyDir ボリュームが再作成されます。ただし、Pod がノードから削除されたとき、クラッシュしたとき、または停止したとき、このボリューム内のデータは削除され、失われます。
emptyDir ボリュームを作成したら、ボリューム タイプ名をポッド マニフェスト ファイルのフィールドとして宣言できます。ボリューム プロパティ セクションの下に、値として空の中括弧{}が表示されます。EmptyDir ボリュームは主に一時的なデータ ストレージに適しています。たとえば、ディスクベースのマージなどのスクラッチ領域に使用できます。
emptyDirボリュームは、ノードをバックアップするメディアに格納できます。たとえば、ネットワーク ストレージやSSDを使用できます。または、emptyDir.mediumフィールドに「memory」を設定すると、KubernetesがRAMベースのファイルシステム（tmpfs）をマウントします。Kubernetesはノードのリブート時にtmpfsをクリアすることに注意してください。
Kubernetes hostPath ボリューム
hostPath ボリュームは、ホスト ノードのファイルシステムからポッドにディレクトリまたはファイルをマウントします。
hostPath ボリュームの主なユースケースは次のとおりです：
- /var/lib/dockerhostPath—を使用して、Docker 内部へのアクセスを必要とするコンテナを実行します。
- /sys hostPath—を使用して、コンテナーで cAdvisor を実行します。
- ポッドが hostPath を指定できるようにするポッドの実行を開始する前に特定の hostPath が存在するかどうか、および作成する必要があるかどうかを定義します。
- hostPath ボリュームのタイプを指定—必須のパス プロパティに加えて、このタイプを設定できます。
HostPathボリュームのセキュリティ
HostPathボリュームは、多くのセキュリティ リスクをもたらします。これらの使用は可能な限り避けてください。HostPathボリュームを使用する必要がある場合は、必要なディレクトリまたはファイルだけを対象にスコープを設定し、ReadOnlyとしてマウントしてください。
主なセキュリティリスクは次のとおりです：
- 公開されている資格情報—HostPathsは特権システム資格情報または特権APIを公開できます。脅威アクターは、これを使用して、クラスターの他の部分を攻撃したり、コンテナエスケープを実行したりできます。
- ルート権限—基盤となるホスト上に作成されたディレクトリやファイルは、root のみが書き込み可能です。hostPath ボリュームに書き込む場合は、ホストのファイル権限を変更するか、特権コンテナ内で root としてプロセスを実行する必要があります。
AdmissionPolicyを使用して、特定のディレクトリへのHostPathアクセスを制限できます。ただし、このポリシーは、volumeMountsがreadOnlyマウントを使用する必要がある場合にのみ有効です。
Kubernetes ボリューム ConfigMap
ConfigMapにより、構成データをポッドに挿入できます。ConfigMap内に格納されたデータは、configMapボリューム タイプで参照し、ポッドで実行されるコンテナ化されたアプリケーションによって利用することができます。ConfigMapを参照する場合は、ボリューム内のConfigMapの名前を指定する必要があります。Kubernetesでは、ConfigMap内の特定のエントリのパスをカスタマイズできます。
Kubernetes ボリュームを格納するためのプラグイン
Kubernetesには、Kubernetesクラスタに導入されたストレージ デバイスへのアクセスを提供するストレージ プラグインが複数用意されています。これらは、StorageClassオブジェクトを使用して実装されます。
Kubernetesで現在サポートされている主なプラグインには、GCEPersistentDisk、AWSElasticBlockStore、AzureDisk、Glusterfs、NFS、iSCSIなどがあります。これらのプラグインの詳細については、StorageClassのドキュメントを参照してください。
2 つの注目すべきストレージ プラグインを詳しく見てみましょう。
NFS
Network File System（NFS）は、ストレージ デバイスをローカル ドライブとしてマウントするための標準プロトコルです。Kubernetesでは、NFSボリュームをローカル ドライブとしてコンテナにマウントできます。レガシー コードはNFS経由でデータにアクセスすることが多いため、このプラグインはレガシー ワークロードをKubernetesに移行する場合に非常に役立ちます。
NFSとKubernetesを経由してデータにアクセスする方法は2つあります：
- エフェメラルNFSボリューム既存のNFSストレージに接続できます。
- PersistentVolumes と NFS:NFS 経由でアクセスするクラスタに管理対象リソースをセットアップできます。
CSI
コンテナ ストレージ インターフェイス（CSI）は、コンテナ オーケストレーション ツールが管理するコンテナにストレージ システムを公開するための標準インターフェイスです。CSIでは、ストレージ ベンダーがプラグインを「アウト オブ ツリー」、つまりKubernetesコード リポジトリにチェックインする必要がなく、Kubernetesに付属していないプラグインを作成できます。
CSI をベースとした Out-of-Tree プラグインは数多く存在し、ストレージ ベンダーが直接提供しています。CSI の登場により、ストレージ テクノロジによる Kubernetes のサポートが格段に容易になりました。
関連コンテンツ：Container Storage Interfaceのガイドを読む
Kubernetes volumeMountsとは
ボリュームを作成してポッドからアクセス可能にするには、次の2つの手順が必要です。
- ポッド テンプレートの spec：volumes プロパティで宣言し、ポッドをいくつかのノードにデプロイします
- spec:containers::volumeMounts プロパティを使用してボリュームを特定のコンテナにマウントする
これらのステップは密接に関連しています。ボリュームを作成するときは、コンテナにもマウントする必要があり、ポッド テンプレートで宣言せずにボリュームをマウントすることはできません。
以下は、ポッド テンプレートの YAML 構成でのボリュームの作成とマウントの両方を示す例です：
spec： containers： —name：my-app image：nginx volumeMounts： —name：my-volume mountPath：/app/config volumes： —name：my-volume
このコードでは：
- volumes（下部）は、my-volume という名前のボリュームを作成し、ポッドに接続します
- volumeMounts は、コンテナ内からボリュームを使用できるようにするファイル パスを含む、ボリュームのマウント方法を定義します
- ボリューム宣言と volumeMounts プロパティの両方で同じボリューム名を使用することが不可欠です。
ポッドのデプロイによる Kubernetes ボリュームの作成
Kubernetes ボリュームを作成するには、ボリュームを宣言する 1 つ以上のポッドをデプロイします。これを行う一般的な方法は、Deployment オブジェクトを使用することです。次の処理を行う Deployment マニフェストの例を次に示します：
- 3つのポッドを導入し、それぞれに1つのNGINXコンテナを配置します
- emptyDir ボリュームを宣言します
- ルートの 3 つのコンテナのそれぞれにボリュームをマウントします
apiVersion：apps/v1 kind：Deployment metadata： name：pods-with-volumes spec： replicas：3 selector： matchLabels： app：demo template： metadata： labels： app：demo spec： containers： —name：my-container image：nginx:1.14.2 volumeMounts： —mountPath：/ name：my-volume volumes： —name：my-volume emptyDir：{}
この Deployment の名前は pods-with-volumes で定義されています。これは、Kubernetes 環境でこの Deployment を参照する方法です。
前のセクションで説明したように、この Deployment オブジェクトはボリュームの作成に必要な 2 つのアクションを実行します：
- spec：template：volumes プロパティはボリュームを宣言します。
- spec:containers::volumeMounts プロパティは、ボリュームをコンテナにマウントします。
この YAML ファイルが my-deployment.yaml という名前で保存されているとします。次のコマンドを使用して、Kubernetes クラスタに Deployment を作成できます：
kubectl apply -f my-deployment.yaml
Deployment が想定されるボリュームで正しく実行されていることを確認するには、次のコマンドを実行します：
kubectl describe pods pods-with-volumes
すべてが正常に機能した場合、出力には、各ポッドに要求されたマウント ポイントを持つ my-container という名前のコンテナがあることが示されます：
マウント： / from my-volume (rw)
出力には、各ポッドで実行されているボリュームも表示されます：
Volumes： my-volume： Type： EmptyDir（Podのライフタイムを共有する一時ディレクトリ）
NetApp Cloud Volumes ONTAPを使用したKubernetesボリュームの管理
NetApp Cloud Volumes ONTAPは業界をリードするエンタープライズクラスのストレージ管理ソリューションであり、AWS、Azure、Google Cloudでセキュアで実証済みのストレージ管理サービスを提供します。Cloud Volumes ONTAP容量はペタバイト規模まで拡張でき、ファイルサービス、データベース、DevOpsなどのさまざまなユースケースや、その他のエンタープライズ ワークロードをサポートし、高可用性、データ保護、Storage Efficiency、Kubernetes統合などの強力な機能セットを提供します。
特に、Cloud Volumes ONTAPは、コンテナ化されたワークロードのKubernetes永続ボリュームのプロビジョニングと管理 要件をサポートしています。
Cloud Volumes ONTAP がコンテナ化されたアプリケーションの課題にどのように対処するかについては、これらの Kubernetes Workloads with Cloud Volumes ONTAP Case Studies をご覧ください。
