環境のプランニング


OpenShift Dedicated 4

Dedicated 4 のプランニングの概要

Red Hat OpenShift Documentation Team

概要

このドキュメントでは、OpenShift Dedicated クラスターのデプロイメントのプランニングに関する考慮事項を説明します。

第1章 制限およびスケーラビリティー

このドキュメントでは、OpenShift Dedicated クラスターでテストされたクラスターの最大値について、最大値のテストに使用されたテスト環境と設定に関する情報とともに詳しく説明します。コントロールプレーンとインフラストラクチャーノードのサイズ設定とスケーリングに関する情報も提供されます。

1.1. クラスターの最大値

OpenShift Dedicated クラスターのインストールを計画するときは、以下のテスト済みオブジェクトの最大値を考慮してください。この表は、OpenShift Dedicated クラスターでテストされた各タイプの最大制限を示しています。

これらのガイドラインは、複数のアベイラビリティーゾーン設定のコンピューティング (ワーカーとも呼ばれる) ノード 249 個のクラスターに基づいています。小規模なクラスターの場合、最大値はこれより低くなります。

Expand
表1.1 テスト済みのクラスターの最大値
最大値のタイプ4.x テスト済みの最大値

Pod 数 [1]

25,000

ノードあたりの Pod 数

250

コアあたりの Pod 数

デフォルト値はありません。

namespace 数 [2]

5,000

namespace あたりの Pod 数 [3]

25,000

サービス数 [4]

10,000

namespace ごとのサービス数

5,000

サービスごとのバックエンド数

5,000

namespace ごとのデプロイメント数 [3]

2,000

  1. ここで表示される Pod 数はテスト用の Pod 数です。実際の Pod 数は、アプリケーションのメモリー、CPU、およびストレージ要件により異なります。
  2. 有効なプロジェクトが多数ある場合は、キースペースが過度に大きくなり、スペースのクォータを超過すると、etcd はパフォーマンスの低下による影響を受ける可能性があります。etcd ストレージを利用できるようにするには、デフラグを含む etcd の定期的なメンテナンスを行うことが強く推奨されます。
  3. システムには、状態遷移への対応として、指定された namespace 内のすべてのオブジェクトに対して反復処理する必要がある制御ループがいくつかあります。単一の namespace にタイプのオブジェクトの数が多くなると、ループのコストが上昇し、状態変更を処理する速度が低下します。この制限は、アプリケーションの各種要件を満たすのに十分な CPU、メモリー、およびディスクがシステムにあることが前提となっています。
  4. 各サービスポートと各サービスのバックエンドには、iptables に対応するエントリーがあります。特定のサービスのバックエンド数は、エンドポイントのオブジェクトサイズに影響があり、その結果、システム全体に送信されるデータサイズにも影響を与えます。

1.2. OpenShift Container Platform テスト環境および設定

以下の表は、AWS クラウドプラットフォームに対してクラスターの最大値をテストする OpenShift Container Platform 環境および設定をリスト表示しています。

Expand
Node仮想 CPURAM(GiB)ディスクタイプディスクサイズ (GiB)/IOPSリージョン

コントロールプレーン/etcd [1]

m5.4xlarge

16

64

gp3

350 / 1,000

3

us-west-2

インフラストラクチャーノード [2]

r5.2xlarge

8

64

gp3

300 / 900

3

us-west-2

ワークロード [3]

m5.2xlarge

8

32

gp3

350 / 900

3

us-west-2

Compute nodes

m5.2xlarge

8

32

gp3

350 / 900

102

us-west-2

  1. io1 ディスクは、4.10 より前のすべてのバージョンでコントロールプレーン/etcd ノードに使用されます。
  2. Prometheus は使用状況パターンに応じて大量のメモリーを要求できるため、インフラストラクチャーノードはモニタリングコンポーネントをホストするために使用されます。
  3. ワークロードノードは、パフォーマンスとスケーラビリティーのワークロードジェネレーターを実行するための専用ノードです。

より大きなクラスターサイズとより多くのオブジェクト数に到達できる可能性があります。ただし、インフラストラクチャーノードのサイズによって、Prometheus で利用できるメモリー量が制限されます。オブジェクトの作成、変更、または削除時に、Prometheus はメトリックをそのメモリーに保存してから、ディスクでメトリックを永続化する前に 3 時間保存されます。オブジェクトの作成、変更、削除のレートが高すぎると、Prometheus はメモリーリソースがないために負荷がかかり、失敗する可能性があります。

1.3. コントロールプレーンとインフラストラクチャーノードのサイズ設定とスケーリング

OpenShift Dedicated クラスターをインストールすると、コントロールプレーンとインフラストラクチャーノードのサイズは、コンピュートノードの数によって自動的に決定されます。

インストール後にクラスター内のコンピュートノードの数を変更した場合、Red Hat サイトリライアビリティーエンジニアリング (SRE) チームは、クラスターの安定性を維持するために、必要に応じてコントロールプレーンとインフラストラクチャーノードをスケーリングします。

1.3.1. インストール中のノードのサイズ設定

インストールプロセス中に、コントロールプレーンとインフラストラクチャーノードのサイズが動的に計算されます。サイズ計算は、クラスター内のコンピュートノードの数に基づいています。

次の表に、インストール中に適用されるコントロールプレーンとインフラストラクチャーノードのサイズを示します。

AWS コントロールプレーンとインフラストラクチャーノードのサイズ:

Expand
コンピュートノードの数コントロールプレーンのサイズインフラストラクチャーノードのサイズ

1 から 25

m5.2xlarge

r5.xlarge

26 から 100

m5.4xlarge

r5.2xlarge

101 から 249

m5.8xlarge

r5.4xlarge

GCP コントロールプレーンとインフラストラクチャーノードのサイズ

Expand
コンピュートノードの数コントロールプレーンのサイズインフラストラクチャーノードのサイズ

1 から 25

custom-8-32768

custom-4-32768-ext

26 から 100

custom-16-65536

custom-8-65536-ext

101 から 249

custom-32-131072

custom-16-131072-ext

2024 年 6 月 21 日以降に作成されたクラスターの GCP コントロールプレーンおよびインフラストラクチャーノードサイズ:

Expand
コンピュートノードの数コントロールプレーンのサイズインフラストラクチャーノードのサイズ

1 から 25

n2-standard-8

n2-highmem-4

26 から 100

n2-standard-16

n2-highmem-8

101 から 249

n2-standard-32

n2-highmem-16

注記

OpenShift Dedicated クラスターバージョン 4.14.14 以降のコンピュートノードの最大数は 249 です。以前のバージョンでは、制限は 180 です。

1.3.2. インストール後のノードのスケーリング

インストール後にコンピュートノードの数を変更すると、コントロールプレーンノードとインフラストラクチャーノードが、必要に応じて Red Hat Site Reliability Engineering (SRE) チームによってスケーリングされます。ノードは、プラットフォームの安定性を維持するためにスケーリングされます。

コントロールプレーンおよびインフラストラクチャーノードのインストール後のスケーリング要件は、ケースごとに評価されます。ノードリソースの消費および受信アラートの考慮が行われます。

コントロールプレーンノードのサイズ変更のアラートのルール

サイズ変更アラートは、次の状況が発生した場合に、クラスター内のコントロールプレーンノードに対してトリガーされます。

  • クラスターでコントロールプレーンノードが平均 66% を超える使用率を維持している。

    注記

    OpenShift Dedicated のコンピュートノードの最大数は 180 です。

インフラストラクチャーノードのサイズ変更アラートのルール

CPU またはメモリーの使用率が継続して高い場合、クラスター内のインフラストラクチャーノードに対してサイズ変更アラートがトリガーされます。このように継続して使用率が高い状態が続いているのは、以下の場合です。

  • 2 つのインフラストラクチャーノードを使用する 1 つのアベイラビリティーゾーンを持つクラスターで、インフラストラクチャーノードが平均 50% を超える使用率を維持している。
  • 3 つのインフラストラクチャーノードを使用する複数のアベイラビリティーゾーンを持つクラスターで、インフラストラクチャーノードが平均 66% を超える使用率を維持している。

    注記

    OpenShift Dedicated クラスターバージョン 4.14.14 以降のコンピュートノードの最大数は 249 です。以前のバージョンでは、制限は 180 です。

    サイズ変更アラートは、使用率が高い状態が継続した場合にのみ表示されます。ノードが一時的にダウンして他のノードがスケールアップするなど、短期間に使用量が急増した場合には、これらのアラートはトリガーされません。

