ストレージ

Red Hat build of MicroShift ストレージは、一時ストレージと永続ストレージという 2 つのカテゴリーに大きく分類されます。

永続ストレージに加え、Pod とコンテナーは、操作に一時または短期的なローカルストレージを必要とする場合があります。この一時ストレージは、個別の Pod の寿命より長くなることはなく、一時ストレージは Pod 間で共有することはできません。

Pod は、スクラッチ領域、キャッシュ、ログに一時ローカルストレージを使用します。ローカルストレージのアカウントや分離がないことに関連する問題には、以下が含まれます。

永続ボリュームとは異なり、一時ストレージは構造化されておらず、領域はノードで実行しているすべての Pod、システムによる他の使用、および Red Hat build of MicroShift の間で共有されます。一時ストレージフレームワークにより、Pod は短期的なローカルストレージのニーズを指定できます。また、Red Hat build of MicroShift がローカルストレージの過剰な使用からノードを保護できるようにします。

一時ストレージフレームワークを使用すると、管理者および開発者はローカルストレージをより適切に管理できますが、I/O スループットやレイテンシーに直接影響はありません。

一時ローカルストレージは常に、プライマリーパーティションで利用できるようになっています。プライマリーパーティションを作成する基本的な方法には、Root、ランタイム の 2 つがあります。

Root

このパーティションでは、kubelet の root ディレクトリー /var/lib/kubelet/ (デフォルト) と /var/log/ ディレクトリーを保持します。このパーティションは、ユーザーの Pod、OS、Kubernetes システムのデーモン間で共有できます。Pod は、EmptyDir ボリューム、コンテナーログ、イメージ階層、コンテナーの書き込み可能な階層を使用して、このパーティションを使用できます。Kubelet はこのパーティションの共有アクセスおよび分離を管理します。このパーティションは一時的なもので、アプリケーションは、このパーティションからディスク IOPS などのパフォーマンス SLA は期待できません。

ランタイム

これは、ランタイムがオーバーレイファイルシステムに使用可能なオプションのパーティションです。Red Hat build of MicroShift は、このパーティションの分離および共有アクセスを特定して提供するように試行します。コンテナーイメージ階層と書き込み可能な階層は、ここに保存されます。ランタイムパーティションが存在すると、root パーティションにはイメージ階層もその他の書き込み可能階層も含まれません。

クラスター管理者は、非終了状態のすべての Pod の一時ストレージに対して制限範囲や一時ストレージの要求数を定義するクォータを設定することで、プロジェクト内で一時ストレージを管理できます。開発者は Pod およびコンテナーのレベルで、このコンピュートリソースの要求および制限を設定することもできます。

要求と制限を指定することで、ローカルの一時ストレージを管理できます。Pod 内の各コンテナーは、以下を指定できます。

一時ストレージの制限と要求は、バイト単位で測定されます。ストレージは、E、P、T、G、M、k のいずれかの接尾辞を使用して、単純な整数または固定小数点数として表すことができます。Ei、Pi、Ti、Gi、Mi、Ki の 2 のべき乗も使用できます。たとえば、128974848、129e6、129M、および 123Mi はすべてほぼ同じ値を表します。接尾辞の大文字と小文字は区別する必要があります。400m の一時ストレージを指定すると、おそらく意図されたものであろう 400 メビバイト (400Mi) または 400 メガバイト (400M) ではなく、0.4 バイトが要求されます。

次の例は、2 つのコンテナーを持つ Pod を示しています。各コンテナーは、2GiB のローカル一時ストレージを要求します。各コンテナーには、4GiB のローカル一時ストレージの制限があります。したがって、Pod には 4GiB のローカル一時ストレージの要求と、8GiB のローカル一時ストレージの制限があります。

apiVersion: v1
kind: Pod
metadata:
  name: frontend
spec:
  containers:
  - name: app
    image: images.my-company.example/app:v4
    resources:
      requests:
        ephemeral-storage: "2Gi" 1
      limits:
        ephemeral-storage: "4Gi" 2
    volumeMounts:
    - name: ephemeral
      mountPath: "/tmp"
  - name: log-aggregator
    image: images.my-company.example/log-aggregator:v6
    resources:
      requests:
        ephemeral-storage: "2Gi" 3
    volumeMounts:
    - name: ephemeral
      mountPath: "/tmp"
  volumes:
    - name: ephemeral
      emptyDir: {}

