2.3. Red Hat OpenShift Service on AWS のサービス定義

このドキュメントでは、Red Hat OpenShift Service on AWS (ROSA) マネージドサービスのサービス定義を説明します。

2.3.1. アカウント管理

このセクションでは、Red Hat OpenShift Service on AWS アカウント管理のサービス定義を説明します。

2.3.1.1. 請求

Red Hat OpenShift Service on AWS の請求は、サービス (ロードバランサー、ストレージ、EC2 インスタンス、他のコンポーネントなど)、および OpenShift サービスの Red Hat サブスクリプションで使用される AWS コンポーネントの使用状況に基づいて Amazon Web Services (AWS) で行われます。

追加の Red Hat ソフトウェアは別途購入する必要があります。

2.3.1.2. クラスターのセルフサービス

お客様はクラスターをセルフサービスで利用できます。これには以下が含まれますが、これらに限定されません。

  • クラスターの作成
  • クラスターの削除
  • アイデンティティープロバイダーの追加または削除
  • 権限が昇格したグループからのユーザーの追加または削除
  • クラスターのプライバシーの設定
  • マシンプールの追加または削除、および自動スケーリングの設定
  • アップグレードポリシーの定義

これらのセルフサービスタスクは、Red Hat OpenShift Service on AWS (ROSA) CLI (rosa) を使用して実行できます。

2.3.1.3. インスタンスタイプ

アベイラビリティゾーンが 1 つのクラスターには、1 つのアベイラビリティゾーンにデプロイされた 3 つ以上のコントロールプレーンノード、2 つ以上のインフラストラクチャーノード、および 2 つ以上のワーカーノードが必要です。

複数のアベイラビリティゾーンクラスターには、少なくとも 3 つのコントロールプレーンノード、3 つのインフラストラクチャーノード、および 3 つのワーカーノードが必要です。追加のノードを購入する場合は、ノードの適切な配分を維持できるように、3 の倍数単位で購入する必要があります。

すべての Red Hat OpenShift Service on AWS クラスターは、最大 180 ワーカーノードをサポートします。

コントロールプレーンおよびインフラストラクチャーノードは Red Hat によりデプロイされ、管理されます。クラウドプロバイダーコンソールを使用して基礎となるインフラストラクチャーをシャットダウンすることはサポートされておらず、データが失われる可能性があります。etcd および API 関連のワークロードを処理する 3 つ以上のコントロールプレーンノードが使用されます。メトリック、ルーティング、Web コンソール、および他のワークロードを処理するインフラストラクチャーノードが少なくとも 2 つあります。コントロールノードとインフラストラクチャーノードでワークロードを実行しないでください。実行する予定のワークロードはすべて、ワーカーノードにデプロイする必要があります。ワーカーノードにデプロイする必要がある Red Hat ワークロードの詳細は、以下の Red Hat Operator サポートセクションを参照してください。

注記

約 1 vCPU コアおよび 1 GiB のメモリーが各ワーカーノードで予約され、割り当て可能なリソースから削除されます。このリソースの予約は、基礎となるプラットフォームに必要なプロセスを実行するのに必要です。これらのプロセスには、udev、kubelet、コンテナーランタイムなどのシステムデーモンが含まれます。予約されるリソースは、カーネル予約も占めます。

監査ログの集計、メトリックコレクション、DNS、イメージレジストリー、SDN などの OpenShift Container Platform コアシステムは、追加の割り当て可能なリソースを使用し、クラスターの安定性および保守性を確保できる可能性があります。消費される追加リソースは、使用方法によって異なる場合があります。

詳細は、Kubernetes のドキュメント を参照してください。

2.3.1.4. AWS インスタンスタイプ

Red Hat OpenShift Service on AWS は、次のワーカーノードインスタンスのタイプとサイズを提供します。

例2.1 一般的用途

  • m5.metal (96† vCPU、384 GiB)
  • m5.xlarge (4 vCPU、16 GiB)
  • m5.2xlarge (8 vCPU、32 GiB)
  • m5.4xlarge (16 vCPU、64 GiB)
  • m5.8xlarge (32 vCPU、128 GiB)
  • m5.12xlarge (48 vCPU、192 GiB)
  • m5.16xlarge (64 vCPU、256 GiB)
  • m5.24xlarge (96 vCPU、384 GiB)
  • m5a.xlarge (4 vCPU、16 GiB)
  • m5a.2xlarge (8 vCPU、32 GiB)
  • m5a.4xlarge (16 vCPU、64 GiB)
  • m5a.8xlarge (32 vCPU、128 GiB)
  • m5a.12xlarge (48 vCPU、192 GiB)
  • m5a.16xlarge (64 vCPU、256 GiB)
  • m5a.24xlarge (96 vCPU、384 GiB)
  • m5dn.metal (96 vCPU、384 GiB)
  • m5zn.metal (48 vCPU、192 GiB)
  • m5d.metal (96† vCPU、384 GiB)
  • m5n.metal (96 vCPU、384 GiB)
  • m6a.metal (192 vCPU、768 GiB)
  • m6a.xlarge (4 vCPU、16 GiB)
  • m6a.2xlarge (8 vCPU、32 GiB)
  • m6a.4xlarge (16 vCPU、64 GiB)
  • m6a.8xlarge (32 vCPU、128 GiB)
  • m6a.12xlarge (48 vCPU、192 GiB)
  • m6a.16xlarge (64 vCPU、256 GiB)
  • m6a.24xlarge (96 vCPU、384 GiB)
  • m6a.32xlarge (128 vCPU、512 GiB)
  • m6a.48xlarge (192 vCPU、768 GiB)
  • m6i.metal (128 vCPU、512 GiB)
  • m6i.xlarge (4 vCPU、16 GiB)
  • m6i.2xlarge (8 vCPU、32 GiB)
  • m6i.4xlarge (16 vCPU、64 GiB)
  • m6i.8xlarge (32 vCPU、128 GiB)
  • m6i.12xlarge (48 vCPU、192 GiB)
  • m6i.16xlarge (64 vCPU、256 GiB)
  • m6i.24xlarge (96 vCPU、384 GiB)
  • m6i.32xlarge (128 vCPU、512 GiB)
  • m6id.xlarge (4 vCPU、16 GiB)
  • m6id.2xlarge (8 vCPU、32 GiB)
  • m6id.4xlarge (16 vCPU、64 GiB)
  • m6id.8xlarge (32 vCPU、128 GiB)
  • m6id.12xlarge (48 vCPU、192 GiB)
  • m6id.16xlarge (64 vCPU、256 GiB)
  • m6id.24xlarge (96 vCPU、384 GiB)
  • m6id.32xlarge (128 vCPU、512 GiB)
  • m6id.metal (128 vCPU、512 GiB)
  • m6idn.xlarge (4 vCPU、16 GiB)
  • m6idn.2xlarge (8 vCPU、32 GiB)
  • m6idn.4xlarge (16 vCPU、64 GiB)
  • m6idn.8xlarge (32 vCPU、128 GiB)
  • m6idn.12xlarge (48 vCPU、192 GiB)
  • m6idn.16xlarge (64 vCPU、256 GiB)
  • m6idn.24xlarge (96 vCPU、384 GiB)
  • m6idn.32xlarge (128 vCPU、512 GiB)
  • m6in.xlarge (4 vCPU、16 GiB)
  • m6in.2xlarge (8 vCPU、32 GiB)
  • m6in.4xlarge (16 vCPU、64 GiB)
  • m6in.8xlarge (32 vCPU、128 GiB)
  • m6in.12xlarge (48 vCPU、192 GiB)
  • m6in.16xlarge (64 vCPU、256 GiB)
  • m6in.24xlarge (96 vCPU、384 GiB)
  • m6in.32xlarge (128 vCPU、512 GiB)
  • m7a.xlarge (4 vCPU、16 GiB)
  • m7a.2xlarge (8 vCPU、32 GiB)
  • m7a.4xlarge (16 vCPU、64 GiB)
  • m7a.8xlarge (32 vCPU、128 GiB)
  • m7a.12xlarge (48 vCPU、192 GiB)
  • m7a.16xlarge (64 vCPU、256 GiB)
  • m7a.24xlarge (96 vCPU、384 GiB)
  • m7a.32xlarge (128 vCPU、512 GiB)
  • m7a.48xlarge (192 vCPU、768 GiB)
  • m7a.metal-48xl (192 vCPU、768 GiB)
  • m7i-flex.2xlarge (8 vCPU、32 GiB)
  • m7i-flex.4xlarge (16 vCPU、64 GiB)
  • m7i-flex.8xlarge (32 vCPU、128 GiB)
  • m7i-flex.xlarge (4 vCPU、16 GiB)
  • m7i.xlarge (4 vCPU、16 GiB)
  • m7i.2xlarge (8 vCPU、32 GiB)
  • m7i.4xlarge (16 vCPU、64 GiB)
  • m7i.8xlarge (32 vCPU、128 GiB)
  • m7i.12xlarge (48 vCPU、192 GiB)
  • m7i.16xlarge (64 vCPU、256 GiB)
  • m7i.24xlarge (96 vCPU、384 GiB)
  • m7i.48xlarge (192 vCPU、768 GiB)
  • m7i.metal-24xl (96 vCPU、384 GiB)
  • m7i.metal-48xl (192 vCPU、768 GiB)

