4.15. AWS Outposts のリモートワーカーを使用して AWS にクラスターをインストールする

OpenShift Container Platform バージョン 4.14 では、AWS Outposts で実行されているリモートワーカーを使用して、Amazon Web Services (AWS) にクラスターをインストールできます。これは、デフォルトの AWS インストールをカスタマイズし、いくつかの手動による手順を実行することで実現できます。

重要

AWS Outposts 上のリモートワーカーを使用して AWS にクラスターをインストールする機能は、テクノロジープレビューとしてのみ使用できます。テクノロジープレビュー機能は、Red Hat 製品サポートのサービスレベルアグリーメント (SLA) の対象外であり、機能的に完全ではない場合があります。Red Hat は、実稼働環境でこれらを使用することを推奨していません。テクノロジープレビューの機能は、最新の製品機能をいち早く提供して、開発段階で機能のテストを行いフィードバックを提供していただくことを目的としています。

Red Hat のテクノロジープレビュー機能のサポート範囲に関する詳細は、テクノロジープレビュー機能のサポート範囲を参照してください。

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

重要

AWS Outposts にリモートワーカーを使用してラスターをインストールするには、すべてのワーカーインスタンスを同じ Outpost インスタンス内に配置する必要があり、AWS リージョンに配置することはできません。クラスターが AWS Outposts と AWS リージョンの両方にインスタンスを持つことはできません。さらに、コントロールプレーンノードはスケジュール対象にすることはできません。

4.15.1. 前提条件

OpenShift Container Platform のインストールおよび更新プロセスの詳細を確認した。
クラスターインストール方法の選択およびそのユーザー向けの準備を確認した。
クラスターをホストするために AWS アカウントを設定している。
使用する AWS Outpost インスタンスでサポートされているインスタンスタイプを理解している。これは get-outpost-instance-types AWS CLI コマンドで検証できます
OutpostArn や AvailabilityZone などの AWS Outpost インスタンスの詳細に精通している。これは list-outposts AWS CLI コマンドで検証できます
重要
クラスターは提供された AWS 認証情報を使用してライフサイクル全体で AWS リソースを作成するため、認証情報はキーベースで長期間有効である必要があります。そのため、コンピューターに AWS プロファイルが保存されている場合、多要素認証デバイスの使用中に生成された一時的なセッショントークンを使用してはなりません。適切なキーの生成の詳細については、AWS ドキュメントの IAM ユーザーのアクセスキーの管理を参照してください。インストールプログラムを実行するときにキーを指定できます。
Amazon Web Services (AWS) の既存の Amazon Virtual Private Cloud (VPC) にアクセスできます。詳細については、「カスタム VPC の使用について」のセクションを参照してください。
ファイアウォールが使用されている場合は、クラスターがアクセスを必要とするサイトを許可するように設定されました。

4.15.2. カスタム VPC の使用について

OpenShift Container Platform 4.14 インストーラーは、AWS Outposts に AWS サブネットを自動的にデプロイできないため、VPC を手動で設定する必要があります。したがって、Amazon Web Services (AWS) の既存の Amazon Virtual Private Cloud (VPC) 内の既存のサブネットに、クラスターをデプロイする必要があります。さらに、OpenShift Container Platform を既存の AWS VPC にデプロイすることで、新しいアカウントの制限の制約を回避したり、所属する企業のガイドラインが設定した運用上の制約をより簡単に順守したりできる場合があります。

インストールプログラムは既存のサブネットにある他のコンポーネントを把握できないため、ユーザーの代わりにサブネットの CIDR を選択することはできません。クラスターをインストールするサブネットのネットワークを独自に設定する必要があります。

4.15.2.1. VPC を使用するための要件

インストールプログラムは、以下のコンポーネントを作成しなくなりました。

インターネットゲートウェイ
NAT ゲートウェイ
サブネット
ルートテーブル
VPC
VPC DHCP オプション
VPC エンドポイント

注記

インストールプログラムでは、クラウド提供の DNS サーバーを使用する必要があります。カスタム DNS サーバーの使用はサポートされていないため、インストールが失敗します。

カスタム VPC を使用する場合は、そのカスタム VPC と使用するインストールプログラムおよびクラスターのサブネットを適切に設定する必要があります。AWS VPC の作成と管理の詳細は、AWS ドキュメントの Amazon VPC コンソールウィザードの設定と VPC とサブネットの操作を参照してください。

インストールプログラムには、以下の機能はありません。

使用するクラスターのネットワーク範囲を細分化する。
サブネットのルートテーブルを設定する。
DHCP などの VPC オプションを設定する。

クラスターをインストールする前に、以下のタスクを完了する必要があります。AWS VPC でのネットワーキングの設定の詳細は、VPC ネットワーキングコンポーネントと VPC のルートテーブルを参照してください。

VPC は以下の特性を満たす必要があります。

注記

AWS Outposts でリモートワーカーを使用して OpenShift Container Platform を作成できるようにするには、ワークロードインスタンスの作成用に AWS Outpost インスタンスに少なくとも 1 つのプライベートサブネットを作成し、コントロールプレーンインスタンスの作成用に AWS リージョンに 1 つのプライベートサブネットを作成する必要があります。リージョンに複数のプライベートサブネットを指定すると、コントロールプレーンインスタンスはこれらのサブネット全体に分散されます。また、プライベートサブネットに使用される各アベイラビリティーゾーン (Outpost プライベートサブネットを含む) にパブリックサブネットを作成する必要があります。これは、クラスターインストールの一部として API サーバーと Ingress ネットワーク用の AWS リージョンにネットワークロードバランサーが作成されるためです。Outpost プライベートサブネットと同じアベイラビリティーゾーンに AWS リージョンプライベートサブネットを作成することができます。

コントロールプレーンが使用するアベイラビリティーゾーンごとに、AWS リージョンにパブリックサブネットとプライベートサブネットを作成します。各アベイラビリティーゾーンには、AWS リージョン内に複数のパブリックサブネットと 1 つのプライベートサブネットを含めることはできません。このタイプの設定の例は、AWS ドキュメントのパブリックサブネットとプライベートサブネット (NAT) を使用した VPC を参照してください。
AWS Outposts にプライベートサブネットを作成するには、最初に Outpost インスタンスが目的のアベイラビリティーゾーンにあることを確認する必要があります。次に、Outpost ARN を追加することで、Outpost インスタンス内のそのアベイラビリティーゾーン内にプライベートサブネットを作成できます。同じアベイラビリティーゾーンで作成された AWS リージョンに別のパブリックサブネットがあることを確認してください。
各サブネット ID を記録します。インストールを完了するには、AWS リージョンで作成されたすべてのサブネット ID を install-config.yaml ファイルの platform セクションに入力し、Outpost で作成されたプライベートサブネット ID を使用するようにワーカー machineset を変更する必要があります。AWS ドキュメントのサブネット ID の検索を参照してください。
重要
AWS Outposts でパブリックサブネットを作成する必要がある場合は、このサブネットがネットワークロードバランサーまたは Classic LoadBalancer に使用されていないことを確認してください。そうしないと、LoadBalancer の作成は失敗します。これを実現するには、kubernetes.io/cluster/.*-outposts: owned 特殊タグをサブネットに含める必要があります。
VPC の CIDR ブロックには、クラスターマシンの IP アドレスプールである Networking.MachineCIDR 範囲が含まれている必要があります。サブネット CIDR ブロックは、指定したマシン CIDR に属している必要があります。
VPC には、パブリックインターネットゲートウェイが接続されている必要があります。アベイラビリティーゾーンごとに以下が必要です。
- パブリックサブネットには、インターネットゲートウェイへのルートが必要です。
- パブリックサブネットには、EIP アドレスが割り当てられた NAT ゲートウェイが必要です。
- プライベートサブネットには、パブリックサブネットの NAT ゲートウェイへのルートが必要です。
注記
ローカルネットワーク経由でローカルクラスターにアクセスするには、VPC を Outpost のローカルゲートウェイルートテーブルに関連付ける必要があります。詳細については、AWS Outposts ユーザーガイドの VPC associations を参照してください。
VPC は kubernetes.io/cluster/.*: owned、Name、openshift.io/cluster タグを使用できません。
インストールプログラムは kubernetes.io/cluster/.*: shared タグを追加するようにサブネットを変更するため、サブネットでは 1 つ以上の空のタグスロットが利用可能である必要があります。AWS ドキュメントでタグ制限を確認し、インストールプログラムでタグを指定する各サブネットに追加できるようにします。Name タグは EC2 Name フィールドと重複し、その結果インストールが失敗するため、使用できません。
VPC で enableDnsSupport および enableDnsHostnames 属性を有効にし、クラスターが VPC に割り当てられている Route 53 ゾーンを使用してクラスターの内部 DNS レコードを解決できるようにする必要があります。AWS ドキュメントの DNS Support in Your VPC を参照してください。
独自の Route 53 ホストプライベートゾーンを使用する場合、クラスターのインストール前に既存のホストゾーンを VPC に関連付ける必要があります。install-config.yaml ファイルの platform.aws.hostedZone フィールドと platform.aws.hostedZoneRole フィールドを使用して、ホストゾーンを定義できます。クラスターをインストールするアカウントとプライベートホストゾーンを共有することで、別のアカウントからプライベートホストゾーンを使用できます。別のアカウントからプライベートホストゾーンを使用する場合は、Passthrough または Manual 認証情報モードを使用する必要があります。

オプション 1: VPC エンドポイントを作成する

VPC エンドポイントを作成し、クラスターが使用しているサブネットにアタッチします。次のようにエンドポイントに名前を付けます。