Pod 仕様のこの設定は、スケジューラーが Pod のスケジューリングを決定する方法と、kubelet が Pod を削除する方法に影響します。まず、スケジューラーは、スケジュールされたコンテナーのリソース要求の合計がノードの容量よりも少ないことを確認します。この場合は、使用可能な一時ストレージ (割り当て可能なリソース) が 4GiB を超える場合にのみ、Pod をノードに割り当てることができます。

次に、コンテナーレベルでは、最初のコンテナーがリソース制限を設定するため、kubelet エビクションマネージャーはこのコンテナーのディスク使用量を測定し、このコンテナーのストレージ使用量がその制限 (4GiB) を超える場合は、Pod をエビクトします。Pod レベルでは、kubelet は、その Pod 内のすべてのコンテナーの制限を合計することで、Pod 全体のストレージ制限を計算します。この場合、Pod レベルでの合計ストレージ使用量は、すべてのコンテナーからのディスク使用量と Pod の emptyDir ボリュームの合計になります。この合計使用量が全体的な Pod ストレージの制限 (4GiB) を超えた場合、kubelet は Pod にエビクションのマークも付けます。

/bin/df をツールとして使用し、一時コンテナーデータが置かれているボリューム (/var/lib/kubelet および /var/lib/containers) の一時ストレージの使用を監視できます。/var/lib/kubelet のみが使用できる領域は、クラスター管理者によって /var/lib/containers が別のディスクに置かれる場合に df コマンドを使用すると表示されます。

/var/lib での使用済みおよび利用可能な領域の人間が判読できる値を表示するには、以下のコマンドを実行します。

$ df -h /var/lib

この出力には、/var/lib での一時ストレージの使用状況が表示されます。

Filesystem  Size  Used Avail Use% Mounted on
/dev/sda1    69G   32G   34G  49% /

汎用一時ボリュームは、永続ボリュームおよび動的プロビジョニングをサポートするすべてのストレージドライバーが提供できる一時ボリュームの一種です。汎用の一時ボリュームは、スクラッチデータ用に Pod ごとのディレクトリー (通常、プロビジョニング後は空) を提供する点で emptyDir ボリュームと類似しています。

汎用の一時ボリュームは Pod 仕様に準拠して指定され、Pod のライフサイクルに従います。これらは Pod と共に作成され、削除されます。

汎用の一時ボリュームには、以下の特徴があります。

ボリューム要求のパラメーターは Pod のボリュームソース内で許可されます。ラベル、アノテーション、および永続ボリューム要求 (PVC) のフィールドの全セットがサポートされます。このような Pod が作成されると、一時ボリュームコントローラーは (汎用一時ボリュームの作成 の手順に示すテンプレートから) Pod と同じ namespace に実際の PVC オブジェクトを作成し、Pod が削除されると PVC が削除されるようにします。これがトリガーとなり、以下の 2 つの方法のいずれかでボリュームのバインディングおよびプロビジョニングが行われます。

リソースの所有権に関しては、汎用一時ストレージを持つ Pod は、その一時ストレージを提供する PVC の所有者となります。Pod が削除されると、Kubernetes ガベージコレクターによって PVC が削除され、ストレージクラスのデフォルトの再利用ポリシーがボリュームを削除することになっているため、通常はボリュームの削除がトリガーされます。回収ポリシーが保持のストレージクラスを使用して、準一時ローカルストレージを作成できます。Pod が削除されてもストレージは存続するため、この場合は別途ボリュームのクリーンアップが行われるようにする必要があります。これらの PVC は存在しますが、それらは他の PVC と同様に使用できます。特に、それらはボリュームのクローン作成またはスナップショット作成時にデータソースとして参照できます。PVC オブジェクトは、ボリュームの現在のステータスも保持します。

汎用一時ボリューム機能を有効にすると、Pod を作成できるユーザーが永続ボリューム要求 (PVC) も間接的に作成できるようになります。この機能は、これらのユーザーが PVC を直接作成するパーミッションを持たない場合でも機能します。クラスター管理者はこれを認識している必要があります。これがセキュリティーモデルに適さない場合は、汎用的な一時ボリュームを持つ Pod などのオブジェクトを拒否する容認 Webhook を使用します。

PVC に対する通常の namespace クォータは依然として適用されるため、ユーザーがこの新しいメカニズムを使用できる場合でも、これを使用して他のポリシーを回避できません。

自動的に作成される永続ボリューム要求 (PVC) には、Pod 名とボリューム名を組み合わせ、間にハイフン (-) を挿入した名前が付けられます。この命名規則では、異なる Pod 間および Pod と手動で作成された PVC 間で競合が生じる可能性があります。

たとえば、pod-a とボリューム scratch の組み合わせと、pod とボリューム a-scratch の組み合わせは、どちらも同じ PVC 名 pod-a-scratch になります。

