検索

環境の準備

download PDF
Red Hat OpenShift Service on AWS 4

Red Hat OpenShift Service on AWS の計画、制限、およびスケーラビリティ

Red Hat OpenShift Documentation Team

概要

このドキュメントでは、クラスターの制限やスケーラビリティーに関する情報など、Red Hat OpenShift Service on AWS (ROSA) クラスターのデプロイに関する計画上の考慮事項を説明します。

第1章 STS を使用する ROSA をデプロイするための前提条件チェックリスト

これは、STS を使用して Red Hat OpenShift Service on AWS (ROSA) のクラシッククラスターを作成するために必要な前提条件のチェックリストです。

注記

このリストは一般的なチェックリストであり、実際の実装は異なる場合があります。

インストールプロセスの実行前に、アクセスできるマシンからこれをデプロイできることを確認します。

  • プロビジョニングするクラウドの API サービス。
  • api.openshift.comoidc.op1.openshiftapps.comsso.redhat.com へのアクセス。
  • プロビジョニングするネットワーク上のホスト。
  • インストールメディアを取得するインターネット。
重要

ROSA CLI のバージョン 1.2.7 以降、新しいクラスター上の OIDC プロバイダーのエンドポイント URL は、すべて Amazon CloudFront と oidc.op1.openshiftapps.com ドメインを使用します。この変更により、ROSA CLI 1.2.7 以降を使用して作成された新しいクラスターのアクセス速度の向上、遅延の減少、回復性の向上が実現されました。既存の OIDC プロバイダー設定に対してサポートされている移行パスはありません。

1.1. アカウントおよび CLI の前提条件

クラスターをデプロイするためにインストールする必要があるアカウントと CLI。

1.1.1. AWS アカウント

1.1.2. AWS CLI (aws)

  • まだインストールしていない場合は AWS コマンドラインインターフェイス からインストールします。
  • CLI を設定します。

    1. ターミナルに aws configure と入力します。

      $ aws configure
    2. AWS Access Key ID を入力し、enter を押します。
    3. AWS Secret Access Key を入力し、enter を押します。
    4. デプロイするデフォルトのリージョンを入力します。
    5. 必要な出力形式として、table または json を入力します。
    6. 以下を実行して出力を確認します。

       $ aws sts get-caller-identity
    7. 次のコマンドを実行して、ELB のサービスロールがすでに存在していることを確認します。

      $ aws iam get-role --role-name "AWSServiceRoleForElasticLoadBalancing"
      1. 存在しない場合は、以下を実行します。

        $ aws iam create-service-linked-role --aws-service-name "elasticloadbalancing.amazonaws.com"

1.1.3. Red Hat アカウント

1.1.4. ROSA CLI (rosa)

  1. まだ有効にしていない場合は、AWS console の AWS アカウントから ROSA を有効にします。
  2. Red Hat OpenShift Service on AWS (ROSA) CLI から、または OpenShift コンソールの AWS コンソール から CLI をインストールします。
  3. ターミナルで rosa login と入力すると、コンソールから トークンページ に移動するよう求められます。

    $ rosa login
  4. Red Hat アカウントの認証情報でログインします。
  5. Load token ボタンをクリックします。
  6. トークンをコピーして CLI プロンプトに貼り付けて、Enter を押します。

    • あるいは、全 $ rosa login --token=abc… コマンドをコピーしてターミナルに貼り付けることもできます。

      $ rosa login --token=<abc..>
  7. 以下を実行して認証情報を確認します。

    $ rosa whoami
  8. 次のコマンドを実行して、十分なクォータがあることを確認します。

    $ rosa verify quota

1.1.5. OpenShift CLI (oc)

  1. OpenShift CLI のスタートガイド または OpenShift コンソールの コマンドラインインターフェイス (CLI) ツール からインストールします。
  2. 以下を実行して、OpenShift CLI が正しくインストールされていることを確認します。

    $ rosa verify openshift-client

上記の前提条件をインストールして有効にしたら、次の手順に進みます。

1.2. SCP の前提条件

ROSA クラスターは、AWS 組織単位内の AWS アカウントでホストされます。Service Control Policy (SCP) が作成され、AWS サブアカウントのアクセスが許可されるサービスを管理する AWS Organizational Unit に適用されます。

  • クラスターに必要なロールやポリシーよりも、組織の SCP の制限が厳しくないことを確認してください。
  • コンソールから Enable ROSA を選択したときに、必要な aws-marketplace:Subscribe パーミッションを許可するように SCP が設定されていることを確認してください。詳細は AWS Organizations service control policy (SCP) is denying required AWS Marketplace permissions を参照してください。
  • ROSA クラシッククラスターを作成すると、関連付けられた AWS OpenID Connect (OIDC) ID プロバイダーが作成されます。

    • この OIDC プロバイダー設定は、us-east-1 AWS リージョンにある公開鍵に依存します。
    • AWS SCP をお持ちのお客様は、これらのクラスターが別のリージョンにデプロイされている場合でも us-east-1 AWS リージョンを使用できるようにする必要があります。

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

ネットワークの観点から必要とされる事項。

1.3.1. ファイアウォール

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

既存の管理対象外の VPC を使用してクラスターを作成する場合、クラスターの作成中に追加のカスタムセキュリティーグループを追加できます。クラスターを作成する前に、次の前提条件を満たしていることを確認してください。

  • クラスターを作成する前に、AWS でカスタムセキュリティーグループを作成する必要があります。
  • カスタムセキュリティーグループを、クラスターの作成に使用している VPC に関連付けます。カスタムセキュリティーグループを他の VPC に関連付けないでください。
  • 場合によって、Security groups per network interface の AWS クォータの追加を要求する必要があります。

詳細は、セキュリティーグループ の詳細な要件を参照してください。

1.3.3. カスタム DNS

  • カスタム DNS を使用する場合、ROSA インストーラーはローカルでホストを解決できるように、デフォルトの DHCP オプションで VPC DNS を使用できる必要があります。

    • これを行うには、aws ec2 describe-dhcp-options を実行し、VPC が VPC Resolver を使用しているかどうかを確認します。

      $ aws ec2 describe-dhcp-options
  • それ以外の場合は、クラスターが内部 IP およびサービスを解決できるように、アップストリーム DNS はクラスタースコープをこの VPC に転送する必要があります。

第2章 STS を使用する ROSA をデプロイするための詳細な要件

Red Hat OpenShift Service on AWS (ROSA) は、Red Hat によるクラスターのお客様の既存 Amazon Web Service (AWS) アカウントへのデプロイを可能にするモデルを提供します。

ヒント

AWS Security Token Service (STS) は、セキュリティーが強化されているため、Red Hat OpenShift Service on AWS (ROSA) にクラスターをインストールして操作するのに推奨される認証情報モードです。

STS で ROSA をインストールする前に、以下の AWS 前提条件を満たしていることを確認してください。

重要

AWS STS を使用する ROSA クラスターを作成すると、関連付けられた AWS OpenID Connect(OIDC) アイデンティティープロバイダーも作成されます。この OIDC プロバイダー設定は、us-east-1 AWS リージョンにある公開鍵に依存します。AWS SCP をお持ちのお客様は、これらのクラスターが別のリージョンにデプロイされている場合でも us-east-1 AWS リージョンを使用できるようにする必要があります。

2.1. デプロイメントに STS を使用する場合のカスタマー要件

AWS Security Token Service (STS) を使用する Red Hat OpenShift Service on AWS (ROSA) クラスターをデプロイする前に、以下の前提条件を満たす必要があります。

2.1.1. アカウント

  • AWS アカウント内にプロビジョニングされる Red Hat OpenShift Service on AWS をサポートするのに十分な AWS 制限が設定されていることを確認する必要があります。CLI で rosa verify quote コマンドを実行すると、クラスターを実行するために必要なクォータがあることが検証されます。

    注記

    クォータの検証は AWS クォータを確認しますが、消費を AWS クォータと比較しません。詳細については、追加リソースの制限とスケーラビリティリンクを参照してください。

  • SCP ポリシーを適用し、強制される場合、これらのポリシーは、クラスターが必要とするロールおよびポリシーよりも制限的であってはなりません。
  • AWS アカウントを Red Hat に譲渡できないようにする必要があります。
  • Red Hat のアクティビティーに対する定義されたロールおよびポリシー以外に、追加の AWS 使用制限を課すことはできません。制限を課すことにより、Red Hat のインシデントへの対応が大幅に妨げられます。
  • ネイティブ AWS サービスを同じ AWS アカウントにデプロイできます。
  • Elastic Load Balancing (ELB) を設定するために必要なため、アカウントにはサービスにリンクされたロールが設定されている必要があります。以前に AWS アカウントでロードバランサーを作成していない場合は、ELB のサービスにリンクされたロールを作成する方法について、追加リソースの Elastic Load Balancing (ELB) サービスにリンクされたロールの作成リンクを参照してください。

    注記

    Red Hat OpenShift Service on AWS およびその他の Red Hat がサポートするサービスをホストする VPC とは別に、仮想プライベートクラウド (VPC) にリソースをデプロイすることを推奨しますが、必須ではありません。

2.1.2. アクセス要件

  • Red Hat には、顧客が提供した AWS アカウントへの AWS コンソールアクセス権が必要です。Red Hat は、このアクセスを保護および管理します。
  • Red Hat OpenShift Service on AWS (ROSA) クラスター内で権限を昇格するために AWS アカウントを使用しないでください。
  • ROSA CLI (rosa) または OpenShift Cluster Manager コンソールで利用可能なアクションは、AWS アカウントで直接実行しないでください。
  • ROSA クラスターをデプロイするために、事前に設定されたドメインは必要ありません。カスタムドメインを使用する場合は、追加のリソースを参照してください。

関連情報

2.1.3. サポート要件

  • Red Hat では、お客様が少なくとも AWS の ビジネスサポート を用意することを推奨します。
  • Red Hat は、お客様の代わりに AWS サポートをリクエストする許可をお客様から受けている場合があります。
  • Red Hat は、お客様のアカウントで AWS リソース制限の引き上げをリクエストする許可をお客様から受けている場合があります。
  • Red Hat は、この要件に関するセクションで指定されていない場合に、すべての Red Hat OpenShift Service on AWS クラスターについての制約、制限、予想される内容およびデフォルトの内容を管理します。

2.1.4. セキュリティー要件

  • Red Hat には、許可リストにある IP アドレスから EC2 ホストおよび API サーバーへの ingress アクセスが必要です。
  • Red Hat では、文書化されたドメインで egress を許可する必要があります。指定されたドメインについては、AWS ファイアウォールの前提条件セクションを参照してください。

2.1.5. OpenShift Cluster Manager を使用するための要件

以下のセクションでは、OpenShift Cluster Manager の要件について説明します。CLI ツールのみを使用する場合は、この要件を無視できます。

OpenShift Cluster Manager を使用するには、AWS アカウントをリンクする必要があります。このリンクの概念は、アカウントの関連付けとしても知られています。

2.1.5.1. AWS アカウントの関連付け

Red Hat OpenShift Service on AWS (ROSA) クラスタープロビジョニングタスクでは、Amazon リソースネーム (ARN) を使用して、IAM ロール ocm-role および user-role を AWS アカウントにリンクする必要があります。