ec2.<aws_region>.amazonaws.com
elasticloadbalancing.<aws_region>.amazonaws.com
s3.<aws_region>.amazonaws.com

このオプションを使用すると、VPC および必要な AWS サービスの間でネットワークトラフィックがプライベートのままになります。

オプション 2: VPC エンドポイントなしでプロキシーを作成する

インストールプロセスの一環として、HTTP または HTTPS プロキシーを設定できます。このオプションを使用すると、インターネットトラフィックはプロキシーを経由して、必要な AWS サービスに到達します。

オプション 3: VPC エンドポイントでプロキシーを作成する

インストールプロセスの一環として、VPC エンドポイントを使用して HTTP または HTTPS プロキシーを設定できます。VPC エンドポイントを作成し、クラスターが使用しているサブネットにアタッチします。次のようにエンドポイントに名前を付けます。

ec2.<aws_region>.amazonaws.com
elasticloadbalancing.<aws_region>.amazonaws.com
s3.<aws_region>.amazonaws.com

install-config.yaml ファイルでプロキシーを設定するときに、これらのエンドポイントを noProxy フィールドに追加します。このオプションを使用すると、プロキシーはクラスターがインターネットに直接アクセスするのを防ぎます。ただし、VPC と必要な AWS サービスの間のネットワークトラフィックはプライベートのままです。

必要な VPC コンポーネント

お使いのマシンとの通信を可能にする適切な VPC およびサブネットを指定する必要があります。

コンポーネント	AWS タイプ	説明
VPC	`AWS::EC2::VPC` `AWS::EC2::VPCEndpoint`	使用するクラスターのパブリック VPC を指定する必要があります。VPC は、各サブネットのルートテーブルを参照するエンドポイントを使用して、S3 でホストされているレジストリーとの通信を強化します。
パブリックサブネット	`AWS::EC2::Subnet` `AWS::EC2::SubnetNetworkAclAssociation`	VPC には 1 から 3 のアベイラビリティーゾーンのパブリックサブネットが必要であり、それらを適切な Ingress ルールに関連付ける必要があります。
インターネットゲートウェイ	`AWS::EC2::InternetGateway` `AWS::EC2::VPCGatewayAttachment` `AWS::EC2::RouteTable` `AWS::EC2::Route` `AWS::EC2::SubnetRouteTableAssociation` `AWS::EC2::NatGateway` `AWS::EC2::EIP`	VPC に割り当てられたパブリックルートを持つパブリックインターネットゲートウェイが必要です。提供されるテンプレートでは、各パブリックサブネットに EIP アドレスと NAT ゲートウェイがあります。これらの NAT ゲートウェイは、プライベートサブネットインスタンスなどのクラスターリソースがインターネットに到達できるようにするもので、一部のネットワークが制限された環境またはプロキシーのシナリオでは必要ありません。
ネットワークアクセス制御	`AWS::EC2::NetworkAcl` `AWS::EC2::NetworkAclEntry`	VPC が以下のポートにアクセスできるようにする必要があります。
		ポート	理由
		`80`	インバウンド HTTP トラフィック
		`443`	インバウンド HTTPS トラフィック
		`22`	インバウンド SSH トラフィック
		`1024` - `65535`	インバウンド一時 (ephemeral) トラフィック
		`0` - `65535`	アウトバウンド一時 (ephemeral) トラフィック
プライベートサブネット	`AWS::EC2::Subnet` `AWS::EC2::RouteTable` `AWS::EC2::SubnetRouteTableAssociation`	VPC にはプライベートサブネットを使用できます。提供される CloudFormation テンプレートは 1 から 3 アベイラビリティーゾーンのプライベートサブネットを作成できます。Outpost でリモートワーカーを実行できるようにするには、対応する AWS リージョン内にあるプライベートサブネットに加えて、VPC に Outpost インスタンス内にあるプライベートサブネットを含める必要があります。プライベートサブネットを使用できる場合は、それらの適切なルートおよびテーブルを指定する必要があります。

4.15.2.2. VPC 検証

指定するサブネットが適切であることを確認するには、インストールプログラムが以下のデータを確認します。

指定したサブネットすべてが存在します。
プライベートサブネットを指定します。
サブネットの CIDR は指定されたマシン CIDR に属します。
各アベイラビリティーゾーンのサブネットを指定します。各アベイラビリティーゾーンには、AWS リージョン内に 1 つのパブリックサブネットと 1 つのプライベートサブネットが含まれます (Outpost インスタンスでは作成されません)。Outpost インスタンスがインストールされているアベイラビリティーゾーンには、Outpost インスタンスに 1 つの追加のプライベートサブネットが含まれている必要があります。
各プライベートサブネットアベイラビリティーゾーンのパブリックサブネットを指定します。マシンは、プライベートサブネットを指定しないアベイラビリティーゾーンにはプロビジョニングされません。

既存の VPC を使用するクラスターを破棄しても、VPC は削除されません。VPC から OpenShift Container Platform クラスターを削除する場合、kubernetes.io/cluster/.*: shared タグは、それが使用したサブネットから削除されます。

4.15.2.3. パーミッションの区分

OpenShift Container Platform 4.3 以降、クラスターのデプロイに、インストールプログラムがプロビジョニングするインフラストラクチャークラスターに必要なすべてのパーミッションを必要としなくなりました。この変更は、ある会社で個人がクラウドで他とは異なるリソースを作成できるようにパーミッションが区分された状態に類似するものです。たとえば、インスタンス、バケット、ロードバランサーなどのアプリケーション固有のアイテムを作成することはできますが、VPC、サブネット、または Ingress ルールなどのネットワーク関連のコンポーネントは作成できない可能性があります。

クラスターの作成時に使用する AWS の認証情報には、VPC、およびサブネット、ルーティングテーブル、インターネットゲートウェイ、NAT、VPN などの VPC 内のコアとなるネットワークコンポーネントの作成に必要なネットワークのパーミッションは必要ありません。ELB、セキュリティーグループ、S3 バケットおよびノードなどの、クラスター内でマシンに必要なアプリケーションリソースを作成するパーミッションは依然として必要になります。

4.15.2.4. クラスター間の分離

OpenShift Container Platform を既存のネットワークにデプロイする場合、クラスターサービスの分離の規模は以下の方法で縮小されます。

複数の OpenShift Container Platform クラスターを同じ VPC にインストールできます。
ICMP Ingress はネットワーク全体から許可されます。
TCP 22 Ingress (SSH) はネットワーク全体に対して許可されます。
コントロールプレーンの TCP 6443 Ingress (Kubernetes API) はネットワーク全体に対して許可されます。
コントロールプレーンの TCP 22623 Ingress (MCS) はネットワーク全体に対して許可されます。

4.15.2.5. AWS セキュリティーグループ

デフォルトでは、インストールプログラムは、セキュリティーグループを作成し、コントロールプレーンとコンピュートマシンに接続します。デフォルトのセキュリティーグループに関連付けられたルールは変更できません。

ただし、既存の VPC に関連付けられている追加の既存の AWS セキュリティーグループをコントロールプレーンとコンピュートマシンに適用できます。カスタムセキュリティーグループを適用すると、これらのマシンの受信トラフィックまたは送信トラフィックを制御する必要がある場合に、組織のセキュリティーニーズを満たすことができます。

インストールプロセスの一環として、クラスターをデプロイする前に install-config.yaml ファイルを変更してカスタムセキュリティーグループを適用します。

詳細は、「既存の AWS セキュリティーグループのクラスターへの適用」を参照してください。

4.15.3. OpenShift Container Platform のインターネットアクセス

OpenShift Container Platform 4.14 では、クラスターをインストールするためにインターネットアクセスが必要になります。

インターネットへのアクセスは以下を実行するために必要です。

OpenShift Cluster Manager にアクセスし、インストールプログラムをダウンロードし、サブスクリプション管理を実行します。クラスターにインターネットアクセスがあり、Telemetry を無効にしない場合、そのサービスは有効なサブスクリプションでクラスターを自動的に使用します。
クラスターのインストールに必要なパッケージを取得するために Quay.io にアクセスします。
クラスターの更新を実行するために必要なパッケージを取得します。

重要

クラスターでインターネットに直接アクセスできない場合、プロビジョニングする一部のタイプのインフラストラクチャーでネットワークが制限されたインストールを実行できます。このプロセスで、必要なコンテンツをダウンロードし、これを使用してミラーレジストリーにインストールパッケージを設定します。インストールタイプによっては、クラスターのインストール環境でインターネットアクセスが不要となる場合があります。クラスターを更新する前に、ミラーレジストリーのコンテンツを更新します。

4.15.4. クラスターノードの SSH アクセス用のキーペアの生成

OpenShift Container Platform をインストールする際に、SSH パブリックキーをインストールプログラムに指定できます。キーは、Ignition 設定ファイルを介して Red Hat Enterprise Linux CoreOS (RHCOS) ノードに渡され、ノードへの SSH アクセスを認証するために使用されます。このキーは各ノードの core ユーザーの ~/.ssh/authorized_keys リストに追加され、パスワードなしの認証が可能になります。

キーがノードに渡されると、キーペアを使用して RHCOS ノードにユーザー core として SSH を実行できます。SSH 経由でノードにアクセスするには、秘密鍵のアイデンティティーをローカルユーザーの SSH で管理する必要があります。

インストールのデバッグまたは障害復旧を実行するためにクラスターノードに対して SSH を実行する場合は、インストールプロセスの間に SSH 公開鍵を指定する必要があります。./openshift-install gather コマンドでは、SSH 公開鍵がクラスターノードに配置されている必要もあります。

重要

障害復旧およびデバッグが必要な実稼働環境では、この手順を省略しないでください。