SRE チームは、ノードでのリソース消費の増加を管理するなど、追加の理由でコントロールプレーンとインフラストラクチャーノードをスケーリングする場合があります。

1.3.3. 大規模なクラスターのサイズに関する考慮事項

大規模なクラスターの場合、インフラストラクチャーノードのサイズ設定はスケーラビリティーに大きな影響を与える要因になる可能性があります。指定のしきい値に影響を与える要因には、etcd バージョンやストレージデータ形式などの多数の要因があります。

これらの制限を超えても、クラスターが障害が発生するとは限りません。ほとんど場合、これらの制限値を超えると、パフォーマンスが全体的に低下します。

第2章 GCP での Customer Cloud Subscription

OpenShift Dedicated は、Red Hat がお客様の既存の Google Cloud Platform (GCP) アカウントにクラスターをデプロイおよび管理できるようにする Customer Cloud Subscription (CCS) モデルを提供します。

2.1. GCP での Customer Cloud Subscription について

Red Hat OpenShift Dedicated は、Red Hat が OpenShift Dedicated をお客様の既存の Google Cloud Platform (GCP) アカウントにデプロイおよび管理できるようにする Customer Cloud Subscription (CCS) モデルを提供します。Red Hat では、このサービスを提供するために複数の前提条件を満たす必要があります。

Red Hat では、すべての GCP リソースを整理するために、お客様が管理する GCP プロジェクトの使用を推奨しています。プロジェクトには、ユーザーおよび API のセットと、それらの API の請求、認証、およびモニタリングの設定が含まれます。

OpenShift Dedicated クラスターは、GCP 組織内の GCP プロジェクトで CCS モデルを使用することが推奨されます。組織リソースは、GCP リソース階層のルートノードであり、組織に属するすべてのリソースは組織ノードでグループ化されます。お客様は、GCP プロジェクト内の Google Cloud リソースにアクセスするために必要なロールと認証情報を作成する際に、サービスアカウントキーまたは Workload Identity Federation の使用を選択できます。

GCP 内で組織リソースを作成および管理する方法の詳細は、組織リソースの作成と管理 を参照してください。

2.2. お客様の要件

Google Cloud Platform (GCP) で Customer Cloud Subscription (CCS) モデルを使用する OpenShift Dedicated クラスターは、デプロイする前に複数の前提条件を満たす必要があります。

2.2.1. アカウント

  • お客様は、Google Cloud の制限Compute Engine に適用される割り当てクォータ が、お客様が提供する GCP アカウント内にプロビジョニングされる OpenShift Dedicated をサポートするのに十分であることを確認します。
  • お客様が提供する GCP アカウントは、お客様の Google Cloud 組織内にある必要があります。
  • お客様が提供する GCP アカウントは、Red Hat に譲渡できません。
  • お客様は、Red Hat のアクティビティーに対して GCP の使用制限を課すことができない場合があります。制限を課すことにより、Red Hat のインシデントへの対応が大幅に妨げられます。
  • Red Hat は、root アカウントなどの高度の権限を持つアカウントがお客様提供の GCP アカウントにログインしたときに Red Hat に警告を発するために、モニタリングを GCP にデプロイします。
  • お客様は、お客様が提供する同じ GCP アカウント内でネイティブ GCP サービスをデプロイできます。

    注記

    OpenShift Dedicated やその他の Red Hat がサポートするサービスをホストする VPC とは別の Virtual Private Cloud (VPC) でリソースをデプロイすることが推奨されますが、これは必須ではありません。

2.2.2. アクセス要件

  • OpenShift Dedicated サービスを適切に管理するには、Red Hat では AdministratorAccess ポリシーを管理者ロールに常に適用する必要があります。

    注記

    このポリシーは、お客様が提供する GCP アカウント内のリソースを変更するための権限と機能のみを Red Hat に提供します。

  • Red Hat には、お客様が指定する GCP アカウントに対する GCP コンソールへのアクセスが必要です。このアクセスは、Red Hat により保護され、管理されます。
  • お客様は、GCP アカウントを使用して OpenShift Dedicated クラスター内でパーミッションを昇格させることはできません。
  • OpenShift Cluster Manager で利用可能なアクションは、お客様が指定する GCP アカウントで直接実行することはできません。

2.2.3. サポート要件

  • Red Hat では、お客様が少なくとも GCP の 拡張サポート を受けることを推奨しています。
  • Red Hat には、お客様に代わって GCP サポートを要求する権限があります。
  • Red Hat は、お客様から、お客様が指定するアカウントで GCP リソース制限の引き上げを要求する権限を受けます。
  • Red Hat は、この要件のセクションで特に指定されていない限り、すべての OpenShift Dedicated クラスターの制限、期待、およびデフォルトを同じ方法で管理します。

2.2.4. セキュリティー要件

  • お客様が指定する IAM 認証情報は、お客様が指定する GCP アカウントに固有の認証情報を使用し、お客様が指定する GCP アカウントのどこにも保存しないでください。
  • ボリュームスナップショットは、お客様が指定する GCP アカウントおよびお客様が指定するリージョン内に残ります。
  • OpenShift Dedicated クラスターを管理、監視、トラブルシューティングするには、Red Hat がクラスターの API サーバーに直接アクセスできる必要があります。OpenShift Dedicated クラスターの API サーバーへの Red Hat のアクセスを制限したり、その他の方法で阻止したりしないでください。

    注記

    SRE は、ネットワーク設定に応じてさまざまな方法を使用してクラスターにアクセスします。プライベートクラスターへのアクセスは、Red Hat の信頼できる IP アドレスのみに制限されます。このアクセス制限は Red Hat によって自動的に管理されます。

  • OpenShift Dedicated には、インターネットを経由する特定のエンドポイントへの Egress アクセスが必要です。ファイアウォールを使用して Egress トラフィックを制御できるのは、Private Service Connect を使用してデプロイされたクラスターだけです。詳細は、GCP ファイアウォールの前提条件 セクションを参照してください。

2.3. 必要なお客様の手順

Customer Cloud Subscription (CCS) モデルをご利用の場合、Red Hat が OpenShift Dedicated をお客様の Google Cloud Platform (GCP) プロジェクトにデプロイして管理します。Red Hat は、これらのサービスを提供するにあたり、いくつかの前提条件を完了することをお願いしています。

注記

以下に示すこのトピックの要件は、Workload Identity Federation (WIF) 認証タイプとサービスアカウント認証タイプの両方を使用して作成された Google Cloud Platform (GCP) 上の OpenShift Dedicated クラスターに適用されます。Red Hat では、GCP にデプロイする OpenShift Dedicated クラスターをインストールして操作するための認証タイプとして、WIF を使用することを推奨しています。これは、WIF によってセキュリティーが強化されるためです。

WIF 認証タイプを使用してクラスターを作成する方法は、関連情報 を参照してください。

WIF 認証タイプにのみ適用される追加要件は、Workload Identity Federation 認証タイプの手順 を参照してください。サービスアカウント認証タイプにのみ適用される追加要件は、サービスアカウント認証タイプの手順 を参照してください。

前提条件

GCP プロジェクトで OpenShift Dedicated を使用する前に、随時、次の組織ポリシー制約が正しく設定されていることを確認してください。

  • constraints/iam.allowedPolicyMemberDomains

    • このポリシー制約は、Red Hat の Directory Customer ID の C02k0l5e8 および C04j7mbwl が許可リストに含まれている場合にのみサポートされます。
  • constraints/compute.restrictLoadBalancerCreationForTypes

    • このポリシー制約は、GCP Private Service Connect (PSC) を使用してプライベートクラスターを作成する場合にのみサポートされます。INTERNAL_TCP_UDP ロードバランサータイプが許可リストに含まれているか、拒否リストから除外されていることを確認する必要があります。

      重要

      GCP Private Service Connect (PSC) を使用してプライベートクラスターを作成する場合、EXTERNAL_NETWORK_TCP_UDP ロードバランサータイプは必須ではありませんが、このロードバランサータイプを制約により禁止すると、クラスターは外部からアクセス可能なロードバランサーを作成できなくなります。

  • constraints/compute.requireShieldedVm

    • このポリシー制約は、最初のクラスター作成時に Enable Secure Boot support for Shielded VMs を選択してクラスターが作成された場合にのみサポートされます。
  • constraints/compute.vmExternalIpAccess

    • このポリシー制約は、GCP Private Service Connect (PSC) を使用してプライベートクラスターを作成する場合にのみサポートされます。他のすべてのクラスタータイプの場合、このポリシー制約はクラスターの作成後にのみサポートされます。
  • constraints/compute.trustedImageProjects

    • このポリシー制約は、プロジェクト redhat-marketplace-publicrhel-cloudrhcos-cloud が許可リストに含まれている場合にのみサポートされます。このポリシー制約が有効になっていて、これらのプロジェクトが許可リストに含まれていない場合、クラスターの作成は失敗します。