ocm-role ARN は Red Hat 組織にラベルとして保存され、user-role ARN は Red Hat ユーザーアカウント内にラベルとして保存されます。Red Hat は、これらの ARN ラベルを使用して、ユーザーが有効なアカウント所有者であり、AWS アカウントで必要なタスクを実行するための正しいアクセス許可が利用可能であることを確認します。

2.1.5.2. AWS アカウントのリンク

Red Hat OpenShift Service on AWS (ROSA) CLI、rosa を使用して、AWS アカウントを既存の IAM ロールにリンクできます。

前提条件

  • AWS アカウントがある。
  • OpenShift Cluster Manager を使用してクラスターを作成しています。
  • AWS アカウント全体のロールをインストールするために必要な権限がある。詳細は、このセクションの関連情報を参照してください。
  • インストールホストに最新の AWS (aws) および ROSA (rosa) CLI をインストールして設定している。
  • ocm-role および user-role IAM ロールを作成しましたが、まだ AWS アカウントにリンクしていません。次のコマンドを実行して、IAM ロールがすでにリンクされているかどうかを確認できます。

    $ rosa list ocm-role
    $ rosa list user-role

    両方のロールの Linked 列に Yes が表示されている場合、ロールはすでに AWS アカウントにリンクされています。

手順

  1. CLI から、Amazon Resource Name (ARN) を使用して、ocm-role リソースを Red Hat 組織にリンクします。

    注記

    rosa link コマンドを実行するには、Red Hat Organization Administrator (組織管理者権限) が必要です。ocm-role リソースを AWS アカウントにリンクすると、組織内のすべてのユーザーに表示されます。

    $ rosa link ocm-role --role-arn <arn>

    出力例

    I: Linking OCM role
    ? Link the '<AWS ACCOUNT ID>` role with organization '<ORG ID>'? Yes
    I: Successfully linked role-arn '<AWS ACCOUNT ID>' with organization account '<ORG ID>'

  2. CLI から、Amazon Resource Name (ARN) を使用して、user-role リソースを Red Hat ユーザーアカウントにリンクします。

    $ rosa link user-role --role-arn <arn>

    出力例

    I: Linking User role
    ? Link the 'arn:aws:iam::<ARN>:role/ManagedOpenShift-User-Role-125' role with organization '<AWS ID>'? Yes
    I: Successfully linked role-arn 'arn:aws:iam::<ARN>:role/ManagedOpenShift-User-Role-125' with organization account '<AWS ID>'

関連情報

2.1.5.3. 複数の AWS アカウントを Red Hat 組織に関連付ける

複数の AWS アカウントを Red Hat 組織に関連付けることができます。複数のアカウントを関連付けると、Red Hat 組織の関連付けられた AWS アカウントのいずれかに Red Hat OpenShift Service on AWS (ROSA) クラスターを作成できます。

この機能を使用すると、リージョンにバインドされた環境として複数の AWS プロファイルを使用することにより、さまざまな AWS リージョンにクラスターを作成できます。

前提条件

  • AWS アカウントがある。
  • OpenShift Cluster Manager を使用してクラスターを作成しています。
  • AWS アカウント全体のロールをインストールするために必要な権限がある。
  • インストールホストに最新の AWS (aws) および ROSA (rosa) CLI をインストールして設定している。
  • ocm-role および user-role IAM ロールを作成している。

手順

追加の AWS アカウントを関連付けるには、最初にローカル AWS 設定でプロファイルを作成します。次に、追加の AWS アカウントに ocm-role、user、および account のロールを作成して、アカウントを Red Hat 組織に関連付けます。

追加のリージョンでロールを作成するには、rosa create コマンドの実行時に --profile <aws-profile> パラメーターを指定し、<aws_profile> を追加のアカウントプロファイル名に置き換えます。

  • OpenShift Cluster Manager ロールを作成するときに AWS アカウントプロファイルを指定するには、以下を実行します。

    $ rosa create --profile <aws_profile> ocm-role
  • ユーザーロールを作成するときに AWS アカウントプロファイルを指定するには、以下を実行します。

    $ rosa create --profile <aws_profile> user-role
  • アカウントロールを作成するときに AWS アカウントプロファイルを指定するには、以下を実行します。

    $ rosa create --profile <aws_profile> account-roles
注記

プロファイルを指定しない場合は、デフォルトの AWS プロファイルが使用されます。

2.2. オプトインリージョンでのクラスターデプロイの要件

AWS のオプトインリージョンは、デフォルトで有効になっていないリージョンです。オプトインリージョンで AWS Security Token Service (STS) を使用する Red Hat OpenShift Service on AWS (ROSA) クラスターをデプロイする場合には、以下の要件を満たす必要があります。

  • リージョンは AWS アカウントで有効にする必要があります。オプトインリージョンの有効化の詳細は、AWS ドキュメント AWS リージョンの管理 を参照してください。
  • AWS アカウントのセキュリティートークンバージョンは、バージョン 2 に設定する必要があります。オプトインリージョンにバージョン 1 セキュリティートークンを使用することはできません。

    重要

    セキュリティートークンのバージョン 2 に更新すると、トークンが長くなるため、トークンを保管するシステムに影響が出ることがあります。詳細は、the AWS documentation on setting STS preferences を参照してください。

2.2.1. AWS セキュリティートークンのバージョン設定

AWS のオプトインリージョンで AWS Security Token Service (STS) を使用して Red Hat OpenShift Service on AWS (ROSA) クラスターを作成する場合は、AWS アカウントでセキュリティートークンのバージョンをバージョン 2 に設定する必要があります。

前提条件

  • インストールホストに、最新の AWS CLI をインストールして設定している。

手順

  1. AWS CLI の設定で定義されている AWS アカウントの ID をリスト表示します。

    $ aws sts get-caller-identity --query Account --output json

    出力が該当する AWS アカウントの ID と一致していることを確認します。

  2. AWS アカウントに設定されているセキュリティートークンのバージョンを記載します。

    $ aws iam get-account-summary --query SummaryMap.GlobalEndpointTokenVersion --output json

    出力例

    1

  3. AWS アカウントの全リージョンのセキュリティートークンのバージョンをバージョン 2 に更新するには、以下のコマンドを実行します。

    $ aws iam set-security-token-service-preferences --global-endpoint-token-version v2Token
    重要

    セキュリティートークンのバージョン 2 に更新すると、トークンが長くなるため、トークンを保管するシステムに影響が出ることがあります。詳細は、the AWS documentation on setting STS preferences を参照してください。

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

STS デプロイメントモデルでは、Red Hat は Amazon Web Services (AWS) IAM ポリシー、IAM ユーザー、または IAM ロールを作成し、管理しなくなります。これらのロールとポリシーの作成については、IAM ロールに関する以下のセクションを参照してください。

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

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

2.4.1. EC2 インスタンス

AWS EC2 インスタンスは、AWS パブリッククラウドに ROSA のコントロールプレーンおよびデータプレーン機能をデプロイするために必要です。

インスタンスタイプは、ワーカーノードの数に応じてコントロールプレーンおよびインフラストラクチャーノードによって異なる場合があります。少なくとも、以下の EC2 インスタンスがデプロイされます。

  • 3 つの m5.2xlarge コントロールプレーンノード
  • 2 つの r5.xlarge インフラストラクチャーノード
  • 2 つの m5.xlarge カスタマイズ可能なワーカーノード

ワーカーノード数の詳細なガイダンスは、このページの関連情報セクションに一覧表示されている「制限およびスケーラビリティー」トピックの初期計画に関する考慮事項に関する情報を参照してください。

2.4.2. Amazon Elastic Block Store ストレージ

Amazon Elastic Block Store (Amazon EBS) ブロックストレージは、ローカルノードストレージと永続ボリュームストレージの両方に使用されます。

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

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

    • サイズ: 350GB
    • タイプ: gp3
    • 1 秒あたりの I/O 処理数: 1000
  • インフラストラクチャーボリューム

    • サイズ: 300GB
    • タイプ: gp3
    • 1 秒あたりの入出力操作: 900
  • ワーカーボリューム

    • サイズ: 300GB
    • タイプ: gp3
    • 1 秒あたりの入出力操作: 900
注記

OpenShift Container Platform 4.11 のリリースより前にデプロイされたクラスターは、デフォルトで gp2 タイプのストレージを使用します。

2.4.3. Elastic Load Balancing

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

2.4.4. S3 ストレージ

イメージレジストリーは、AWS S3 ストレージによって支えられています。S3 の使用およびクラスターのパフォーマンスを最適化するために、リソースのプルーニングを定期的に実行します。

注記

通常のサイズがそれぞれ 2TB の 2 つのバケットが必要です。

2.4.5. VPC

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

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

    注記

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

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

図2.1 サンプル VPC アーキテクチャー

VPC Reference Architecture

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

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

表2.1 デフォルトのセキュリティーグループに必要なポート
グループタイプIP プロトコルポート範囲

MasterSecurityGroup

AWS::EC2::SecurityGroup

icmp

0

tcp

22

tcp

6443

tcp

22623

WorkerSecurityGroup

AWS::EC2::SecurityGroup

icmp

0

tcp

22

BootstrapSecurityGroup

AWS::EC2::SecurityGroup

tcp

22

tcp

19531

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

既存の管理対象外の VPC を使用してクラスターを作成する場合、クラスターの作成中に追加のカスタムセキュリティーグループを追加できます。カスタムセキュリティーグループには次の制限があります。

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

2.6. 次のステップ

2.7. 関連情報

第3章 ROSA IAM ロールのリソース

Red Hat OpenShift Service on AWS (ROSA) Web UI では 、OpenShift Cluster Manager および rosa コマンドラインインターフェイス (CLI) でエンドユーザーエクスペリエンスを提供するための信頼関係を作成する AWS アカウントに対する特定の権限が必要です。

この信頼関係は ocm-role AWS IAM ロールの作成と関連付けによって実現されます。このロールには、Red Hat アカウントを AWS アカウントにリンクする AWS インストーラーとの信頼ポリシーがあります。さらに、Web UI ユーザーごとにuser-role AWS IAM ロールも必要です。これは、これらのユーザーを特定する役割を果たします。この user-role の AWS IAM ロールにはパーミッションがありません。

OpenShift Cluster Manager を使用するために必要な AWS IAM ロールは次のとおりです。

  • ocm-role
  • user-role

ROSA CLI (rosa) または OpenShift Cluster Manager Web UI のどちらを使用してクラスターを管理する場合でも ROSA CLI で account-roles と呼ばれるアカウント全体のロールを作成する必要があります。これらのアカウントのロールは最初のクラスターに必要であり、これらのロールは複数のクラスターで使用できます。これらの必要なアカウントロールは次のとおりです。

  • Worker-Role
  • Support-Role
  • Installer-Role
  • ControlPlane-Role
注記

ロールの作成では、AWS アクセスまたはシークレットキーは要求されません。このワークフローのベースとして、AWS Security Token Service (STS) が使用されます。AWS STS は、一時的な制限付きの認証情報を使用して認証を行います。