注記

AWS キーペアなどのプラットフォームに固有の方法で設定したキーではなく、ローカルキーを使用する必要があります。

手順

クラスターノードへの認証に使用するローカルマシンに既存の SSH キーペアがない場合は、これを作成します。たとえば、Linux オペレーティングシステムを使用するコンピューターで以下のコマンドを実行します。
```
$ ssh-keygen -t ed25519 -N '' -f <path>/<file_name> 1
```
1
新しい SSH キーのパスとファイル名 (~/.ssh/id_ed25519 など) を指定します。既存のキーペアがある場合は、公開鍵が ~/.ssh ディレクトリーにあることを確認します。
注記
x86_64、ppc64le、および s390x アーキテクチャーのみで FIPS 140-2/140-3 検証のために NIST に提出された RHEL 暗号化ライブラリーを使用する OpenShift Container Platform クラスターをインストールする予定がある場合は、ed25519 アルゴリズムを使用するキーを作成しないでください。代わりに、rsa アルゴリズムまたは ecdsa アルゴリズムを使用するキーを作成します。
公開 SSH キーを表示します。
```
$ cat <path>/<file_name>.pub
```
たとえば、次のコマンドを実行して ~/.ssh/id_ed25519.pub 公開鍵を表示します。
```
$ cat ~/.ssh/id_ed25519.pub
```
ローカルユーザーの SSH エージェントに SSH 秘密鍵 ID が追加されていない場合は、それを追加します。キーの SSH エージェント管理は、クラスターノードへのパスワードなしの SSH 認証、または ./openshift-install gather コマンドを使用する場合は必要になります。
注記
一部のディストリビューションでは、~/.ssh/id_rsa および ~/.ssh/id_dsa などのデフォルトの SSH 秘密鍵のアイデンティティーは自動的に管理されます。
1. ssh-agent プロセスがローカルユーザーに対して実行されていない場合は、バックグラウンドタスクとして開始します。
```
$ eval "$(ssh-agent -s)"
```
  出力例
```
Agent pid 31874
```
  注記
  クラスターが FIPS モードにある場合は、FIPS 準拠のアルゴリズムのみを使用して SSH キーを生成します。鍵は RSA または ECDSA のいずれかである必要があります。
SSH プライベートキーを ssh-agent に追加します。
```
$ ssh-add <path>/<file_name> 1
```
1
~/.ssh/id_ed25519 などの、SSH プライベートキーのパスおよびファイル名を指定します。
出力例
```
Identity added: /home/<you>/<path>/<file_name> (<computer_name>)
```

次のステップ

OpenShift Container Platform をインストールする際に、SSH パブリックキーをインストールプログラムに指定します。

4.15.5. インストールプログラムの取得

OpenShift Container Platform をインストールする前に、インストールに使用しているホストにインストールファイルをダウンロードします。

前提条件

500 MB のローカルディスク領域がある Linux または macOS を実行するコンピューターが必要です。

手順

OpenShift Cluster Manager サイトのインフラストラクチャープロバイダーページにアクセスします。Red Hat アカウントがある場合は、認証情報を使用してログインします。アカウントがない場合はこれを作成します。
インフラストラクチャープロバイダーを選択します。
インストールタイプのページに移動し、ホストオペレーティングシステムとアーキテクチャーに対応するインストールプログラムをダウンロードして、インストール設定ファイルを保存するディレクトリーにファイルを配置します。
重要
インストールプログラムは、クラスターのインストールに使用するコンピューターにいくつかのファイルを作成します。クラスターのインストール完了後は、インストールプログラムおよびインストールプログラムが作成するファイルを保持する必要があります。ファイルはいずれもクラスターを削除するために必要になります。
重要
インストールプログラムで作成されたファイルを削除しても、クラスターがインストール時に失敗した場合でもクラスターは削除されません。クラスターを削除するには、特定のクラウドプロバイダー用の OpenShift Container Platform のアンインストール手順を実行します。
インストールプログラムを展開します。たとえば、Linux オペレーティングシステムを使用するコンピューターで以下のコマンドを実行します。
```
$ tar -xvf openshift-install-linux.tar.gz
```
Red Hat OpenShift Cluster Manager からインストールプルシークレットをダウンロードします。このプルシークレットを使用し、OpenShift Container Platform コンポーネントのコンテナーイメージを提供する Quay.io など、組み込まれた各種の認証局によって提供されるサービスで認証できます。

4.15.6. クラスターインストールの最小リソース要件

それぞれのクラスターマシンは、以下の最小要件を満たしている必要があります。

表4.24 最小リソース要件
マシン	オペレーティングシステム	vCPU ^[1]	仮想 RAM	ストレージ	1 秒あたりの入出力 (IOPS) ^[2]
ブートストラップ	RHCOS	4	16 GB	100 GB	300
コントロールプレーン	RHCOS	4	16 GB	100 GB	300
Compute	RHCOS、RHEL 8.6 以降 ^[3]	2	8 GB	100 GB	300

1 vCPU は、同時マルチスレッド (SMT) またはハイパースレッディングが有効にされていない場合に 1 つの物理コアと同等です。これが有効にされている場合、数式「(コアごとのスレッド × コア数) × ソケット数 = 仮想 CPU」を使用して対応する比率を計算します。
OpenShift Container Platform および Kubernetes はディスクのパフォーマンスに敏感であり、特に 10 ms p99 fsync 期間を必要とするコントロールプレーンノード上の etcd については、高速ストレージが推奨されます。多くのクラウドプラットフォームでは、ストレージサイズと IOPS スケールが一緒にあるため、十分なパフォーマンスを得るためにストレージボリュームの割り当てが必要になる場合があります。
すべての user-provisioned installation と同様に、クラスターで RHEL コンピュートマシンの使用を選択する場合は、システム更新の実行、パッチの適用、その他すべての必要なタスクの完了など、オペレーティングシステムのライフサイクルの管理と保守をすべて担当します。RHEL 7 コンピューティングマシンの使用は推奨されておらず、OpenShift Container Platform 4.10 以降では削除されています。

注記

OpenShift Container Platform バージョン 4.13 の時点で、RHCOS は RHEL バージョン 9.2 に基づいており、マイクロアーキテクチャーの要件を更新します。次のリストには、各アーキテクチャーに必要な最小限の命令セットアーキテクチャー (ISA) が含まれています。

x86-64 アーキテクチャーには x86-64-v2 ISA が必要
ARM64 アーキテクチャーには ARMv8.0-A ISA が必要
IBM Power アーキテクチャーには Power 9 ISA が必要
s390x アーキテクチャーには z14 ISA が必要

詳細は、RHEL アーキテクチャーを参照してください。

プラットフォームのインスタンスタイプがクラスターマシンの最小要件を満たす場合、これは OpenShift Container Platform で使用することがサポートされます。

関連情報

ストレージの最適化

4.15.7. AWS Outposts インスタンスタイプの特定

AWS Outposts ラックのカタログには、ローカルインスタンスストレージの有無にかかわらず、最新世代の Intel 搭載 EC2 インスタンスタイプをサポートするオプションが含まれています。AWS Outpost インスタンスで設定されているインスタンスタイプを特定します。インストールプロセスの一環として、インストールプログラムがワーカーノードのデプロイに使用するインスタンスタイプで install-config.yaml ファイルを更新する必要があります。

手順

AWS CLI を使用して、次のコマンドを実行して、サポートされているインスタンスタイプのリストを取得します。

$ aws outposts get-outpost-instance-types --outpost-id <outpost_id> 1

1: <outpost_id> の場合、ワーカーインスタンスの AWS アカウントで使用される Outpost ID を指定します。
重要
AWS Outpost インスタンスの容量を購入するときは、各サーバーが提供する EC2 容量レイアウトを指定します。各サーバーは、インスタンスタイプの 1 つのファミリーをサポートします。レイアウトは、単一のインスタンスタイプまたは複数のインスタンスタイプを提供できます。Dedicated Hosts を使用すると、その初期レイアウトに選択したものを変更できます。容量全体に対して単一のインスタンスタイプをサポートするようにホストを割り当てた場合、そのホストからは単一のインスタンスタイプしか起動できません。

AWS Outposts でサポートされているインスタンスタイプは変更される可能性があります。詳細については、AWS Outposts ドキュメントのコンピュートとストレージのページを確認してください。

4.15.8. インストール設定ファイルの作成

Amazon Web Services (AWS) での OpenShift Container Platform のインストールをカスタマイズできます。

前提条件

OpenShift Container Platform インストールプログラムおよびクラスターのプルシークレットがある。

手順

install-config.yaml ファイルを作成します。
1. インストールプログラムが含まれるディレクトリーに切り替え、以下のコマンドを実行します。
```
$ ./openshift-install create install-config --dir <installation_directory> 1
```
  1
  <installation_directory> の場合、インストールプログラムが作成するファイルを保存するためにディレクトリー名を指定します。
  ディレクトリーを指定する場合:
  - ディレクトリーに execute 権限があることを確認します。この権限は、インストールディレクトリーで Terraform バイナリーを実行するために必要です。
  - 空のディレクトリーを使用します。ブートストラップ X.509 証明書などの一部のインストールアセットは有効期限が短いため、インストールディレクトリーを再利用しないでください。別のクラスターインストールの個別のファイルを再利用する必要がある場合は、それらをディレクトリーにコピーすることができます。ただし、インストールアセットのファイル名はリリース間で変更される可能性があります。インストールファイルを以前のバージョンの OpenShift Container Platform からコピーする場合は注意してコピーを行ってください。
    注記
    古い設定の再利用を回避するために、~/.powervs ディレクトリーは必ず削除してください。以下のコマンドを実行します。
    $ rm -rf ~/.powervs
