Kubernetes オブジェクトボリュームの詳細な使用方法

概要

ボリュームは、さまざまなストレージ リソースを抽象化および仮想化したものです。ストレージ リソースを管理、制御、および使用するための統合インターフェイスを提供します。 Openstack のボリュームは仮想マシン用のストレージを提供し、Docker のボリュームはコンテナ用のストレージを提供します。 Kubernetes でデプロイ可能な最小の実行単位はポッドであるため、Kubernetes ボリュームはポッドにストレージを提供します。もちろん、ポッドをデプロイする際にボリュームを用意する必要はありません。ポッド内のコンテナは、配置されたノードのハードディスクを使用します。データの読み取りと書き込みが同時に行える場所を読み書き可能層と呼びます。このストレージは、ポッド レベルではなく、コンテナ レベルでの一時ストレージです。ライフサイクルはコンテナと同じです。コンテナがクラッシュして再起動した場合、つまり古いコンテナが削除され、新しいコンテナが起動された場合、古いコンテナの読み取りおよび書き込み可能なレイヤーはコンテナとともに削除され、その上のデータは失われます。同様に、ポッドがノード間で移行およびスケジュールされる場合、コンテナの読み取り/書き込みレイヤーは移行およびスケジュールされません。したがって、Kubernetes はポッドレベルのボリュームを提供する必要があります。この記事のボリュームは、特に Kubernetes を指します。

ボリュームタイプ

ボリュームは、それぞれ独自の目的、特性、機能を持つ多くの具体的な実装を持つ抽象的な概念です。ほぼ何でもボリュームとして使用できます。種類は次のとおりです。

• awsElasticブロックストア
• アズールディスク
• Azureファイル
• セフス
• 構成マップ
• シーエスアイ
• 下向きAPI
• 空のディレクトリ
• fc (ファイバーチャネル)
• 群れをなす
• gce永続ディスク
• gitRepo (非推奨)
• グラスター
• ホストパス
• iSCSI
• 地元
• ナフサ
• 永続ボリュームクレーム
• 投影された
• ポートワークスボリューム
• クォーバイト
• rbd
• スケールIO
• 秘密
• ストレージ
• vsphereボリューム
• ここでは上記のタイプをすべて一つずつ紹介するのではなく、現在使用されている可能性のあるローカル ディスク ストレージと分散ストレージについて簡単に紹介します。

一般的なストレージタイプの説明と例

セフス

Cephfs は、オープンソースであり、可用性が高く、弾力的にスケーラブルであり、オペレーティング システムとハードウェアに特別な要件がなく、ユーザーが簡単に構築でき、使用するノードに特別な要件がないため、優れた人気のあるクラウド環境ストレージ ソリューションです。 awsElasticBlockStore で説明されているすべての機能を備えており、単一のボリュームを複数のノードで同時に使用できます。ユーザーはまず独自の cephfs 環境を構築し、次にそれに接続するように Kubernetes クラスターを構成し、最後にポッドでそれが提供するボリュームを使用します。詳細については、こちらを参照してください。

構成マップ

ユーザーはまずconfigMapを作成し、その中にデータを保存します。この時点では、データはKubernetesのetcdデータベースに保存されており、ボリュームはまだ存在していません。ユーザーがポッドで作成された configMap を参照すると、システムはまずノード上にボリュームを作成し、そこにデータを保存します。このボリュームは、ノードが占有するストレージ スペースを占有します。その後は通常のボリュームと同じように使用できます。

ConfigMap は Kubernetes のオブジェクト タイプです。その本質は、個別に管理された構成情報をボリュームの形式でポッド内のコンテナーに渡すことであり、永続的なデータを保存するために使用されるものではありません。詳細はこちらをご覧ください。

下向きAPI

configMap と同様に、ボリュームの形式でポッド内のコンテナに情報を渡します。 configMap の情報はオブジェクトの作成時にユーザーによって渡されますが、downwardAPI の情報はポッド オブジェクト自体から取得されます。downwardAPI は作成する必要はありません。これはポッド Spec のフィールドであり、その内容はポッド オブジェクト自体の他のフィールド (ポッド メタデータ、イメージ、その他の情報など) を指します。ポッドを作成すると、システムは最初に指定されたフィールドを抽出し、次にボリュームを作成し、抽出されたフィールドを保存してマウントし、コンテナーがこれらのフィールドを読み取ることができるようにします。

