Pod およびコンテナーは性質上、一時的または遷移的であり、ステートレスアプリケーション用に設計されています。一時ストレージを使用すると、管理者および開発者は一部の操作についてローカルストレージをより適切に管理できるようになります。一時ストレージの概要、タイプ、および管理の詳細は、一時ストレージについて を参照してください。

コンテナーにデプロイされるステートフルアプリケーションには永続ストレージが必要です。Red Hat OpenShift Service on AWS は、永続ボリューム (PV) と呼ばれる事前にプロビジョニングされたストレージフレームワークを使用して、クラスター管理者が永続ストレージをプロビジョニングできるようにします。これらのボリューム内のデータは、個々の Pod のライフサイクルを超えて存在することができます。開発者は Persistent Volume Claim(永続ボリューム要求、PVC) を使用してストレージ要件を要求できます。永続ストレージの概要、設定、およびライフサイクルの詳細は、永続ストレージについて を参照してください。

一時ストレージの制限と要求は、バイト単位で測定されます。ストレージは、E、P、T、G、M、k のいずれかの接尾辞を使用して、単純な整数または固定小数点数として表すことができます。Ei、Pi、Ti、Gi、Mi、Ki の 2 のべき乗も使用できます。

たとえば、128974848、129e6、129M、および 123Mi はすべてほぼ同じ値を表します。

次のサンプル設定ファイルは、2 つのコンテナーを持つ 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: {}

Pod 仕様の設定は、スケジューラーが Pod のスケジュールを決定する方法と、kubelet が Pod を削除するタイミングの両方に影響します。

PVC で定義される開発者からの要求に対応し、クラスター管理者はストレージおよび一致する PV をプロビジョニングする 1 つ以上の動的プロビジョナーを設定します。

PVC の作成時に、ストレージの特定容量の要求、必要なアクセスモードの指定のほか、ストレージクラスを作成してストレージの記述や分類を行います。マスターのコントロールループは新規 PVC の有無を監視し、新規 PVC を適切な PV にバインドします。適切な PV がない場合は、ストレージクラスのプロビジョナーが PV を作成します。

すべての PV のサイズが PVC サイズを超える可能性があります。これは、手動でプロビジョニングされる PV にとくに当てはまります。超過を最小限にするために、Red Hat OpenShift Service on AWS は他のすべての条件に一致する最小の PV にバインドします。

要求は、一致するボリュームが存在しないか、ストレージクラスを提供するいずれの利用可能なプロビジョナーで作成されない場合には、無期限でバインドされないままになります。要求は、一致するボリュームが利用可能になるとバインドされます。たとえば、多数の手動でプロビジョニングされた 50Gi ボリュームを持つクラスターは 100Gi を要求する PVC に一致しません。PVC は 100Gi PV がクラスターに追加されるとバインドされます。

Pod は要求をボリュームとして使用します。クラスターは要求を検査して、バインドされたボリュームを検索し、Pod にそのボリュームをマウントします。複数のアクセスモードをサポートするボリュームの場合は、要求を Pod のボリュームとして使用する際に適用するモードを指定する必要があります。

要求が存在し、その要求がバインドされている場合は、バインドされた PV を必要な期間保持できます。Pod のスケジュールおよび要求された PV のアクセスは、persistentVolumeClaim を Pod のボリュームブロックに組み込んで実行できます。

ボリュームの処理が終了したら、API から PVC オブジェクトを削除できます。これにより、リソースを回収できるようになります。ボリュームは要求の削除時に解放 (リリース) されたものとみなされますが、別の要求で利用できる状態にはなりません。以前の要求側に関連するデータはボリューム上に残るため、ポリシーに基づいて処理される必要があります。

永続ボリュームの回収ポリシーは、クラスターに対してリリース後のボリュームの処理方法について指示します。ボリュームの回収ポリシーは、Retain、Recycle または Delete のいずれかにすることができます。