2. プロンプト時に、クラウドの設定の詳細情報を指定します。
  1. オプション: クラスターマシンにアクセスするために使用する SSH キーを選択します。
    注記
    インストールのデバッグまたは障害復旧を実行する必要のある実稼働用の OpenShift Container Platform クラスターでは、ssh-agent プロセスが使用する SSH キーを指定します。
  2. ターゲットに設定するプラットフォームとして AWS を選択します。
  3. Amazon Web Services (AWS) プロファイルをコンピューターに保存していない場合、インストールプログラムを実行するように設定したユーザーの AWS アクセスキー ID およびシークレットアクセスキーを入力します。
  4. クラスターのデプロイ先とする AWS リージョンを選択します。
  5. クラスターに設定した Route 53 サービスのベースドメインを選択します。
  6. クラスターの記述名を入力します。
install-config.yaml ファイルを変更します。AWS Outposts のインストールには次の制限があり、install-config.yaml ファイルを手動で変更する必要があります。
- ほぼ無限のスケールを提供する AWS リージョンとは異なり、AWS Outposts は、他のワークロードによってまだ消費されていないプロビジョニングされた容量、EC2 ファミリーと世代、設定されたインスタンスサイズ、およびコンピュート容量の可用性によって制限されます。したがって、新しい OpenShift Container Platform クラスターを作成する場合、設定ファイルの compute.platform.aws.type セクションでサポートされているインスタンスタイプを指定する必要があります。
- AWS Outposts で実行されているリモートワーカーを使用して OpenShift Container Platform クラスターをデプロイする場合、コンピュートインスタンスに使用できるアベイラビリティーゾーンは 1 つ (Outpost インスタンスが作成されたアベイラビリティーゾーン) だけです。したがって、新しい OpenShift Container Platform クラスターを作成する場合、コンピュートインスタンスをこのアベイラビリティーゾーンに制限するために、設定ファイルの compute.platform.aws.zones セクションに関連するアベイラビリティーゾーンを指定することが推奨されます。
- Amazon Elastic Block Store (EBS) gp3 ボリュームは、AWS Outposts サービスではサポートされていません。このボリュームタイプは、OpenShift Container Platform クラスターで使用されるデフォルトのタイプです。したがって、新しい OpenShift Container Platform クラスターを作成するときは、compute.platform.aws.rootVolume.type セクションのボリュームタイプを gp2 に変更する必要があります。これらの値の変更方法については、以下を参照してください。
install-config.yaml ファイルをバックアップし、複数のクラスターをインストールするのに使用できるようにします。
重要
install-config.yaml ファイルはインストールプロセス時に使用されます。このファイルを再利用する必要がある場合は、この段階でこれをバックアップしてください。

関連情報

AWS のインストール設定パラメーター

4.15.8.1. AWS のカスタマイズされた install-config.yaml ファイルのサンプル

インストール設定ファイル install-config.yaml をカスタマイズして、OpenShift Container Platform クラスターのプラットフォームに関する詳細を指定するか、必要なパラメーターの値を変更することができます。

重要

このサンプルの YAML ファイルは参照用にのみ提供されます。インストールプログラムを使用して install-config.yaml ファイルを取得し、これを変更する必要があります。

apiVersion: v1
baseDomain: example.com 1
credentialsMode: Mint 2
controlPlane: 3 4
  hyperthreading: Enabled 5
  name: master
  platform: {}
  replicas: 3
compute: 6
- hyperthreading: Enabled 7
  name: worker
  platform:
    aws:
      type: m5.large 8
      zones:
        - us-east-1a 9
      rootVolume:
        type: gp2 10
        size: 120
  replicas: 3
metadata:
  name: test-cluster 11
networking:
  clusterNetwork:
  - cidr: 10.128.0.0/14
    hostPrefix: 23
  machineNetwork:
  - cidr: 10.0.0.0/16
  networkType: OVNKubernetes 12
  serviceNetwork:
  - 172.30.0.0/16
platform:
  aws:
    region: us-west-2 13
    propagateUserTags: true 14
    userTags:
      adminContact: jdoe
      costCenter: 7536
  subnets: 15
  - subnet-1
  - subnet-2
  - subnet-3
sshKey: ssh-ed25519 AAAA... 16
pullSecret: '{"auths": ...}' 17

1 11 13 17: 必須。インストールプログラムはこの値の入力を求めるプロンプトを出します。
2: オプション: Cloud Credential Operator (CCO) に指定されたモードの使用を強制するには、このパラメーターを追加します。デフォルトでは、CCO は kube-system namespace のルート認証情報を使用して、認証情報の機能を動的に判断しようとします。CCO モードの詳細は、認証および認可 ガイドの「Cloud Credential Operator について」セクションを参照してください。
3 6 14: これらのパラメーターおよび値を指定しない場合、インストールプログラムはデフォルトの値を指定します。
4: controlPlane セクションは単一マッピングですが、compute セクションはマッピングのシーケンスになります。複数の異なるデータ構造の要件を満たすには、compute セクションの最初の行はハイフン - で始め、controlPlane セクションの最初の行はハイフンで始めることができません。1 つのコントロールプレーンプールのみが使用されます。
5 7: 同時マルチスレッドまたは hyperthreading を有効/無効にするかどうか。デフォルトでは、同時スレッドはマシンのコアのパフォーマンスを上げるために有効にされます。パラメーター値を Disabled に設定するとこれを無効にすることができます。一部のクラスターマシンで同時マルチスレッドを無効にする場合は、これをすべてのクラスターマシンで無効にする必要があります。
重要
同時スレッドを無効にする場合は、容量計画においてマシンパフォーマンスの大幅な低下が考慮に入れられていることを確認します。同時マルチスレッドを無効にする場合は、マシンに対して m4.2xlarge または m5.2xlarge などの大規模なインスタンスタイプを使用します。
8: AWS Outpost インスタンスで実行されているコンピュートインスタンスの場合、AWS Outpost インスタンスでサポートされているインスタンスタイプを指定します。
9: AWS Outpost インスタンスで実行されているコンピュートインスタンスの場合、Outpost インスタンスが配置されているアベイラビリティーゾーンを指定します。
10: AWS Outpost インスタンスで実行されているコンピュートインスタンスの場合、サポートされていない gp3 ボリュームタイプの使用を避けるために、ボリュームタイプ gp2 を指定します。
12: インストールするクラスターネットワークプラグイン。サポートされている値は OVNKubernetes と OpenShiftSDN です。デフォルトの値は OVNkubernetes です。
15: 独自の VPC を指定する場合は、クラスターが使用する各アベイラビリティーゾーンのサブネットを指定します。
16: クラスター内のマシンにアクセスするために使用する sshKey 値をオプションで指定できます。
注記
インストールのデバッグまたは障害復旧を実行する必要のある実稼働用の OpenShift Container Platform クラスターでは、ssh-agent プロセスが使用する SSH キーを指定します。

4.15.8.2. 既存の AWS セキュリティーグループをクラスターに適用する

既存の AWS セキュリティーグループをコントロールプレーンとコンピュートマシンに適用すると、これらのマシンの受信トラフィックまたは送信トラフィックを制御する必要がある場合に、組織のセキュリティーニーズを満たすことができます。

前提条件

AWS でセキュリティーグループを作成している。詳細は、セキュリティーグループの操作に関する AWS ドキュメントを参照してください。
セキュリティーグループは、クラスターをデプロイする既存の VPC に関連付ける必要があります。セキュリティーグループを別の VPC に関連付けることはできません。
既存の install-config.yaml ファイルがある。

手順

install-config.yaml ファイルで、compute.platform.aws.additionalSecurityGroupIDs パラメーターを編集して、コンピュートマシンに 1 つ以上のカスタムセキュリティーグループを指定します。
controlPlane.platform.aws.additionalSecurityGroupIDs パラメーターを編集して、コントロールプレーンマシンに 1 つ以上のカスタムセキュリティーグループを指定します。
ファイルを保存し、クラスターをデプロイする際に参照します。

カスタムセキュリティーグループを指定するサンプル install-config.yaml ファイル

# ...
compute:
- hyperthreading: Enabled
  name: worker
  platform:
    aws:
      additionalSecurityGroupIDs:
        - sg-1 1
        - sg-2
  replicas: 3
controlPlane:
  hyperthreading: Enabled
  name: master
  platform:
    aws:
      additionalSecurityGroupIDs:
        - sg-3
        - sg-4
  replicas: 3
platform:
  aws:
    region: us-east-1
    subnets: 2
      - subnet-1
      - subnet-2
      - subnet-3

1: Amazon EC2 コンソールに表示されるセキュリティーグループの名前を、sg 接頭辞を含めて指定します。
2: クラスターが使用する各アベイラビリティーゾーンのサブネットを指定します。

4.15.9. マニフェストファイルの生成

インストールプログラムを使用して、アセットディレクトリーにマニフェストファイルのセットを生成します。マニフェストファイルは、ワーカーマシンに使用する AWS Outposts サブネットを指定し、ネットワークプロバイダーが必要とする設定を指定するために必要です。

install-config.yaml ファイルを再利用する予定の場合は、マニフェストファイルを生成する前にバックアップファイルを作成します。

手順

オプション: install-config.yaml ファイルのバックアップコピーを作成します。
```
$ cp install-config.yaml install-config.yaml.backup
```

アセットディレクトリーにマニフェストのセットを生成します。

$ openshift-install create manifests --dir <installation_-_directory>

このコマンドにより、以下の情報が表示されます。

出力例