† これらのインスタンスタイプは、48 個の物理コア上で 96 個の論理プロセッサーを提供します。これらは、2 つの物理 Intel ソケットを備えた単一サーバー上で実行します。

例2.2 バースト可能な汎用目的

  • t3.xlarge (4 vCPU、16 GiB)
  • t3.2xlarge (8 vCPU、32 GiB)
  • t3a.xlarge (4 vCPU、16 GiB)
  • t3a.2xlarge (8 vCPU、32 GiB)

例2.3 メモリー集約型

  • x1.16xlarge (64 vCPU、976 GiB)
  • x1.32xlarge (128 vCPU、1,952 GiB)
  • x1e.xlarge (4 vCPU、122 GiB)
  • x1e.2xlarge (8 vCPU、244 GiB)
  • x1e.4xlarge (16 vCPU、488 GiB)
  • x1e.8xlarge (32 vCPU、976 GiB)
  • x1e.16xlarge (64 vCPU、1,952 GiB)
  • x1e.32xlarge (128 vCPU、3,904 GiB)
  • x2idn.16xlarge (64 vCPU、1,024 GiB)
  • x2idn.24xlarge (96 vCPU、1,536 GiB)
  • x2idn.32xlarge (128 vCPU、2,048 GiB)
  • x2iedn.xlarge (4 vCPU、128 GiB)
  • x2iedn.2xlarge (8 vCPU、256 GiB)
  • x2iedn.4xlarge (16 vCPU、512 GiB)
  • x2iedn.8xlarge (32 vCPU、1,024 GiB)
  • x2iedn.16xlarge (64 vCPU、2,048 GiB)
  • x2iedn.24xlarge (96 vCPU、3,072 GiB)
  • x2iedn.32xlarge (128 vCPU、4,096 GiB)
  • x2iezn.metal (48 vCPU、1,536 GiB)
  • x2iezn.2xlarge (8 vCPU、256 GiB)
  • x2iezn.4xlarge (16vCPU、512 GiB)
  • x2iezn.6xlarge (24vCPU、768 GiB)
  • x2iezn.8xlarge (32vCPU、1,024 GiB)
  • x2iezn.12xlarge (48vCPU、1,536 GiB)
  • x2idn.metal (128vCPU、2,048 GiB)
  • x2iedn.metal (128vCPU、4,096 GiB)