GCP 組織ポリシー制約の設定の詳細は、組織ポリシー制約 を参照してください。

手順

  1. OpenShift Dedicated クラスターをホストする Google Cloud プロジェクトを作成 します。
  2. OpenShift Dedicated クラスターをホストするプロジェクトで以下の必要な API を 有効にします

    Expand
    表2.1 必要な API サービス
    API サービスコンソールサービス名目的

    Cloud Deployment Manager V2 API

    deploymentmanager.googleapis.com

    インフラストラクチャーリソースの自動デプロイと管理に使用されます。

    Compute Engine API

    compute.googleapis.com

    仮想マシン、ファイアウォール、ネットワーク、永続ディスクボリューム、ロードバランサーの作成と管理に使用されます。

    Cloud Resource Manager API

    cloudresourcemanager.googleapis.com

    プロジェクトの取得、プロジェクトの IAM ポリシーの取得または設定、必要な権限の検証、タグ付けに使用されます。

    Cloud DNS API

    dns.googleapis.com

    DNS ゾーンを作成し、クラスタードメインの DNS レコードを管理するために使用されます。

    IAM Service Account Credentials API

    iamcredentials.googleapis.com

    IAM サービスアカウントの権限を借用するための有効期間が短い認証情報を作成するために使用されます。

    Identity and Access Management (IAM) API

    iam.googleapis.com

    クラスターの IAM 設定を管理するために使用されます。

    Service Management API

    servicemanagement.googleapis.com

    GCP リソースのクォータ情報を取得するために間接的に使用されます。

    Service Usage API

    serviceusage.googleapis.com

    お客様の Google Cloud アカウントで利用可能なサービスを確認するために使用されます。

    Cloud Storage JSON API

    storage-api.googleapis.com

    イメージレジストリー、Ignition、およびクラスターバックアップ (該当する場合) 用の Cloud Storage にアクセスするために使用されます。

    Cloud Storage

    storage-component.googleapis.com

    イメージレジストリー、Ignition、およびクラスターバックアップ (該当する場合) 用の Cloud Storage を管理するために使用されます。

    Organization Policy API

    orgpolicy.googleapis.com

    クラスターの作成や管理に影響を与える可能性のある、お客様の Google Cloud に適用されるガバナンスルールを特定するために使用されます。

    Cloud Identity-Aware Proxy API

    iap.googleapis.com [*]

    緊急時に、アクセスできないクラスターノードのトラブルシューティングを行うために使用されます。

    この API は、Private Service Connect を使用してデプロイされたクラスターに必要です。

2.3.1. Workload Identity Federation 認証タイプの手順

必要なお客様の手順 に記載されている必要なお客様手順の他に、認証タイプとして Workload Identity Federation (WIF) を使用して Google Cloud Platform (GCP) 上に OpenShift Dedicated クラスターを作成するときに実行する必要がある作業があります。

手順

  1. WIF 認証タイプを実装するユーザーの サービスアカウント に次のロールを割り当てます。

    重要

    次のロールは、WIF 設定を作成、更新、または削除する場合にのみ必要です。

    Expand
    表2.2 必要なロール
    ロールコンソールロール名ロールの目的

    Role Administrator

    roles/iam.roleAdmin

    カスタムロールを作成するために、OCM CLI の GCP クライアントで必要です。

    Service Account Admin

    roles/iam.serviceAccountAdmin

    OSD デプロイヤー、サポート、および Operator が必要とするサービスアカウントを事前に作成するために必要です。

    Workload Identity Pool Admin

    roles/iam.workloadIdentityPoolAdmin

    ワークロードアイデンティティープールを作成して設定するために必要です。

    Project IAM Admin

    roles/resourcemanager.projectIamAdmin

    サービスアカウントにロールを割り当て、クラウドリソースに対する操作を実行するために必要な権限をそのロールに付与するために必要です。

  2. OpenShift Cluster Manager API コマンドラインインターフェイス (ocm) をインストールします。

    重要

    OpenShift Cluster Manager API コマンドラインインターフェイス (ocm) は、開発者プレビュー機能です。Red Hat 開発者プレビュー機能のサポート範囲の詳細は、開発者プレビューのサポート範囲 を参照してください。

  3. Red Hat OpenShift Cluster Manager アカウントに対して認証するには、次のいずれかのコマンドを実行します。

    1. システムが Web ベースのブラウザーをサポートしている場合は、Red Hat シングルサインオン (SSO) 認可コードコマンドを実行し、セキュアに認証します。

      構文

      $ ocm login --use-auth-code
      Copy to Clipboard Toggle word wrap

      このコマンドを実行すると、Red Hat SSO ログインにリダイレクトされます。Red Hat のログインまたはメールでログインします。

    2. コンテナー、リモートホスト、および Web ブラウザーのないその他の環境で作業している場合は、安全な認証のために Red Hat シングルサインオン (SSO) デバイスコードコマンドを実行します。

      構文

      $ ocm login --use-device-code
      Copy to Clipboard Toggle word wrap

      このコマンドを実行すると、Red Hat SSO ログインにリダイレクトされ、ログインコードが提供されます。

      アカウントを切り替えるには、https://sso.redhat.com からログアウトし、端末で ocm logout コマンドを実行してから再度ログインを試みます。

  4. gcloud CLI をインストールします。
  5. Application Default Credentials (ADC) を使用して gcloud CLI を認証します。

2.3.2. サービスアカウント認証タイプの手順

必要なお客様の手順 に記載されている必要なお客様手順の他に、認証タイプとしてサービスアカウントを使用して Google Cloud Platform (GCP) 上に OpenShift Dedicated クラスターを作成するときに実行する必要がある作業があります。

手順

  1. Red Hat が必要なアクションを実行できるようにするには、GCP プロジェクトに osd-ccs-admin IAM サービスアカウント ユーザーを作成する必要があります。

    以下のロールを サービスアカウントに付与する 必要があります。

    Expand
    表2.3 必要なロール
    ロールコンソールロール名

    Compute Admin

    roles/compute.admin

    DNS Administrator

    roles/dns.admin

    Organization Policy Viewer

    roles/orgpolicy.policyViewer

    Service Management Administrator

    roles/servicemanagement.admin

    Service Usage Admin

    roles/serviceusage.serviceUsageAdmin

    Storage Admin

    roles/storage.admin

    Compute Load Balancer Admin

    roles/compute.loadBalancerAdmin

    Role Viewer

    roles/viewer

    Role Administrator

    roles/iam.roleAdmin

    Security Admin

    roles/iam.securityAdmin

    Service Account Key Admin

    roles/iam.serviceAccountKeyAdmin

    Service Account Admin

    roles/iam.serviceAccountAdmin

    Service Account User

    roles/iam.serviceAccountUser

  2. osd-ccs-admin IAM サービスアカウントの サービスアカウントキー を作成します。キーは osServiceAccount.json という名前のファイルにエクスポートします。この JSON ファイルは、クラスターの作成時に Red Hat OpenShift Cluster Manager にアップロードされます。

2.4. Red Hat 管理 Google Cloud リソース

Red Hat は、以下の IAM Google Cloud Platform (GCP) リソースを作成し、管理します。

重要

IAM サービスアカウントおよびロール、および IAM グループおよびロール のトピックは、サービスアカウント認証タイプを使用して作成されたクラスターにのみ適用されます。

2.4.1. IAM サービスアカウントおよびロール