永続ボリューム要求 (PVC) が削除されても、永続ボリューム (PV) は依然として存在し、released (リリース済み) とみなされます。ただし、PV は、直前の要求側のデータがボリューム上に残るため、別の要求には利用できません。

回収される PV が別の PVC で使用できるようになります。

永続ボリュームの回収ポリシーを変更するには、以下を実行します。

Red Hat OpenShift Service on AWS (ROSA) は、次の永続ボリュームストレージオプションをサポートしています。

ROSA は、他のストレージベンダーの Kubernetes Container Storage Interface (CSI) 互換ボリュームプロビジョナーと連携して機能します。ROSA の CSI ドライバーについて、詳細は CSI ボリュームの設定 を参照してください

通常、永続ボリューム (PV) には特定のストレージ容量があります。これは PV の capacity 属性を使用して設定されます。

現時点で、ストレージ容量は設定または要求できる唯一のリソースです。今後は属性として IOPS、スループットなどが含まれる可能性があります。

永続ボリュームは、リソースプロバイダーでサポートされるすべての方法でホストにマウントできます。プロバイダーには各種の機能があり、それぞれの PV のアクセスモードは特定のボリュームでサポートされる特定のモードに設定されます。たとえば、NFS は複数の読み取り/書き込みクライアントをサポートしますが、特定の NFS PV は読み取り専用としてサーバー上でエクスポートされる可能性があります。それぞれの PV は、その特定の PV の機能について記述するアクセスモードの独自のセットを取得します。

要求は、同様のアクセスモードのボリュームに一致します。一致する条件はアクセスモードとサイズの 2 つの条件のみです。要求のアクセスモードは要求 (request) を表します。そのため、より多くのアクセスを付与することはできますが、アクセスを少なくすることはできません。たとえば、要求により RWO が要求されるものの、利用できる唯一のボリュームが NFS PV (RWO+ROX+RWX) の場合に、要求は RWO をサポートする NFS に一致します。

直接的なマッチングが常に最初に試行されます。ボリュームのモードは、要求モードと一致するか、要求した内容以上のものを含む必要があります。サイズは予想されるものより多いか、これと同等である必要があります。2 つのタイプのボリューム (NFS および iSCSI など) のどちらにも同じセットのアクセスモードがある場合、それらのいずれかがそれらのモードを持つ要求に一致する可能性があります。ボリュームのタイプ間で順序付けすることはできず、タイプを選択することはできません。

同じモードのボリュームはすべて分類され、サイズ別 (一番小さいものから一番大きいもの順) に分類されます。バインダーは一致するモードのグループを取得し、1 つのサイズが一致するまでそれぞれを (サイズの順序で) 繰り返し処理します。

以下の表では、アクセスモードをまとめています。

ボリュームは以下のフェーズのいずれかにあります。

以下のコマンドを実行して、PV にバインドされている PVC の名前を表示できます。

$ 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

要求は、ストレージクラスの名前を storageClassName 属性に指定して特定のストレージクラスをオプションでリクエストできます。リクエストされたクラスの PV、つまり PVC と同じ storageClassName を持つ PV のみが PVC にバインドされます。クラスター管理者は 1 つ以上のストレージクラスを提供するように動的プロビジョナーを設定できます。クラスター管理者は、PVC の仕様に一致する PV をオンデマンドで作成できます。

クラスター管理者は、すべての PVC にデフォルトストレージクラスを設定することもできます。デフォルトのストレージクラスが設定されると、PVC は "" に設定された StorageClass または storageClassName アノテーションがストレージクラスなしの PV にバインドされるように明示的に要求する必要があります。

要求は、特定のアクセスモードのストレージを要求する際にボリュームと同じ規則を使用します。

要求は、Pod の場合のようにリソースの特定の数量を要求できます。今回の例では、ストレージに対する要求です。同じリソースモデルがボリュームと要求の両方に適用されます。