このような競合は検出され、Pod 用に作成された場合にのみ、PVC は一時ボリュームに使用されます。このチェックは所有者の関係に基づいています。既存の PVC は上書きまたは変更されませんが、競合は解決されません。適切な PVC がないと、Pod は起動できません。

PVC は namespace に固有であり、PV を使用する手段として開発者によって作成および使用されます。PV リソース自体は、単一の namespace に限定されません。これらは Red Hat build of MicroShift クラスター全体で共有でき、任意の namespace から要求できます。PV が PVC にバインドされた後は、その PV を追加の PVC にバインドすることはできません。これには、バインドされた PV を単一の namespace にスコープする効果があります。

PV は、クラスター管理者によって静的にプロビジョニングされているか、StorageClass オブジェクトを使用して動的にプロビジョニングされているクラスター内の既存ストレージの一部を表す、PersistentVolume API オブジェクトで定義されます。これは、ノードがクラスターリソースであるのと同様にクラスター内のリソースです。

PV は Volumes などのボリュームプラグインですが、PV を使用する個々の Pod から独立したライフサイクルを持ちます。PV オブジェクトは、その LVM、ホストパスなどのホストファイルシステム、または raw ブロックデバイスなど、ストレージの実装の詳細をキャプチャーします。

PersistentVolumes と同様に、PersistentVolumeClaims (PVC) は API オブジェクトであり、開発者によるストレージの要求を表します。これは Pod がノードリソースを消費する点で Pod に似ており、PVC は PV リソースを消費します。たとえば、Pod は特定のレベルのリソース (CPU およびメモリーなど) を要求し、PVC は特定のストレージ容量およびアクセスモードを要求できます。OpenShift Container Platform でサポートされるアクセスモードは、Red Hat build of MicroShift でも定義できます。ただし、Red Hat build of MicroShift はマルチノードデプロイメントをサポートしていないため、ReadWriteOnce (RWO) のみが適切です。

PV はクラスターのリソースです。PVC はそれらのリソースの要求であり、リソースに対する要求チェックとして機能します。PV と PVC 間の相互作用には以下のライフサイクルが設定されます。

各 PV には、以下の例のように、ボリュームの仕様およびステータスである spec および status が含まれます。

apiVersion: v1
kind: PersistentVolume
metadata:
  name: pv0001 1
spec:
  capacity:
    storage: 5Gi 2
  accessModes:
    - ReadWriteOnce 3
  persistentVolumeReclaimPolicy: Retain 4
  ...
status:
  ...

$ oc get pv <pv-claim>

apiVersion: v1
kind: PersistentVolume
metadata:
  name: pv0001
spec:
  capacity:
    storage: 1Gi
  accessModes:
    - ReadWriteOnce
  mountOptions: 1
    - nfsvers=4.1
  nfs:
    path: /tmp
    server: 172.17.0.2
  persistentVolumeReclaimPolicy: Retain
  claimRef:
    name: claim1
    namespace: default

各 PersistentVolumeClaim オブジェクトには、永続ボリューム要求 (PVC) の仕様およびステータスである spec および status が含まれます。 以下が例になります。

kind: PersistentVolumeClaim
apiVersion: v1
metadata:
  name: myclaim 1
spec:
  accessModes:
    - ReadWriteOnce 2
  resources:
    requests:
      storage: 8Gi 3
  storageClassName: gold 4
status:
  ...

kind: Pod
apiVersion: v1
metadata:
  name: mypod
spec:
  containers:
    - name: myfrontend
      image: dockerfile/nginx
      volumeMounts:
      - mountPath: "/var/www/html" 1
        name: mypd 2
  volumes:
    - name: mypd
      persistentVolumeClaim:
        claimName: myclaim 3

ストレージボリュームに多数のファイル (~1,000,000 以上) が含まれる場合は、Pod のタイムアウトが生じる可能性があります。

デフォルトでは、Red Hat build of MicroShift は、ボリュームがマウントされる際に Pod の securityContext で指定される fsGroup に一致するよう、各ボリュームのコンテンツの所有者とパーミッションを再帰的に変更するため、これが発生する可能性があります。大規模なボリュームでは、所有者とパーミッションの確認と変更には時間がかかり、Pod の起動が遅くなる場合があります。securityContext 内の fsGroupChangePolicy フィールドを使用して、Red Hat build of MicroShift がボリュームの所有権とパーミッションをチェックおよび管理する方法を制御できます。

