3.8. AWS の government リージョンへのクラスターのインストール
OpenShift Container Platform バージョン 4.17 では、Amazon Web Services (AWS) 上のクラスターを government リージョンにインストールできます。リージョンを設定するには、クラスターをインストールする前に、install-config.yaml
ファイルでパラメーターを変更します。
3.8.1. 前提条件
- OpenShift Container Platform のインストールおよび更新 プロセスの詳細を確認した。
- クラスターインストール方法の選択およびそのユーザー向けの準備 を確認した。
クラスターをホストするために AWS アカウントを設定 している。
重要AWS プロファイルがご使用のコンピューターに保存されている場合、マルチファクター認証デバイスを使用中に生成した一時的なセッショントークンを使用することはできません。クラスターは継続的に現行の AWS 認証情報を使用して、クラスターの有効期間全体にわたって AWS リソースを作成するため、有効期間の長い認証情報を使用する必要があります。適切なキーを生成するには、AWS ドキュメントの Managing Access Keys for IAM Users を参照してください。キーは、インストールプログラムの実行時に指定できます。
- ファイアウォールを使用する場合は、クラスターがアクセスを必要とするサイトを許可するようにファイアウォールを設定する必要がある。
3.8.2. AWS government リージョン
OpenShift Container Platform は、AWS GovCloud (US) リージョンへのクラスターのデプロイをサポートします。
以下の AWS GovCloud パーティションがサポートされます。
-
us-gov-east-1
-
us-gov-west-1
3.8.3. インストール要件
クラスターをインストールする前に、以下を行う必要があります。
クラスターをホストするために、既存のプライベート AWS VPC とサブネットを提供します。
パブリックゾーンは、AWS GovCloud の Route 53 ではサポートされません。その結果、AWS government リージョンにデプロイする場合、クラスターはプライベートである必要があります。
-
インストール設定ファイル (
install-config.yaml
) を手動で作成します。
3.8.4. プライベートクラスター
外部エンドポイントを公開しないプライベート OpenShift Container Platform クラスターをデプロイすることができます。プライベートクラスターは内部ネットワークからのみアクセスでき、インターネット上では表示されません。
パブリックゾーンは、AWS GovCloud リージョンの Route 53 ではサポートされていません。したがって、クラスターを AWS GovCloud リージョンにデプロイする場合は、クラスターをプライベートにする必要があります。
デフォルトで、OpenShift Container Platform はパブリックにアクセス可能な DNS およびエンドポイントを使用できるようにプロビジョニングされます。プライベートクラスターは、クラスターのデプロイ時に DNS、Ingress コントローラー、および API サーバーを private に設定します。つまり、クラスターリソースは内部ネットワークからのみアクセスでき、インターネット上では表示されません。
クラスターにパブリックサブネットがある場合、管理者により作成されたロードバランサーサービスはパブリックにアクセスできる可能性があります。クラスターのセキュリティーを確保するには、これらのサービスに明示的にプライベートアノテーションが付けられていることを確認してください。
プライベートクラスターをデプロイするには、以下を行う必要があります。
- 要件を満たす既存のネットワークを使用します。クラスターリソースはネットワーク上の他のクラスター間で共有される可能性があります。
以下にアクセスできるマシンからデプロイ。
- プロビジョニングするクラウドの API サービス。
- プロビジョニングするネットワーク上のホスト。
- インストールメディアを取得するインターネット。
これらのアクセス要件を満たし、所属する会社のガイドラインに準拠したすべてのマシンを使用することができます。たとえば、このマシンには、クラウドネットワーク上の bastion ホスト、または VPN 経由でネットワークにアクセスできるマシンを使用できます。
3.8.4.1. AWS のプライベートクラスター
Amazon Web Services (AWS) でプライベートクラスターを作成するには、クラスターをホストするために既存のプライベート VPC およびサブネットを指定する必要があります。インストールプログラムは、クラスターが必要とする DNS レコードを解決できる必要もあります。インストールプログラムは、プライベートネットワークからのみアクセスできるように Ingress Operator および API サーバーを設定します。
クラスターには、引き続き AWS API にアクセスするためにインターネットへのアクセスが必要になります。
以下のアイテムは、プライベートクラスターのインストール時に必要ではなく、作成されません。
- パブリックサブネット
- パブリック Ingress をサポートするパブリックロードバランサー
-
クラスターの
baseDomain
に一致するパブリック Route 53 ゾーン
インストールプログラムは、プライベート Route 53 ゾーンを作成するために指定する baseDomain
とクラスターに必要なレコードを使用します。クラスターは、Operator がクラスターのパブリックレコードを作成せず、すべてのクラスターマシンが指定するプライベートサブネットに配置されるように設定されます。
3.8.4.1.1. 制限事項
プライベートクラスターにパブリック機能を追加する機能には制限があります。
- Kubernetes API エンドポイントは、追加のアクションを実行せずにインストールする場合はパブリックにすることができません。これらのアクションには、使用中のアベイラビリティーゾーンごとに VPC でパブリックサブネットやパブリックのロードバランサーを作成することや、6443 のインターネットからのトラフィックを許可するようにコントロールプレーンのセキュリティーグループを設定することなどが含まれます。
-
パブリックのサービスタイプのロードバランサーを使用する場合には、各アベイラビリティーゾーンのパブリックサブネットに
kubernetes.io/cluster/<cluster-infra-id>: shared
のタグを付け、AWS がそれらを使用してパブリックロードバランサーを作成できるようにします。
3.8.5. カスタム VPC の使用について
OpenShift Container Platform 4.17 では、Amazon Web Services (AWS) の既存の Amazon Virtual Private Cloud (VPC) における既存サブネットにクラスターをデプロイできます。OpenShift Container Platform を既存の AWS VPC にデプロイすると、新規アカウントの制限を回避したり、会社のガイドラインによる運用上の制約をより容易に遵守することが可能になる場合があります。VPC を作成するために必要なインフラストラクチャーの作成パーミッションを取得できない場合は、このインストールオプションを使用します。
インストールプログラムは既存のサブネットにある他のコンポーネントを把握できないため、ユーザーの代わりにサブネットの CIDR を選択することはできません。クラスターをインストールするサブネットのネットワークを独自に設定する必要があります。
3.8.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
認証情報モードを使用する必要があります。
非接続環境で作業している場合、EC2、ELB、および S3 エンドポイントのパブリック IP アドレスに到達することはできません。インストール中にインターネットトラフィックを制限するレベルに応じて、次の設定オプションを使用できます。
オプション 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 |
| 使用するクラスターのパブリック VPC を指定する必要があります。VPC は、各サブネットのルートテーブルを参照するエンドポイントを使用して、S3 でホストされているレジストリーとの通信を強化します。 | |
パブリックサブネット |
| VPC には 1 から 3 のアベイラビリティーゾーンのパブリックサブネットが必要であり、それらを適切な Ingress ルールに関連付ける必要があります。 | |
インターネットゲートウェイ |
| VPC に割り当てられたパブリックルートを持つパブリックインターネットゲートウェイが必要です。提供されるテンプレートでは、各パブリックサブネットに EIP アドレスと NAT ゲートウェイがあります。これらの NAT ゲートウェイは、プライベートサブネットインスタンスなどのクラスターリソースがインターネットに到達できるようにするもので、一部のネットワークが制限された環境またはプロキシーのシナリオでは必要ありません。 | |
ネットワークアクセス制御 |
| VPC が以下のポートにアクセスできるようにする必要があります。 | |
ポート | 理由 | ||
| インバウンド HTTP トラフィック | ||
| インバウンド HTTPS トラフィック | ||
| インバウンド SSH トラフィック | ||
| インバウンド一時 (ephemeral) トラフィック | ||
| アウトバウンド一時 (ephemeral) トラフィック | ||
プライベートサブネット |
| VPC にはプライベートサブネットを使用できます。提供される CloudFormation テンプレートは 1 から 3 アベイラビリティーゾーンのプライベートサブネットを作成できます。プライベートサブネットを使用できる場合は、それらの適切なルートおよびテーブルを指定する必要があります。 |
3.8.5.2. VPC 検証
指定するサブネットが適切であることを確認するには、インストールプログラムが以下のデータを確認します。
- 指定したサブネットすべてが存在します。
- プライベートサブネットを指定します。
- サブネットの CIDR は指定されたマシン CIDR に属します。
- 各アベイラビリティーゾーンのサブネットを指定します。それぞれのアベイラビリティーゾーンには、複数のパブリックおよびプライベートサブネットがありません。プライベートクラスターを使用する場合、各アベイラビリティーゾーンのプライベートサブネットのみを指定します。それ以外の場合は、各アベイラビリティーゾーンのパブリックサブネットおよびプライベートサブネットを指定します。
- 各プライベートサブネットアベイラビリティーゾーンのパブリックサブネットを指定します。マシンは、プライベートサブネットを指定しないアベイラビリティーゾーンにはプロビジョニングされません。
既存の VPC を使用するクラスターを破棄しても、VPC は削除されません。VPC から OpenShift Container Platform クラスターを削除する場合、kubernetes.io/cluster/.*: shared
タグは、それが使用したサブネットから削除されます。
3.8.5.3. パーミッションの区分
OpenShift Container Platform 4.3 以降、クラスターのデプロイに、インストールプログラムがプロビジョニングするインフラストラクチャークラスターに必要なすべてのパーミッションを必要としなくなりました。この変更は、ある会社で個人がクラウドで他とは異なるリソースを作成できるようにパーミッションが区分された状態に類似するものです。たとえば、インスタンス、バケット、ロードバランサーなどのアプリケーション固有のアイテムを作成することはできますが、VPC、サブネット、または Ingress ルールなどのネットワーク関連のコンポーネントは作成できない可能性があります。
クラスターの作成時に使用する AWS の認証情報には、VPC、およびサブネット、ルーティングテーブル、インターネットゲートウェイ、NAT、VPN などの VPC 内のコアとなるネットワークコンポーネントの作成に必要なネットワークのパーミッションは必要ありません。ELB、セキュリティーグループ、S3 バケットおよびノードなどの、クラスター内でマシンに必要なアプリケーションリソースを作成するパーミッションは依然として必要になります。
3.8.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.8.5.5. オプション: AWS セキュリティーグループ
デフォルトでは、インストールプログラムは、セキュリティーグループを作成し、コントロールプレーンとコンピュートマシンに接続します。デフォルトのセキュリティーグループに関連付けられたルールは変更できません。
ただし、既存の VPC に関連付けられている追加の既存の AWS セキュリティーグループをコントロールプレーンとコンピュートマシンに適用できます。カスタムセキュリティーグループを適用すると、これらのマシンの受信トラフィックまたは送信トラフィックを制御する必要がある場合に、組織のセキュリティーニーズを満たすことができます。
インストールプロセスの一環として、クラスターをデプロイする前に install-config.yaml
ファイルを変更してカスタムセキュリティーグループを適用します。
詳細は、「既存の AWS セキュリティーグループのクラスターへの適用」を参照してください。
3.8.6. AWS Marketplace イメージの取得
AWS Marketplace イメージを使用して OpenShift Container Platform クラスターをデプロイする場合は、最初に AWS を通じてサブスクライブする必要があります。オファーにサブスクライブすると、インストールプログラムがコンピュートノードのデプロイに使用する AMI ID が提供されます。
前提条件
- オファーを購入するための AWS アカウントを持っている。このアカウントは、クラスターのインストールに使用されるアカウントと同じである必要はありません。
手順
- AWS Marketplace で OpenShift Container Platform サブスクリプションを完了します。
ご使用の AWS リージョンの AMI ID を記録します。インストールプロセスの一環として、クラスターをデプロイする前に、この値で
install-config.yaml
ファイルを更新する必要があります。AWS Marketplace コンピュートノードを含む
install-config.yaml
ファイルのサンプルapiVersion: v1 baseDomain: example.com compute: - hyperthreading: Enabled name: worker platform: aws: amiID: ami-06c4d345f7c207239 1 type: m5.4xlarge replicas: 3 metadata: name: test-cluster platform: aws: region: us-east-2 2 sshKey: ssh-ed25519 AAAA... pullSecret: '{"auths": ...}'
3.8.7. インストール設定ファイルの手動作成
クラスターをインストールするには、インストール設定ファイルを手動で作成する必要があります。
前提条件
- ローカルマシンには、インストールプログラムに提供する SSH 公開鍵があります。このキーは、デバッグおよび障害復旧のためにクラスターノードへの SSH 認証に使用されます。
- OpenShift Container Platform インストールプログラムおよびクラスターのプルシークレットを取得しています。
手順
必要なインストールアセットを保存するためのインストールディレクトリーを作成します。
$ mkdir <installation_directory>
重要ディレクトリーを作成する必要があります。ブートストラップ X.509 証明書などの一部のインストールアセットの有効期限は短く設定されているため、インストールディレクトリーを再利用することができません。別のクラスターインストールの個別のファイルを再利用する必要がある場合は、それらをディレクトリーにコピーすることができます。ただし、インストールアセットのファイル名はリリース間で変更される可能性があります。インストールファイルを以前のバージョンの OpenShift Container Platform からコピーする場合は注意してコピーを行ってください。
提供されるサンプルの
install-config.yaml
ファイルテンプレートをカスタマイズし、これを<installation_directory>
に保存します。注記この設定ファイルの名前を
install-config.yaml
と付ける必要があります。install-config.yaml
ファイルをバックアップし、複数のクラスターをインストールするのに使用できるようにします。重要install-config.yaml
ファイルは、インストールプロセスの次の手順で使用されます。この時点でこれをバックアップする必要があります。
関連情報
3.8.7.1. クラスターインストールの最小リソース要件
それぞれのクラスターマシンは、以下の最小要件を満たしている必要があります。
マシン | オペレーティングシステム | 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 で使用することがサポートされます。
関連情報
3.8.7.2. AWS のテスト済みインスタンスタイプ
以下の Amazon Web Services (AWS) インスタンスタイプは OpenShift Container Platform でテストされています。
AWS インスタンスには、次の表に記載されているマシンタイプを使用してください。表に記載されていないインスタンスタイプを使用する場合は、使用するインスタンスサイズが、「クラスターインストールの最小リソース要件」セクションに記載されている最小リソース要件と一致していることを確認してください。
例3.20 64 ビット x86 アーキテクチャーに基づくマシンタイプ
-
c4.*
-
c5.*
-
c5a.*
-
i3.*
-
m4.*
-
m5.*
-
m5a.*
-
m6a.*
-
m6i.*
-
r4.*
-
r5.*
-
r5a.*
-
r6i.*
-
t3.*
-
t3a.*
3.8.7.3. 64 ビット ARM インフラストラクチャー上の AWS のテスト済みインスタンスタイプ
次の Amazon Web Services (AWS) 64 ビット ARM インスタンスタイプは、OpenShift Container Platform でテストされています。
AWS ARM インスタンスには、次のチャートに含まれるマシンタイプを使用してください。チャートに記載されていないインスタンスタイプを使用する場合は、使用するインスタンスサイズが、「クラスターインストールの最小リソース要件」に記載されている最小リソース要件と一致していることを確認してください。
例3.21 64 ビット ARM アーキテクチャーに基づくマシンタイプ
-
c6g.*
-
c7g.*
-
m6g.*
-
m7g.*
-
r8g.*
3.8.7.4. AWS のカスタマイズされた install-config.yaml ファイルのサンプル
インストール設定ファイル install-config.yaml
をカスタマイズして、OpenShift Container Platform クラスターのプラットフォームに関する詳細を指定するか、必要なパラメーターの値を変更することができます。
このサンプルの YAML ファイルは参照用にのみ提供されます。これを使用して、手動で作成したインストール設定ファイルにパラメーター値を入力します。
apiVersion: v1 baseDomain: example.com 1 credentialsMode: Mint 2 controlPlane: 3 4 hyperthreading: Enabled 5 name: master platform: aws: zones: - us-gov-west-1a - us-gov-west-1b rootVolume: iops: 4000 size: 500 type: io1 6 metadataService: authentication: Optional 7 type: m6i.xlarge replicas: 3 compute: 8 - hyperthreading: Enabled 9 name: worker platform: aws: rootVolume: iops: 2000 size: 500 type: io1 10 metadataService: authentication: Optional 11 type: c5.4xlarge zones: - us-gov-west-1c replicas: 3 metadata: name: test-cluster 12 networking: clusterNetwork: - cidr: 10.128.0.0/14 hostPrefix: 23 machineNetwork: - cidr: 10.0.0.0/16 networkType: OVNKubernetes 13 serviceNetwork: - 172.30.0.0/16 platform: aws: region: us-gov-west-1 14 propagateUserTags: true 15 userTags: adminContact: jdoe costCenter: 7536 subnets: 16 - subnet-1 - subnet-2 - subnet-3 amiID: ami-0c5d3e03c0ab9b19a 17 serviceEndpoints: 18 - name: ec2 url: https://vpce-id.ec2.us-west-2.vpce.amazonaws.com hostedZone: Z3URY6TWQ91KVV 19 fips: false 20 sshKey: ssh-ed25519 AAAA... 21 publish: Internal 22 pullSecret: '{"auths": ...}' 23
- 1 12 14 23
- 必須。
- 2
- オプション: Cloud Credential Operator (CCO) に指定されたモードの使用を強制するには、このパラメーターを追加します。デフォルトでは、CCO は
kube-system
namespace のルート認証情報を使用して、認証情報の機能を動的に判断しようとします。CCO モードの詳細は、認証および認可 ガイドの「Cloud Credential Operator について」セクションを参照してください。 - 3 8 15
- これらのパラメーターおよび値を指定しない場合、インストールプログラムはデフォルトの値を指定します。
- 4
controlPlane
セクションは単一マッピングですが、compute
セクションはマッピングのシーケンスになります。複数の異なるデータ構造の要件を満たすには、compute
セクションの最初の行はハイフン-
で始め、controlPlane
セクションの最初の行はハイフンで始めることができません。1 つのコントロールプレーンプールのみが使用されます。- 5 9
- 同時マルチスレッドまたは
hyperthreading
を有効/無効にするかどうか。デフォルトでは、同時スレッドはマシンのコアのパフォーマンスを上げるために有効にされます。パラメーター値をDisabled
に設定するとこれを無効にすることができます。一部のクラスターマシンで同時マルチスレッドを無効にする場合は、これをすべてのクラスターマシンで無効にする必要があります。重要同時スレッドを無効にする場合は、容量計画においてマシンパフォーマンスの大幅な低下が考慮に入れられていることを確認します。同時マルチスレッドを無効にする場合は、マシンに対して
m4.2xlarge
またはm5.2xlarge
などの大規模なインスタンスタイプを使用します。 - 6 10
- 大規模なクラスターの場合などに etcd の高速のストレージを設定するには、ストレージタイプを
io1
として設定し、iops
を2000
に設定します。 - 7 11
- Amazon EC2 Instance Metadata Service v2 (IMDSv2) を要求するかどうか。IMDSv2 を要求するには、パラメーター値を
Required
に設定します。IMDSv1 と IMDSv2 の両方の使用を許可するには、パラメーター値をOptional
に設定します。値が指定されていない場合、IMDSv1 と IMDSv2 の両方が許可されます。注記クラスターのインストール中に設定されるコントロールプレーンマシンの IMDS 設定は、AWS CLI を使用してのみ変更できます。コンピュートマシンの IMDS 設定は、コンピュートマシンセットを使用して変更できます。
- 13
- インストールするクラスターネットワークプラグイン。サポートされる値はデフォルト値の
OVNKubernetes
のみです。 - 16
- 独自の VPC を指定する場合は、クラスターが使用する各アベイラビリティーゾーンのサブネットを指定します。
- 17
- クラスターのマシンを起動するために使用される AMI の ID。これが設定されている場合、AMI はクラスターと同じリージョンに属する必要があります。
- 18
- AWS サービスエンドポイント。未確認の AWS リージョンにインストールする場合は、カスタムエンドポイントが必要です。エンドポイントの URL は
https
プロトコルを使用しなければならず、ホストは証明書を信頼する必要があります。 - 19
- 既存の Route 53 プライベートホストゾーンの ID。既存のホストゾーンを指定するには、独自の VPC を指定する必要があり、ホストゾーンはすでにクラスターをインストールする前に VPC に関連付けられます。定義されていない場合は、インストールプログラムは新規のホストゾーンを作成します。
- 20
- FIPS モードを有効または無効にするかどうか。デフォルトでは、FIPS モードは有効にされません。FIPS モードが有効にされている場合、OpenShift Container Platform が実行される Red Hat Enterprise Linux CoreOS (RHCOS) マシンがデフォルトの Kubernetes 暗号スイートをバイパスし、代わりに RHCOS で提供される暗号モジュールを使用します。重要
クラスターで FIPS モードを有効にするには、FIPS モードで動作するように設定された Red Hat Enterprise Linux (RHEL) コンピューターからインストールプログラムを実行する必要があります。RHEL で FIPS モードを設定する方法の詳細は、RHEL から FIPS モードへの切り替え を参照してください。
FIPS モードでブートされた Red Hat Enterprise Linux (RHEL) または Red Hat Enterprise Linux CoreOS (RHCOS) を実行する場合、OpenShift Container Platform コアコンポーネントは、x86_64、ppc64le、および s390x アーキテクチャーのみで、FIPS 140-2/140-3 検証のために NIST に提出された RHEL 暗号化ライブラリーを使用します。
- 21
- クラスター内のマシンにアクセスするために使用する
sshKey
値をオプションで指定できます。注記インストールのデバッグまたは障害復旧を実行する必要のある実稼働用の OpenShift Container Platform クラスターでは、
ssh-agent
プロセスが使用する SSH キーを指定します。 - 22
- クラスターのユーザーに表示されるエンドポイントをパブリッシュする方法。プライベートクラスターをデプロイするには、
publish
をInternal
に設定します。これはインターネットからアクセスできません。デフォルト値はExternal
です。
3.8.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
ファイルを編集し、プロキシー設定を追加します。以下に例を示します。apiVersion: v1 baseDomain: my.domain.com proxy: httpProxy: http://<username>:<pswd>@<ip>:<port> 1 httpsProxy: https://<username>:<pswd>@<ip>:<port> 2 noProxy: ec2.<aws_region>.amazonaws.com,elasticloadbalancing.<aws_region>.amazonaws.com,s3.<aws_region>.amazonaws.com 3 additionalTrustBundle: | 4 -----BEGIN CERTIFICATE----- <MY_TRUSTED_CA_CERT> -----END CERTIFICATE----- additionalTrustBundlePolicy: <policy_to_add_additionalTrustBundle> 5
- 1
- クラスター外の HTTP 接続を作成するために使用するプロキシー URL。URL スキームは
http
である必要があります。 - 2
- クラスター外で HTTPS 接続を作成するために使用するプロキシー URL。
- 3
- プロキシーから除外するための宛先ドメイン名、IP アドレス、または他のネットワーク CIDR のコンマ区切りのリスト。サブドメインのみと一致するように、ドメインの前に
.
を付けます。たとえば、.y.com
はx.y.com
に一致しますが、y.com
には一致しません。*
を使用し、すべての宛先のプロキシーをバイパスします。AmazonEC2
、Elastic Load Balancing
、およびS3
VPC エンドポイントを VPC に追加した場合は、これらのエンドポイントをnoProxy
フィールドに追加する必要があります。 - 4
- 指定されている場合、インストールプログラムは HTTPS 接続のプロキシーに必要な 1 つ以上の追加の CA 証明書が含まれる
user-ca-bundle
という名前の設定マップをopenshift-config
namespace に生成します。次に Cluster Network Operator は、これらのコンテンツを Red Hat Enterprise Linux CoreOS (RHCOS) 信頼バンドルにマージするtrusted-ca-bundle
設定マップを作成し、この設定マップは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 Container Platform のインストール時にこれを参照します。
インストールプログラムは、指定の install-config.yaml
ファイルのプロキシー設定を使用する cluster
という名前のクラスター全体のプロキシーを作成します。プロキシー設定が指定されていない場合、cluster
Proxy
オブジェクトが依然として作成されますが、これには spec
がありません。
cluster
という名前の Proxy
オブジェクトのみがサポートされ、追加のプロキシーを作成することはできません。
3.8.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
ファイル
# ... 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
3.8.8. 管理者レベルのシークレットを kube-system プロジェクトに保存する代替方法
デフォルトでは、管理者のシークレットは kube-system
プロジェクトに保存されます。install-config.yaml
ファイルの credentialsMode
パラメーターを Manual
に設定した場合は、次のいずれかの代替手段を使用する必要があります。
- 長期クラウド認証情報を手動で管理するには、長期認証情報を手動で作成する の手順に従ってください。
- 個々のコンポーネントのクラスター外部で管理される短期認証情報を実装するには、Cloud Credential Operator ユーティリティーマニフェストの組み込み に記載された手順に従います。
3.8.8.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
このコマンドにより、それぞれの
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 がアップグレード可能な状態であることを確認します。
3.8.8.2. 短期認証情報を使用するように AWS クラスターを設定
AWS Security Token Service (STS) を使用するように設定されたクラスターをインストールするには、CCO ユーティリティーを設定し、クラスターに必要な AWS リソースを作成する必要があります。
3.8.8.2.1. Cloud Credential Operator ユーティリティーの設定
Cloud Credential Operator (CCO) が手動モードで動作しているときにクラスターの外部からクラウドクレデンシャルを作成および管理するには、CCO ユーティリティー (ccoctl
) バイナリーを抽出して準備します。
ccoctl
ユーティリティーは、Linux 環境で実行する必要がある Linux バイナリーです。
前提条件
- クラスター管理者のアクセスを持つ OpenShift Container Platform アカウントを使用できる。
-
OpenShift CLI (
oc
) がインストールされている。
ccoctl
ユーティリティー用の AWS アカウントを作成し、次の権限で使用できるようにしました。例3.22 必要な 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 アカウントには次の追加パーミッションが必要です。例3.23 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.<rhel_version>" \1 -a ~/.pull-secret
- 1
<rhel_version>
には、ホストが使用する Red Hat Enterprise Linux (RHEL) のバージョンに対応する値を指定します。値が指定されていない場合は、デフォルトでccoctl.rhel8
が使用されます。次の値が有効です。-
rhel8
: RHEL 8 を使用するホストの場合はこの値を指定します。 -
rhel9
: RHEL 9 を使用するホストの場合はこの値を指定します。
-
次のコマンドを実行して、権限を変更して
ccoctl
を実行可能にします。$ chmod 775 ccoctl.<rhel_version>
検証
ccoctl
が使用できることを確認するには、help ファイルを表示します。コマンドを実行するときは、相対ファイル名を使用します。以下に例を示します。$ ./ccoctl.rhel9
出力例
OpenShift credentials provisioning tool Usage: ccoctl [command] Available Commands: 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-title} nutanix Manage credentials objects for Nutanix Flags: -h, --help help for ccoctl Use "ccoctl [command] --help" for more information about a command.
3.8.8.2.2. Cloud Credential Operator ユーティリティーを使用した AWS リソースの作成
AWS リソースを作成するときは、次のオプションがあります。
-
ccoctl aws create-all
コマンドを使用して AWS リソースを自動的に作成できます。これはリソースを作成する最も簡単な方法です。単一コマンドでの AWS リソースの作成 を参照してください。 -
AWS リソースの変更前に
ccoctl
ツールが作成する JSON ファイルを確認する必要がある場合や、ccoctl
ツールが AWS リソースを自動作成するために使用するプロセスが組織の要件を満たさない場合は、AWS リソースを個別に作成できます。AWS リソースの個別の作成 を参照してください。
3.8.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}')
以下のコマンドを実行して、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
注記このコマンドの実行には少し時間がかかる場合があります。
次のコマンドを実行し、
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 ロールの一覧表示を参照してください。
3.8.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
出力例
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
出力例
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 ロールを作成します。
次のコマンドを実行して、インストールファイルのリリースイメージを
$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
次のコマンドを実行し、
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
AWS にクエリーを実行すると、IAM ロールが作成されていることを確認できます。詳細は AWS ドキュメントの IAM ロールの一覧表示を参照してください。
3.8.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 # ...
インストールマニフェストファイルをまだ作成していない場合は、次のコマンドを実行して作成します。
$ 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 .
3.8.9. クラスターのデプロイ
互換性のあるクラウドプラットフォームに OpenShift Container Platform をインストールできます。
インストールプログラムの create cluster
コマンドは、初期インストール時に 1 回だけ実行できます。
前提条件
- クラスターをホストするクラウドプラットフォームでアカウントを設定しました。
- OpenShift Container Platform インストールプログラムおよびクラスターのプルシークレットがある。
- ホスト上のクラウドプロバイダーアカウントに、クラスターをデプロイするための適切な権限があることが確認されました。アカウントの権限が正しくないと、インストールプロセスが失敗し、不足している権限を示すエラーメッセージが表示されます。
手順
インストールプログラムが含まれるディレクトリーに切り替え、クラスターのデプロイメントを初期化します。
$ ./openshift-install create cluster --dir <installation_directory> \ 1 --log-level=info 2
オプション: クラスターのインストールに使用した 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 設定ファイルを使用することにより、インストール中に証明書の更新が実行された場合のインストールの失敗を回避できます。
3.8.10. 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
3.8.11. 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
ユーザーとしてログインします。
関連情報
- OpenShift Container Platform Web コンソールへのアクセスと理解に関する詳細は、Web コンソールへのアクセス を参照してください。
3.8.12. 次のステップ
- インストールの検証。
- クラスターをカスタマイズ します。
- 必要に応じて、リモートヘルスレポートをオプトアウト できます。
- 必要に応じて、クラウドプロバイダーの認証情報を削除 できます。