Pod は要求をボリュームとして使用することでストレージにアクセスします。この要求を使用して、Pod と同じ namespace 内に要求を共存させる必要があります。クラスターは Pod の namespace で要求を見つけ、これを使用して要求をサポートする PersistentVolume を取得します。以下のように、ボリュームはホストにマウントされ、Pod に組み込まれます。

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

ストレージクラスを使用すると、ストレージのレベルや使用状況を区別し、記述することができます。ストレージクラスを定義することにより、ユーザーは動的にプロビジョニングされた永続ボリュームを取得できます。

Red Hat OpenShift Service on AWS はボリュームをマウントしてコンテナーに渡す前に、永続ボリューム定義の fsType パラメーターで指定されたファイルシステムがボリュームに含まれていることを確認します。デバイスが指定されたファイルシステムでフォーマットされていない場合、デバイスのデータはすべて消去され、デバイスはそのファイルシステムで自動的にフォーマットされます。

この検証により、フォーマットされていない AWS ボリュームを永続ボリュームとして使用できるようになります。これは、Red Hat OpenShift Service on AWS が最初に使用する前にフォーマットするためです。

デフォルトでは、Red Hat OpenShift Service on AWS は、1 つのノードにアタッチされた最大 39 個の EBS ボリュームをサポートします。この制限は、AWS ボリュームの制限 に合致します。ボリュームの制限は、インスタンスのタイプによって異なります。

in-tree ボリュームプラグインでは不可能な追加のストレージオプション (ボリュームスナップショットなど) へのアクセスに関する詳細は、AWS Elastic Block Store CSI ドライバー Operator を参照してください。

AWS でコンテナー永続ボリュームを暗号化するための KMS キーを定義すると、AWS へのデプロイ時に明示的なコンプライアンスおよびセキュリティーのガイドラインがある場合に役立ちます。

CSI ドライバーは通常、コンテナーイメージとして提供されます。これらのコンテナーは、それらが実行される Red Hat OpenShift Service on AWS を認識しません。Red Hat OpenShift Service on AWS で CSI 互換のストレージバックエンドを使用するには、クラスター管理者は、Red Hat OpenShift Service on AWS とストレージドライバーの間のブリッジとして機能する複数のコンポーネントをデプロイする必要があります。

次の図は、Red Hat OpenShift Service on AWS クラスターの Pod で実行されるコンポーネントの概要を示しています。

異なるストレージバックエンドに対して複数の CSI ドライバーを実行できます。各ドライバーには、独自の外部コントローラーのデプロイメントおよびドライバーと CSI レジストラーを含むデーモンセットが必要です。

Red Hat OpenShift Service on AWS は、デフォルトで特定の CSI ドライバーをインストールし、in-tree ボリュームプラグインでは不可能なストレージオプションをユーザーに提供します。

これらのサポートされているストレージアセットにマウントする CSI プロビジョニングされた永続ボリュームを作成するために、Red Hat OpenShift Service on AWS は、必要な CSI ドライバー Operator、CSI ドライバー、および必要なストレージクラスをデフォルトでインストールします。Operator およびドライバーのデフォルト namespace についての詳細は、特定の CSI ドライバー Operator のドキュメントを参照してください。

以下の表では、Red Hat OpenShift Service on AWS とともにインストールされる CSI ドライバーと、ボリュームのスナップショットやサイズ変更など、それらがサポートする CSI 機能について説明します。

前の表にリストされているドライバーに加えて、ROSA はサードパーティーストレージベンダーの CSI ドライバーでも機能します。Red Hat は、サードパーティーのプロビジョナーや接続されている CSI ドライバーを監督しません。ソースコード、デプロイメント、運用、および Kubernetes の互換性は、ベンダーがを完全に制御します。これらのボリュームプロビジョナーはお客様が管理するものとし、各ベンダーにはそのサポートを提供する責任があります。詳細は、Red Hat OpenShift Service on AWS の共有責任 マトリクスを参照してください。