osd-managed-admin IAM サービスアカウントは、お客様が指定する GCP アカウントを制御した直後に作成されます。これは、OpenShift Dedicated クラスターのインストールを実行するユーザーです。

以下のロールがサービスアカウントに割り当てられます。

Expand
表2.4 osd-managed-admin の IAM ロール
ロールコンソールロール名説明

Compute Admin

roles/compute.admin

すべての Compute Engine リソースを完全に制御します。

DNS Administrator

roles/dns.admin

すべての Cloud DNS リソースに読み取り/書き込みアクセスを提供します。

Security Admin

roles/iam.securityAdmin

IAM ポリシーを取得し、設定するためのパーミッションを持つセキュリティー管理者ロール。

Storage Admin

roles/storage.admin

オブジェクトおよびバケットを完全に制御します。

個別の バケット に適用される場合、制御はバケット内の指定されたバケットおよびオブジェクトにのみ適用されます。

Service Account Admin

roles/iam.serviceAccountAdmin

サービスアカウントを作成および管理します。

Service Account Key Admin

roles/iam.serviceAccountKeyAdmin

サービスアカウントキーを作成して管理 (ローテーション) します。

Service Account User

roles/iam.serviceAccountUser

サービスアカウントとして操作を実行します。

Role Administrator

roles/iam.roleAdmin

プロジェクトのすべてのカスタムロールへのアクセスを提供します。

2.4.2. IAM グループおよびロール

sd-sre-platform-gcp-access Google グループに、緊急トラブルシューティングの目的で Red Hat のサイトリライアビリティーエンジニアリング (SRE) のコンソールへのアクセスが許可されるため、GCP プロジェクトへのアクセスが付与されます。

注記
  • Workload Identity Federation (WIF) 認証タイプを使用する場合に作成されるクラスターに固有の sd-sre-platform-gcp-access グループ内のロールに関する詳細は、managed-cluster-config を参照してください。
  • Workload Identity Federation 認証タイプを使用してクラスターを作成する方法は、関連情報 を参照してください。

以下のロールがグループに割り当てられます。

Expand
表2.5 sd-sre-platform-gcp-access の IAM ロール
ロールコンソールロール名説明

Compute Admin

roles/compute.admin

すべての Compute Engine リソースを完全に制御します。

Editor

roles/editor

すべてのビューアーパーミッション、および状態を変更するアクションのパーミッションを提供します。

Organization Policy Viewer

roles/orgpolicy.policyViewer

リソースに対する組織ポリシーの表示アクセスを提供します。

Project IAM Admin

roles/resourcemanager.projectIamAdmin

プロジェクトの IAM ポリシーを管理するためのパーミッションを提供します。

Quota Administrator

roles/servicemanagement.quotaAdmin

サービスクォータを管理するアクセスを提供します。

Role Administrator

roles/iam.roleAdmin

プロジェクトのすべてのカスタムロールへのアクセスを提供します。

Service Account Admin

roles/iam.serviceAccountAdmin

サービスアカウントを作成および管理します。

Service Usage Admin

roles/serviceusage.serviceUsageAdmin

サービス状態の有効化、無効化、および検査を行い、操作を検査し、コンシューマープロジェクトのクォータおよび請求書を使用する機能。

Tech Support Editor

roles/cloudsupport.techSupportEditor

テクニカルサポートケースへの完全読み取り/書き込みアクセスを提供します。

2.5. プロビジョニングされる GCP インフラストラクチャー

以下は、デプロイされた OpenShift Dedicated クラスターでプロビジョニングされる Google Cloud Platform (GCP) コンポーネントの概要です。プロビジョニングされるすべての GCP コンポーネントの詳細な一覧は、OpenShift Container Platform ドキュメント を参照してください。

2.5.1. コンピュートインスタンス

GCP インスタンスは、GCP で OpenShift Dedicated のコントロールプレーン機能およびデータプレーン機能をデプロイするために必要になります。インスタンスタイプは、ワーカーノードの数に応じてコントロールプレーンおよびインフラストラクチャーノードによって異なる場合があります。

  • 単一アベイラビリティーゾーン

    • 2 つのインフラノード (カスタムマシンタイプ: 4 つの vCPU と 32 GB の RAM)
    • 3 つのコントロールプレーンノード (カスタムマシンタイプ: 8 つの vCPU と 32 GB の RAM)
    • 2 つのワーカーノード (カスタムマシンタイプ: 4 つの vCPU と 16 GB の RAM)
  • 複数のアベイラビリティーゾーン

    • 3 つのインフラノード (カスタムマシンタイプ: 4 つの vCPU と 32 GB の RAM)
    • 3 つのコントロールプレーンノード (カスタムマシンタイプ: 8 つの vCPU と 32 GB の RAM)
    • 3 つのワーカーノード (カスタムマシンタイプ: 4 つの vCPU と 16 GB の RAM)

2.5.2. ストレージ

  • インフラストラクチャーのボリューム:

    • 300 GB SSD 永続ディスク (インスタンスの削除時に削除)
    • 110 GB の標準永続ディスク (インスタンスの削除時に保持)
  • ワーカーのボリューム:

    • 300 GB SSD 永続ディスク (インスタンスの削除時に削除)
  • コントロールプレーンのボリューム:

    • 350 GB SSD 永続ディスク (インスタンスの削除時に削除)

2.5.3. VPC

注記

別のクラスター用にインストーラーによって自動的に作成された VPC に新しい OpenShift Dedicated クラスターをインストールすることはサポートされていません。

  • サブネット: コントロールプレーンワークロード用の 1 つのマスターサブネットと、その他すべてのワークロード用の 1 つのワーカーサブネット。
  • ルーターテーブル: VPC ごとに 1 つのグローバルルートテーブル。
  • インターネットゲートウェイ: クラスターごとに 1 つのインターネットゲートウェイ。
  • NAT ゲートウェイ: クラスターごとに 1 つのマスター NAT ゲートウェイと 1 つのワーカー NAT ゲートウェイ。

2.5.4. サービス

GCP CCS クラスターで次のサービスを有効にする必要があります。

  • deploymentmanager
  • compute
  • cloudapis
  • cloudresourcemanager
  • dns
  • iamcredentials
  • iam
  • servicemanagement
  • serviceusage
  • storage-api
  • storage-component
  • orgpolicy
  • networksecurity

2.6. GCP アカウントの制限

OpenShift Dedicated クラスターは多くの Google Cloud Platform (GCP) コンポーネントを使用しますが、デフォルトの クォータ は、OpenShift Dedicated クラスターのインストール機能に影響を与えません。

標準の OpenShift Dedicated クラスターは以下のリソースを使用します。一部のリソースはブートストラッププロセス時にのみ必要となり、クラスターのデプロイ後に削除されることに注意してください。

Expand
表2.6 デフォルトのクラスターで使用される GCP リソース
サービスコンポーネント場所必要なリソースの合計ブートストラップ後に削除されるリソース

サービスアカウント

IAM

グローバル

5

0

ファイアウォールのルール

Compute

グローバル

11

1

転送ルール

Compute

グローバル

2

0

使用中のグローバル IP アドレス

Compute

グローバル

4

1

ヘルスチェック

Compute

グローバル

3

0

イメージ

Compute

グローバル

1

0

ネットワーク

Compute

グローバル

2

0

静的 IP アドレス

Compute

リージョン

4

1

ルーター

Compute

グローバル

1

0

ルート

Compute

グローバル

2

0

サブネットワーク

Compute

グローバル

2

0

ターゲットプール

Compute

グローバル

3

0

CPU

Compute

リージョン

28

4

永続ディスク SSD (GB)

Compute

リージョン

896

128

注記

インストール時にクォータが十分ではない場合、インストールプログラムは超過したクォータとリージョンの両方を示すエラーを表示します。

実際のクラスターサイズ、計画されるクラスターの拡張、およびアカウントに関連付けられた他のクラスターからの使用法を考慮してください。CPU、静的 IP アドレス、および永続ディスク SSD (ストレージ) のクォータは、ほとんどの場合に不十分になる可能性のあるものです。