これらのロールの作成の詳細は、アカウント全体の IAM ロールとポリシー参照 を参照してください。

ROSA CLI では operator-roles と呼ばれるクラスター固有の Operator ロールは、バックエンドストレージ、Ingress、レジストリーの管理など、クラスター操作を実行するために必要な一時的なパーミッションを取得します。これらのロールは、作成するクラスターに必要です。これらの必要な Operator ロールは次のとおりです。

  • <cluster_name>-<hash>-openshift-cluster-csi-drivers-ebs-cloud-credentials
  • <cluster_name>-<hash>-openshift-cloud-network-config-controller-credentials
  • <cluster_name>-<hash>-openshift-machine-api-aws-cloud-credentials
  • <cluster_name>-<hash>-openshift-cloud-credential-operator-cloud-credentials
  • <cluster_name>-<hash>-openshift-image-registry-installer-cloud-credentials
  • <cluster_name>-<hash>-openshift-ingress-operator-cloud-credentials

これらのロールの作成の詳細は、クラスター固有の Operator IAM ロール参照 を参照してください。

3.1. ocm-role IAM リソースについて

ユーザーの Red Hat 組織が Red Hat OpenShift Service on AWS (ROSA) クラスターを作成できるようにするには ocm-role IAM リソースを作成する必要があります。AWS へのリンクのコンテキストでは、Red Hat 組織は OpenShift Cluster Manager 内の単一のユーザーです。

以下は、ocm-role IAM リソースに関するいくつかの考慮事項です。

  • Red Hat 組織ごとに 1 つの ocm-role IAM ロールのみをリンクできますが、AWS アカウントごとに任意の数の ocm-role IAM ロールを指定できます。Web UI では、一度にリンクできるのはこれらのロールの内 1 つだけです。
  • Red Hat 組織のすべてのユーザーは、ocm-roleIAM リソースを作成してリンクできます。
  • Red Hat Organization Administrator (組織管理者) のみが ocm-roleIAM IAM リソースのリンクを解除できます。この制限は、他の Red Hat 組織のメンバーが他のユーザーのインターフェイス機能を妨害しないように保護するためのものです。

    注記

    既存組織の一部ではない Red Hat アカウントを作成したばかりの場合、このアカウントは Red Hat Organization Administrator でもあります。

  • 基本および管理 ocm-role IAM リソースの AWS アクセス許可ポリシーのリストについては、このセクションの追加リソースの OpenShift Cluster Manager ロールについてを参照してください。

ROSA CLI (rosa) を使用すると、IAM リソースを作成するときにリンクできます。

注記

IAM リソースを AWS アカウントにリンクするまたは関連付けることは、ocm-role IAM ロールと Red Hat OpenShift Cluster Manager ロールを使用して信頼ポリシーを作成することを意味します。IAM リソースを作成してリンクすると、AWS の ocm-role IAM リソース と arn:aws:iam::7333:role/RH-Managed-OpenShift-Installer リソースとの信頼関係が表示されます。

Red Hat Organization Administrator (組織管理者) ocm-role IAM リソースを作成してリンクした後、すべての組織メンバーが独自の user-role IAM ロールを作成してリンクする場合もあります。この IAM リソースは、ユーザーごとに 1 回だけ作成およびリンクする必要があります。Red Hat 組織内の別のユーザーがすでに ocm-role IAM リソースを作成してリンクしている場合は、独自の user-role IAM ロールを作成してリンクしていることを確認する必要があります。

関連情報

3.1.1. ocm-role IAM ロールの作成

ocm-role IAM ロールは、コマンドラインインターフェイス (CLI) を使用して作成します。

前提条件

  • AWS アカウントがある。
  • OpenShift Cluster Manager 組織で Red Hat 組織管理者特権がある。
  • AWS アカウント全体のロールをインストールするために必要な権限がある。
  • インストールホストに、最新の Red Hat OpenShift Service on AWS (ROSA) CLI (rosa) をインストールして設定している。

手順

  • 基本的な権限を持つ ocm-role IAM ロールを作成するには、次のコマンドを実行します。

    $ rosa create ocm-role
  • 管理者権限を持つ ocm-role IAM ロールを作成するには、次のコマンドを実行します。

    $ rosa create ocm-role --admin

    このコマンドを使用すると、特定の属性を指定してロールを作成できます。次の出力例は、選択された自動モードを示しています。これにより、ROSA CLI (rosa) で Operator のロールとポリシーを作成できます。詳細は、関連情報に記載されているアカウント全体のロールの作成方法を参照してください。

出力例

I: Creating ocm role
? Role prefix: ManagedOpenShift 1
? Enable admin capabilities for the OCM role (optional): No 2
? Permissions boundary ARN (optional): 3
? Role Path (optional): 4
? Role creation mode: auto 5
I: Creating role using 'arn:aws:iam::<ARN>:user/<UserName>'
? Create the 'ManagedOpenShift-OCM-Role-182' role? Yes 6
I: Created role 'ManagedOpenShift-OCM-Role-182' with ARN  'arn:aws:iam::<ARN>:role/ManagedOpenShift-OCM-Role-182'
I: Linking OCM role
? OCM Role ARN: arn:aws:iam::<ARN>:role/ManagedOpenShift-OCM-Role-182 7
? Link the 'arn:aws:iam::<ARN>:role/ManagedOpenShift-OCM-Role-182' role with organization '<AWS ARN>'? Yes 8
I: Successfully linked role-arn 'arn:aws:iam::<ARN>:role/ManagedOpenShift-OCM-Role-182' with organization account '<AWS ARN>'

1
作成されたすべての AWS リソースの接頭辞値。この例では、ManagedOpenShift がすべての AWS リソースを付加します。
2
このロールに追加の管理者権限を付与するかどうかを選択します。
注記

--admin オプションを使用した場合、このプロンプトは表示されません。

3
パーミッション境界を設定するためのポリシーの Amazon Resource Name (ARN)。
4
ユーザー名の IAM パスを指定します。
5
AWS ロールの作成方法を選択します。auto を使用して、ROSA CLI はロールおよびポリシーを生成してリンクします。auto モードでは、AWS ロールを作成するためのいくつかの異なるプロンプトが表示されます。
6
auto メソッドは、接頭辞を使用して特定の ocm-role を作成するかどうかを尋ねます。
7
IAM ロールを OpenShift Cluster Manager に関連付けることを確認します。
8
作成したロールを AWS 組織にリンクします。

3.2. user-role IAM ロールについて

Web UI ユーザーごとに ユーザーロール IAM ロールを作成して、これらのユーザーが ROSA クラスターを作成できるようにする必要があります。

user-role IAM ロールに関するいくつかの考慮事項は次のとおりです。

  • Red Hat ユーザーアカウントごとに必要な user-role IAM ロールは 1 つだけですが、Red Hat 組織は IAM リソースの多くを持つことができます。
  • Red Hat 組織のすべてのユーザーは、user-role IAM ロールを作成してリンクできます。
  • Red Hat 組織の AWS アカウントごとに多数の user-role IAM ロールが存在する可能性があります。
  • Red Hat は、user-role IAM ロールを使用してユーザーを識別します。この IAM リソースには AWS アカウントのパーミッションがありません。
  • AWS アカウントは複数の user-role IAM ロールを指定できますが、各 IAM ロールを Red Hat 組織の各ユーザーにリンクする必要があります。ユーザーには、リンクされた user-role IAM ロールを複数指定できません。
注記

IAM リソースを AWS アカウントにリンクするまたは関連付けることは、user-role IAM ロールと Red Hat OpenShift Cluster Manager ロールを使用して信頼ポリシーを作成することを意味します。IAM リソースを作成してリンクすると、AWS の user-role IAM リソース と arn:aws:iam::710019948333:role/RH-Managed-OpenShift-Installer リソースとの信頼関係が表示されます。

3.2.1. ユーザーロール IAM ロールの作成

コマンドラインインターフェイス (CLI) を使用して、user-role IAM ロールを作成できます。

前提条件

  • AWS アカウントがある。
  • インストールホストに、最新の Red Hat OpenShift Service on AWS (ROSA) CLI (rosa) をインストールして設定している。

手順

  • 基本的な権限を持つ user-role IAM ロールを作成するには、次のコマンドを実行します。

    $ rosa create user-role

    このコマンドを使用すると、特定の属性を指定してロールを作成できます。次の出力例は、選択された自動モードを示しています。これにより、ROSA CLI (rosa) で Operator のロールとポリシーを作成できます。詳細は、関連情報の「自動および手動のデプロイメントモードについて」を参照してください。

出力例

I: Creating User role
? Role prefix: ManagedOpenShift 1
? Permissions boundary ARN (optional): 2
? Role Path (optional): 3
? Role creation mode: auto 4
I: Creating ocm user role using 'arn:aws:iam::2066:user'
? Create the 'ManagedOpenShift-User.osdocs-Role' role? Yes 5
I: Created role 'ManagedOpenShift-User.osdocs-Role' with ARN 'arn:aws:iam::2066:role/ManagedOpenShift-User.osdocs-Role'
I: Linking User role
? User Role ARN: arn:aws:iam::2066:role/ManagedOpenShift-User.osdocs-Role
? Link the 'arn:aws:iam::2066:role/ManagedOpenShift-User.osdocs-Role' role with account '1AGE'? Yes 6
I: Successfully linked role ARN 'arn:aws:iam::2066:role/ManagedOpenShift-User.osdocs-Role' with account '1AGE'

1
作成されたすべての AWS リソースの接頭辞値。この例では、ManagedOpenShift がすべての AWS リソースを付加します。
2
パーミッション境界を設定するためのポリシーの Amazon Resource Name (ARN)。
3
ユーザー名の IAM パスを指定します。
4
AWS ロールの作成方法を選択します。auto を使用して、ROSA CLI はロールおよびポリシーを生成してリンクします。auto モードでは、AWS ロールを作成するためのいくつかの異なるプロンプトが表示されます。
5
auto メソッドは、接頭辞を使用して特定の user-role を作成するかどうかを尋ねます。
6
作成したロールを AWS 組織にリンクします。
重要

クラスターを削除する前に user-role IAM ロールのリンクを解除または削除すると、エラーが発生してクラスターを削除できなくなります。削除プロセスを続行するには、このロールを作成または再リンクする必要があります。詳細は、削除できないクラスターの修復 を参照してください。

3.3. AWS アカウントの関連付け

Red Hat OpenShift Service on AWS (ROSA) クラスタープロビジョニングタスクでは、Amazon リソースネーム (ARN) を使用して、IAM ロール ocm-role および user-role を AWS アカウントにリンクする必要があります。

ocm-role ARN は Red Hat 組織にラベルとして保存され、user-role ARN は Red Hat ユーザーアカウント内にラベルとして保存されます。Red Hat は、これらの ARN ラベルを使用して、ユーザーが有効なアカウント所有者であり、AWS アカウントで必要なタスクを実行するための正しいアクセス許可が利用可能であることを確認します。

3.3.1. AWS アカウントのリンク

Red Hat OpenShift Service on AWS (ROSA) CLI、rosa を使用して、AWS アカウントを既存の IAM ロールにリンクできます。