永続ストレージの動的プロビジョニングは、CSI ドライバーおよび基礎となるストレージバックエンドの機能により異なります。CSI ドライバーのプロバイダーは、Red Hat OpenShift Service on AWS でストレージクラスを作成する方法と、設定に使用できるパラメーターを文書化する必要があります。

作成されたストレージクラスは、動的プロビジョニングを有効にするために設定できます。

以下の例では、テンプレートを変更せずにデフォルトの MySQL テンプレートをインストールします。

デフォルトのストレージクラスを管理すると、複数の異なる目的を達成できます。

これらの目的を達成するには、ClusterCSIDriver オブジェクトの spec.storageClassState フィールドの設定を変更します。このフィールドで可能な設定は以下のとおりです。

oc patch clustercsidriver $DRIVERNAME --type=merge -p "{\"spec\":{\"storageClassState\":\"${STATE}\"}}" 1

次の手順を使用して、デフォルトのストレージクラスを変更します。

たとえば、gp3 と standard の 2 つのストレージクラスがあり、デフォルトのストレージクラスを gp3 から standard に変更する必要がある場合などです。

Red Hat OpenShift Service on AWS は AWS EBS CSI ドライバー を使用して永続ボリューム (PV) をプロビジョニングできます。

Container Storage Interface (CSI) Operator およびドライバーを使用する場合、永続ストレージ および CSI ボリュームの設定 について理解しておくことが推奨されます。

AWS EBS ストレージアセットにマウントする CSI プロビジョニングされた PV を作成するために、Red Hat OpenShift Service on AWS は AWS EBS CSI Driver Operator (Red Hat Operator) と AWS EBS CSI ドライバーをデフォルトで openshift-cluster-csi-drivers namespace にインストールします。

ストレージベンダーはこれまで Kubernetes の一部としてストレージドライバーを提供してきました。Container Storage Interface (CSI) の実装では、サードパーティーのプロバイダーは、コア Kubernetes コードを変更せずに標準のインターフェイスを使用してストレージプラグインを提供できます。

CSI Operator は、in-tree (インツリー) ボリュームプラグインでは不可能なボリュームスナップショットなどのストレージオプションを Red Hat OpenShift Service on AWS ユーザーに付与します。

Red Hat OpenShift Service on AWS で AWS EBS 永続ボリュームを動的にプロビジョニングする方法については、Amazon Elastic Block Store を使用した永続ストレージ を参照してください。

Red Hat OpenShift Service on AWS は AWS EFS CSI ドライバー を使用して永続ボリューム (PV) をプロビジョニングできます。

CSI Operator およびドライバーを使用する場合は、永続ストレージ および CSI ボリュームの設定 について理解しておくことが推奨されます。

AWS EFS CSI Driver Operator をインストールした後、Red Hat OpenShift Service on AWS は、デフォルトで AWS EFS CSI Operator と AWS EFS CSI ドライバーを openshift-cluster-csi-drivers namespace にインストールします。これにより、AWS EFS CSI ドライバー Operator は、AWS EFS アセットにマウントする CSI がプロビジョニングする PV を作成することができます。

ストレージベンダーはこれまで Kubernetes の一部としてストレージドライバーを提供してきました。Container Storage Interface (CSI) の実装では、サードパーティーのプロバイダーは、コア Kubernetes コードを変更せずに標準のインターフェイスを使用してストレージプラグインを提供できます。

CSI Operator は、in-tree (インツリー) ボリュームプラグインでは不可能なボリュームスナップショットなどのストレージオプションを Red Hat OpenShift Service on AWS ユーザーに付与します。

ストレージクラスを使用すると、ストレージのレベルや使用状況を区別し、記述することができます。ストレージクラスを定義することにより、ユーザーは動的にプロビジョニングされた永続ボリュームを取得できます。

AWS EFS CSI Driver Operator (Red Hat Operator) は、インストール後、デフォルトではストレージクラスを作成しません。ただし、AWS EFS ストレージクラスを手動で作成することは可能です。