以下のリージョンのいずれかにクラスターをデプロイする予定の場合、ストレージクォータの最大値を超え、CPU クォータ制限を超える可能性が高くなります。

  • asia-east2
  • asia-northeast2
  • asia-south1
  • australia-southeast1
  • europe-north1
  • europe-west2
  • europe-west3
  • europe-west6
  • northamerica-northeast1
  • southamerica-east1
  • us-west2

GCP コンソール からリソースクォータを増やすことは可能ですが、サポートチケットを作成する必要がある場合があります。OpenShift Dedicated クラスターをインストールする前にサポートチケットを解決できるように、クラスターのサイズを早期に計画してください。

2.7. GCP ファイアウォールの前提条件

ファイアウォールを使用して Google Cloud Platform (GCP) 上の OpenShift Dedicated からの Egress トラフィックを制御する場合は、以下の表に記載されている特定のドメインとポートの組み合わせへのアクセスを許可するようにファイアウォールを設定する必要があります。OpenShift Dedicated がフルマネージドの OpenShift サービスを提供するには、このアクセスが必要です。

重要

ファイアウォールを使用して Egress トラフィックを制御できるのは、Private Service Connect を使用してデプロイされた Google Cloud Platform (GCP) 上の OpenShift Dedicated クラスターだけです。

手順

  1. パッケージとツールのインストールとダウンロードに使用する次の URL を許可リストに追加します。

    Expand
    ドメインポート機能

    registry.redhat.io

    443

    コアコンテナーイメージを指定します。

    quay.io

    443

    コアコンテナーイメージを指定します。

    cdn01.quay.io

    cdn02.quay.io

    cdn03.quay.io

    cdn04.quay.io

    cdn05.quay.io

    cdn06.quay.io

    443

    コアコンテナーイメージを指定します。

    sso.redhat.com

    443

    必須。https://console.redhat.com/openshift サイトでは、sso.redhat.com からの認証を使用してプルシークレットをダウンロードし、Red Hat SaaS ソリューションを使用してサブスクリプション、クラスターインベントリー、チャージバックレポートなどのモニタリングを行います。

    quayio-production-s3.s3.amazonaws.com

    443

    コアコンテナーイメージを指定します。

    pull.q1w2.quay.rhcloud.com

    443

    コアコンテナーイメージを指定します。

    registry.access.redhat.com

    443

    Red Hat Ecosytem Catalog に保存されているすべてのコンテナーイメージをホストします。さらに、レジストリーは、開発者が OpenShift および Kubernetes 上で構築するのに役立つ odo CLI ツールへのアクセスを提供します。

    registry.connect.redhat.com

    443

    すべてのサードパーティーのイメージと認定 Operator に必要です。

    console.redhat.com

    443

    必須。クラスターと Red Hat OpenShift Cluster Manager 間の対話を可能にし、アップグレードのスケジューリングなどの機能を有効にします。

    sso.redhat.com

    443

    https://console.redhat.com/openshift サイトは、sso.redhat.com からの認証を使用します。

    catalog.redhat.com

    443

    registry.access.redhat.com および https://registry.redhat.io サイトは catalog.redhat.com にリダイレクトされます。

  2. 次のテレメトリー URL を許可リストに追加します。

    Expand
    ドメインポート機能

    cert-api.access.redhat.com

    443

    テレメトリーに必要です。

    api.access.redhat.com

    443

    テレメトリーに必要です。

    infogw.api.openshift.com

    443

    テレメトリーに必要です。

    console.redhat.com

    443

    テレメトリーと Red Hat Insights に必要です。

    observatorium-mst.api.openshift.com

    443

    マネージド OpenShift 固有のテレメトリーに使用されます。

    observatorium.api.openshift.com

    443

    マネージド OpenShift 固有のテレメトリーに使用されます。

    注記

    マネージドクラスターでは、テレメトリーを有効にする必要があります。これは、Red Hat が問題に迅速に対応し、お客様をより適切にサポートし、製品のアップグレードがクラスターに与える影響をよりよく理解できるようにするためです。Red Hat によるリモートヘルスモニタリングデータの使用方法の詳細は、関連情報 セクションの リモートヘルスモニタリングについて を参照してください。

  3. 次の OpenShift Dedicated URL を許可リストに追加します。

    Expand
    ドメインポート機能

    mirror.openshift.com

    443

    ミラーリングされたインストールのコンテンツおよびイメージへのアクセスに使用されます。このサイトはリリースイメージ署名のソースでもあります。

    api.openshift.com

    443

    クラスターに更新が利用可能かどうかを確認するのに使用されます。

  4. 次の Site Reliability Engineering (SRE) および管理 URL を許可リストに追加します。

    Expand
    ドメインポート機能

    api.pagerduty.com

    443

    このアラートサービスは、クラスター内の alertmanager が使用します。これにより、Red Hat SRE に対してイベントの SRE 通知に関するアラートが送信されます。

    events.pagerduty.com

    443

    このアラートサービスは、クラスター内の alertmanager が使用します。これにより、Red Hat SRE に対してイベントの SRE 通知に関するアラートが送信されます。

    api.deadmanssnitch.com

    443

    クラスターが利用可能かどうかを示す定期的な ping を送信して、OpenShift Dedicated が使用するアラートサービス。

    nosnch.in

    443

    クラスターが利用可能かどうかを示す定期的な ping を送信して、OpenShift Dedicated が使用するアラートサービス。

    http-inputs-osdsecuritylogs.splunkcloud.com

    443

    splunk-forwarder-operator によって使用され、ログベースのアラートに Red Hat SRE が使用するロギング転送エンドポイントとして使用されます。

    sftp.access.redhat.com (推奨)

    22

    must-gather-operator が、クラスターに関する問題のトラブルシューティングに役立つ診断ログをアップロードするのに使用される SFTP サーバー。

  5. 次の Google Cloud Platform (GCP) API エンドポイントの URL を許可リストに追加します。

    Expand
    ドメインポート機能

    accounts.google.com

    443

    GCP アカウントにアクセスするために使用されます。

    *.googleapis.com

    または

    storage.googleapis.com

    iam.googleapis.com

    serviceusage.googleapis.com

    cloudresourcemanager.googleapis.com

    compute.googleapis.com

    oauth2.googleapis.com

    dns.googleapis.com

    iamcredentials.googleapis.com

    443

    GCP サービスおよびリソースへのアクセスに使用されます。GCP ドキュメントの Cloud Endpoints を参照して、お使いの API を許可するエンドポイントを確認してください。

    注記

    必要な Google API は、Service Usage API (serviceusage.googleapis.com) を除き、Private Google Access の制限付き仮想 IP (VIP) を使用して公開できます。これを回避するには、Private Google Access プライベート仮想 IP 使用して Service Usage API を公開する必要があります。

2.8. 関連情報

第3章 AWS での Customer Cloud Subscription

OpenShift Dedicated は、Red Hat がクラスターをお客様の既存の Amazon Web Service (AWS) アカウントにデプロイおよび管理できるようにする Customer Cloud Subscription (CCS) モデルを提供します。

3.1. AWS での Customer Cloud Subscription について

Customer Cloud Subscription (CCS) モデルを使用して OpenShift Dedicated を既存の Amazon Web Services (AWS) アカウントにデプロイする場合、Red Hat では複数の前提条件を満たす必要があります。

Red Hat では、複数の AWS アカウントを管理するために AWS Organization を使用することを推奨します。お客様が管理する AWS Organization は、複数の AWS アカウントをホストします。組織には、すべてのアカウントがアカウント階層で参照する組織には root アカウントがあります。

OpenShift Dedicated クラスターは、AWS Organizational Unit 内の AWS アカウントでホストされる CCS モデルを使用することが推奨されます。Service Control Policy (SCP) が作成され、AWS サブアカウントのアクセスが許可されるサービスを管理する AWS Organizational Unit に適用されます。SCP は、Organizational Unit 内のすべての AWS サブアカウントの単一の AWS アカウント内で利用可能なパーミッションにのみ適用されます。SCP を単一の AWS アカウントに適用することもできます。お客様の AWS Organization 内の他のすべてのアカウントは、お客様が必要とされる方法に応じて管理されます。Red Hat のサイトリライアビリティーエンジニアリング (SRE) には、AWS Organization 内の SCP に対する制御がありません。

3.2. お客様の要件

Amazon Web Services (AWS) で Customer Cloud Subscription (CCS) モデルを使用する OpenShift Dedicated クラスターは、デプロイする前に複数の前提条件を満たす必要があります。