INFO Consuming Install Config from target directory
INFO Manifests created in: <installation_directory>/manifests and <installation_directory>/openshift

このコマンドにより、以下のマニフェストファイルが生成されます。

出力例

$ tree
.
├── manifests
│   ├── cluster-config.yaml
│   ├── cluster-dns-02-config.yml
│   ├── cluster-infrastructure-02-config.yml
│   ├── cluster-ingress-02-config.yml
│   ├── cluster-network-01-crd.yml
│   ├── cluster-network-02-config.yml
│   ├── cluster-proxy-01-config.yaml
│   ├── cluster-scheduler-02-config.yml
│   ├── cvo-overrides.yaml
│   ├── kube-cloud-config.yaml
│   ├── kube-system-configmap-root-ca.yaml
│   ├── machine-config-server-tls-secret.yaml
│   └── openshift-config-secret-pull-secret.yaml
└── openshift
    ├── 99_cloud-creds-secret.yaml
    ├── 99_kubeadmin-password-secret.yaml
    ├── 99_openshift-cluster-api_master-machines-0.yaml
    ├── 99_openshift-cluster-api_master-machines-1.yaml
    ├── 99_openshift-cluster-api_master-machines-2.yaml
    ├── 99_openshift-cluster-api_master-user-data-secret.yaml
    ├── 99_openshift-cluster-api_worker-machineset-0.yaml
    ├── 99_openshift-cluster-api_worker-user-data-secret.yaml
    ├── 99_openshift-machineconfig_99-master-ssh.yaml
    ├── 99_openshift-machineconfig_99-worker-ssh.yaml
    ├── 99_role-cloud-creds-secret-reader.yaml
    └── openshift-install-manifests.yaml

4.15.9.1. マニフェストファイルの変更

注記

AWS Outposts 環境には、マニフェスト生成ファイルの手動変更が必要な以下の制限があります。

ネットワーク接続の最大伝送単位 (MTU) は、接続を介して渡すことができる最大許容パケットのサイズ (バイト単位) です。Outpost サービスリンクは、最大 1300 バイトのパケットサイズをサポートします。サービスリンクの詳細については、AWS リージョンへの Outpost 接続を参照してください。

これらの値の変更方法については、以下を参照してください。

ワーカーの machineset に Outpost Subnet を使用する
<installation_directory>/openshift/99_openshift-cluster-api_worker-machineset-0.yaml ファイルを変更します。サブネット ID を見つけて、Outpost で作成されたプライベートサブネットの ID に置き換えます。その結果、すべてのワーカーマシンが Outpost に作成されます。
ネットワークプロバイダーの MTU 値を指定する
Outpost サービスリンクは、最大 1300 バイトのパケットサイズをサポートします。この要件に従うには、ネットワークプロバイダーの MTU を変更する必要があります。マニフェストディレクトリーの下に、cluster-network-03-config.yml という名前の新しいファイルを作成します。
OpenShift SDN ネットワークプロバイダーを使用する場合は、MTU 値を 1250 に設定します。
```
apiVersion: operator.openshift.io/v1
kind: Network
metadata:
  name: cluster
spec:
  defaultNetwork:
    openshiftSDNConfig:
      mtu: 1250
```
OVN-Kubernetes ネットワークプロバイダーが使用される場合は、MTU の値を 1200 に設定します。
```
apiVersion: operator.openshift.io/v1
kind: Network
metadata:
  name: cluster
spec:
  defaultNetwork:
    ovnKubernetesConfig:
      mtu: 1200
```

4.15.10. バイナリーのダウンロードによる OpenShift CLI のインストール

コマンドラインインターフェイスを使用して OpenShift Container Platform と対話するために CLI (oc) をインストールすることができます。oc は Linux、Windows、または macOS にインストールできます。

重要

以前のバージョンの oc をインストールしている場合、これを使用して OpenShift Container Platform 4.14 のすべてのコマンドを実行することはできません。新規バージョンの oc をダウンロードし、インストールします。

Linux への OpenShift CLI のインストール

以下の手順を使用して、OpenShift CLI (oc) バイナリーを Linux にインストールできます。

手順

Red Hat カスタマーポータルの OpenShift Container Platform ダウンロードページに移動します。
Product Variant ドロップダウンリストからアーキテクチャーを選択します。
バージョン ドロップダウンリストから適切なバージョンを選択します。
OpenShift v4.14 Linux Client エントリーの横にある Download Now をクリックして、ファイルを保存します。
アーカイブを展開します。
```
$ tar xvf <file>
```
oc バイナリーを、PATH にあるディレクトリーに配置します。
PATH を確認するには、以下のコマンドを実行します。
```
$ echo $PATH
```

検証

OpenShift CLI のインストール後に、oc コマンドを使用して利用できます。
```
$ oc <command>
```

Windows への OpenShift CLI のインストール

以下の手順を使用して、OpenShift CLI (oc) バイナリーを Windows にインストールできます。

手順

Red Hat カスタマーポータルの OpenShift Container Platform ダウンロードページに移動します。
バージョン ドロップダウンリストから適切なバージョンを選択します。
OpenShift v4.14 Windows Client エントリーの横にある Download Now をクリックして、ファイルを保存します。
ZIP プログラムでアーカイブを展開します。
oc バイナリーを、PATH にあるディレクトリーに移動します。
PATH を確認するには、コマンドプロンプトを開いて以下のコマンドを実行します。
```
C:\> path
```

検証

OpenShift CLI のインストール後に、oc コマンドを使用して利用できます。
```
C:\> oc <command>
```

macOS への OpenShift CLI のインストール

以下の手順を使用して、OpenShift CLI (oc) バイナリーを macOS にインストールできます。

手順

Red Hat カスタマーポータルの OpenShift Container Platform ダウンロードページに移動します。
バージョン ドロップダウンリストから適切なバージョンを選択します。
OpenShift v4.14 macOS Client エントリーの横にある Download Now をクリックして、ファイルを保存します。
注記
macOS arm64 の場合は、OpenShift v4.14 macOS arm64 Client エントリーを選択します。
アーカイブを展開し、解凍します。
oc バイナリーをパスにあるディレクトリーに移動します。
PATH を確認するには、ターミナルを開き、以下のコマンドを実行します。
```
$ echo $PATH
```

検証

oc コマンドを使用してインストールを確認します。
```
$ oc <command>
```

4.15.11. 管理者レベルのシークレットを kube-system プロジェクトに保存する代替方法

デフォルトでは、管理者のシークレットは kube-system プロジェクトに保存されます。install-config.yaml ファイルの credentialsMode パラメーターを Manual に設定した場合は、次のいずれかの代替手段を使用する必要があります。

長期クラウド認証情報を手動で管理するには、長期認証情報を手動で作成するの手順に従ってください。
クラスターの外部で管理される短期認証情報を個々のコンポーネントに対して実装するには、短期認証情報を使用するように AWS クラスターを設定するの手順に従ってください。

4.15.11.1. 長期認証情報を手動で作成する

Cloud Credential Operator (CCO) は、クラウドアイデンティティーおよびアクセス管理 (IAM) API に到達できない環境にインストールする前に手動モードに配置できます。管理者はクラスター kube-system namespace に管理者レベルの認証情報シークレットを保存しないようにします。

手順

install-config.yaml 設定ファイルの credentialsMode パラメーターを Manual に設定しなかった場合は、次のように値を変更します。
設定ファイルのサンプルスニペット
```
apiVersion: v1
baseDomain: example.com
credentialsMode: Manual
# ...
```
インストールマニフェストファイルをまだ作成していない場合は、次のコマンドを実行して作成します。
```
$ openshift-install create manifests --dir <installation_directory>
```
ここで、<installation_directory> は、インストールプログラムがファイルを作成するディレクトリーに置き換えます。
次のコマンドを実行して、インストールファイルのリリースイメージを $RELEASE_IMAGE 変数に設定します。
```
$ RELEASE_IMAGE=$(./openshift-install version | awk '/release image/ {print $3}')
```
以下のコマンドを実行して、OpenShift Container Platform リリースイメージから CredentialsRequest カスタムリソース (CR) のリストを抽出します。
```
$ oc adm release extract \
  --from=$RELEASE_IMAGE \
  --credentials-requests \
  --included \1
  --install-config=<path_to_directory_with_installation_configuration>/install-config.yaml \2
  --to=<path_to_directory_for_credentials_requests> 3
```
1
--included パラメーターには、特定のクラスター設定に必要なマニフェストのみが含まれます。
2
install-config.yaml ファイルの場所を指定します。
3
CredentialsRequest オブジェクトを保存するディレクトリーへのパスを指定します。指定したディレクトリーが存在しない場合は、このコマンドによって作成されます。
このコマンドにより、それぞれの CredentialsRequest オブジェクトに YAML ファイルが作成されます。
サンプル CredentialsRequest オブジェクト
```
apiVersion: cloudcredential.openshift.io/v1
kind: CredentialsRequest
metadata:
  name: <component_credentials_request>
  namespace: openshift-cloud-credential-operator
  ...
spec:
  providerSpec:
    apiVersion: cloudcredential.openshift.io/v1
    kind: AWSProviderSpec
    statementEntries:
    - effect: Allow
      action:
      - iam:GetUser
      - iam:GetUserPolicy
      - iam:ListAccessKeys
      resource: "*"
  ...
```

以前に生成した openshift-install マニフェストディレクトリーにシークレットの YAML ファイルを作成します。シークレットは、それぞれの CredentialsRequest オブジェクトについて spec.secretRef に定義される namespace およびシークレット名を使用して保存する必要があります。

シークレットを含む CredentialsRequest オブジェクトのサンプル