例2.4 最適化されたメモリー

  • r4.xlarge (4 vCPU、30.5 GiB)
  • r4.2xlarge (8 vCPU、61 GiB)
  • r4.4xlarge (16 vCPU、122 GiB)
  • r4.8xlarge (32 vCPU、244 GiB)
  • r4.16xlarge (64 vCPU、488 GiB)
  • r5.metal (96† vCPU、768 GiB)
  • r5.xlarge (4 vCPU、32 GiB)
  • r5.2xlarge (8 vCPU、64 GiB)
  • r5.4xlarge (16 vCPU、128 GiB)
  • r5.8xlarge (32 vCPU、256 GiB)
  • r5.12xlarge (48 vCPU、384 GiB)
  • r5.16xlarge (64 vCPU、512 GiB)
  • r5.24xlarge (96 vCPU、768 GiB)
  • r5a.xlarge (4 vCPU、32 GiB)
  • r5a.2xlarge (8 vCPU、64 GiB)
  • r5a.4xlarge (16 vCPU、128 GiB)
  • r5a.8xlarge (32 vCPU、256 GiB)
  • r5a.12xlarge (48 vCPU、384 GiB)
  • r5a.16xlarge (64 vCPU、512 GiB)
  • r5a.24xlarge (96 vCPU、768 GiB)
  • r5ad.xlarge (4 vCPU、32 GiB)
  • r5ad.2xlarge (8 vCPU、64 GiB)
  • r5ad.4xlarge (16 vCPU、128 GiB)
  • r5ad.8xlarge (32 vCPU、256 GiB)
  • r5ad.12xlarge(48 vCPU、384 GiB)
  • r5ad.16xlarge (64 vCPU、512 GiB)
  • r5ad.24xlarge (96 vCPU、768 GiB)
  • r5b.metal (96 768 GiB)
  • r5b.xlarge (4 vCPU、32 GiB)
  • r5b.2xlarge (8 vCPU、364 GiB)
  • r5b.4xlarge (16 vCPU、3,128 GiB)
  • r5b.8xlarge (32 vCPU、3,256 GiB)
  • r5b.12xlarge (48 vCPU、3,384 GiB)
  • r5b.16xlarge (64 vCPU、3,512 GiB)
  • r5b.24xlarge (96 vCPU、3,768 GiB)
  • r5d.metal (96† vCPU、768 GiB)
  • r5d.xlarge (4 vCPU、32 GiB)
  • r5d.2xlarge (8 vCPU、64 GiB)
  • r5d.4xlarge (16 vCPU、128 GiB)
  • r5d.8xlarge (32 vCPU、256 GiB)
  • r5d.12xlarge (48 vCPU、384 GiB)
  • r5d.16xlarge (64 vCPU、512 GiB)
  • r5d.24xlarge (96 vCPU、768 GiB)
  • r5n.metal (96 vCPU、768 GiB)
  • r5n.xlarge (4 vCPU、32 GiB)
  • r5n.2xlarge (8 vCPU、64 GiB)
  • r5n.4xlarge (16 vCPU、128 GiB)
  • r5n.8xlarge (32 vCPU、256 GiB)
  • r5n.12xlarge (48 vCPU、384 GiB)
  • r5n.16xlarge (64 vCPU、512 GiB)
  • r5n.24xlarge (96 vCPU、768 GiB)
  • r5dn.metal (96 vCPU、768 GiB)
  • r5dn.xlarge (4 vCPU、32 GiB)
  • r5dn.2xlarge (8 vCPU、64 GiB)
  • r5dn.4xlarge (16 vCPU、128 GiB)
  • r5dn.8xlarge (32 vCPU、256 GiB)
  • r5dn.12xlarge(48 vCPU、384 GiB)
  • r5dn.16xlarge (64 vCPU、512 GiB)
  • r5dn.24xlarge (96 vCPU、768 GiB)
  • r6a.xlarge (4 vCPU、32 GiB)
  • r6a.2xlarge (8 vCPU、64 GiB)
  • r6a.4xlarge (16 vCPU、128 GiB)
  • r6a.8xlarge (32 vCPU、256 GiB)
  • r6a.12xlarge (48 vCPU、384 GiB)
  • r6a.16xlarge (64 vCPU、512 GiB)
  • r6a.24xlarge (96 vCPU、768 GiB)
  • r6a.32xlarge (128 vCPU、1,024 GiB)
  • r6a.48xlarge (192 vCPU、1,536 GiB)
  • r6i.metal (128 vCPU、1,024 GiB)
  • r6i.xlarge (4 vCPU、32 GiB)
  • r6i.2xlarge (8 vCPU、64 GiB)
  • r6i.4xlarge (16 vCPU、128 GiB)
  • r6i.8xlarge (32 vCPU、256 GiB)
  • r6i.12xlarge (48 vCPU、384 GiB)
  • r6i.16xlarge (64 vCPU、512 GiB)
  • r6i.24xlarge (96 vCPU、768 GiB)
  • r6i.32xlarge (128 vCPU、1,024 GiB)
  • r6id.metal (128 vCPU, 1,024 GiB)
  • r6id.xlarge (4 vCPU、32 GiB)
  • r6id.2xlarge (8 vCPU、64 GiB)
  • r6id.4xlarge (16 vCPU、128 GiB)
  • r6id.8xlarge (32 vCPU、256 GiB)
  • r6id.12xlarge (48 vCPU、384 GiB)
  • r6id.16xlarge (64 vCPU、512 GiB)
  • r6id.24xlarge (96 vCPU、768 GiB)
  • r6id.32xlarge (128 vCPU、1,024 GiB)
  • r6idn.12xlarge (48 vCPU、384 GiB)
  • r6idn.16xlarge (64 vCPU、512 GiB)
  • r6idn.24xlarge (96 vCPU、768 GiB)
  • r6idn.2xlarge (8 vCPU、64 GiB)
  • r6idn.32xlarge (128 vCPU、1,024 GiB)
  • r6idn.4xlarge (16 vCPU、128 GiB)
  • r6idn.8xlarge (32 vCPU、256 GiB)
  • r6idn.xlarge (4 vCPU、32 GiB)
  • r6in.12xlarge (48 vCPU、384 GiB)
  • r6in.16xlarge (64 vCPU、512 GiB)
  • r6in.24xlarge (96 vCPU、768 GiB)
  • r6in.2xlarge (8 vCPU、64 GiB)
  • r6in.32xlarge (128 vCPU、1,024 GiB)
  • r6in.4xlarge (16 vCPU、128 GiB)
  • r6in.8xlarge (32 vCPU、256 GiB)
  • r6in.xlarge (4 vCPU、32 GiB)
  • r7iz.xlarge (4 vCPU、32 GiB)
  • r7iz.2xlarge (8 vCPU、64 GiB)
  • r7iz.4xlarge (16 vCPU、128 GiB)
  • r7iz.8xlarge (32 vCPU、256 GiB)
  • r7iz.12xlarge (48 vCPU、384 GiB)
  • r7iz.16xlarge (64 vCPU、512 GiB)
  • r7iz.32xlarge (128 vCPU、1024 GiB)
  • r7iz.metal-16xl (64 vCPU、512 GiB)
  • r7iz.metal-32xl (128 vCPU、1,024 GiB)
  • z1d.metal (48‡ vCPU、384 GiB)
  • z1d.xlarge (4 vCPU、32 GiB)
  • z1d.2xlarge (8 vCPU、64 GiB)
  • z1d.3xlarge (12 vCPU、96 GiB)
  • z1d.6xlarge (24 vCPU、192 GiB)
  • z1d.12xlarge (48 vCPU、384 GiB)

† これらのインスタンスタイプは、48 個の物理コア上で 96 個の論理プロセッサーを提供します。これらは、2 つの物理 Intel ソケットを備えた単一サーバー上で実行します。

‡ このインスタンスタイプは、24 個の物理コア上に 48 個の論理プロセッサーを提供します。

例2.5 高速コンピューティング

  • p3.2xlarge (8 vCPU、61 GiB)
  • p3.8xlarge (32 vCPU、244 GiB)
  • p3.16xlarge (64 vCPU、488 GiB)
  • p3dn.24xlarge (96 vCPU、768 GiB)
  • p4d.24xlarge (96 vCPU、1,152 GiB)
  • p4de.24xlarge (96 vCPU、1,152 GiB)
  • p5.48xlarge (192 vCPU、2,048 GiB)
  • g4dn.xlarge (4 vCPU、16 GiB)
  • g4dn.2xlarge (8 vCPU、32 GiB)
  • g4dn.4xlarge (16 vCPU、64 GiB)
  • g4dn.8xlarge (32 vCPU、128 GiB)
  • g4dn.12xlarge (48 vCPU、192 GiB)
  • g4dn.16xlarge (64 vCPU、256 GiB)
  • g4dn.metal (96 vCPU、384 GiB)
  • g5.xlarge (4 vCPU、16 GiB)
  • g5.2xlarge (8 vCPU、32 GiB)
  • g5.4xlarge (16 vCPU、64 GiB)
  • g5.8xlarge (32 vCPU、128 GiB)
  • g5.16xlarge (64 vCPU、256 GiB)
  • g5.12xlarge (48 vCPU、192 GiB)
  • g5.24xlarge (96 vCPU、384 GiB)
  • g5.48xlarge (192 vCPU、768 GiB)
  • dl1.24xlarge (96 vCPU、768 GiB)†

† Intel 固有で Nvidia で対応していません。

GPU インスタンスタイプソフトウェアスタックのサポートは AWS によって提供されます。AWS サービスクォータが必要な GPU インスタンスタイプに対応できることを確認します。