towardAPI の目的は、ラベルや注釈などのポッド独自のフィールド情報をコンテナに渡す手段を提供することです。詳細はこちらをご覧ください。

空のディレクトリ

emptyDir ボリュームは、ノード上でポッド インスタンスが実行された場合にのみ作成されます。最初はノード上の空のディレクトリであり、ポッド内の任意のコンテナがそれをボリュームとしてマウントできます。何らかの理由でコンテナが削除され再起動された場合、作成された emptyDir は削除またはクリアされません。ポッド インスタンスがノードを離れ、別のノードにスケジュールされるか、スケールダウンにより削除されると、emptyDir は削除されます。つまり、ポッドはまだ存在しますが、データは失われます。例：

APIバージョン: v1
種類: ポッド
メタデータ:
 名前: test-pd
仕様:
 コンテナ:
 - イメージ: k8s.gcr.io/test-webserver
  名前: テストコンテナ
  ボリュームマウント:
  - マウントパス: /cache
   名前: キャッシュボリューム
 ボリューム:
 - 名前: キャッシュボリューム
  空ディレクトリ: {}

グラスター

cephfsと同様に、クラウド環境で人気のストレージソリューション

ホストパス

APIバージョン: v1
種類: ポッド
メタデータ:
 名前: test-pd
仕様:
 コンテナ:
 - イメージ: k8s.gcr.io/test-webserver
  名前: テストコンテナ
  ボリュームマウント:
  - マウントパス: /test-pd
   名前: テストボリューム
 ボリューム:
 - 名前: テストボリューム
  ホストパス:
   # ホスト上のディレクトリの場所
   パス: /data
   # このフィールドはオプションです
   タイプ: ディレクトリ

iSCSI

安価であることが特徴のインターネット小型コンピュータシステムインターフェース。

地元

emptyDir と同様に、ノード内のストレージ スペースも占有します。違いは、Kubernetes ではオブジェクト型であり、ユーザーは通常のオブジェクトと同じように管理できる点です。 emptyDir は、ポッド インスタンスが開始されたときに実行時に割り当てられ、ポッドがノードを離れると削除されます。ローカル ボリュームはユーザーによって作成され、システムは適切なノードにリソースを割り当てます。このノードにスケジュールされたポッドはそれをマウントすることができ、ユーザーが削除しない限り、ポッドが去っても消えません。例：

APIバージョン: v1
種類: 永続ボリューム
メタデータ:
 名前: example-pv
仕様:
 容量：
  ストレージ: 100Gi
 # volumeMode フィールドでは、BlockVolume Alpha 機能ゲートを有効にする必要があります。
 ボリュームモード: ファイルシステム
 アクセスモード:
 -一度だけ読み書き可能
 persistentVolumeReclaimPolicy: 削除
 ストレージクラス名: ローカルストレージ
 地元：
  パス: /mnt/disks/ssd1
 ノードアフィニティ:
  必須：
   ノードセレクタ用語:
   - 一致する表現:
    - キー: kubernetes.io/hostname
     演算子:
     値:
     - 例ノード

ナフサ

ナフサ
ネットワークファイルシステム

永続ボリュームクレーム

フロッカーに似ており、さまざまなクラウド環境を保護するために使用されます。

投影された

コンテナが Secret、ConfigMap、DownwardAPI などの複数の既存ボリュームをマウントする必要がある場合、このタイプの各ボリュームはそれぞれマウント ディレクトリを占有する必要があります。ただし、projected はそれらを統合し、1 つのディレクトリにのみマウントできます。例:

APIバージョン: v1
種類: ポッド
メタデータ:
 名前: ボリュームテスト
仕様:
 コンテナ:
 - 名前: コンテナテスト
  画像: ビジーボックス
  ボリュームマウント:
  - 名前: オールインワン
   マウントパス: "/projected-volume"
   読み取り専用: true
 ボリューム:
 - 名前: オールインワン
  予測:
   出典:
   - 秘密：
     名前: mysecret
     アイテム:
      - キー: ユーザー名
       パス: my-group/my-username
   - 下向きAPI:
     アイテム:
      - パス: "ラベル"
       フィールド参照:
        フィールドパス: metadata.labels
      - パス: "cpu_limit"
       リソースフィールド参照:
        コンテナ名: コンテナテスト
        リソース: limits.cpu
   - 構成マップ:
     名前: myconfigmap
     アイテム:
      - キー: config
       パス: my-group/my-config