3.2.1. アカウント

  • お客様は、お客様が提供する AWS アカウント内にプロビジョニングされる OpenShift Dedicated をサポートするのに十分な AWS 制限 が設定されていることを確認します。
  • お客様が提供した AWS アカウントは、該当するサービスコントロールポリシー (SCP) が適用されたお客様の AWS Organization 組織にある必要があります。

    注記

    お客様が提供したアカウントが AWS Organization 内にあることや SCP を適用することは要件ではありませんが、Red Hat が制限なしで SCP にリスト表示されるすべてのアクションを実行できるようにする必要があります。

  • お客様が提供する AWS アカウントは、Red Hat に譲渡できません。
  • お客様は、Red Hat の各種アクティビティーに対して AWS の使用に関する制限を課すことができない場合があります。制限を課すことにより、Red Hat のインシデントへの対応が大幅に妨げられます。
  • Red Hat は、root アカウントなどの高度の権限を持つアカウントがお客様提供の AWS アカウントにログインしたときに Red Hat に警告を発するために、モニタリングを AWS にデプロイします。
  • お客様が提供した同じ AWS アカウント内でネイティブ AWS サービスをデプロイできます。

    注記

    OpenShift Dedicated やその他の Red Hat がサポートするサービスをホストする VPC とは別の Virtual Private Cloud (VPC) でリソースをデプロイすることが推奨されますが、これは必須ではありません。

3.2.2. アクセス要件

  • OpenShift Dedicated サービスを適切に管理するには、Red Hat では AdministratorAccess ポリシーを管理者ロールに常に適用する必要があります。

    注記

    このポリシーは、お客様が提供する AWS アカウント内のリソースを変更するための権限と機能のみを Red Hat に提供します。

  • Red Hat には、お客様が提供する AWS アカウントへの AWS コンソールアクセス権が必要です。このアクセスは、Red Hat によって保護され、管理されます。
  • お客様は AWS アカウントを使用して OpenShift Dedicated クラスター内でパーミッションを昇格させることはできません。
  • OpenShift Cluster Manager で利用可能なアクションは、お客様によって提供される AWS アカウントで直接実行することはできません。

3.2.3. サポート要件

  • Red Hat では、お客様が少なくとも AWS の ビジネスサポート を用意することを推奨します。
  • Red Hat は、AWS サポートを代行してリクエストする権限をお客様から受けます。
  • Red Hat は、お客様が指定するアカウントで AWS リソース制限の引き上げを要求する権限をお客様から受けます。
  • Red Hat は、この要件のセクションで特に指定されていない限り、すべての OpenShift Dedicated クラスターの制限、期待、およびデフォルトを同じ方法で管理します。

3.2.4. セキュリティー要件

  • お客様が指定する IAM 認証情報はお客様が指定する AWS アカウントに固有のもので、お客様が指定する AWS アカウントには保存しないでください。
  • ボリュームスナップショットは、お客様が指定する AWS アカウントおよびお客様が指定するリージョン内に残ります。
  • Red Hat には、ホワイトリストの Red Hat マシンを使用して EC2 ホストおよび API サーバーへの ingress アクセスが必要です。
  • Red Hat では、Red Hat が管理する中央ロギングスタックにシステムおよび監査ログを転送できるようにするために egress が必要です。

3.3. 必要なお客様の手順

Customer Cloud Subscription (CCS) モデルにより、Red Hat は OpenShift Dedicated をお客様の Amazon Web Services (AWS) アカウントにデプロイおよび管理できるようにします。Red Hat では、これらのサービスを提供するために複数の前提条件が必要です。

手順

  1. お客様が AWS Organization を使用している場合、組織内の AWS アカウントを使用するか、新規のアカウントを作成する 必要があります。
  2. Red Hat が必要なアクションを実行できるようにするには、Service Control Policy (SCP) を作成するか、AWS アカウントに適用されているものがないことを確認する必要があります。
  3. SCP を AWS アカウントに 割り当て ます。
  4. AWS アカウント内で、以下の要件で osdCcsAdmin IAM ユーザーを 作成する 必要があります。

    • このユーザーは、少なくとも プログラムによるアクセス が有効になっている必要があります。
    • このユーザーには、AdministratorAccess ポリシーが割り当てられている必要があります。
  5. IAM ユーザー認証情報を Red Hat に提供します。

    • OpenShift Cluster Managerアクセスキー ID および シークレットアクセスキー を指定する必要があります。

3.4. 最低限必要な Service Control Policy (SCP)

Service Control Policy (SCP) の管理は、お客様の責任です。これらのポリシーは AWS Organization で維持され、割り当てられる AWS アカウント内で利用可能なサービスを管理します。

Expand
必須/任意サービスアクション効果

必須

Amazon EC2

すべて

許可

Amazon EC2 Auto Scaling

すべて

許可

Amazon S3

すべて

許可

アイデンティティーおよびアクセス管理

すべて

許可

Elastic Load Balancing

すべて

許可

Elastic Load Balancing V2

すべて

許可

Amazon CloudWatch

すべて

許可

Amazon CloudWatch Events

すべて

許可

Amazon CloudWatch Logs

すべて

許可

AWS Support

すべて

許可

AWS Key Management Service

すべて

許可

AWS Security Token Service

すべて

許可

AWS Resource Tagging

すべて

許可

AWS Route53 DNS

すべて

許可

AWS Service Quotas

ListServices

GetRequestedServiceQuotaChange

GetServiceQuota

RequestServiceQuotaIncrease

ListServiceQuotas

許可

任意

AWS Billing

ViewAccount

Viewbilling

ViewUsage

許可

AWS Cost and Usage Report

すべて

許可

AWS Cost Explorer Services

すべて

許可

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Effect": "Allow",
            "Action": [
                "ec2:*"
            ],
            "Resource": [
                "*"
            ]
        },
        {
            "Effect": "Allow",
            "Action": [
                "autoscaling:*"
            ],
            "Resource": [
                "*"
            ]
        },
        {
            "Effect": "Allow",
            "Action": [
                "s3:*"
            ],
            "Resource": [
                "*"
            ]
        },
        {
            "Effect": "Allow",
            "Action": [
                "iam:*"
            ],
            "Resource": [
                "*"
            ]
        },
        {
            "Effect": "Allow",
            "Action": [
                "elasticloadbalancing:*"
            ],
            "Resource": [
                "*"
            ]
        },
        {
            "Effect": "Allow",
            "Action": [
                "cloudwatch:*"
            ],
            "Resource": [
                "*"
            ]
        },
        {
            "Effect": "Allow",
            "Action": [
                "events:*"
            ],
            "Resource": [
                "*"
            ]
        },
        {
            "Effect": "Allow",
            "Action": [
                "logs:*"
            ],
            "Resource": [
                "*"
            ]
        },
        {
            "Effect": "Allow",
            "Action": [
                "support:*"
            ],
            "Resource": [
                "*"
            ]
        },
        {
            "Effect": "Allow",
            "Action": [
                "kms:*"
            ],
            "Resource": [
                "*"
            ]
        },
        {
            "Effect": "Allow",
            "Action": [
                "sts:*"
            ],
            "Resource": [
                "*"
            ]
        },
        {
            "Effect": "Allow",
            "Action": [
                "tag:*"
            ],
            "Resource": [
                "*"
            ]
        },
        {
            "Effect": "Allow",
            "Action": [
                "route53:*"
            ],
            "Resource": [
                "*"
            ]
        },
        {
            "Effect": "Allow",
            "Action": [
                "servicequotas:ListServices",
                "servicequotas:GetRequestedServiceQuotaChange",
                "servicequotas:GetServiceQuota",
                "servicequotas:RequestServiceQuotaIncrease",
                "servicequotas:ListServiceQuotas"
            ],
            "Resource": [
                "*"
            ]
        }
    ]
}
Copy to Clipboard Toggle word wrap

3.5. AWS の Red Hat 管理 IAM リファレンス

Red Hat は、IAM ポリシー、IAM ユーザー、IAM ロールなどの以下の Amazon Web Services (AWS) リソースを作成し、管理します。

3.5.1. IAM ポリシー

注記

