第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 クラスター全体で共有できます。Persistent volume claim (PVC) はプロジェクトまたは namespace に固有のもので、ユーザーによって要求されます。KMS キーを定義して、AWS のコンテナー永続ボリュームを暗号化できます。デフォルトでは、Red Hat OpenShift Service on AWS バージョン 4.10 以降を使用して新たに作成されたクラスターは、gp3 ストレージと AWS EBS CSI ドライバー を使用します。
インフラストラクチャーにおけるストレージの高可用性は、基礎となるストレージのプロバイダーに委ねられています。
4.1.1. EBS ストレージクラスの作成
ストレージクラスを使用すると、ストレージのレベルや使用状況を区別し、記述することができます。ストレージクラスを定義することにより、ユーザーは動的にプロビジョニングされた永続ボリュームを取得できます。
4.1.2. 永続ボリューム要求 (PVC) の作成
前提条件
ストレージは、Red Hat OpenShift Service on AWS でボリュームとしてマウントする前に、基盤となるインフラストラクチャーに存在する必要があります。
手順
- Red Hat OpenShift Service on AWS コンソールで、Storage → Persistent Volume Claims をクリックします。
- 永続ボリューム要求の概要で、Create Persistent Volume Claim をクリックします。
表示されるページで必要なオプションを定義します。
- ドロップダウンメニューから以前に作成したストレージクラスを選択します。
- ストレージ要求の一意の名前を入力します。
- アクセスモードを選択します。この選択により、ストレージクレームの読み取りおよび書き込みアクセスが決定されます。
- ストレージ要求のサイズを定義します。
- Create をクリックして永続ボリューム要求 (PVC) を作成し、永続ボリュームを生成します。
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 ドライバー 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) を指定します。キーを指定しないが、
暗号化されたフィールドがtrueに設定されている場合、デフォルトの KMS キーが使用されます。AWS ドキュメントの Finding the key ID and key ARN on AWS の検索を参照してください。
KMS キーを指定するストレージクラスで persistent volume claim (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 EOFPVC を使用するワークロードコンテナーを作成します。
$ 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 ドライバー Operator を参照してください。