例2.6 最適化されたコンピュート

  • c5.metal (96 vCPU、192 GiB)
  • c5.xlarge (4 vCPU、8 GiB)
  • c5.2xlarge (8 vCPU、16 GiB)
  • c5.4xlarge (16 vCPU、32 GiB)
  • c5.9xlarge (36 vCPU、72 GiB)
  • c5.12xlarge (48 vCPU、96 GiB)
  • c5.18xlarge (72 vCPU、144 GiB)
  • c5.24xlarge (96 vCPU、192 GiB)
  • c5d.metal (96 vCPU、192 GiB)
  • c5d.xlarge (4 vCPU、8 GiB)
  • c5d.2xlarge (8 vCPU、16 GiB)
  • c5d.4xlarge (16 vCPU、32 GiB)
  • c5d.9xlarge (36 vCPU、72 GiB)
  • c5d.12xlarge (48 vCPU、96 GiB)
  • c5d.18xlarge(72 vCPU、144 GiB)
  • c5d.24xlarge (96 vCPU、192 GiB)
  • c5a.xlarge (4 vCPU、8 GiB)
  • c5a.2xlarge (8 vCPU、16 GiB)
  • c5a.4xlarge (16 vCPU、32 GiB)
  • c5a.8xlarge (32 vCPU、64 GiB)
  • c5a.12xlarge (48 vCPU、96 GiB)
  • c5a.16xlarge (64 vCPU、128 GiB)
  • c5a.24xlarge (96 vCPU、192 GiB)
  • c5ad.xlarge (4 vCPU、8 GiB)
  • c5ad.2xlarge (8 vCPU、16 GiB)
  • c5ad.4xlarge (16 vCPU、32 GiB)
  • c5ad.8xlarge (32 vCPU、64 GiB)
  • c5ad.12xlarge (48 vCPU、96 GiB)
  • c5ad.16xlarge (64 vCPU、128 GiB)
  • c5ad.24xlarge (96 vCPU、192 GiB)
  • c5n.metal (72 vCPU、192 GiB)
  • c5n.xlarge (4 vCPU、10.5 GiB)
  • c5n.2xlarge (8 vCPU、21 GiB)
  • c5n.4xlarge (16 vCPU、42 GiB)
  • c5n.9xlarge (36 vCPU、96 GiB)
  • c5n.18xlarge (72 vCPU、192 GiB)
  • c6a.xlarge (4 vCPU、8 GiB)
  • c6a.2xlarge (8 vCPU、16 GiB)
  • c6a.4xlarge (16 vCPU、32 GiB)
  • c6a.8xlarge (32 vCPU、64 GiB)
  • c6a.12xlarge (48 vCPU、96 GiB)
  • c6a.16xlarge (64 vCPU、128 GiB)
  • c6a.24xlarge (96 vCPU、192 GiB)
  • c6a.32xlarge (128 vCPU、256 GiB)
  • c6a.48xlarge (192 vCPU、384 GiB)
  • c6i.metal (128 vCPU、256 GiB)
  • c6i.xlarge (4 vCPU、8 GiB)
  • c6i.2xlarge (8 vCPU、16 GiB)
  • c6i.4xlarge (16 vCPU、32 GiB)
  • c6i.8xlarge (32 vCPU、64 GiB)
  • c6i.12xlarge (48 vCPU、96 GiB)
  • c6i.16xlarge (64 vCPU、128 GiB)
  • c6i.24xlarge (96 vCPU、192 GiB)
  • c6i.32xlarge (128 vCPU、256 GiB)
  • c6id.metal (128 vCPU、256 GiB)
  • c6id.xlarge (4 vCPU、8 GiB)
  • c6id.2xlarge (8 vCPU、16 GiB)
  • c6id.4xlarge (16 vCPU、32 GiB)
  • c6id.8xlarge (32 vCPU、64 GiB)
  • c6id.12xlarge (48 vCPU、96 GiB)
  • c6id.16xlarge (64 vCPU、128 GiB)
  • c6id.24xlarge (96 vCPU、192 GiB)
  • c6id.32xlarge (128 vCPU、256 GiB)
  • c6in.12xlarge (48 vCPU、96 GiB)
  • c6in.16xlarge (64 vCPU、128 GiB)
  • c6in.24xlarge (96 vCPU、192 GiB)
  • c6in.2xlarge (8 vCPU、16 GiB)
  • c6in.32xlarge (128 vCPU、256 GiB)
  • c6in.4xlarge (16 vCPU、32 GiB)
  • c6in.8xlarge (32 vCPU、64 GiB)
  • c6in.xlarge (4 vCPU、8 GiB)
  • m5zn.12xlarge (48 vCPU、192 GiB)
  • m5zn.2xlarge (8 vCPU、32 GiB)
  • m5zn.3xlarge (16 vCPU、48 GiB)
  • m5zn.6xlarge (32 vCPU、96 GiB)
  • m5zn.xlarge (4 vCPU、16 GiB)

例2.7 最適化されたストレージ

  • c5ad.12xlarge (48 vCPU、96 GiB)
  • c5ad.16xlarge (64 vCPU、128 GiB)
  • c5ad.24xlarge (96 vCPU、192 GiB)
  • c5ad.2xlarge (8 vCPU、16 GiB)
  • c5ad.4xlarge (16 vCPU、32 GiB)
  • c5ad.8xlarge (32 vCPU、64 GiB)
  • c5ad.xlarge (4 vCPU、8 GiB)
  • i3.metal (72† vCPU、512 GiB)
  • i3.xlarge (4 vCPU、30.5 GiB)
  • i3.2xlarge (8 vCPU、61 GiB)
  • i3.4xlarge (16 vCPU、122 GiB)
  • i3.8xlarge (32 vCPU、244 GiB)
  • i3.16xlarge (64 vCPU、488 GiB)
  • i3en.metal (96 vCPU、768 GiB)
  • i3en.xlarge (4 vCPU、32 GiB)
  • i3en.2xlarge (8 vCPU、64 GiB)
  • i3en.3xlarge (12 vCPU、96 GiB)
  • i3en.6xlarge (24 vCPU、192 GiB)
  • i3en.12xlarge (48 vCPU、384 GiB)
  • i3en.24xlarge (96 vCPU、768 GiB)
  • i4i.xlarge (4 vCPU、32 GiB)
  • i4i.2xlarge (8 vCPU、64 GiB)
  • i4i.4xlarge (16 vCPU、128 GiB)
  • i4i.8xlarge (32 vCPU、256 GiB)
  • i4i.12xlarge (48 vCPU、384 GiB)
  • i4i.16xlarge (64 vCPU、512 GiB)
  • i4i.24xlarge (96 vCPU、768 GiB)
  • i4i.32xlarge (128 vCPU、1,024 GiB)
  • i4i.metal (128 vCPU、1,024 GiB)
  • m5ad.xlarge (4 vCPU、16 GiB)
  • m5ad.2xlarge (8 vCPU、32 GiB)
  • m5ad.4xlarge (16 vCPU、64 GiB)
  • m5ad.8xlarge (32 vCPU、128 GiB)
  • m5ad.12xlarge (48 vCPU、192 GiB)
  • m5ad.16xlarge (64 vCPU、256 GiB)
  • m5ad.24xlarge (96 vCPU、384 GiB)
  • m5d.xlarge (4 vCPU、16 GiB)
  • m5d.2xlarge (8 vCPU、32 GiB)
  • m5d.4xlarge (16 vCPU、64 GiB)
  • m5d.8xlarge (32 vCPU、28 GiB)
  • m5d.12xlarge (48 vCPU、192 GiB)
  • m5d.16xlarge (64 vCPU、256 GiB)
  • m5d.24xlarge (96 vCPU、384 GiB)

† このインスタンスタイプは、36 個の物理コア上に 72 個の論理プロセッサーを提供します。

注記

仮想インスタンスタイプは、.metal インスタンスタイプよりも速く初期化されます。