IAM ポリシーは、OpenShift Dedicated の機能の変更に伴って変更されることがあります。

  • AdministratorAccess ポリシーは管理ロールによって使用されます。このポリシーは、お客様が指定する AWS アカウントで OpenShift Dedicated クラスターを管理するために必要なアクセスを Red Hat に提供します。

    {
        "Version": "2012-10-17",
        "Statement": [
            {
                "Action": "*",
                "Resource": "*",
                "Effect": "Allow"
            }
        ]
    }
    Copy to Clipboard Toggle word wrap
  • CustomerAdministratorAccess ロールは、AWS アカウント内のサービスのサブセットを管理するためのお客様アクセスを提供します。現時点では、以下が可能になります。

    • VPC ピアリング
    • VPN 設定
    • 直接接続 (サービスコントロールポリシーを通じて許可されている場合にのみ使用可能)

      {
          "Version": "2012-10-17",
          "Statement": [
              {
                  "Effect": "Allow",
                  "Action": [
                      "ec2:AttachVpnGateway",
                      "ec2:DescribeVpnConnections",
                      "ec2:AcceptVpcPeeringConnection",
                      "ec2:DeleteVpcPeeringConnection",
                      "ec2:DescribeVpcPeeringConnections",
                      "ec2:CreateVpnConnectionRoute",
                      "ec2:RejectVpcPeeringConnection",
                      "ec2:DetachVpnGateway",
                      "ec2:DeleteVpnConnectionRoute",
                      "ec2:DeleteVpnGateway",
                      "ec2:DescribeVpcs",
                      "ec2:CreateVpnGateway",
                      "ec2:ModifyVpcPeeringConnectionOptions",
                      "ec2:DeleteVpnConnection",
                      "ec2:CreateVpcPeeringConnection",
                      "ec2:DescribeVpnGateways",
                      "ec2:CreateVpnConnection",
                      "ec2:DescribeRouteTables",
                      "ec2:CreateTags",
                      "ec2:CreateRoute",
                "directconnect:*"
                  ],
                  "Resource": "*"
              }
          ]
      }
      Copy to Clipboard Toggle word wrap
  • 有効にされている場合、BillingReadOnlyAccess ロールは、アカウントの請求情報および使用状況に関する情報を表示するための読み取り専用アクセスを提供します。

    請求および使用状況のアクセスは、AWS Organization の root アカウントが有効になっている場合にのみ付与されます。これは任意のステップであり、読み取り専用の請求および使用方法のアクセスを有効にし、このプロファイルとそれを使用するロールには影響を与えません。このロールが有効になっていない場合は、ユーザーに請求および使用状況の情報は表示されません。請求データへのアクセスを有効にする方法 は、このチュートリアルを参照してください。

    {
        "Version": "2012-10-17",
        "Statement": [
            {
                "Effect": "Allow",
                "Action": [
                    "aws-portal:ViewAccount",
                    "aws-portal:ViewBilling"
                ],
                "Resource": "*"
            }
        ]
    }
    Copy to Clipboard Toggle word wrap

3.5.2. IAM ユーザー

osdManagedAdmin ユーザーは、お客様が指定する AWS アカウントの制御直後に作成されます。これは、OpenShift Dedicated クラスターのインストールを実行するユーザーです。

3.5.3. IAM ロール

  • network-mgmt ロールは、別の AWS アカウントを介して AWS アカウントへの管理アクセスを提供します。また、読み取り専用のロールと同じアクセスを持ちます。network-mgmt ロールは、Customer Cloud Subscription (CCS) 以外のクラスターにのみ適用されます。以下のポリシーはロールに割り当てられます。

    • AmazonEC2ReadOnlyAccess
    • CustomerAdministratorAccess
  • read-only ロールは、別の AWS アカウントを介して AWS アカウントへのカスタマーフェデレーションの読み取り専用アクセスを提供します。以下のポリシーはロールに割り当てられます。

    • AWSAccountUsageReportAccess
    • AmazonEC2ReadOnlyAccess
    • AmazonS3ReadOnlyAccess
    • IAMReadOnlyAccess
    • BillingReadOnlyAccess

3.6. プロビジョニングされた AWS インフラストラクチャー

これは、デプロイされた OpenShift Dedicated クラスター上のプロビジョニングされた Amazon Web Services (AWS) コンポーネントの概要です。プロビジョニングされたすべての AWS コンポーネントの詳細なリストは、OpenShift Container Platform ドキュメント を参照してください。

3.6.1. AWS Elastic Computing (EC2) インスタンス

AWS EC2 インスタンスは、AWS パブリッククラウドで OpenShift Dedicated のコントロールプレーン機能およびデータプレーン機能をデプロイするために必要になります。インスタンスタイプは、ワーカーノードの数に応じてコントロールプレーンおよびインフラストラクチャーノードによって異なる場合があります。

  • 単一アベイラビリティーゾーン

    • 3 m5.2xlarge 最小 (コントロールプレーンノード)
    • 2 r5.xlarge 最小 (インフラストラクチャーノード)
    • 2 m5.xlarge 最小だが高い変数 (ワーカーノード)
  • 複数のアベイラビリティーゾーン

    • 3 m5.2xlarge 最小 (コントロールプレーンノード)
    • 3 r5.xlarge 最小 (インフラストラクチャーノード)
    • 3 m5.xlarge 最小だが高い変数 (ワーカーノード)

3.6.2. AWS Elastic Block Store (EBS) ストレージ

Amazon EBS ブロックストレージは、ローカルノードストレージおよび永続ボリュームストレージの両方に使用されます。

各 EC2 インスタンスのボリューム要件:

  • コントロールプレーンボリューム

    • サイズ: 350 GB
    • タイプ: io1
    • 1 秒あたりの入出力操作: 1000
  • インフラストラクチャーボリューム

    • サイズ: 300 GB
    • タイプ: gp2
    • 1 秒あたりの I/O 処理数: 900
  • ワーカーボリューム

    • サイズ: 300 GB
    • タイプ: gp2
    • 1 秒あたりの I/O 処理数: 900

3.6.3. Elastic Load Balancing (ELB) ロードバランサー

API 用に最大 2 つのネットワークロードバランサー、アプリケーションルーター用に最大 2 つのクラシックロードバランサー。詳細は、AWS に関する ELB ドキュメント を参照してください。

3.6.4. S3 ストレージ

イメージレジストリーおよび Elastic Block Store (EBS) ボリュームスナップショットは、AWS S3 ストレージでサポートされます。リソースのプルーニングは、S3 の使用とクラスターのパフォーマンスを最適化するために定期的に実行されます。

注記

それぞれ 2TB の一般的なサイズの 2 つのバケットが必要です。

3.6.5. VPC

お客様はクラスターごとに 1 つの VPC を確認できるはずです。さらに、VPC には以下の設定が必要です。

注記

別のクラスター用にインストーラーによって自動的に作成された VPC に新しい OpenShift Dedicated クラスターをインストールすることはサポートされていません。

  • サブネット: 単一アベイラビリティーゾーンがあるクラスターの 2 つのサブネット、または複数のアベイラビリティーゾーンがあるクラスターの 6 つのサブネット。

    注記

    パブリックサブネット は、インターネットゲートウェイを介してインターネットに直接接続します。プライベートサブネット は、ネットワークアドレス変換 (NAT) ゲートウェイを介してインターネットに接続します。

  • ルートテーブル: プライベートサブネットごとに 1 つのルートテーブルと、クラスターごとに 1 つの追加テーブル。
  • インターネットゲートウェイ: クラスターごとに 1 つのインターネットゲートウェイ。
  • NAT ゲートウェイ: パブリックサブネットごとに 1 つの NAT ゲートウェイ。
3.6.5.1. サンプル VPC アーキテクチャー

3.6.6. セキュリティーグループ

AWS セキュリティーグループは、プロトコルおよびポートアクセスレベルでセキュリティーを提供します。これらは EC2 インスタンスおよび Elastic Load Balancing に関連付けられます。各セキュリティーグループには、EC2 インスタンスの送受信トラフィックをフィルタリングする一連のルールが含まれます。OpenShift Container Platform インストール に必要なポートがネットワーク上で開いており、ホスト間のアクセスを許可するように設定されていることを確認する必要があります。

3.6.6.1. 追加のカスタムセキュリティーグループ

