第2章 ポリシーおよびサービス定義
2.1. OpenShift Dedicated サービス定義
2.1.1. アカウント管理
2.1.1.1. 請求オプション
お客様は、OpenShift Dedicated (OSD) の年間サブスクリプションを購入するか、クラウドマーケットプレイスを通じてオンデマンドで利用するか選択できます。お客様は、Customer Cloud Subscription (CCS) と呼ばれる独自のクラウドインフラストラクチャーアカウントを使用するか、Red Hat が所有するクラウドプロバイダーアカウントにデプロイするか決定できます。以下の表は、請求に関する追加情報と、対応するサポート対象のデプロイメントオプションを示しています。
| OSD サブスクリプションタイプ | クラウドインフラストラクチャーアカウント | 請求の経由先 |
|---|---|---|
| Red Hat 経由、容量固定型の年間サブスクリプション | Red Hat クラウドアカウント | Red Hat 経由、OSD サブスクリプションとクラウドインフラストラクチャーの使用料 |
| お客様自身のクラウドアカウント | Red Hat 経由、OSD サブスクリプションの使用料 クラウドプロバイダー経由、クラウドインフラストラクチャーの使用料 | |
| Google Cloud Marketplace 経由、オンデマンドの使用量ベース | お客様自身の Google Cloud アカウント | Google Cloud 経由、クラウドインフラストラクチャーと Red Hat OSD サブスクリプションの使用料 |
| Red Hat Marketplace 経由、オンデマンドの使用量ベース | お客様自身のクラウドアカウント | Red Hat 経由、OSD サブスクリプションの使用料 クラウドプロバイダー経由、クラウドインフラストラクチャーの使用料 |
Customer Cloud Subscription (CSS) と呼ばれるお客様自身のクラウドインフラストラクチャーアカウントを使用する場合、お客様はクラウドインフラストラクチャーのコストを削減するために、Reserved Instance (RI) コンピュートインスタンスを事前に購入または提供する責任があります。
以下を含む追加のリソースを OpenShift Dedicated クラスター用に購入できます。
- 追加のノード (マシンプールの使用により異なるタイプおよびサイズになります)
- ミドルウェア (JBoss EAP、JBoss Fuse など): 特定のミドルウェアコンポーネントに基づく追加の価格
- 追加のストレージが 500 GB の増分 (標準のみ、100 GB を含む)
- 追加の 12 TiB ネットワーク I/O (標準のみ、12 TB が含まれる)
- サービスのロードバランサーは 4 つのバンドルで利用できます。HTTP/SNI 以外のトラフィックまたは非標準ポートを有効にします (標準のみ)。
2.1.1.2. クラスターのセルフサービス
必要なサブスクリプションを購入している場合は、OpenShift Cluster Manager からクラスターを作成、スケーリング、および削除できます。
Red Hat OpenShift Cluster Manager で利用可能なアクションは、クラスター内から直接実行することはできません。これは、すべてのアクションが自動的に元に戻されるなど、悪影響を与える可能性があるためです。
2.1.1.3. クラウドプロバイダー
OpenShift Dedicated は、以下のクラウドプロバイダーで OpenShift Container Platform クラスターを管理サービスとして提供します。
- Amazon Web Services (AWS)
- Google Cloud Platform (GCP)
2.1.1.4. インスタンスタイプ
単一アベイラビリティーゾーンのクラスターでは、単一のアベイラビリティーゾーンにデプロイされた Customer Cloud Subscription (CCS) クラスター用に最低でも 2 つのワーカーノードが必要です。標準クラスターには、最低でも 4 つのワーカーノードが必要です。これらの 4 つのワーカーノードはベースサブスクリプションに含まれます。
複数のアベイラビリティーゾーンのクラスターでは、Customer Cloud Subscription (CCS) クラスター用に少なくとも 3 つのワーカーノードが必要です。3 つの各アベイラビリティーゾーンに 1 つずつデプロイされます。標準クラスターに 9 つ以上のワーカーノードが必要です。これらの 9 個以上のワーカーノードはベースサブスクリプションに含まれます。適切なノードの分散を維持するために、追加のノードを 3 の倍数に購入する必要があります。
単一の OpenShift Dedicated マシンプール内のワーカーノードはすべて、同じタイプとサイズである必要があります。ただし、OpenShift Dedicated クラスター内の複数のマシンプールにわたってワーカーノードが存在する場合は、異なるタイプやサイズに指定できます。
コントロールプレーンとインフラストラクチャーノードも Red Hat から提供されます。etcd および API 関連のワークロードを処理する 3 つ以上のコントロールプレーンノードが使用されます。メトリック、ルーティング、Web コンソール、および他のワークロードを処理するインフラストラクチャーノードが少なくとも 2 つあります。コントロールプレーンノードとインフラストラクチャーノードでワークロードを実行しないでください。実行する予定のワークロードはすべて、ワーカーノードにデプロイする必要があります。ワーカーノードにデプロイする必要がある Red Hat ワークロードの詳細は、以下の Red Hat Operator サポートセクションを参照してください。
約 1 vCPU コアおよび 1 GiB のメモリーが各ワーカーノードで予約され、割り当て可能なリソースから削除されます。これは、基礎となるプラットフォームに必要なプロセス を実行する必要があります。これには、udev、kubelet、コンテナーランタイムなどのシステムデーモンや、カーネル予約のアカウントが含まれます。監査ログの集計、メトリックコレクション、DNS、イメージレジストリー、SDN などの OpenShift Container Platform コアシステムは、追加の割り当て可能なリソースを使用し、クラスターの安定性および保守性を確保できる可能性があります。消費される追加リソースは、使用方法によって異なる場合があります。
OpenShift Dedicated 4.11 以降、デフォルトの Pod ごとの PID 制限は 4096 です。この PID 制限を有効にする場合は、OpenShift Dedicated クラスターを 4.11 以降にアップグレードする必要があります。4.11 より前のバージョンを実行している OpenShift Dedicated クラスターでは、デフォルトの PID 制限として 1024 が使用されます。
OpenShift Dedicated クラスターでは、Pod ごとの PID 制限を設定することはできません。
2.1.1.5. Customer Cloud Subscription クラスターの AWS インスタンスタイプ
OpenShift Dedicated は以下のワーカーノードのインスタンスタイプおよび 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)
- 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.metal (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、128 GiB)
- m5d.12xlarge (48 vCPU、192 GiB)
- m5d.16xlarge (64 vCPU、256 GiB)
- m5d.24xlarge (96 vCPU、384 GiB)
- m5n.metal (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)
- m5n.12xlarge (48 vCPU、192 GiB)
- m5n.16xlarge (64 vCPU、256 GiB)
- m5n.24xlarge (96 vCPU、384 GiB)
- m5dn.metal (96 vCPU、384 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)
- m5zn.metal (48 vCPU、192 GiB)
- m5zn.xlarge (4 vCPU、16 GiB)
- m5zn.2xlarge (8 vCPU、32 GiB)
- m5zn.3xlarge (12 vCPU、48 GiB)
- m5zn.6xlarge (24 vCPU、96 GiB)
- m5zn.12xlarge (48 vCPU、192 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)
- 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)
- m7i-flex.xlarge (4 vCPU、16 GiB)
- m7i-flex.2xlarge (8 vCPU、32 GiB)
- m7i-flex.4xlarge (16 vCPU、64 GiB)
- m7i-flex.8xlarge (32 vCPU、128 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)
† これらのインスタンスタイプは、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、1952 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、1024 GiB)
- x2idn.24xlarge (96 vCPU、1536 GiB)
- x2idn.32xlarge (128 vCPU、2048 GiB)
- x2iedn.xlarge (4 vCPU、128 GiB)
- x2iedn.2xlarge (8 vCPU、256 GiB)
- x2iedn.4xlarge (16 vCPU、512 GiB)
- x2iedn.8xlarge (32 vCPU、1024 GiB)
- x2iedn.16xlarge (64 vCPU、2048 GiB)
- x2iedn.24xlarge (96 vCPU、3072 GiB)
- x2iedn.32xlarge (128 vCPU、4096 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)
- x2iezn.metal (48 vCPU、1,536 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)
- 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.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)
- 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)
- r7a.xlarge (4 vCPU、32 GiB)
- r7a.2xlarge (8 vCPU、64 GiB)
- r7a.4xlarge (16 vCPU、128 GiB)
- r7a.8xlarge (32 vCPU、256 GiB)
- r7a.12xlarge (48 vCPU、384 GiB)
- r7a.16xlarge (64 vCPU、512 GiB)
- r7a.24xlarge (96 vCPU、768 GiB)
- r7a.32xlarge (128 vCPU、1024 GiB)
- r7a.48xlarge (192 vCPU、1536 GiB)
- r7a.metal-48xl (192 vCPU、1536 GiB)
- r7i.xlarge (4 vCPU、32 GiB)
- r7i.2xlarge (8 vCPU、64 GiB)
- r7i.4xlarge (16 vCPU、128 GiB)
- r7i.8xlarge (32 vCPU、256 GiB)
- r7i.12xlarge (48 vCPU、384 GiB)
- r7i.16xlarge (64 vCPU、512 GiB)
- r7i.24xlarge (96 vCPU、768 GiB)
- r7i.metal-24xl (96 vCPU、768 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、1024 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)
- g4ad.xlarge (4 vCPU、16 GiB)
- g4ad.2xlarge (8 vCPU、32 GiB)
- g4ad.4xlarge (16 vCPU、64 GiB)
- g4ad.8xlarge (32 vCPU、128 GiB)
- g4ad.16xlarge (64 vCPU、256 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.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)
- c7a.xlarge (4 vCPU、8 GiB)
- c7a.2xlarge (8 vCPU、16 GiB)
- c7a.4xlarge (16 vCPU、32 GiB)
- c7a.8xlarge (32 vCPU、64 GiB)
- c7a.12xlarge (48 vCPU、96 GiB)
- c7a.16xlarge (64 vCPU、128 GiB)
- c7a.24xlarge (96 vCPU、192 GiB)
- c7a.32xlarge (128 vCPU、256 GiB)
- c7a.48xlarge (192 vCPU、384 GiB)
- c7a.metal-48xl (192 vCPU、384 GiB)
- c7i.xlarge (4 vCPU、8 GiB)
- c7i.2xlarge (8 vCPU、16 GiB)
- c7i.4xlarge (16 vCPU、32 GiB)
- c7i.8xlarge (32 vCPU、64 GiB)
- c7i.12xlarge (48 vCPU、96 GiB)
- c7i.16xlarge (64 vCPU、128 GiB)
- c7i.24xlarge (96 vCPU、192 GiB)
- c7i.48xlarge (192 vCPU、384 GiB)
- c7i.metal-24xl (96 vCPU、192 GiB)
- c7i.metal-48xl (192 vCPU、384 GiB)
- hpc6a.48xlarge (96 vCPU、384 GiB)
- hpc6id.32xlarge (64 vCPU、1024 GiB)
- hpc7a.12xlarge (24 vCPU、768 GiB)
- hpc7a.24xlarge (48 vCPU、768 GiB)
- hpc7a.48xlarge (96 vCPU、768 GiB)
- hpc7a.96xlarge (192 vCPU、768 GiB)
例2.7 最適化されたストレージ
- 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、1024 GiB)
- i4i.metal (128 vCPU、1024 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)
関連情報
2.1.1.6. 標準クラスターの AWS インスタンスタイプ
OpenShift Dedicated は以下のワーカーノードのタイプおよび AWS のサイズを提供します。
例2.9 一般的用途
- m5.xlarge (4 vCPU、16 GiB)
- m5.2xlarge (8 vCPU、32 GiB)
- m5.4xlarge (16 vCPU、64 GiB)
例2.10 メモリー最適化
- r5.xlarge (4 vCPU、32 GiB)
- r5.2xlarge (8 vCPU、64 GiB)
- r5.4xlarge (16 vCPU、128 GiB)
例2.11 コンピュート最適化
- c5.2xlarge (8 vCPU、16 GiB)
- c5.4xlarge (16 vCPU、32 GiB)
2.1.1.7. Google Cloud コンピュートタイプ
OpenShift Dedicated は、他のクラウドインスタンスタイプと同じ共通の CPU およびメモリーの容量を持つために選択される Google Cloud の以下のワーカーノードタイプおよびサイズを提供します。
e2、a2、a3 コンピュートタイプは、CCS でのみ使用できます。
例2.12 一般的用途
- custom-4-16384 (4 vCPU、16 GiB)
- custom-8-32768 (8 vCPU、32 GiB)
- custom-16-65536 (16 vCPU、64 GiB)
- custom-32-131072 (32 vCPU、128 GiB)
- custom-48-199608 (48 vCPU、192 GiB)
- custom-64-262144 (64 vCPU、256 GiB)
- custom-96-393216 (96 vCPU、384 GiB)
- e2-standard-4 (4 vCPU、16 GiB)
- n2-standard-4 (4 vCPU、16 GiB)
- e2-standard-8 (8 vCPU、32 GiB)
- n2-standard-8 (8 vCPU、32 GiB)
- e2-standard-16 (16 vCPU、64 GiB)
- n2-standard-16 (16 vCPU、64 GiB)
- e2-standard-32 (32 vCPU、128 GiB)
- n2-standard-32 (32 vCPU、128 GiB)
- n2-standard-48 (48 vCPU、192 GiB)
- n2-standard-64 (64 vCPU、256 GiB)
- n2-standard-80 (80 vCPU、320 GiB)
- n2-standard-96 (96 vCPU、384 GiB)
- n2-standard-128 (128 vCPU、512 GiB)
例2.13 メモリー最適化
- custom-4-32768-ext (4 vCPU、32 GiB)
- custom-8-65536-ext (8 vCPU、64 GiB)
- custom-16-131072-ext (16 vCPU、128 GiB)
- e2-highmem-4 (4 vCPU、32 GiB)
- e2-highmem-8 (8 vCPU、64 GiB)
- e2-highmem-16 (16 vCPU、128 GiB)
- n2-highmem-4 (4 vCPU、32 GiB)
- n2-highmem-8 (8 vCPU、64 GiB)
- n2-highmem-16 (16 vCPU、128 GiB)
- n2-highmem-32 (32 vCPU、256 GiB)
- n2-highmem-48 (48 vCPU、384 GiB)
- n2-highmem-64 (64 vCPU、512 GiB)
- n2-highmem-80 (80 vCPU、640 GiB)
- n2-highmem-96 (96 vCPU、768 GiB)
- n2-highmem-128 (128 vCPU、864 GiB)
例2.14 コンピュート最適化
- custom-8-16384 (8 vCPU、16 GiB)
- custom-16-32768 (16 vCPU、32 GiB)
- custom-36-73728 (36 vCPU、72 GiB)
- custom-48-98304 (48 vCPU、96 GiB)
- custom-72-147456 (72 vCPU、144 GiB)
- custom-96-196608 (96 vCPU、192 GiB)
- c2-standard-4 (4 vCPU、16 GiB)
- c2-standard-8 (8 vCPU、32 GiB)
- c2-standard-16 (16 vCPU、64 GiB)
- c2-standard-30 (30 vCPU、120 GiB)
- c2-standard-60 (60 vCPU、240 GiB)
- e2-highcpu-8 (8 vCPU、8 GiB)
- e2-highcpu-16 (16 vCPU、16 GiB)
- e2-highcpu-32 (32 vCPU、32 GiB)
- n2-highcpu-8 (8 vCPU、8 GiB)
- n2-highcpu-16 (16 vCPU、16 GiB)
- n2-highcpu-32 (32 vCPU、32 GiB)
- n2-highcpu-48 (48 vCPU、48 GiB)
- n2-highcpu-64 (64 vCPU、64 GiB)
- n2-highcpu-80 (80 vCPU、80 GiB)
- n2-highcpu-96 (96 vCPU、96 GiB)
例2.15 高速コンピューティング
- a2-highgpu-1g (12 vCPU、85 GiB)
- a2-highgpu-2g (24 vCPU、170 GiB)
- a2-highgpu-4g (48 vCPU、340 GiB)
- a2-highgpu-8g (96 vCPU、680 GiB)
- a2-megagpu-16g (96 vCPU、1.33 TiB)
- a2-ultragpu-1g (12 vCPU、170 GiB)
- a2-ultragpu-2g (24 vCPU、340 GiB)
- a2-ultragpu-4g (48 vCPU、680 GiB)
- a2-ultragpu-8g (96 vCPU、1360 GiB)
- a3-highgpu-1g (26 vCPU、234 GiB)
- a3-highgpu-2g (52 vCPU、468 GiB)
- a3-highgpu-4g (104 vCPU、936 GiB)
- a3-highgpu-8g (208 vCPU、1872 GiB)
- a3-megagpu-8g (208 vCPU、1872 GiB)
- a3-edgegpu-8g (208 vCPU、1872 GiB)
2.1.1.8. リージョンおよびアベイラビリティーゾーン
次のリージョンは OpenShift Container Platform 4 でサポートされており、OpenShift Dedicated でもサポートされています。
2.1.1.8.1. AWS のリージョンとアベイラビリティーゾーン
以下の AWS リージョンは OpenShift Container Platform 4 と OpenShift Dedicated でサポートされます。
- af-south-1 (Cape Town, AWS オプトインが必要)
- ap-east-1 (Hong Kong、AWS オプトインが必要)
- ap-northeast-1 (Tokyo)
- ap-northeast-2 (Seoul)
- ap-northeast-3 (Osaka)
- ap-south-1 (Mumbai)
- ap-south-2 (Hyderabad、AWS オプトインが必要)
- ap-southeast-1 (Singapore)
- ap-southeast-2 (Sydney)
- ap-southeast-3 (Jakarta、AWS オプトインが必要)
- ap-southeast-4 (Melbourne、AWS オプトインが必要)
- ca-central-1 (Central Canada)
- eu-central-1 (Frankfurt)
- eu-central-2 (Zurich、AWS オプトインが必要)
- eu-north-1 (Stockholm)
- eu-south-1 (Milan、AWS オプトインが必要)
- eu-south-2 (Spain、AWS オプトインが必要)
- eu-west-1 (Ireland)
- eu-west-2 (London)
- eu-west-3 (Paris)
- me-central-1 (UAE、AWS オプトインが必要)
- me-south-1 (Bahrain、AWS オプトインが必要)
- sa-east-1 (São Paulo)
- us-east-1 (N. Virginia)
- us-east-2 (Ohio)
- us-west-1 (N. California)
- us-west-2 (Oregon)
2.1.1.8.2. Google Cloud のリージョンとアベイラビリティーゾーン
以下の Google Cloud リージョンが現在サポートされています。
- asia-east1, Changhua County, Taiwan
- asia-east2, Hong Kong
- asia-northeast1, Tokyo, Japan
- asia-northeast2, Osaka, Japan
- asia-south1, Mumbai, India
- asia-south2, Delhi, India
- asia-southeast1, Jurong West, Singapore
- australia-southeast1, Sydney, Australia
- australia-southeast2, Melbourne, Australia
- europe-north1, Hamina, Finland
- europe-west1, St. Ghislain, Belgium
- europe-west2, London, England, UK
- europe-west3, Frankfurt, Germany
- europe-west4, Eemshaven, Netherlands
- europe-west6, Zürich, Switzerland
- europe-west8, Milan, Italy
- europe-west12, Turin, Italy
- europe-southwest1, Madrid, Spain
- northamerica-northeast1, Montréal, Québec, Canada
- southamerica-east1, Osasco (São Paulo), Brazil
- southamerica-west1, Santiago, Chile
- us-central1, Council Bluffs, Iowa, USA
- us-east1, Moncks Corner, South Carolina, USA
- us-east4, Ashburn, Northern Virginia, USA
- us-west1, The Dalles, Oregon, USA
- us-west2, Los Angeles, California, USA
- me-central1, Doha, Qatar
- me-central2, Dammam, Saudi Arabia
Multi-AZ クラスターは、3 つ以上のアベイラビリティーゾーンを持つリージョンにのみデプロイできます (AWS および Google Cloud を参照してください)。
新規 OpenShift Dedicated クラスターは、単一のリージョンの専用 Virtual Private Cloud (VPC) 内にインストールされます。また、単一アベイラビリティーゾーン (Single-AZ) または複数のアベイラビリティーゾーン (Multi-AZ) にデプロイするオプションを選択できます。これにより、クラスターレベルのネットワークおよびリソースの分離が行われ、VPN 接続や VPC ピアリングなどのクラウドプロバイダーの VPC 設定が有効になります。永続ボリュームはクラウドブロックストレージによってサポートされ、プロビジョニングされるアベイラビリティーゾーンに固有のものとなります。永続ボリュームは、Pod がスケジュール対象外にされないように、関連付けられた Pod リソースが特定のアベイラビリティーゾーンに割り当てられるまでボリュームにバインドされません。アベイラビリティーゾーン固有のリソースは、同じアベイラビリティーゾーン内のリソースでのみ利用できます。
リージョンおよび単一またはマルチアベイラビリティーゾーンの選択肢は、クラスターをデプロイした後で変更できません。
2.1.1.9. サービスレベルアグリーメント (SLA)
サービスの SLA は、Red Hat Enterprise Agreement Appendix 4 (Online Subscription Services) の Appendix 4 で定義されています。
2.1.1.10. 限定サポートステータス
クラスターが 限定サポート ステータスに移行すると、Red Hat はクラスターをプロアクティブに監視しなくなり、SLA は適用されなくなり、SLA に対して要求されたクレジットは拒否されます。製品サポートがなくなったという意味ではありません。場合によっては、違反要因を修正すると、クラスターが完全にサポートされた状態に戻ることがあります。ただし、それ以外の場合は、クラスターを削除して再作成する必要があります。
クラスターは、次のシナリオなど、さまざまな理由で限定サポートステータスに移行する場合があります。
- サポート終了日までにクラスターをサポートされるバージョンにアップグレードしない場合
Red Hat は、サポート終了日以降のバージョンについて、ランタイムまたは SLA を保証しません。継続的なサポートを受けるには、サポートが終了する前に、クラスターを、サポートされているバージョンにアップグレードしてください。有効期限が切れる前にクラスターをアップグレードしないと、クラスターは、サポートされているバージョンにアップグレードされるまで、限定サポートステータスに移行します。
Red Hat は、サポートされていないバージョンからサポートされているバージョンにアップグレードするために、商業的に合理的なサポートを提供します。ただし、サポートされるアップグレードパスが利用できなくなった場合は、新規クラスターを作成し、ワークロードを移行することが必要になることがあります。
- ネイティブの OpenShift Dedicated コンポーネント、または Red Hat によってインストールおよび管理されているその他のコンポーネントを削除または交換した場合
- クラスター管理者パーミッションを使用した場合、Red Hat は、インフラストラクチャーサービス、サービスの可用性、またはデータ損失に影響を与えるアクションを含む、ユーザーまたは認可されたユーザーのアクションに対して責任を負いません。Red Hat がそのようなアクションを検出した場合、クラスターは限定サポートステータスに移行する可能性があります。Red Hat はステータスの変更を通知します。アクションを元に戻すか、サポートケースを作成して、クラスターの削除と再作成が必要になる可能性のある修復手順を検討する必要があります。
クラスターが限定サポートステータスに移行する可能性のある特定のアクションについて質問がある場合、またはさらに支援が必要な場合は、サポートチケットを作成します。
2.1.1.11. サポート
OpenShift Dedicated には Red Hat Premium サポートが含まれており、これは Red Hat カスタマーポータル を使用してアクセスできます。
OpenShift Dedicated に含まれるサポート対象となる内容の 詳細 は、製品サポートの対象範囲 を参照してください。
サポートの応答時間は、OpenShift Dedicated の SLA を参照してください。
2.1.2. ロギング
OpenShift Dedicated は、Amazon CloudWatch (AWS 上) または Google Cloud Logging (GCP 上) への任意の統合ログ転送を提供します。
詳細は、About log collection and forwarding を参照してください。
2.1.2.1. クラスター監査ロギング
クラスター監査ログは、インテグレーションが有効になっている場合に、Amazon CloudWatch (AWS 上) または Google Cloud Logging (GCP 上) を通じて利用できます。インテグレーションが有効でない場合は、サポートケースを作成して監査ログをリクエストできます。監査ログのリクエストでは、日時の範囲が 21 日を超えないように指定する必要があります。監査ログをリクエストする際には、監査ログのサイズが 1 日あたり数 GB になることに注意してください。
2.1.2.2. アプリケーションロギング
STDOUT に送信されるアプリケーションログは、クラスターロギングスタックがインストールされている場合に、それを介して Amazon CloudWatch (AWS 上) または Google Cloud Logging (GCP 上) に転送されます。
2.1.3. モニタリング
2.1.3.1. クラスターメトリック
OpenShift Dedicated クラスターには、CPU、メモリー、ネットワークベースのメトリクスを含むクラスターモニタリングの統合された Prometheus/Grafana スタックが同梱されます。これは Web コンソールからアクセスでき、Grafana ダッシュボードを使用してクラスターレベルのステータスおよび容量/使用状況を表示することもできます。また、これらのメトリックは OpenShift Dedicated ユーザーによって提供される CPU またはメモリーメトリックをベースとする Horizontal Pod Autoscaling を許可します。
2.1.3.2. クラスターの通知
クラスター通知は、クラスターのステータス、健全性、またはパフォーマンスに関するメッセージです。
クラスター通知は、Red Hat Site Reliability Engineering (SRE) が管理対象クラスターの健全性をユーザーに通知する際に使用する主な方法です。SRE は、クラスター通知を使用して、クラスターの問題を解決または防止するためのアクションを実行するように促すこともあります。
クラスターの所有者と管理者は、クラスターの健全性とサポート対象の状態を維持するために、クラスター通知を定期的に確認して対処する必要があります。
クラスターの通知は、Red Hat Hybrid Cloud Console のクラスターの Cluster history タブで表示できます。デフォルトでは、クラスターの所有者のみがクラスター通知をメールで受信します。他のユーザーがクラスター通知メールを受信する必要がある場合は、各ユーザーをクラスターの通知連絡先として追加します。
2.1.4. ネットワーク
2.1.4.1. アプリケーションのカスタムドメイン
OpenShift Dedicated 4.14 以降、Custom Domain Operator は非推奨になりました。OpenShift Dedicated 4.14 以降で Ingress を管理するには、Ingress Operator を使用します。OpenShift Dedicated 4.13 以前のバージョンでは機能に変更はありません。
ルートにカスタムホスト名を使用するには、正規名 (CNAME) レコードを作成して DNS プロバイダーを更新する必要があります。CNAME レコードは、OpenShift の正規ルーターのホスト名をカスタムドメインにマッピングする必要があります。OpenShift の正規ルーターのホスト名は、ルートの作成後に Route Details ページに表示されます。または、ワイルドカード CNAME レコードを 1 度作成して、指定のホスト名のすべてのサブドメインをクラスターのルーターにルーティングできます。
2.1.4.2. クラスターサービスのカスタムドメイン
カスタムドメインおよびサブドメインは、プラットフォームサービスルート (API、Web コンソールルート、またはデフォルトのアプリケーションルート) では使用できません。
2.1.4.3. ドメイン検証証明書
OpenShift Dedicated には、クラスターの内部サービスと外部サービスの両方に必要な TLS セキュリティー証明書が含まれます。外部ルートの場合は、2 つの別個の TLS ワイルドカード証明書があり、各クラスターに提供され、これが各クラスターにインストールされます。1 つは Web コンソールとルートのデフォルトホスト名用、もう 1 つは API エンドポイント用です。Let’s Encrypt は証明書に使用される認証局です。たとえば、内部 API エンドポイント などのクラスター内のルートでは、クラスターの組み込み認証局によって署名された TLS 証明書を使用し、TLS 証明書を信頼するためにすべての Pod で CA バンドルが利用可能である必要があります。
2.1.4.4. ビルド用のカスタム認証局
OpenShift Dedicated は、イメージレジストリーからイメージをプルする際にビルドによって信頼されるカスタム認証局の使用をサポートします。
2.1.4.5. ロードバランサー
OpenShift Dedicated は、最大 5 つの異なるロードバランサーを使用します。
- クラスターの内部にあり、内部クラスター通信のトラフィックのバランスを取るために使用される内部コントロールプレーンのロードバランサー。
- OpenShift Container Platform および Kubernetes API へのアクセスに使用される外部コントロールプレーンのロードバランサー。このロードバランサーは、Red Hat OpenShift Cluster Manager で無効にできます。このロードバランサーが無効になると、Red Hat は API DNS を内部コントロールロードバランサーを参照するように再設定します。
- Red Hat によるクラスター管理用に予約される Red Hat の外部コントロールプレーンのロードバランサー。アクセスは厳密に制御され、許可リストの bastion ホストからの通信のみが可能です。
-
デフォルトのアプリケーションロードバランサーであるデフォルトの router/ingress ロードバランサー (URL の
appsで表される)。デフォルトのロードバランサーを OpenShift Cluster Manager で設定して、インターネット上で一般にアクセス可能にしたり、既存のプライベート接続でプライベートにのみアクセス可能にしたりできます。ロギング UI、メトリック API、レジストリーなどのクラスターサービスを含む、クラスターのすべてのアプリケーションルートは、このデフォルトのルーターロードバランサーで公開されます。 -
オプション: セカンダリーアプリケーションロードバランサーであるセカンダリールーター/ingress ロードバランサー (URL の
apps2で表される)。セカンダリーロードバランサーを OpenShift Cluster Manager で設定して、インターネット上で一般にアクセス可能にしたり、既存のプライベート接続でプライベートにのみアクセス可能にしたりできます。'Label match' がこのルーターロードバランサーに設定されている場合は、このラベルに一致するアプリケーションルートのみがこのルーターロードバランサーで公開されます。そうでない場合は、すべてのアプリケーションルートもこのルーターのロードバランサーで公開されます。 - オプション: OpenShift Dedicated で実行しているサービスにマップできるサービスのロードバランサー。HTTP/SNI 以外のトラフィックや標準以外のポートの使用などの高度な ingress 機能を有効にします。これらは、標準クラスター用に 4 のグループで購入したり、Customer Cloud Subscription (CCS) クラスターで課金せずにプロビジョニングできます。ただし、各 AWS アカウントには、各クラスター内で使用できる Classic Load Balancer の数を制限する クォータがあります。
2.1.4.6. ネットワーク使用量
標準の OpenShift Dedicated クラスターの場合、ネットワーク使用量は、インバウンド、VPC ピアリング、VPN、および AZ トラフィック間のデータ転送に基づいて測定されます。標準の OpenShift Dedicated ベースクラスターで、ネットワーク I/O の 12 TB が提供されます。追加のネットワーク I/O は、12 TB の増分で購入できます。CCS OpenShift Dedicated クラスターの場合、ネットワークの使用量は監視されず、クラウドプロバイダーによって直接請求されます。
2.1.4.7. クラスター ingress
プロジェクト管理者は、IP 許可リストによる ingress コントロールなど、さまざまな目的でルートアノテーションを追加できます。
Ingress ポリシーは、ovs-networkpolicy プラグインを使用する NetworkPolicy オブジェクトを使用して変更することもできます。これにより、同じクラスターの Pod 間や同じ namespace にある Pod 間など、Ingress ネットワークポリシーを Pod レベルで完全に制御できます。
すべてのクラスター Ingress トラフィックは定義されたロードバランサーを通過します。すべてのノードへの直接のアクセスは、クラウド設定によりブロックされます。
2.1.4.8. クラスター egress
EgressNetworkPolicy オブジェクトでの Pod egress トラフィックの制御は、OpenShift Dedicated での送信トラフィックを防ぐか、これを制限するために使用できます。
コントロールプレーンおよびインフラストラクチャーノードからのパブリック送信トラフィックは、クラスターイメージのセキュリティーおよびクラスターのモニタリングを維持するために必要です。これには、0.0.0.0/0 ルートがインターネットゲートウェイにのみ属している必要があります。プライベート接続でこの範囲をルーティングすることはできません。
OpenShift Dedicated クラスターは NAT ゲートウェイを使用して、クラスターから出るパブリック送信トラフィックのパブリック静的 IP を表示します。クラスターがデプロイされる各サブネットは、個別の NAT ゲートウェイを受信します。複数のアベイラビリティーゾーンで AWS にデプロイされるクラスターの場合は、最大 3 つの固有の静的 IP アドレスがクラスターの egress トラフィック用に存在できます。アベイラビリティーゾーントポロジーに関係なく、Google Cloud にデプロイされたクラスターの場合は、ワーカーノードの egress トラフィックに 1 つの静的 IP アドレスがあります。クラスター内に留まるトラフィックや、パブリックインターネットに送信されないトラフィックは 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.1.4.9. クラウドネットワーク設定
OpenShift Dedicated では、複数のクラウドプロバイダー管理テクノロジーを介したプライベートネットワーク接続の設定を可能にします。
- VPN 接続
- AWS VPC ピアリング
- AWS Transit Gateway
- AWS Direct Connect
- Google Cloud VPC Network ピアリング
- Google Cloud Classic VPN
- Google Cloud HA VPN
Red Hat SRE はプライベートネットワーク接続を監視しません。これらの接続の監視は、お客様の責任で行われます。
2.1.4.10. DNS 転送
プライベートクラウドネットワーク設定を持つ OpenShift Dedicated クラスターの場合、お客様は、明示的に提供されたドメインを照会する必要がある、そのプライベート接続で使用可能な内部 DNS サーバーを指定できます。
2.1.4.11. ネットワークの検証
OpenShift Dedicated クラスターを既存の Virtual Private Cloud (VPC) にデプロイするとき、またはクラスターに新しいサブネットを持つ追加のマシンプールを作成するときに、ネットワーク検証チェックが自動的に実行します。このチェックによりネットワーク設定が検証され、エラーが強調表示されるため、デプロイメント前に設定の問題を解決できます。
ネットワーク検証チェックを手動で実行して、既存のクラスターの設定を検証することもできます。
関連情報
- ネットワーク検証チェックの詳細は、ネットワーク検証 を参照してください。
2.1.5. ストレージ
2.1.5.1. 暗号化された保存時の OS /ノードストレージ
コントロールプレーンノードは、encrypted-at-rest-EBS ストレージを使用します。
2.1.5.2. 暗号化された保存時の PV
永続ボリューム (PV) に使用される EBS ボリュームは、デフォルトで保存時に暗号化されます。
2.1.5.3. ブロックストレージ (RWO)
永続ボリューム (PV) は、ReadWriteOnce (RWO) アクセスモードを使用する AWS EBS および Google Cloud の永続ディスクブロックストレージによってサポートされます。標準の OpenShift Dedicated ベースクラスターでは、100 GB のブロックストレージは、アプリケーション要求に基づいて動的にプロビジョニングされ、再利用されます。追加の永続ストレージは 500 GB の増分で購入できます。
PV は一度に 1 つのノードにのみ割り当てられ、それらがプロビジョニングされるアベイラビリティーゾーンに固有のものですが、アベイラビリティーゾーンの任意のノードに割り当てることができます。
各クラウドプロバイダーには、1 つのノードに割り当てることのできる PV の数に独自の制限があります。詳細は、AWS インスタンスタイプの制限 または Google Cloud Platform カスタムマシンタイプ を参照してください。
2.1.6. プラットフォーム
2.1.6.1. クラスターバックアップポリシー
お客様がアプリケーションとアプリケーションデータのバックアップ計画を立てることが重要です。
アプリケーションおよびアプリケーションデータのバックアップは、OpenShift Dedicated サービスの一部ではありません。各 OpenShift Dedicated クラスターのすべての Kubernetes オブジェクトは、クラスターが回復不能になる場合に備えて迅速なリカバリーを可能にするためにバックアップされます。
バックアップは、クラスターと同じアカウントのセキュアなオブジェクトストレージ (Multi-AZ) バケットに保存されます。Red Hat Enterprise Linux CoreOS は OpenShift Container Platform クラスターによって完全に管理され、ステートフルなデータはノードのルートボリュームに保存されないため、ノードのルートボリュームはバックアップされません。
以下の表は、バックアップの頻度を示しています。
| コンポーネント | スナップショットの頻度 | 保持期間 | 注記 |
|---|---|---|---|
| 完全なオブジェクトストアのバックアップ | 日次 (0100 UTC) | 7 日 | これは、すべての Kubernetes オブジェクトの完全バックアップです。このバックアップスケジュールでは、永続ボリューム (PV) がバックアップされていません。 |
| 完全なオブジェクトストアのバックアップ | 週次 (月曜日: 0200 UTC) | 30 日 | これは、すべての Kubernetes オブジェクトの完全バックアップです。このバックアップスケジュールでは、PV はバックアップされません。 |
| 完全なオブジェクトストアのバックアップ | 毎時 (1 時間ごとに 17 分を経過した時点) | 24 時間 | これは、すべての Kubernetes オブジェクトの完全バックアップです。このバックアップスケジュールでは、PV はバックアップされません。 |
2.1.6.2. 自動スケーリング
ノードの自動スケーリングは OpenShift Dedicated で利用できます。クラスター上のノードの自動スケーリングの詳細は、About autoscaling nodes on a cluster を参照してください。
2.1.6.3. デーモンセット
お客様は OpenShift Dedicated で DaemonSet を作成し、実行できます。DaemonSets をワーカーノードでのみの実行に制限するには、以下の nodeSelector を使用します。
...
spec:
nodeSelector:
role: worker
...2.1.6.4. 複数のアベイラビリティーゾーン
複数アベイラビリティーゾーンのクラスターでは、コントロールノードは複数のアベイラビリティーゾーンに分散され、各アベイラビリティーゾーンに 3 つ以上のワーカーノードが必要です。
2.1.6.5. ノードラベル
カスタムノードラベルはノードの作成時に Red Hat によって作成され、現時点では OpenShift Dedicated クラスターで変更することはできません。
2.1.6.6. OpenShift バージョン
OpenShift Dedicated はサービスとして実行し、最新の OpenShift Container Platform バージョンで最新の状態に維持されます。
2.1.6.7. Upgrades
アップグレードポリシーおよび手順の詳細は、OpenShift Dedicated のライフサイクル を参照してください。
2.1.6.8. Windows コンテナー
Windows コンテナーは、現時点で OpenShift Dedicated では利用できません。
2.1.6.9. コンテナーエンジン
OpenShift Dedicated は OpenShift 4 で実行し、唯一の利用可能なコンテナーエンジンとして CRI-O を使用します。
2.1.6.10. オペレーティングシステム
OpenShift Dedicated は OpenShift 4 で実行し、すべてのコントロールプレーンおよびワーカーノードのオペレーティングシステムとして Red Hat Enterprise Linux CoreOS を使用します。
2.1.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.1.6.12. Kubernetes Operator のサポート
OperatorHub marketplace にリスト表示されるすべての Operator はインストールに利用できるはずです。Red Hat Operator を含む OperatorHub からインストールされる Operator は、OpenShift Dedicated サービスの一部として管理されている SRE ではありません。特定の Operator のサポート可能性の詳細は、Red Hat カスタマーポータル を参照してください。
2.1.7. セキュリティー
このセクションでは、OpenShift Dedicated セキュリティーのサービス定義を説明します。
2.1.7.1. 認証プロバイダー
クラスターの認証は、Red Hat OpenShift Cluster Manager クラスター作成プロセスの一部として設定されます。OpenShift はアイデンティティープロバイダーではないため、クラスターへのアクセスすべてが統合ソリューションの一部としてお客様によって管理される必要があります。同時にプロビジョニングされる複数のアイデンティティープロバイダーのプロビジョニングがサポートされています。以下のアイデンティティープロバイダーがサポートされます。
- GitHub または GitHub Enterprise OAuth
- GitLab OAuth
- Google OAuth
- LDAP
- OpenID Connect
2.1.7.2. 特権付きコンテナー
特権付きコンテナーは、デフォルトで OpenShift Dedicated では使用できません。anyuid および nonroot 以外の Security Context Constraints は dedicated-admins グループのメンバーに利用でき、多くのユースケースに対応する必要があります。特権付きコンテナーは cluster-admin ユーザーのみが利用できます。
2.1.7.3. お客様管理者ユーザー
OpenShift Dedicated は、通常のユーザーのほかに、dedicated-admin という OpenShift Dedicated 固有のグループへのアクセスを提供します。dedicated-admin グループのメンバーであるクラスターのすべてのユーザーは、
- クラスターでお客様が作成したすべてのプロジェクトへの管理者アクセス権を持ちます。
- クラスターのリソースクォータと制限を管理できます。
-
NetworkPolicyオブジェクトを追加および管理できます。 - スケジューラー情報を含む、クラスター内の特定のノードおよび PV に関する情報を表示できます。
-
クラスター上の予約された
dedicated-adminプロジェクトにアクセスできます。これにより、昇格された権限を持つサービスアカウントの作成が可能になり、クラスター上のプロジェクトのデフォルトの制限とクォータを更新できるようになります。 -
OperatorHub から Operator をインストールできます (
*すべての*.operators.coreos.comAPI グループの動詞)。
2.1.7.4. クラスター管理ロール
Customer Cloud Subscriptions (CCS) のある OpenShift Dedicated の管理者として、cluster-admin ロールにアクセスできます。cluster-admin ロールを持つアカウントにログインしている場合、ユーザーはクラスターを制御し、設定するためのほとんど無制限のアクセスを持っています。クラスターの不安定化を防ぐため、または OpenShift Cluster Manager で管理されており、クラスター内の変更が上書きされるために、Webhook でブロックされる設定がいくつかあります。
2.1.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.1.7.6. 規制コンプライアンス
OpenShift Dedicated は、セキュリティーおよび管理に関する一般的な業界のベストプラクティスに従います。認定の概要を以下の表に示します。
| コンプライアンス | AWS 専用の OpenShift | GCP 専用の OpenShift |
|---|---|---|
| HIPAA Qualified | はい (Customer Cloud Subscriptions のみ) | はい (Customer Cloud Subscriptions のみ) |
| ISO 27001 | はい | はい |
| PCI DSS | はい | はい |
| SOC 2 タイプ 2 | はい | はい |
2.1.7.7. ネットワークセキュリティー
各 OpenShift Dedicated クラスターは、ファイアウォールルール (AWS Security Groups または Google Cloud Compute Engine ファイアウォールルール) を使用して、クラウドインフラストラクチャーレベルでセキュアなネットワーク設定で保護されます。AWS の OpenShift Dedicated のお客様は、AWS Shield Standard による DDoS 攻撃に対して保護されます。同様に、GCP 上の OpenShift Dedicated が使するすべての GCP ロードバランサーとパブリック IP アドレスは、Google Cloud Armor Standard によって DDoS 攻撃から保護されます。
2.1.7.8. etcd 暗号化
OpenShift Dedicated では、コントロールプレーンストレージはデフォルトで保存時に暗号化されます。これには、etcd ボリュームの暗号化が含まれます。このストレージレベルの暗号化は、クラウドプロバイダーのストレージ層を介して提供されます。
etcd 暗号化を有効にして、キーではなく etcd のキーの値を暗号化することもできます。etcd 暗号化を有効にすると、以下の Kubernetes API サーバーおよび OpenShift API サーバーリソースが暗号化されます。
- シークレット
- config map
- ルート
- OAuth アクセストークン
- OAuth 認証トークン
etcd 暗号化機能はデフォルトで有効にされず、これはクラスターのインストール時にのみ有効にできます。etcd 暗号化が有効にされている場合でも、コントロールプレーンノードにアクセスできるユーザーまたは cluster-admin 権限を持つユーザーは、etcd キーの値にアクセスできます。
etcd のキー値の etcd 暗号化を有効にすると、約 20% のパフォーマンスのオーバーヘッドが発生します。このオーバーヘッドは、etcd ボリュームを暗号化するデフォルトのコントロールプレーンのストレージ暗号化に加えて、この 2 つ目の暗号化レイヤーの導入により生じます。Red Hat は、お客様のユースケースで特に etcd 暗号化が必要な場合にのみ有効にすることを推奨します。