例2.8 高メモリー

  • u-3tb1.56xlarge (224 vCPU、3,072 GiB)
  • u-6tb1.56xlarge (224 vCPU、6,144 GiB)
  • u-6tb1.112xlarge (448 vCPU、6,144 GiB)
  • u-6tb1.metal (448 vCPU、6,144 GiB)
  • u-9tb1.112xlarge (448 vCPU、9,216 GiB)
  • u-9tb1.metal (448 vCPU、9,216 GiB)
  • u-12tb1.112xlarge (448 vCPU、12,288 GiB)
  • u-12tb1.metal (448 vCPU、12,288 GiB)
  • u-18tb1.metal (448 vCPU、18,432 GiB)
  • u-24tb1.metal (448 vCPU、24,576 GiB)
  • u-24tb1.112xlarge (448 vCPU、24,576 GiB)

例2.9 最適化されたネットワーク

  • c5n.xlarge (4 vCPU、10.5 GiB)
  • c5n.2xlarge (8 vCPU、21 GiB)
  • c5n.4xlarge (16 vCPU、42 GiB)
  • c5n.9xlarge (36 vCPU、96 GiB)
  • c5n.18xlarge (72 vCPU、192 GiB)
  • m5dn.xlarge (4 vCPU、16 GiB)
  • m5dn.2xlarge (8 vCPU、32 GiB)
  • m5dn.4xlarge (16 vCPU、64 GiB)
  • m5dn.8xlarge (32 vCPU、128 GiB)
  • m5dn.12xlarge (48 vCPU、192 GiB)
  • m5dn.16xlarge (64 vCPU、256 GiB)
  • m5dn.24xlarge (96 vCPU、384 GiB)
  • m5n.12xlarge (48 vCPU、192 GiB)
  • m5n.16xlarge (64 vCPU、256 GiB)
  • m5n.24xlarge (96 vCPU、384 GiB)
  • m5n.xlarge (4 vCPU、16 GiB)
  • m5n.2xlarge (8 vCPU、32 GiB)
  • m5n.4xlarge (16 vCPU、64 GiB)
  • m5n.8xlarge (32 vCPU、128 GiB)

2.3.1.5. リージョンおよびアベイラビリティーゾーン

現在、以下の AWS リージョンが Red Hat OpenShift 4 で利用可能であり、Red Hat OpenShift Service on AWS でサポートされています。

注記

OpenShift 4 のサポートの有無にかかわらず、中国リージョンはサポートされません。

注記

GovCloud (US) リージョンの場合は、Access request for Red Hat OpenShift Service on AWS (ROSA) FedRAMP を送信する必要があります。

GovCloud (US) リージョンは、ROSA Classic クラスターでのみサポートされます。

例2.10 AWS リージョン

  • us-east-1 (N. Virginia)
  • us-east-2 (Ohio)
  • us-west-1 (N. California)
  • us-west-2 (Oregon)
  • af-south-1 (Cape Town、AWS オプトインが必要)
  • ap-east-1 (Hong Kong、AWS オプトインが必要)
  • ap-south-2 (Hyderabad、AWS オプトインが必要)
  • ap-southeast-3 (Jakarta、AWS オプトインが必要)
  • ap-southeast-4 (Melbourne、AWS オプトインが必要)
  • ap-south-1 (Mumbai)
  • ap-northeast-3 (Osaka)
  • ap-northeast-2 (Seoul)
  • ap-southeast-1 (Singapore)
  • ap-southeast-2 (Sydney)
  • ap-northeast-1 (Tokyo)
  • ca-central-1 (Central Canada)
  • eu-central-1 (Frankfurt)
  • eu-west-1 (Ireland)
  • eu-west-2 (London)
  • eu-south-1 (Milan、AWS オプトインが必要)
  • eu-west-3 (Paris)
  • eu-south-2 (Spain)
  • eu-central-2 (Zurich、AWS オプトインが必要)
  • me-south-1 (Bahrain、AWS オプトインが必要)
  • me-central-1 (UAE、AWS オプトインが必要)
  • sa-east-1 (São Paulo)
  • us-gov-east-1 (AWS GovCloud - 米国東部)
  • us-gov-west-1 (AWS GovCloud - 米国西部)

複数のアベイラビリティーゾーンのクラスターは、少なくとも 3 つのアベイラビリティーゾーンのあるリージョンにのみデプロイできます。詳細は、AWS ドキュメントの Regions and Availability Zones セクションを参照してください。

新規 Red Hat OpenShift Service on AWS クラスターはそれぞれ、インストーラーで作成された Virtual Private Cloud (VPC)、または既存の Virtual Private Cloud (VPC) 内にインストールされます。オプションとして、単一アベイラビリティーゾーン (Single-AZ) または複数アベイラビリティーゾーン (Multi-AZ) にデプロイすることができます。これにより、クラスターレベルのネットワークおよびリソースの分離が行われ、VPN 接続や VPC ピアリングなどのクラウドプロバイダーの VPC 設定が有効になります。永続ボリューム (PV) は Amazon Elastic Block Storage (Amazon EBS) によってサポートされ、それらがプロビジョニングされるアベイラビリティーゾーンに固有のものとして機能します。永続ボリューム要求 (PVC) は、Pod がスケジュールできなくなる状況を防ぐために、関連付けられた Pod リソースが特定のアベイラビリティーゾーンに割り当てられるまでボリュームにバインドされません。アベイラビリティーゾーン固有のリソースは、同じアベイラビリティーゾーン内のリソースでのみ利用できます。

警告

リージョンおよびアベイラビリティーゾーンの単一または複数の選択は、クラスターのデプロイ後に変更できません。

2.3.1.6. Local Zones

Red Hat OpenShift Service on AWS は、顧客がレイテンシーの影響を受けやすいアプリケーションのワークロードを配置できる大都市集中型のアベイラビリティーゾーンである AWS Local Zones の使用をサポートします。Local Zones は、独自のインターネット接続を持つ AWS リージョンの拡張です。AWS Local Zones の詳細は、AWS ドキュメント How Local Zones work を参照してください。

AWS Local Zones を有効にして Local Zone をマシンプールに追加する手順は、マシンプール用のローカルゾーンの設定 を参照してください。

2.3.1.7. Service Level Agreement (SLA)

サービス自体の SLA は、Red Hat Enterprise Agreement Appendix 4 (Online Subscription Services) で定義されています。

2.3.1.8. 限定サポートステータス

クラスターが 限定サポート ステータスに移行すると、Red Hat はクラスターをプロアクティブに監視しなくなり、SLA は適用されなくなり、SLA に対して要求されたクレジットは拒否されます。製品サポートがなくなったという意味ではありません。場合によっては、違反要因を修正すると、クラスターが完全にサポートされた状態に戻ることがあります。ただし、それ以外の場合は、クラスターを削除して再作成する必要があります。

クラスターは、次のシナリオなど、さまざまな理由で限定サポートステータスに移行する場合があります。

サポート終了日までにクラスターをサポートされるバージョンにアップグレードしない場合

Red Hat は、サポート終了日以降のバージョンについて、ランタイムまたは SLA を保証しません。継続的なサポートを受けるには、サポートが終了する前に、クラスターを、サポートされているバージョンにアップグレードしてください。有効期限が切れる前にクラスターをアップグレードしない場合、クラスターは、サポートされているバージョンにアップグレードされるまで、限定サポートステータスに移行します。