apiVersion: cloudcredential.openshift.io/v1
kind: CredentialsRequest
metadata:
  name: <component_credentials_request>
  namespace: openshift-cloud-credential-operator
  ...
spec:
  providerSpec:
    apiVersion: cloudcredential.openshift.io/v1
    kind: AWSProviderSpec
    statementEntries:
    - effect: Allow
      action:
      - s3:CreateBucket
      - s3:DeleteBucket
      resource: "*"
      ...
  secretRef:
    name: <component_secret>
    namespace: <component_namespace>
  ...

サンプル Secret オブジェクト

apiVersion: v1
kind: Secret
metadata:
  name: <component_secret>
  namespace: <component_namespace>
data:
  aws_access_key_id: <base64_encoded_aws_access_key_id>
  aws_secret_access_key: <base64_encoded_aws_secret_access_key>

重要

手動でメンテナンスされる認証情報を使用するクラスターをアップグレードする前に、CCO がアップグレード可能な状態であることを確認します。

4.15.11.2. 短期認証情報を使用するように AWS クラスターを設定

AWS Security Token Service (STS) を使用するように設定されたクラスターをインストールするには、CCO ユーティリティーを設定し、クラスターに必要な AWS リソースを作成する必要があります。

4.15.11.2.1. Cloud Credential Operator ユーティリティーの設定

Cloud Credential Operator (CCO) が手動モードで動作しているときにクラスターの外部からクラウドクレデンシャルを作成および管理するには、CCO ユーティリティー (ccoctl) バイナリーを抽出して準備します。

注記

ccoctl ユーティリティーは、Linux 環境で実行する必要がある Linux バイナリーです。

前提条件

クラスター管理者のアクセスを持つ OpenShift Container Platform アカウントを使用できる。
OpenShift CLI (oc) がインストールされている。

ccoctl ユーティリティー用の AWS アカウントを作成し、次の権限で使用できるようにしました。
例4.94 必要な AWS パーミッション
必要な iam 権限
- iam:CreateOpenIDConnectProvider
- iam:CreateRole
- iam:DeleteOpenIDConnectProvider
- iam:DeleteRole
- iam:DeleteRolePolicy
- iam:GetOpenIDConnectProvider
- iam:GetRole
- iam:GetUser
- iam:ListOpenIDConnectProviders
- iam:ListRolePolicies
- iam:ListRoles
- iam:PutRolePolicy
- iam:TagOpenIDConnectProvider
- iam:TagRole
必要な s3 権限
- s3:CreateBucket
- s3:DeleteBucket
- s3:DeleteObject
- s3:GetBucketAcl
- s3:GetBucketTagging
- s3:GetObject
- s3:GetObjectAcl
- s3:GetObjectTagging
- s3:ListBucket
- s3:PutBucketAcl
- s3:PutBucketPolicy
- s3:PutBucketPublicAccessBlock
- s3:PutBucketTagging
- s3:PutObject
- s3:PutObjectAcl
- s3:PutObjectTagging
必要な cloudfront 権限
- cloudfront:ListCloudFrontOriginAccessIdentities
- cloudfront:ListDistributions
- cloudfront:ListTagsForResource
OIDC 設定を、パブリック CloudFront ディストリビューション URL 経由で IAM アイデンティティープロバイダーがアクセスするプライベート S3 バケットに保存する予定の場合、ccoctl ユーティリティーを実行する AWS アカウントには次の追加パーミッションが必要です。
例4.95 CloudFront を使用したプライベート S3 バケットに対する追加の権限
- cloudfront:CreateCloudFrontOriginAccessIdentity
- cloudfront:CreateDistribution
- cloudfront:DeleteCloudFrontOriginAccessIdentity
- cloudfront:DeleteDistribution
- cloudfront:GetCloudFrontOriginAccessIdentity
- cloudfront:GetCloudFrontOriginAccessIdentityConfig
- cloudfront:GetDistribution
- cloudfront:TagResource
- cloudfront:UpdateDistribution
注記
これらの追加のパーミッションは、ccoctl aws create-all コマンドで認証情報要求を処理する際の --create-private-s3-bucket オプションの使用をサポートします。

手順

次のコマンドを実行して、OpenShift Container Platform リリースイメージの変数を設定します。
```
$ RELEASE_IMAGE=$(./openshift-install version | awk '/release image/ {print $3}')
```
以下のコマンドを実行して、OpenShift Container Platform リリースイメージから CCO コンテナーイメージを取得します。
```
$ CCO_IMAGE=$(oc adm release info --image-for='cloud-credential-operator' $RELEASE_IMAGE -a ~/.pull-secret)
```
注記
$RELEASE_IMAGE のアーキテクチャーが、ccoctlツールを使用する環境のアーキテクチャーと一致していることを確認してください。
以下のコマンドを実行して、OpenShift Container Platform リリースイメージ内の CCO コンテナーイメージから ccoctl バイナリーを抽出します。
```
$ oc image extract $CCO_IMAGE --file="/usr/bin/ccoctl" -a ~/.pull-secret
```
次のコマンドを実行して、権限を変更して ccoctl を実行可能にします。
```
$ chmod 775 ccoctl
```

検証

ccoctl が使用できることを確認するには、help ファイルを表示します。コマンドを実行するときは、相対ファイル名を使用します。以下に例を示します。

$ ./ccoctl.rhel9

出力例

OpenShift credentials provisioning tool

Usage:
  ccoctl [command]

Available Commands:
  alibabacloud Manage credentials objects for alibaba cloud
  aws          Manage credentials objects for AWS cloud
  azure        Manage credentials objects for Azure
  gcp          Manage credentials objects for Google cloud
  help         Help about any command
  ibmcloud     Manage credentials objects for IBM Cloud
  nutanix      Manage credentials objects for Nutanix

Flags:
  -h, --help   help for ccoctl

Use "ccoctl [command] --help" for more information about a command.

4.15.11.2.2. Cloud Credential Operator ユーティリティーを使用した AWS リソースの作成

AWS リソースを作成するときは、次のオプションがあります。

ccoctl aws create-all コマンドを使用して AWS リソースを自動的に作成できます。これはリソースを作成する最も簡単な方法です。単一コマンドでの AWS リソースの作成を参照してください。
AWS リソースの変更前に ccoctl ツールが作成する JSON ファイルを確認する必要がある場合や、ccoctl ツールが AWS リソースを自動作成するために使用するプロセスが組織の要件を満たさない場合は、AWS リソースを個別に作成できます。AWS リソースの個別の作成を参照してください。

4.15.11.2.2.1. 単一コマンドでの AWS リソースの作成

ccoctl ツールが AWS リソースの作成に使用するプロセスが組織の要件を自動的に満たす場合は、ccoctl aws create-all コマンドを使用して AWS リソースの作成を自動化できます。

それ以外の場合は、AWS リソースを個別に作成できます。詳細は、「AWS リソースの個別の作成」を参照してください。

注記

デフォルトで、ccoctl はコマンドが実行されるディレクトリーにオブジェクトを作成します。オブジェクトを別のディレクトリーに作成するには、--output-dir フラグを使用します。この手順では、<path_to_ccoctl_output_dir> を使用してこの場所を参照します。

前提条件

以下が必要になります。

ccoctl バイナリーを抽出して準備している。

手順

次のコマンドを実行して、インストールファイルのリリースイメージを $RELEASE_IMAGE 変数に設定します。
```
$ RELEASE_IMAGE=$(./openshift-install version | awk '/release image/ {print $3}')
```
以下のコマンドを実行して、OpenShift Container Platform リリースイメージから CredentialsRequest オブジェクトのリストを抽出します。
```
$ oc adm release extract \
  --from=$RELEASE_IMAGE \
  --credentials-requests \
  --included \1
  --install-config=<path_to_directory_with_installation_configuration>/install-config.yaml \2
  --to=<path_to_directory_for_credentials_requests> 3
```
1
--included パラメーターには、特定のクラスター設定に必要なマニフェストのみが含まれます。
2
install-config.yaml ファイルの場所を指定します。
3
CredentialsRequest オブジェクトを保存するディレクトリーへのパスを指定します。指定したディレクトリーが存在しない場合は、このコマンドによって作成されます。
注記
このコマンドの実行には少し時間がかかる場合があります。
次のコマンドを実行し、ccoctl ツールを使用して CredentialsRequest オブジェクトをすべて処理します。
```
$ ccoctl aws create-all \
  --name=<name> \1
  --region=<aws_region> \2
  --credentials-requests-dir=<path_to_credentials_requests_directory> \3
  --output-dir=<path_to_ccoctl_output_dir> \4
  --create-private-s3-bucket 5
```
1
追跡用に作成されたクラウドリソースにタグを付けるために使用される名前です。
2
クラウドリソースが作成される AWS リージョンです。
3
コンポーネント CredentialsRequest オブジェクトのファイルを含むディレクトリーを指定します。
4
オプション: ccoctl ユーティリティーがオブジェクトを作成するディレクトリーを指定します。デフォルトでは、ユーティリティーは、コマンドが実行されるディレクトリーにオブジェクトを作成します。
5
オプション: デフォルトでは、ccoctl ユーティリティーは OpenID Connect (OIDC) 設定ファイルをパブリック S3 バケットに保存し、S3 URL をパブリック OIDC エンドポイントとして使用します。代わりに、パブリック CloudFront 配布 URL を介して IAM ID プロバイダーによってアクセスされるプライベート S3 バケットに OIDC 設定を保存するには、--create-private-s3-bucket パラメーターを使用します。
注記
クラスターで TechPreviewNoUpgrade 機能セットによって有効化されたテクノロジープレビュー機能を使用している場合は、--enable-tech-preview パラメーターを含める必要があります。

