3.7. AWS の特殊リージョンにクラスターをインストールする
OpenShift Container Platform バージョン 4.20 では、Amazon Web Services (AWS) 上のクラスターを、シークレットおよびトップシークレットリージョン、政府向けリージョン、中国リージョンなどの特殊なリージョンにインストールできます。リージョンを設定するには、クラスターをインストールする前に、install-config.yaml ファイルでパラメーターを変更します。
次の特殊リージョンがサポートされています。
| リージョンタイプ | サポートされているリージョン |
|---|---|
| 中国 |
|
| シークレットおよびトップシークレット |
|
| 政府向け |
|
OpenShift Container Platform 4.20 では、インストールプログラムは Terraform の代わりに Cluster API を使用して、AWS へのインストール中にクラスターインフラストラクチャーをプロビジョニングします。Cluster API 実装を使用した AWS のクラスターをシークレットまたはトップシークレットリージョンにインストールすることは、OpenShift Container Platform 4.20 のリリース時点ではテストされていません。このドキュメントは、シークレットリージョンへのインストールがテストされたときに更新されます。
Network Load Balancer のシークレットまたはトップシークレットのセキュリティーグループのサポートには、これらのリージョンへのインストールの失敗を引き起こす既知の問題があります。詳細は、OCPBUGS-33311 を参照してください。
AWS SC2S および C2S リージョンでサポートされる最大 MTU は、パブリックリージョンと同じではありません。インストール中の MTU の設定に関する詳細は、ネットワークをカスタマイズした AWS へのクラスターのインストール の クラスターネットワークオペレーターの設定オブジェクト セクションを参照してください。
3.7.1. 前提条件 リンクのコピーリンクがクリップボードにコピーされました!
- 中国リージョンにクラスターをインストールする場合は、インターネットコンテンツプロバイダー (ICP) ライセンスが必要です。
- OpenShift Container Platform のインストールおよび更新 プロセスの詳細を確認した。
- クラスターインストール方法の選択およびそのユーザー向けの準備 を確認した。
- クラスターをホストするための AWS アカウントを設定 した。
- ファイアウォールを使用する場合は、クラスターがアクセスを必要とするサイトを許可するようにファイアウォールを設定する必要がある。
AWS プロファイルがご使用のコンピューターに保存されている場合、マルチファクター認証デバイスを使用中に生成した一時的なセッショントークンを使用することはできません。クラスターは継続的に現行の AWS 認証情報を使用して、クラスターの有効期間全体にわたって AWS リソースを作成するため、有効期間の長い認証情報を使用する必要があります。適切なキーを生成するには、AWS ドキュメントの Managing Access Keys for IAM Users を参照してください。キーは、インストールプログラムの実行時に指定できます。
3.7.2. 政府向けリージョンのインストール要件 リンクのコピーリンクがクリップボードにコピーされました!
政府向けリージョンで AWS Marketplace イメージを使用して OpenShift Container Platform クラスターをデプロイする場合は、まず AWS を通じてサブスクライブする必要があります。オファーにサブスクライブすると、インストールプログラムがコンピュートノードのデプロイに使用する AMI ID が提供されます。
AWS Marketplace イメージを使用するには、コンピュートマシンの RHCOS イメージのみを変更する必要があります。コントロールプレーンマシンおよびインフラストラクチャーノードに OpenShift Container Platform サブスクリプションは必要なく、デフォルトでパブリック RHCOS デフォルトイメージが使用されるため、AWS 請求書にサブスクリプションコストは発生しません。したがって、クラスターのデフォルトのブートイメージやコントロールプレーンのブートイメージは変更しないでください。AWS Marketplace イメージを適用すると追加のライセンスコストが発生し、これは修正できません。
前提条件
- オファーを購入するための AWS アカウントを持っている。このアカウントは、クラスターのインストールに使用されるアカウントと同じである必要はありません。
手順
- AWS Marketplace で OpenShift Container Platform サブスクリプションを完了します。
-
ご使用の AWS リージョンの AMI ID を記録します。インストールプロセスの一環として、クラスターをデプロイする前に、この値で
install-config.yamlファイルを更新する必要があります。
3.7.3. 中国、シークレット、およびトップシークレットリージョンのインストール要件 リンクのコピーリンクがクリップボードにコピーされました!
Red Hat は、AWS の中国、シークレット、またはトップシークレットリージョン向けの Red Hat Enterprise Linux CoreOS (RHCOS) Amazon Machine Image (AMI) を公開していません。
これらのリージョンのいずれかにクラスターをインストールするには、以下を実行する必要があります。
- カスタム RHCOS AMI をアップロードします。
-
インストール設定ファイル (
install-config.yaml) を手動で作成します。 - インストール設定ファイルで、AWS リージョンおよび付随するカスタム AMI を指定します。
OpenShift Container Platform インストールプログラムを使用してインストール設定ファイルを作成することはできません。インストーラーは RHCOS AMI のネイティブサポートのない AWS リージョンをリスト表示しません。
クラスターをシークレットまたはトップシークレットリージョンにインストールする場合は、AWS API でカスタム CA トラストバンドルが必要になるため、install-config.yaml ファイルの additionalTrustBundle フィールドでカスタム CA 証明書も定義する必要があります。インストールプログラムが AWS API にアクセスできるようにするには、インストールプログラムを実行するマシンに CA 証明書を定義する必要もあります。マシン上のトラストストアに CA バンドルを追加するか、AWS_CA_BUNDLE 環境変数を使用するか、AWS 設定ファイルの ca_bundle フィールドで CA バンドルを定義する必要があります。
3.7.4. プライベートクラスター リンクのコピーリンクがクリップボードにコピーされました!
外部エンドポイントを公開しないプライベート OpenShift Container Platform クラスターをデプロイすることができます。プライベートクラスターは内部ネットワークからのみアクセスでき、インターネット上では表示されません。
AWS の政府向け、シークレット、およびトップシークレットリージョンの Route 53 では、パブリックゾーンがサポートされていません。したがって、クラスターをこれらのリージョンのいずれかにデプロイする場合は、クラスターをプライベートにする必要があります。
デフォルトで、OpenShift Container Platform はパブリックにアクセス可能な DNS およびエンドポイントを使用できるようにプロビジョニングされます。プライベートクラスターは、クラスターのデプロイ時に DNS、Ingress コントローラー、および API サーバーを private に設定します。つまり、クラスターリソースは内部ネットワークからのみアクセスでき、インターネット上では表示されません。
クラスターにパブリックサブネットがある場合、管理者により作成されたロードバランサーサービスはパブリックにアクセスできる可能性があります。クラスターのセキュリティーを確保するには、これらのサービスに明示的にプライベートアノテーションが付けられていることを確認してください。
プライベートクラスターをデプロイするには、以下を行う必要があります。
- 要件を満たす既存のネットワークを使用します。クラスターリソースはネットワーク上の他のクラスター間で共有される可能性があります。
以下にアクセスできるマシンからデプロイ。
- プロビジョニングするクラウドの API サービス。
- プロビジョニングするネットワーク上のホスト。
- インストールメディアを取得するインターネット。
これらのアクセス要件を満たし、所属する会社のガイドラインに準拠したすべてのマシンを使用することができます。たとえば、このマシンには、クラウドネットワーク上の bastion ホストを使用できます。
AWS China は、VPC とネットワーク間の VPN 接続をサポートしません。Beijing および Ningxia リージョンの Amazon VPC サービスの詳細は、AWS China ドキュメントの Amazon Virtual Private Cloud を参照してください。
3.7.4.1. AWS のプライベートクラスター リンクのコピーリンクがクリップボードにコピーされました!
Amazon Web Services (AWS) でプライベートクラスターを作成するには、クラスターをホストするために既存のプライベート VPC およびサブネットを指定する必要があります。インストールプログラムは、クラスターが必要とする DNS レコードを解決できる必要もあります。インストールプログラムは、プライベートネットワークからのみアクセスできるように Ingress Operator および API サーバーを設定します。
クラスターには、引き続き AWS API にアクセスするためにインターネットへのアクセスが必要になります。
以下のアイテムは、プライベートクラスターのインストール時に必要ではなく、作成されません。
- パブリックサブネット
- パブリック Ingress をサポートするパブリックロードバランサー
-
クラスターの
baseDomainに一致するパブリック Route 53 ゾーン
インストールプログラムは、プライベート Route 53 ゾーンを作成するために指定する baseDomain とクラスターに必要なレコードを使用します。クラスターは、Operator がクラスターのパブリックレコードを作成せず、すべてのクラスターマシンが指定するプライベートサブネットに配置されるように設定されます。
3.7.4.1.1. 制限事項 リンクのコピーリンクがクリップボードにコピーされました!
プライベートクラスターにパブリック機能を追加する機能には制限があります。
- Kubernetes API エンドポイントは、追加のアクションを実行せずにインストールする場合はパブリックにすることができません。これらのアクションには、使用中のアベイラビリティーゾーンごとに VPC でパブリックサブネットやパブリックのロードバランサーを作成することや、6443 のインターネットからのトラフィックを許可するようにコントロールプレーンのセキュリティーグループを設定することなどが含まれます。
-
パブリックのサービスタイプのロードバランサーを使用する場合には、各アベイラビリティーゾーンのパブリックサブネットに
kubernetes.io/cluster/<cluster-infra-id>: sharedのタグを付け、AWS がそれらを使用してパブリックロードバランサーを作成できるようにします。
3.7.5. カスタム VPC の使用について リンクのコピーリンクがクリップボードにコピーされました!
OpenShift Container Platform 4.20 では、Amazon Web Services (AWS) の既存 Amazon Virtual Private Cloud (VPC) 内の既存サブネットにクラスターをデプロイできます。OpenShift Container Platform を既存の AWS VPC にデプロイすると、新規アカウントの制限を回避したり、会社のガイドラインによる運用上の制約をより容易に遵守することが可能になる場合があります。VPC を作成するために必要なインフラストラクチャーの作成パーミッションを取得できない場合は、このインストールオプションを使用します。
インストールプログラムは既存のサブネットにある他のコンポーネントを把握できないため、ユーザーの代わりにサブネットの CIDR を選択することはできません。クラスターをインストールするサブネットのネットワークを独自に設定する必要があります。
3.7.5.1. VPC を使用するための要件 リンクのコピーリンクがクリップボードにコピーされました!
インストールプログラムは、以下のコンポーネントを作成しなくなりました。
- インターネットゲートウェイ
- NAT ゲートウェイ
- サブネット
- ルートテーブル
- VPC
- VPC DHCP オプション
- VPC エンドポイント
インストールプログラムでは、クラウド提供の DNS サーバーを使用する必要があります。カスタム DNS サーバーの使用はサポートされていないため、インストールが失敗します。
カスタム VPC を使用する場合は、そのカスタム VPC と使用するインストールプログラムおよびクラスターのサブネットを適切に設定する必要があります。AWS VPC コンソールウィザードの設定と AWS VPC の作成および管理の詳細は、Amazon Web Services ドキュメントの VPC の作成 を参照してください。
インストールプログラムには、以下の機能はありません。
- 使用するクラスターのネットワーク範囲を細分化する。
- サブネットのルートテーブルを設定する。
- DHCP などの VPC オプションを設定する。
クラスターをインストールする前に、以下のタスクを完了する必要があります。AWS VPC でのネットワーキングの設定の詳細は、VPC ネットワーキングコンポーネント と VPC のルートテーブル を参照してください。
VPC は以下の特性を満たす必要があります。
VPC は
kubernetes.io/cluster/.*: owned、Name、openshift.io/clusterタグを使用できません。インストールプログラムは
kubernetes.io/cluster/.*: sharedタグを追加するようにサブネットを変更するため、サブネットでは 1 つ以上の空のタグスロットが利用可能である必要があります。AWS ドキュメントで タグ制限 を確認し、インストールプログラムでタグを指定する各サブネットに追加できるようにします。Nameタグは EC2Nameフィールドと重複し、その結果インストールが失敗するため、使用できません。-
OpenShift Container Platform クラスターを AWS Outpost に拡張し、既存の Outpost サブネットを使用する場合、既存のサブネットで
kubernetes.io/cluster/unmanaged: trueタグを使用する必要があります。このタグを適用しないと、Cloud Controller Manager が Outpost サブネットにサービスロードバランサーを作成するため、インストールが失敗する可能性があります。これはサポートされていない設定です。 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認証情報モードを使用する必要があります。
SC2S または C2S リージョンのクラスターは、EC2、ELB、および S3 エンドポイントのパブリック IP アドレスに到達できません。インストール中にインターネットトラフィックを制限するレベルに応じて、次の設定オプションを使用できます。
3.7.5.1.1. オプション 1: VPC エンドポイントを作成する リンクのコピーリンクがクリップボードにコピーされました!
VPC エンドポイントを作成し、クラスターが使用しているサブネットにアタッチします。次のようにエンドポイントに名前を付けます。
- 中国
-
ec2.<aws_region>.amazonaws.com.cn -
elasticloadbalancing.<aws_region>.amazonaws.com -
s3.<aws_region>.amazonaws.com
-
- SC2S
-
elasticloadbalancing.<aws_region>.sc2s.sgov.gov -
ec2.<aws_region>.sc2s.sgov.gov -
s3.<aws_region>.sc2s.sgov.gov
-
- C2S
-
elasticloadbalancing.<aws_region>.c2s.ic.gov -
ec2.<aws_region>.c2s.ic.gov -
s3.<aws_region>.c2s.ic.gov
-
このオプションを使用すると、VPC および必要な AWS サービスの間でネットワークトラフィックがプライベートのままになります。
3.7.5.1.2. オプション 2: VPC エンドポイントなしでプロキシーを作成する リンクのコピーリンクがクリップボードにコピーされました!
インストールプロセスの一環として、HTTP または HTTPS プロキシーを設定できます。このオプションを使用すると、インターネットトラフィックはプロキシーを経由して、必要な AWS サービスに到達します。
3.7.5.1.3. オプション 3: VPC エンドポイントでプロキシーを作成する リンクのコピーリンクがクリップボードにコピーされました!
インストールプロセスの一環として、VPC エンドポイントを使用して HTTP または HTTPS プロキシーを設定できます。VPC エンドポイントを作成し、クラスターが使用しているサブネットにアタッチします。次のようにエンドポイントに名前を付けます。
- 中国
-
ec2.<aws_region>.amazonaws.com.cn -
elasticloadbalancing.<aws_region>.amazonaws.com -
s3.<aws_region>.amazonaws.com
-
- SC2S
-
elasticloadbalancing.<aws_region>.sc2s.sgov.gov -
ec2.<aws_region>.sc2s.sgov.gov -
s3.<aws_region>.sc2s.sgov.gov
-
- C2S
-
elasticloadbalancing.<aws_region>.c2s.ic.gov -
ec2.<aws_region>.c2s.ic.gov -
s3.<aws_region>.c2s.ic.gov
-
install-config.yaml ファイルでプロキシーを設定するときに、これらのエンドポイントを noProxy フィールドに追加します。このオプションを使用すると、プロキシーはクラスターがインターネットに直接アクセスするのを防ぎます。ただし、VPC と必要な AWS サービスの間のネットワークトラフィックはプライベートのままです。
必要な VPC コンポーネント
お使いのマシンとの通信を可能にする適切な VPC およびサブネットを指定する必要があります。
| コンポーネント | AWS タイプ | 説明 | |
|---|---|---|---|
| VPC |
| 使用するクラスターのパブリック VPC を指定する必要があります。VPC は、各サブネットのルートテーブルを参照するエンドポイントを使用して、S3 でホストされているレジストリーとの通信を強化します。 | |
| パブリックサブネット |
| VPC には 1 から 3 のアベイラビリティーゾーンのパブリックサブネットが必要であり、それらを適切な Ingress ルールに関連付ける必要があります。 | |
| インターネットゲートウェイ |
| VPC に割り当てられたパブリックルートを持つパブリックインターネットゲートウェイが必要です。提供されるテンプレートでは、各パブリックサブネットに EIP アドレスと NAT ゲートウェイがあります。これらの NAT ゲートウェイは、プライベートサブネットインスタンスなどのクラスターリソースがインターネットに到達できるようにするもので、一部のネットワークが制限された環境またはプロキシーのシナリオでは必要ありません。 | |
| ネットワークアクセス制御 |
| VPC が以下のポートにアクセスできるようにする必要があります。 | |
| ポート | 理由 | ||
|
| インバウンド HTTP トラフィック | ||
|
| インバウンド HTTPS トラフィック | ||
|
| インバウンド SSH トラフィック | ||
|
| インバウンド一時 (ephemeral) トラフィック | ||
|
| アウトバウンド一時 (ephemeral) トラフィック | ||
| プライベートサブネット |
| VPC にはプライベートサブネットを使用できます。提供される CloudFormation テンプレートは 1 から 3 アベイラビリティーゾーンのプライベートサブネットを作成できます。プライベートサブネットを使用できる場合は、それらの適切なルートおよびテーブルを指定する必要があります。 | |
3.7.5.2. VPC 検証 リンクのコピーリンクがクリップボードにコピーされました!
指定するサブネットが適切であることを確認するには、インストールプログラムが以下のデータを確認します。
- 指定したサブネットすべてが存在します。
- プライベートサブネットを指定します。
- サブネットの CIDR は指定されたマシン CIDR に属します。
- 各アベイラビリティーゾーンのサブネットを指定します。それぞれのアベイラビリティーゾーンには、複数のパブリックおよびプライベートサブネットがありません。プライベートクラスターを使用する場合、各アベイラビリティーゾーンのプライベートサブネットのみを指定します。それ以外の場合は、各アベイラビリティーゾーンのパブリックサブネットおよびプライベートサブネットを指定します。
- 各プライベートサブネットアベイラビリティーゾーンのパブリックサブネットを指定します。マシンは、プライベートサブネットを指定しないアベイラビリティーゾーンにはプロビジョニングされません。
既存の VPC を使用するクラスターを破棄しても、VPC は削除されません。VPC から OpenShift Container Platform クラスターを削除する場合、kubernetes.io/cluster/.*: shared タグは、それが使用したサブネットから削除されます。
3.7.5.3. パーミッションの区分 リンクのコピーリンクがクリップボードにコピーされました!
OpenShift Container Platform 4.3 以降、クラスターのデプロイに、インストールプログラムがプロビジョニングするインフラストラクチャークラスターに必要なすべてのパーミッションを必要としなくなりました。この変更は、ある会社で個人がクラウドで他とは異なるリソースを作成できるようにパーミッションが区分された状態に類似するものです。たとえば、インスタンス、バケット、ロードバランサーなどのアプリケーション固有のアイテムを作成することはできますが、VPC、サブネット、または Ingress ルールなどのネットワーク関連のコンポーネントは作成できない可能性があります。
クラスターの作成時に使用する AWS の認証情報には、VPC、およびサブネット、ルーティングテーブル、インターネットゲートウェイ、NAT、VPN などの VPC 内のコアとなるネットワークコンポーネントの作成に必要なネットワークのパーミッションは必要ありません。ELB、セキュリティーグループ、S3 バケットおよびノードなどの、クラスター内でマシンに必要なアプリケーションリソースを作成するパーミッションは依然として必要になります。
3.7.5.4. クラスター間の分離 リンクのコピーリンクがクリップボードにコピーされました!
OpenShift Container Platform を既存のネットワークにデプロイする場合、クラスターサービスの分離の規模は以下の方法で縮小されます。
- 複数の OpenShift Container Platform クラスターを同じ VPC にインストールできます。
- ICMP Ingress はネットワーク全体から許可されます。
- TCP 22 Ingress (SSH) はネットワーク全体に対して許可されます。
- コントロールプレーンの TCP 6443 Ingress (Kubernetes API) はネットワーク全体に対して許可されます。
- コントロールプレーンの TCP 22623 Ingress (MCS) はネットワーク全体に対して許可されます。
3.7.5.5. オプション: AWS セキュリティーグループ リンクのコピーリンクがクリップボードにコピーされました!
デフォルトでは、インストールプログラムは、セキュリティーグループを作成し、コントロールプレーンとコンピュートマシンに接続します。デフォルトのセキュリティーグループに関連付けられたルールは変更できません。
ただし、既存の VPC に関連付けられている追加の既存の AWS セキュリティーグループをコントロールプレーンとコンピュートマシンに適用できます。カスタムセキュリティーグループを適用すると、これらのマシンの受信トラフィックまたは送信トラフィックを制御する必要がある場合に、組織のセキュリティーニーズを満たすことができます。
インストールプロセスの一環として、クラスターをデプロイする前に install-config.yaml ファイルを変更してカスタムセキュリティーグループを適用します。
詳細は、「既存の AWS セキュリティーグループのクラスターへの適用」を参照してください。
3.7.6. AWS でのカスタム RHCOS AMI のアップロード リンクのコピーリンクがクリップボードにコピーされました!
カスタム Amazon Web Services (AWS) リージョンにデプロイする場合、そのリージョンに属するカスタム Red Hat Enterprise Linux CoreOS (RHCOS) Amazon Machine Image (AMI) をアップロードする必要があります。
前提条件
- AWS アカウントを設定している。
- 必要な IAM サービスロール で、Amazon S3 バケットを作成している。
- RHCOS VMDK ファイルを Amazon S3 にアップロードしている。RHCOS VMDK ファイルは、インストールする OpenShift Container Platform のバージョンと同じか、それ以下のバージョンである必要があります。
- AWS CLI をダウンロードし、これをコンピューターにインストールしている。Install the AWS CLI Using the Bundled Installer を参照してください。
手順
AWS プロファイルを環境変数としてエクスポートします。
export AWS_PROFILE=<aws_profile>
$ export AWS_PROFILE=<aws_profile>1 Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
govcloudやbeijingadminなど、AWS の認証情報を格納する AWS プロファイル名。
カスタム AMI に関連付けるリージョンを環境変数としてエクスポートします。
export AWS_DEFAULT_REGION=<aws_region>
$ export AWS_DEFAULT_REGION=<aws_region>1 Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
us-gov-east-1やcn-north-1などの AWS リージョン。
環境変数として Amazon S3 にアップロードした RHCOS のバージョンをエクスポートします。
export RHCOS_VERSION=<version>
$ export RHCOS_VERSION=<version>1 Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
4.20.0などの RHCOS VMDK バージョン。
Amazon S3 バケット名を環境変数としてエクスポートします。
export VMIMPORT_BUCKET_NAME=<s3_bucket_name>
$ export VMIMPORT_BUCKET_NAME=<s3_bucket_name>Copy to Clipboard Copied! Toggle word wrap Toggle overflow containers.jsonファイルを作成し、RHCOS VMDK ファイルを定義します。Copy to Clipboard Copied! Toggle word wrap Toggle overflow RHCOS ディスクを Amazon EBS スナップショットとしてインポートします。
aws ec2 import-snapshot --region ${AWS_DEFAULT_REGION} \ --description "<description>" \ --disk-container "file://<file_path>/containers.json"$ aws ec2 import-snapshot --region ${AWS_DEFAULT_REGION} \ --description "<description>" \1 --disk-container "file://<file_path>/containers.json"2 Copy to Clipboard Copied! Toggle word wrap Toggle overflow イメージインポートのステータスを確認します。
watch -n 5 aws ec2 describe-import-snapshot-tasks --region ${AWS_DEFAULT_REGION}$ watch -n 5 aws ec2 describe-import-snapshot-tasks --region ${AWS_DEFAULT_REGION}Copy to Clipboard Copied! Toggle word wrap Toggle overflow 出力例
Copy to Clipboard Copied! Toggle word wrap Toggle overflow SnapshotIdをコピーして、イメージを登録します。RHCOS スナップショットからカスタム RHCOS AMI を作成します。
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
これらの API の詳細は、AWS ドキュメントの importing snapshots および creating EBS-backed AMIs を参照してください。
3.7.7. インストール設定ファイルの手動作成 リンクのコピーリンクがクリップボードにコピーされました!
クラスターをインストールするには、インストール設定ファイルを手動で作成する必要があります。
前提条件
- インストールプログラムで使用するための SSH 公開鍵がローカルマシン上に存在する。この鍵は、デバッグや障害復旧のために、クラスターノードへの SSH 認証に使用できます。
- OpenShift Container Platform インストールプログラムとクラスターのプルシークレットを取得している。
手順
必要なインストールアセットを保存するためのインストールディレクトリーを作成します。
mkdir <installation_directory>
$ mkdir <installation_directory>Copy to Clipboard Copied! Toggle word wrap Toggle overflow 重要このディレクトリーは必ず作成してください。ブートストラップ X.509 証明書などの一部のインストールアセットは、有効期限が短いため、インストールディレクトリーを再利用しないでください。別のクラスターインストールの個別のファイルを再利用する必要がある場合は、それらをディレクトリーにコピーすることができます。ただし、インストールアセットのファイル名はリリース間で変更される可能性があります。インストールファイルを以前のバージョンの OpenShift Container Platform からコピーする場合は注意してください。
提供されているサンプルの
install-config.yamlファイルテンプレートをカスタマイズし、ファイルを<installation_directory>に保存します。注記この設定ファイルの名前を
install-config.yamlと付ける必要があります。多くのクラスターのインストールに使用できるように、
install-config.yamlファイルをバックアップします。重要インストールプロセスの次のステップで
install-config.yamlファイルを使用するため、今すぐこのファイルをバックアップしてください。
3.7.7.1. AWS のカスタマイズされた install-config.yaml ファイルのサンプル リンクのコピーリンクがクリップボードにコピーされました!
インストール設定ファイル install-config.yaml をカスタマイズして、OpenShift Container Platform クラスターのプラットフォームに関する詳細を指定するか、必要なパラメーターの値を変更することができます。
このサンプルの YAML ファイルは参照用にのみ提供されます。インストールプログラムを使用して install-config.yaml ファイルを取得し、これを変更する必要があります。すべてのインストール設定パラメーターの完全なリストと説明は、AWS のインストール設定パラメーター を参照してください。
AWS のサンプル install-config.yaml ファイル
3.7.7.2. クラスターインストールの最小リソース要件 リンクのコピーリンクがクリップボードにコピーされました!
それぞれのクラスターマシンは、以下の最小要件を満たしている必要があります。
| マシン | オペレーティングシステム | 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 つの物理コアと同等です。これが有効にされている場合、(コアあたりのスレッド数 x コア数) x ソケット数 = 仮想 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.19 の場合、RHCOS は RHEL バージョン 9.6 に基づいています。これは、マイクロアーキテクチャー要件を更新します。次のリストには、各アーキテクチャーに必要な最小限の命令セットアーキテクチャー (ISA) が含まれています。
- x86-64 アーキテクチャーには x86-64-v2 ISA が必要
- ARM64 アーキテクチャーには ARMv8.0-A ISA が必要
- IBM Power アーキテクチャーには Power 9 ISA が必要
- s390x アーキテクチャーには z14 ISA が必要
詳細は、アーキテクチャー (RHEL ドキュメント) を参照してください。
プラットフォームのインスタンスタイプがクラスターマシンの最小要件を満たす場合、これは OpenShift Container Platform で使用することがサポートされます。
3.7.7.3. AWS のテスト済みインスタンスタイプ リンクのコピーリンクがクリップボードにコピーされました!
以下の Amazon Web Services (AWS) インスタンスタイプは OpenShift Container Platform でテストされています。
AWS インスタンスには、次の表に記載されているマシンタイプを使用してください。表に記載されていないインスタンスタイプを使用する場合は、使用するインスタンスサイズが、「クラスターインストールの最小リソース要件」セクションに記載されている最小リソース要件と一致していることを確認してください。
例3.8 64 ビット x86 アーキテクチャーに基づくマシンタイプ
-
c4.* -
c5.* -
c5a.* -
i3.* -
m4.* -
m5.* -
m5a.* -
m6a.* -
m6i.* -
r4.* -
r5.* -
r5a.* -
r6i.* -
t3.* -
t3a.*
3.7.7.4. 64 ビット ARM インフラストラクチャー上の AWS のテスト済みインスタンスタイプ リンクのコピーリンクがクリップボードにコピーされました!
次の Amazon Web Services (AWS) 64 ビット ARM インスタンスタイプは、OpenShift Container Platform でテストされています。
AWS ARM インスタンスには、次のチャートに含まれるマシンタイプを使用してください。チャートに記載されていないインスタンスタイプを使用する場合は、使用するインスタンスサイズが、「クラスターインストールの最小リソース要件」に記載されている最小リソース要件と一致していることを確認してください。
例3.9 64 ビット ARM アーキテクチャーに基づくマシンタイプ
-
c6g.* -
c7g.* -
m6g.* -
m7g.* -
r8g.*
3.7.7.5. インストール時のクラスター全体のプロキシーの設定 リンクのコピーリンクがクリップボードにコピーされました!
実稼働環境では、インターネットへの直接アクセスを拒否し、代わりに HTTP または HTTPS プロキシーを使用することができます。プロキシー設定を install-config.yaml ファイルで行うことにより、新規の OpenShift Container Platform クラスターをプロキシーを使用するように設定できます。
前提条件
-
既存の
install-config.yamlファイルがある。 クラスターがアクセスする必要のあるサイトを確認済みで、それらのいずれかがプロキシーをバイパスする必要があるかどうかを判別している。デフォルトで、すべてのクラスター Egress トラフィック (クラスターをホストするクラウドに関するクラウドプロバイダー API に対する呼び出しを含む) はプロキシーされます。プロキシーを必要に応じてバイパスするために、サイトを
Proxyオブジェクトのspec.noProxyフィールドに追加している。注記Proxyオブジェクトのstatus.noProxyフィールドには、インストール設定のnetworking.machineNetwork[].cidr、networking.clusterNetwork[].cidr、およびnetworking.serviceNetwork[]フィールドの値が設定されます。Amazon Web Services (AWS)、Google Cloud Platform (GCP)、Microsoft Azure、および Red Hat OpenStack Platform (RHOSP) へのインストールの場合、
Proxyオブジェクトのstatus.noProxyフィールドには、インスタンスメタデータのエンドポイント (169.254.169.254) も設定されます。
手順
install-config.yamlファイルを編集し、プロキシー設定を追加します。以下に例を示します。Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
- クラスター外の HTTP 接続を作成するために使用するプロキシー URL。URL スキームは
httpである必要があります。 - 2
- クラスター外で HTTPS 接続を作成するために使用するプロキシー URL。
- 3
- プロキシーから除外するための宛先ドメイン名、IP アドレス、または他のネットワーク CIDR のコンマ区切りのリスト。サブドメインのみと一致するように、ドメインの前に
.を付けます。たとえば、.y.comはx.y.comに一致しますが、y.comには一致しません。*を使用し、すべての宛先のプロキシーをバイパスします。AmazonEC2、Elastic Load Balancing、およびS3VPC エンドポイントを VPC に追加した場合は、これらのエンドポイントをnoProxyフィールドに追加する必要があります。 - 4
- 指定されている場合、インストールプログラムは HTTPS 接続のプロキシーに必要な 1 つ以上の追加の CA 証明書が含まれる
user-ca-bundleという名前の設定マップをopenshift-confignamespace に生成します。次に Cluster Network Operator は、これらのコンテンツを Red Hat Enterprise Linux CoreOS (RHCOS) 信頼バンドルにマージするtrusted-ca-bundleconfig map を作成し、この config map はProxyオブジェクトのtrustedCAフィールドで参照されます。additionalTrustBundleフィールドは、プロキシーのアイデンティティー証明書が RHCOS 信頼バンドルからの認証局によって署名されない限り必要になります。 - 5
- オプション:
trustedCAフィールドのuser-ca-bundle設定マップを参照するProxyオブジェクトの設定を決定するポリシー。許可される値はProxyonlyおよびAlwaysです。Proxyonlyを使用して、http/httpsプロキシーが設定されている場合にのみuser-ca-bundle設定マップを参照します。Alwaysを使用して、常にuser-ca-bundle設定マップを参照します。デフォルト値はProxyonlyです。
注記インストールプログラムは、プロキシーの
readinessEndpointsフィールドをサポートしません。注記インストーラーがタイムアウトした場合は、インストーラーの
wait-forコマンドを使用してデプロイメントを再起動してからデプロイメントを完了します。以下に例を示します。./openshift-install wait-for install-complete --log-level debug
$ ./openshift-install wait-for install-complete --log-level debugCopy to Clipboard Copied! Toggle word wrap Toggle overflow - ファイルを保存し、OpenShift Container Platform のインストール時にこれを参照します。
インストールプログラムは、指定の install-config.yaml ファイルのプロキシー設定を使用する cluster という名前のクラスター全体のプロキシーを作成します。プロキシー設定が指定されていない場合、cluster Proxy オブジェクトが依然として作成されますが、これには spec がありません。
cluster という名前の Proxy オブジェクトのみがサポートされ、追加のプロキシーを作成することはできません。
3.7.7.6. 既存の 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 ファイル
3.7.8. 管理者レベルのシークレットを kube-system プロジェクトに保存する代替方法 リンクのコピーリンクがクリップボードにコピーされました!
デフォルトでは、管理者のシークレットは kube-system プロジェクトに保存されます。install-config.yaml ファイルの credentialsMode パラメーターを Manual に設定した場合は、次のいずれかの代替手段を使用する必要があります。
- 長期クラウド認証情報を手動で管理するには、長期認証情報を手動で作成する の手順に従ってください。
- クラスターの外部で管理される短期認証情報を個々のコンポーネントに対して実装するには、短期認証情報を使用するように AWS クラスターを設定する の手順に従ってください。
3.7.8.1. 長期認証情報を手動で作成する リンクのコピーリンクがクリップボードにコピーされました!
Cloud Credential Operator (CCO) は、クラウドアイデンティティーおよびアクセス管理 (IAM) API に到達できない環境にインストールする前に手動モードに配置できます。管理者はクラスター kube-system namespace に管理者レベルの認証情報シークレットを保存しないようにします。
手順
install-config.yaml設定ファイルのcredentialsModeパラメーターをManualに設定しなかった場合は、次のように値を変更します。設定ファイルのサンプルスニペット
apiVersion: v1 baseDomain: example.com credentialsMode: Manual # ...
apiVersion: v1 baseDomain: example.com credentialsMode: Manual # ...Copy to Clipboard Copied! Toggle word wrap Toggle overflow インストールマニフェストファイルをまだ作成していない場合は、次のコマンドを実行して作成します。
openshift-install create manifests --dir <installation_directory>
$ openshift-install create manifests --dir <installation_directory>Copy to Clipboard Copied! Toggle word wrap Toggle overflow ここで、
<installation_directory>は、インストールプログラムがファイルを作成するディレクトリーに置き換えます。次のコマンドを実行して、インストールファイルのリリースイメージを
$RELEASE_IMAGE変数に設定します。RELEASE_IMAGE=$(./openshift-install version | awk '/release image/ {print $3}')$ RELEASE_IMAGE=$(./openshift-install version | awk '/release image/ {print $3}')Copy to Clipboard Copied! Toggle word wrap Toggle overflow 以下のコマンドを実行して、OpenShift Container Platform リリースイメージから
CredentialsRequestカスタムリソース (CR) のリストを抽出します。Copy to Clipboard Copied! Toggle word wrap Toggle overflow このコマンドにより、それぞれの
CredentialsRequestオブジェクトに YAML ファイルが作成されます。サンプル
CredentialsRequestオブジェクトCopy to Clipboard Copied! Toggle word wrap Toggle overflow 以前に生成した
openshift-installマニフェストディレクトリーにシークレットの YAML ファイルを作成します。シークレットは、それぞれのCredentialsRequestオブジェクトについてspec.secretRefに定義される namespace およびシークレット名を使用して保存する必要があります。シークレットを含む
CredentialsRequestオブジェクトのサンプルCopy to Clipboard Copied! Toggle word wrap Toggle overflow サンプル
SecretオブジェクトCopy to Clipboard Copied! Toggle word wrap Toggle overflow
手動でメンテナンスされる認証情報を使用するクラスターをアップグレードする前に、CCO がアップグレード可能な状態であることを確認します。
3.7.8.2. 短期認証情報を使用するように AWS クラスターを設定する リンクのコピーリンクがクリップボードにコピーされました!
AWS Security Token Service (STS) を使用するように設定されたクラスターをインストールするには、CCO ユーティリティーを設定し、クラスターに必要な AWS リソースを作成する必要があります。
3.7.8.2.1. Cloud Credential Operator ユーティリティーの設定 リンクのコピーリンクがクリップボードにコピーされました!
Cloud Credential Operator (CCO) が手動モードで動作しているときにクラスターの外部からクラウドクレデンシャルを作成および管理するには、CCO ユーティリティー (ccoctl) バイナリーを抽出して準備します。
ccoctl ユーティリティーは、Linux 環境で実行する必要がある Linux バイナリーです。
前提条件
- クラスター管理者のアクセスを持つ OpenShift Container Platform アカウントを使用できる。
-
OpenShift CLI (
oc) がインストールされている。
ccoctlユーティリティーで使用できるように、次の権限を持つ 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 アカウントには次の追加パーミッションが必要です。-
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}')$ RELEASE_IMAGE=$(./openshift-install version | awk '/release image/ {print $3}')Copy to Clipboard Copied! Toggle word wrap Toggle overflow 以下のコマンドを実行して、OpenShift Container Platform リリースイメージから CCO コンテナーイメージを取得します。
CCO_IMAGE=$(oc adm release info --image-for='cloud-credential-operator' $RELEASE_IMAGE -a ~/.pull-secret)
$ CCO_IMAGE=$(oc adm release info --image-for='cloud-credential-operator' $RELEASE_IMAGE -a ~/.pull-secret)Copy to Clipboard Copied! Toggle word wrap Toggle overflow 注記$RELEASE_IMAGEのアーキテクチャーが、ccoctlツールを使用する環境のアーキテクチャーと一致していることを確認してください。以下のコマンドを実行して、OpenShift Container Platform リリースイメージ内の CCO コンテナーイメージから
ccoctlバイナリーを抽出します。oc image extract $CCO_IMAGE \ --file="/usr/bin/ccoctl.<rhel_version>" \ -a ~/.pull-secret
$ oc image extract $CCO_IMAGE \ --file="/usr/bin/ccoctl.<rhel_version>" \1 -a ~/.pull-secretCopy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
<rhel_version>には、ホストが使用する Red Hat Enterprise Linux (RHEL) のバージョンに対応する値を指定します。値が指定されていない場合は、デフォルトでccoctl.rhel8が使用されます。次の値が有効です。-
rhel8: RHEL 8 を使用するホストの場合はこの値を指定します。 -
rhel9: RHEL 9 を使用するホストの場合はこの値を指定します。
-
次のコマンドを実行して、権限を変更して
ccoctlを実行可能にします。chmod 775 ccoctl.<rhel_version>
$ chmod 775 ccoctl.<rhel_version>Copy to Clipboard Copied! Toggle word wrap Toggle overflow
検証
ccoctlが使用できることを確認するには、help ファイルを表示します。コマンドを実行するときは、相対ファイル名を使用します。以下に例を示します。./ccoctl.rhel9
$ ./ccoctl.rhel9Copy to Clipboard Copied! Toggle word wrap Toggle overflow 出力例
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
3.7.8.2.2. Cloud Credential Operator ユーティリティーを使用した AWS リソースの作成 リンクのコピーリンクがクリップボードにコピーされました!
AWS リソースを作成するときは、次のオプションがあります。
-
ccoctl aws create-allコマンドを使用して AWS リソースを自動的に作成できます。これはリソースを作成する最も簡単な方法です。単一コマンドでの AWS リソースの作成 を参照してください。 -
AWS リソースの変更前に
ccoctlツールが作成する JSON ファイルを確認する必要がある場合や、ccoctlツールが AWS リソースを自動作成するために使用するプロセスが組織の要件を満たさない場合は、AWS リソースを個別に作成できます。AWS リソースの個別作成 を参照してください。
3.7.8.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}')$ RELEASE_IMAGE=$(./openshift-install version | awk '/release image/ {print $3}')Copy to Clipboard Copied! Toggle word wrap Toggle overflow 以下のコマンドを実行して、OpenShift Container Platform リリースイメージから
CredentialsRequestオブジェクトのリストを抽出します。Copy to Clipboard Copied! Toggle word wrap Toggle overflow 注記このコマンドの実行には少し時間がかかる場合があります。
次のコマンドを実行し、
ccoctlツールを使用してCredentialsRequestオブジェクトをすべて処理します。Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 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
$ ls <path_to_ccoctl_output_dir>/manifestsCopy to Clipboard Copied! Toggle word wrap Toggle overflow 出力例
Copy to Clipboard Copied! Toggle word wrap Toggle overflow AWS にクエリーを実行すると、IAM ロールが作成されていることを確認できます。詳細は AWS ドキュメントの IAM ロールの一覧表示を参照してください。
3.7.8.2.2.2. AWS リソースの個別作成 リンクのコピーリンクがクリップボードにコピーされました!
ccoctl ツールを使用して、AWS リソースを個別に作成できます。このオプションは、異なるユーザーや部門間でこれらのリソースを作成する責任を共有する組織に役に立ちます。
それ以外の場合は、ccoctl aws create-all コマンドを使用して AWS リソースを自動的に作成できます。詳細は、「単一コマンドによる AWS リソースの作成」を参照してください。
デフォルトで、ccoctl はコマンドが実行されるディレクトリーにオブジェクトを作成します。オブジェクトを別のディレクトリーに作成するには、--output-dir フラグを使用します。この手順では、<path_to_ccoctl_output_dir> を使用してこの場所を参照します。
一部の ccoctl コマンドは AWS API 呼び出しを行い、AWS リソースを作成または変更します。--dry-run フラグを使用して、API 呼び出しを回避できます。このフラグを使用すると、代わりにローカルファイルシステムに JSON ファイルが作成されます。JSON ファイルを確認して変更し、AWS CLI ツールで --cli-input-json パラメーターを使用して適用できます。
前提条件
-
ccoctlバイナリーを展開して準備しておく。
手順
次のコマンドを実行して、クラスターの OpenID Connect プロバイダーを設定するために使用されるパブリックおよびプライベート RSA キーファイルを生成します。
ccoctl aws create-key-pair
$ ccoctl aws create-key-pairCopy to Clipboard Copied! Toggle word wrap Toggle overflow 出力例
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
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 installerCopy to Clipboard Copied! Toggle word wrap Toggle overflow 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> \ --region=<aws_region> \ --public-key-file=<path_to_ccoctl_output_dir>/serviceaccount-signer.public
$ ccoctl aws create-identity-provider \ --name=<name> \1 --region=<aws_region> \2 --public-key-file=<path_to_ccoctl_output_dir>/serviceaccount-signer.public3 Copy to Clipboard Copied! Toggle word wrap Toggle overflow 出力例
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
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.comCopy to Clipboard Copied! Toggle word wrap Toggle overflow openid-configurationは検出ドキュメントであり、keys.jsonは JSON Web キーセットファイルです。このコマンドは、YAML 設定ファイルを
/<path_to_ccoctl_output_dir>/manifests/cluster-authentication-02-config.yamlにも作成します。このファイルは、AWS IAM アイデンティティープロバイダーがトークンを信頼するように、クラスターが生成するサービスアカウントトークンの発行側の URL フィールドを設定します。クラスターの各コンポーネントに IAM ロールを作成します。
次のコマンドを実行して、インストールファイルのリリースイメージを
$RELEASE_IMAGE変数に設定します。RELEASE_IMAGE=$(./openshift-install version | awk '/release image/ {print $3}')$ RELEASE_IMAGE=$(./openshift-install version | awk '/release image/ {print $3}')Copy to Clipboard Copied! Toggle word wrap Toggle overflow OpenShift Container Platform リリースイメージから
CredentialsRequestオブジェクトの一覧を抽出します。Copy to Clipboard Copied! Toggle word wrap Toggle overflow 次のコマンドを実行し、
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
$ 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.comCopy to Clipboard Copied! Toggle word wrap Toggle overflow 注記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
$ ls <path_to_ccoctl_output_dir>/manifestsCopy to Clipboard Copied! Toggle word wrap Toggle overflow 出力例
Copy to Clipboard Copied! Toggle word wrap Toggle overflow AWS にクエリーを実行すると、IAM ロールが作成されていることを確認できます。詳細は AWS ドキュメントの IAM ロールの一覧表示を参照してください。
3.7.8.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 # ...
apiVersion: v1 baseDomain: example.com credentialsMode: Manual # ...Copy to Clipboard Copied! Toggle word wrap Toggle overflow インストールマニフェストファイルをまだ作成していない場合は、次のコマンドを実行して作成します。
openshift-install create manifests --dir <installation_directory>
$ openshift-install create manifests --dir <installation_directory>Copy to Clipboard Copied! Toggle word wrap Toggle overflow ここで、
<installation_directory>は、インストールプログラムがファイルを作成するディレクトリーに置き換えます。次のコマンドを実行して、
ccoctlユーティリティーが生成したマニフェストを、インストールプログラムが作成したmanifestsディレクトリーにコピーします。cp /<path_to_ccoctl_output_dir>/manifests/* ./manifests/
$ cp /<path_to_ccoctl_output_dir>/manifests/* ./manifests/Copy to Clipboard Copied! Toggle word wrap Toggle overflow 秘密鍵を含む
tlsディレクトリーをインストールディレクトリーにコピーします。cp -a /<path_to_ccoctl_output_dir>/tls .
$ cp -a /<path_to_ccoctl_output_dir>/tls .Copy to Clipboard Copied! Toggle word wrap Toggle overflow
3.7.9. クラスターのデプロイ リンクのコピーリンクがクリップボードにコピーされました!
互換性のあるクラウドプラットフォームに OpenShift Container Platform をインストールできます。
インストールプログラムの create cluster コマンドは、初期インストール時に 1 回だけ実行できます。
前提条件
- クラスターをホストするクラウドプラットフォームでアカウントを設定した。
- OpenShift Container Platform インストールプログラムおよびクラスターのプルシークレットがある。
- ホスト上のクラウドプロバイダーアカウントに、クラスターをデプロイするための正しい権限があることを確認した。アカウントの権限が正しくないと、インストールプロセスが失敗し、不足している権限を示すエラーメッセージが表示されます。
手順
インストールプログラムが格納されているディレクトリーで、次のコマンドを実行して、クラスターのデプロイメントを初期化します。
./openshift-install create cluster --dir <installation_directory> \ --log-level=info$ ./openshift-install create cluster --dir <installation_directory> \1 --log-level=info2 Copy to Clipboard Copied! Toggle word wrap Toggle overflow オプション: クラスターのインストールに使用した IAM アカウントから
AdministratorAccessポリシーを削除するか、無効にします。注記AdministratorAccessポリシーが提供する昇格したパーミッションはインストール時にのみ必要です。
検証
クラスターのデプロイが正常に完了すると、次のようになります。
-
ターミナルには、Web コンソールへのリンクや
kubeadminユーザーの認証情報など、クラスターにアクセスするための指示が表示されます。 -
認証情報は
<installation_directory>/.openshift_install.logにも出力されます。
インストールプログラム、またはインストールプログラムが作成するファイルを削除することはできません。これらはいずれもクラスターを削除するために必要になります。
出力例
-
インストールプログラムが生成する Ignition 設定ファイルには、24 時間が経過すると期限切れになり、その後に更新される証明書が含まれます。証明書を更新する前にクラスターが停止し、24 時間経過した後にクラスターを再起動すると、クラスターは期限切れの証明書を自動的に復元します。例外として、kubelet 証明書を回復するために保留状態の
node-bootstrapper証明書署名要求 (CSR) を手動で承認する必要があります。詳細は、コントロールプレーン証明書の期限切れの状態からのリカバリー に関するドキュメントを参照してください。 - 24 時間証明書はクラスターのインストール後 16 時間から 22 時間にローテーションするため、Ignition 設定ファイルは、生成後 12 時間以内に使用することを推奨します。12 時間以内に Ignition 設定ファイルを使用することにより、インストール中に証明書の更新が実行された場合のインストールの失敗を回避できます。
3.7.10. CLI の使用によるクラスターへのログイン リンクのコピーリンクがクリップボードにコピーされました!
クラスター kubeconfig ファイルをエクスポートし、デフォルトシステムユーザーとしてクラスターにログインできます。kubeconfig ファイルには、クライアントを正しいクラスターおよび API サーバーに接続するために CLI で使用されるクラスターに関する情報が含まれます。このファイルはクラスターに固有のファイルであり、OpenShift Container Platform のインストール時に作成されます。
前提条件
- OpenShift Container Platform クラスターをデプロイしていること。
-
OpenShift CLI (
oc) がインストールされている。
手順
次のコマンドを実行して、
kubeadmin認証情報をエクスポートします。export KUBECONFIG=<installation_directory>/auth/kubeconfig
$ export KUBECONFIG=<installation_directory>/auth/kubeconfig1 Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
<installation_directory>には、インストールファイルを保存したディレクトリーへのパスを指定します。
次のコマンドを実行し、エクスポートされた設定を使用して
ocコマンドを正常に実行できることを確認します。oc whoami
$ oc whoamiCopy to Clipboard Copied! Toggle word wrap Toggle overflow 出力例
system:admin
system:adminCopy to Clipboard Copied! Toggle word wrap Toggle overflow
3.7.11. Web コンソールを使用したクラスターへのログイン リンクのコピーリンクがクリップボードにコピーされました!
kubeadmin ユーザーは、OpenShift Container Platform のインストール後はデフォルトで存在します。OpenShift Container Platform Web コンソールを使用し、kubeadmin ユーザーとしてクラスターにログインできます。
前提条件
- インストールホストにアクセスできる。
- クラスターのインストールを完了しており、すべてのクラスター Operator が利用可能である。
手順
インストールホストで
kubeadmin-passwordファイルからkubeadminユーザーのパスワードを取得します。cat <installation_directory>/auth/kubeadmin-password
$ cat <installation_directory>/auth/kubeadmin-passwordCopy to Clipboard Copied! Toggle word wrap Toggle overflow 注記または、インストールホストで
<installation_directory>/.openshift_install.logログファイルからkubeadminパスワードを取得できます。OpenShift Container Platform Web コンソールルートをリスト表示します。
oc get routes -n openshift-console | grep 'console-openshift'
$ oc get routes -n openshift-console | grep 'console-openshift'Copy to Clipboard Copied! Toggle word wrap Toggle overflow 注記または、インストールホストで
<installation_directory>/.openshift_install.logログファイルからで OpenShift Container Platform ルートを取得できます。出力例
console console-openshift-console.apps.<cluster_name>.<base_domain> console https reencrypt/Redirect None
console console-openshift-console.apps.<cluster_name>.<base_domain> console https reencrypt/Redirect NoneCopy to Clipboard Copied! Toggle word wrap Toggle overflow -
Web ブラウザーで前述のコマンドの出力で詳細に説明されたルートに移動し、
kubeadminユーザーとしてログインします。
3.7.12. 次のステップ リンクのコピーリンクがクリップボードにコピーされました!
- インストールの検証
- クラスターのカスタマイズ
- 必要に応じて、リモートヘルスレポート を作成できます。
- 必要に応じて、クラウドプロバイダーの認証情報を削除 できます。