Red Hat は、サポートされていないバージョンからサポートされているバージョンにアップグレードするための商業的に合理的なサポートを提供します。ただし、サポートされるアップグレードパスが利用できなくなった場合は、新規クラスターを作成し、ワークロードを移行することが必要になることがあります。

ネイティブの Red Hat OpenShift Service on AWS コンポーネント、または Red Hat がインストールおよび管理するその他のコンポーネントを削除または置き換える場合
クラスター管理者パーミッションを使用した場合、Red Hat は、インフラストラクチャーサービス、サービスの可用性、またはデータ損失に影響を与えるアクションを含む、ユーザーまたは認可されたユーザーのアクションに対して責任を負いません。Red Hat がそのようなアクションを検出した場合、クラスターは限定サポートステータスに移行する可能性があります。Red Hat はステータスの変更を通知します。アクションを元に戻すか、サポートケースを作成して、クラスターの削除と再作成が必要になる可能性のある修復手順を検討する必要があります。

クラスターが限定サポートステータスに移行する可能性のある特定のアクションについて質問がある場合、またはさらに支援が必要な場合は、サポートチケットを作成します。

2.3.1.9. サポート

Red Hat OpenShift Service on AWS には Red Hat Premium サポートが含まれており、このサポートは Red Hat カスタマーポータル を使用して利用できます。

サポートの応答時間については、Red Hat OpenShift Service on AWS の SLA を参照してください。

AWS サポートは、AWS との既存のサポート契約に基づきます。

2.3.2. Logging

Red Hat OpenShift Service on AWS は、Amazon (AWS) CloudWatch へのオプションの統合ログ転送を提供します。

2.3.2.1. クラスター監査ロギング

クラスター監査ログは、インテグレーションが有効になっている場合に AWS CloudWatch 経由で利用できます。インテグレーションが有効でない場合は、サポートケースを作成して監査ログをリクエストできます。

2.3.2.2. アプリケーションロギング

STDOUT に送信されるアプリケーションログは Fluentd によって収集され、クラスターロギングスタックで AWS CloudWatch に転送されます (インストールされている場合)。

2.3.3. モニタリング

このセクションでは、Red Hat OpenShift Service on AWS モニタリングのサービス定義を説明します。

2.3.3.1. クラスターメトリック

Red Hat OpenShift Service on AWS クラスターには、CPU、メモリー、ネットワークベースのメトリクスを含むクラスターモニタリングの統合された Prometheus スタックが同梱されます。これは Web コンソールからアクセスできます。また、これらのメトリックは Red Hat OpenShift Service on AWS ユーザーによって提供される CPU またはメモリーメトリックをベースとする Horizontal Pod Autoscaling を許可します。

2.3.3.2. クラスターステータスの通知

Red Hat は、OpenShift Cluster Manager で利用可能なクラスターダッシュボードと、クラスターの初回デプロイで使用した連絡先、およびお客様が指定する追加の連絡先のメールアドレスに送信されるメール通知を使用して、Red Hat OpenShift Service on AWS クラスターの正常性およびステータスについて通信します。

2.3.4. ネットワーク

このセクションでは、Red Hat OpenShift Service on AWS ネットワークのサービス定義を説明します。

2.3.4.1. アプリケーションのカスタムドメイン

警告

Red Hat OpenShift Service on AWS 4.14 以降、Custom Domain Operator は非推奨になりました。Red Hat OpenShift Service on AWS 4.14 以降で Ingress を管理するには、Ingress Operator を使用します。Red Hat OpenShift Service on AWS 4.13 以前のバージョンでは機能に変更はありません。

ルートにカスタムホスト名を使用するには、正規名 (CNAME) レコードを作成して DNS プロバイダーを更新する必要があります。CNAME レコードでは、OpenShift の正規ルーターのホスト名をカスタムドメインにマップする必要があります。OpenShift の正規ルーターのホスト名は、ルートの作成後に Route Details ページに表示されます。または、ワイルドカード CNAME レコードを 1 度作成して、指定のホスト名のすべてのサブドメインをクラスターのルーターにルーティングできます。

2.3.4.2. ドメイン検証証明書

Red Hat OpenShift Service on AWS には、クラスターの内部サービスと外部サービスの両方に必要な TLS セキュリティー証明書が含まれます。外部ルートの場合は、各クラスターに提供され、インストールされる 2 つの別個の TLS ワイルドカード証明書があります。1 つは Web コンソールおよびルートのデフォルトホスト名用であり、もう 1 つは API エンドポイント用です。Let's Encrypt は証明書に使用される認証局です。内部の API エンドポイント などのクラスター内のルートでは、クラスターの組み込み認証局によって署名された TLS 証明書を使用し、TLS 証明書を信頼するためにすべての Pod で CA バンドルが利用可能である必要があります。

2.3.4.3. ビルドのカスタム認証局

Red Hat OpenShift Service on AWS は、イメージレジストリーからイメージをプルする際にビルドによって信頼されるカスタム認証局の使用をサポートします。

2.3.4.4. ロードバランサー

Red Hat OpenShift Service on AWS は、最大 5 つの異なるロードバランサーを使用します。

  • クラスターの内部にあり、内部のクラスター通信のトラフィックのバランスを取るために使用される内部コントロールプレーンのロードバランサー。
  • OpenShift および Kubernetes API へのアクセスに使用される外部コントロールプレーンのロードバランサー。このロードバランサーは OpenShift Cluster Manager で無効にできます。このロードバランサーが無効にされている場合、Red Hat は API DNS を内部コントロールプレーンのロードバランサーを参照するように再設定します。
  • Red Hat によるクラスター管理用に予約される Red Hat の外部コントロールプレーンのロードバランサー。アクセスは厳密に制御され、ホワイトリストに登録されている bastion ホストからのみ通信が可能です。
  • デフォルトのアプリケーションロードバランサーであるデフォルトの外部ルーター/ingress ロードバランサー (URL の apps で示される)。デフォルトのロードバランサーを OpenShift Cluster Manager で設定して、インターネット上で一般にアクセス可能にしたり、既存のプライベート接続でプライベートにのみアクセス可能にしたりできます。ロギング UI、メトリック API、レジストリーなどのクラスターサービスを含む、クラスターのすべてのアプリケーションルートは、このデフォルトのルーターロードバランサーで公開されます。
  • オプション: セカンダリーアプリケーションロードバランサーであるセカンダリールーター/ingress ロードバランサー (URL の apps2 で示される)。セカンダリーロードバランサーを OpenShift Cluster Manager で設定して、インターネット上で一般にアクセス可能にしたり、既存のプライベート接続でプライベートにのみアクセス可能にしたりできます。Label match がこのルーターロードバランサーに設定されている場合は、このラベルに一致するアプリケーションルートのみがこのルーターロードバランサーで公開されます。それ以外の場合は、すべてのアプリケーションルートがこのルーターロードバランサーで公開されます。
  • オプション: サービスのロードバランサー。サービスの非 HTTP/SNI トラフィックおよび非標準ポートを有効にします。これらのロードバランサーを Red Hat OpenShift Service on AWS で実行されているサービスにマップし、HTTP/SNI 以外のトラフィックや標準以外のポートの使用などの高度な ingress 機能を有効にできます。各 AWS アカウントには、各クラスター内で使用できる Classic Load Balancer の数を制限 するクォータがあります。