検証

OpenShift Container Platform シークレットが作成されることを確認するには、<path_to_ccoctl_output_dir>/manifests ディレクトリーのファイルを一覧表示します。

$ ls <path_to_ccoctl_output_dir>/manifests

出力例

cluster-authentication-02-config.yaml
openshift-cloud-credential-operator-cloud-credential-operator-iam-ro-creds-credentials.yaml
openshift-cloud-network-config-controller-cloud-credentials-credentials.yaml
openshift-cluster-api-capa-manager-bootstrap-credentials-credentials.yaml
openshift-cluster-csi-drivers-ebs-cloud-credentials-credentials.yaml
openshift-image-registry-installer-cloud-credentials-credentials.yaml
openshift-ingress-operator-cloud-credentials-credentials.yaml
openshift-machine-api-aws-cloud-credentials-credentials.yaml

AWS にクエリーを実行すると、IAM ロールが作成されていることを確認できます。詳細は AWS ドキュメントの IAM ロールの一覧表示について参照してください。

4.15.11.2.2.2. AWS リソースの個別の作成

ccoctl ツールを使用して、AWS リソースを個別に作成できます。このオプションは、異なるユーザーや部門間でこれらのリソースを作成する責任を共有する組織に役に立ちます。

それ以外の場合は、ccoctl aws create-all コマンドを使用して AWS リソースを自動的に作成できます。詳細は、「単一コマンドによる AWS リソースの作成」を参照してください。

注記

一部の ccoctl コマンドは AWS API 呼び出しを行い、AWS リソースを作成または変更します。--dry-run フラグを使用して、API 呼び出しを回避できます。このフラグを使用すると、代わりにローカルファイルシステムに JSON ファイルが作成されます。JSON ファイルを確認して変更し、AWS CLI ツールで --cli-input-json パラメーターを使用して適用できます。

前提条件

ccoctl バイナリーを展開して準備しておく。

手順

次のコマンドを実行して、クラスターの OpenID Connect プロバイダーを設定するために使用されるパブリックおよびプライベート RSA キーファイルを生成します。
```
$ ccoctl aws create-key-pair
```
出力例
```
2021/04/13 11:01:02 Generating RSA keypair
2021/04/13 11:01:03 Writing private key to /<path_to_ccoctl_output_dir>/serviceaccount-signer.private
2021/04/13 11:01:03 Writing public key to /<path_to_ccoctl_output_dir>/serviceaccount-signer.public
2021/04/13 11:01:03 Copying signing key for use by installer
```
serviceaccount-signer.private および serviceaccount-signer.public は、生成されるキーファイルです。
このコマンドは、クラスターがインストール時に必要とするプライベートキーを /<path_to_ccoctl_output_dir>/tls/bound-service-account-signing-key.key に作成します。
次のコマンドを実行して、AWS 上に OpenID Connect ID プロバイダーと S3 バケットを作成します。
```
$ ccoctl aws create-identity-provider \
  --name=<name> \1
  --region=<aws_region> \2
  --public-key-file=<path_to_ccoctl_output_dir>/serviceaccount-signer.public 3
```
1
<name> は、追跡用に作成されたクラウドリソースにタグを付けるために使用される名前です。
2
<aws_region> は、クラウドリソースが作成される AWS リージョンです。
3
<path_to_ccoctl_output_dir> は、ccoctl aws create-key-pair コマンドが生成したパブリックキーファイルへのパスです。
出力例
```
2021/04/13 11:16:09 Bucket <name>-oidc created
2021/04/13 11:16:10 OpenID Connect discovery document in the S3 bucket <name>-oidc at .well-known/openid-configuration updated
2021/04/13 11:16:10 Reading public key
2021/04/13 11:16:10 JSON web key set (JWKS) in the S3 bucket <name>-oidc at keys.json updated
2021/04/13 11:16:18 Identity Provider created with ARN: arn:aws:iam::<aws_account_id>:oidc-provider/<name>-oidc.s3.<aws_region>.amazonaws.com
```
openid-configuration は検出ドキュメントであり、keys.json は JSON Web キーセットファイルです。
このコマンドは、YAML 設定ファイルを /<path_to_ccoctl_output_dir>/manifests/cluster-authentication-02-config.yaml にも作成します。このファイルは、AWS IAM アイデンティティープロバイダーがトークンを信頼するように、クラスターが生成するサービスアカウントトークンの発行側の URL フィールドを設定します。
クラスターの各コンポーネントについて IAM ロールを作成します。
1. 次のコマンドを実行して、インストールファイルのリリースイメージを $RELEASE_IMAGE 変数に設定します。
```
$ RELEASE_IMAGE=$(./openshift-install version | awk '/release image/ {print $3}')
```
2. OpenShift Container Platform リリースイメージから CredentialsRequest オブジェクトの一覧を抽出します。
```
$ oc adm release extract \
  --from=$RELEASE_IMAGE \
  --credentials-requests \
  --included \1
  --install-config=<path_to_directory_with_installation_configuration>/install-config.yaml \2
  --to=<path_to_directory_for_credentials_requests> 3
```
  1
  --included パラメーターには、特定のクラスター設定に必要なマニフェストのみが含まれます。
  2
  install-config.yaml ファイルの場所を指定します。
  3
  CredentialsRequest オブジェクトを保存するディレクトリーへのパスを指定します。指定したディレクトリーが存在しない場合は、このコマンドによって作成されます。
3. 次のコマンドを実行し、ccoctl ツールを使用して CredentialsRequest オブジェクトをすべて処理します。
```
$ ccoctl aws create-iam-roles \
  --name=<name> \
  --region=<aws_region> \
  --credentials-requests-dir=<path_to_credentials_requests_directory> \
  --identity-provider-arn=arn:aws:iam::<aws_account_id>:oidc-provider/<name>-oidc.s3.<aws_region>.amazonaws.com
```
  注記
  GovCloud などの代替の IAM API エンドポイントを使用する AWS 環境では、--region パラメーターでリージョンを指定する必要もあります。
  クラスターで TechPreviewNoUpgrade 機能セットによって有効化されたテクノロジープレビュー機能を使用している場合は、--enable-tech-preview パラメーターを含める必要があります。
  それぞれの CredentialsRequest オブジェクトについて、ccoctl は指定された OIDC アイデンティティープロバイダーに関連付けられた信頼ポリシーと、OpenShift Container Platform リリースイメージの各 CredentialsRequest オブジェクトに定義されるパーミッションポリシーを使用して IAM ロールを作成します。

検証

OpenShift Container Platform シークレットが作成されることを確認するには、<path_to_ccoctl_output_dir>/manifests ディレクトリーのファイルを一覧表示します。

$ ls <path_to_ccoctl_output_dir>/manifests

出力例

cluster-authentication-02-config.yaml
openshift-cloud-credential-operator-cloud-credential-operator-iam-ro-creds-credentials.yaml
openshift-cloud-network-config-controller-cloud-credentials-credentials.yaml
openshift-cluster-api-capa-manager-bootstrap-credentials-credentials.yaml
openshift-cluster-csi-drivers-ebs-cloud-credentials-credentials.yaml
openshift-image-registry-installer-cloud-credentials-credentials.yaml
openshift-ingress-operator-cloud-credentials-credentials.yaml
openshift-machine-api-aws-cloud-credentials-credentials.yaml

4.15.11.2.3. Cloud Credential Operator ユーティリティーマニフェストの組み込み

個々のコンポーネントに対してクラスターの外部で管理される短期セキュリティー認証情報を実装するには、Cloud Credential Operator ユーティリティー (ccoctl) が作成したマニフェストファイルを、インストールプログラムの正しいディレクトリーに移動する必要があります。

前提条件

クラスターをホストするクラウドプラットフォームでアカウントを設定しました。
Cloud Credential Operator ユーティリティー (ccoctl) が設定されている。
ccoctl ユーティリティーを使用して、クラスターに必要なクラウドプロバイダーリソースを作成している。

手順

install-config.yaml 設定ファイルの credentialsMode パラメーターを Manual に設定しなかった場合は、次のように値を変更します。
設定ファイルのサンプルスニペット
```
apiVersion: v1
baseDomain: example.com
credentialsMode: Manual
# ...
```
インストールマニフェストファイルをまだ作成していない場合は、次のコマンドを実行して作成します。
```
$ openshift-install create manifests --dir <installation_directory>
```
ここで、<installation_directory> は、インストールプログラムがファイルを作成するディレクトリーに置き換えます。
次のコマンドを実行して、ccoctl ユーティリティーが生成したマニフェストを、インストールプログラムが作成した manifests ディレクトリーにコピーします。
```
$ cp /<path_to_ccoctl_output_dir>/manifests/* ./manifests/
```
秘密鍵を含む tls ディレクトリーをインストールディレクトリーにコピーします。
```
$ cp -a /<path_to_ccoctl_output_dir>/tls .
```

4.15.12. クラスターのデプロイ

互換性のあるクラウドプラットフォームに OpenShift Container Platform をインストールできます。

重要

インストールプログラムの create cluster コマンドは、初期インストール時に 1 回だけ実行できます。

前提条件

クラスターをホストするクラウドプラットフォームでアカウントを設定しました。
OpenShift Container Platform インストールプログラムおよびクラスターのプルシークレットがある。
ホスト上のクラウドプロバイダーアカウントに、クラスターをデプロイするための適切な権限があることが確認されました。アカウントの権限が正しくないと、インストールプロセスが失敗し、不足している権限を示すエラーメッセージが表示されます。

手順