前提条件

  • AWS アカウントがある。
  • OpenShift Cluster Manager を使用してクラスターを作成しています。
  • AWS アカウント全体のロールをインストールするために必要な権限がある。詳細は、このセクションの関連情報を参照してください。
  • インストールホストに最新の AWS (aws) および ROSA (rosa) CLI をインストールして設定している。
  • ocm-role および user-role IAM ロールを作成しましたが、まだ AWS アカウントにリンクしていません。次のコマンドを実行して、IAM ロールがすでにリンクされているかどうかを確認できます。

    $ rosa list ocm-role
    $ rosa list user-role

    両方のロールの Linked 列に Yes が表示されている場合、ロールはすでに AWS アカウントにリンクされています。

手順

  1. CLI から、Amazon Resource Name (ARN) を使用して、ocm-role リソースを Red Hat 組織にリンクします。

    注記

    rosa link コマンドを実行するには、Red Hat Organization Administrator (組織管理者権限) が必要です。ocm-role リソースを AWS アカウントにリンクすると、組織内のすべてのユーザーに表示されます。

    $ rosa link ocm-role --role-arn <arn>

    出力例

    I: Linking OCM role
    ? Link the '<AWS ACCOUNT ID>` role with organization '<ORG ID>'? Yes
    I: Successfully linked role-arn '<AWS ACCOUNT ID>' with organization account '<ORG ID>'

  2. CLI から、Amazon Resource Name (ARN) を使用して、user-role リソースを Red Hat ユーザーアカウントにリンクします。

    $ rosa link user-role --role-arn <arn>

    出力例

    I: Linking User role
    ? Link the 'arn:aws:iam::<ARN>:role/ManagedOpenShift-User-Role-125' role with organization '<AWS ID>'? Yes
    I: Successfully linked role-arn 'arn:aws:iam::<ARN>:role/ManagedOpenShift-User-Role-125' with organization account '<AWS ID>'

3.3.2. 複数の AWS アカウントを Red Hat 組織に関連付ける

複数の AWS アカウントを Red Hat 組織に関連付けることができます。複数のアカウントを関連付けると、Red Hat 組織の関連付けられた AWS アカウントのいずれかに Red Hat OpenShift Service on AWS (ROSA) クラスターを作成できます。

この機能を使用すると、リージョンにバインドされた環境として複数の AWS プロファイルを使用することにより、さまざまな AWS リージョンにクラスターを作成できます。

前提条件

  • AWS アカウントがある。
  • OpenShift Cluster Manager を使用してクラスターを作成しています。
  • AWS アカウント全体のロールをインストールするために必要な権限がある。
  • インストールホストに最新の AWS (aws) および ROSA (rosa) CLI をインストールして設定している。
  • ocm-role および user-role IAM ロールを作成している。

手順

追加の AWS アカウントを関連付けるには、最初にローカル AWS 設定でプロファイルを作成します。次に、追加の AWS アカウントに ocm-role、user、および account のロールを作成して、アカウントを Red Hat 組織に関連付けます。

追加のリージョンでロールを作成するには、rosa create コマンドの実行時に --profile <aws-profile> パラメーターを指定し、<aws_profile> を追加のアカウントプロファイル名に置き換えます。

  • OpenShift Cluster Manager ロールを作成するときに AWS アカウントプロファイルを指定するには、以下を実行します。

    $ rosa create --profile <aws_profile> ocm-role
  • ユーザーロールを作成するときに AWS アカウントプロファイルを指定するには、以下を実行します。

    $ rosa create --profile <aws_profile> user-role
  • アカウントロールを作成するときに AWS アカウントプロファイルを指定するには、以下を実行します。

    $ rosa create --profile <aws_profile> account-roles
注記

プロファイルを指定しない場合は、デフォルトの AWS プロファイルが使用されます。

3.4. インストーラーロールのパーミッション境界

インストーラーロールの パーミッション境界 としてポリシーを適用できます。AWS 管理ポリシーまたはカスタマー管理ポリシーを使用して、Amazon Web Services (AWS) アイデンティティーおよびアクセス管理 (IAM) エンティティー (ユーザーまたはロール) の境界を設定できます。ポリシーと境界ポリシーの組み合わせにより、ユーザーまたはロールが最大限アクセスできるパーミッションを制限できます。インストーラーポリシー自体の変更がサポートされていないため、ROSA には、インストーラーロールの権限を制限できる 3 つの準備されたパーミッション境界ポリシーファイルのセットが含まれています。

注記

この機能は、Red Hat OpenShift Service on AWS (クラシックアーキテクチャー) クラスターでのみサポートされます。

パーミッション境界ポリシーファイルは以下のとおりです。

  • Core 境界ポリシーファイルには、ROSA (クラシックアーキテクチャー) インストーラーが Red Hat OpenShift Service on AWS クラスターをインストールするために必要な最小限の権限が含まれています。インストーラーには、仮想プライベートクラウド (VPC) または PrivateLink (PL) を作成する権限がありません。VPC を指定する必要があります。
  • VPC 境界ポリシーファイルには、ROSA (クラシックアーキテクチャー) インストーラーが VPC を作成/管理するために必要最小限の権限が含まれています。PL またはコアインストールのアクセス許可は含まれません。インストーラーがクラスターをインストールして VPC を作成/管理するのに十分な権限を持つクラスターをインストールする必要があり、PL を設定する必要がない場合は、インストーラーロールとともにコアファイルと VPC 境界ファイルを使用します。
  • PrivateLink (PL) 境界ポリシーファイルには、ROSA (クラシックアーキテクチャー) インストーラーがクラスターを使用して AWS PL を作成するために必要最小限の権限が含まれています。VPC またはコアのインストールの権限は含まれません。インストール中に、すべての PL クラスターに対して事前に作成された VPC を提供します。

パーミッション境界ポリシーファイルを使用する場合は、以下の組み合わせが適用されます。

  • パーミッション境界ポリシーがない場合、完全なインストーラーポリシー権限がクラスターに適用されます。
  • Core は、インストーラーロールに対して最も限定的な権限だけを設定します。VPC および PL 権限は Core only の境界ポリシーに含まれません。

    • インストーラーは VPC または PL を作成または管理できません。
    • 顧客が提供する VPC が必要であり、PrivateLink (PL) は利用できません。
  • Core + VPC は、インストーラーロールのコアおよび VPC パーミッションを設定します。

    • インストーラーは PL を作成または管理できません。
    • カスタム/BYO-VPC を使用していないことを前提としています。
    • インストーラーが VPC を作成して管理することを前提としています。
  • Core + PrivateLink (PL) は、インストーラーが PL インフラストラクチャーをプロビジョニングできることを意味します。

    • お客様が提供する VPC が必要です。
    • これは、PL のプライベートクラスター用です。

この例の手順は、ROSA の Core インストーラーのパーミッション境界ポリシーのみを使用して、権限が最も制限されたインストーラーロールおよびポリシーに適用できます。これは、AWS コンソールまたは AWS CLI を使用して実行できます。この例では、AWS CLI と次のポリシーを使用します。