fsGroupChangePolicy は、Pod 内で公開される前にボリュームの所有者およびパーミッションを変更する動作を定義します。このフィールドは、fsGroupで制御される所有者およびパーミッションをサポートするボリュームタイプにのみ適用されます。このフィールドには、以下の 2 つの値を指定できます。

securityContext:
  runAsUser: 1000
  runAsGroup: 3000
  fsGroup: 2000
  fsGroupChangePolicy: "OnRootMismatch" 1
  ...

Container Storage Interface (CSI) を使用して、作成後にストレージボリュームを拡張することができます。

CSI ボリューム拡張は、以下をサポートしません。

ローカルストレージ Operator (LSO) を使用して作成された永続ボリューム (PV) および永続ボリューム要求 (PVC) を手動で拡張できます。

Kubelet は、ボリューム上の基礎となるファイルシステムを自動的に拡張するはずです。必要に応じて、新しいサイズを反映するように PVC の status フィールドを更新します。

GCE Persistent Disk ボリューム (gcePD)、AWS Elastic Block Store EBS (EBS)、Cinder など、ファイルシステムのサイズ変更が必要なボリュームタイプに基づいて PVC を拡張するには、2 段階のプロセスがあります。まず、クラウドプロバイダーのボリュームオブジェクトを拡張します。次に、ノードのファイルシステムを拡張します。

ノードでのファイルシステムの拡張は、新規 Pod がボリュームと共に起動する場合にのみ実行されます。

基礎となるストレージの拡張に失敗した場合に Red Hat build of MicroShift の管理者は Persistent Volume Claim (PVC) の状態を手動で復旧し、サイズ変更要求を取り消します。そうでない場合は、サイズ変更要求がコントローラーによって継続的に再試行されます。

Red Hat build of MicroShift で LVMS を使用するには、次のシステム仕様が必要です。

Warning  ProvisioningFailed    3s (x2 over 5s)  topolvm.cybozu.com_topolvm-controller-858c78d96c-xttzp_0fa83aef-2070-4ae2-bcb9-163f818dcd9f failed to provision volume with
StorageClass "topolvm-provisioner": rpc error: code = ResourceExhausted desc = no enough space left on VG: free=(BYTES_INT), requested=(BYTES_INT)

Red Hat build of MicroShift の起動後、LVMS は openshift-storage namespace のクラスターに自動的にデプロイされます。

LVMS は StorageCapacity 追跡を使用して、要求されたストレージがボリュームグループの空きストレージよりも大きい場合は、LVMS PVC を持つ Pod がスケジュールされないようにします。StorageCapacity 追跡の詳細は、Storage Capacity を参照してください。

Red Hat build of MicroShift が実行するとき、指定されている場合は /etc/microshift/lvmd.yaml からの LVMS 設定が使用されます。作成するすべての設定ファイルを /etc/microshift/ ディレクトリーに配置する必要があります。

Red Hat build of MicroShift は、LVM 設定のパススルーをサポートしており、カスタムボリュームグループ、シンボリュームプロビジョニングパラメーター、予約済みの未割り当てボリュームグループ領域を指定できます。作成した LVMS 設定ファイルはいつでも編集できます。ファイルの編集後に設定の変更をデプロイするには、Red Hat build of MicroShift を再起動する必要があります。

次の lvmd.yaml サンプルファイルは、基本的な LVMS 設定を示しています。

socket-name: 1
device-classes: 2
  - name: 3
    volume-group: 4
    spare-gb: 5
    default: 6
  - name: hdd
    volume-group: hdd-vg
    spare-gb: 10
  - name: striped
    volume-group: multi-pv-vg
    spare-gb: 10
    stripe: 7
    stripe-size: 8
  - name: raid
    volume-group: raid-vg
    lvcreate-options: 9
      - --type=raid1

ストライピングは、専用オプション (stripe および stripe-size) および lvcreate-options を使用して設定できます。どちらのオプションも使用できますが、同時に使用することはできません。lvcreate-options で stripe と stripe-size を使用すると、lvcreate への引数が重複します。lvcreate-options: ["--stripes=n"] と stripe: n を同時に設定しないでください。ただし、ストライピングに lvcreate-options を使用しない場合は、両方を使用できます。以下に例を示します。

stripe: 2
lvcreate-options: ["--mirrors=1"]

LVMS StorageClass は、デフォルトの StorageClass でデプロイされます。.spec.storageClassName が定義されていない PersistentVolumeClaim オブジェクトには、デフォルトの StorageClass からプロビジョニングされた PersistentVolume が自動的に含まれます。次の手順を使用して、論理ボリュームをプロビジョニングし、Pod にマウントします。