ROSA with HCP クラスターのインストール
Red Hat OpenShift Service on AWS (ROSA) クラスターのインストール、アクセス、および削除
概要
第1章 デフォルトのオプションを使用した ROSA with HCP クラスターの作成
ROSA Classic のクイックスタートガイドをお探しの場合は、Red Hat OpenShift Service on AWS クイックスタートガイド を参照してください。
Red Hat OpenShift Service on AWS (ROSA) with Hosted Control Plane は、Red Hat OpenShift Service on AWS (ROSA) クラスターを作成するためのより効率的で信頼性の高いアーキテクチャーを提供します。ROSA with HCP では、各クラスターに ROSA サービスアカウントで分離された専用のコントロールプレーンがあります。
デフォルトのオプションと AWS Identity and Access Management (IAM) リソースの自動作成を使用して、ROSA with HCP クラスターをすばやく作成します。ROSA CLI (rosa
) を使用してクラスターをデプロイできます。
既存の ROSA クラスターを Hosted Control Plane アーキテクチャーにアップグレードまたは変換することはできないため、ROSA with HCP の機能を使用するには新しいクラスターを作成する必要があります。
ROSA with HCP クラスターは、AWS Security Token Service (STS) 認証のみをサポートします。
関連資料
- ROSA with HCP と ROSA Classic の比較は、アーキテクチャーモデルの比較 のドキュメントを参照してください。
- ROSA CLI を使用して自動モードで ROSA with HCP の使用を開始する方法 については、AWS ドキュメントを参照してください。
関連情報
サポートされている証明書の完全なリストは、「Red Hat OpenShift Service on AWS のプロセスとセキュリティーについて」の コンプライアンス セクションを参照してください。
自動作成モードに関する考慮事項
このドキュメントの手順では、ROSA CLI の auto
モードを使用して、現在の AWS アカウントを使用して必要な IAM リソースを即座に作成します。必要なリソースには、アカウント全体の IAM ロールおよびポリシー、クラスター固有の Operator ロール、ならびに OpenID Connect (OIDC) ID プロバイダーが含まれます。
または、IAM リソースを自動的にデプロイする代わりに、IAM リソースの作成に必要な aws
コマンドを出力する manual
モードを使用することもできます。manual
モードを使用するか、カスタマイズを使用して ROSA with HCP クラスターをデプロイする手順は、カスタマイズを使用したクラスターの作成 を参照してください。
次のステップ
- AWS の前提条件 を満たしていることを確認してください。
1.1. デフォルトのクラスター仕様の概要
デフォルトのインストールオプションを使用すると、Security Token Service (STS) を使用して ROSA with HCP クラスターをすばやく作成できます。次の要約では、デフォルトのクラスター仕様について説明します。
表1.1 ROSA with HCP クラスターのデフォルトの仕様
コンポーネント | デフォルトの仕様 |
---|---|
アカウントおよびロール |
|
クラスター設定 |
|
暗号化 |
|
コンピュートノードマシンプール |
|
ネットワーク設定 |
|
Classless Inter-Domain Routing (CIDR) の範囲 |
|
クラスターのロールおよびポリシー |
|
クラスター更新戦略 |
|
1.2. ROSA with HCP の前提条件
ROSA with HCP クラスターを作成するには、次のものが必要です。
- 設定された仮想プライベートクラウド (VPC)
- アカウント全体のロール
- OIDC 設定
- オペレーターのロール
1.2.1. ROSA with HCP クラスター用の仮想プライベートクラウドの作成
ROSA with HCP クラスターを作成するには、Virtual Private Cloud (VPC) が必要です。次の方法を使用して VPC を作成できます。
- Terraform テンプレートを使用して VPC を作成する
- AWS コンソールで VPC リソースを手動で作成する
Terraform の手順はテストとデモンストレーションを目的としています。独自のインストールでは、独自に使用するために VPC にいくつかの変更を加える必要があります。また、この Terraform スクリプトを使用するときは、クラスターをインストールする予定のリージョンと同じリージョンにあることを確認する必要があります。これらの例では、us-east-2
を使用します。
Terraform を使用した Virtual Private Cloud の作成
Terraform は、確立されたテンプレートを使用してさまざまなリソースを作成できるツールです。次のプロセスでは、必要に応じてデフォルトのオプションを使用して、ROSA with HCP クラスターを作成します。Terraform の使用の詳細は、関連情報を参照してください。
前提条件
- マシンに Terraform バージョン 1.4.0 以降がインストールされている。
- マシンに Git がインストールされている。
手順
シェルプロンプトを開き、次のコマンドを実行して Terraform VPC リポジトリーのクローンを作成します。
$ git clone https://github.com/openshift-cs/terraform-vpc-example
次のコマンドを実行して、作成したディレクトリーに移動します。
$ cd terraform-vpc-example
次のコマンドを実行して、Terraform ファイルを開始します。
$ terraform init
このプロセスが完了すると、初期化を確認するメッセージが表示されます。
既存の Terraform テンプレートに基づいて VPC Terraform プランを構築するには、
plan
コマンドを実行します。AWS リージョンを含める必要があります。クラスター名の指定を選択できます。terraform plan
が完了すると、rosa.tfplan
ファイルがhypershift-tf
ディレクトリーに追加されます。オプションの詳細は、Terraform VPC リポジトリーの README ファイル を参照してください。$ terraform plan -out rosa.tfplan -var region=<region>
次のコマンドを実行して、このプランファイルを適用して VPC を構築します。
$ terraform apply rosa.tfplan
任意: 次のコマンドを実行して、Terraform でプロビジョニングされたプライベート、パブリック、およびマシンプールのサブネット ID の値を環境変数としてキャプチャーし、ROSA with HCP クラスターを作成するときに使用できます。
$ export SUBNET_IDS=$(terraform output -raw cluster-subnets-string)
次のコマンドを使用して、変数が正しく設定されたことを確認できます。
$ echo $SUBNET_IDS
出力例
$ subnet-0a6a57e0f784171aa,subnet-078e84e5b10ecf5b0
関連情報
- ニーズに合わせて VPC をカスタマイズするときに使用できるすべてのオプションの詳細なリストは、Terraform VPC リポジトリーを参照してください。
Virtual Private Cloud を手動で作成する
Terraform を使用する代わりに Virtual Private Cloud (VPC) を手動で作成することを選択した場合は、AWS コンソールの VPC ページ に移動します。VPC は、次の表に示す要件を満たしている必要があります。
表1.2 VPC の要件
要件 | 詳細 |
---|---|
VPC 名 | クラスターを作成するときは、特定の VPC 名と ID が必要です。 |
CIDR 範囲 | VPC CIDR 範囲はマシンの CIDR と一致する必要があります。 |
アベイラビリティーゾーン | 単一ゾーンの場合は 1 つの可用性ゾーンが必要で、複数ゾーンの場合は 3 つの可用性ゾーンが必要です。 |
パブリックサブネット | パブリッククラスターには、NAT ゲートウェイを備えたパブリックサブネットが 1 つ必要です。プライベートクラスターにはパブリックサブネットは必要ありません。 |
DNS ホスト名と解決 | DNS ホスト名と解決が有効になっていることを確認する必要があります。 |
サブネットへのタグ付け
VPC を使用して ROSA with HCP クラスターを作成する前に、VPC サブネットにタグを付ける必要があります。自動サービスのプリフライトチェックでは、これらのリソースを使用する前に、これらのリソースが正しくタグ付けされていることを確認します。次の表は、リソースを次のようにタグ付けする方法を示しています。
リソース | キー | 値 |
---|---|---|
パブリックサブネット |
|
|
プライベートサブネット |
|
|
少なくとも 1 つのプライベートサブネットと、該当する場合は 1 つのパブリックサブネットにタグを付ける必要があります。
前提条件
- VPC を作成している。
-
aws
CLI をインストールしている。
手順
次のコマンドを実行して、ターミナルでリソースにタグを付けます。
パブリックサブネットの場合は、以下を実行します。
$ aws ec2 create-tags --resources <public-subnet-id> --tags Key=kubernetes.io/role/elb,Value=1
プライベートサブネットの場合は、以下を実行します。
$ aws ec2 create-tags --resources <private-subnet-id> --tags Key=kubernetes.io/role/internal-elb,Value=1
検証
次のコマンドを実行して、タグが正しく適用されていることを確認します。
$ aws ec2 describe-tags --filters "Name=resource-id,Values=<subnet_id>"
出力例
TAGS Name <subnet-id> subnet <prefix>-subnet-public1-us-east-1a TAGS kubernetes.io/role/elb <subnet-id> subnet 1
1.2.2. アカウント全体の STS ロールおよびポリシーの作成
Red Hat OpenShift Service on AWS (ROSA) CLI (rosa
) を使用して、Red Hat OpenShift Service on AWS (ROSA) with Hosted Control Plane クラスターを作成する前に、Operator ポリシーを含む、必要なアカウント全体のロールとポリシーを作成します。
ROSA with HCP クラスターには、AWS 管理ポリシーがアタッチされたアカウントと Operator ロールが必要です。顧客管理のポリシーはサポートされていません。ROSA with HCP クラスターの AWS 管理ポリシーの詳細は、AWS managed policies for ROSA account roles を参照してください。
前提条件
- ROSA with HCP の AWS の前提条件を完了している。
- 利用可能な AWS サービスクォータがある。
- AWS コンソールで ROSA サービスを有効にしている。
-
インストールホストに、最新の ROSA CLI (
rosa
) をインストールして設定している。 - ROSA CLI を使用して Red Hat アカウントにログインしている。
手順
AWS アカウントに存在しない場合は、次のコマンドを実行して、必要なアカウント全体の STS ロールを作成し、ポリシーをアタッチします。
$ rosa create account-roles --hosted-cp
オプション: 次のコマンドを実行して、接頭辞を環境変数として設定します。
$ export ACCOUNT_ROLES_PREFIX=<account_role_prefix>
次のコマンドを実行して、変数の値を表示します。
$ echo $ACCOUNT_ROLES_PREFIX
出力例
ManagedOpenShift
ROSA の AWS 管理 IAM ポリシーの詳細は、AWS managed IAM policies for ROSA を参照してください。
1.2.3. OpenID Connect 設定の作成
ROSA with HCP クラスターを使用する場合は、クラスターを作成する前に OpenID Connect (OIDC) 設定を作成する必要があります。この設定は、OpenShift Cluster Manager で使用するために登録されています。
前提条件
- ROSA with HCP の AWS の前提条件を完了している。
- Red Hat OpenShift Service on AWS の AWS 前提条件を完了している。
-
インストールホストに、最新の Red Hat OpenShift Service on AWS (ROSA) CLI (
rosa
) をインストールして設定している。
手順
AWS リソースと一緒に OIDC 設定を作成するには、次のコマンドを実行します。
$ rosa create oidc-config --mode=auto --yes
このコマンドは次の情報を返します。
出力例
? Would you like to create a Managed (Red Hat hosted) OIDC Configuration Yes I: Setting up managed OIDC configuration I: To create Operator Roles for this OIDC Configuration, run the following command and remember to replace <user-defined> with a prefix of your choice: rosa create operator-roles --prefix <user-defined> --oidc-config-id 13cdr6b If you are going to create a Hosted Control Plane cluster please include '--hosted-cp' I: Creating OIDC provider using 'arn:aws:iam::4540112244:user/userName' ? Create the OIDC provider? Yes I: Created OIDC provider with ARN 'arn:aws:iam::4540112244:oidc-provider/dvbwgdztaeq9o.cloudfront.net/13cdr6b'
クラスターを作成するときは、OIDC 設定 ID を指定する必要があります。CLI 出力では、
--mode auto
のこの値が提供されます。それ以外の場合は、--mode manual
のaws
CLI 出力に基づいてこれらの値を決定する必要があります。オプション: OIDC 設定 ID を変数として保存して、後で使用できます。次のコマンドを実行して変数を保存します。
$ export OIDC_ID=<oidc_config_id>1
- 1
- 上記の出力例では、OIDC 設定 ID は 13cdr6b です。
次のコマンドを実行して、変数の値を表示します。
$ echo $OIDC_ID
出力例
13cdr6b
検証
ユーザー組織に関連付けられているクラスターで使用できる可能な OIDC 設定をリストできます。以下のコマンドを実行します。
$ rosa list oidc-config
出力例
ID MANAGED ISSUER URL SECRET ARN 2330dbs0n8m3chkkr25gkkcd8pnj3lk2 true https://dvbwgdztaeq9o.cloudfront.net/2330dbs0n8m3chkkr25gkkcd8pnj3lk2 233hvnrjoqu14jltk6lhbhf2tj11f8un false https://oidc-r7u1.s3.us-east-1.amazonaws.com aws:secretsmanager:us-east-1:242819244:secret:rosa-private-key-oidc-r7u1-tM3MDN
1.2.4. Operator のロールとポリシーの作成
ROSA with HCP クラスターを使用する場合は、Red Hat OpenShift Service on AWS (ROSA) with Hosted Control Plane (HCP) デプロイメントに必要な Operator IAM ロールを作成する必要があります。クラスター Operator は、Operator のロールを使用して、バックエンドストレージ、クラウドプロバイダーの認証情報、クラスターへの外部アクセスの管理など、クラスター操作を実行するために必要な一時的なアクセス許可を取得します。
前提条件
- ROSA with HCP の AWS の前提条件を完了している。
-
インストールホストに、最新の Red Hat OpenShift Service on AWS (ROSA) CLI (
rosa
) をインストールして設定している。 - アカウント全体の AWS ロールを作成している。
手順
次のコマンドを使用して、接頭辞名を環境変数に設定します。
$ export OPERATOR_ROLES_PREFIX=<prefix_name>
Operator ロールを作成するには、次のコマンドを実行します。
$ rosa create operator-roles --hosted-cp --prefix=$OPERATOR_ROLES_PREFIX --oidc-config-id=$OIDC_ID --installer-role-arn arn:aws:iam::${AWS_ACCOUNT_ID}:role/${ACCOUNT_ROLES_PREFIX}-HCP-ROSA-Installer-Role
次の内訳は、Operator ロール作成のオプションを示しています。
$ rosa create operator-roles --hosted-cp --prefix=$OPERATOR_ROLES_PREFIX 1 --oidc-config-id=$OIDC_ID 2 --installer-role-arn arn:aws:iam::${AWS_ACCOUNT_ID}:role/${ACCOUNT_ROLES_PREFIX}-HCP-ROSA-Installer-Role 3
ROSA with HCP クラスター用の正しいロールを作成するには、
--hosted-cp
パラメーターを含める必要があります。このコマンドは次の情報を返します。出力例
? Role creation mode: auto ? Operator roles prefix: <pre-filled_prefix> 1 ? OIDC Configuration ID: 23soa2bgvpek9kmes9s7os0a39i13qm4 | https://dvbwgdztaeq9o.cloudfront.net/23soa2bgvpek9kmes9s7os0a39i13qm4 2 ? Create hosted control plane operator roles: Yes W: More than one Installer role found ? Installer role ARN: arn:aws:iam::4540112244:role/<prefix>-HCP-ROSA-Installer-Role ? Permissions boundary ARN (optional): I: Reusable OIDC Configuration detected. Validating trusted relationships to operator roles: I: Creating roles using 'arn:aws:iam::4540112244:user/<userName>' I: Created role '<prefix>-openshift-cluster-csi-drivers-ebs-cloud-credentials' with ARN 'arn:aws:iam::4540112244:role/<prefix>-openshift-cluster-csi-drivers-ebs-cloud-credentials' I: Created role '<prefix>-openshift-cloud-network-config-controller-cloud-credenti' with ARN 'arn:aws:iam::4540112244:role/<prefix>-openshift-cloud-network-config-controller-cloud-credenti' I: Created role '<prefix>-kube-system-kube-controller-manager' with ARN 'arn:aws:iam::4540112244:role/<prefix>-kube-system-kube-controller-manager' I: Created role '<prefix>-kube-system-capa-controller-manager' with ARN 'arn:aws:iam::4540112244:role/<prefix>-kube-system-capa-controller-manager' I: Created role '<prefix>-kube-system-control-plane-operator' with ARN 'arn:aws:iam::4540112244:role/<prefix>-kube-system-control-plane-operator' I: Created role '<prefix>-kube-system-kms-provider' with ARN 'arn:aws:iam::4540112244:role/<prefix>-kube-system-kms-provider' I: Created role '<prefix>-openshift-image-registry-installer-cloud-credentials' with ARN 'arn:aws:iam::4540112244:role/<prefix>-openshift-image-registry-installer-cloud-credentials' I: Created role '<prefix>-openshift-ingress-operator-cloud-credentials' with ARN 'arn:aws:iam::4540112244:role/<prefix>-openshift-ingress-operator-cloud-credentials' I: To create a cluster with these roles, run the following command: rosa create cluster --sts --oidc-config-id 23soa2bgvpek9kmes9s7os0a39i13qm4 --operator-roles-prefix <prefix> --hosted-cp
これで、Operator ロールが作成され、ROSA with HCP クラスターの作成に使用できるようになりました。
検証
ROSA アカウントに関連付けられている Operator ロールをリスト表示できます。以下のコマンドを実行します。
$ rosa list operator-roles
出力例
I: Fetching operator roles ROLE PREFIX AMOUNT IN BUNDLE <prefix> 8 ? Would you like to detail a specific prefix Yes 1 ? Operator Role Prefix: <prefix> ROLE NAME ROLE ARN VERSION MANAGED <prefix>-kube-system-capa-controller-manager arn:aws:iam::4540112244:role/<prefix>-kube-system-capa-controller-manager 4.13 No <prefix>-kube-system-control-plane-operator arn:aws:iam::4540112244:role/<prefix>-kube-system-control-plane-operator 4.13 No <prefix>-kube-system-kms-provider arn:aws:iam::4540112244:role/<prefix>-kube-system-kms-provider 4.13 No <prefix>-kube-system-kube-controller-manager arn:aws:iam::4540112244:role/<prefix>-kube-system-kube-controller-manager 4.13 No <prefix>-openshift-cloud-network-config-controller-cloud-credenti arn:aws:iam::4540112244:role/<prefix>-openshift-cloud-network-config-controller-cloud-credenti 4.13 No <prefix>-openshift-cluster-csi-drivers-ebs-cloud-credentials arn:aws:iam::4540112244:role/<prefix>-openshift-cluster-csi-drivers-ebs-cloud-credentials 4.13 No <prefix>-openshift-image-registry-installer-cloud-credentials arn:aws:iam::4540112244:role/<prefix>-openshift-image-registry-installer-cloud-credentials 4.13 No <prefix>-openshift-ingress-operator-cloud-credentials arn:aws:iam::4540112244:role/<prefix>-openshift-ingress-operator-cloud-credentials 4.13 No
- 1
- コマンドを実行すると、AWS アカウントに関連付けられているすべての接頭辞が表示され、この接頭辞に関連付けられているロールの数が記録されます。これらのロールとその詳細をすべて表示する必要がある場合は、詳細プロンプトで "Yes" と入力すると、これらのロールが詳細とともにリストされます。
関連情報
- オペレーター接頭辞については、カスタム Operator IAM ロール接頭辞 を参照してください。
1.3. CLI を使用した ROSA with HCP クラスターの作成
Red Hat OpenShift Service on AWS (ROSA) CLI (rosa
) を使用してクラスターを作成する場合は、デフォルトのオプションを選択してクラスターを迅速に作成できます。
前提条件
- ROSA with HCP の AWS の前提条件を完了している。
- 利用可能な AWS サービスクォータがある。
- AWS コンソールで ROSA サービスを有効にしている。
-
インストールホストに、最新の ROSA CLI (
rosa
) をインストールして設定している。rosa version
を実行して、現在インストールされている ROSA CLI のバージョンを確認します。新しいバージョンが利用可能な場合、CLI はこのアップグレードをダウンロードするためのリンクを提供します。 - ROSA CLI を使用して Red Hat アカウントにログインしている。
- OIDC 設定が作成されている。
- AWS Elastic Load Balancing (ELB) サービスロールが AWS アカウントに存在することを確認している。
手順
ROSA with HCP クラスターを作成するには、次のいずれかのコマンドを使用します。
注記ROSA with HCP クラスターを作成する場合、デフォルトのマシン Classless Inter-Domain Routing (CIDR) は
10.0.0.0/16
です。これが VPC サブネットの CIDR 範囲に対応していない場合は、次のコマンドに--machine-cidr <address_block>
を追加します。Red Hat OpenShift Service on AWS のデフォルト CIDR 範囲について、詳細は CIDR 範囲の定義 を参照してください。環境変数を設定していない場合は、以下のコマンドを実行します。
$ rosa create cluster --cluster-name=<cluster_name> \ <.> --mode=auto --hosted-cp [--private] \ <.> --operator-roles-prefix <operator-role-prefix> \ <.> --oidc-config-id <id-of-oidc-configuration> \ --subnet-ids=<public-subnet-id>,<private-subnet-id>
<.> クラスターの名前を指定します。クラスター名が 15 文字を超える場合、openshiftapps.com でプロビジョニングされたクラスターのサブドメインとして自動生成されたドメイン接頭辞が含まれます。サブドメインをカスタマイズするには、
--domain-prefix
フラグを使用します。ドメイン接頭辞は 15 文字を超えてはならず、一意である必要があり、クラスターの作成後に変更できません。<.> オプション:--private
引数は、プライベート ROSA with HCP クラスターを作成するために使用されます。この引数を使用する場合は、--subnet-ids
にプライベートサブネット ID のみを使用するようにしてください。<.> デフォルトでは、クラスター固有の Operator のロール名には、クラスター名とランダムな 4 桁のハッシュが接頭辞として付けられます。オプションで、ロール名の<cluster_name>-<hash>
を置き換えるカスタム接頭辞を指定できます。接頭辞は、クラスター固有の Operator IAM ロールを作成するときに適用されます。接頭辞の詳細は、カスタム Operator IAM ロール接頭辞についてを参照してください。注記関連するアカウント全体のロールを作成したときにカスタム ARN パスを指定した場合、カスタムパスは自動的に検出されます。カスタムパスは、後のステップで作成するときに、クラスター固有の Operator ロールに適用されます。
環境変数を設定する場合は、次のコマンドを実行して、公開または非公開で利用可能な API と Ingress を使用して、初期マシンプールが 1 つ含まれるクラスターを作成します。
$ rosa create cluster --private --cluster-name=<cluster_name> \ --mode=auto --hosted-cp --operator-roles-prefix=$OPERATOR_ROLES_PREFIX \ --oidc-config-id=$OIDC_ID --subnet-ids=$SUBNET_IDS
環境変数を設定する場合は、次のコマンドを実行して、単一の初期マシンプール、公開されている API、および公開されている Ingress が含まれるクラスターを作成します。
$ rosa create cluster --cluster-name=<cluster_name> --mode=auto \ --hosted-cp --operator-roles-prefix=$OPERATOR_ROLES_PREFIX \ --oidc-config-id=$OIDC_ID --subnet-ids=$SUBNET_IDS
次のコマンドを実行して、クラスターのステータスを確認します。
$ rosa describe cluster --cluster=<cluster_name>
以下の
State
フィールドの変更は、クラスターインストールの進捗として出力に表示されます。-
pending (Preparing account)
-
installing (DNS setup in progress)
-
installing
ready
注記インストールが失敗した場合や、
State
フィールドが 10 分以上ready
に変わらない場合は、インストールのトラブルシューティングのドキュメントで詳細を確認してください。詳細は、インストールのトラブルシューティングを参照してください。Red Hat サポートにサポートを依頼する手順は、Red Hat OpenShift Service on AWS のサポートを受けるを参照してください。
-
Red Hat OpenShift Service on AWS インストールプログラムのログを監視して、クラスター作成の進行状況を追跡します。ログを確認するには、次のコマンドを実行します。
$ rosa logs install --cluster=<cluster_name> --watch \ <.>
<.> オプション: インストールの進行中に新しいログメッセージを監視するには、
--watch
引数を使用します。
1.4. 次のステップ
1.5. 関連情報
- 手動モードを使用して ROSA クラスターをデプロイする手順は、カスタマイズを使用したクラスターの作成 を参照してください。
- STS を使用する Red Hat OpenShift Service on AWS をデプロイするのに必要な AWS Identity Access Management (IAM) リソースの詳細は、STS を使用するクラスターの IAM リソースについて を参照してください。
- セキュリティーグループの要件については、追加のカスタムセキュリティーグループ を参照してください。
- オプションで Operator ロール名接頭辞を設定する方法の詳細は、カスタム Operator IAM ロール接頭辞について を参照してください。
- STS を使用する ROSA をインストールするための前提条件の詳細は、STS を使用する ROSA の AWS の前提条件 を参照してください。
-
auto
モードとmanual
モードを使用して必要な STS リソースを作成する方法の詳細は、自動デプロイメントモードと手動デプロイメントモードについて を参照してください。 - AWS IAM で OpenID Connect (OIDC) アイデンティティープロバイダーの使用に関する詳細は、AWS ドキュメントの Creating OpenID Connect (OIDC) identity providers を参照してください。
- ROSA クラスターのインストールのトラブルシューティングの詳細は、インストールのトラブルシューティング を参照してください。
- Red Hat サポートにサポートを依頼する手順は、Red Hat OpenShift Service on AWS のサポートを受ける を参照してください。
第2章 カスタム AWS KMS 暗号鍵を使用した ROSA with HCP クラスターの作成
カスタムの AWS Key Management Service (KMS) キーを使用して、Red Hat OpenShift Service on AWS (ROSA) with Hosted Control Plane クラスターを作成します。
2.1. ROSA with HCP の前提条件
ROSA with HCP クラスターを作成するには、次のものが必要です。
- 設定された仮想プライベートクラウド (VPC)
- アカウント全体のロール
- OIDC 設定
- オペレーターのロール
2.1.1. ROSA with HCP クラスター用の仮想プライベートクラウドの作成
ROSA with HCP クラスターを作成するには、Virtual Private Cloud (VPC) が必要です。次の方法を使用して VPC を作成できます。
- Terraform テンプレートを使用して VPC を作成する
- AWS コンソールで VPC リソースを手動で作成する
Terraform の手順はテストとデモンストレーションを目的としています。独自のインストールでは、独自に使用するために VPC にいくつかの変更を加える必要があります。また、この Terraform スクリプトを使用するときは、クラスターをインストールする予定のリージョンと同じリージョンにあることを確認する必要があります。これらの例では、us-east-2
を使用します。
Terraform を使用した Virtual Private Cloud の作成
Terraform は、確立されたテンプレートを使用してさまざまなリソースを作成できるツールです。次のプロセスでは、必要に応じてデフォルトのオプションを使用して、ROSA with HCP クラスターを作成します。Terraform の使用の詳細は、関連情報を参照してください。
前提条件
- マシンに Terraform バージョン 1.4.0 以降がインストールされている。
- マシンに Git がインストールされている。
手順
シェルプロンプトを開き、次のコマンドを実行して Terraform VPC リポジトリーのクローンを作成します。
$ git clone https://github.com/openshift-cs/terraform-vpc-example
次のコマンドを実行して、作成したディレクトリーに移動します。
$ cd terraform-vpc-example
次のコマンドを実行して、Terraform ファイルを開始します。
$ terraform init
このプロセスが完了すると、初期化を確認するメッセージが表示されます。
既存の Terraform テンプレートに基づいて VPC Terraform プランを構築するには、
plan
コマンドを実行します。AWS リージョンを含める必要があります。クラスター名の指定を選択できます。terraform plan
が完了すると、rosa.tfplan
ファイルがhypershift-tf
ディレクトリーに追加されます。オプションの詳細は、Terraform VPC リポジトリーの README ファイル を参照してください。$ terraform plan -out rosa.tfplan -var region=<region>
次のコマンドを実行して、このプランファイルを適用して VPC を構築します。
$ terraform apply rosa.tfplan
任意: 次のコマンドを実行して、Terraform でプロビジョニングされたプライベート、パブリック、およびマシンプールのサブネット ID の値を環境変数としてキャプチャーし、ROSA with HCP クラスターを作成するときに使用できます。
$ export SUBNET_IDS=$(terraform output -raw cluster-subnets-string)
次のコマンドを使用して、変数が正しく設定されたことを確認できます。
$ echo $SUBNET_IDS
出力例
$ subnet-0a6a57e0f784171aa,subnet-078e84e5b10ecf5b0
関連情報
- ニーズに合わせて VPC をカスタマイズするときに使用できるすべてのオプションの詳細なリストは、Terraform VPC リポジトリーを参照してください。
Virtual Private Cloud を手動で作成する
Terraform を使用する代わりに Virtual Private Cloud (VPC) を手動で作成することを選択した場合は、AWS コンソールの VPC ページ に移動します。VPC は、次の表に示す要件を満たしている必要があります。
表2.1 VPC の要件
要件 | 詳細 |
---|---|
VPC 名 | クラスターを作成するときは、特定の VPC 名と ID が必要です。 |
CIDR 範囲 | VPC CIDR 範囲はマシンの CIDR と一致する必要があります。 |
アベイラビリティーゾーン | 単一ゾーンの場合は 1 つの可用性ゾーンが必要で、複数ゾーンの場合は 3 つの可用性ゾーンが必要です。 |
パブリックサブネット | パブリッククラスターには、NAT ゲートウェイを備えたパブリックサブネットが 1 つ必要です。プライベートクラスターにはパブリックサブネットは必要ありません。 |
DNS ホスト名と解決 | DNS ホスト名と解決が有効になっていることを確認する必要があります。 |
2.1.2. アカウント全体の STS ロールおよびポリシーの作成
Red Hat OpenShift Service on AWS (ROSA) CLI (rosa
) を使用して、Red Hat OpenShift Service on AWS (ROSA) with Hosted Control Plane クラスターを作成する前に、Operator ポリシーを含む、必要なアカウント全体のロールとポリシーを作成します。
ROSA with HCP クラスターには、AWS 管理ポリシーがアタッチされたアカウントと Operator ロールが必要です。顧客管理のポリシーはサポートされていません。ROSA with HCP クラスターの AWS 管理ポリシーの詳細は、AWS managed policies for ROSA account roles を参照してください。
前提条件
- ROSA with HCP の AWS の前提条件を完了している。
- 利用可能な AWS サービスクォータがある。
- AWS コンソールで ROSA サービスを有効にしている。
-
インストールホストに、最新の ROSA CLI (
rosa
) をインストールして設定している。 - ROSA CLI を使用して Red Hat アカウントにログインしている。
手順
AWS アカウントに存在しない場合は、次のコマンドを実行して、必要なアカウント全体の STS ロールを作成し、ポリシーをアタッチします。
$ rosa create account-roles --hosted-cp
オプション: 次のコマンドを実行して、接頭辞を環境変数として設定します。
$ export ACCOUNT_ROLES_PREFIX=<account_role_prefix>
次のコマンドを実行して、変数の値を表示します。
$ echo $ACCOUNT_ROLES_PREFIX
出力例
ManagedOpenShift
ROSA の AWS 管理 IAM ポリシーの詳細は、AWS managed IAM policies for ROSA を参照してください。
2.1.3. OpenID Connect 設定の作成
ROSA with HCP クラスターを使用する場合は、クラスターを作成する前に OpenID Connect (OIDC) 設定を作成する必要があります。この設定は、OpenShift Cluster Manager で使用するために登録されています。
前提条件
- ROSA with HCP の AWS の前提条件を完了している。
- Red Hat OpenShift Service on AWS の AWS 前提条件を完了している。
-
インストールホストに、最新の Red Hat OpenShift Service on AWS (ROSA) CLI (
rosa
) をインストールして設定している。
手順
AWS リソースと一緒に OIDC 設定を作成するには、次のコマンドを実行します。
$ rosa create oidc-config --mode=auto --yes
このコマンドは次の情報を返します。
出力例
? Would you like to create a Managed (Red Hat hosted) OIDC Configuration Yes I: Setting up managed OIDC configuration I: To create Operator Roles for this OIDC Configuration, run the following command and remember to replace <user-defined> with a prefix of your choice: rosa create operator-roles --prefix <user-defined> --oidc-config-id 13cdr6b If you are going to create a Hosted Control Plane cluster please include '--hosted-cp' I: Creating OIDC provider using 'arn:aws:iam::4540112244:user/userName' ? Create the OIDC provider? Yes I: Created OIDC provider with ARN 'arn:aws:iam::4540112244:oidc-provider/dvbwgdztaeq9o.cloudfront.net/13cdr6b'
クラスターを作成するときは、OIDC 設定 ID を指定する必要があります。CLI 出力では、
--mode auto
のこの値が提供されます。それ以外の場合は、--mode manual
のaws
CLI 出力に基づいてこれらの値を決定する必要があります。オプション: OIDC 設定 ID を変数として保存して、後で使用できます。次のコマンドを実行して変数を保存します。
$ export OIDC_ID=<oidc_config_id>1
- 1
- 上記の出力例では、OIDC 設定 ID は 13cdr6b です。
次のコマンドを実行して、変数の値を表示します。
$ echo $OIDC_ID
出力例
13cdr6b
検証
ユーザー組織に関連付けられているクラスターで使用できる可能な OIDC 設定をリストできます。以下のコマンドを実行します。
$ rosa list oidc-config
出力例
ID MANAGED ISSUER URL SECRET ARN 2330dbs0n8m3chkkr25gkkcd8pnj3lk2 true https://dvbwgdztaeq9o.cloudfront.net/2330dbs0n8m3chkkr25gkkcd8pnj3lk2 233hvnrjoqu14jltk6lhbhf2tj11f8un false https://oidc-r7u1.s3.us-east-1.amazonaws.com aws:secretsmanager:us-east-1:242819244:secret:rosa-private-key-oidc-r7u1-tM3MDN
2.1.4. Operator のロールとポリシーの作成
ROSA with HCP クラスターを使用する場合は、Red Hat OpenShift Service on AWS (ROSA) with Hosted Control Plane (HCP) デプロイメントに必要な Operator IAM ロールを作成する必要があります。クラスター Operator は、Operator のロールを使用して、バックエンドストレージ、クラウドプロバイダーの認証情報、クラスターへの外部アクセスの管理など、クラスター操作を実行するために必要な一時的なアクセス許可を取得します。
前提条件
- ROSA with HCP の AWS の前提条件を完了している。
-
インストールホストに、最新の Red Hat OpenShift Service on AWS (ROSA) CLI (
rosa
) をインストールして設定している。 - アカウント全体の AWS ロールを作成している。
手順
次のコマンドを使用して、接頭辞名を環境変数に設定します。
$ export OPERATOR_ROLES_PREFIX=<prefix_name>
Operator ロールを作成するには、次のコマンドを実行します。
$ rosa create operator-roles --hosted-cp --prefix=$OPERATOR_ROLES_PREFIX --oidc-config-id=$OIDC_ID --installer-role-arn arn:aws:iam::${AWS_ACCOUNT_ID}:role/${ACCOUNT_ROLES_PREFIX}-HCP-ROSA-Installer-Role
次の内訳は、Operator ロール作成のオプションを示しています。
$ rosa create operator-roles --hosted-cp --prefix=$OPERATOR_ROLES_PREFIX 1 --oidc-config-id=$OIDC_ID 2 --installer-role-arn arn:aws:iam::${AWS_ACCOUNT_ID}:role/${ACCOUNT_ROLES_PREFIX}-HCP-ROSA-Installer-Role 3
ROSA with HCP クラスター用の正しいロールを作成するには、
--hosted-cp
パラメーターを含める必要があります。このコマンドは次の情報を返します。出力例
? Role creation mode: auto ? Operator roles prefix: <pre-filled_prefix> 1 ? OIDC Configuration ID: 23soa2bgvpek9kmes9s7os0a39i13qm4 | https://dvbwgdztaeq9o.cloudfront.net/23soa2bgvpek9kmes9s7os0a39i13qm4 2 ? Create hosted control plane operator roles: Yes W: More than one Installer role found ? Installer role ARN: arn:aws:iam::4540112244:role/<prefix>-HCP-ROSA-Installer-Role ? Permissions boundary ARN (optional): I: Reusable OIDC Configuration detected. Validating trusted relationships to operator roles: I: Creating roles using 'arn:aws:iam::4540112244:user/<userName>' I: Created role '<prefix>-openshift-cluster-csi-drivers-ebs-cloud-credentials' with ARN 'arn:aws:iam::4540112244:role/<prefix>-openshift-cluster-csi-drivers-ebs-cloud-credentials' I: Created role '<prefix>-openshift-cloud-network-config-controller-cloud-credenti' with ARN 'arn:aws:iam::4540112244:role/<prefix>-openshift-cloud-network-config-controller-cloud-credenti' I: Created role '<prefix>-kube-system-kube-controller-manager' with ARN 'arn:aws:iam::4540112244:role/<prefix>-kube-system-kube-controller-manager' I: Created role '<prefix>-kube-system-capa-controller-manager' with ARN 'arn:aws:iam::4540112244:role/<prefix>-kube-system-capa-controller-manager' I: Created role '<prefix>-kube-system-control-plane-operator' with ARN 'arn:aws:iam::4540112244:role/<prefix>-kube-system-control-plane-operator' I: Created role '<prefix>-kube-system-kms-provider' with ARN 'arn:aws:iam::4540112244:role/<prefix>-kube-system-kms-provider' I: Created role '<prefix>-openshift-image-registry-installer-cloud-credentials' with ARN 'arn:aws:iam::4540112244:role/<prefix>-openshift-image-registry-installer-cloud-credentials' I: Created role '<prefix>-openshift-ingress-operator-cloud-credentials' with ARN 'arn:aws:iam::4540112244:role/<prefix>-openshift-ingress-operator-cloud-credentials' I: To create a cluster with these roles, run the following command: rosa create cluster --sts --oidc-config-id 23soa2bgvpek9kmes9s7os0a39i13qm4 --operator-roles-prefix <prefix> --hosted-cp
これで、Operator ロールが作成され、ROSA with HCP クラスターの作成に使用できるようになりました。
検証
ROSA アカウントに関連付けられている Operator ロールをリスト表示できます。以下のコマンドを実行します。
$ rosa list operator-roles
出力例
I: Fetching operator roles ROLE PREFIX AMOUNT IN BUNDLE <prefix> 8 ? Would you like to detail a specific prefix Yes 1 ? Operator Role Prefix: <prefix> ROLE NAME ROLE ARN VERSION MANAGED <prefix>-kube-system-capa-controller-manager arn:aws:iam::4540112244:role/<prefix>-kube-system-capa-controller-manager 4.13 No <prefix>-kube-system-control-plane-operator arn:aws:iam::4540112244:role/<prefix>-kube-system-control-plane-operator 4.13 No <prefix>-kube-system-kms-provider arn:aws:iam::4540112244:role/<prefix>-kube-system-kms-provider 4.13 No <prefix>-kube-system-kube-controller-manager arn:aws:iam::4540112244:role/<prefix>-kube-system-kube-controller-manager 4.13 No <prefix>-openshift-cloud-network-config-controller-cloud-credenti arn:aws:iam::4540112244:role/<prefix>-openshift-cloud-network-config-controller-cloud-credenti 4.13 No <prefix>-openshift-cluster-csi-drivers-ebs-cloud-credentials arn:aws:iam::4540112244:role/<prefix>-openshift-cluster-csi-drivers-ebs-cloud-credentials 4.13 No <prefix>-openshift-image-registry-installer-cloud-credentials arn:aws:iam::4540112244:role/<prefix>-openshift-image-registry-installer-cloud-credentials 4.13 No <prefix>-openshift-ingress-operator-cloud-credentials arn:aws:iam::4540112244:role/<prefix>-openshift-ingress-operator-cloud-credentials 4.13 No
- 1
- コマンドを実行すると、AWS アカウントに関連付けられているすべての接頭辞が表示され、この接頭辞に関連付けられているロールの数が記録されます。これらのロールとその詳細をすべて表示する必要がある場合は、詳細プロンプトで "Yes" と入力すると、これらのロールが詳細とともにリストされます。
2.1.5. カスタム AWS KMS キーを使用した ROSA クラスターの作成
ノードのルートボリューム、etcd データベース、またはその両方の暗号化に使用するお客様提供の KMS キーを使用して、Red Hat OpenShift Service on AWS (ROSA) クラスターを作成できます。両方にそれぞれ異なる KMS キー ARN を指定できます。
ROSA with HCP は、お客様提供の KMS キーを使用して永続ボリュームを暗号化するように default
ストレージクラスを自動設定しません。これは、インストール後にクラスター内で設定できるものです。
手順
次のコマンドを実行して、AWS の顧客管理のカスタム KMS キーを作成します。
$ KMS_ARN=$(aws kms create-key --region $AWS_REGION --description 'Custom ROSA Encryption Key' --tags TagKey=red-hat,TagValue=true --query KeyMetadata.Arn --output text)
このコマンドで、後の手順のために、このカスタムキーの Amazon リソースネーム (ARN) 出力が保存されます。
注記お客様は、お客様の KMS キーに必要な
--tags TagKey=red-hat,TagValue=true
引数を指定する必要があります。次のコマンドを実行して、KMS キーが作成されたことを確認します。
$ echo $KMS_ARN
AWS アカウント ID を環境変数に設定します。
$ AWS_ACCOUNT_ID=<aws_account_id>
前述の手順で作成したアカウント全体のインストーラーロールと Operator ロールの ARN を、ファイルの
Statement.Principal.AWS
セクションに追加します。次の例では、デフォルトのManagedOpenShift-HCP-ROSA-Installer-Role
ロールの ARN が追加されます。{ "Version": "2012-10-17", "Id": "key-rosa-policy-1", "Statement": [ { "Sid": "Enable IAM User Permissions", "Effect": "Allow", "Principal": { "AWS": "arn:aws:iam::${AWS_ACCOUNT_ID}:root" }, "Action": "kms:*", "Resource": "*" }, { "Sid": "Installer Permissions", "Effect": "Allow", "Principal": { "AWS": "arn:aws:iam::${AWS_ACCOUNT_ID}:role/ManagedOpenShift-HCP-ROSA-Installer-Role" }, "Action": [ "kms:CreateGrant", "kms:DescribeKey", "kms:GenerateDataKeyWithoutPlaintext" ], "Resource": "*" }, { "Sid": "ROSA KubeControllerManager Permissions", "Effect": "Allow", "Principal": { "AWS": "arn:aws:iam::${AWS_ACCOUNT_ID}:role/<operator_role_prefix>-kube-system-kube-controller-manager" }, "Action": "kms:DescribeKey", "Resource": "*" }, { "Sid": "ROSA KMS Provider Permissions", "Effect": "Allow", "Principal": { "AWS": "arn:aws:iam::${AWS_ACCOUNT_ID}:role/<operator_role_prefix>-kube-system-kms-provider" }, "Action": [ "kms:Encrypt", "kms:Decrypt", "kms:DescribeKey" ], "Resource": "*" }, { "Sid": "ROSA NodeManager Permissions", "Effect": "Allow", "Principal": { "AWS": "arn:aws:iam::${AWS_ACCOUNT_ID}:role/<operator_role_prefix>-kube-system-capa-controller-manager" }, "Action": [ "kms:DescribeKey", "kms:GenerateDataKeyWithoutPlaintext", "kms:CreateGrant" ], "Resource": "*" } ] }
次のコマンドを実行して、作成されたポリシーファイルの詳細を確認します。
$ cat rosa-key-policy.json
次のコマンドを実行して、新しく生成されたキーポリシーをカスタム KMS キーに適用します。
$ aws kms put-key-policy --key-id $KMS_ARN \ --policy file://rosa-key-policy.json \ --policy-name default
次のコマンドを実行してクラスターを作成します。
注記クラスター名が 15 文字を超える場合、
*.openshiftapps.com
にプロビジョニングされたクラスターのサブドメインとして自動生成されたドメイン接頭辞が含まれます。サブドメインをカスタマイズするには、
--domain-prefix
フラグを使用します。ドメイン接頭辞は 15 文字を超えてはならず、一意である必要があり、クラスターの作成後に変更できません。$ rosa create cluster --cluster-name <cluster_name> \ --subnet-ids <private_subnet_id>,<public_subnet_id> \ --sts \ --mode auto \ --machine-cidr 10.0.0.0/16 \ --compute-machine-type m5.xlarge \ --hosted-cp \ --region <aws_region> \ --oidc-config-id $OIDC_ID \ --kms-key-arn $KMS_ARN \ 1 --etcd-encryption-kms-arn $KMS_ARN \ 2 --operator-roles-prefix $OPERATOR_ROLES_PREFIX
検証
OpenShift Cluster Manager を使用して、KMS キーが機能することを確認できます。
- OpenShift Cluster Manager に移動し、Instances を選択します。
- インスタンスを選択します。
- Storage タブをクリックします。
- KMS key ID をコピーします。
- Key Management Service を検索して選択します。
- コピーした KMS key ID を Filter フィールドに入力します。
2.2. 次のステップ
2.3. 関連情報
- CLI を使用してクラスターを作成する方法については、CLI を使用した ROSA with HCP クラスターの作成 を参照してください。
- 手動モードを使用して ROSA クラスターをデプロイする手順は、カスタマイズを使用したクラスターの作成 を参照してください。
- STS を使用する Red Hat OpenShift Service on AWS をデプロイするのに必要な AWS Identity Access Management (IAM) リソースの詳細は、STS を使用するクラスターの IAM リソースについて を参照してください。
- オプションで Operator ロール名接頭辞を設定する方法の詳細は、カスタム Operator IAM ロール接頭辞について を参照してください。
- STS を使用する ROSA をインストールするための前提条件の詳細は、STS を使用する ROSA の AWS の前提条件 を参照してください。
-
auto
モードとmanual
モードを使用して必要な STS リソースを作成する方法の詳細は、自動デプロイメントモードと手動デプロイメントモードについて を参照してください。 - AWS IAM での OpenID Connect (OIDC) ID プロバイダーの使用の詳細は、Creating OpenID Connect (OIDC) identity providers を参照してください。
- ROSA クラスターのインストールのトラブルシューティングの詳細は、インストールのトラブルシューティング を参照してください。
- Red Hat サポートにサポートを依頼する手順は、Red Hat OpenShift Service on AWS のサポートを受ける を参照してください。
第3章 ROSA with HCP でのプライベートクラスターの作成
このドキュメントでは、Red Hat OpenShift Service on AWS (ROSA) with Hosted Control Plane (HCP) のプライベートクラスターを作成する方法について説明します。
3.1. AWS プライベートクラスターの作成
ROSA コマンドラインインターフェイス (CLI) rosa
を使用して、ROSA with HCP に複数のアベイラビリティーゾーン (Multi-AZ) を持つプライベートクラスターを作成できます。
前提条件
- 利用可能な AWS サービスクォータがある。
- AWS コンソールで ROSA サービスを有効にしている。
- インストールホストに、最新バージョンの ROSA CLI をインストールして設定している。
手順
Hosted Control Plane を使用したクラスターの作成には、10 分ほどかかる場合があります。
少なくとも 1 つのプライベートサブネットを持つ VPC を作成します。マシンの Classless Inter-Domain Routing (CIDR) が、仮想プライベートクラウドの CIDR と一致していることを確認します。詳細は、独自の VPC を使用するための要件 および VPC 検証 を参照してください。
重要ファイアウォールを使用する場合は、ROSA が機能するのに必要なサイトにアクセスできるようにファイアウォールを設定する必要があります。
詳細は、「AWS PrivateLink ファイアウォールの前提条件」セクションを参照してください。
次のコマンドを実行して、アカウント全体の IAM ロールを作成します。
$ rosa create account-roles --hosted-cp
次のコマンドを実行して、OIDC 設定を作成します。
$ rosa create oidc-config --mode=auto --yes
OIDC 設定の ID を保存します。Operator ロールの作成に必要なためです。
出力例
I: Setting up managed OIDC configuration I: To create Operator Roles for this OIDC Configuration, run the following command and remember to replace <user-defined> with a prefix of your choice: rosa create operator-roles --prefix <user-defined> --oidc-config-id 28s4avcdt2l318r1jbk3ifmimkurk384 If you are going to create a Hosted Control Plane cluster please include '--hosted-cp' I: Creating OIDC provider using 'arn:aws:iam::46545644412:user/user' I: Created OIDC provider with ARN 'arn:aws:iam::46545644412:oidc-provider/oidc.op1.openshiftapps.com/28s4avcdt2l318r1jbk3ifmimkurk384'
次のコマンドを実行して、Operator ロールを作成します。
$ rosa create operator-roles --hosted-cp --prefix <operator_roles_prefix> --oidc-config-id <oidc_config_id> --installer-role-arn arn:aws:iam::$<account_roles_prefix>:role/$<account_roles_prefix>-HCP-ROSA-Installer-Role
次のコマンドを実行して、ROSA with HCP プライベートクラスターを作成します。
$ rosa create cluster --private --cluster-name=<cluster-name> --sts --mode=auto --hosted-cp --operator-roles-prefix <operator_role_prefix> --oidc-config-id <oidc_config_id> [--machine-cidr=<VPC CIDR>/16] --subnet-ids=<private-subnet-id1>[,<private-subnet-id2>,<private-subnet-id3>]
以下のコマンドを実行して Pod のステータスを確認します。クラスターの作成中、出力の
State
フィールドはpending
からinstalling
に移行し、最後にready
に移行します。$ rosa describe cluster --cluster=<cluster_name>
注記インストールが失敗する場合や、10 分経っても
State
フィールドがready
に変わらない場合は、「関連情報」セクションの「Red Hat OpenShift Service on AWS のインストールのトラブルシューティング」ドキュメントを参照してください。以下のコマンドを実行して、OpenShift インストーラーのログでクラスターの進捗を追跡します。
$ rosa logs install --cluster=<cluster_name> --watch
3.2. API にアクセスするための AWS セキュリティーグループの設定
ROSA with HCP プライベートクラスターでは、お客様の VPC で公開される AWS PrivateLink エンドポイントにデフォルトのセキュリティーグループがあります。このセキュリティーグループは、VPC 内に存在するリソースまたは VPC CIDR 範囲に関連付けられた IP アドレスを持つリソースにのみ制限されている PrivateLink エンドポイントにアクセスできます。VPC ピアリングとトランジットゲートウェイを介した VPC 外部のエンティティーへのアクセスを許可するには、別のセキュリティーグループを作成して PrivateLink エンドポイントに割り当てて、必要なアクセス権を付与する必要があります。
前提条件
- 企業ネットワークまたは他の VPC に接続性がある。
- VPC 内でセキュリティーグループを作成して割り当てる権限を持っている。
手順
次のコマンドを実行して、クラスター名を環境変数として設定します。
$ export CLUSTER_NAME=<cluster_name>
次のコマンドを実行すると、変数が設定されたことを確認できます。
$ echo $CLUSTER_NAME
出力例
hcp-private
次のコマンドを実行して、VPC エンドポイント (VPCE) ID と VPC ID を見つけます。
$ read -r VPCE_ID VPC_ID <<< $(aws ec2 describe-vpc-endpoints --filters "Name=tag:api.openshift.com/id,Values=$(rosa describe cluster -c ${CLUSTER_NAME} -o yaml | grep '^id: ' | cut -d' ' -f2)" --query 'VpcEndpoints[].[VpcEndpointId,VpcId]' --output text)
次のコマンドを実行して、セキュリティーグループを作成します。
$ export SG_ID=$(aws ec2 create-security-group --description "Granting API access to ${CLUSTER_NAME} from outside of VPC" --group-name "${CLUSTER_NAME}-api-sg" --vpc-id $VPC_ID --output text)
次のコマンドを実行して、セキュリティーグループに Ingress ルールを追加します。
$ aws ec2 authorize-security-group-ingress --group-id $SG_ID --ip-permissions FromPort=443,ToPort=443,IpProtocol=tcp,IpRanges=[{CidrIp=0.0.0.0/0}]
次のコマンドを実行して、新しいセキュリティーグループを VPCE に追加します。
$ aws ec2 modify-vpc-endpoint --vpc-endpoint-id $VPCE_ID --add-security-group-ids $SG_ID
これで、ROSA with HCP プライベートクラスターを使用して API にアクセスできるようになりました。
3.3. 次のステップ
3.4. 関連情報
第4章 外部認証を使用した ROSA with HCP クラスターの作成
外部認証を使用してアクセストークンを発行する Hosted Control Plane (HCP) クラスターを使用して、Red Hat OpenShift Service on AWS (ROSA) を作成できます。
既存の ROSA クラスターを Hosted Control Plane アーキテクチャーにアップグレードまたは変換することはできないため、ROSA with HCP の機能を使用するには新しいクラスターを作成する必要があります。また、外部認証プロバイダーを使用するように作成されたクラスターを、内部 OAuth2 サーバーを使用するように変換することもできません。新しいクラスターも作成する必要があります。
ROSA with HCP クラスターは、Security Token Service (STS) 認証のみをサポートします。
関連資料
- ROSA with HCP と ROSA Classic の比較は、アーキテクチャーモデルの比較 のドキュメントを参照してください。
- ROSA CLI を使用して自動モードで ROSA with HCP の使用を開始する方法 については、AWS ドキュメントを参照してください。
関連情報
サポートされている証明書の完全なリストは、「Red Hat OpenShift Service on AWS のプロセスとセキュリティーについて」の コンプライアンス セクションを参照してください。
4.1. ROSA with HCP の前提条件
ROSA with HCP クラスターを作成するには、次の手順を完了する必要があります。
- AWS の前提条件 を満たしている。
- 仮想プライベートクラウド (VPC) を設定している。
- アカウント全体のロール を作成している。
- OIDC 設定 を作成している。
- Operator ロール を作成している。
4.2. 外部認証プロバイダーを使用する ROSA with HCP クラスターの作成
外部認証サービスを使用するクラスターを作成するには、ROSA CLI で --external-auth-providers-enabled
フラグを使用します。
ROSA with HCP クラスターを作成する場合、デフォルトのマシン Classless Inter-Domain Routing (CIDR) は 10.0.0.0/16
です。これが VPC サブネットの CIDR 範囲に対応していない場合は、次のコマンドに --machine-cidr <address_block>
を追加します。
手順
OIDC_ID
、SUBNET_IDS
、およびOPERATOR_ROLES_PREFIX
変数を使用して環境を準備した場合は、これらの変数をクラスターの作成時にも引き続き使用できます。たとえば、以下のコマンドを実行します。$ rosa create cluster --hosted-cp --subnet-ids=$SUBNET_IDS \ --oidc-config-id=$OIDC_ID --cluster-name=<cluster_name> \ --operator-roles-prefix=$OPERATOR_ROLES_PREFIX \ --external-auth-providers-enabled
環境変数を設定していない場合は、以下のコマンドを実行します。
$ rosa create cluster --cluster-name=<cluster_name> --sts --mode=auto \ --hosted-cp --operator-roles-prefix <operator-role-prefix> \ --oidc-config-id <ID-of-OIDC-configuration> \ --external-auth-providers-enabled \ --subnet-ids=<public-subnet-id>,<private-subnet-id>
検証
次のコマンドを実行して、クラスターの詳細で外部認証が有効になっていることを確認します。
$ rosa describe cluster --cluster=<cluster_name>
Name: rosa-ext-test Display Name: rosa-ext-test ID: <cluster_id> External ID: <cluster_ext_id> Control Plane: ROSA Service Hosted OpenShift Version: 4.15.3 Channel Group: stable DNS: <dns> AWS Account: <AWS_id> AWS Billing Account: <AWS_id> API URL: <ocm_api> Console URL: Region: us-east-1 Availability: - Control Plane: MultiAZ - Data Plane: SingleAZ Nodes: - Compute (desired): 2 - Compute (current): 0 Network: - Type: OVNKubernetes - Service CIDR: <service_cidr> - Machine CIDR: <machine_cidr> - Pod CIDR: <pod_cidr> - Host Prefix: /23 - Subnets: <subnet_ids> EC2 Metadata Http Tokens: optional Role (STS) ARN: arn:aws:iam::<AWS_id>:role/<account_roles_prefix>-HCP-ROSA-Installer-Role Support Role ARN: arn:aws:iam::<AWS_id>:role/<account_roles_prefix>-HCP-ROSA-Support-Role Instance IAM Roles: - Worker: arn:aws:iam::<AWS_id>:role/<account_roles_prefix>-HCP-ROSA-Worker-Role Operator IAM Roles: - arn:aws:iam::<AWS_id>:role/<operator_roles_prefix>-openshift-cloud-network-config-controller-clo - arn:aws:iam::<AWS_id>:role/<operator_roles_prefix>-kube-system-capa-controller-manager - arn:aws:iam::<AWS_id>:role/<operator_roles_prefix>-kube-system-control-plane-operator - arn:aws:iam::<AWS_id>:role/<operator_roles_prefix>-kube-system-kms-provider - arn:aws:iam::<AWS_id>:role/<operator_roles_prefix>-kube-system-kube-controller-manager - arn:aws:iam::<AWS_id>:role/<operator_roles_prefix>-openshift-image-registry-installer-cloud-cred - arn:aws:iam::<AWS_id>:role/<operator_roles_prefix>-openshift-ingress-operator-cloud-credentials - arn:aws:iam::<AWS_id>:role/<operator_roles_prefix>-openshift-cluster-csi-drivers-ebs-cloud-crede Managed Policies: Yes State: ready Private: No Created: Mar 29 2024 14:25:52 UTC User Workload Monitoring: Enabled Details Page: https://<url> OIDC Endpoint URL: https://<endpoint> (Managed) Audit Log Forwarding: Disabled External Authentication: Enabled 1
- 1
External Authentication
フラグが有効になり、外部認証プロバイダーを作成できるようになりました。
4.3. 外部認証プロバイダーの作成
外部認証プロバイダーのオプションを有効にして ROSA with HCP クラスターを作成した後、ROSA CLI を使用してプロバイダーを作成する必要があります。
ROSA CLI の rosa create|delete|list idp[s]
コマンドと同様に、rosa create external-auth-provider
を使用して作成した既存のアイデンティティープロバイダーを編集できません。代わりに、外部認証プロバイダーを削除して、新しい認証プロバイダーを作成する必要があります。
次の表は、外部認証プロバイダーを作成するときに使用できる CLI フラグを示しています。
CLI フラグ | 説明 |
---|---|
| クラスターの名前または ID。 |
| 外部認証プロバイダーを参照するために使用される名前。 |
| この文字列は、アカウントをアプリケーションに関連付けるために使用されるクライアントシークレット。クライアントシークレットを含めない場合、このコマンドはパブリック OIDC OAuthClient を使用します。 |
| これは、トークンオーディエンスのコンマ区切りリストです。 |
| トークン発行者の URL。 |
| クラスターアイデンティティーのユーザー名を構築するために使用されるクレームの名前。 |
| クラスターアイデンティティーのグループー名を構築するために使用されるクレームの名前。 |
手順
対話型コマンドインターフェイスを使用するには、次のコマンドを実行します。
$ rosa create external-auth-provider -c <cluster_name>
I: Enabling interactive mode ? Name: 1 ? Issuer audiences: 2 ? The serving url of the token issuer: 3 ? CA file path (optional): 4 ? Claim mapping username: 5 ? Claim mapping groups: 6 ? Claim validation rule (optional): 7 ? Console client id (optional): 8
- 1
- 外部認証プロバイダーの名前。この名前は、数字とダッシュが含まれる小文字である必要があります。
- 2
- この認証プロバイダーがトークンを発行するオーディエンス ID。
- 3
- トークンを提供する発行者の URL。
- 4
- オプション: リクエストを行うときに使用する証明書ファイル。
- 5
メール
の使用など、クラスターアイデンティティーのユーザー名を構築するために使用されるクレームの名前。- 6
グループ
の使用など、ID トークンをクラスターアイデンティティーに変換する方法。- 7
- オプション: ユーザーを認証するトークン要求を検証するのに役立つルール。このフィールドは、
:<required_value>
の形式にする必要があります。 - 8
- オプション: アプリ登録でコンソールに使用するアプリケーションまたはクライアント ID。
次のコマンドを使用して、外部認証プロバイダーを作成するために必要な ID を含めることができます。
rosa create external-auth-provider --cluster=<cluster_id> \ --name=<provider_name> --issuer-url=<issuing_url> \ --issuer-audiences=<audience_id> \ --claim-mapping-username-claim=email \ --claim-mapping-groups-claim=groups \ --console-client-id=<client_id_for_app_registration> \ --console-client-secret=<client_secret>
出力例
I: Successfully created an external authentication provider for cluster '<cluster_id>'
検証
外部認証プロバイダーを確認するには、次のいずれかのオプションを実行します。
次のコマンドを使用して、指定されたクラスターの外部認証設定をリスト表示します。
$ rosa list external-auth-provider -c <cluster_name>
出力例
次の例は、設定された Microsoft Entra ID 外部認証プロバイダーを示しています。
NAME ISSUER URL m-entra-id https://login.microsoftonline.com/<group_id>/v2.0
次のコマンドを使用して、指定されたクラスターの外部認証設定を表示します。
$ rosa describe external-auth-provider \ -c <cluster_name> --name <name_of_external_authentication>
出力例
ID: ms-entra-id Cluster ID: <cluster_id> Issuer audiences: - <audience_id> Issuer Url: https://login.microsoftonline.com/<group_id>/v2.0 Claim mappings group: groups Claim mappings username: email
関連情報
- IDP 用に Entra ID を設定する方法の詳細は、Azure ドキュメントの What is Microsoft Entra ID? または Microsoft Entra ID (旧称 Azure Active Directory) のアイデンティティープロバイダーとしての設定 ドキュメントのチュートリアルセクションを参照してください。
-
ROSA CLI の同様の
idps
ツールの詳細は、idp の作成
を参照してください。 -
ROSA CLI のオプションの詳細は、
create external-auth-provider
、list external-auth-provider
、およびdelete external-auth-provider
を参照してください。
4.4. ROSA with HCP の brak glass 認証情報の作成
ROSA with HCP クラスターの所有者は、break glass 認証情報を使用して一時的な管理クライアント認証情報を作成し、カスタム OpenID Connect (OIDC) トークン発行者を指定して設定されたクラスターにアクセスできます。Break glass 認証情報を作成すると、新しい cluster-admin kubeconfig
ファイルが生成されます。kubeconfig
ファイルには、CLI がクライアントを正しいクラスターと API サーバーに接続するために使用するクラスターに関する情報が含まれています。新しく生成された kubeconfig
ファイルを使用して、ROSA with HCP クラスターへのアクセスを許可できます。
前提条件
- 外部認証を有効にした ROSA with HCP クラスターが作成されている。詳細は、外部認証プロバイダーを使用する HCP クラスターを使用した ROSA with HCP の作成 を参照してください。
- 外部認証プロバイダーが作成されている。詳細は、外部認証プロバイダーの作成 を参照してください。
-
cluster admin
権限が割り当てられたアカウントがある。
手順
次のいずれかのコマンドを使用して、Break Glass 認証情報を作成します。
対話型コマンドインターフェイスを使用してカスタム設定を対話的に指定し、ブレークグラス認証情報を作成するには、次のコマンドを実行します。
$ rosa create break-glass-credential -c <cluster_name> -i 1
- 1
- <cluster_name> は、クラスターの名前に置き換えます。
このコマンドは、対話型 CLI プロセスを開始します。
出力例
I: Enabling interactive mode ? Username (optional): 1 ? Expiration duration (optional): 2 I: Successfully created a break glass credential for cluster 'ac-hcp-test'.
指定された値を使用して、
mycluster
というクラスターの Break Glass 認証情報を作成するには以下を実行します。$ rosa create break-glass-credential -c mycluster --username test-username --expiration 1h
次のコマンドを実行して、
mycluster
というクラスターで使用可能な Break Glass 認証情報 ID、ステータス、および関連ユーザーをリスト表示します。$ rosa list break-glass-credential -c mycluster
出力例
ID USERNAME STATUS 2a7jli9n4phe6c02ul7ti91djtv2o51d test-user issued
注記コマンドに
-o json
引数を追加することで、JSON 出力で認証情報を表示することもできます。break glass 認証情報のステータスを表示するには、<break_glass_credential_id> をブレークグラス認証情報 ID に置き換えて、次のコマンドを実行します。
$ rosa describe break-glass-credential <break_glass_credential_id> -c <cluster_name>
出力例
ID: 2a7jli9n4phe6c02ul7ti91djtv2o51d Username: test-user Expire at: Dec 28 2026 10:23:05 EDT Status: issued
Status
フィールドで使用可能な値のリストは次のとおりです。-
issued
break glass 認証情報が発行され、使用できる状態になりました。 -
expired
ブレークグラス認証情報の有効期限が切れているため、使用できなくなりました。 -
failed
ブレークグラス認証情報の作成に失敗しました。この場合、失敗の詳細を示すサービスログが送信されます。サービスログの詳細は、Red Hat OpenShift Service on AWS クラスターのサービスログへのアクセス を参照してください。Red Hat サポートに問い合わせる手順については、サポート を参照してください。 -
awaiting_revocation
break glass 認証情報は現在取り消されているため、使用できません。 -
revoked
break glass 認証情報は取り消されており、使用できなくなりました。
-
kubeconfig
を取得するには、次のコマンドを実行します。kubeconfig
ディレクトリーを作成します。$ mkdir ~/kubeconfigs
新しく生成された
kubeconfig
ファイルをエクスポートします。<cluster_name> はクラスターの名前に置き換えます。$ export CLUSTER_NAME=<cluster_name> && export KUBECONFIG=~/kubeconfigs/break-glass-${CLUSTER_NAME}.kubeconfig
kubeconfig
を表示します。$ rosa describe break-glass-credential <break_glass_credential_id> -c mycluster --kubeconfig
出力例
apiVersion: v1 clusters: - cluster: server: <server_url> name: cluster contexts: - context: cluster: cluster namespace: default user: test-username name: admin current-context: admin kind: Config preferences: {} users: - name: test-user user: client-certificate-data: <client-certificate-data> 1 client-key-data: <client-key-data> 2
オプション:
kubeconfig
を保存するには、次のコマンドを実行します。$ rosa describe break-glass-credential <break_glass_credential_id> -c mycluster --kubeconfig > $KUBECONFIG
関連情報
- 外部認証を有効にした ROSA with HCP クラスターの作成の詳細は、外部認証プロバイダーを使用する ROSA with HCP クラスターの作成 を参照してください。
- CLI 設定の詳細は、CLI プロファイルの管理 を参照してください。
4.5. Break glass 認証情報を使用した ROSA with HCP クラスターへのアクセス
Break glass 認証情報から新しい kubeconfig
を使用して、ROSA with HCP クラスターへの一時的な管理者アクセス権を取得します。
前提条件
- 外部認証が有効になっている ROSA with HCP クラスターにアクセスできる。詳細は、外部認証プロバイダーを使用する ROSA with HCP クラスターの作成 を参照してください。
-
oc
およびkubectl
CLI がインストールされている。 -
新しい
kubeconfig
が設定されている。詳細は、ROSA with HCP クラスターの Break Glass 認証情報の作成 を参照してください。
手順
クラスターの詳細にアクセスします。
$ rosa describe break-glass-credential <break_glass_credential_id> -c <cluster_name> --kubeconfig > $KUBECONFIG
クラスターからノードを一覧表示します。
$ oc get nodes
出力例
NAME STATUS ROLES AGE VERSION ip-10-0-0-27.ec2.internal Ready worker 8m v1.28.7+f1b5f6c ip-10-0-0-67.ec2.internal Ready worker 9m v1.28.7+f1b5f6c
適切な認証情報があることを確認します。
$ kubectl auth whoami
出力例
ATTRIBUTE VALUE Username system:customer-break-glass:test-user Groups [system:masters system:authenticated]
外部 OIDC プロバイダーで定義されたグループに
ClusterRoleBinding
を適用します。ClusterRoleBinding
は、Microsoft Entra ID で作成されたrosa-hcp-admins
グループを ROSA with HCP クラスター内のグループにマップします。$ oc apply -f - <<EOF apiVersion: rbac.authorization.k8s.io/v1 kind: ClusterRoleBinding metadata: name: rosa-hcp-admins roleRef: apiGroup: rbac.authorization.k8s.io kind: ClusterRole name: cluster-admin subjects: - apiGroup: rbac.authorization.k8s.io kind: Group name: f715c264-ab90-45d5-8a29-2e91a609a895 EOF
出力例
clusterrolebinding.rbac.authorization.k8s.io/rosa-hcp-admins created
注記ClusterRoleBinding
が適用されると、ROSA with HCP クラスターが設定され、rosa
CLI と Red Hat Hybrid Cloud Console が外部 OpenID Connect (OIDC) プロバイダーを通じて認証されます。ロールの割り当てとクラスターでのアプリケーションのデプロイを開始できるようになりました。
関連情報
- クラスターロールバインディングの詳細は、RBAC を使用したパーミッションの定義および適用 を参照してください。
4.6. ROSA with HCP クラスターの Break Glass 認証情報の取り消し
revoke break-glass-credentials
コマンドを使用すると、プロビジョニングした Break Glass 認証情報へのアクセスをいつでも取り消すことができます。
前提条件
- break glass 認証情報が作成されている。
- クラスターの所有者である。
手順
次のコマンドを実行して、ROSA with HCP クラスターの Break Glass 認証情報を取り消します。
重要このコマンドを実行すると、クラスターに関連するすべての Break Glass 認証情報へのアクセスが取り消されます。
$ rosa revoke break-glass-credentials -c <cluster_name> 1
- 1
- <cluster_name> は、クラスターの名前に置き換えます。
出力例
? Are you sure you want to revoke all the break glass credentials on cluster 'my-cluster'?: Yes I: Successfully requested revocation for all break glass credentials from cluster 'my-cluster'
検証
失効処理には数分かかる場合があります。次のいずれかのコマンドを実行すると、クラスターの Break Glass 認証情報が取り消されたことを確認できます。
すべての Break Glass 認証情報をリスト表示し、それぞれのステータスを確認します。
$ rosa list break-glass-credential -c <cluster_name>
出力例
ID USERNAME STATUS 2330dbs0n8m3chkkr25gkkcd8pnj3lk2 test-user awaiting_revocation
個々の認証情報をチェックしてステータスを確認することもできます。
$ rosa describe break-glass-credential <break_glass_credential_id> -c <cluster_name>
出力例
ID: 2330dbs0n8m3chkkr25gkkcd8pnj3lk2 Username: test-user Expire at: Dec 28 2026 10:23:05 EDT Status: issued Revoked at: Dec 27 2026 15:30:33 EDT
4.7. 外部認証プロバイダーの削除
ROSA CLI を使用して外部認証プロバイダーを削除します。
手順
次のコマンドを実行して、クラスター上の外部認証プロバイダーを表示します。
$ rosa list external-auth-provider -c <cluster_name>
出力例
NAME ISSUER URL entra-test https://login.microsoftonline.com/<group_id>/v2.0
次のコマンドを実行して、外部認証プロバイダーを削除します。
$ rosa delete external-auth-provider <name_of_provider> -c <cluster_name>
出力例
? Are you sure you want to delete external authentication provider entra-test on cluster rosa-ext-test? Yes I: Successfully deleted external authentication provider 'entra-test' from cluster 'rosa-ext-test'
検証
次のコマンドを実行して、クラスター上の外部認証プロバイダーを照会します。
$ rosa list external-auth-provider -c <cluster_name>
出力例
E: there are no external authentication providers for this cluster
4.8. 関連情報
- 手動モードを使用して ROSA クラスターをデプロイする手順は、カスタマイズを使用したクラスターの作成 を参照してください。
- STS を使用する Red Hat OpenShift Service on AWS をデプロイするのに必要な AWS Identity Access Management (IAM) リソースの詳細は、STS を使用するクラスターの IAM リソースについて を参照してください。
- Red Hat OpenShift Service on AWS のデフォルト CIDR 範囲について、詳細は CIDR 範囲の定義 を参照してください。
- オプションで Operator ロール名接頭辞を設定する方法の詳細は、カスタム Operator IAM ロール接頭辞について を参照してください。
- STS を使用する ROSA をインストールするための前提条件の詳細は、STS を使用する ROSA の AWS の前提条件 を参照してください。
-
auto
モードとmanual
モードを使用して必要な STS リソースを作成する方法の詳細は、自動デプロイメントモードと手動デプロイメントモードについて を参照してください。 - AWS IAM で OpenID Connect (OIDC) アイデンティティープロバイダーの使用に関する詳細は、AWS ドキュメントの Creating OpenID Connect (OIDC) identity providers を参照してください。
- ROSA クラスターのインストールのトラブルシューティングの詳細は、インストールのトラブルシューティング を参照してください。
- Red Hat サポートにサポートを依頼する手順は、Red Hat OpenShift Service on AWS のサポートを受ける を参照してください。
第5章 HCP を備えた ROSA クラスターでの Node Tuning Operator の使用
Red Hat OpenShift Service on AWS (ROSA) with Hosted Control Plane (HCP) は、ROSA with HCP クラスター上のノードのパフォーマンスを向上させる Node Tuning Operator をサポートしています。ノード調整設定を作成する前に、カスタム調整仕様を作成する必要があります。
目的
Node Tuning Operator は、TuneD デーモンを調整することでノードレベルのチューニングを管理し、パフォーマンスプロファイルコントローラーを使用して低レイテンシーのパフォーマンスを実現するのに役立ちます。ほとんどの高パフォーマンスアプリケーションでは、一定レベルのカーネルのチューニングが必要です。Node Tuning Operator は、ノードレベルの sysctl の統一された管理インターフェイスをユーザーに提供し、ユーザーが指定するカスタムチューニングを追加できるよう柔軟性を提供します。
Operator は、コンテナー化された Red Hat OpenShift Service on AWS の TuneD デーモンを Kubernetes デーモンセットとして管理します。これにより、カスタムチューニング仕様が、デーモンが認識する形式でクラスターで実行されるすべてのコンテナー化された TuneD デーモンに渡されます。デーモンは、ノードごとに 1 つずつ、クラスターのすべてのノードで実行されます。
コンテナー化された TuneD デーモンによって適用されるノードレベルの設定は、プロファイルの変更をトリガーするイベントで、または終了シグナルの受信および処理によってコンテナー化された TuneD デーモンが正常に終了する際にロールバックされます。
Node Tuning Operator は、Performance Profile コントローラーを使用して自動チューニングを実装し、Red Hat OpenShift Service on AWS アプリケーションの低レイテンシーパフォーマンスを実現します。
クラスター管理者は、以下のようなノードレベルの設定を定義するパフォーマンスプロファイルを設定します。
- カーネルを kernel-rt に更新します。
- ハウスキーピング用の CPU を選択します。
- 実行中のワークロード用の CPU を選択します。
現在、CPU 負荷分散の無効化は cgroup v2 ではサポートされていません。その結果、cgroup v2 が有効になっている場合は、パフォーマンスプロファイルから望ましい動作が得られない可能性があります。パフォーマンスプロファイルを使用している場合は、cgroup v2 を有効にすることは推奨されません。
Node Tuning Operator は、バージョン 4.1 以降の標準の Red Hat OpenShift Service on AWS インストールに含まれています。
Red Hat OpenShift Service on AWS の以前のバージョンでは、OpenShift アプリケーションの低レイテンシーパフォーマンスを実現する自動チューニングを実装するために Performance Addon Operator が使用されていました。Red Hat OpenShift Service on AWS 4.11 以降では、この機能は Node Tuning Operator の一部です。
5.1. カスタムチューニング仕様
Operator のカスタムリソース (CR) には 2 つの重要なセクションがあります。1 つ目のセクションの profile:
は TuneD プロファイルおよびそれらの名前のリストです。2 つ目の recommend:
は、プロファイル選択ロジックを定義します。
複数のカスタムチューニング仕様は、Operator の namespace に複数の CR として共存できます。新規 CR の存在または古い CR の削除は Operator によって検出されます。既存のカスタムチューニング仕様はすべてマージされ、コンテナー化された TuneD デーモンの適切なオブジェクトは更新されます。
管理状態
Operator 管理の状態は、デフォルトの Tuned CR を調整して設定されます。デフォルトで、Operator は Managed 状態であり、spec.managementState
フィールドはデフォルトの Tuned CR に表示されません。Operator Management 状態の有効な値は以下のとおりです。
- Managed: Operator は設定リソースが更新されるとそのオペランドを更新します。
- Unmanaged: Operator は設定リソースへの変更を無視します。
- Removed: Operator は Operator がプロビジョニングしたオペランドおよびリソースを削除します。
プロファイルデータ
profile:
セクションは、TuneD プロファイルおよびそれらの名前をリスト表示します。
{ "profile": [ { "name": "tuned_profile_1", "data": "# TuneD profile specification\n[main]\nsummary=Description of tuned_profile_1 profile\n\n[sysctl]\nnet.ipv4.ip_forward=1\n# ... other sysctl's or other TuneD daemon plugins supported by the containerized TuneD\n" }, { "name": "tuned_profile_n", "data": "# TuneD profile specification\n[main]\nsummary=Description of tuned_profile_n profile\n\n# tuned_profile_n profile settings\n" } ] }
推奨プロファイル
profile:
選択ロジックは、CR の recommend:
セクションによって定義されます。recommend:
セクションは、選択基準に基づくプロファイルの推奨項目のリストです。
"recommend": [ { "recommend-item-1": details_of_recommendation, # ... "recommend-item-n": details_of_recommendation, } ]
リストの個別項目:
{ "profile": [ { # ... } ], "recommend": [ { "profile": <tuned_profile_name>, 1 "priority":{ <priority>, 2 }, "match": [ 3 { "label": <label_information> 4 }, ] }, ] }
<match>
は、以下のように再帰的に定義されるオプションの一覧です。
"match": [
{
"label": 1
},
]
- 1
- ノードまたは Pod のラベル名。
<match>
が省略されない場合、ネストされたすべての <match>
セクションが true
に評価される必要もあります。そうでない場合には false
が想定され、それぞれの <match>
セクションのあるプロファイルは適用されず、推奨されません。そのため、ネスト化 (子の <match>
セクション) は論理 AND 演算子として機能します。これとは逆に、<match>
一覧のいずれかの項目が一致する場合は、<match>
の一覧全体が true
に評価されます。そのため、リストは論理 OR 演算子として機能します。
例: ノードまたは Pod のラベルベースのマッチング
[ { "match": [ { "label": "tuned.openshift.io/elasticsearch", "match": [ { "label": "node-role.kubernetes.io/master" }, { "label": "node-role.kubernetes.io/infra" } ], "type": "pod" } ], "priority": 10, "profile": "openshift-control-plane-es" }, { "match": [ { "label": "node-role.kubernetes.io/master" }, { "label": "node-role.kubernetes.io/infra" } ], "priority": 20, "profile": "openshift-control-plane" }, { "priority": 30, "profile": "openshift-node" } ]
上記のコンテナー化された TuneD デーモンの CR は、プロファイルの優先順位に基づいてその recommend.conf
ファイルに変換されます。最も高い優先順位 (10
) を持つプロファイルは openshift-control-plane-es
であるため、これが最初に考慮されます。指定されたノードで実行されるコンテナー化された TuneD デーモンは、同じノードに tuned.openshift.io/elasticsearch
ラベルが設定された Pod が実行されているかどうかを確認します。これがない場合は、<match>
セクション全体が false
として評価されます。このラベルを持つこのような Pod がある場合に、<match>
セクションが true
に評価されるようにするには、ノードラベルを node-role.kubernetes.io/master
または node-role.kubernetes.io/infra
にする必要もあります。
優先順位が 10
のプロファイルのラベルが一致した場合は、openshift-control-plane-es
プロファイルが適用され、その他のプロファイルは考慮されません。ノード/Pod ラベルの組み合わせが一致しない場合は、2 番目に高い優先順位プロファイル (openshift-control-plane
) が考慮されます。このプロファイルは、コンテナー化された TuneD Pod が node-role.kubernetes.io/master
または node-role.kubernetes.io/infra
ラベルを持つノードで実行される場合に適用されます。
最後に、プロファイル openshift-node
には最低の優先順位である 30
が設定されます。これには <match>
セクションがないため、常に一致します。これは、より高い優先順位の他のプロファイルが指定されたノードで一致しない場合に openshift-node
プロファイルを設定するために、最低の優先順位のノードが適用される汎用的な (catch-all) プロファイルとして機能します。
例: マシンプールベースのマッチング
{ "apiVersion": "tuned.openshift.io/v1", "kind": "Tuned", "metadata": { "name": "openshift-node-custom", "namespace": "openshift-cluster-node-tuning-operator" }, "spec": { "profile": [ { "data": "[main]\nsummary=Custom OpenShift node profile with an additional kernel parameter\ninclude=openshift-node\n[bootloader]\ncmdline_openshift_node_custom=+skew_tick=1\n", "name": "openshift-node-custom" } ], "recommend": [ { "priority": 20, "profile": "openshift-node-custom" } ] } }
クラウドプロバイダー固有の TuneD プロファイル
この機能により、すべてのクラウドプロバイダー固有のノードに、Red Hat OpenShift Service on AWS クラスター上の特定のクラウドプロバイダーに合わせて特別に調整された TuneD プロファイルを簡単に割り当てることができます。別のノードラベルを追加したり、ノードをマシンプールにグループ化したりする必要はありません。
この機能は、<cloud-provider>://<cloud-provider-specific-id>
の形式で spec.providerID
ノードオブジェクト値を利用して、NTO オペランドコンテナーの <cloud-provider>
の値で /var/lib/tuned/provider
ファイルを書き込みます。その後、このファイルのコンテンツは TuneD により、プロバイダー provider-<cloud-provider>
プロファイル (存在する場合) を読み込むために使用されます。
openshift-control-plane
および openshift-node
プロファイルの両方の設定を継承する openshift
プロファイルは、条件付きプロファイルの読み込みを使用してこの機能を使用するよう更新されるようになりました。現時点で、NTO や TuneD にクラウドプロバイダー固有のプロファイルは含まれていません。ただし、すべての クラウドプロバイダー固有のクラスターノードに適用されるカスタムプロファイル provider-<cloud-provider>
を作成できます。
GCE クラウドプロバイダープロファイルの例
{ "apiVersion": "tuned.openshift.io/v1", "kind": "Tuned", "metadata": { "name": "provider-gce", "namespace": "openshift-cluster-node-tuning-operator" }, "spec": { "profile": [ { "data": "[main]\nsummary=GCE Cloud provider-specific profile\n# Your tuning for GCE Cloud provider goes here.\n", "name": "provider-gce" } ] } }
プロファイルの継承により、provider-<cloud-provider>
プロファイルで指定された設定は、openshift
プロファイルとその子プロファイルによって上書きされます。
5.2. ROSA with HCP のノードチューニング設定の作成
Red Hat OpenShift Service on AWS (ROSA) CLI (rosa
) を使用してチューニング設定を作成できます。
前提条件
- ROSA CLI の最新バージョンをダウンロードしている。
- 最新バージョンのクラスターがある。
- ノードチューニング用に設定された仕様ファイルがある。
手順
次のコマンドを実行して、チューニング設定を作成します。
$ rosa create tuning-config -c <cluster_id> --name <name_of_tuning> --spec-path <path_to_spec_file>
spec.json
ファイルへのパスを指定する必要があります。指定しない場合、コマンドはエラーを返します。出力例
$ I: Tuning config 'sample-tuning' has been created on cluster 'cluster-example'. $ I: To view all tuning configs, run 'rosa list tuning-configs -c cluster-example'
検証
次のコマンドを使用して、アカウントによって適用されている既存のチューニング設定を確認できます。
$ rosa list tuning-configs -c <cluster_name> [-o json]
設定リストに必要な出力のタイプを指定できます。
出力タイプを指定しないと、チューニング設定の ID と名前が表示されます。
出力タイプを指定しない出力例
ID NAME 20468b8e-edc7-11ed-b0e4-0a580a800298 sample-tuning
json
などの出力タイプを指定すると、チューニング設定を JSON テキストとして受け取ります。注記次の JSON 出力には、読みやすくするために改行が含まれています。この JSON 出力は、JSON 文字列内の改行を削除しない限り無効です。
JSON 出力を指定したサンプル出力
[ { "kind": "TuningConfig", "id": "20468b8e-edc7-11ed-b0e4-0a580a800298", "href": "/api/clusters_mgmt/v1/clusters/23jbsevqb22l0m58ps39ua4trff9179e/tuning_configs/20468b8e-edc7-11ed-b0e4-0a580a800298", "name": "sample-tuning", "spec": { "profile": [ { "data": "[main]\nsummary=Custom OpenShift profile\ninclude=openshift-node\n\n[sysctl]\nvm.dirty_ratio=\"55\"\n", "name": "tuned-1-profile" } ], "recommend": [ { "priority": 20, "profile": "tuned-1-profile" } ] } } ]
5.3. ROSA with HCP のノードチューニング設定の変更
Red Hat OpenShift Service on AWS (ROSA) CLI (rosa
) を使用して、ノードチューニング設定を表示し、更新できます。
前提条件
- ROSA CLI の最新バージョンをダウンロードしている。
- 最新バージョンのクラスターがある。
- クラスターにノード調整設定が追加されている。
手順
チューニング設定を表示するには、
rosa description
コマンドを使用します。$ rosa describe tuning-config -c <cluster_id> 1 --name <name_of_tuning> 2 [-o json] 3
この仕様ファイルの次の項目は次のとおりです。
出力タイプを指定しない出力例
Name: sample-tuning ID: 20468b8e-edc7-11ed-b0e4-0a580a800298 Spec: { "profile": [ { "data": "[main]\nsummary=Custom OpenShift profile\ninclude=openshift-node\n\n[sysctl]\nvm.dirty_ratio=\"55\"\n", "name": "tuned-1-profile" } ], "recommend": [ { "priority": 20, "profile": "tuned-1-profile" } ] }
JSON 出力を指定したサンプル出力
{ "kind": "TuningConfig", "id": "20468b8e-edc7-11ed-b0e4-0a580a800298", "href": "/api/clusters_mgmt/v1/clusters/23jbsevqb22l0m58ps39ua4trff9179e/tuning_configs/20468b8e-edc7-11ed-b0e4-0a580a800298", "name": "sample-tuning", "spec": { "profile": [ { "data": "[main]\nsummary=Custom OpenShift profile\ninclude=openshift-node\n\n[sysctl]\nvm.dirty_ratio=\"55\"\n", "name": "tuned-1-profile" } ], "recommend": [ { "priority": 20, "profile": "tuned-1-profile" } ] } }
チューニング設定を確認した後、
rosa edit
コマンドを使用して既存の設定を編集します。$ rosa edit tuning-config -c <cluster_id> --name <name_of_tuning> --spec-path <path_to_spec_file>
このコマンドでは、
spec.json
ファイルを使用して設定を編集します。
検証
rosa description
コマンドを再度実行して、spec.json
ファイルに加えた変更がチューニング設定で更新されていることを確認します。$ rosa describe tuning-config -c <cluster_id> --name <name_of_tuning>
出力例
Name: sample-tuning ID: 20468b8e-edc7-11ed-b0e4-0a580a800298 Spec: { "profile": [ { "data": "[main]\nsummary=Custom OpenShift profile\ninclude=openshift-node\n\n[sysctl]\nvm.dirty_ratio=\"55\"\n", "name": "tuned-2-profile" } ], "recommend": [ { "priority": 10, "profile": "tuned-2-profile" } ] }
5.4. ROSA with HCP のノードチューニング設定の削除
Red Hat OpenShift Service on AWS (ROSA) CLI (rosa
) を使用して、チューニング設定を削除できます。
マシンプールで参照されているチューニング設定は削除できません。チューニング設定を削除する前に、すべてのマシンプールからチューニング設定を削除する必要があります。
前提条件
- ROSA CLI の最新バージョンをダウンロードしている。
- 最新バージョンのクラスターがある。
- クラスターに、削除したいノードチューニング設定がある。
手順
チューニング設定を削除するには、次のコマンドを実行します。
$ rosa delete tuning-config -c <cluster_id> <name_of_tuning>
クラスター上のチューニング設定が削除されました。
出力例
? Are you sure you want to delete tuning config sample-tuning on cluster sample-cluster? Yes I: Successfully deleted tuning config 'sample-tuning' from cluster 'sample-cluster'
第6章 ROSA with HCP クラスターの削除
Red Hat OpenShift Service on AWS (ROSA) with hosted control planes (HCP) クラスターを削除する場合は、Red Hat OpenShift Cluster Manager または ROSA コマンドラインインターフェイス (CLI) (rosa
) のいずれかを使用できます。クラスターを削除した後、クラスターで使用されている AWS Identity and Access Management (IAM) リソースを削除することもできます。
6.1. ROSA with HCP クラスターとクラスター固有の IAM リソースの削除
ROSA コマンドラインインターフェイス (CLI) (rosa
) または Red Hat OpenShift Cluster Manager を使用して、ROSA with HCP クラスターを削除できます。
クラスターを削除した後、ROSA CLI を使用して、AWS アカウント内のクラスター固有のアイデンティティーおよびアクセス管理 (IAM) リソースを消去できます。クラスター固有のリソースには、Operator ロールと OpenID Connect (OIDC) プロバイダーが含まれます。
IAM リソースは、クラスターの削除およびクリーンアップのプロセスで使用されるため、クラスターの削除は、IAM リソースを削除する前に完了する必要があります。
アドオンがインストールされている場合、クラスターの削除前にアドオンをアンインストールするため、削除により多くの時間がかかります。所要時間は、アドオンの数とサイズによって異なります。
前提条件
- ROSA with HCP クラスターをインストールした。
-
インストールホストに、最新の ROSA CLI (
rosa
) をインストールして設定している。
手順
次のコマンドを実行して、クラスター ID、クラスター固有の Operator ロールの Amazon リソース名 (ARN)、および OIDC プロバイダーのエンドポイント URL を取得します。
$ rosa describe cluster --cluster=<cluster_name>
出力例
Name: test_cluster Domain Prefix: test_cluster Display Name: test_cluster ID: <cluster_id> 1 External ID: <external_id> Control Plane: ROSA Service Hosted OpenShift Version: 4.15.0 Channel Group: stable DNS: test_cluster.l3cn.p3.openshiftapps.com AWS Account: <AWS_id> AWS Billing Account: <AWS_id> API URL: https://api.test_cluster.l3cn.p3.openshiftapps.com:443 Console URL: Region: us-east-1 Availability: - Control Plane: MultiAZ - Data Plane: SingleAZ Nodes: - Compute (desired): 2 - Compute (current): 0 Network: - Type: OVNKubernetes - Service CIDR: 172.30.0.0/16 - Machine CIDR: 10.0.0.0/16 - Pod CIDR: 10.128.0.0/14 - Host Prefix: /23 - Subnets: <subnet_ids> EC2 Metadata Http Tokens: optional Role (STS) ARN: arn:aws:iam::<AWS_id>:role/test_cluster-HCP-ROSA-Installer-Role Support Role ARN: arn:aws:iam::<AWS_id>:role/test_cluster-HCP-ROSA-Support-Role Instance IAM Roles: - Worker: arn:aws:iam::<AWS_id>:role/test_cluster-HCP-ROSA-Worker-Role Operator IAM Roles: 2 - arn:aws:iam::<AWS_id>:role/test_cluster-openshift-cloud-network-config-controller-cloud-crede - arn:aws:iam::<AWS_id>:role/test_cluster-openshift-image-registry-installer-cloud-credentials - arn:aws:iam::<AWS_id>:role/test_cluster-openshift-ingress-operator-cloud-credentials - arn:aws:iam::<AWS_id>:role/test_cluster-kube-system-kube-controller-manager - arn:aws:iam::<AWS_id>:role/test_cluster-kube-system-capa-controller-manager - arn:aws:iam::<AWS_id>:role/test_cluster-kube-system-control-plane-operator - arn:aws:iam::<AWS_id>:role/hcpcluster-kube-system-kms-provider - arn:aws:iam::<AWS_id>:role/test_cluster-openshift-cluster-csi-drivers-ebs-cloud-credentials Managed Policies: Yes State: ready Private: No Created: Apr 16 2024 20:32:06 UTC User Workload Monitoring: Enabled Details Page: https://console.redhat.com/openshift/details/s/<cluster_id> OIDC Endpoint URL: https://oidc.op1.openshiftapps.com/<cluster_id> (Managed) 3 Audit Log Forwarding: Disabled External Authentication: Disabled
重要クラスターを削除した後、ROSA CLI を使用してクラスター固有の STS リソースを削除するには、クラスター ID が必要になります。
OpenShift Cluster Manager または ROSA CLI (
rosa
) を使用してクラスターを削除します。OpenShift Cluster Manager を使用してクラスターを削除するには、以下を実行します。
- OpenShift Cluster Manager に移動します。
- クラスターの横にあるオプションメニュー をクリックし、Delete cluster を選択します。
- プロンプトにクラスターの名前を入力し、Delete をクリックします。
ROSA CLI を使用してクラスターを削除するには:
次のコマンドを実行します。
<cluster_name>
は、クラスターの名前または ID に置き換えます。$ rosa delete cluster --cluster=<cluster_name> --watch
重要Operator ロールと OIDC プロバイダーを削除する前に、クラスターの削除が完了するまで待つ必要があります。
次のコマンドを実行して、クラスター固有の Operator IAM ロールを削除します。
$ rosa delete operator-roles --prefix <operator_role_prefix>
次のコマンドを実行して OIDC プロバイダーを削除します。
$ rosa delete oidc-provider --oidc-config-id <oidc_config_id>
トラブルシューティング
- IAM ロールが欠落しているためにクラスターを削除できない場合は、削除できないクラスターの修復 を参照してください。
他の理由でクラスターを削除できない場合:
- Hybrid Cloud Console で保留中のクラスターのアドオンがないことを確認します。
- Amazon Web Console で、すべての AWS リソースと依存関係が削除されていることを確認します。
6.2. アカウント全体の IAM リソースを削除する
アカウント全体の AWS アイデンティティーおよびアクセス管理 (IAM) リソースに依存する Hosted Control Plane (HCP) クラスターを備えたすべての Red Hat OpenShift Service on AWS (ROSA) を削除したら、アカウント全体のリソースを削除できます。
Red Hat OpenShift Cluster Manager を使用して HCP クラスターで ROSA をインストールする必要がなくなった場合は、OpenShift Cluster Manager とユーザー IAM ロールを削除することもできます。
アカウント全体の IAM ロールおよびポリシーは、同じ AWS アカウントの他の ROSA with HCP クラスターによって使用される可能性があります。他のクラスターで必要でない場合にのみリソースを削除します。
OpenShift Cluster Manager を使用して同じ AWS アカウント内の他の Red Hat OpenShift Service on AWS クラスターをインストール、管理、および削除する場合は、OpenShift Cluster Manager とユーザーの IAM ロールが必要です。OpenShift Cluster Manager を使用してアカウントに Red Hat OpenShift Service on AWS クラスターをインストールする必要がなくなった場合にのみ、ロールを削除してください。削除前にこれらのロールが削除された場合にクラスターを修復する方法は、クラスターのデプロイメントのトラブルシューティング の削除できないクラスターの修復を参照してください。
関連情報
6.2.1. アカウント全体の IAM ロールとポリシーの削除
このセクションでは、ROSA with HCP のデプロイ用に作成したアカウント全体の IAM ロールおよびポリシーを、アカウント全体の Operator ポリシーとともに削除する手順について説明します。アカウント全体の AWS アイデンティティーおよびアクセス管理 (IAM) ロールとポリシーは、それらに依存するすべての ROSA with HCP クラスターを削除した後にのみ削除できます。
アカウント全体の IAM ロールとポリシーは、同じ AWS アカウント内の他の Red Hat OpenShift Service on AWS によって使用される可能性があります。他のクラスターで必要とされていない場合に限り、ロールだけを削除します。
前提条件
- 削除するアカウント全体の IAM ロールがある。
-
インストールホストに、最新の ROSA CLI (
rosa
) をインストールして設定している。
手順
アカウント全体のロールを削除します。
ROSA CLI (
rosa
) を使用して、AWS アカウントのアカウント全体のロールをリスト表示します。$ rosa list account-roles
出力例
I: Fetching account roles ROLE NAME ROLE TYPE ROLE ARN OPENSHIFT VERSION AWS Managed ManagedOpenShift-HCP-ROSA-Installer-Role Installer arn:aws:iam::<aws_account_id>:role/ManagedOpenShift-HCP-ROSA-Installer-Role 4.15 Yes ManagedOpenShift-HCP-ROSA-Support-Role Support arn:aws:iam::<aws_account_id>:role/ManagedOpenShift-HCP-ROSA-Support-Role 4.15 Yes ManagedOpenShift-HCP-ROSA-Worker-Role Worker arn:aws:iam::<aws_account_id>:role/ManagedOpenShift-HCP-ROSA-Worker-Role 4.15 Yes
アカウント全体のロールを削除します。
$ rosa delete account-roles --prefix <prefix> --mode auto 1
- 1
- その際、
--<prefix>
引数を含める必要があります。<prefix>
を削除するアカウント全体のロールの接頭辞に置き換えてください。アカウント全体のロールを作成したときにカスタム接頭辞を指定しなかった場合は、デフォルトの接頭辞であるManagedOpenShift
を指定します。
重要アカウント全体の IAM ロールは、同じ AWS アカウント内の他の ROSA クラスターによって使用される場合があります。他のクラスターで必要とされていない場合に限り、ロールだけを削除します。
出力例
W: There are no classic account roles to be deleted I: Deleting hosted CP account roles ? Delete the account role 'delete-rosa-HCP-ROSA-Installer-Role'? Yes I: Deleting account role 'delete-rosa-HCP-ROSA-Installer-Role' ? Delete the account role 'delete-rosa-HCP-ROSA-Support-Role'? Yes I: Deleting account role 'delete-rosa-HCP-ROSA-Support-Role' ? Delete the account role 'delete-rosa-HCP-ROSA-Worker-Role'? Yes I: Deleting account role 'delete-rosa-HCP-ROSA-Worker-Role' I: Successfully deleted the hosted CP account roles
アカウント全体のインラインポリシーと Operator ポリシーを削除します。
AWS IAM Console の Policies ページで、アカウント全体のロールとポリシーを作成したときに指定した接頭辞でポリシーのリストをフィルタリングします。
注記アカウント全体のロールを作成したときにカスタム接頭辞を指定しなかった場合は、デフォルトの接頭辞である
ManagedOpenShift
を検索します。AWS IAM Console を使用して、アカウント全体のインラインポリシーと Operator ポリシーを削除します。AWS IAM コンソールを使用して IAM ポリシーを削除する方法の詳細は、AWS ドキュメントの IAM ポリシーの削除 を参照してください。
重要アカウント全体のインライン IAM ポリシーと Operator IAM ポリシーは、同じ AWS アカウント内の他の ROSA with HCP によって使用される可能性があります。他のクラスターで必要とされていない場合に限り、ロールだけを削除します。
6.2.2. OpenShift Cluster Manager およびユーザー IAM ロールのリンク解除と削除
Red Hat OpenShift Cluster Manager を使用して ROSA with HCP クラスターをインストールすると、OpenShift Cluster Manager と、Red Hat 組織にリンクするユーザーアイデンティティーおよびアクセス管理 (IAM) ロールも作成されます。クラスターを削除した後、ROSA CLI (rosa
) を使用して、ロールのリンクを解除して削除できます。
OpenShift Cluster Manager を使用して同じ AWS アカウントに他の ROSA クラスターをインストールおよび管理する場合は、OpenShift Cluster Manager とユーザー IAM ロールが必要です。OpenShift Cluster Manager を使用して ROSA with HCP クラスターをインストールする必要がなくなった場合にのみ、ロールを削除してください。
前提条件
- OpenShift Cluster Manager とユーザー IAM ロールを作成し、それらを Red Hat 組織にリンクしている。
-
インストールホストに、最新の ROSA CLI (
rosa
) をインストールして設定している。 - Red Hat 組織で組織管理者権限があります。
手順
Red Hat 組織から OpenShift Cluster Manager IAM ロールのリンクを解除し、ロールを削除します。
AWS アカウントで OpenShift Cluster Manager IAM ロールをリスト表示します。
$ rosa list ocm-roles
出力例
I: Fetching ocm roles ROLE NAME ROLE ARN LINKED ADMIN AWS Managed ManagedOpenShift-OCM-Role-<red_hat_organization_external_id> arn:aws:iam::<aws_account_id>:role/ManagedOpenShift-OCM-Role-<red_hat_organization_external_id> Yes Yes Yes
上記のコマンドの出力で OpenShift Cluster Manager IAM ロールがリンク済みとしてリストされている場合は、次のコマンドを実行して、Red Hat 組織からロールのリンクを解除します。
$ rosa unlink ocm-role --role-arn <arn> 1
- 1
<arn>
を OpenShift Cluster Manager IAM ロールの Amazon Resource Name (ARN) に置き換えます。ARN は、前のコマンドの出力で指定されます。上記の例では、ARN の形式はarn:aws:iam::<aws_account_id>:role/ManagedOpenShift-OCM-Role-<red_hat_organization_external_id>
です。
出力例
I: Unlinking OCM role ? Unlink the 'arn:aws:iam::<aws_account_id>:role/ManagedOpenShift-OCM-Role-<red_hat_organization_external_id>' role from organization '<red_hat_organization_id>'? Yes I: Successfully unlinked role-arn 'arn:aws:iam::<aws_account_id>:role/ManagedOpenShift-OCM-Role-<red_hat_organization_external_id>' from organization account '<red_hat_organization_id>'
OpenShift Cluster Manager IAM のロールとポリシーを削除します。
$ rosa delete ocm-role --role-arn <arn>
出力例
I: Deleting OCM role ? OCM Role ARN: arn:aws:iam::<aws_account_id>:role/ManagedOpenShift-OCM-Role-<red_hat_organization_external_id> ? Delete 'arn:aws:iam::<aws_account_id>:role/ManagedOpenShift-OCM-Role-<red_hat_organization_external_id>' ocm role? Yes ? OCM role deletion mode: auto 1 I: Successfully deleted the OCM role
- 1
- 削除モードを指定します。
auto
モードを使用して、OpenShift Cluster Manager IAM ロールとポリシーを自動的に削除できます。manual
モードでは、ROSA CLI はロールとポリシーを削除するために必要なaws
コマンドを生成します。manual
モードでは、aws
コマンドを手動で実行する前に詳細を確認することができます。
Red Hat 組織からユーザー IAM ロールのリンクを解除し、ロールを削除します。
AWS アカウントのユーザー IAM ロールをリスト表示します。
$ rosa list user-roles
出力例
I: Fetching user roles ROLE NAME ROLE ARN LINKED ManagedOpenShift-User-<ocm_user_name>-Role arn:aws:iam::<aws_account_id>:role/ManagedOpenShift-User-<ocm_user_name>-Role Yes
上記のコマンドの出力にユーザー IAM ロールがリンクされていると表示されている場合は、Red Hat 組織からロールのリンクを解除します。
$ rosa unlink user-role --role-arn <arn> 1
- 1
<arn>
をユーザー IAM ロールの Amazon Resource Name (ARN) に置き換えます。ARN は、前のコマンドの出力で指定されます。前の例では、ARN の形式はarn:aws:iam::<aws_account_id>:role/ManagedOpenShift-User-<ocm_user_name>-Role
です。
出力例
I: Unlinking user role ? Unlink the 'arn:aws:iam::<aws_account_id>:role/ManagedOpenShift-User-<ocm_user_name>-Role' role from the current account '<ocm_user_account_id>'? Yes I: Successfully unlinked role ARN 'arn:aws:iam::<aws_account_id>:role/ManagedOpenShift-User-<ocm_user_name>-Role' from account '<ocm_user_account_id>'
ユーザー IAM ロールを削除します。
$ rosa delete user-role --role-arn <arn>
出力例
I: Deleting user role ? User Role ARN: arn:aws:iam::<aws_account_id>:role/ManagedOpenShift-User-<ocm_user_name>-Role ? Delete the 'arn:aws:iam::<aws_account_id>:role/ManagedOpenShift-User-<ocm_user_name>-Role' role from the AWS account? Yes ? User role deletion mode: auto 1 I: Successfully deleted the user role
- 1
- 削除モードを指定します。
auto
モードを使用して、ユーザー IAM ロールを自動的に削除できます。manual
モードでは、ROSA CLI はロールを削除するために必要なaws
コマンドを生成します。manual
モードでは、aws
コマンドを手動で実行する前に詳細を確認できます。