この手順では、Red Hat OpenShift Service on AWS で使用できるように、AWS で EFS ボリュームを作成および設定する方法を説明します。

AWS EFS CSI ドライバー は、他の CSI ドライバーとは異なる形式の動的プロビジョニングをサポートします。既存の EFS ボリュームのサブディレクトリーとして新しい PV をプロビジョニングします。PV はお互いに独立しています。しかし、これらはすべて同じ EFS ボリュームを共有しています。ボリュームが削除されると、そのボリュームからプロビジョニングされたすべての PV も削除されます。EFS CSI ドライバーは、そのようなサブディレクトリーごとに AWS アクセスポイントを作成します。AWS AccessPoint の制限により、単一の StorageClass/EFS ボリュームから動的にプロビジョニングできるのは 1000 PV のみです。

動的プロビジョニングの設定で問題が発生した場合は、Amazon Elastic File Storage のトラブルシューティング を参照してください。

動的プロビジョニングを行わずに、Amazon Elastic File Storage (Amazon EFS) ボリュームを単一の PV として使用できます。ボリューム全体が Pod にマウントされます。

静的 PV の設定に問題がある場合は、Amazon Elastic File Storage のトラブルシューティング を参照してください。

次の情報は、Amazon Elastic File Storage (Amazon EFS) のセキュリティーにとって重要です。

前述の動的プロビジョニングなどでアクセスポイントを使用する場合、Amazon はファイルの GID をアクセスポイントの GID に自動的に置き換えます。また、EFS では、ファイルシステムの権限を評価する際に、アクセスポイントのユーザー ID、グループ ID、セカンダリーグループ ID を考慮します。EFS は、NFS クライアントの ID を無視します。アクセスポイントの詳細については、https://docs.aws.amazon.com/efs/latest/ug/efs-access-points.html を参照してください。

結果として、EFS ボリュームは暗黙のうちに FSGroup を無視します。Red Hat OpenShift Service on AWS は、ボリューム上のファイルの GID を FSGroup に置き換えることができません。マウントされた EFS アクセスポイントにアクセスできる Pod は、そこにあるすべてのファイルにアクセスできます。

これとは関係ありませんが、転送中の暗号化はデフォルトで有効になっています。詳しくは、https://docs.aws.amazon.com/efs/latest/ug/encryption-in-transit.html を参照してください。

次の情報は、Amazon Elastic File Storage (Amazon EFS) に関する問題のトラブルシューティング方法に関するガイダンスです。

AWS EFS CSI Driver Operator (Red Hat Operator) をアンインストールすると、すべての EFS PV にアクセスできなくなります。

以下のリソースは、ストレージクラスを設定するために使用するパラメーターおよびデフォルト値を示しています。この例では、AWS ElasticBlockStore (EBS) オブジェクト定義を使用します。

kind: StorageClass 1
apiVersion: storage.k8s.io/v1 2
metadata:
  name: <storage-class-name> 3
  annotations: 4
    storageclass.kubernetes.io/is-default-class: 'true'
    ...
provisioner: kubernetes.io/aws-ebs 5
parameters: 6
  type: gp3
...

ストレージクラスをクラスター全体のデフォルトとして設定するには、以下のアノテーションをストレージクラスのメタデータに追加します。

storageclass.kubernetes.io/is-default-class: "true"

以下に例を示します。

apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
  annotations:
    storageclass.kubernetes.io/is-default-class: "true"
...

これにより、特定のストレージクラスを指定しない永続ボリューム要求 (PVC) がデフォルトのストレージクラスによって自動的にプロビジョニングされるようになります。ただし、クラスターには複数のストレージクラスを設定できますが、それらのうちの 1 つのみをデフォルトのストレージクラスにすることができます。

ストレージクラスの記述を設定するには、以下のアノテーションをストレーククラスのメタデータに追加します。

kubernetes.io/description: My Storage Class Description

以下に例を示します。

apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
  annotations:
    kubernetes.io/description: My Storage Class Description
...