ストレージ

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 内の各コンテナーは、以下を指定できます。

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"
      limits:
        ephemeral-storage: "4Gi"
    volumeMounts:
    - name: ephemeral
      mountPath: "/tmp"
  volumes:
    - name: ephemeral
      emptyDir: {}

/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/disk/by-partuuid/4cd1448a-01    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 は起動できません。

ROSA では、Security Context Constraints (SCC) を使用して、クラスター内の Pod のアクセス許可を制御できます。これらのアクセス許可によって、Pod が実行できるアクションとアクセスできるリソースが決まります。SCC を使用して、Pod がシステムに受け入れられるために必要な Pod の実行に関する条件の一覧を定義できます。

詳細は、Security Context Constraints の管理 を参照してください。

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: storage.k8s.io/v1
kind: StorageClass
metadata:
  annotations:
    storageclass.kubernetes.io/is-default-class: "true"
  name: topolvm-provisioner
mountOptions:
  - uid=1500
  - gid=1500
parameters:
  csi.storage.k8s.io/fstype: xfs
provisioner: topolvm.io
reclaimPolicy: Delete
volumeBindingMode: WaitForFirstConsumer
allowVolumeExpansion: true

永続ボリューム要求(PVC)は、さまざまなアクセスモードで作成できます。ReadWriteOnce (RWO)アクセスモードセットを持つ PVC により、同じノード上の複数の Pod が同じ PV に一度に読み取りまたは書き込みできるようになります。

同じノードの Pod が同じ PV に読み取りまたは書き込みできない場合があります。これは、ノードの Pod に同じ SELinux コンテキストがない場合に発生します。永続ボリュームは、RWO アクセスモードで PVC によって後で要求できます。

次の手順を使用して、Pod が一致しているかどうかを確認します。

次の手順を使用して、不一致が見つかった場合は Pod の SELinux コンテキストを更新します。

以下の検証手順を使用して、SCC (Security Context Constraints)と両方の SELinux ラベルを確認します。

各 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 の管理者が永続ボリューム要求 (PVC) の状態を手動で復旧し、サイズ変更要求を取り消します。そうでない場合は、サイズ変更要求がコントローラーによって継続的に再試行されます。

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)

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

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

LVM Storage を使用したストレージのプロビジョニングで使用できるデバイスのサイズを設定する際の制限は、次のとおりです。

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

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

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

socket-name: 1
device-classes: 2
  - name: "default" 3
    volume-group: "VGNAMEHERE" 4
    spare-gb: 0 5
    default: 6

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

socket-name: /run/topolvm/lvmd.sock
device-classes:
  - name: ssd
    volume-group: ssd-vg
    spare-gb: 0 1
    default: true
  - name: hdd
    volume-group: hdd-vg
    spare-gb: 0
  - name: thin
    spare-gb: 0
    thin-pool:
      name: thin
      overprovision-ratio: 10
    type: thin
    volume-group: ssd
  - name: striped
    volume-group: multi-pv-vg
    spare-gb: 0
    stripe: 2
    stripe-size: "64"
    lvcreate-options:2

ボリュームスナップショットの作成やボリュームクローン作成などの高度なストレージ機能を使用するには、以下のアクションを実行する必要があります。

LVMS がシン論理ボリューム (LV) を管理するには、etc/lvmd.yaml 設定ファイルでシンプールの デバイスクラス アレイを指定する必要があります。複数のシンプールデバイスクラスが許可されます。

追加のストレージプールがデバイスクラスで設定されている場合、ストレージプールをユーザーおよびワークロードに公開するには、追加のストレージクラスも存在する必要があります。シンプールで動的プロビジョニングを有効にするには、StorageClass リソースがクラスター上に存在する必要があります。StorageClass リソースは、topolvm.io/device-class パラメーターでソース device-class クラス配列を指定します。

socket-name: 1
device-classes: 2
  - name: thin 3
    default: true
    spare-gb: 0 4
    thin-pool:
      name: thin
      overprovision-ratio: 10 5
    type: thin 6
    volume-group: ssd 7

apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
  annotations:
    storageclass.kubernetes.io/is-default-class: "true" 1
  name: topolvm-provisioner
parameters:
  "csi.storage.k8s.io/fstype": "xfs" 2
provisioner: topolvm.io 3
reclaimPolicy: Delete
volumeBindingMode: WaitForFirstConsumer 4
allowVolumeExpansion: 5

スナップショットは、LVMS でサポートされる CSI ストレージ機能です。動的スナップショットを有効にするには、少なくとも 1 つの VolumeSnapshotClass 設定ファイルがクラスターに存在する必要があります。

apiVersion: snapshot.storage.k8s.io/v1
kind: VolumeSnapshotClass
metadata:
  name: topolvm-snapclass
  annotations:
    snapshot.storage.kubernetes.io/is-default-class: "true" 1
driver: topolvm.io 2
deletionPolicy: Delete 3

論理ボリュームマネージャー (LVM) シンボリュームでボリュームスナップショットを使用すると、MicroShift クラスターで実行されているアプリケーションからのデータ損失を防ぐことができます。MicroShift は、論理ボリュームマネージャーストレージ (LVMS) Container Storage Interface (CSI) プロバイダーのみをサポートします。

$ oc apply -f - <<EOF
apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: test-claim-thin
spec:
  accessModes:
  - ReadWriteOnce
  resources:
    requests:
      storage: 1Gi
  storageClassName: topolvm-provisioner-thin
---
apiVersion: v1
kind: Pod
metadata:
  name: base
spec:
  containers:
  - command:
	    - nginx
	    - -g
	    - 'daemon off;'
    image: registry.redhat.io/rhel8/nginx-122@sha256:908ebb0dec0d669caaf4145a8a21e04fdf9ebffbba5fd4562ce5ab388bf41ab2
    name: test-container
    securityContext:
      allowPrivilegeEscalation: false
      capabilities:
        drop:
        - ALL
    volumeMounts:
    - mountPath: /vol
      name: test-vol
  securityContext:
    runAsNonRoot: true
    seccompProfile:
      type: RuntimeDefault
  volumes:
  - name: test-vol
    persistentVolumeClaim:
      claimName: test-claim-thin
EOF

論理ボリュームマネージャーストレージ (LVMS) は、論理ボリュームマネージャー (LVM) シンボリュームの永続ボリューム要求 (PVC) のクローン作成をサポートします。クローンは、既存のボリュームの複製で、他のボリュームと同様に使用できます。プロビジョニング時に、データソースが同じ namespace 内のソース PVC を参照すると、元のボリュームと全く同じ複製が作成されます。クローン作成された PVC の作成後に、これは新規オブジェクトと見なされ、ソース PVC と完全に分離されます。クローンは、作成された時点のソースからのデータを表します。

ストレージの移行は、保存されたデータを最新のストレージバージョンに更新するプロセスです (例: v1beta1 から v1beta2)。ストレージのバージョンを更新するには、次の手順を実行します。