第4章 Configuring persistent storage
4.1. AWS Elastic Block Store を使用した永続ストレージ
Red Hat OpenShift Service on AWS クラスターは、Amazon Elastic Block Store (Amazon EBS) ボリュームを使用する 4 つのストレージクラスで事前に構築されています。これらのストレージクラスはすぐに使用でき、Kubernetes と AWS にある程度精通していることを前提としています。
以下は、事前構築済みの 4 つのストレージクラスです。
名前 | プロビジョナー |
---|---|
gp2 | kubernetes.io/aws-ebs |
gp2-csi | ebs.csi.aws.com |
gp3 (デフォルト) | kubernetes.io/aws-ebs |
gp3-csi | ebs.csi.aws.com |
gp3 ストレージクラスがデフォルトとして設定されています。ただし、任意のストレージクラスをデフォルトのストレージクラスとして選択できます。
Kubernetes 永続ボリュームフレームワークは、管理者がクラスターのプロビジョニングを永続ストレージを使用して実行できるようにし、ユーザーが基礎となるインフラストラクチャーの知識がなくてもこれらのリソースを要求できるようにします。Amazon EBS ボリュームを動的にプロビジョニングできます。永続ボリュームは単一のプロジェクトまたは namespace にバインドされていません。Red Hat OpenShift Service on AWS クラスター全体で共有できます。永続ボリューム要求はプロジェクトまたは namespace に固有のもので、ユーザーによって要求されます。KMS キーを定義して、AWS のコンテナー永続ボリュームを暗号化できます。デフォルトでは、Red Hat OpenShift Service on AWS バージョン 4.10 以降を使用して新しく作成されたクラスターは、gp3 ストレージと AWS EBS CSI ドライバー を使用します。
インフラストラクチャーにおけるストレージの高可用性は、基礎となるストレージのプロバイダーに委ねられています。
4.1.1. EBS ストレージクラスの作成
ストレージクラスを使用すると、ストレージのレベルや使用状況を区別し、記述することができます。ストレージクラスを定義することにより、ユーザーは動的にプロビジョニングされた永続ボリュームを取得できます。
4.1.2. 永続ボリューム要求の作成
前提条件
ストレージは、Red Hat OpenShift Service on AWS でボリュームとしてマウントする前に、基盤となるインフラストラクチャーに存在する必要があります。
手順
-
Red Hat OpenShift Service on AWS コンソールで、Storage
Persistent Volume Claims をクリックします。 - 永続ボリューム要求の概要で、Create Persistent Volume Claim をクリックします。
表示されるページで必要なオプションを定義します。
- ドロップダウンメニューから以前に作成したストレージクラスを選択します。
- ストレージ要求の一意の名前を入力します。
- アクセスモードを選択します。この選択により、ストレージクレームの読み取りおよび書き込みアクセスが決定されます。
- ストレージ要求のサイズを定義します。
- Create をクリックして永続ボリューム要求を作成し、永続ボリュームを生成します。
4.1.3. ボリュームのフォーマット
Red Hat OpenShift Service on AWS はボリュームをマウントしてコンテナーに渡す前に、永続ボリューム定義の fsType
パラメーターで指定されたファイルシステムがボリュームに含まれていることを確認します。デバイスが指定されたファイルシステムでフォーマットされていない場合、デバイスのデータはすべて消去され、デバイスはそのファイルシステムで自動的にフォーマットされます。
この検証により、フォーマットされていない AWS ボリュームを永続ボリュームとして使用できるようになります。これは、Red Hat OpenShift Service on AWS が最初に使用する前にフォーマットするためです。
4.1.4. ノード上の EBS ボリュームの最大数
デフォルトでは、Red Hat OpenShift Service on AWS は、1 つのノードにアタッチされた最大 39 個の EBS ボリュームをサポートします。この制限は、AWS ボリュームの制限 に合致します。ボリュームの制限は、インスタンスのタイプによって異なります。
クラスター管理者は、In-tree または Container Storage Interface (CSI) ボリュームのいずれかと、それぞれのストレージクラスを使用する必要がありますが、ボリュームの両方のタイプを同時に使用することはできません。割り当てられている EBS ボリュームの最大数は、in-tree および CSI ボリュームについて別々にカウントされるため、各タイプの EBS ボリュームを最大 39 個使用できます。
in-tree ボリュームプラグインでは不可能な追加のストレージオプション (ボリュームスナップショットなど) へのアクセスに関する詳細は、AWS Elastic Block Store CSI Driver Operator を参照してください。
4.1.5. KMS キーを使用した AWS 上のコンテナー永続ボリュームの暗号化
AWS でコンテナー永続ボリュームを暗号化するための KMS キーを定義すると、AWS へのデプロイ時に明示的なコンプライアンスおよびセキュリティーのガイドラインがある場合に役立ちます。
前提条件
- 基盤となるインフラストラクチャーには、ストレージが含まれている必要があります。
- AWS で顧客 KMS キーを作成する必要があります。
手順
ストレージクラスを作成します。
$ cat << EOF | oc create -f - apiVersion: storage.k8s.io/v1 kind: StorageClass metadata: name: <storage-class-name> 1 parameters: fsType: ext4 2 encrypted: "true" kmsKeyId: keyvalue 3 provisioner: ebs.csi.aws.com reclaimPolicy: Delete volumeBindingMode: WaitForFirstConsumer EOF
- 1
- ストレージクラスの名前を指定します。
- 2
- プロビジョニングされたボリューム上に作成されるファイルシステム。
- 3
- コンテナー永続ボリュームを暗号化するときに使用するキーの完全な Amazon リソースネーム (ARN) を指定します。キーを指定せず、
encrypted
フィールドがtrue
に設定されていると、デフォルトの KMS キーが使用されます。AWS ドキュメントの Finding the key ID and key ARN on AWS の検索を参照してください。
KMS キーを指定するストレージクラスで永続ボリューム要求 (PVC) を作成します。
$ cat << EOF | oc create -f - apiVersion: v1 kind: PersistentVolumeClaim metadata: name: mypvc spec: accessModes: - ReadWriteOnce volumeMode: Filesystem storageClassName: <storage-class-name> resources: requests: storage: 1Gi EOF
PVC を使用するワークロードコンテナーを作成します。
$ cat << EOF | oc create -f - kind: Pod metadata: name: mypod spec: containers: - name: httpd image: quay.io/centos7/httpd-24-centos7 ports: - containerPort: 80 volumeMounts: - mountPath: /mnt/storage name: data volumes: - name: data persistentVolumeClaim: claimName: mypvc EOF
4.1.6. 関連情報
- in-tree ボリュームプラグインでは不可能なボリュームスナップショットなどの追加のストレージオプションへのアクセスの詳細は、AWS Elastic Block Store CSI Driver Operator を参照してください。