例3.1 sts_installer_core_permission_boundary_policy.json

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Effect": "Allow",
            "Action": [
		    "autoscaling:DescribeAutoScalingGroups",
		    "ec2:AllocateAddress",
		    "ec2:AssociateAddress",
		    "ec2:AttachNetworkInterface",
		    "ec2:AuthorizeSecurityGroupEgress",
		    "ec2:AuthorizeSecurityGroupIngress",
		    "ec2:CopyImage",
		    "ec2:CreateNetworkInterface",
		    "ec2:CreateSecurityGroup",
		    "ec2:CreateTags",
		    "ec2:CreateVolume",
		    "ec2:DeleteNetworkInterface",
		    "ec2:DeleteSecurityGroup",
		    "ec2:DeleteSnapshot",
		    "ec2:DeleteTags",
		    "ec2:DeleteVolume",
		    "ec2:DeregisterImage",
		    "ec2:DescribeAccountAttributes",
		    "ec2:DescribeAddresses",
		    "ec2:DescribeAvailabilityZones",
		    "ec2:DescribeDhcpOptions",
		    "ec2:DescribeImages",
		    "ec2:DescribeInstanceAttribute",
		    "ec2:DescribeInstanceCreditSpecifications",
		    "ec2:DescribeInstances",
		    "ec2:DescribeInstanceStatus",
		    "ec2:DescribeInstanceTypeOfferings",
		    "ec2:DescribeInstanceTypes",
		    "ec2:DescribeInternetGateways",
		    "ec2:DescribeKeyPairs",
		    "ec2:DescribeNatGateways",
		    "ec2:DescribeNetworkAcls",
		    "ec2:DescribeNetworkInterfaces",
		    "ec2:DescribePrefixLists",
		    "ec2:DescribeRegions",
		    "ec2:DescribeReservedInstancesOfferings",
		    "ec2:DescribeRouteTables",
		    "ec2:DescribeSecurityGroups",
		    "ec2:DescribeSecurityGroupRules",
		    "ec2:DescribeSubnets",
		    "ec2:DescribeTags",
		    "ec2:DescribeVolumes",
		    "ec2:DescribeVpcAttribute",
		    "ec2:DescribeVpcClassicLink",
		    "ec2:DescribeVpcClassicLinkDnsSupport",
		    "ec2:DescribeVpcEndpoints",
		    "ec2:DescribeVpcs",
		    "ec2:GetConsoleOutput",
		    "ec2:GetEbsDefaultKmsKeyId",
		    "ec2:ModifyInstanceAttribute",
		    "ec2:ModifyNetworkInterfaceAttribute",
		    "ec2:ReleaseAddress",
		    "ec2:RevokeSecurityGroupEgress",
		    "ec2:RevokeSecurityGroupIngress",
		    "ec2:RunInstances",
		    "ec2:StartInstances",
		    "ec2:StopInstances",
		    "ec2:TerminateInstances",
		    "elasticloadbalancing:AddTags",
		    "elasticloadbalancing:ApplySecurityGroupsToLoadBalancer",
		    "elasticloadbalancing:AttachLoadBalancerToSubnets",
		    "elasticloadbalancing:ConfigureHealthCheck",
		    "elasticloadbalancing:CreateListener",
		    "elasticloadbalancing:CreateLoadBalancer",
		    "elasticloadbalancing:CreateLoadBalancerListeners",
		    "elasticloadbalancing:CreateTargetGroup",
		    "elasticloadbalancing:DeleteLoadBalancer",
		    "elasticloadbalancing:DeleteTargetGroup",
		    "elasticloadbalancing:DeregisterInstancesFromLoadBalancer",
		    "elasticloadbalancing:DeregisterTargets",
		    "elasticloadbalancing:DescribeInstanceHealth",
		    "elasticloadbalancing:DescribeListeners",
		    "elasticloadbalancing:DescribeLoadBalancerAttributes",
		    "elasticloadbalancing:DescribeLoadBalancers",
		    "elasticloadbalancing:DescribeTags",
		    "elasticloadbalancing:DescribeTargetGroupAttributes",
		    "elasticloadbalancing:DescribeTargetGroups",
		    "elasticloadbalancing:DescribeTargetHealth",
		    "elasticloadbalancing:ModifyLoadBalancerAttributes",
		    "elasticloadbalancing:ModifyTargetGroup",
		    "elasticloadbalancing:ModifyTargetGroupAttributes",
		    "elasticloadbalancing:RegisterInstancesWithLoadBalancer",
		    "elasticloadbalancing:RegisterTargets",
		    "elasticloadbalancing:SetLoadBalancerPoliciesOfListener",
		    "iam:AddRoleToInstanceProfile",
		    "iam:CreateInstanceProfile",
		    "iam:DeleteInstanceProfile",
		    "iam:GetInstanceProfile",
		    "iam:TagInstanceProfile",
		    "iam:GetRole",
		    "iam:GetRolePolicy",
		    "iam:GetUser",
		    "iam:ListAttachedRolePolicies",
		    "iam:ListInstanceProfiles",
		    "iam:ListInstanceProfilesForRole",
		    "iam:ListRolePolicies",
		    "iam:ListRoles",
		    "iam:ListUserPolicies",
		    "iam:ListUsers",
		    "iam:PassRole",
		    "iam:RemoveRoleFromInstanceProfile",
		    "iam:SimulatePrincipalPolicy",
		    "iam:TagRole",
		    "iam:UntagRole",
		    "route53:ChangeResourceRecordSets",
		    "route53:ChangeTagsForResource",
		    "route53:CreateHostedZone",
		    "route53:DeleteHostedZone",
		    "route53:GetAccountLimit",
		    "route53:GetChange",
		    "route53:GetHostedZone",
		    "route53:ListHostedZones",
		    "route53:ListHostedZonesByName",
		    "route53:ListResourceRecordSets",
		    "route53:ListTagsForResource",
		    "route53:UpdateHostedZoneComment",
		    "s3:CreateBucket",
		    "s3:DeleteBucket",
		    "s3:DeleteObject",
		    "s3:GetAccelerateConfiguration",
		    "s3:GetBucketAcl",
		    "s3:GetBucketCORS",
		    "s3:GetBucketLocation",
		    "s3:GetBucketLogging",
		    "s3:GetBucketObjectLockConfiguration",
		    "s3:GetBucketPolicy",
		    "s3:GetBucketRequestPayment",
		    "s3:GetBucketTagging",
		    "s3:GetBucketVersioning",
		    "s3:GetBucketWebsite",
		    "s3:GetEncryptionConfiguration",
		    "s3:GetLifecycleConfiguration",
		    "s3:GetObject",
		    "s3:GetObjectAcl",
		    "s3:GetObjectTagging",
		    "s3:GetObjectVersion",
		    "s3:GetReplicationConfiguration",
		    "s3:ListBucket",
		    "s3:ListBucketVersions",
		    "s3:PutBucketAcl",
		    "s3:PutBucketTagging",
		    "s3:PutEncryptionConfiguration",
		    "s3:PutObject",
		    "s3:PutObjectAcl",
		    "s3:PutObjectTagging",
		    "servicequotas:GetServiceQuota",
		    "servicequotas:ListAWSDefaultServiceQuotas",
		    "sts:AssumeRole",
		    "sts:AssumeRoleWithWebIdentity",
		    "sts:GetCallerIdentity",
		    "tag:GetResources",
		    "tag:UntagResources",
		    "kms:DescribeKey",
		    "cloudwatch:GetMetricData",
		    "ec2:CreateRoute",
		    "ec2:DeleteRoute",
		    "ec2:CreateVpcEndpoint",
		    "ec2:DeleteVpcEndpoints",
		    "ec2:CreateVpcEndpointServiceConfiguration",
		    "ec2:DeleteVpcEndpointServiceConfigurations",
		    "ec2:DescribeVpcEndpointServiceConfigurations",
		    "ec2:DescribeVpcEndpointServicePermissions",
		    "ec2:DescribeVpcEndpointServices",
		    "ec2:ModifyVpcEndpointServicePermissions"
            ],
            "Resource": "*"
        },
        {
            "Effect": "Allow",
            "Action": [
                "secretsmanager:GetSecretValue"
            ],
            "Resource": "*",
            "Condition": {
                "StringEquals": {
                    "aws:ResourceTag/red-hat-managed": "true"
                }
            }
        }
    ]
}
重要

パーミッション境界を使用するには、パーミッション境界ポリシーを準備し、AWS IAM の関連するインストーラーロールに追加する必要があります。ROSA (rosa) CLI は、パーミッション境界機能を提供しますが、これはインストーラーロールだけでなくすべてのロールに適用されるため、提供されているパーミッション境界ポリシー (インストーラーロールのみ対象) では機能しません。

前提条件

  • AWS アカウントがある。
  • AWS のロールとポリシーの管理に必要な権限がある。
  • ワークステーションに最新の AWS (aws) および ROSA (rosa) CLI をインストールして設定している。
  • インストーラーロールと対応するポリシーを含む ROSA アカウント全体のロールがすでに準備されている。これらが AWS アカウントに存在しない場合は、関連情報 のアカウント全体の STS ロールとポリシーの作成を参照してください。

手順

  1. rosa CLI で次のコマンドを入力して、ポリシーファイルを準備します。

    $ curl -o ./rosa-installer-core.json https://raw.githubusercontent.com/openshift/managed-cluster-config/master/resources/sts/4.16/sts_installer_core_permission_boundary_policy.json
  2. 次のコマンドを入力して、AWS でポリシーを作成し、Amazon Resource Name (ARN) を収集します。

    $ aws iam create-policy \
    --policy-name rosa-core-permissions-boundary-policy \
    --policy-document file://./rosa-installer-core.json \
    --description "ROSA installer core permission boundary policy, the minimum permission set, allows BYO-VPC, disallows PrivateLink"

    出力例

    {
        "Policy": {
            "PolicyName": "rosa-core-permissions-boundary-policy",
            "PolicyId": "<Policy ID>",
            "Arn": "arn:aws:iam::<account ID>:policy/rosa-core-permissions-boundary-policy",
            "Path": "/",
            "DefaultVersionId": "v1",
            "AttachmentCount": 0,
            "PermissionsBoundaryUsageCount": 0,
            "IsAttachable": true,
            "CreateDate": "<CreateDate>",
            "UpdateDate": "<UpdateDate>"
        }
    }

  3. 次のコマンドを入力して、制限するインストーラーロールにアクセス許可境界ポリシーを追加します。

    $ aws iam put-role-permissions-boundary \
    --role-name ManagedOpenShift-Installer-Role \
    --permissions-boundary arn:aws:iam::<account ID>:policy/rosa-core-permissions-boundary-policy
  4. rosa CLI で次のコマンドを入力して、インストーラーロールを表示し、添付されたポリシー (パーミッション境界を含む) を検証します。

    $ aws iam get-role --role-name ManagedOpenShift-Installer-Role \
    --output text | grep PERMISSIONSBOUNDARY

    出力例

    PERMISSIONSBOUNDARY	arn:aws:iam::<account ID>:policy/rosa-core-permissions-boundary-policy	Policy

    PL および VPC パーミッション境界ポリシーのその他の例については、以下を参照してください。

    例3.2 sts_installer_privatelink_permission_boundary_policy.json

    {
    "Version": "2012-10-17",
      "Statement": [
        {
          "Effect": "Allow",
          "Action": [
            "ec2:ModifyVpcEndpointServiceConfiguration",
            "route53:ListHostedZonesByVPC",
            "route53:CreateVPCAssociationAuthorization",
            "route53:AssociateVPCWithHostedZone",
            "route53:DeleteVPCAssociationAuthorization",
            "route53:DisassociateVPCFromHostedZone",
            "route53:ChangeResourceRecordSets"
          ],
          "Resource": "*"
        }
      ]
    }

    例3.3 sts_installer_vpc_permission_boundary_policy.json

    {
         "Version": "2012-10-17",
        "Statement": [
            {
                "Effect": "Allow",
                "Action": [
    		    "ec2:AssociateDhcpOptions",
    		    "ec2:AssociateRouteTable",
    		    "ec2:AttachInternetGateway",
    		    "ec2:CreateDhcpOptions",
    		    "ec2:CreateInternetGateway",
    		    "ec2:CreateNatGateway",
    		    "ec2:CreateRouteTable",
    		    "ec2:CreateSubnet",
    		    "ec2:CreateVpc",
    		    "ec2:DeleteDhcpOptions",
    		    "ec2:DeleteInternetGateway",
    		    "ec2:DeleteNatGateway",
    		    "ec2:DeleteRouteTable",
    		    "ec2:DeleteSubnet",
    		    "ec2:DeleteVpc",
    		    "ec2:DetachInternetGateway",
    		    "ec2:DisassociateRouteTable",
    		    "ec2:ModifySubnetAttribute",
    		    "ec2:ModifyVpcAttribute",
    		    "ec2:ReplaceRouteTableAssociation"
                ],
                "Resource": "*"
            }
        ]
    }

3.5. 関連情報

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

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

4.1. クラスターの最大数

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

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

注記

すべてのテストで使用される OpenShift Container Platform バージョンは OCP 4.8.0 です。

表4.1 テスト済みのクラスターの最大値
最大値のタイプ4.8 テスト済みの最大値

ノード数

102

Pod 数 [1]

20,400

ノードあたりの Pod 数

250

コアあたりの Pod 数

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

namespace 数 [2]

3,400

namespace あたりの Pod 数 [3]

20,400

サービス数 [4]

10,000

namespace あたりのサービス数

10,000

サービスあたりのバックエンド数

10,000

namespace あたりのデプロイメント数 [3]

1,000

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

OpenShift Container Platform 4.8 では、CPU コア (500 ミリコア) の半分がシステムによって予約されます (OpenShift Container Platform の以前のバージョンと比較)。

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

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