2.3.4.5. クラスター ingress

プロジェクト管理者は、IP 許可リストによる ingress の制御など、さまざまな目的でルートアノテーションを追加できます。

Ingress ポリシーは、ovs-networkpolicy プラグインを使用する NetworkPolicy オブジェクトを使用して変更することもできます。これにより、同じクラスターの Pod 間や同じ namespace にある Pod 間など、Ingress ネットワークポリシーを Pod レベルで完全に制御できます。

すべてのクラスター ingress トラフィックは定義されたロードバランサーを通過します。すべてのノードへの直接のアクセスは、クラウド設定によりブロックされます。

2.3.4.6. クラスター egress

EgressNetworkPolicy オブジェクトでの Pod egress トラフィックの制御は、Red Hat OpenShift Service on AWS での送信トラフィックを防ぐか、これを制限するために使用できます。

コントロールプレーンおよびインフラストラクチャーノードからの公開される送信トラフィックは、クラスターイメージのセキュリティーおよびクラスターのモニタリングを維持するために必要です。これには、0.0.0.0/0 ルートがインターネットゲートウェイにのみ属している必要があります。プライベート接続でこの範囲のルートをルーティングすることはできません。

OpenShift 4 クラスターは NAT ゲートウェイを使用して、クラスターからの公開される送信トラフィックのパブリック静的 IP を表示します。クラスターがデプロイされるそれぞれのアベイラビリティーゾーンは個別の NAT ゲートウェイを受信するため、最大 3 つの固有の静的 IP アドレスがクラスターの egress トラフィックについて存在する可能性があります。クラスター内に留まるトラフィックや、パブリックインターネットに送信されないトラフィックは NAT ゲートウェイを通過せず、トラフィックの送信元となるノードに属するソース IP アドレスを持ちます。ノード IP アドレスは動的であるため、お客様はプライベートリソースへのアクセス時に個々の IP アドレスをホワイトリストに入れることはできません。

お客様はクラスター上で Pod を実行し、外部サービスをクエリーすることで、パブリック静的 IP アドレスを判別できます。以下に例を示します。

$ oc run ip-lookup --image=busybox -i -t --restart=Never --rm -- /bin/sh -c "/bin/nslookup -type=a myip.opendns.com resolver1.opendns.com | grep -E 'Address: [0-9.]+'"

2.3.4.7. クラウドネットワーク設定

Red Hat OpenShift Service on AWS では、次のような AWS 管理のテクノロジーを使用してプライベートネットワーク接続を設定できます。

  • VPN 接続
  • VPC ピアリング
  • Transit Gateway
  • Direct Connect
重要

Red Hat のサイト信頼性エンジニアリング (SRE) チームは、プライベートネットワーク接続を監視しません。これらの接続の監視は、お客様の責任で行われます。

2.3.4.8. DNS 転送

プライベートクラウドネットワーク設定を持つ Red Hat OpenShift Service on AWS クラスターの場合、お客様はそのプライベート接続で利用可能な内部 DNS サーバーを指定でき、明示的に提供されるドメインについてこれをクエリーする必要があります。

2.3.4.9. ネットワークの検証

Red Hat OpenShift Service on AWS クラスターを既存の Virtual Private Cloud (VPC) にデプロイするとき、またはクラスターに新しいサブネットを持つ追加のマシンプールを作成するときに、ネットワーク検証チェックが自動的に実行します。このチェックによりネットワーク設定が検証され、エラーが強調表示されるため、デプロイメント前に設定の問題を解決できます。

ネットワーク検証チェックを手動で実行して、既存のクラスターの設定を検証することもできます。

関連情報

2.3.5. Storage

このセクションでは、Red Hat OpenShift Service on AWS ストレージのサービス定義を説明します。

2.3.5.1. 保存時に暗号化される (Encrypted-at-rest) OS およびノードストレージ

コントロールプレーン、インフラストラクチャー、およびワーカーノードは、保存時に暗号化された Amazon Elastic Block Store (Amazon EBS) ストレージを使用します。

2.3.5.2. 暗号化された保存時の PV

PV に使用される EBS ボリュームはデフォルトで保存時に暗号化されます。

2.3.5.3. ブロックストレージ (RWO)

永続ボリューム (PV) は、Read-Write-Once の Amazon Elastic Block Store (Amazon EBS) によってサポートされています。

PV は一度に 1 つのノードにのみ割り当てられ、それらがプロビジョニングされるアベイラビリティーゾーンに固有のものです。ただし、PV はそのアベイラビリティーゾーンの任意のノードに割り当てることができます。

各クラウドプロバイダーには、1 つのノードに割り当てることのできる PV の数について独自の制限があります。詳細は、AWS インスタンスタイプの制限 を参照してください。

2.3.5.4. 共有ストレージ (RWX)

AWS CSI ドライバーは、Red Hat OpenShift Service on AWS の RWX サポートを提供するのに使用できます。コミュニティー Operator は、設定を簡素化するために提供されます。詳細は、Amazon Elastic File Storage Setup for OpenShift Dedicated and Red Hat OpenShift Service on AWS を参照してください。

2.3.6. プラットフォーム

このセクションでは、Red Hat OpenShift Service on AWS (ROSA) プラットフォームのサービス定義を説明します。

2.3.6.1. クラスターバックアップポリシー

重要

Red Hat は、デフォルト構成である STS を使用する ROSA クラスターのバックアップ方法を提供していません。お客様がアプリケーションとアプリケーションデータのバックアップ計画を立てることが重要です。以下の表は、IAM ユーザー認証情報を使用して作成されたクラスターにのみ適用されます。

アプリケーションおよびアプリケーションデータのバックアップは Red Hat OpenShift Service on AWS サービスの一部として行われません。次の表に、クラスターバックアップポリシーの概要を示します。

コンポーネントスナップショットの頻度保持期間注記

完全なオブジェクトストアのバックアップ

毎日

7 日

これは、etcd などのすべての Kubernetes オブジェクトの完全バックアップです。このバックアップスケジュールでは、永続ボリューム (PV) がバックアップされていません。

週次

30 日

完全なオブジェクトストアのバックアップ

毎時

24 時間

これは、etcd などのすべての Kubernetes オブジェクトの完全バックアップです。このバックアップスケジュールでは、PV はバックアップされません。

ノードのルートボリューム

なし

該当なし

ノードは短期的なものと見なされます。ノードのルートボリュームには、何も保存できません。

2.3.6.2. 自動スケーリング

ノードの自動スケーリングは Red Hat OpenShift Service on AWS で利用できます。オートスケーラーオプションを設定して、クラスター内のマシンの数を自動的にスケーリングできます。

2.3.6.3. デーモンセット

Red Hat OpenShift Service on AWS でデーモンセットを作成し、実行できます。デーモンセットをワーカーノードでのみの実行に制限するには、以下の nodeSelector を使用します。

...
spec:
  nodeSelector:
    role: worker
...

2.3.6.4. 複数のアベイラビリティーゾーン

複数アベイラビリティーゾーンのクラスターでは、コントロールプレーンノードは複数のアベイラビリティーゾーンに分散され、各アベイラビリティーゾーンに 1 つ以上のワーカーノードが必要になります。

2.3.6.5. ノードラベル

カスタムノードラベルはノードの作成時に Red Hat によって作成され、現時点では Red Hat OpenShift Service on AWS クラスターで変更することはできません。ただし、カスタムラベルは新規マシンプールの作成時にサポートされます。