インストールプログラムが含まれるディレクトリーに切り替え、クラスターのデプロイメントを初期化します。
```
$ ./openshift-install create cluster --dir <installation_directory> \ 1
    --log-level=info 2
```
1
<installation_directory> については、カスタマイズした ./install-config.yaml ファイルの場所を指定します。
2
異なるインストールの詳細情報を表示するには、info ではなく、warn、debug、または error を指定します。
オプション: クラスターのインストールに使用した IAM アカウントから AdministratorAccess ポリシーを削除するか、無効にします。
注記
AdministratorAccess ポリシーが提供する昇格したパーミッションはインストール時にのみ必要です。

検証

クラスターのデプロイが正常に完了すると、次のようになります。

ターミナルには、Web コンソールへのリンクや kubeadmin ユーザーの認証情報など、クラスターにアクセスするための指示が表示されます。
認証情報は <installation_directory>/.openshift_install.log にも出力されます。

重要

インストールプログラム、またはインストールプログラムが作成するファイルを削除することはできません。これらはいずれもクラスターを削除するために必要になります。

出力例

...
INFO Install complete!
INFO To access the cluster as the system:admin user when using 'oc', run 'export KUBECONFIG=/home/myuser/install_dir/auth/kubeconfig'
INFO Access the OpenShift web-console here: https://console-openshift-console.apps.mycluster.example.com
INFO Login to the console with user: "kubeadmin", and password: "password"
INFO Time elapsed: 36m22s

重要

インストールプログラムが生成する Ignition 設定ファイルには、24 時間が経過すると期限切れになり、その後に更新される証明書が含まれます。証明書を更新する前にクラスターが停止し、24 時間経過した後にクラスターを再起動すると、クラスターは期限切れの証明書を自動的に復元します。例外として、kubelet 証明書を回復するために保留状態の node-bootstrapper 証明書署名要求 (CSR) を手動で承認する必要があります。詳細は、コントロールプレーン証明書の期限切れの状態からのリカバリー に関するドキュメントを参照してください。
24 時間証明書はクラスターのインストール後 16 時間から 22 時間にローテーションするため、Ignition 設定ファイルは、生成後 12 時間以内に使用することを推奨します。12 時間以内に Ignition 設定ファイルを使用することにより、インストール中に証明書の更新が実行された場合のインストールの失敗を回避できます。

4.15.13. CLI の使用によるクラスターへのログイン

クラスター kubeconfig ファイルをエクスポートし、デフォルトシステムユーザーとしてクラスターにログインできます。kubeconfig ファイルには、クライアントを正しいクラスターおよび API サーバーに接続するために CLI で使用されるクラスターに関する情報が含まれます。このファイルはクラスターに固有のファイルであり、OpenShift Container Platform のインストール時に作成されます。

前提条件

OpenShift Container Platform クラスターをデプロイしていること。
oc CLI をインストールしていること。

手順

kubeadmin 認証情報をエクスポートします。
```
$ export KUBECONFIG=<installation_directory>/auth/kubeconfig 1
```
1
<installation_directory> には、インストールファイルを保存したディレクトリーへのパスを指定します。
エクスポートされた設定を使用して、oc コマンドを正常に実行できることを確認します。
```
$ oc whoami
```
出力例
```
system:admin
```

/validating-an-installation.adoc

4.15.14. Web コンソールを使用したクラスターへのログイン

kubeadmin ユーザーは、OpenShift Container Platform のインストール後はデフォルトで存在します。OpenShift Container Platform Web コンソールを使用し、kubeadmin ユーザーとしてクラスターにログインできます。

前提条件

インストールホストにアクセスできる。
クラスターのインストールを完了しており、すべてのクラスター Operator が利用可能である。

手順

インストールホストで kubeadmin-password ファイルから kubeadmin ユーザーのパスワードを取得します。
```
$ cat <installation_directory>/auth/kubeadmin-password
```
注記
または、インストールホストで <installation_directory>/.openshift_install.log ログファイルから kubeadmin パスワードを取得できます。
OpenShift Container Platform Web コンソールルートをリスト表示します。
```
$ oc get routes -n openshift-console | grep 'console-openshift'
```
注記
または、インストールホストで <installation_directory>/.openshift_install.log ログファイルからで OpenShift Container Platform ルートを取得できます。
出力例
```
console     console-openshift-console.apps.<cluster_name>.<base_domain>            console     https   reencrypt/Redirect   None
```
Web ブラウザーで前述のコマンドの出力で詳細に説明されたルートに移動し、kubeadmin ユーザーとしてログインします。

4.15.15. OpenShift Container Platform の Telemetry アクセス

OpenShift Container Platform 4.14 では、クラスターの健全性および正常に実行された更新についてのメトリクスを提供するためにデフォルトで実行される Telemetry サービスにもインターネットアクセスが必要です。クラスターがインターネットに接続されている場合、Telemetry は自動的に実行され、クラスターは OpenShift Cluster Manager に登録されます。

OpenShift Cluster Manager インベントリーが正常である (Telemetry によって自動的に維持、または OpenShift Cluster Manager を使用して手動で維持) ことを確認した後に、subscription watch を使用して、アカウントまたはマルチクラスターレベルで OpenShift Container Platform サブスクリプションを追跡します。

関連情報

OpenShift Container Platform Web コンソールへのアクセスと理解に関する詳細は、Web コンソールへのアクセスを参照してください。
Telemetry サービスの詳細は、リモートヘルスモニタリングを参照してください。

4.15.16. クラスターの制限

重要

ネットワークロードバランサー (NLB) と Classic Load Balancer は、AWS Outposts ではサポートされていません。クラスターが作成されると、すべてのロードバランサーが AWS リージョンに作成されます。Outpost インスタンス内で作成されたロードバランサーを使用するには、Application Load Balancer を使用する必要があります。その目標を達成するために、AWS Load Balancer Operator を使用できます。

ALB の outpost インスタンスにあるパブリックサブネットを使用する場合は、VPC の作成時に追加された特別なタグ (kubernetes.io/cluster/.*-outposts: own) を削除する必要があります。これにより、LoadBalancer (ネットワークロードバランサー) タイプの新しいサービスを作成できなくなります。

詳細は、AWS Load Balancer Operator についてを参照してください。

重要

AWS Elastic Block Store の制限を使用した永続ストレージ

AWS Outposts は、Amazon Elastic Block Store (EBS) gp3 ボリュームをサポートしていません。インストール後、クラスターには 2 つのストレージクラス (gp3-csi と gp2-csi) が含まれ、gp3-csi がデフォルトのストレージクラスになります。常に gp2-csi を使用することが重要です。以下の OpenShift CLI (oc) コマンドを使用して、デフォルトのストレージクラスを変更できます。
```
$ oc annotate --overwrite storageclass gp3-csi storageclass.kubernetes.io/is-default-class=false
$ oc annotate --overwrite storageclass gp2-csi storageclass.kubernetes.io/is-default-class=true
```
Outpost インスタンスでボリュームを作成するために、CSI ドライバーは、CSINode オブジェクトに格納されているトポロジーキーに基づいて Outpost ARN を決定します。CSI ドライバーが正しいトポロジー値を使用するようにするには、WaitForConsumer ボリュームバインドモードを使用し、作成された新しいストレージクラスに許可されたトポロジーを設定しないようにする必要があります。

4.15. AWS Outposts のリモートワーカーを使用して AWS にクラスターをインストールする

4.15.1. 前提条件

4.15.2. カスタム VPC の使用について

4.15.2.1. VPC を使用するための要件

オプション 1: VPC エンドポイントを作成する

オプション 2: VPC エンドポイントなしでプロキシーを作成する

オプション 3: VPC エンドポイントでプロキシーを作成する

4.15.2.2. VPC 検証

4.15.2.3. パーミッションの区分

4.15.2.4. クラスター間の分離

4.15.2.5. AWS セキュリティーグループ

4.15.3. OpenShift Container Platform のインターネットアクセス

4.15.4. クラスターノードの SSH アクセス用のキーペアの生成

4.15.5. インストールプログラムの取得

4.15.6. クラスターインストールの最小リソース要件

4.15.7. AWS Outposts インスタンスタイプの特定

4.15.8. インストール設定ファイルの作成

4.15.8.1. AWS のカスタマイズされた install-config.yaml ファイルのサンプル

4.15.8.2. 既存の AWS セキュリティーグループをクラスターに適用する

4.15.9. マニフェストファイルの生成

4.15.9.1. マニフェストファイルの変更

4.15.10. バイナリーのダウンロードによる OpenShift CLI のインストール

Linux への OpenShift CLI のインストール

Windows への OpenShift CLI のインストール

macOS への OpenShift CLI のインストール

4.15.11. 管理者レベルのシークレットを kube-system プロジェクトに保存する代替方法

4.15.11.1. 長期認証情報を手動で作成する

4.15.11.2. 短期認証情報を使用するように AWS クラスターを設定

4.15.11.2.1. Cloud Credential Operator ユーティリティーの設定

4.15.11.2.2. Cloud Credential Operator ユーティリティーを使用した AWS リソースの作成

4.15.11.2.2.1. 単一コマンドでの AWS リソースの作成

4.15.11.2.2.2. AWS リソースの個別の作成

4.15.11.2.3. Cloud Credential Operator ユーティリティーマニフェストの組み込み

4.15.12. クラスターのデプロイ

4.15.13. CLI の使用によるクラスターへのログイン

4.15.14. Web コンソールを使用したクラスターへのログイン

4.15.15. OpenShift Container Platform の Telemetry アクセス

4.15.16. クラスターの制限

4.15.17. 次のステップ

詳細情報

試用、購入および販売

コミュニティー

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

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

会社概要

Red Hat legal and privacy links

Red Hat legal and privacy links