ノードタイプvCPURAM(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 はメモリーリソースがないために負荷がかかり、失敗する可能性があります。

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

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

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

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

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

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

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

1 から 25

m5.2xlarge

r5.xlarge

26 から 100

m5.4xlarge

r5.2xlarge

101 から 180

m5.8xlarge

r5.4xlarge

注記

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

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

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

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

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

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

  • コントロールプレーンノードは、クラシック ROSA クラスターで平均 66% 以上の使用率を維持します。

    注記

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

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

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

  • インフラストラクチャーノードは、2 つのインフラストラクチャーノードを使用するアベイラビリティーゾーンが 1 つあるクラシック ROSA クラスターで、平均 50% 以上の使用率を維持します。
  • インフラストラクチャーノードは、3 つのインフラストラクチャーノードを使用するアベイラビリティーゾーンが 複数あるクラシック ROSA クラスターで、平均 66% 以上の使用率を維持します。

    注記

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

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

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

スケーリングが適用されると、サービスログエントリーを通じて顧客に通知されます。サービスログの詳細については、ROSA クラスターのサービスログへのアクセス を参照してください。

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

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

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

4.4. 次のステップ

4.5. 関連情報

第5章 環境のプランニング

5.1. テスト済みのクラスターの最大値に基づく環境計画

本書では、テスト済みのクラスターの最大値に基づいて、AWS での Red Hat OpenShift Service 環境をプランニングする方法を説明します。

ノード上で物理リソースを過剰にサブスクライブすると、Kubernetes スケジューラーが Pod の配置時に行うリソースの保証に影響が及びます。メモリースワップを防ぐために実行できる処置について確認してください。

一部のテスト済みの最大値については、単一の namespace/ユーザーが作成するオブジェクトでのみ変更されます。これらの制限はクラスター上で数多くのオブジェクトが実行されている場合には異なります。

本書に記載されている数は、Red Hat のテスト方法、セットアップ、設定、およびチューニングに基づいています。これらの数は、独自のセットアップおよび環境に応じて異なります。

環境の計画時に、以下の式を使用して、ノードに配置できる Pod の数を判別します。

required pods per cluster / pods per node = total number of nodes needed

ノードあたりの現在の Pod の最大数は 250 です。ただし、ノードに適合する Pod 数はアプリケーション自体によって異なります。アプリケーション要件を基にした環境計画 で説明されているように、アプリケーションのメモリー、CPU、およびストレージ要件を検討してください。

シナリオ例

クラスターごとに 2200 の Pod のあるクラスターのスコープを設定する場合、ノードごとに最大 250 の Pod があることを前提として、最低でも 9 つのノードが必要になります。

2200 / 250 = 8.8

ノード数を 20 に増やす場合は、Pod 配分がノードごとに 110 の Pod に変わります。

2200 / 20 = 110

ここでは、以下のようになります。

required pods per cluster / total number of nodes = expected pods per node

5.2. アプリケーション要件に基づく環境計画

本書では、アプリケーション要件に応じて AWS 上の Red Hat OpenShift Service 環境をプランニングする方法を説明します。

アプリケーション環境の例を考えてみましょう。

Pod タイプPod 数最大メモリーCPU コア数永続ストレージ

apache

100

500 MB

0.5

1 GB

node.js

200

1 GB

1

1 GB

postgresql

100

1 GB

2

10 GB

JBoss EAP

100

1 GB

1

1 GB

推定要件: CPU コア 550 個、メモリー 450 GB、および 1.4 TB ストレージ

ノードのインスタンスサイズは、希望に応じて増減を調整できます。ノードのリソースはオーバーコミットされることが多く、デプロイメントシナリオでは、小さいノードで数を増やしたり、大きいノードで数を減らしたりして、同じリソース量を提供することもできます。このデプロイメントシナリオでは、小さいノードで数を増やしたり、大きいノードで数を減らしたりして、同じリソース量を提供することもできます。運用上の敏捷性やインスタンスあたりのコストなどの要因を考慮する必要があります。

ノードのタイプ数量CPURAM (GB)

ノード (オプション 1)

100

4

16

ノード (オプション 2)

50

8

32

ノード (オプション 3)

25

16

64

アプリケーションによってはオーバーコミットの環境に適しているものもあれば、そうでないものもあります。たとえば、Java アプリケーションや Huge Page を使用するアプリケーションの多くは、オーバーコミットに対応できません。対象のメモリーは、他のアプリケーションに使用できません。上記の例では、環境は一般的な比率として約 30 % オーバーコミットされています。

アプリケーション Pod は環境変数または DNS のいずれかを使用してサービスにアクセスできます。環境変数を使用する場合、それぞれのアクティブなサービスについて、変数が Pod がノードで実行される際に kubelet によって挿入されます。クラスター対応の DNS サーバーは、Kubernetes API で新規サービスの有無を監視し、それぞれに DNS レコードのセットを作成します。DNS がクラスター全体で有効にされている場合、すべての Pod は DNS 名でサービスを自動的に解決できるはずです。DNS を使用したサービス検出は、5000 サービスを超える使用できる場合があります。サービス検出に環境変数を使用し、namespace で 5000 サービスを超える場合に引数のリストが許可される長さを超えると、Pod およびデプロイメントが失敗し始めます。

デプロイメントのサービス仕様ファイルのサービスリンクを無効にして、以下を解消します。

Kind: Template
apiVersion: template.openshift.io/v1
metadata:
  name: deploymentConfigTemplate
  creationTimestamp:
  annotations:
    description: This template will create a deploymentConfig with 1 replica, 4 env vars and a service.
    tags: ''
objects:
  - kind: DeploymentConfig
    apiVersion: apps.openshift.io/v1
    metadata:
      name: deploymentconfig${IDENTIFIER}
    spec:
      template:
        metadata:
          labels:
            name: replicationcontroller${IDENTIFIER}
        spec:
          enableServiceLinks: false
          containers:
          - name: pause${IDENTIFIER}
            image: "${IMAGE}"
            ports:
            - containerPort: 8080
              protocol: TCP
            env:
            - name: ENVVAR1_${IDENTIFIER}
              value: "${ENV_VALUE}"
            - name: ENVVAR2_${IDENTIFIER}
              value: "${ENV_VALUE}"
            - name: ENVVAR3_${IDENTIFIER}
              value: "${ENV_VALUE}"
            - name: ENVVAR4_${IDENTIFIER}
              value: "${ENV_VALUE}"
            resources: {}
            imagePullPolicy: IfNotPresent
            capabilities: {}
            securityContext:
              capabilities: {}
              privileged: false
          restartPolicy: Always
          serviceAccount: ''
      replicas: 1
      selector:
        name: replicationcontroller${IDENTIFIER}
      triggers:
      - type: ConfigChange
      strategy:
        type: Rolling
  - kind: Service
    apiVersion: v1
    metadata:
      name: service${IDENTIFIER}
    spec:
      selector:
        name: replicationcontroller${IDENTIFIER}
      ports:
      - name: serviceport${IDENTIFIER}
        protocol: TCP
        port: 80
        targetPort: 8080
      portalIP: ''
      type: ClusterIP
      sessionAffinity: None
    status:
      loadBalancer: {}
  parameters:
  - name: IDENTIFIER
    description: Number to append to the name of resources
    value: '1'
    required: true
  - name: IMAGE
    description: Image to use for deploymentConfig
    value: gcr.io/google-containers/pause-amd64:3.0
    required: false
  - name: ENV_VALUE
    description: Value to use for environment variables
    generate: expression
    from: "[A-Za-z0-9]{255}"
    required: false
  labels:
template: deploymentConfigTemplate

namespace で実行できるアプリケーション Pod の数は、環境変数がサービス検出に使用される場合にサービスの数およびサービス名の長さによって異なります。システムの ARG_MAX は、新規プロセスの引数の最大の長さを定義し、デフォルトで 2097152 バイト (2 MiB) に設定されます。kubelet は、以下を含む namespace で実行するようにスケジュールされる各 Pod に環境変数を挿入します。

  • <SERVICE_NAME>_SERVICE_HOST=<IP>
  • <SERVICE_NAME>_SERVICE_PORT=<PORT>
  • <SERVICE_NAME>_PORT=tcp://<IP>:<PORT>
  • <SERVICE_NAME>_PORT_<PORT>_TCP=tcp://<IP>:<PORT>
  • <SERVICE_NAME>_PORT_<PORT>_TCP_PROTO=tcp
  • <SERVICE_NAME>_PORT_<PORT>_TCP_PORT=<PORT>
  • <SERVICE_NAME>_PORT_<PORT>_TCP_ADDR=<ADDR>

引数の長さが許可される値を超え、サービス名の文字数がこれに影響を及ぼす場合は、namespace の Pod が起動に失敗し始めます。

第6章 必要な AWS サービスクォータ

Red Hat OpenShift Service on AWS クラスターの実行に必要な Amazon Web Service (AWS) サービスクォータのリストを確認します。

6.1. 必要な AWS サービスクォータ

以下の表は、1 つの Red Hat OpenShift Service on AWS クラスターを作成して実行するために必要な AWS サービスのクォータとレベルを示しています。ほとんどのデフォルト値は大抵のワークロードに適していますが、次の場合には追加クォータのリクエストが必要になることがあります。

  • ROSA (クラシックアーキテクチャー) クラスターでは、クラスターの作成、可用性、およびアップグレードを提供するために、最低 100 vCPU の AWS EC2 サービスクォータが必要です。実行中のオンデマンド標準 Amazon EC2 インスタンスに割り当てられる vCPU のデフォルトの最大値は 5 です。したがって、以前に同じ AWS アカウントを使用して ROSA クラスターを作成したことがない場合は、Running On-Demand Standard (A, C, D, H, I, M, R, T, Z) instances を実行するための追加の EC2 クォータをリクエストする必要があります。
  • カスタムセキュリティーグループなど、一部のオプションのクラスター設定機能により、追加クォータのリクエストが必要になることがあります。たとえば、ROSA はデフォルトで 1 つのセキュリティーグループをワーカーマシンプールのネットワークインターフェイスに関連付けますが、Security groups per network interface のデフォルトのクォータは 5 であるため、5 つのカスタムセキュリティーグループを追加するには、追加のクォータをリクエストする必要があります。セキュリティーグループを追加すると、ワーカーのネットワークインターフェイス上のセキュリティーグループが、合計 6 つになるためです。
注記

AWS SDK を使用すると、ROSA はクォータをチェックできますが、AWS SDK の計算では、既存の使用量が考慮されません。そのため、クォータチェックが AWS SDK で合格しても、クラスターの作成が失敗する可能性があります。この問題を修正するには、クォータを増やします。

特定のクォータを変更または増やす必要がある場合は、Amazon のドキュメントの requesting a quota inscrease を参照してください。大きなクォータリクエストはレビューのために Amazon サポートに送信され、承認されるまでに時間がかかります。クォータリクエストが緊急の場合は、AWS サポートにお問い合わせください。

表6.1 ROSA に必要なサービスクォータ
クォータ名サービスコードクォータコードAWS のデフォルト最小要件説明

Running On-Demand Standard (A, C, D, H, I, M, R, T, Z) instances

ec2

L-1216C47A

5

100

オンデマンド標準 (A、C、D、H、I、M、R、T、Z) インスタンスの実行に割り当てられる vCPU の最大数。

デフォルト値の 5 vCPU は、ROSA クラスターを作成するには不十分です。ROSA では、クラスター作成に必要な vCPU は最低 100 個です。

Storage for General Purpose SSD (gp2) volume storage in TiB

ebs

L-D18FCD1D

50

300

このリージョンの汎用 SSD (gp2) ボリューム全体にプロビジョニングできるストレージの最大集計量 (TiB 単位)。

Storage for General Purpose SSD (gp3) volume storage in TiB

ebs

L-7A658B76

50

300

このリージョンの汎用 SSD (gp3) ボリューム全体にプロビジョニングできるストレージの最大集計量 (TiB 単位)。

最適なパフォーマンスを得るには、300 TiB のストレージが最低限必要です。

Storage for Provisioned IOPS SSD (io1) volumes in TiB

ebs

L-FD252861

50

300

このリージョンのプロビジョンド IOPS SSD (io1) ボリューム全体にプロビジョニングできるストレージの最大集計量 (TiB 単位)。

最適なパフォーマンスを得るには、300 TiB のストレージが最低限必要です。

表6.2 一般的な AWS サービスクォータ
クォータ名サービスコードクォータコードAWS のデフォルト最小要件説明

EC2-VPC Elastic IPs

ec2

L-0263D0A3

5

5

このリージョンで EC2-VPC に割り当てることができる Elastic IP アドレスの最大数。

VPCs per Region

vpc

L-F678F1CE

5

5

リージョンあたりの VPC の最大数。このクォータは、リージョンあたりのインターネットゲートウェイの最大数に直接関係しています。

Internet gateways per Region

vpc

L-A4707A72

5

5

リージョンあたりのインターネットゲートウェイの最大数。このクォータは、リージョンあたりの VPC の最大数に直接関係しています。このクォータを増やすには、リージョンあたりの VPC の数を増やします。

Network interfaces per Region

vpc

L-DF5E4CA3

5,000

5,000

リージョンあたりのネットワークインターフェイスの最大数。

Security groups per network interface

vpc

L-2AFB9258

5

5

ネットワークインターフェイスごとのセキュリティーグループの最大数。セキュリティーグループごとのルール数のクォータとこのクォータを掛けた値が 1000 を超えることはできません。

Snapshots per Region

ebs

L-309BACF6

10,000

10,000

リージョンあたりのスナップショットの最大数

IOPS for Provisioned IOPS SSD (Io1) volumes

ebs

L-B3A130E6

300,000

300,000

このリージョンのプロビジョンド IOPS SSD (io1) ボリューム全体にプロビジョニングできる IOPS の最大集計数。

Application Load Balancers per Region

elasticloadbalancing

L-53DA6B97

50

50

各リージョンに存在できる Application Load Balancer の最大数。

Classic Load Balancers per Region

elasticloadbalancing

L-E9E9831D

20

20

各リージョンに存在できる Classic Load Balancer の最大数。

6.1.1. 関連情報

6.2. 次のステップ

第7章 STS を使用するための環境の設定

AWS の前提条件を満たしていることを確認した後に、環境を設定し、Red Hat OpenShift Service on AWS (ROSA) をインストールします。

ヒント

AWS Security Token Service (STS) は、セキュリティーが強化されているため、Red Hat OpenShift Service on AWS (ROSA) にクラスターをインストールして操作するのに推奨される認証情報モードです。

7.1. STS のための環境の設定

AWS Security Token Service (STS) を使用する Red Hat OpenShift Service on AWS (ROSA) クラスターを作成する前に、次の手順を実行して環境をセットアップします。

前提条件

  • デプロイメントの前提条件およびポリシーを確認し、完了している。
  • Red Hat アカウント がない場合は作成している。次に、確認リンクについてのメールを確認する。ROSA をインストールするには認証情報が必要です。

手順

  1. 使用する Amazon Web Services (AWS) アカウントにログインします。

    実稼働クラスターを実行するには、専用の AWS アカウントを使用することが推奨されます。AWS Organizations を使用している場合は、組織内の AWS アカウントを使用するか、アカウントを新規作成 できます。

    AWS Organizations を使用しており、使用する予定の AWS アカウントにサービスコントロールポリシー (SCP) を適用する必要がある場合、これらのポリシーは、クラスターが必要とするロールおよびポリシーよりも制限的なものである必要はありません。

  2. AWS マネジメントコンソールで ROSA サービスを有効にします。

    1. AWS アカウント にサインインします。
    2. ROSA を有効にするには、ROSA service に移動し、Enable OpenShift を選択します。
  3. AWS CLI をインストールし、設定します。

    1. AWS コマンドラインインターフェイスのドキュメントを参照し、オペレーティングシステムの AWS CLI を インストール し、設定 します。

      .aws/credentials ファイルで正しい aws_access_key_id および aws_secret_access_key を指定します。AWS ドキュメントの AWS 設定の基本 を参照してください。

    2. デフォルトの AWS リージョンを設定します。

      注記

      環境変数を使用してデフォルトの AWS リージョンを設定できます。

      ROSA は以下の優先順位でリージョンを評価します。

      1. --region フラグを指定して rosa コマンドを実行する際に指定されるリージョン。
      2. AWS_DEFAULT_REGION 環境変数に設定されるリージョン。AWS ドキュメントの Environment variables to configure the AWS CLI を参照してください。
      3. AWS 設定ファイルで設定されるデフォルトのリージョン。AWS ドキュメントの Quick configuration with aws configure を参照してください。
    3. オプション: AWS の名前付きプロファイルを使用して AWS CLI 設定および認証情報を設定します。rosa は以下の優先順位で AWS の名前付きプロファイルを評価します。

      1. rosa コマンドを --profile フラグを指定して実行する場合に指定されるプロファイル。
      2. AWS_PROFILE 環境変数に設定されるプロファイル。AWS ドキュメントの Named profiles を参照してください。
    4. 以下のコマンドを実行して AWS API をクエリーし、AWS CLI がインストールされ、正しく設定されていることを確認します。

      $ aws sts get-caller-identity
  4. ROSA CLI の最新バージョン (rosa) をインストールします。

    1. 使用しているオペレーティングシステム用の ROSA CLI の最新リリースをダウンロードします。
    2. オプション: rosa にダウンロードしたファイルの名前を変更し、ファイルを実行可能にします。本書では、rosa を使用して実行可能ファイルを参照します。

      $ chmod +x rosa
    3. オプション: rosa をパスに追加します。

      $ mv rosa /usr/local/bin/rosa
    4. 以下のコマンドを実行して、インストールを確認します。

      $ rosa

      出力例

      Command line tool for Red Hat OpenShift Service on AWS.
      For further documentation visit https://access.redhat.com/documentation/ja-jp/red_hat_openshift_service_on_aws
      
      Usage:
        rosa [command]
      
      Available Commands:
        completion  Generates completion scripts
        create      Create a resource from stdin
        delete      Delete a specific resource
        describe    Show details of a specific resource
        download    Download necessary tools for using your cluster
        edit        Edit a specific resource
        grant       Grant role to a specific resource
        help        Help about any command
        init        Applies templates to support Red Hat OpenShift Service on AWS
        install     Installs a resource into a cluster
        link        Link a ocm/user role from stdin
        list        List all resources of a specific type
        login       Log in to your Red Hat account
        logout      Log out
        logs        Show installation or uninstallation logs for a cluster
        revoke      Revoke role from a specific resource
        uninstall   Uninstalls a resource from a cluster
        unlink      UnLink a ocm/user role from stdin
        upgrade     Upgrade a resource
        verify      Verify resources are configured correctly for cluster install
        version     Prints the version of the tool
        whoami      Displays user account information
      
      Flags:
            --color string   Surround certain characters with escape sequences to display them in color on the terminal. Allowed options are [auto never always] (default "auto")
            --debug          Enable debug mode.
        -h, --help           help for rosa
      
      Use "rosa [command] --help" for more information about a command.

    5. ROSA CLI のコマンド補完スクリプトを生成します。以下の例では、Linux マシン用の Bash 補完スクリプトを生成します。

      $ rosa completion bash | sudo tee /etc/bash_completion.d/rosa
    6. 既存のターミナルから rosa コマンドの補完を可能にするためのスクリプトを作成します。以下の例では、Linux マシン上で rosa の Bash 補完スクリプトをソースとして使用しています。

      $ source /etc/bash_completion.d/rosa
  5. ROSA CLI で Red Hat アカウントにログインします。

    1. 以下のコマンドを入力します。

      $ rosa login
    2. <my_offline_access_token> をトークンに置き換えます。

      出力例

      To login to your Red Hat account, get an offline access token at https://console.redhat.com/openshift/token/rosa
      ? Copy the token and paste it here: <my-offline-access-token>

      出力例

      I: Logged in as '<rh-rosa-user>' on 'https://api.openshift.com'

  6. AWS アカウントに ROSA クラスターをデプロイするために必要なクォータがあることを確認します。

    $ rosa verify quota [--region=<aws_region>]

    出力例

    I: Validating AWS quota...
    I: AWS quota ok

    注記

    AWS クォータはリージョンによって異なる場合があります。エラーが発生した場合は、別のリージョンを試してください。

    クォータを増やす必要がある場合は、AWS 管理コンソール に移動して、失敗したサービスのクォータの増加をリクエストします。

    クォータの確認に成功したら、次のステップに進みます。

  7. クラスターデプロイメント用に AWS アカウントを準備します。

    1. 次のコマンドを実行して、Red Hat および AWS 認証情報が正しく設定されていることを確認します。AWS アカウント ID、デフォルトのリージョンおよび ARN が予想される内容と一致していることを確認します。現時点では、OpenShift Cluster Manager で始まる行は無視しても問題ありません。

      $ rosa whoami

      出力例

      AWS Account ID:               000000000000
      AWS Default Region:           us-east-1
      AWS ARN:                      arn:aws:iam::000000000000:user/hello
      OCM API:                      https://api.openshift.com
      OCM Account ID:               1DzGIdIhqEWyt8UUXQhSoWaaaaa
      OCM Account Name:             Your Name
      OCM Account Username:         you@domain.com
      OCM Account Email:            you@domain.com
      OCM Organization ID:          1HopHfA2hcmhup5gCr2uH5aaaaa
      OCM Organization Name:        Red Hat
      OCM Organization External ID: 0000000

  8. ROSA (rosa) CLI から OpenShift CLI (oc) バージョン 4.7.9 以降をインストールします。

    1. 以下のコマンドを入力して、最新バージョンの oc CLI をダウンロードします。

      $ rosa download openshift-client
    2. oc CLI をダウンロードした後に、これをデプロイメントし、パスに追加します。
    3. 以下のコマンドを実行して、oc CLI が正常にインストールされていることを確認します。

      $ rosa verify openshift-client

ロールの作成

これらの手順を完了したら、IAM および OIDC アクセスベースのロールをセットアップできます。

7.2. 次のステップ

7.3. 関連情報

第8章 ROSA クラスターのインストールに使用する Terraform の準備

Terraform は、リソースを設定すると必要に応じてそれらのリソースをレプリケートできる infrastructure-as-code ツールです。Terraform は、宣言的言語を使用して作成タスクを実行します。インフラストラクチャーリソースの任意の最終状態を宣言すると、Terraform は仕様に合わせてリソースを作成します。

8.1. Terraform の前提条件

Terraform 設定内で Red Hat Cloud Services プロバイダー を使用するには、次の前提条件を満たす必要があります。

  • Red Hat OpenShift Service on AWS (ROSA) コマンドラインインターフェイス (CLI) ツールをインストールしている。

    インストール手順の詳細は、関連情報を参照してください。

  • オフライン Red Hat OpenShift Cluster Manager トークン がある。

    このトークンは、Red Hat Hybrid Cloud Console 経由で生成されます。これは各自のアカウントに固有のものであるため、共有はしないでください。トークンは、アカウントのアクセス権と権限に基づき生成されます。

  • Terraform バージョン 1.4.6 以降をインストールしている。

    ローカルシステム用に Terraform を設定しておく必要があります。Terraform Web サイトには、MacOS、Windows、および Linux のインストールオプションが含まれています。

  • リソースの作成に必要な AWS アカウント関連する認証情報 がある。認証情報は AWS プロバイダー用に設定されています。AWS Terraform プロバイダーのドキュメントで、Authentication and Configuration セクションを参照してください。
  • Terraform を操作する AWS IAM ロールポリシーに、少なくとも以下の権限がある。権限については、AWS コンソールで確認してください。

    例8.1 Terraform の最小限の AWS 権限

    {
      "Version": "2012-10-17",
      "Statement": [
        {
          "Sid": "VisualEditor0",
          "Effect": "Allow",
          "Action": [
            "iam:GetPolicyVersion",
            "iam:DeletePolicyVersion",
            "iam:CreatePolicyVersion",
            "iam:UpdateAssumeRolePolicy",
            "secretsmanager:DescribeSecret",
            "iam:ListRoleTags",
            "secretsmanager:PutSecretValue",
            "secretsmanager:CreateSecret",
            "iam:TagRole",
            "secretsmanager:DeleteSecret",
            "iam:UpdateOpenIDConnectProviderThumbprint",
            "iam:DeletePolicy",
            "iam:CreateRole",
            "iam:AttachRolePolicy",
            "iam:ListInstanceProfilesForRole",
            "secretsmanager:GetSecretValue",
            "iam:DetachRolePolicy",
            "iam:ListAttachedRolePolicies",
            "iam:ListPolicyTags",
            "iam:ListRolePolicies",
            "iam:DeleteOpenIDConnectProvider",
            "iam:DeleteInstanceProfile",
            "iam:GetRole",
            "iam:GetPolicy",
            "iam:ListEntitiesForPolicy",
            "iam:DeleteRole",
            "iam:TagPolicy",
            "iam:CreateOpenIDConnectProvider",
            "iam:CreatePolicy",
            "secretsmanager:GetResourcePolicy",
            "iam:ListPolicyVersions",
            "iam:UpdateRole",
            "iam:GetOpenIDConnectProvider",
            "iam:TagOpenIDConnectProvider",
            "secretsmanager:TagResource",
            "sts:AssumeRoleWithWebIdentity",
            "iam:ListRoles"
          ],
          "Resource": [
            "arn:aws:secretsmanager:*:<ACCOUNT_ID>:secret:*",
            "arn:aws:iam::<ACCOUNT_ID>:instance-profile/*",
            "arn:aws:iam::<ACCOUNT_ID>:role/*",
            "arn:aws:iam::<ACCOUNT_ID>:oidc-provider/*",
            "arn:aws:iam::<ACCOUNT_ID>:policy/*"
          ]
        },
        {
          "Sid": "VisualEditor1",
          "Effect": "Allow",
          "Action": [
            "s3:*"
            ],
          "Resource": "*"
        }
      ]
    }

8.2. Terraform を使用する場合の考慮事項

一般に、Terraform を使用してクラウドリソースを管理する場合は、すべての変更が Terraform 方法論を使用して実行されることを前提として行う必要があります。AWS コンソールや Red Hat コンソールなど、Terraform 外部のツールを使用して Terraform によって作成されたクラウドリソースを変更する場合は注意してください。Terraform によってすでに管理されているクラウドリソースを管理するために Terraform 外部のツールを使用すると、宣言した Terraform 設定から設定のドリフトが発生します。

たとえば、Red Hat Hybrid Cloud Console を使用して Terraform で作成されたクラスターをアップグレードする場合は、今後の設定変更を適用する前に Terraform の状態を調整する必要があります。詳細は、HashiCorp Developer ドキュメントの Manage resources in Terraform state を参照してください。

関連情報

8.3. アカウントロール Terraform の例

次の例は、Terraform を使用して ROSA の Amazon Web Services (AWS) Identity and Access Management (IAM) アカウントロールを作成する方法を示しています。

重要

Terraform の状態ファイルは変更しないでください。詳細は、Terraform 使用時の考慮事項 を参照してください。

手順

  1. 次のコマンドを実行して、AWS アカウントで既存のロールとポリシーを確認します。

    $ rosa list account-roles
  2. ターミナルで次のコマンドを実行して、Red Hat OpenShift Cluster Manager トークン をエクスポートします。この値には、完全な OpenShift Cluster Manager トークンが含まれている必要があります。

    $ export RHCS_TOKEN="<your_offline_token>"

    次のコマンドを実行すると、トークンが保存されたことを確認できます。

    $ echo $RHCS_TOKEN

    コマンドラインにトークンが表示されます。

  3. オプション: 次のコマンドを実行して、作成するロールの先頭に付加する独自の account-role 接頭辞を指定できます。

    注記

    account-role 接頭辞を指定しない場合、account-role- の後にランダムな 4 文字の文字列が続く形式で接頭辞が生成されます。

    $ export TF_VAR_account_role_prefix=<account_role_prefix>
  4. 次のコードテンプレートを使用して、Terraform ファイルをローカルに作成します。

    注記

    これらのファイルは、現在のディレクトリーに作成されます。Terraform を実行するディレクトリーにいることを確認してください。

    1. main.tf ファイルは Red Hat Cloud Services Terraform プロバイダーを呼び出します。これにより、Terraform で OpenShift サービスを使用できるようになります。次のコマンドを実行して、main.tf ファイルを作成します。

      $ cat<<-EOF>main.tf
        #
        # Copyright (c) 2022 Red Hat, Inc.
        #
        # Licensed under the Apache License, Version 2.0 (the "License");
        # you may not use this file except in compliance with the License.
        # You may obtain a copy of the License at
        #
        #   http://www.apache.org/licenses/LICENSE-2.0
        #
        # Unless required by applicable law or agreed to in writing, software
        # distributed under the License is distributed on an "AS IS" BASIS,
        # WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
        # See the License for the specific language governing permissions and
        # limitations under the License.
        #
      
        terraform {
          required_providers {
            aws = {
              source  = "hashicorp/aws"
              version = ">= 4.20.0"
            }
            rhcs = {
              version = "1.4.0"
              source  = "terraform-redhat/rhcs"
            }
          }
        }
      
        data "rhcs_policies" "all_policies" {}
      
        data "rhcs_versions" "all" {}
      
        module "create_account_roles" {
          source  = "terraform-redhat/rosa-sts/aws"
          version = "0.0.15"
      
          create_operator_roles = false
          create_oidc_provider  = false
          create_account_roles  = true
      
          account_role_prefix    = var.account_role_prefix
          rosa_openshift_version = var.openshift_version
          account_role_policies  = data.rhcs_policies.all_policies.account_role_policies
          operator_role_policies = data.rhcs_policies.all_policies.operator_role_policies
          all_versions           = data.rhcs_versions.all
          tags                   = var.tags
        }
      EOF
    2. output.tf ファイルで、アカウントロールの接頭辞の構造を定義します。この出力定義を使用すると、生成されるさまざまなロールの構築方法を指定できます。次のコマンドを実行して、output.tf ファイルを作成します。

      $ cat<<-EOF>output.tf
        output "account_role_prefix" {
          value = module.create_account_roles.account_role_prefix
        }
      EOF
    3. variables.tf を使用すると、選択変数に必要な値を指定できます。すでに account_role_prefix の変数をエクスポートしている場合は、この変数のデフォルト値を空白のままにしておきます。両方の場所に異なる値を使用して変数を設定すると、予期しない結果が生じる可能性があります。次のコマンドを実行して、variables.tf ファイルを作成します。

      重要

      OpenShift Cluster Manager トークンが安全な場所に保存されていない場合は、このファイルに含めないでください。

      $ cat<<-EOF>variables.tf
        variable "openshift_version" {
          type = string
          default = "4.13"
          description = "Enter the desired OpenShift version as X.Y. This version should match what you intend for your ROSA cluster. For example, if you plan to create a ROSA cluster using '4.13.10', then this version should be '4.13'. You can see the supported versions of OpenShift by running 'rosa list version'."
        }
      
        variable "account_role_prefix" {
          type    = string
          default = ""
          description = "Your account roles are prepended with whatever value you enter here. The default value in the ROSA CLI is 'ManagedOpenshift-' before all of your account roles."
        }
      
        variable "tags" { 1
          type        = map
          default     = null
          description = "(Optional) List of AWS resource tags to apply."
        }
      EOF
      1
      tags パラメーターは、文字列変数のマップを使用します。使用する形式は次の例のようになります。
      variable "tags" {
        type    = "map"
        default = {
          "us-east-1" = "image-1234"
          "us-west-2" = "image-4567"
        }
      }
  5. Terraform ファイルを保存したディレクトリーで次のコマンドを実行して、これらのリソースを作成するように Terraform をセットアップします。

    $ terraform init
  6. オプション: 次のコマンドを実行して、コピーした Terraform コードが正しいことを確認します。

    $ terraform validate

    出力例

    Success! The configuration is valid.

  7. オプション: 次のコマンドを実行して、Terraform テンプレートをテストし、再利用可能な Terraform プランファイルを作成します。

    $ terraform plan -out account-roles.tfplan
  8. 次のコマンドを実行して、Terraform でアカウント全体の IAM ロールをビルドします。

    $ terraform apply "account-roles.tfplan"
    注記

    最初に terraform plan コマンドを使用した場合は、作成した account-roles.tf ファイルをここで指定できます。それ以外の場合、Terraform は作成したものを適用する前に、このプランを一時的に作成します。

検証

  • 次のコマンドを実行して、account-roles が作成されたことを確認します。

    $ rosa list account-roles

    出力例

    I: Fetching account roles
    ROLE NAME                            ROLE TYPE      ROLE ARN                                                            OPENSHIFT VERSION  AWS Managed
    account-role-6kn4-ControlPlane-Role  Control plane  arn:aws:iam::269733383066:role/account-role-6kn4-ControlPlane-Role  4.13               No
    account-role-6kn4-Installer-Role     Installer      arn:aws:iam::269733383066:role/account-role-6kn4-Installer-Role     4.13               No
    account-role-6kn4-Support-Role       Support        arn:aws:iam::269733383066:role/account-role-6kn4-Support-Role       4.13               No
    account-role-6kn4-Worker-Role        Worker         arn:aws:iam::269733383066:role/account-role-6kn4-Worker-Role        4.13               No

クリーンアップ

Terraform を使用して作成したリソースの使用が終了したら、次のコマンドを実行してこれらのリソースをパージする必要があります。

$ terraform destroy

8.4. 次のステップ

8.5. 関連情報

法律上の通知

Copyright © 2024 Red Hat, Inc.
The text of and illustrations in this document are licensed by Red Hat under a Creative Commons Attribution–Share Alike 3.0 Unported license ("CC-BY-SA"). An explanation of CC-BY-SA is available at http://creativecommons.org/licenses/by-sa/3.0/. In accordance with CC-BY-SA, if you distribute this document or an adaptation of it, you must provide the URL for the original version.
Red Hat, as the licensor of this document, waives the right to enforce, and agrees not to assert, Section 4d of CC-BY-SA to the fullest extent permitted by applicable law.
Red Hat, Red Hat Enterprise Linux, the Shadowman logo, the Red Hat 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 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 は、企業がコアとなるデータセンターからネットワークエッジに至るまで、各種プラットフォームや環境全体で作業を簡素化できるように、強化されたソリューションを提供しています。

© 2024 Red Hat, Inc.