2.3.6.6. OpenShift のバージョン

Red Hat OpenShift Service on AWS はサービスとして実行され、最新の OpenShift Container Platform バージョンで最新の状態に維持されます。最新バージョンへのアップグレードのスケジューリング機能を利用できます。

2.3.6.7. Upgrades

アップグレードは、ROSA CLI、rosa、または OpenShift Cluster Manager を使用してスケジュールできます。

アップグレードポリシーおよび手順の詳細は、Red Hat OpenShift Service on AWS のライフサイクル を参照してください。

2.3.6.8. Windows Containers

現時点では、Windows コンテナーに対する Red Hat OpenShift のサポートは Red Hat OpenShift Service on AWS では利用できません。

2.3.6.9. コンテナーエンジン

Red Hat OpenShift Service on AWS は OpenShift 4 で実行し、唯一の利用可能なコンテナーエンジンとして CRI-O を使用します。

2.3.6.10. オペレーティングシステム

Red Hat OpenShift Service on AWS は OpenShift 4 で実行され、すべてのコントロールプレーンおよびワーカーノードのオペレーティングシステムとして Red Hat CoreOS を使用します。

2.3.6.11. Red Hat Operator のサポート

通常、Red Hat ワークロードは、Operator Hub を通じて利用できる Red Hat 提供の Operator を指します。Red Hat ワークロードは Red Hat SRE チームによって管理されないため、ワーカーノードにデプロイする必要があります。これらの Operator は、追加の Red Hat サブスクリプションが必要になる場合があり、追加のクラウドインフラストラクチャーコストが発生する場合があります。これらの Red Hat 提供の Operator の例は次のとおりです。

  • Red Hat Quay
  • Red Hat Advanced Cluster Management
  • Red Hat Advanced Cluster Security
  • Red Hat OpenShift Service Mesh
  • OpenShift Serverless
  • Red Hat OpenShift Logging
  • Red Hat OpenShift Pipelines

2.3.6.12. Kubernetes Operator のサポート

OperatorHub marketplace にリスト表示されるすべての Operator はインストールに利用できるはずです。これらの Operator はお客様のワークロードと見なされるため、Red Hat SRE の監視の対象外です。

2.3.7. セキュリティー

このセクションでは、Red Hat OpenShift Service on AWS セキュリティーのサービス定義を説明します。

2.3.7.1. 認証プロバイダー

クラスターの認証は、OpenShift Cluster Manager またはクラスター作成プロセスを使用するか、ROSA CLI rosa を使用して設定できます。ROSA はアイデンティティープロバイダーではないため、クラスターへのアクセスすべてが統合ソリューションの一部としてお客様によって管理される必要があります。同時にプロビジョニングされる複数のアイデンティティープロバイダーの使用がサポートされます。以下のアイデンティティープロバイダーがサポートされます。

  • GitHub または GitHub Enterprise
  • GitLab
  • Google
  • LDAP
  • OpenID Connect
  • htpasswd

2.3.7.2. 特権付きコンテナー

特権付きコンテナーは、cluster-admin ロールを持つユーザーが利用できます。特権付きコンテナーを cluster-admin として使用する場合、これは Red Hat Enterprise Agreement Appendix 4 (Online Subscription Services) の責任および除外事項に基づいて使用されます。

2.3.7.3. お客様管理者ユーザー

Red Hat OpenShift Service on AWS は、通常のユーザーに加えて、dedicated-admin と呼ばれる ROSA 固有のグループへのアクセスを提供します。dedicated-admin グループのメンバーであるクラスターのすべてのユーザーは、以下を実行できます。

  • クラスターでお客様が作成したすべてのプロジェクトへの管理者アクセス権を持ちます。
  • クラスターのリソースクォータと制限を管理できます。
  • NetworkPolicy オブジェクトを追加および管理できます。
  • スケジューラー情報を含む、クラスター内の特定のノードおよび PV に関する情報を表示できます。
  • クラスター上の予約された dedicated-admin プロジェクトにアクセスできます。これにより、昇格された権限を持つサービスアカウントの作成が可能になり、クラスター上のプロジェクトのデフォルトの制限とクォータを更新できるようになります。
  • OperatorHub から Operator をインストールし、すべての *.operators.coreos.com API グループのすべての動詞を実行できます。

2.3.7.4. クラスター管理ロール

Red Hat OpenShift Service on AWS の管理者には、組織のクラスターについて cluster-admin ロールへのデフォルトアクセスがあります。cluster-admin ロールを持つアカウントにログインしている場合、ユーザーのパーミッションは、特権付きセキュリティーコンテキストを実行するために拡大します。

2.3.7.5. プロジェクトのセルフサービス

デフォルトで、すべてのユーザーはプロジェクトを作成し、更新し、削除できます。これは、dedicated-admin グループのメンバーが認証されたユーザーから self-provisioner ロールを削除すると制限されます。

$ oc adm policy remove-cluster-role-from-group self-provisioner system:authenticated:oauth

以下を適用すると、制限を元に戻すことができます。

$ oc adm policy add-cluster-role-to-group self-provisioner system:authenticated:oauth

2.3.7.6. 規制コンプライアンス

最新のコンプライアンス情報は、「Red Hat OpenShift Service on AWS のプロセスおよびセキュリティーについて」を参照してください。

2.3.7.7. ネットワークセキュリティー

Red Hat OpenShift Service on AWS では、AWS は AWS Shield と呼ばれる標準の DDoS 保護をすべてのロードバランサーで提供します。これにより、Red Hat OpenShift Service on AWS に使用されるすべてのパブリック向けロードバランサーで最も一般的に使用されるレベル 3 および 4 攻撃に対し、95% の保護が提供されます。応答を受信するために haproxy ルーターに送信される HTTP 要求に 10 秒のタイムアウトが追加されるか、追加の保護を提供するために接続が切断されます。

2.3.7.8. etcd 暗号化

Red Hat OpenShift Service on AWS では、コントロールプレーンストレージがデフォルトで保存時に暗号化されます。これには etcd ボリュームの暗号化も含まれます。このストレージレベルの暗号化は、クラウドプロバイダーのストレージ層を介して提供されます。

etcd 暗号化を有効にして、キーではなく etcd のキーの値を暗号化することもできます。etcd 暗号化を有効にすると、以下の Kubernetes API サーバーおよび OpenShift API サーバーリソースが暗号化されます。

  • シークレット
  • 設定マップ
  • ルート
  • OAuth アクセストークン
  • OAuth 認証トークン

etcd 暗号化機能はデフォルトで有効にされず、これはクラスターのインストール時にのみ有効にできます。etcd 暗号化が有効にされている場合でも、コントロールプレーンノードにアクセスできるユーザーまたは cluster-admin 権限を持つユーザーは、etcd キーの値にアクセスできます。

重要

etcd のキー値の etcd 暗号化を有効にすると、約 20% のパフォーマンスのオーバーヘッドが発生します。このオーバーヘッドは、etcd ボリュームを暗号化するデフォルトのコントロールプレーンのストレージ暗号化に加えて、この 2 つ目の暗号化レイヤーの導入により生じます。Red Hat は、お客様のユースケースで特に etcd 暗号化が必要な場合にのみ有効にすることを推奨します。

2.3.8. 関連情報