非マネージド VPC を使用してクラスターを作成する場合は、クラスターの作成中にカスタムセキュリティーグループを追加できます。カスタムセキュリティーグループには次の制限があります。

  • クラスターを作成する前に、AWS でカスタムセキュリティーグループを作成する必要があります。詳細は、Amazon EC2 security groups for Linux instances を参照してください。
  • カスタムセキュリティーグループを、クラスターのインストール先の VPC に関連付ける必要があります。カスタムセキュリティーグループを別の VPC に関連付けることはできません。
  • カスタムセキュリティーグループを追加する場合は、VPC の追加クォータをリクエストする必要がある場合があります。AWS クォータ引き上げのリクエストは、Requesting a quota increase を参照してください。

3.7. ネットワークの前提条件

3.7.1. 最小帯域幅

OpenShift Dedicated では、クラスターのデプロイメント中、クラスターインフラストラクチャーと、デプロイメントアーティファクトおよびリソースを提供するパブリックインターネットまたはプライベートネットワークロケーションとの間に、最低 120 Mbps の帯域幅が必要です。ネットワーク接続が 120 Mbps より遅い場合 (たとえば、プロキシー経由で接続している場合)、クラスターのインストールプロセスがタイムアウトし、デプロイメントが失敗します。

クラスターのデプロイ後のネットワーク要件はワークロードに基づきます。ただし、最小帯域幅 120 Mbps は、クラスターと Operator を適切なタイミングで確実にアップグレードするために役立ちます。

3.8. AWS アカウントの制限

OpenShift Dedicated クラスターは数多くの Amazon Web Services (AWS) コンポーネントを使用し、デフォルトの サービス制限 は、OpenShift Dedicated クラスターをインストールする機能に影響を与えます。特定のクラスター設定を使用し、クラスターを特定の AWS リージョンにデプロイするか、アカウントを使用して複数のクラスターを実行する場合、AWS アカウントの追加リソースを要求することが必要になる場合があります。

以下の表は、OpenShift Dedicated クラスターのインストールおよび実行機能に影響を与える可能性のある AWS コンポーネントをまとめています。

Expand
コンポーネントデフォルトで利用できるクラスターの数デフォルトの AWS の制限説明

インスタンスの制限

変動あり。

変動あり。

少なくとも、各クラスターは次のインスタンスを作成します。

  • 1 つのブートストラップマシン。これはインストール後に削除されます。
  • 3 つのコントロールプレーンノード。
  • 1 つのアベイラビリティゾーンに 2 つのインフラストラクチャーノード。マルチアベイラビリティゾーンに 3 つのインフラストラクチャーノード。
  • 1 つのアベイラビリティゾーンに 2 つのワーカーノード。マルチアベイラビリティゾーンに 3 つのワーカーノード

これらのインスタンスタイプの数は、新規アカウントのデフォルト制限内の値です。追加のワーカーノードをデプロイし、大規模なワークロードをデプロイするか、異なるインスタンスタイプを使用するには、アカウントの制限を見直し、クラスターが必要なマシンをデプロイできることを確認します。

ほとんどのリージョンでは、ブートストラップおよびワーカーマシンは m4.large マシンを使用し、コントロールプレーンマシンは m4.xlarge インスタンスを使用します。これらのインスタンスタイプをサポートしないすべてのリージョンを含む一部のリージョンでは、m5.large および m5.xlarge インスタンスが代わりに使用されます。

Elastic IP (EIP)

0 - 1

アカウントごとに 5 つの EIP

クラスターを高可用性設定でプロビジョニングするために、インストールプログラムはそれぞれの リージョン内のアベイラビリティーゾーン にパブリックおよびプライベートのサブネットを作成します。各プライベートサブネットには NAT ゲートウェイ が必要であり、各 NAT ゲートウェイには別個の Elastic IP が必要です。AWS リージョンマップ を確認して、各リージョンにあるアベイラビリティーゾーンの数を判別します。デフォルトの高可用性を利用するには、少なくとも 3 つのアベイラビリティーゾーンがあるリージョンにクラスターをインストールします。アベイラビリティーゾーンが 6 つ以上あるリージョンにクラスターをインストールするには、EIP 制限を引き上げる必要があります。

重要

us-east-1 リージョンを使用するには、アカウントの EIP 制限を引き上げる必要があります。

Virtual Private Cloud (VPC)

5

リージョンごとに 5 つの VPC

各クラスターは独自の VPC を作成します。

Elastic Load Balancing (ELB)

3

リージョンごとに 20

デフォルトで、各クラスターは、プライマリー API サーバーの内部および外部のネットワークロードバランサーおよびルーターの単一の Classic Load Balancer を作成します。追加の Kubernetes LoadBalancer Service オブジェクトをデプロイすると、追加の ロードバランサー が作成されます。

NAT ゲートウェイ

5

アベイラビリティゾーンごとに 5 つ

クラスターは各アベイラビリティーゾーンに 1 つの NAT ゲートウェイをデプロイします。

Elastic Network Interface (ENI)

12 以上

リージョンごとに 350

デフォルトのインストールは 21 の ENI を作成し、リージョンの各アベイラビリティーゾーンに 1 つの ENI を作成します。たとえば、us-east-1 リージョンには 6 つのアベイラビリティーゾーンが含まれるため、そのゾーンにデプロイされるクラスターは 27 の ENI を使用します。AWS リージョンマップ を確認して、各リージョンにあるアベイラビリティーゾーンの数を判別します。

クラスターの使用量やデプロイされたワークロード別に作成された追加のマシンやロードバランサーに対して、追加の ENI が作成されます。

VPC ゲートウェイ

20

アカウントごとに 20

各クラスターは、S3 アクセス用の単一の VPC ゲートウェイを作成します。

S3 バケット

99

アカウントごとに 100 バケット

インストールプロセスでは 1 つの一時的なバケットを作成し、各クラスターのレジストリーコンポーネントがバケットを作成するため、AWS アカウントごとに 99 の OpenShift Dedicated クラスターのみを作成できます。

Security Groups

250

アカウントごとに 2,500

各クラスターは、10 の個別のセキュリティーグループを作成します。

Legal Notice

Copyright © 2025 Red Hat

OpenShift documentation is licensed under the Apache License 2.0 (https://www.apache.org/licenses/LICENSE-2.0).

Modified versions must remove all Red Hat trademarks.

Portions adapted from https://github.com/kubernetes-incubator/service-catalog/ with modifications by Red Hat.

Red Hat, Red Hat Enterprise Linux, the Red Hat logo, the Shadowman logo, JBoss, OpenShift, Fedora, the Infinity logo, and RHCE are trademarks of Red Hat, Inc., registered in the United States and other countries.

Linux® is the registered trademark of Linus Torvalds in the United States and other countries.

Java® is a registered trademark of Oracle and/or its affiliates.

XFS® is a trademark of Silicon Graphics International Corp. or its subsidiaries in the United States and/or other countries.

MySQL® is a registered trademark of MySQL AB in the United States, the European Union and other countries.

Node.js® is an official trademark of Joyent. Red Hat Software Collections is not formally related to or endorsed by the official Joyent Node.js open source or commercial project.

The OpenStack® Word Mark and OpenStack logo are either registered trademarks/service marks or trademarks/service marks of the OpenStack Foundation, in the United States and other countries and are used with the OpenStack Foundation’s permission. We are not affiliated with, endorsed or sponsored by the OpenStack Foundation, or the OpenStack community.

All other trademarks are the property of their respective owners.

トップに戻る
Red Hat logoGithubredditYoutubeTwitter

詳細情報

試用、購入および販売

コミュニティー

Red Hat ドキュメントについて

Red Hat をお使いのお客様が、信頼できるコンテンツが含まれている製品やサービスを活用することで、イノベーションを行い、目標を達成できるようにします。 最新の更新を見る.

多様性を受け入れるオープンソースの強化

Red Hat では、コード、ドキュメント、Web プロパティーにおける配慮に欠ける用語の置き換えに取り組んでいます。このような変更は、段階的に実施される予定です。詳細情報: Red Hat ブログ.

会社概要

Red Hat は、企業がコアとなるデータセンターからネットワークエッジに至るまで、各種プラットフォームや環境全体で作業を簡素化できるように、強化されたソリューションを提供しています。

Theme

© 2025 Red Hat