インストール
OpenShift Container Platform クラスターのインストールおよび設定
概要
第1章 インストールの概要
1.1. OpenShift Container Platform インストールの概要
1.1.1. OpenShift Container Platform のインストール
OpenShift Container Platform インストールプログラムでは、以下に詳細がリストされている 4 つの方法でクラスターをデプロイできます。
- インタラクティブ: Web ベースの Assisted Installer を使用してクラスターをデプロイできます。これは、ネットワークがインターネットに接続されているクラスターに最適です。Assisted Installer は、OpenShift Container Platform をインストールする最も簡単な方法であり、スマートなデフォルトを提供し、クラスターをインストールする前に事前検証を実行します。また、自動化および高度な設定シナリオのための RESTful API も提供します。
- ローカルエージェントベース: 非接続環境またはネットワークが制限された環境では、Agent-based Installer を使用してクラスターをローカルにデプロイできます。この方法では、Assisted Installer の多くの利点を得られますが、最初に Agent-based Installer をダウンロードして設定する必要があります。設定はコマンドラインインターフェイスで行います。このアプローチは、非接続環境に最適です。
- 自動化: installer-provisioned infrastructure にクラスターをデプロイできます。インストールプログラムは、各クラスターホストのベースボード管理コントローラー (BMC) をプロビジョニングに使用します。接続環境または非接続環境でクラスターをデプロイできます。
- 完全な制御: お客様が準備および保守するインフラストラクチャーにクラスターをデプロイメントできます。これにより、最大限のカスタマイズ性が提供されます。接続環境または非接続環境でクラスターをデプロイできます。
それぞれの方法でデプロイしたクラスターは、以下の特性を持ちます。
- 単一障害点のない高可用性インフラストラクチャーがデフォルトで利用可能です。
- 管理者は適用される更新の内容とタイミングを制御できます。
1.1.1.1. インストールプログラムについて
インストールプログラムを使用して、各タイプのクラスターをデプロイメントできます。インストールプログラムは、ブートストラップ、コントロールプレーン、コンピュートマシンの Ignition 設定ファイルなどのメインアセットを生成します。インフラストラクチャーを適切に設定している場合、これらの 3 つのマシン設定を使用して OpenShift Container Platform クラスターを起動できます。
OpenShift Container Platform インストールプログラムは、クラスターのインストールを管理するために一連のターゲットおよび依存関係を使用します。インストールプログラムには、達成する必要のある一連のターゲットが設定され、それぞれのターゲットには一連の依存関係が含まれます。各ターゲットはそれぞれの依存関係の条件が満たされ次第、別個に解決されるため、インストールプログラムは複数のターゲットを並行して達成できるように動作し、最終的にクラスターが実行するようにします。プログラムが依存関係を満たしているため、インストールプログラムはコマンドを実行してコンポーネントを再作成する代わりに、既存のコンポーネントを認識して使用します。
図1.1 OpenShift Container Platform インストールのターゲットおよび依存関係

1.1.1.2. Red Hat Enterprise Linux CoreOS (RHCOS) について
インストール後に、各クラスターマシンは Red Hat Enterprise Linux CoreOS (RHCOS) をオペレーティングマシンとして使用します。RHCOS は Red Hat Enterprise Linux (RHEL) の不変のコンテナーホストのバージョンであり、デフォルトで SELinux が有効になった RHEL カーネルを特長としています。RHCOS には、Kubernetes ノードエージェントである kubelet
や、Kubernetes に対して最適化される CRI-O コンテナーランタイムが含まれます。
OpenShift Container Platform 4.15 クラスターのすべてのコントロールプレーンは、Ignition と呼ばれる最初の起動時に使用される重要なプロビジョニングツールが含まれる RHCOS を使用する必要があります。このツールは、クラスターのマシンの設定を可能にします。オペレーティングシステムの更新は、OSTree をバックエンドとして使用する起動可能なコンテナーイメージとして配信され、Machine Config Operator によりクラスター全体にデプロイされます。実際のオペレーティングシステムの変更は、rpm-ostree を使用することにより、atomic 操作として各マシン上でインプレースで行われます。これらのテクノロジーを組み合わせることで、OpenShift Container Platform は、プラットフォーム全体を最新の状態に保つインプレースアップグレードによって、クラスター上の他のアプリケーションを管理するのと同じようにオペレーティングシステムを管理できるようになります。これらのインプレースアップグレードにより、オペレーションチームの負担を軽減できます。
すべてのクラスターマシンのオペレーティングシステムとして RHCOS を使用する場合、クラスターはオペレーティングシステムを含むコンポーネントとマシンのあらゆる側面を管理します。このため、マシンを変更できるのは、インストールプログラムと Machine Config Operator だけです。インストールプログラムは、Ignition 設定ファイルを使用して各マシンの正確な状態を設定し、インストール後に Machine Config Operator が新しい証明書やキーの適用などのマシンへの追加の変更を完了します。
1.1.1.3. OpenShift Container Platform のインストールに関する一般的な用語集
この用語集では、インストールコンテンツに関する一般的な用語を定義しています。インストールプロセスの理解を深めるために、次の用語リストを確認してください。
- Assisted Installer
- クラスター設定を作成するための Web ベースのユーザーインターフェイスまたは RESTful API を提供する、console.redhat.com でホストされるインストーラー。Assisted Installer は検出イメージを生成します。クラスターマシンは、RHCOS とエージェントをインストールする検出イメージで起動します。Assisted Installer とエージェントは、ともにインストール前の検証とクラスターのインストールを提供します。
- Agent-based Installer
- Assisted Installer に似たインストーラーですが、最初に Agent-based Installer をダウンロードする必要があります。Agent-based Installer は非接続環境に最適です。
- ブートストラップノード
- OpenShift Container Platform コントロールプレーンをデプロイするために必要な最小限の Kubernetes 設定を実行する一時的なマシン。
- コントロールプレーン
- コンテナーのライフサイクルを定義、デプロイ、および管理するための API とインターフェイスを公開するコンテナーオーケストレーションレイヤー。コントロールプレーンマシンとも呼ばれます。
- コンピュートノード
- クラスターユーザーのワークロードを実行するノード。ワーカーノードとしても知られています。
- 非接続インストール
- 場合によっては、プロキシーサーバーを介しても、データセンターの一部はインターネットにアクセスできない可能性があります。このような環境でも OpenShift Container Platform をインストールできますが、必要なソフトウェアおよびイメージをダウンロードし、これらを非接続環境で利用できる状態にする必要があります。
- OpenShift Container Platform インストールプログラム
- インフラストラクチャーをプロビジョニングし、クラスターをデプロイするプログラム。
- installer-provisioned infrastructure
- インストールプログラムは、クラスターを実行するインフラストラクチャーをデプロイして設定します。
- Ignition 設定ファイル
- オペレーティングシステムの初期化中に Ignition ツールが Red Hat Enterprise Linux CoreOS (RHCOS) を設定するために使用するファイル。インストールプログラムは、ブートストラップ、コントロールプレーン、およびワーカーノードを初期化するために、さまざまな Ignition 設定ファイルを生成します。
- Kubernetes マニフェスト
- JSON または YAML 形式の Kubernetes API オブジェクトの仕様。設定ファイルには、デプロイメント、設定マップ、シークレット、デーモンセットなどを含めることができます。
- Kubelet
- コンテナーが Pod で実行されていることを確認するために、クラスター内の各ノードで実行されるプライマリーノードエージェント。
- ロードバランサー
- ロードバランサーは、クライアントに対する単一の通信先として機能します。API のロードバランサーは、着信トラフィックをコントロールプレーンノード全体に分散します。
- Machine Config Operator
- クラスター内のノードのカーネルと kubelet との間にあるすべてのものを含む、基本オペレーティングシステムとコンテナーランタイムの設定と更新を管理および適用する Operator。
- Operator
- OpenShift Container Platform クラスターで Kubernetes アプリケーションをパッケージ化、デプロイ、および管理するための推奨される方法。Operator は、人間の操作に関する知識を取り入れて、簡単にパッケージ化してお客様と共有できるソフトウェアにエンコードします。
- user-provisioned infrastructure
- OpenShift Container Platform は、ユーザーが独自にプロビジョニングするインフラストラクチャーにインストールできます。インストールプログラムを使用すると、クラスターインフラストラクチャーのプロビジョニングに必要なアセットを生成し、クラスターインフラストラクチャーを作成して、提供したインフラストラクチャーにクラスターをデプロイできます。
1.1.1.4. インストールプロセス
Assisted Installer を除き、OpenShift Container Platform クラスターをインストールする場合は、OpenShift Cluster Manager Hybrid Cloud Console の適切な クラスタータイプ ページから、インストールプログラムをダウンロードする必要があります。このコンソールは以下を管理します。
- アカウントの REST API。
- 必要なコンポーネントを取得するために使用するプルシークレットであるレジストリートークン。
- クラスターのアイデンティティーを Red Hat アカウントに関連付けて使用状況のメトリクスの収集を容易にするクラスター登録。
OpenShift Container Platform 4.15 では、インストールプログラムは、一連のアセットに対して一連のファイル変換を実行する Go バイナリーファイルです。インストールプログラムと対話する方法は、インストールタイプによって異なります。次のインストールユースケースを検討してください。
- Assisted Installer を使用してクラスターをデプロイするには、Assisted Installer を使用してクラスター設定を行う必要があります。ダウンロードして設定するインストールプログラムはありません。クラスター設定が完了したら、検出 ISO をダウンロードし、そのイメージを使用してクラスターマシンを起動します。Assisted Installer を使用して、完全に統合された Nutanix、vSphere、およびベアメタル、ならびに統合されていないその他のプラットフォームにクラスターをインストールできます。ベアメタルにインストールする場合は、ネットワーク、負荷分散、ストレージ、個々のクラスターマシンなど、すべてのクラスターインフラストラクチャーとリソースを提供する必要があります。
- Agent-based Installer を使用してクラスターをデプロイするには、最初に Agent-based Installer をダウンロードします。次に、クラスターを設定して、検出イメージを生成します。検出イメージを使用してクラスターマシンを起動します。これにより、インストールプログラムと通信してプロビジョニングを処理するエージェントがインストールされます。インストールプログラムとを操作したりプロビジョナーマシンを自分で設定したりする必要はありません。ネットワーク、負荷分散、ストレージ、個々のクラスターマシンなど、すべてのクラスターインフラストラクチャーとリソースを提供する必要があります。このアプローチは、非接続環境に最適です。
- installer-provisioned infrastructure のクラスターの場合、インフラストラクチャーのブートストラップおよびプロビジョニングは、ユーザーが独自に行うのではなくインストールプログラムが代行します。インストールプログラムは、ベアメタルにインストールする場合を除き、クラスターをサポートするために必要なすべてのネットワーク、マシン、およびオペレーティングシステムを作成します。ベアメタルにインストールする場合は、ブートストラップマシン、ネットワーク、負荷分散、ストレージ、個々のクラスターマシンなど、すべてのクラスターインフラストラクチャーとリソースを提供する必要があります。
- クラスターのインフラストラクチャーを独自にプロビジョニングし、管理する場合には、ブートストラップマシン、ネットワーク、負荷分散、ストレージ、および個々のクラスターマシンを含む、すべてのクラスターインフラストラクチャーおよびリソースを指定する必要があります。
インストールプログラムの場合、プログラムはインストール中に 3 つのファイルセットを使用します。それは、install-config.yaml
という名前のインストール設定ファイル、Kubernetes マニフェスト、およびマシンタイプの Ignition 設定ファイルです。
インストール時に、Kubernetes および基礎となる RHCOS オペレーティングシステムを制御する Ignition 設定ファイルを変更できます。ただし、これらのオブジェクトに対して加える変更の適合性を確認するための検証の方法はなく、これらのオブジェクトを変更するとクラスターが機能しなくなる可能性があります。これらのオブジェクトを変更する場合、クラスターが機能しなくなる可能性があります。このリスクがあるために、変更方法に関する文書化された手順に従っているか、Red Hat サポートが変更することを指示した場合を除き、Kubernetes および Ignition 設定ファイルの変更はサポートされていません。
インストール設定ファイルは Kubernetes マニフェストに変換され、その後マニフェストは Ignition 設定にラップされます。インストールプログラムはこれらの Ignition 設定ファイルを使用してクラスターを作成します。
インストール設定ファイルはインストールプログラムの実行時にすべてプルーニングされるため、再び使用する必要のあるすべての設定ファイルをバックアップしてください。
インストール時に設定したパラメーターを変更することはできませんが、インストール後に数多くのクラスター属性を変更することができます。
Assisted Installer を使用したインストールプロセス
Assisted Installer を使用したインストールでは、Web ベースのユーザーインターフェイスまたは RESTful API を使用して対話的にクラスター設定を作成します。Assisted Installer ユーザーインターフェイスは、ユーザーインターフェイスまたは API で変更しない限り、必要な値の入力を求め、残りのパラメーターに適切なデフォルト値を提供します。Assisted Installer は検出イメージを生成します。このイメージをダウンロードして、クラスターマシンの起動に使用します。イメージによって RHCOS とエージェントがインストールされ、エージェントがプロビジョニングを処理します。OpenShift Container Platform を、Assisted Installer を使用して完全な統合により、Nutanix、vSphere、およびベアメタルにインストールできます。統合せずに、Assisted Installer を使用して OpenShift Container Platform を別のプラットフォームにインストールすることも可能です。
OpenShift Container Platform は、オペレーティングシステム自体を含む、クラスターのすべての側面を管理します。各マシンは、それが参加するクラスターでホストされるリソースを参照する設定に基づいて起動します。この設定により、クラスターは更新の適用時に自己管理できます。
可能であれば、Agent-based Installer をダウンロードして設定する必要がないように、Assisted Installer 機能を使用してください。
エージェントベースのインフラストラクチャーを使用したインストールプロセス
Agent-based installation は Assisted Installer を使用する場合とよく似ていますが、最初に Agent-based Installer をダウンロードしてインストールする必要があります。エージェントベースのインストールは、Assisted Installer の利便性を活用したいが、非接続環境でクラスターをインストールする必要がある場合に役立ちます。
可能であれば、エージェントベースのインストール機能を使用してください。その場合、ブートストラップ仮想マシンを使用してプロビジョナーマシンを作成し、クラスターインフラストラクチャーをプロビジョニングして維持する必要がなくなります。
installer-provisioned infrastructure でのインストールプロセス
デフォルトのインストールタイプは、installer-provisioned infrastructure です。デフォルトで、インストールプログラムはインストールウィザードとして機能し、独自に判別できない値の入力を求めるプロンプトを出し、残りのパラメーターに妥当なデフォルト値を提供します。インストールプロセスは、高度なインフラストラクチャーシナリオに対応するようカスタマイズすることもできます。インストールプログラムは、クラスターの基盤となるインフラストラクチャーをプロビジョニングします。
標準クラスターまたはカスタマイズされたクラスターのいずれかをインストールすることができます。標準クラスターの場合、クラスターをインストールするために必要な最小限の詳細情報を指定します。カスタマイズされたクラスターの場合、コントロールプレーンが使用するマシン数、クラスターがデプロイする仮想マシンのタイプ、または Kubernetes サービスネットワークの CIDR 範囲などのプラットフォームの詳細を指定することができます。
可能な場合は、この機能を使用してクラスターインフラストラクチャーのプロビジョニングと保守の手間を省くようにしてください。他のすべての環境の場合には、インストールプログラムを使用してクラスターインフラストラクチャーをプロビジョニングするために必要なアセットを生成できます。
installer-provisioned infrastructure クラスターの場合、OpenShift Container Platform は、オペレーティングシステム自体を含むクラスターのすべての側面を管理します。各マシンは、それが参加するクラスターでホストされるリソースを参照する設定に基づいて起動します。この設定により、クラスターは更新の適用時に自己管理できます。
user-provisioned infrastructure を使用したインストールプロセス
OpenShift Container Platform はユーザーが独自にプロビジョニングするインフラストラクチャーにインストールすることもできます。インストールプログラムを使用してクラスターインフラストラクチャーのプロビジョニングに必要なアセットを生成し、クラスターインフラストラクチャーを作成し、その後にクラスターをプロビジョニングしたインフラストラクチャーにデプロイします。
インストールプログラムがプロビジョニングしたインフラストラクチャーを使用しない場合は、クラスターリソースをユーザー自身で管理し、維持する必要があります。次のリストは、一部のセルフマネージドリソースの詳細を示しています。
- クラスターを設定するコントロールプレーンおよびコンピュートマシンの基礎となるインフラストラクチャー
- ロードバランサー
- DNS レコードおよび必要なサブネットを含むクラスターネットワーク
- クラスターインフラストラクチャーおよびアプリケーションのストレージ
クラスターで user-provisioned infrastructure を使用する場合には、RHEL コンピュートマシンをクラスターに追加するオプションを使用できます。
インストールプロセスの詳細
クラスターがプロビジョニングされると、クラスター内の各マシンにはクラスターに関する情報が必要になります。OpenShift Container Platform は初期設定時に一時的なブートストラップマシンを使用して、必要な情報を永続的なコントロールプレーンに提供します。一時的なブートストラップマシンは、クラスターの作成方法を記述する Ignition 設定ファイルを使用して起動します。ブートストラップマシンは、コントロールプレーンを設定するコントロールプレーンマシンを作成します。その後、コントロールプレーンマシンはコンピュートマシン (ワーカーマシンとしても知られる) を作成します。以下の図はこのプロセスを示しています。
図1.2 ブートストラップ、コントロールプレーンおよびコンピュートマシンの作成

クラスターマシンを初期化した後、ブートストラップマシンは破棄されます。すべてのクラスターがこのブートストラッププロセスを使用してクラスターを初期化しますが、ユーザーがクラスターのインフラストラクチャーをプロビジョニングする場合には、多くの手順を手動で実行する必要があります。
-
インストールプログラムが生成する Ignition 設定ファイルには、24 時間が経過すると期限切れになり、その後に更新される証明書が含まれます。証明書を更新する前にクラスターが停止し、24 時間経過した後にクラスターを再起動すると、クラスターは期限切れの証明書を自動的に復元します。例外として、kubelet 証明書を回復するために保留状態の
node-bootstrapper
証明書署名要求 (CSR) を手動で承認する必要があります。詳細は、コントロールプレーン証明書の期限切れの状態からのリカバリー に関するドキュメントを参照してください。 - 24 時間証明書はクラスターのインストール後 16 時間から 22 時間でローテーションするため、Ignition 設定ファイルは、生成後 12 時間以内に使用することを検討してください。12 時間以内に Ignition 設定ファイルを使用することにより、インストール中に証明書の更新が実行された場合のインストールの失敗を回避できます。
クラスターのブートストラップには、以下のステップが関係します。
- ブートストラップマシンが起動し、コントロールプレーンマシンの起動に必要なリモートリソースのホスティングを開始します。インフラストラクチャーをプロビジョニングする場合、この手順では人的介入が必要になります。
- ブートストラップマシンは、単一ノードの etcd クラスターと一時的な Kubernetes コントロールプレーンを起動します。
- コントロールプレーンマシンは、ブートストラップマシンからリモートリソースをフェッチし、起動を終了します。インフラストラクチャーをプロビジョニングする場合、この手順では人的介入が必要になります。
- 一時的なコントロールプレーンは、実稼働コントロールプレーンマシンに対して実稼働コントロールプレーンをスケジュールします。
- Cluster Version Operator (CVO) はオンラインになり、etcd Operator をインストールします。etcd Operator はすべてのコントロールプレーンノードで etcd をスケールアップします。
- 一時的なコントロールプレーンはシャットダウンし、コントロールを実稼働コントロールプレーンに渡します。
- ブートストラップマシンは OpenShift Container Platform コンポーネントを実稼働コントロールプレーンに挿入します。
- インストールプログラムはブートストラップマシンをシャットダウンします。インフラストラクチャーをプロビジョニングする場合、この手順では人的介入が必要になります。
- コントロールプレーンはコンピュートノードを設定します。
- コントロールプレーンは一連の Operator の形式で追加のサービスをインストールします。
このブートストラッププロセスの結果として、OpenShift Container Platform クラスターが実行されます。次に、クラスターはサポートされる環境でのコンピュートマシンの作成など、日常の操作に必要な残りのコンポーネントをダウンロードし、設定します。
1.1.1.5. インストール後のノード状態の確認
以下のインストールヘルスチェックが正常に行われると、OpenShift Container Platform のインストールが完了します。
- プロビジョナーは、OpenShift Container Platform Web コンソールにアクセスできます。
- すべてのコントロールプレーンノードが準備状態にある。
- すべてのクラスター Operator が利用可能です。
インストールが完了すると、ワーカーノードを実行する特定のクラスター Operator が継続的にすべてのワーカーノードのプロビジョニングを試みます。すべてのワーカーノードが READY
と報告されるまで、多少時間がかかります。ベアメタルへのインストールの場合、ワーカーノードのトラブルシューティングを行う前に、少なくとも 60 分間待機してください。他のすべてのプラットフォームへのインストールの場合は、ワーカーノードのトラブルシューティングを行う前に、少なくとも 40 分間待機してください。ワーカーノードを実行するクラスター Operator の DEGRADED
状態は、ノードの状態ではなく、Operator 自体のリソースに依存します。
インストールが完了したら、引き続きクラスター内におけるノードの状態を監視できます。
前提条件
- インストールプログラムはターミナルで正常に解決されます。
手順
すべてのワーカーノードのステータスを表示します。
Copy to Clipboard Copied! Toggle word wrap Toggle overflow oc get nodes
$ oc get nodes
出力例
Copy to Clipboard Copied! Toggle word wrap Toggle overflow NAME STATUS ROLES AGE VERSION example-compute1.example.com Ready worker 13m v1.21.6+bb8d50a example-compute2.example.com Ready worker 13m v1.21.6+bb8d50a example-compute4.example.com Ready worker 14m v1.21.6+bb8d50a example-control1.example.com Ready master 52m v1.21.6+bb8d50a example-control2.example.com Ready master 55m v1.21.6+bb8d50a example-control3.example.com Ready master 55m v1.21.6+bb8d50a
NAME STATUS ROLES AGE VERSION example-compute1.example.com Ready worker 13m v1.21.6+bb8d50a example-compute2.example.com Ready worker 13m v1.21.6+bb8d50a example-compute4.example.com Ready worker 14m v1.21.6+bb8d50a example-control1.example.com Ready master 52m v1.21.6+bb8d50a example-control2.example.com Ready master 55m v1.21.6+bb8d50a example-control3.example.com Ready master 55m v1.21.6+bb8d50a
すべてのワーカーマシンノードのフェーズを表示します。
Copy to Clipboard Copied! Toggle word wrap Toggle overflow oc get machines -A
$ oc get machines -A
出力例
Copy to Clipboard Copied! Toggle word wrap Toggle overflow NAMESPACE NAME PHASE TYPE REGION ZONE AGE openshift-machine-api example-zbbt6-master-0 Running 95m openshift-machine-api example-zbbt6-master-1 Running 95m openshift-machine-api example-zbbt6-master-2 Running 95m openshift-machine-api example-zbbt6-worker-0-25bhp Running 49m openshift-machine-api example-zbbt6-worker-0-8b4c2 Running 49m openshift-machine-api example-zbbt6-worker-0-jkbqt Running 49m openshift-machine-api example-zbbt6-worker-0-qrl5b Running 49m
NAMESPACE NAME PHASE TYPE REGION ZONE AGE openshift-machine-api example-zbbt6-master-0 Running 95m openshift-machine-api example-zbbt6-master-1 Running 95m openshift-machine-api example-zbbt6-master-2 Running 95m openshift-machine-api example-zbbt6-worker-0-25bhp Running 49m openshift-machine-api example-zbbt6-worker-0-8b4c2 Running 49m openshift-machine-api example-zbbt6-worker-0-jkbqt Running 49m openshift-machine-api example-zbbt6-worker-0-qrl5b Running 49m
関連情報
インストールのスコープ
OpenShift Container Platform インストールプログラムのスコープは意図的に狭められています。単純さを確保し、確実にインストールを実行できるように設計されているためです。インストールが完了した後に数多くの設定タスクを実行することができます。
関連情報
- OpenShift Container Platform 設定リソースの詳細は、利用可能なクラスターのカスタマイズ を参照してください。
1.1.1.6. OpenShift Local の概要
OpenShift Local は、OpenShift Container Platform クラスターのビルドを開始するための迅速なアプリケーション開発をサポートします。OpenShift Local は、ローカルのコンピューターで実行し、セットアップおよびテストをシンプル化し、コンテナーベースのアプリケーションを開発するのに必要なすべてのツールと共にクラウド開発環境をローカルにエミュレートすることを目的として設計されています。
OpenShift Local は、使用するプログラミング言語にかかわらずアプリケーションをホストし、事前に設定された最小限の Red Hat OpenShift Container Platform クラスターをローカル PC に提供します。その際に、サーバーベースのインフラストラクチャーは必要ありません。
ホストされる環境では、OpenShift Local はマイクロサービスを作成してイメージに変換し、Linux、macOS、または Windows 10 以降を実行するノートパソコンまたはデスクトップ上の Kubernetes がホストするコンテナーで直接それらを実行できます。
OpenShift Local の詳細は、Red Hat OpenShift Local の概要 を参照してください。
1.1.2. OpenShift Container Platform クラスターでサポートされるプラットフォーム
OpenShift Container Platform バージョン 4.15 では、installer-provisioned infrastructure を使用するクラスターの場合、以下のプラットフォームにインストールできます。
- Alibaba Cloud
- Amazon Web Services (AWS)
- ベアメタル
- Google Cloud Platform (GCP)
- IBM Cloud®
- Microsoft Azure
- Microsoft Azure Stack Hub
- Nutanix
Red Hat OpenStack Platform (RHOSP)
- OpenShift Container Platform の最新リリースは、最新の RHOSP のロングライフリリースおよび中間リリースの両方をサポートします。RHOSP リリースの互換性の詳細は、OpenShift Container Platform on RHOSP support matrix を参照してください。
- VMware vSphere
これらのクラスターの場合は、インストールプロセスを実行するコンピューターを含むすべてのマシンが、プラットフォームコンテナーのイメージをプルし、Telemetry データを Red Hat に提供できるようインターネットに直接アクセスできる必要があります。
インストール後は、以下の変更はサポートされません。
- クラウドプロバイダープラットフォームの混在。
- クラウドプロバイダーコンポーネントの混在。たとえば、クラスターをインストールしたプラットフォーム上の別のプラットフォームから永続ストレージフレームワークを使用します。
OpenShift Container Platform 4.15 では、user-provisioned infrastructure を使用するクラスターの場合、以下のプラットフォームにインストールできます。
- AWS
- Azure
- Azure Stack Hub
- ベアメタル
- GCP
- IBM Power®
- IBM Z® または IBM® LinuxONE
RHOSP
- OpenShift Container Platform の最新リリースは、最新の RHOSP のロングライフリリースおよび中間リリースの両方をサポートします。RHOSP リリースの互換性の詳細は、OpenShift Container Platform on RHOSP support matrix を参照してください。
- VMware Cloud on AWS
- VMware vSphere
プラットフォームでサポートされているケースに応じて、user-provisioned infrastructure でインストールを実行できます。これにより、完全なインターネットアクセスでのマシンの実行、プロキシーの背後へのクラスターの配置、非接続インストールの実行が可能になります。
非接続インストールでは、クラスターのインストールに必要なイメージをダウンロードして、ミラーレジストリーに配置し、そのデータを使用してクラスターをインストールできます。vSphere またはベアメタルインフラストラクチャー上での非接続インストールでは、プラットフォームコンテナーのイメージをプルするためにインターネットにアクセスする必要がありますが、クラスターマシンはインターネットへの直接のアクセスを必要としません。
OpenShift Container Platform 4.x Tested Integrations のページには、各種プラットフォームの統合テストの詳細が記載されています。
関連情報
- それぞれのサポートされているプラットフォームで利用できるインストールのタイプの詳細は、各種プラットフォームのサポートされているインストール方法 を参照してください。
- インストール方法の選択と必要なリソースの準備については、クラスターインストール方法の選択およびそのユーザー向けの準備 を参照してください。
- Red Hat OpenShift Network Calculator は、デプロイフェーズと拡張フェーズの両方で、クラスターネットワークを設計するのに役立ちます。クラスターネットワークに関連する一般的な疑問を解消し、便利な JSON 形式で出力を提供します。
1.2. クラスターインストール方法の選択およびそのユーザー向けの準備
OpenShift Container Platform をインストールする前に、実行するインストールプロセスを決定し、ユーザー用にクラスターを準備する際に必要なすべてのリソースがあることを確認します。
1.2.1. クラスターのインストールタイプの選択
OpenShift Container Platform クラスターをインストールする前に、実行する最適なインストール手順を選択する必要があります。以下の質問に回答して、最も良いオプションを選択します。
1.2.1.1. OpenShift Container Platform クラスターを独自にインストールし、管理しますか ?
OpenShift Container Platform を独自にインストールし、管理する必要がある場合、以下のプラットフォームにインストールすることができます。
- Alibaba Cloud
- 64 ビット x86 インスタンスの Amazon Web Services (AWS)
- 64 ビット ARM インスタンスの Amazon Web Services (AWS)
- 64 ビット x86 インスタンスの Microsoft Azure
- 64 ビット ARM インスタンスの Microsoft Azure
- Microsoft Azure Stack Hub
- 64 ビット x86 インスタンス上の Google Cloud Platform (GCP)
- 64 ビット ARM インスタンス上の Google Cloud Platform (GCP)
- Red Hat OpenStack Platform (RHOSP)
- IBM Cloud®
- IBM Z® または IBM® LinuxONE
- IBM Z® または IBM® LinuxONE for Red Hat Enterprise Linux (RHEL) KVM
- IBM Power®
- IBM Power® Virtual Server
- Nutanix
- VMware vSphere
- ベアメタルまたはその他のプラットフォームに依存しないインフラストラクチャー
OpenShift Container Platform 4 クラスターは、オンプレミスハードウェアとクラウドホストサービスの両方にデプロイできますが、クラスターのすべてのマシンは同じデータセンターまたはクラウドホストサービスにある必要があります。
OpenShift Container Platform を使用する必要があるが、クラスターを独自に管理することを望まない場合は、複数のマネージドサービスオプションを使用できます。Red Hat によって完全に管理されるクラスターが必要な場合は、OpenShift Dedicated または OpenShift Online を使用することができます。OpenShift を Azure、AWS、IBM Cloud®、または Google Cloud でマネージドサービスとして使用することもできます。マネージドサービスの詳細は、OpenShift の製品 ページを参照してください。クラウド仮想マシンを仮想ベアメタルとして OpenShift Container Platform クラスターをインストールする場合、対応するクラウドベースのストレージはサポートされません。
1.2.1.2. OpenShift Container Platform 3 を使用したことがあり、その上で OpenShift Container Platform 4 を使用することを希望していますか ?
OpenShift Container Platform 3 を使用したことがあり、OpenShift Container Platform 4 を使用してみたいと思われる場合は、OpenShift Container Platform 4 がどのように異なるかを理解しておく必要があります。OpenShift Container Platform 4 では、Kubernetes アプリケーション、プラットフォームが実行されるオペレーティングシステム、Red Hat Enterprise Linux CoreOS (RHCOS) を共にシームレスにパッケージ化し、デプロイし、管理する Operator を使用します。マシンをデプロイし、それらのオペレーティングシステムを設定して OpenShift Container Platform をそれらにインストールできるようにする代わりに、RHCOS オペレーティングシステムが OpenShift Container Platform クラスターの統合された部分として使用されます。OpenShift Container Platform のインストールプロセスの一部として、クラスターマシンのオペレーティングシステムをデプロイします。OpenShift Container Platform 3 と 4 の相違点 を参照してください。
OpenShift Container Platform クラスターのインストールプロセスの一部としてマシンをプロビジョニングする必要があるため、OpenShift Container Platform 3 クラスターを OpenShift Container Platform 4 にアップグレードすることはできません。その代わりに、新規の OpenShift Container Platform 4 クラスターを作成し、OpenShift Container Platform 3 ワークロードをそれらに移行する必要があります。移行の詳細は、OpenShift Container Platform 3 から 4 への移行の概要 を参照してください。OpenShift Container Platform 4 に移行するにあたり、任意のタイプの実稼働用のクラスターのインストールプロセスを使用して新規クラスターを作成できます。
1.2.1.3. クラスターで既存のコンポーネントを使用する必要がありますか ?
オペレーティングシステムは OpenShift Container Platform に不可欠な要素であり、OpenShift Container Platform のインストールプログラムはすべてのインフラストラクチャーの起動を簡単に実行できます。これらは、installer provisioned infrastructure のインストールと呼ばれています。この種のインストールでは、ユーザーは既存のインフラストラクチャーをクラスターに提供できますが、インストールプログラムがクラスターを最初に必要とするすべてのマシンをデプロイします。
クラスターまたはその基盤となるマシンの Alibaba Cloud、AWS、Azure、Azure Stack Hub、GCP、または Nutanix へのカスタマイズを指定することなく、インストーラーでプロビジョニングされたインフラストラクチャークラスターをデプロイできます。
インストーラーでプロビジョニングされたインフラストラクチャークラスターの基本設定 (クラスターマシンのインスタンスタイプなど) を実行する必要がある場合は、Alibaba Cloud、AWS、Azure、GCP、または Nutanix のインストールをカスタマイズできます。
インストーラーでプロビジョニングされるインフラストラクチャーのインストールの場合、AWS の既存の VPC、Azure の vNet、または GCP の VPC を使用できます。ネットワークインフラストラクチャーの一部を再利用して、AWS、Azure、または GCP のクラスターが環境内の既存の IP アドレスの割り当てと共存し、既存の MTU および VXLAN 設定と統合するようにできます。これらのクラウドに既存のアカウントおよび認証情報がある場合は、それらを再利用できますが、OpenShift Container Platform クラスターをインストールするために必要なパーミッションを持つようアカウントを変更する必要がある場合があります。
installer-provisioned infrastructure メソッドを使用して、vSphere および ベアメタル のハードウェアに適切なマシンインスタンスを作成できます。さらに、vSphere では、インストール時に追加のネットワークパラメーターをカスタマイズすることもできます。
VMware vSphere やベアメタルプラットフォームなどの一部の installer-provisioned infrastructure インストールでは、Ingress 仮想 IP (VIP) に到達する外部トラフィックがデフォルトの IngressController
レプリカ間で分散されません。ベースライン IngressController
ルーターのパフォーマンスを超えることが予想される vSphere およびベアメタル installer-provisioned infrastructure インストールでは、外部ロードバランサーを設定する必要があります。外部ロードバランサーを設定すると、複数の IngressController
レプリカのパフォーマンスが実現します。ベースライン IngressController パフォーマンスの詳細は、ベースライン Ingress Controller (ルーター) パフォーマンス を参照してください。外部ロードバランサーの設定の詳細は、ユーザー管理ロードバランサーの設定 を参照してください。
大規模なクラウドインフラストラクチャーを再利用する必要がある場合、user-provisioned infrastructure のインストールを実行できます。これらのインストールでは、インストールプロセス時にクラスターに必要なマシンを手動でデプロイします。AWS、Azure、および Azure Stack Hub で user-provisioned infrastructure を実行する場合、提供されるテンプレートを使用して必要なすべてのコンポーネントを起動できます。共有 VPC on GCP を再利用することもできます。それ以外の場合は、プロバイダーに依存しない インストール方法を使用して、クラスターを他のクラウドにデプロイすることができます。
user-provisioned infrastructure は、既存のハードウェアで実行することもできます。RHOSP、IBM Z® または IBM® LinuxONE、RHEL KVM が搭載された IBM Z® および IBM® LinuxONE、IBM Power、または vSphere を使用する場合は、特定のインストール手順に従ってクラスターをデプロイします。サポートされる他のハードウェアを使用する場合は、ベアメタルのインストール 手順に従います。vSphere や ベアメタル などの一部のプラットフラォームの場合は、インストール時に追加のネットワークパラメーターをカスタマイズすることもできます。
1.2.1.4. クラスターに追加のセキュリティーが必要ですか ?
user-provisioned installation 方法を使用する場合、クラスターのプロキシーを設定できます。この手順は各インストール手順に含まれています。
パブリッククラウドのクラスターがエンドポイントを外部に公開するのを防ぐ必要がある場合、AWS、Azure、または GCP の installer-provisioned infrastructure を使用してプライベートクラスターをデプロイすることができます。
非接続のクラスターまたはネットワークが制限されたクラスターなど、インターネットへのアクセスが限定されたクラスターをインストールする必要がある場合、インストールパッケージをミラーリング し、そこからクラスターをインストールできます。user-provisioned infrastructure によるインストールの詳細な手順を実行して、AWS、GCP、IBM Z® または IBM® LinuxONE、RHEL KVM が搭載された IBM Z® または IBM® LinuxONE、IBM Power®、vSphere、または ベアメタル のネットワークが制限された環境にインストールしてください。ネットワークが制限された環境へのクラスターのインストールは、installer-provisioned infrastructure を使用して、AWS、GCP、IBM Cloud®、Nutanix、RHOSP、および vSphere 用の詳細な手順に従って実行することもできます。
クラスターを AWS GovCloud リージョン、AWS China リージョン、または Azure government リージョン にデプロイする必要がある場合は、installer-provisioned infrastructure のインストール時にこれらのカスタムリージョンを設定できます。
インストール中に FIPS 140-2/140-3 検証 のために NIST に提出された RHEL 暗号化ライブラリーを使用するようにクラスターマシンを設定することもできます。
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 暗号化ライブラリーを使用します。
1.2.2. インストール後のユーザー向けのクラスターの準備
一部の設定は、クラスターのインストールに必須ではありませんが、ユーザーがクラスターにアクセスする前に設定することが推奨されます。クラスターを設定する Operator を カスタマイズ することでクラスター自体をカスタマイズし、クラスターをアイデンティティープロバイダーなどの他の必要なシステムに統合できます。
実稼働クラスターの場合、以下の統合を設定する必要があります。
1.2.3. ワークロードに関するクラスターの準備
ワークロードのニーズによっては、アプリケーションのデプロイを開始する前に、追加の手順が必要になる場合があります。たとえば、アプリケーションの ビルドストラテジー をサポートできるようなインフラストラクチャーを準備した後に、低レイテンシー のワークロードに対応できるようにしたり、機密のワークロードを保護 できるようにしたりする必要がある場合があります。アプリケーションワークロードの モニタリング を設定することもできます。Windows ワークロード を実行する予定がある場合は、インストールプロセス中に OVN-Kubernetes を使用してハイブリッドネットワーク を有効にする必要があります。クラスターのインストール後はハイブリッドネットワークを有効にできません。
1.2.4. 各種プラットフォームのサポートされているインストール方法
各種のプラットフォームで各種のインストールを実行できます。
以下の表にあるように、すべてのプラットフォームですべてのインストールオプションがサポートされている訳ではありません。チェックマークは、オプションがサポートされていることを示し、関連するセクションにリンクしています。
Alibaba | AWS (64 ビット x86) | AWS (64 ビット ARM) | Azure (64 ビット x86) | Azure (64 ビット ARM) | Azure Stack Hub | GCP (64-bit x86) | GCP (64 ビット ARM) | Nutanix | RHOSP | ベアメタル (64 ビット x86) | ベアメタル (64 ビット ARM) | vSphere | IBM Cloud® | IBM Z® | IBM Power® | IBM Power® Virtual Server | |
---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
デフォルト | |||||||||||||||||
カスタム | |||||||||||||||||
ネットワークのカスタマイズ | |||||||||||||||||
ネットワークが制限されたインストール | |||||||||||||||||
プライベートクラスター | |||||||||||||||||
既存の仮想プライベートネットワーク | |||||||||||||||||
government リージョン | |||||||||||||||||
秘密の地域 | |||||||||||||||||
China リージョン |
Alibaba | AWS (64 ビット x86) | AWS (64 ビット ARM) | Azure (64 ビット x86) | Azure (64 ビット ARM) | Azure Stack Hub | GCP (64-bit x86) | GCP (64 ビット ARM) | Nutanix | RHOSP | ベアメタル (64 ビット x86) | ベアメタル (64 ビット ARM) | vSphere | IBM Cloud® | IBM Z® | RHEL KVM を使用した IBM Z® | IBM Power® | プラットフォームの指定なし | |
---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
カスタム | ||||||||||||||||||
ネットワークのカスタマイズ | ||||||||||||||||||
ネットワークが制限されたインストール | ||||||||||||||||||
クラスタープロジェクト外でホストされる共有 VPC |
1.3. クラスター機能
クラスター管理者は、クラスター機能を使用して、インストール前にオプションコンポーネントを有効または無効にできます。クラスター管理者は、インストール後いつでもクラスター機能を有効にすることができます。
クラスター管理者は、クラスター機能を有効にした後、それを無効にすることはできません。
1.3.1. クラスター機能の有効化
install-config.yaml
ファイルを作成してクラスターをカスタマイズするインストール方法を使用する場合は、クラスターで使用可能にするクラスター機能を選択できます。
特定のクラスター機能を有効または無効にしてクラスターをカスタマイズする場合は、install-config.yaml
ファイルを手動で管理する必要があります。新しい OpenShift Container Platform の更新では、既存のコンポーネントの新しい機能ハンドルが宣言されたり、新しいコンポーネントがまとめて導入されたりする可能性があります。install-config.yaml
ファイルをカスタマイズするユーザーは、OpenShift Container Platform の更新に合わせて install-config.yaml
ファイルを定期的に更新することも検討してください。
次の設定パラメーターを使用して、クラスター機能を選択できます。
capabilities: baselineCapabilitySet: v4.11 additionalEnabledCapabilities: - CSISnapshot - Console - Storage
capabilities:
baselineCapabilitySet: v4.11
additionalEnabledCapabilities:
- CSISnapshot
- Console
- Storage
- 1
- インストールする機能のベースラインセットを定義します。有効な値は
None
、vCurrent
、v4.x
です。None
を選択すると、すべてのオプション機能が無効になります。デフォルト値はvCurrent
で、すべてのオプション機能が有効になります。注記v4.x
は、現在のクラスターバージョン以前の任意の値を参照します。たとえば、OpenShift Container Platform 4.12 クラスターでの有効値はv4.11
とv4.12
です。 - 2
- 明示的に有効にする機能のリストを定義します。これらの機能は、
baselineCapabilitySet
で指定された機能に加えて有効になります。注記この例では、デフォルトで
v4.11
に設定されています。additionalEnabledCapabilities
フィールドでは、デフォルトのv4.11
機能セット以外を有効にできます。
次の表では、baselineCapabilitySet
の値を説明します。
値 | 説明 |
---|---|
| 新しいリリースで導入される新しいデフォルト機能を自動的に追加する場合、このオプションを指定します。 |
|
OpenShift Container Platform 4.11 のデフォルト機能を有効にする場合、このオプションを指定します。 |
|
OpenShift Container Platform 4.12 のデフォルト機能を有効にする場合、このオプションを指定します。 |
|
OpenShift Container Platform 4.13 のデフォルト機能を有効にする場合、このオプションを指定します。 |
|
OpenShift Container Platform 4.14 のデフォルト機能を有効にする場合、このオプションを指定します。 |
|
OpenShift Container Platform 4.15 のデフォルト機能を有効にする場合、このオプションを指定します。 |
|
他のセットが大きすぎる場合や、機能が必要ない場合、 |
1.3.2. OpenShift Container Platform 4.15 のオプションのクラスター機能
現在、クラスター Operator はこれらのオプション機能を提供します。以下は、各オプションによって提供される機能と、無効にした場合に失われる機能をまとめたものです。
1.3.2.1. ベアメタル機能
目的
Cluster Baremetal Operator は、baremetal
機能の機能を提供します。
Cluster Baremetal Operator (CBO) は、OpenShift Container Platform コンピュートノードを実行する準備が整った、完全に機能するワーカーノードにベアメタルサーバーを導入するために必要なすべてのコンポーネントをデプロイします。CBO は、Bare Metal Operator (BMO) と Ironic コンテナーで構成される metal3 デプロイメントが、OpenShift Container Platform クラスター内のコントロールプレーンノードの 1 つで実行されるようにします。また、CBO は、監視し、適切なアクションを実行するリソースへの OpenShift Container Platform の更新をリッスンします。
installer-provisioned infrastructure を使用したデプロイメントには、ベアメタル機能が必要です。ベアメタル機能を無効にすると、これらのデプロイメントで予期しない問題が発生する可能性があります。
クラスター管理者は、クラスター内に BareMetalHost
リソースを持たない user-provisioned infrastructure を使用したインストールの実行中に限り、ベアメタル機能を無効にすることを推奨します。
ベアメタル機能が無効になっている場合、クラスターはベアメタルノードをプロビジョニングまたは管理できません。デプロイメントに BareMetalHost
リソースがない場合にのみ、この機能を無効にしてください。baremetal
機能は MachineAPI
機能に依存します。baremetal
機能を有効にする場合は、MachineAPI
も有効にする必要があります。
1.3.2.2. ビルド機能
目的
Build
機能により、Build
API が有効になります。Build
API は、Build
オブジェクトと BuildConfig
オブジェクトのライフサイクルを管理します。
Build
機能が無効になっている場合、クラスターは Build
または BuildConfig
リソースを使用できません。クラスター内で Build
リソースおよび BuildConfig
リソースが必要ない場合にのみ、この機能を無効にします。
1.3.2.3. クラウド認証情報機能
目的
Cloud Credential Operator は、CloudCredential
の機能を提供します。
現在、CloudCredential
機能の無効化は、ベアメタルクラスターでのみサポートされています。
Cloud Credential Operator (CCO) は、クラウドプロバイダーの認証情報を Kubernetes カスタムリソース定義 (CRD) として管理します。CCO は CredentialsRequest
カスタムリソース (CR) で同期し、OpenShift Container Platform コンポーネントが、クラスターの実行に必要な特定のパーミッションと共にクラウドプロバイダーの認証情報を要求できるようにします。
install-config.yaml
ファイルで credentialsMode
パラメーターに異なる値を設定すると、CCO は複数の異なるモードで動作するように設定できます。モードが指定されていない場合や、credentialsMode
パラメーターが空の文字列 (""
) に設定されている場合は、CCO はデフォルトモードで動作します。
1.3.2.4. クラスターストレージ機能
目的
Cluster Storage Operator は、Storage
機能を提供します。
Cluster Storage Operator は OpenShift Container Platform のクラスター全体のストレージのデフォルト値を設定します。これにより、OpenShift Container Platform クラスターのデフォルトの storageclass
の存在を確認できます。また、クラスターがさまざまなストレージバックエンドを使用できるようにする Container Storage Interface (CSI) ドライバーもインストールします。
クラスターストレージ機能が無効になっている場合、クラスターにデフォルトの storageclass
または CSI ドライバーはありません。クラスターストレージ機能が無効になっている場合、管理者権限を持つユーザーは、デフォルトの storageclass
を作成して CSI ドライバーを手動でインストールできます。
注記
- Operator が作成するストレージクラスは、そのアノテーションを編集することで非デフォルトにすることができますが、Operator が実行されているかぎり、このストレージクラスを削除することはできません。
1.3.2.5. コンソール機能
目的
Console Operator は、コンソール
機能を提供します。
Console Operator は OpenShift Container Platform Web コンソールをクラスターにインストールし、維持します。Console Operator はデフォルトでインストールされ、コンソールを自動的に維持します。
関連情報
1.3.2.6. CSI スナップショットコントローラー機能
目的
Cluster CSI Snapshot Controller Operator は、CSISnapshot
機能を提供します。
Cluster CSI Snapshot Controller Operator は、CSI Snapshot Controller をインストールし、維持します。CSI Snapshot Controller は VolumeSnapshot
CRD オブジェクトを監視し、ボリュームスナップショットの作成および削除のライフサイクルを管理します。
関連情報
1.3.2.7. DeploymentConfig 機能
目的
DeploymentConfig
機能は、DeploymentConfig
API を有効にして管理します。
DeploymentConfig
機能を無効にすると、クラスター内で次のリソースが使用できなくなります。
-
DeploymentConfig
リソース -
deployer
サービスアカウント
クラスターに DeploymentConfig
リソースと deployer
サービスアカウントが必要ない場合にのみ、DeploymentConfig
機能を無効にしてください。
1.3.2.8. Insights 機能
目的
Insights Operator は、Insights
機能を提供します。
Insights Operator は OpenShift Container Platform 設定データを収集し、これを Red Hat に送信します。このデータは、クラスターで発生する可能性のある問題について、今後を見据えた上で、事前に対応できる内容に関して推奨事項を生み出します。これらの今後の対応案については、console.redhat.comの Insights Advisor を介してクラスター管理者に伝達されます。
注記
Insights Operator は、OpenShift Container Platform Telemetry を補完します。
1.3.2.9. マシン API 機能
目的
machine-api-operator
、cluster-autoscaler-operator
、および cluster-control-plane-machine-set-operator
Operator は、MachineAPI
機能の機能を提供します。この機能は、user-provisioned infrastructure を使用してクラスターをインストールする場合にのみ無効にできます。
Machine API 機能は、クラスター内のすべてのマシンの設定と管理を担当します。インストール中に Machine API 機能を無効にした場合は、すべてのマシン関連タスクを手動で管理する必要があります。
1.3.2.10. マーケットプレイス機能
目的
Marketplace Operator は、marketplace
機能の機能を提供します。
Marketplace Operator は、クラスター上の一連のデフォルトの Operator Lifecycle Manager (OLM) カタログを使用して、クラスター外の Operator をクラスターに持ち込むプロセスを簡素化します。Marketplace Operator がインストールされると、openshift-marketplace
namespace が作成されます。OLM は、openshift-marketplace
namespace にインストールされたカタログソースがクラスター上のすべての namespace で利用可能であることを保証します。
marketplace
機能を無効にすると、Marketplace Operator は openshift-marketplace
namespace を作成しません。カタログソースは引き続きクラスターで手動で設定および管理できますが、OLM は、クラスター上のすべての namespace でカタログを利用できるようにするために、openshift-marketplace
namespace に依存しています。システム管理者やクラスター管理者など、openshift-
で始まる namespace を作成する権限が昇格されたユーザーは、openshift-marketplace
namespace を手動で作成できます。
marketplace
機能を有効にすると、Marketplace Operator を設定することで個々のカタログを有効または無効にすることができます。
1.3.2.11. Operator Lifecycle Manager 機能
目的
Operator Lifecycle Manager (OLM) を使用することにより、ユーザーは Kubernetes ネイティブアプリケーション (Operator) および OpenShift Container Platform クラスター全体で実行される関連サービスについてインストール、更新、およびそのライフサイクルの管理を実行できます。これは、Operator を効果的かつ自動化された拡張可能な方法で管理するために設計されたオープンソースツールキットの Operator Framework の一部です。
Operator が次の API のいずれかを必要とする場合は、OperatorLifecycleManager
機能を有効にする必要があります。
-
ClusterServiceVersion
-
CatalogSource
-
Subscription
-
InstallPlan
-
OperatorGroup
marketplace
機能は、OperatorLifecycleManager
機能に依存します。OperatorLifecycleManager
機能を無効にして marketplace
機能を有効にすることはできません。
1.3.2.12. ノードチューニング機能
目的
Node Tuning Operator は、NodeTuning
の機能を提供します。
Node Tuning Operator は、TuneD デーモンを調整することでノードレベルのチューニングを管理し、Performance Profile コントローラーを使用して低レイテンシーのパフォーマンスを実現するのに役立ちます。ほとんどの高パフォーマンスアプリケーションでは、一定レベルのカーネルのチューニングが必要です。Node Tuning Operator は、ノードレベルの sysctl の統一された管理インターフェイスをユーザーに提供し、ユーザーが指定するカスタムチューニングを追加できるよう柔軟性を提供します。
NodeTuning 機能を無効にすると、一部のデフォルトチューニング設定がコントロールプレーンノードに適用されなくなります。これにより、900 を超えるノードまたは 900 のルートを持つ大規模なクラスターのスケーラビリティとパフォーマンスが制限される可能性があります。
1.3.2.13. OpenShift サンプル機能
目的
Cluster Samples Operator は、openshift-samples
機能の機能を提供します。
Cluster Samples Operator は、openshift
namespace に保存されるサンプルイメージストリームおよびテンプレートを管理します。
初回起動時に、Operator はデフォルトのサンプル設定リソースを作成し、イメージストリームおよびテンプレートの作成を開始します。設定オブジェクトは、キーが cluster
で、タイプが configs.samples
のクラスタースコープのオブジェクトです。
イメージストリームは、registry.redhat.io
のイメージを参照する Red Hat Enterprise Linux CoreOS (RHCOS) ベースの OpenShift Container Platform イメージストリームです。同様に、テンプレートは OpenShift Container Platform テンプレートとして分類されます。
サンプル機能を無効にすると、ユーザーはそれが提供するイメージストリーム、サンプル、およびテンプレートにアクセスできなくなります。デプロイメントによっては、このコンポーネントが不要な場合は無効にすることができます。
1.3.2.14. クラスターイメージレジストリー機能
目的
Cluster Image Registry Operator は、ImageRegistry
の機能を提供します。
Cluster Image Registry Operator は、OpenShift イメージレジストリーのシングルトンインスタンスを管理します。ストレージの作成を含む、レジストリーのすべての設定を管理します。
初回起動時に、Operator はクラスターで検出される設定に基づいてデフォルトの image-registry
リソースインスタンスを作成します。これは、クラウドプロバイダーに基づいて使用するクラウドストレージのタイプを示します。
完全な image-registry
リソースを定義するのに利用できる十分な情報がない場合、その不完全なリソースが定義され、Operator は足りない情報を示す情報を使用してリソースのステータスを更新します。
Cluster Image Registry Operator は openshift-image-registry
namespace で実行され、その場所のレジストリーインスタンスも管理します。レジストリーのすべての設定およびワークロードリソースはその namespace に置かれます。
イメージレジストリーをクラスターのユーザー認証および認可システムに統合するために、サービスアカウントトークンシークレットとイメージプルシークレットがクラスターのサービスアカウントごとに生成されます。
ImageRegistry
機能を無効にした場合、または Cluster Image Registry Operator の設定で統合 OpenShift イメージレジストリーを無効にした場合、サービスアカウントのトークンシークレットとイメージプルシークレットは、サービスアカウントごとに生成されません。
ImageRegistry
機能を無効にすると、リソースに制約のある環境で OpenShift Container Platform の全体的なリソースフットプリントを削減できます。デプロイメントに応じて、このコンポーネントが必要ない場合は無効にすることができます。
プロジェクト
1.3.3. クラスター機能の表示
クラスター管理者は、clusterversion
リソースの状態を使用して機能を表示できます。
前提条件
-
OpenShift CLI (
oc
) がインストールされている。
手順
クラスター機能のステータスを表示するには、次のコマンドを実行します。
Copy to Clipboard Copied! Toggle word wrap Toggle overflow oc get clusterversion version -o jsonpath='{.spec.capabilities}{"\n"}{.status.capabilities}{"\n"}'
$ oc get clusterversion version -o jsonpath='{.spec.capabilities}{"\n"}{.status.capabilities}{"\n"}'
出力例
Copy to Clipboard Copied! Toggle word wrap Toggle overflow {"additionalEnabledCapabilities":["openshift-samples"],"baselineCapabilitySet":"None"} {"enabledCapabilities":["openshift-samples"],"knownCapabilities":["CSISnapshot","Console","Insights","Storage","baremetal","marketplace","openshift-samples"]}
{"additionalEnabledCapabilities":["openshift-samples"],"baselineCapabilitySet":"None"} {"enabledCapabilities":["openshift-samples"],"knownCapabilities":["CSISnapshot","Console","Insights","Storage","baremetal","marketplace","openshift-samples"]}
1.3.4. クラスター機能を有効にするベースライン機能セットの設定
クラスター管理者は、OpenShift Container Platform のインストール後、baselineCapabilitySet
設定パラメーターを設定することで、いつでもクラスター機能を有効にできます。
前提条件
-
OpenShift CLI (
oc
) がインストールされている。
手順
baselineCapabilitySet
設定パラメーターを設定するには、次のコマンドを実行します。Copy to Clipboard Copied! Toggle word wrap Toggle overflow oc patch clusterversion version --type merge -p '{"spec":{"capabilities":{"baselineCapabilitySet":"vCurrent"}}}'
$ oc patch clusterversion version --type merge -p '{"spec":{"capabilities":{"baselineCapabilitySet":"vCurrent"}}}'
1 - 1
baselineCapabilitySet
には、vCurrent
、v4.15
、またはNone
を指定できます。
1.3.5. 追加で有効な機能を設定することによるクラスター機能の有効化
クラスター管理者は、OpenShift Container Platform のインストール後、additionalEnabledCapabilities
設定パラメーターを設定することで、いつでもクラスター機能を有効にできます。
前提条件
-
OpenShift CLI (
oc
) がインストールされている。
手順
次のコマンドを実行して、追加の有効な機能を表示します。
Copy to Clipboard Copied! Toggle word wrap Toggle overflow oc get clusterversion version -o jsonpath='{.spec.capabilities.additionalEnabledCapabilities}{"\n"}'
$ oc get clusterversion version -o jsonpath='{.spec.capabilities.additionalEnabledCapabilities}{"\n"}'
出力例
Copy to Clipboard Copied! Toggle word wrap Toggle overflow ["openshift-samples"]
["openshift-samples"]
additionalEnabledCapabilities
設定パラメーターを設定するには、次のコマンドを実行します。Copy to Clipboard Copied! Toggle word wrap Toggle overflow oc patch clusterversion/version --type merge -p '{"spec":{"capabilities":{"additionalEnabledCapabilities":["openshift-samples", "marketplace"]}}}'
$ oc patch clusterversion/version --type merge -p '{"spec":{"capabilities":{"additionalEnabledCapabilities":["openshift-samples", "marketplace"]}}}'
クラスターですでに有効になっている機能を無効にすることはできません。クラスターバージョン Operator (CVO) は、クラスターですでに有効になっている機能を調整し続けます。
機能を無効にしようとすると、CVO は異なる仕様を示します。
oc get clusterversion version -o jsonpath='{.status.conditions[?(@.type=="ImplicitlyEnabledCapabilities")]}{"\n"}'
$ oc get clusterversion version -o jsonpath='{.status.conditions[?(@.type=="ImplicitlyEnabledCapabilities")]}{"\n"}'
出力例
{"lastTransitionTime":"2022-07-22T03:14:35Z","message":"The following capabilities could not be disabled: openshift-samples","reason":"CapabilitiesImplicitlyEnabled","status":"True","type":"ImplicitlyEnabledCapabilities"}
{"lastTransitionTime":"2022-07-22T03:14:35Z","message":"The following capabilities could not be disabled: openshift-samples","reason":"CapabilitiesImplicitlyEnabled","status":"True","type":"ImplicitlyEnabledCapabilities"}
クラスターのアップグレード中に、特定の機能が暗黙的に有効になる可能性があります。アップグレード前にクラスターでリソースがすでに実行されていた場合には、そのリソースに含まれるすべての機能が有効になります。たとえば、クラスターのアップグレード中に、そのクラスターですでに実行中のリソースが、システムにより marketplace
機能に含まれるように、変更される場合などです。クラスター管理者が marketplace
機能を明示的に有効にしていなくても、システムによって暗黙的に有効にされています。
1.4. FIPS 暗号のサポート
OpenShift Container Platform クラスターを FIPS モードでインストールできます。
OpenShift Container Platform は 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 暗号化ライブラリーを使用します。
NIST 検証プログラムの詳細は、暗号化モジュール検証プログラム を参照してください。検証のために提出された RHEL 暗号化ライブラリーの個別バージョンの最新の NIST ステータスについては、政府の標準規格 を参照してください。
クラスターで FIPS モードを有効にするには、FIPS モードで動作するように設定された RHEL 8 コンピューターからインストールプログラムを実行する必要があります。OpenShift Container Platform クラスターをインストールするために、FIPS モードを有効にして RHEL 9 を実行することはできません。
RHEL での FIPS モードの設定の詳細は、FIPS モードでのシステムのインストール を参照してください。
クラスター内の Red Hat Enterprise Linux CoreOS (RHCOS) マシンの場合、この変更は、ユーザーがクラスターのデプロイメント時に変更できるクラスターオプションを制御する install-config.yaml
ファイルのオプションのステータスに基づいてマシンがデプロイされる際に適用されます。Red Hat Enterprise Linux (RHEL) マシンでは、ワーカーマシンとして使用する予定のマシンにオペレーティングシステムをインストールする場合に FIPS モードを有効にする必要があります。
FIPS はクラスターが使用するオペレーティングシステムの初回の起動前に有効にされている必要があり、クラスターをデプロイしてから FIPS を有効にすることはできません。
1.4.1. OpenShift Container Platform での FIPS 検証
OpenShift Container Platform は、それが使用するオペレーティングシステムのコンポーネント用に RHEL および RHCOS 内の特定の FIPS 検証済みまたは進行中のモジュール (Modules in Process) モジュールを使用します。RHEL8 core crypto components を参照してください。たとえば、ユーザーが SSH を使用して OpenShift Container Platform クラスターおよびコンテナーに接続する場合、その接続は適切に暗号化されます。
OpenShift Container Platform コンポーネントは Go で作成され、Red Hat の golang コンパイラーを使用してビルドされます。クラスターの FIPS モードを有効にすると、暗号署名を必要とするすべての OpenShift Container Platform コンポーネントは RHEL および RHCOS 暗号ライブラリーを呼び出します。
属性 | 制限事項 |
---|---|
RHEL 8 および RHCOS オペレーティングシステムでの FIPS サポート。 | FIPS 実装は、ハッシュ関数を計算し、そのハッシュに基づくキーを検証する単一の機能を提供しません。この制限については、今後の OpenShift Container Platform リリースで継続的に評価され、改善されます。 |
CRI-O ランタイムの FIPS サポート。 | |
OpenShift Container Platform サービスの FIPS サポート。 | |
RHEL 8 および RHCOS バイナリーおよびイメージから取得される FIPS 検証済みまたは進行中のモジュール (Modules in Process) 暗号化モジュールおよびアルゴリズム。 | |
FIPS と互換性のある golang コンパイラーの使用。 | TLS FIPS サポートは完全に実装されていませんが、今後の OpenShift Container Platform リリースで予定されています。 |
複数のアーキテクチャー間の FIPS サポート。 |
FIPS は現在、 |
1.4.2. クラスターが使用するコンポーネントでの FIPS サポート
OpenShift Container Platform クラスター自体は FIPS 検証済みまたは進行中のモジュール (Modules in Process) モジュールを使用しますが、OpenShift Container Platform クラスターをサポートするシステムが暗号化の FIPS 検証済みまたは進行中のモジュール (Modules in Process) モジュールを使用していることを確認してください。
1.4.2.1. etcd
etcd に保存されるシークレットが FIPS 検証済みまたは進行中のモジュール (Modules in Process) の暗号を使用できるようにするには、ノードを FIPS モードで起動します。クラスターを FIPS モードでインストールした後に、FIPS 承認の aes cbc
暗号アルゴリズムを使用して etcd データを暗号化 できます。
1.4.2.2. ストレージ
ローカルストレージの場合は、RHEL が提供するディスク暗号化または RHEL が提供するディスク暗号化を使用する Container Native Storage を使用します。RHEL が提供するディスク暗号を使用するボリュームにすべてのデータを保存し、クラスター用に FIPS モードを有効にすることで、移動しないデータと移動するデータまたはネットワークデータは FIPS の検証済みまたは進行中のモジュール (Modules in Process) の暗号化によって保護されます。ノードのカスタマイズ で説明されているように、各ノードのルートファイルシステムを暗号化するようにクラスターを設定できます。
1.4.2.3. ランタイム
コンテナーに対して FIPS 検証済みまたは進行中のモジュール (Modules in Process) 暗号モジュールを使用しているホストで実行されていることを認識させるには、CRI-O を使用してランタイムを管理します。
1.4.3. FIPS モードでのクラスターのインストール
FIPS モードでクラスターをインストールするには、必要なインフラストラクチャーにカスタマイズされたクラスターをインストールする方法の説明に従ってください。クラスターをデプロイする前に、fips: true
を install-config.yaml
ファイルに設定していることを確認します。
クラスターで FIPS モードを有効にするには、FIPS モードで動作するように設定された RHEL コンピューターからインストールプログラムを実行する必要があります。RHEL での FIPS モードの設定の詳細は、FIPS モードでのシステムのインストール を参照してください。
Azure File ストレージを使用している場合、FIPS モードを有効にすることはできません。
AES CBC
暗号化を etcd データストアに適用するには、クラスターをインストールした後に etcd データの暗号化 プロセスを実行してください。
RHEL ノードをクラスターに追加する場合は、初回の起動前に FIPS モードをマシン上で有効にしていることを確認してください。Adding RHEL compute machines to an OpenShift Container Platform cluster および RHEL 8 ドキュメントの Enabling FIPS Mode を参照してください。
第2章 非接続インストールミラーリング
2.1. 非接続インストールミラーリングについて
ミラーレジストリーを使用して、クラスターが、外部コンテンツに対する組織の制御条件を満たすコンテナーイメージのみを使用するようにすることができます。ネットワークが制限された環境でプロビジョニングするインフラストラクチャーにクラスターをインストールする前に、必要なコンテナーイメージをその環境にミラーリングする必要があります。コンテナーイメージをミラーリングするには、ミラーリング用のレジストリーが必要です。
2.1.1. ミラーレジストリーの作成
Red Hat Quay などのコンテナーイメージレジストリーがすでにある場合は、それをミラーレジストリーとして使用できます。レジストリーをまだ持っていない場合は、Red Hat OpenShift のミラーレジストリー を使用して、ミラーレジストリーを作成 できます。
2.1.2. 非接続インストールのイメージのミラーリング
以下の手順のいずれかを使用して、OpenShift Container Platform イメージリポジトリーをミラーレジストリーにミラーリングできます。
2.2. Red Hat OpenShift 導入用のミラーレジストリーを使用したミラーレジストリーの作成
Red Hat OpenShift 導入用のミラーレジストリー は、切断されたインストールに必要な OpenShift Container Platform のコンテナーイメージのミラーリングターゲットとして使用できる小規模で合理化されたコンテナーレジストリーです。
Red Hat Quay などのコンテナーイメージレジストリーがすでにある場合は、このセクションをスキップして、OpenShift Container Platform イメージリポジトリーのミラーリング に直接進むことができます。
2.2.1. 前提条件
- OpenShift Container Platform サブスクリプション
- Podman 3.4.2 以降および OpenSSL がインストールされている Red Hat Enterprise Linux (RHEL) 8 および 9。
- Red Hat Quay サービスの完全修飾ドメイン名。DNS サーバーを介して解決する必要があります。
- ターゲットホストでのキーベースの SSH 接続。SSH キーは、ローカルインストール用に自動的に生成されます。リモートホストの場合は、独自の SSH キーを生成する必要があります。
- vCPU 2 つ以上。
- RAM 8 GB。
OpenShift Container Platform 4.15 リリースイメージ用に約 12 GB、または OpenShift Container Platform 4.15 リリースイメージおよび OpenShift Container Platform 4.15 Red Hat Operator イメージ用に約 358 GB。ストリームあたり最大 1 TB 以上が推奨されます。
重要これらの要件は、リリースイメージと Operator イメージのみを使用したローカルテスト結果に基づいています。ストレージ要件は、組織のニーズによって異なります。たとえば、複数の z-stream をミラーリングする場合は、より多くのスペースが必要になることがあります。標準の Red Hat Quay 機能 または適切な API コールアウト を使用して不要なイメージを削除し、スペースを解放できます。
2.2.2. Red Hat OpenShift 導入用のミラーレジストリー
OpenShift Container Platform の切断されたデプロイメントの場合に、クラスターのインストールを実行するためにコンテナーレジストリーが必要です。このようなクラスターで実稼働レベルのレジストリーサービスを実行するには、別のレジストリーデプロイメントを作成して最初のクラスターをインストールする必要があります。Red Hat OpenShift 導入用のミラーレジストリー は、このニーズに対応し、すべての OpenShift サブスクリプションに含まれています。これは、OpenShift コンソールの ダウンロード ページからダウンロードできます。
Red Hat OpenShift 導入用のミラーレジストリー を使用すると、ユーザーは、mirror-registry
コマンドラインインターフェイス (CLI) ツールを使用して、Red Hat Quay の小規模バージョンとその必要なコンポーネントをインストールできます。Red Hat OpenShift 導入用のミラーレジストリー は、事前設定されたローカルストレージとローカルデータベースを使用して自動的にデプロイされます。また、このレジストリーには、自動生成されたユーザー認証情報とアクセス許可も含まれており、単一の入力セットを使用するだけで開始でき、追加の設定を選択する必要はありません。
Red Hat OpenShift のミラーレジストリー は、事前に決定されたネットワーク設定を提供し、成功時にデプロイされたコンポーネントの認証情報とアクセス URL を報告します。完全修飾ドメイン名 (FQDN) サービス、スーパーユーザー名とパスワード、カスタム TLS 証明書などのオプションの設定入力のセットも少しだけ含まれています。これにより、ユーザーはコンテナーレジストリーを利用できるため、制限されたネットワーク環境で OpenShift Container Platform を実行するときに、すべての OpenShift Container Platform リリースコンテンツのオフラインミラーを簡単に作成できます。
インストール環境で別のコンテナーレジストリーがすでに使用可能な場合、Red Hat OpenShift 導入用のミラーレジストリー の使用はオプションです。
2.2.2.1. Red Hat OpenShift のミラーレジストリーに関する制限
Red Hat OpenShift のミラーレジストリー には次の制限が適用されます。
- Red Hat OpenShift のミラーレジストリー は高可用性レジストリーではなく、ローカルファイルシステムストレージのみがサポートされます。Red Hat Quay や OpenShift Container Platform の内部イメージレジストリーを置き換えることを目的としたものではありません。
- Red Hat OpenShift のミラーレジストリー は、Red Hat Quay の実稼働デプロイメントの代替となることを意図したものではありません。
Red Hat OpenShift のミラーレジストリー は、Release イメージや Red Hat Operator イメージなど、接続されていない OpenShift Container Platform クラスターのインストールに必要なイメージをホストする場合にのみサポートされます。Red Hat Enterprise Linux (RHEL) マシンのローカルストレージを使用して、RHEL でサポートされるストレージは、Red Hat OpenShift 導入用のミラーレジストリー でサポートされます。
注記Red Hat OpenShift のミラーレジストリー はローカルストレージを使用します。そのため、イメージをミラーリングするときには、消費されるストレージの使用量に常に注意し、潜在的な問題を軽減するために Red Hat Quay のガベージコレクション機能を使用してください。この機能の詳細は、「Red Hat Quay ガベージコレクション」を参照してください。
- ブートストラップ目的で Red Hat OpenShift のミラーレジストリー にプッシュされる Red Hat 製品イメージのサポートは、各製品の有効なサブスクリプションでカバーされます。ブートストラップエクスペリエンスをさらに有効にする例外のリストは、セルフマネージド Red Hat OpenShift のサイジングおよびサブスクリプションガイド に記載されています。
- お客様が作成したコンテンツは、Red Hat OpenShift のミラーレジストリー でホストしないでください。
- クラスターのグループの更新時にクラスターが複数あると単一障害点を生み出す可能性があるため、複数のクラスターで Red Hat OpenShift のミラーレジストリー を使用することは推奨されません。Red Hat OpenShift 導入用のミラーレジストリーを活用して、OpenShift Container Platform コンテンツを他のクラスターに提供できる Red Hat Quay などの実稼働環境レベルの高可用性レジストリーをホストできるクラスターをインストールすることを推奨します。
2.2.3. Red Hat OpenShift 導入用のミラーレジストリーを使用したローカルホストでのミラーリング
この手順では、mirror-registry
インストーラーツールを使用して、Red Hat OpenShift 導入用のミラーレジストリーをローカルホストにインストールする方法を説明します。このツールを使用することで、ユーザーは、OpenShift Container Platform イメージのミラーを保存する目的で、ポート 443 で実行されるローカルホストレジストリーを作成できます。
mirror-registry
CLI ツールを使用してRed Hat OpenShift 導入用のミラーレジストリー をインストールすると、マシンにいくつかの変更が加えられます。インストール後、インストールファイル、ローカルストレージ、および設定バンドルを含む $HOME/quay-install
ディレクトリーが作成されます。デプロイ先がローカルホストである場合には、信頼できる SSH キーが生成され、コンテナーのランタイムが永続的になるようにホストマシン上の systemd ファイルが設定されます。さらに、init
という名前の初期ユーザーが、自動生成されたパスワードを使用して作成されます。すべてのアクセス認証情報は、インストール操作の最後に出力されます。
手順
-
OpenShift コンソールの ダウンロード ページにある Red Hat OpenShift 導入用のミラーレジストリー の最新バージョンは、
mirror-registry.tar.gz
パッケージをダウンロードしてください。 mirror-registry
ツールを使用して、現在のユーザーアカウントでローカルホストにRed Hat OpenShift 導入用のミラーレジストリー をインストールします。使用可能なフラグの完全なリストは、「Red Hat OpenShift フラグのミラーレジストリー」を参照してください。Copy to Clipboard Copied! Toggle word wrap Toggle overflow ./mirror-registry install \ --quayHostname <host_example_com> \ --quayRoot <example_directory_name>
$ ./mirror-registry install \ --quayHostname <host_example_com> \ --quayRoot <example_directory_name>
インストール中に生成されたユーザー名とパスワードを使用して、次のコマンドを実行してレジストリーにログインします。
Copy to Clipboard Copied! Toggle word wrap Toggle overflow podman login -u init \ -p <password> \ <host_example_com>:8443> \ --tls-verify=false
$ podman login -u init \ -p <password> \ <host_example_com>:8443> \ --tls-verify=false
1 - 1
- 生成された rootCA 証明書を信頼するようにシステムを設定して、
--tls-verify=false
の実行を回避できます。詳細は、「SSL を使用した Red Hat Quay への接続の保護」および「認証局を信頼するようにシステムを設定する」を参照してください。
注記インストール後、
https:// <host.example.com>:8443
の UI にアクセスしてログインすることもできます。ログイン後、OpenShift Container Platform イメージをミラーリングできます。必要に応じて、このドキュメントの「OpenShift Container Platform イメージリポジトリーのミラーリング」または、「非接続クラスターで使用する Operator カタログのミラーリング」セクションを参照してください。
注記ストレージレイヤーの問題が原因でRed Hat OpenShift 導入用のミラーレジストリー で保存されたイメージに問題がある場合は、OpenShift Container Platform イメージを再ミラーリングするか、より安定したストレージにミラーレジストリーを再インストールできます。
2.2.4. ローカルホストからの Red Hat OpenShift 導入用のミラーレジストリーの更新
この手順では、upgrade
コマンドを使用してローカルホストから Red Hat OpenShift 導入用のミラーレジストリー を更新する方法を説明します。最新バージョンに更新することで、新機能、バグ修正およびセキュリティー脆弱性の修正が保証されます。
バージョン 1 からバージョン 2 にアップグレードする場合は、次の制約に注意してください。
-
SQLite では複数の書き込みが許可されていないため、ワーカー数が
1
に設定されます。 - mirror registry for Red Hat OpenShift のユーザーインターフェイス (UP) を使用しないでください。
-
アップグレード中は
sqlite-storage
Podman ボリュームにアクセスしないでください。 - アップグレードプロセス中にミラーレジストリーが再起動されるため、ミラーレジストリーのダウンタイムが断続的に発生します。
-
PostgreSQL のデータは、復旧用に
/$HOME/quay-instal/quay-postgres-backup/
ディレクトリーにバックアップされます。
前提条件
- Red Hat OpenShift 導入用のミラーレジストリー をローカルホストにインストールしている。
手順
mirror registry for Red Hat OpenShift を 1.3 → 2.y にアップグレードする場合、インストールディレクトリーがデフォルトの
/etc/quay-install
である場合は、次のコマンドを入力できます。Copy to Clipboard Copied! Toggle word wrap Toggle overflow sudo ./mirror-registry upgrade -v
$ sudo ./mirror-registry upgrade -v
注記-
Red Hat OpenShift のミラーレジストリー は、Quay ストレージ、Postgres データ、および
/etc/quay-install
データの Podman ボリュームを新しい$HOME/quay-install
の場所に移行します。これにより、今後のアップグレード時に--quayRoot
フラグなしで Red Hat OpenShift のミラーレジストリー を使用できます。 -
./mirr-registry upgrade -v
フラグを使用して Red Hat OpenShift のミラーレジストリー をアップグレードする場合は、ミラーレジストリーの作成時に使用したものと同じ認証情報を含める必要があります。たとえば、Red Hat OpenShift 導入用のミラーレジストリー を--quayHostname<host_example_com>
および--quayRoot<example_directory_name>
でインストールした場合、ミラーレジストリーを適切にアップグレードするには、その文字列を含める必要があります。
-
Red Hat OpenShift のミラーレジストリー は、Quay ストレージ、Postgres データ、および
mirror registry for Red Hat OpenShift を 1.3 → 2.y にアップグレードする場合、1.y デプロイメントでカスタムの quay 設定とストレージディレクトリーを使用していた場合は、
--quayRoot
フラグと--quayStorage
フラグを渡す必要があります。以下に例を示します。Copy to Clipboard Copied! Toggle word wrap Toggle overflow sudo ./mirror-registry upgrade --quayHostname <host_example_com> --quayRoot <example_directory_name> --quayStorage <example_directory_name>/quay-storage -v
$ sudo ./mirror-registry upgrade --quayHostname <host_example_com> --quayRoot <example_directory_name> --quayStorage <example_directory_name>/quay-storage -v
mirror registry for Red Hat OpenShift を 1.3 → 2.y にアップグレードし、カスタムの SQLite ストレージパスを指定する場合は、
--sqliteStorage
フラグを渡す必要があります。次に例を示します。Copy to Clipboard Copied! Toggle word wrap Toggle overflow sudo ./mirror-registry upgrade --sqliteStorage <example_directory_name>/sqlite-storage -v
$ sudo ./mirror-registry upgrade --sqliteStorage <example_directory_name>/sqlite-storage -v
2.2.5. Red Hat OpenShift 導入用のミラーレジストリーを使用したリモートホストでのミラーリング
この手順では、mirror-registry
ツールを使用して、Red Hat OpenShift 導入用のミラーレジストリー をリモートホストにインストールする方法を説明します。そうすることで、ユーザーは OpenShift Container Platform イメージのミラーを保持するレジストリーを作成できます。
mirror-registry
CLI ツールを使用してRed Hat OpenShift 導入用のミラーレジストリー をインストールすると、マシンにいくつかの変更が加えられます。インストール後、インストールファイル、ローカルストレージ、および設定バンドルを含む $HOME/quay-install
ディレクトリーが作成されます。デプロイ先がローカルホストである場合には、信頼できる SSH キーが生成され、コンテナーのランタイムが永続的になるようにホストマシン上の systemd ファイルが設定されます。さらに、init
という名前の初期ユーザーが、自動生成されたパスワードを使用して作成されます。すべてのアクセス認証情報は、インストール操作の最後に出力されます。
手順
-
OpenShift コンソールの ダウンロード ページにある Red Hat OpenShift 導入用のミラーレジストリー の最新バージョンは、
mirror-registry.tar.gz
パッケージをダウンロードしてください。 mirror-registry
ツールを使用して、現在のユーザーアカウントでローカルホストにRed Hat OpenShift 導入用のミラーレジストリー をインストールします。使用可能なフラグの完全なリストは、「Red Hat OpenShift フラグのミラーレジストリー」を参照してください。Copy to Clipboard Copied! Toggle word wrap Toggle overflow ./mirror-registry install -v \ --targetHostname <host_example_com> \ --targetUsername <example_user> \ -k ~/.ssh/my_ssh_key \ --quayHostname <host_example_com> \ --quayRoot <example_directory_name>
$ ./mirror-registry install -v \ --targetHostname <host_example_com> \ --targetUsername <example_user> \ -k ~/.ssh/my_ssh_key \ --quayHostname <host_example_com> \ --quayRoot <example_directory_name>
インストール中に生成されたユーザー名とパスワードを使用して、次のコマンドを実行してミラーレジストリーにログインします。
Copy to Clipboard Copied! Toggle word wrap Toggle overflow podman login -u init \ -p <password> \ <host_example_com>:8443> \ --tls-verify=false
$ podman login -u init \ -p <password> \ <host_example_com>:8443> \ --tls-verify=false
1 - 1
- 生成された rootCA 証明書を信頼するようにシステムを設定して、
--tls-verify=false
の実行を回避できます。詳細は、「SSL を使用した Red Hat Quay への接続の保護」および「認証局を信頼するようにシステムを設定する」を参照してください。
注記インストール後、
https:// <host.example.com>:8443
の UI にアクセスしてログインすることもできます。ログイン後、OpenShift Container Platform イメージをミラーリングできます。必要に応じて、このドキュメントの「OpenShift Container Platform イメージリポジトリーのミラーリング」または、「非接続クラスターで使用する Operator カタログのミラーリング」セクションを参照してください。
注記ストレージレイヤーの問題が原因でRed Hat OpenShift 導入用のミラーレジストリー で保存されたイメージに問題がある場合は、OpenShift Container Platform イメージを再ミラーリングするか、より安定したストレージにミラーレジストリーを再インストールできます。
2.2.6. リモートホストからの Red Hat OpenShift 導入用のミラーレジストリーの更新
この手順では、upgrade
コマンドを使用してリモートホストから Red Hat OpenShift 導入用のミラーレジストリー を更新する方法を説明します。最新バージョンへの更新により、バグ修正およびセキュリティー脆弱性の修正が確保されます。
バージョン 1 からバージョン 2 にアップグレードする場合は、次の制約に注意してください。
-
SQLite では複数の書き込みが許可されていないため、ワーカー数が
1
に設定されます。 - mirror registry for Red Hat OpenShift のユーザーインターフェイス (UP) を使用しないでください。
-
アップグレード中は
sqlite-storage
Podman ボリュームにアクセスしないでください。 - アップグレードプロセス中にミラーレジストリーが再起動されるため、ミラーレジストリーのダウンタイムが断続的に発生します。
-
PostgreSQL のデータは、復旧用に
/$HOME/quay-instal/quay-postgres-backup/
ディレクトリーにバックアップされます。
前提条件
- Red Hat OpenShift 導入用のミラーレジストリー をリモートホストにインストールしている。
手順
Red Hat OpenShift 導入用のミラーレジストリー をリモートホストからアップグレードするには、以下のコマンドを入力します。
Copy to Clipboard Copied! Toggle word wrap Toggle overflow ./mirror-registry upgrade -v --targetHostname <remote_host_url> --targetUsername <user_name> -k ~/.ssh/my_ssh_key
$ ./mirror-registry upgrade -v --targetHostname <remote_host_url> --targetUsername <user_name> -k ~/.ssh/my_ssh_key
注記./mirror-registry upgrade -v
フラグを使用して Red Hat OpenShift 導入用のミラーレジストリー をアップグレードするユーザーは、ミラーレジストリーの作成時に使用したものと同じクレデンシャルを含める必要があります。たとえば、Red Hat OpenShift 導入用のミラーレジストリー を--quayHostname<host_example_com>
および--quayRoot<example_directory_name>
でインストールした場合、ミラーレジストリーを適切にアップグレードするには、その文字列を含める必要があります。mirror registry for Red Hat OpenShift を 1.3 → 2.y にアップグレードし、カスタムの SQLite ストレージパスを指定する場合は、
--sqliteStorage
フラグを渡す必要があります。次に例を示します。Copy to Clipboard Copied! Toggle word wrap Toggle overflow ./mirror-registry upgrade -v --targetHostname <remote_host_url> --targetUsername <user_name> -k ~/.ssh/my_ssh_key --sqliteStorage <example_directory_name>/quay-storage
$ ./mirror-registry upgrade -v --targetHostname <remote_host_url> --targetUsername <user_name> -k ~/.ssh/my_ssh_key --sqliteStorage <example_directory_name>/quay-storage
2.2.7. Red Hat OpenShift SSL/TLS 証明書のミラーレジストリーの置き換え
Red Hat OpenShift のミラーレジストリー の SSL/TLS 証明書を更新する必要がある場合もあるはずです。これは、以下のシナリオで役に立ちます。
- 現在の Red Hat OpenShift のミラーレジストリー 証明書を置き換える場合。
- 以前の Red Hat OpenShift のミラーレジストリー インストールと同じ証明書を使用している場合。
- Red Hat OpenShift のミラーレジストリー 証明書を定期的に更新している場合。
Red Hat OpenShift のミラーレジストリー の SSL/TLS 証明書を置き換えるには、次の手順を使用します。
前提条件
-
OpenShift コンソールの ダウンロード ページから
./mirror-registry
バイナリーをダウンロードしている。
手順
次のコマンドを入力して、Red Hat OpenShift のミラーレジストリー をインストールします。
Copy to Clipboard Copied! Toggle word wrap Toggle overflow ./mirror-registry install \ --quayHostname <host_example_com> \ --quayRoot <example_directory_name>
$ ./mirror-registry install \ --quayHostname <host_example_com> \ --quayRoot <example_directory_name>
Red Hat OpenShift のミラーレジストリー が
$HOME/quay-install
ディレクトリーにインストールされます。-
新しい認証局 (CA) バンドルを準備し、新しい
ssl.key
およびssl.crt
キーファイルを生成します。詳細は、Red Hat Quay への接続を保護するための SSL/TLS の使用 を参照してください。 次のコマンドを入力して、
/$HOME/quay-install
に環境変数 (QUAY
など) を割り当てます。Copy to Clipboard Copied! Toggle word wrap Toggle overflow export QUAY=/$HOME/quay-install
$ export QUAY=/$HOME/quay-install
次のコマンドを入力して、新しい
ssl.crt
ファイルを/$HOME/quay-install
ディレクトリーにコピーします。Copy to Clipboard Copied! Toggle word wrap Toggle overflow cp ~/ssl.crt $QUAY/quay-config
$ cp ~/ssl.crt $QUAY/quay-config
次のコマンドを入力して、新しい
ssl.key
ファイルを/$HOME/quay-install
ディレクトリーにコピーします。Copy to Clipboard Copied! Toggle word wrap Toggle overflow cp ~/ssl.key $QUAY/quay-config
$ cp ~/ssl.key $QUAY/quay-config
次のコマンドを入力して、
quay-app
アプリケーション Pod を再起動します。Copy to Clipboard Copied! Toggle word wrap Toggle overflow systemctl restart quay-app
$ systemctl restart quay-app
2.2.8. Red Hat OpenShift 導入用のミラーレジストリーのアンインストール
次のコマンドを実行して、ローカルホストから Red Hat OpenShift 導入用のミラーレジストリー をアンインストールできます。
Copy to Clipboard Copied! Toggle word wrap Toggle overflow ./mirror-registry uninstall -v \ --quayRoot <example_directory_name>
$ ./mirror-registry uninstall -v \ --quayRoot <example_directory_name>
注記-
Red Hat OpenShift 導入用のミラーレジストリー を削除しようとと、削除前にユーザーにプロンプトが表示されます。
--autoApprove
を使用して、このプロンプトをスキップできます。 -
--quayRoot
フラグを指定して Red Hat OpenShift 導入用のミラーレジストリー をインストールした場合には、アンインストール時に--quayRoot
フラグを含める必要があります。たとえば、Red Hat OpenShift 導入用のミラーレジストリー のインストールで--quayRoot example_directory_name
を指定した場合には、この文字列を追加して、ミラーレジストリーを適切にアンインストールする必要があります。
-
Red Hat OpenShift 導入用のミラーレジストリー を削除しようとと、削除前にユーザーにプロンプトが表示されます。
2.2.9. mirror registry for Red Hat OpenShift のフラグ
mirror registry for Red Hat OpenShift では、次のフラグを使用できます。
Flags | 説明 |
---|---|
|
対話型プロンプトを無効にするブール値。 |
| Quay のインストール中に作成された init ユーザーのパスワード。空白を含まず、8 文字以上にする必要があります。 |
|
初期ユーザーのユーザー名を表示します。指定しない場合、デフォルトで |
| インストール、アンインストール、およびアップグレードコマンドの実行時に、ユーザーがカラーシーケンスを無効にして、それを Ansible に伝播できるようにします。 |
|
クライアントがレジストリーへの接続に使用するミラーレジストリーの完全修飾ドメイン名。Quay |
|
Quay 永続ストレージデータが保存されるフォルダー。デフォルトは |
|
|
|
SQLite データベースデータが保存されるフォルダー。指定されていない場合は、デフォルトで |
|
SSH ID キーのパス。指定しない場合、デフォルトは |
|
SSL/TLS 公開鍵/証明書へのパス。デフォルトは |
|
|
|
HTTPS 通信に使用される SSL/TLS 秘密鍵へのパス。デフォルトは |
|
Quay のインストール先のホスト名。デフォルトは |
|
SSH に使用するターゲットホストのユーザー。デフォルトは |
| デバッグログと Ansible Playbook の出力を表示します。 |
| mirror registry for Red Hat OpenShift のバージョンを表示します。 |
-
システムのパブリック DNS 名がローカルホスト名と異なる場合は、
--quayHostname
を変更する必要があります。さらに、--quayHostname
フラグは、IP アドレスを使用したインストールをサポートしていません。ホスト名を使用してインストールする必要があります。 -
--sslCheckSkip
は、ミラーレジストリーがプロキシーの背後に設定されており、公開されているホスト名が内部の Quay ホスト名と異なる場合に使用されます。また、インストール中に、指定した Quay ホスト名に対して証明書の検証を行わない場合にも使用できます。
2.2.10. mirror registry for Red Hat OpenShift のリリースノート
mirror registry for Red Hat OpenShift は、非接続環境でのインストールに使用する OpenShift Container Platform の必要なコンテナーイメージをミラーリングするためのターゲットとして使用できる、小規模で効率的なコンテナーレジストリーです。
以下のリリースノートは、OpenShift Container Platform の mirror registry for Red Hat OpenShift の開発状況を記録したものです。
2.2.10.1. mirror registry for Red Hat OpenShift 2.0 のリリースノート
以下のセクションでは、mirror registry for Red Hat OpenShift の 2.0 リリースの詳細をそれぞれ説明します。
2.2.10.1.1. Mirror registry for Red Hat OpenShift 2.0.1
発行日:2024 年 9 月 26 日
Red Hat Openshift 導入 用のミラーレジストリー が Red Hat Quay 3.12.1 で利用できるようになりました。
Red Hat Openshift 導入用のミラーレジストリー については、以下のアドバイザリーを利用できます。
2.2.10.1.2. Mirror registry for Red Hat OpenShift 2.0.0
発行日: 2024 年 9 月 3 日
Red Hat Openshift 導入 用のミラーレジストリー が Red Hat Quay 3.12.0 で利用できるようになりました。
Red Hat Openshift 導入用のミラーレジストリー については、以下のアドバイザリーを利用できます。
2.2.10.1.2.1. 新機能
mirror registry for Red Hat OpenShift のリリースに伴い、内部データベースが PostgreSQL から SQLite にアップグレードされました。その結果、データがデフォルトで
sqlite-storage
Podman ボリュームに保存されるようになり、tarball 全体のサイズが 300 MB 削減されました。新規インストールではデフォルトで SQLite が使用されます。バージョン 2.0 にアップグレードする前に、環境に応じて「ローカルホストからの mirror registry for Red Hat OpenShift の更新」または「リモートホストからの mirror registry for Red Hat OpenShift の更新」を参照してください。
-
新しい機能フラグ
--sqliteStorage
が追加されました。このフラグを使用すると、SQLite データベースのデータを保存する場所を手動で設定できます。
2.2.10.2. Mirror registry for Red Hat OpenShift 1.3 のリリースノート
以下のセクションでは、Mirror registry for Red Hat OpenShift の 1.3.z リリースの詳細をそれぞれ説明します。
2.2.10.2.1. Mirror registry for Red Hat OpenShift 1.3.11
発行日: 2024 年 4 月 23 日
Red Hat OpenShift のミラーレジストリー が、Red Hat Quay 3.8.15 で利用できるようになりました。
Red Hat OpenShift 導入用のミラーレジストリー では、以下のアドバイザリーを使用できます。
2.2.10.2.2. Mirror registry for Red Hat OpenShift 1.3.10
発行日: 2023 年 12 月 7 日
Red Hat OpenShift のミラーレジストリー が、Red Hat Quay 3.8.14 で利用できるようになりました。
Red Hat OpenShift 導入用のミラーレジストリー では、以下のアドバイザリーを使用できます。
2.2.10.2.3. Red Hat OpenShift 1.3.9 のミラーレジストリー
発行日: 2023-09-19
Red Hat OpenShift のミラーレジストリー が、Red Hat Quay 3.8.12 で利用できるようになりました。
Red Hat OpenShift 導入用のミラーレジストリー では、以下のアドバイザリーを使用できます。
2.2.10.2.4. Red Hat OpenShift 1.3.8 のミラーレジストリー
発行日: 2023 年 8 月 16 日
Red Hat OpenShift のミラーレジストリー が、Red Hat Quay 3.8.11 で利用できるようになりました。
Red Hat OpenShift 導入用のミラーレジストリー では、以下のアドバイザリーを使用できます。
2.2.10.2.5. Red Hat OpenShift 1.3.7 のミラーレジストリー
発行日: 2023-07-19
Red Hat OpenShift のミラーレジストリー が、Red Hat Quay 3.8.10 で利用できるようになりました。
Red Hat OpenShift 導入用のミラーレジストリー では、以下のアドバイザリーを使用できます。
2.2.10.2.6. Red Hat OpenShift 1.3.6 のミラーレジストリー
発行日: 2023-05-30
Red Hat OpenShift のミラーレジストリー が、Red Hat Quay 3.8.8 で利用できるようになりました。
Red Hat OpenShift 導入用のミラーレジストリー では、以下のアドバイザリーを使用できます。
2.2.10.2.7. Red Hat OpenShift 1.3.5 のミラーレジストリー
発行日: 2023-05-18
Red Hat OpenShift のミラーレジストリー が、Red Hat Quay 3.8.7 で利用できるようになりました。
Red Hat OpenShift 導入用のミラーレジストリー では、以下のアドバイザリーを使用できます。
2.2.10.2.8. Red Hat OpenShift 1.3.4 のミラーレジストリー
発行日: 2023-04-25
Red Hat OpenShift のミラーレジストリー が、Red Hat Quay 3.8.6 で利用できるようになりました。
Red Hat OpenShift 導入用のミラーレジストリー では、以下のアドバイザリーを使用できます。
2.2.10.2.9. Red Hat OpenShift 1.3.3 のミラーレジストリー
発行: 2023-04-05
Red Hat OpenShift のミラーレジストリー が Red Hat Quay 3.8.5 で利用できるようになりました。
Red Hat OpenShift 導入用のミラーレジストリー では、以下のアドバイザリーを使用できます。
2.2.10.2.10. Red Hat OpenShift 1.3.2 のミラーレジストリー
発行: 2023-03-21
Red Hat OpenShift のミラーレジストリー は、Red Hat Quay 3.8.4 で利用できるようになりました。
Red Hat OpenShift 導入用のミラーレジストリー では、以下のアドバイザリーを使用できます。
2.2.10.2.11. Red Hat OpenShift 1.3.1 のミラーレジストリー
発行日: 2023-03-7
Red Hat OpenShift のミラーレジストリー は、Red Hat Quay 3.8.3 で利用できるようになりました。
Red Hat OpenShift 導入用のミラーレジストリー では、以下のアドバイザリーを使用できます。
2.2.10.2.12. Red Hat OpenShift 1.3.0 のミラーレジストリー
発行日: 2023-02-20
Red Hat OpenShift のミラーレジストリー が Red Hat Quay 3.8.1 で利用できるようになりました。
Red Hat OpenShift 導入用のミラーレジストリー では、以下のアドバイザリーを使用できます。
2.2.10.2.12.1. 新機能
- Red Hat OpenShift のミラーレジストリー が Red Hat Enterprise Linux (RHEL) 9 インストールでサポートされるようになりました。
Red Hat OpenShift ローカルホストインストールのミラーレジストリー で IPv6 サポートが利用できるようになりました。
Red Hat OpenShift リモートホストインストールのミラーレジストリー では、IPv6 は現在サポートされていません。
-
新しい機能フラグ
--quayStorage
が追加されました。このフラグを指定すると、Quay 永続ストレージの場所を手動で設定できます。 -
新しい機能フラグ
--pgStorage
が追加されました。このフラグを指定すると、Postgres 永続ストレージの場所を手動で設定できます。 以前は、Red Hat OpenShift のミラーレジストリー をインストールするには、root 権限 (
sudo
) が必要でした。今回の更新により、Red Hat OpenShift のミラーレジストリー をインストールするために、sudo
は不要になりました。Red Hat OpenShift のミラーレジストリー を
sudo
でインストールすると、インストールファイル、ローカルストレージ、および設定バンドルを含む/etc/quay-install
ディレクトリーが作成されていました。sudo
要件の削除により、インストールファイルと設定バンドルが$HOME/quay-install
にインストールされるようになりました。Postgres や Quay などのローカルストレージは、Podman によって自動的に作成される名前付きボリュームに格納されるようになりました。これらのファイルが保存されているデフォルトのディレクトリーを上書きするには、Red Hat OpenShift のミラーレジストリー のコマンドライン引数を使用できます。Red Hat OpenShift コマンドライン引数のミラーレジストリー の詳細は、「Red Hat OpenShift フラグのミラーレジストリー」を参照してください。
2.2.10.2.12.2. バグ修正
-
以前のバージョンでは、Red Hat OpenShift のミラーレジストリー をアンインストールしようとすると、次のエラーが返される可能性がありました。
["Error: no container with name or ID \"quay-postgres\" found: no such container"], "stdout": "", "stdout_lines": []*
今回の更新により、Red Hat OpenShift サービスのミラーレジストリー を停止してアンインストールする順序が変更され、Red Hat OpenShift のミラーレジストリー をアンインストールするときにエラーが発生しなくなりました。詳細は、PROJQUAY-4629 を参照してください。
2.2.10.3. Mirror registry for Red Hat OpenShift 1.2 のリリースノート
以下のセクションでは、Mirror registry for Red Hat OpenShift の 1.3.z リリースの詳細をそれぞれ説明します。
2.2.10.3.1. Red Hat OpenShift 1.2.9 のミラーレジストリー
Red Hat OpenShift 導入用のミラーレジストリー が Red Hat Quay 3.7.10 で利用できるようになりました。
Red Hat OpenShift 導入用のミラーレジストリー では、以下のアドバイザリーを使用できます。
2.2.10.3.2. Red Hat OpenShift 1.2.8 のミラーレジストリー
Red Hat OpenShift 導入用のミラーレジストリー が Red Hat Quay 3.7.9 で利用できるようになりました。
Red Hat OpenShift 導入用のミラーレジストリー では、以下のアドバイザリーを使用できます。
2.2.10.3.3. Red Hat OpenShift 1.2.7 のミラーレジストリー
Red Hat OpenShift 導入用のミラーレジストリー が Red Hat Quay 3.7.8 で利用できるようになりました。
Red Hat OpenShift 導入用のミラーレジストリー では、以下のアドバイザリーを使用できます。
2.2.10.3.3.1. バグ修正
-
以前は、
getFQDN()
は完全修飾ドメイン名 (FQDN) ライブラリーに依存してその FQDN を決定し、FQDN ライブラリーは/etc/hosts
フォルダーを直接読み取ろうとしました。その結果、一部の Red Hat Enterprise Linux CoreOS (RHCOS) インストールで、一般的でない DNS 設定を使用すると、FQDN ライブラリーのインストールが失敗し、インストールが中止されました。今回の更新により、Red Hat OpenShift 導入用のミラーレジストリー はhostname
を使用して FQDN を決定します。その結果、FQDN ライブラリーはインストールに失敗しません。(PROJQUAY-4139)
2.2.10.3.4. Red Hat OpenShift 1.2.6 のミラーレジストリー
Red Hat OpenShift 導入用のミラーレジストリー が Red Hat Quay 3.7.7 で利用できるようになりました。
Red Hat OpenShift 導入用のミラーレジストリー では、以下のアドバイザリーを使用できます。
2.2.10.3.4.1. 新機能
新しい機能フラグ --no-color
(-c
) が追加されました。この機能フラグにより、インストール、アンインストール、およびアップグレードコマンドの実行時に、ユーザーはカラーシーケンスを無効にして、それを Ansible に伝播することができます。
2.2.10.3.5. Red Hat OpenShift 1.2.5 のミラーレジストリー
Red Hat OpenShift 導入用のミラーレジストリー が Red Hat Quay 3.7.6 で利用できるようになりました。
Red Hat OpenShift 導入用のミラーレジストリー では、以下のアドバイザリーを使用できます。
2.2.10.3.6. Red Hat OpenShift 1.2.4 のミラーレジストリー
Red Hat OpenShift 導入用のミラーレジストリー が Red Hat Quay 3.7.5 で利用できるようになりました。
Red Hat OpenShift 導入用のミラーレジストリー では、以下のアドバイザリーを使用できます。
2.2.10.3.7. Red Hat OpenShift 1.2.3 のミラーレジストリー
Red Hat OpenShift 導入用のミラーレジストリー が Red Hat Quay 3.7.4 で利用できるようになりました。
Red Hat OpenShift 導入用のミラーレジストリー では、以下のアドバイザリーを使用できます。
2.2.10.3.8. Red Hat OpenShift 1.2.2 のミラーレジストリー
Red Hat OpenShift 導入用のミラーレジストリー が Red Hat Quay 3.7.3 で利用できるようになりました。
Red Hat OpenShift 導入用のミラーレジストリー では、以下のアドバイザリーを使用できます。
2.2.10.3.9. Red Hat OpenShift 1.2.1 のミラーレジストリー
Red Hat OpenShift 導入用のミラーレジストリー が Red Hat Quay 3.7.2 で利用できるようになりました。
Red Hat OpenShift 導入用のミラーレジストリー では、以下のアドバイザリーを使用できます。
2.2.10.3.10. Red Hat OpenShift 1.2.0 のミラーレジストリー
Red Hat OpenShift 導入用のミラーレジストリー が Red Hat Quay 3.7.1 で利用できるようになりました。
Red Hat OpenShift 導入用のミラーレジストリー では、以下のアドバイザリーを使用できます。
2.2.10.3.10.1. バグ修正
-
以前は、Quay Pod Operator 内で実行されているすべてのコンポーネントとワーカーのログレベルが
DEBUG
に設定されていました。その結果、不要なスペースを消費する大量のトラフィックログが作成されました。今回の更新では、ログレベルがデフォルトでWARN
に設定され、トラフィック情報を減らして問題のシナリオに焦点を当てています。(PROJQUAY-3504)
2.2.10.4. Mirror registry for Red Hat OpenShift 1.1 のリリースノート
以下のセクションでは、Red Hat Openshift 導入用のミラーレジストリーの 1.1.0 リリースの詳細を説明します。
2.2.10.4.1. Red Hat OpenShift 1.1.0 のミラーレジストリー
Red Hat OpenShift 導入用のミラーレジストリー では、以下のアドバイザリーを使用できます。
2.2.10.4.1.1. 新機能
新しいコマンド
mirror-registry upgrade
が追加されました。このコマンドは、設定やデータに干渉することなく、すべてのコンテナーイメージをアップグレードします。注記以前に
quayRoot
がデフォルト以外に設定されていた場合は、それをアップグレードコマンドに渡す必要があります。
2.2.10.4.1.2. バグ修正
-
以前は、
quayHostname
またはtargetHostname
がない場合に、ローカルホスト名がデフォルトになることはありませんでした。今回の更新により、quayHostname
とtargetHostname
がない場合は、ローカルホスト名がデフォルトになります。(PROJQUAY-3079) -
以前は、コマンド
./mirror-registry --version
がunknown flag
エラーを返しました。現在は、./mirror-registry --version
を実行すると、Red Hat OpenShift 導入用のミラーレジストリー の現行バージョンが返されます。(PROJQUAY-3086) -
以前は、たとえば
./mirror-registry install --initUser <user_name> --initPassword <password> --verbose
を実行する場合など、ユーザーはインストール中にパスワードを設定できませんでした。今回の更新により、ユーザーはインストール中にパスワードを設定できるようになりました。(PROJQUAY-3149) - 以前は、Red Hat OpenShift 導入用のミラーレジストリー は、Pod が破棄された場合に Pod を再作成しませんでした。現在は、Pod が破棄された場合は Pod が再作成されます。(PROJQUAY-3261)
2.2.11. Red Hat OpenShift のミラーレジストリーのトラブルシューティング
Red Hat OpenShift のミラーレジストリー のトラブルシューティングに、ミラーレジストリーによってインストールされた systemd サービスのログを収集すると役立ちます。次のサービスがインストールされます。
- quay-app.service
- quay-postgres.service
- quay-redis.service
- quay-pod.service
前提条件
- Red Hat OpenShift のミラーレジストリー がインストールされている。
手順
root 権限で Red Hat OpenShift のミラーレジストリー をインストールした場合は、次のコマンドを入力して systemd サービスのステータス情報を取得できます。
Copy to Clipboard Copied! Toggle word wrap Toggle overflow sudo systemctl status <service>
$ sudo systemctl status <service>
標準ユーザーとして Red Hat OpenShift のミラーレジストリー をインストールした場合は、次のコマンドを入力して systemd サービスのステータス情報を取得できます。
Copy to Clipboard Copied! Toggle word wrap Toggle overflow systemctl --user status <service>
$ systemctl --user status <service>
2.2.12. 関連情報
2.3. 非接続インストールのイメージのミラーリング
クラスターが、外部コンテンツに対する組織の制限条件を満たすコンテナーイメージのみを使用するようにできますネットワークが制限された環境でプロビジョニングするインフラストラクチャーにクラスターをインストールする前に、必要なコンテナーイメージをその環境にミラーリングする必要があります。コンテナーイメージをミラーリングするには、ミラーリング用のレジストリーが必要です。
必要なコンテナーイメージを取得するには、インターネットへのアクセスが必要です。この手順では、ネットワークとインターネットの両方にアクセスできるミラーホストにミラーレジストリーを配置します。ミラーホストにアクセスできない場合は、非接続クラスターで使用する Operator カタログのミラーリング を使用して、ネットワークの境界を越えて移動できるデバイスにイメージをコピーします。
2.3.1. 前提条件
以下のレジストリーのいずれかなど、OpenShift Container Platform クラスターをホストする場所に Docker v2-2 をサポートするコンテナーイメージレジストリーが必要です。
Red Hat Quay のライセンスをお持ちの場合は、概念実証のため に、または Red Hat Quay Operator を使用 して Red Hat Quay をデプロイする方法を記載したドキュメントを参照してください。レジストリーの選択とインストールについてさらにサポートが必要な場合は、営業担当者または Red Hat サポートにお問い合わせください。
- コンテナーイメージレジストリーの既存のソリューションがまだない場合には、OpenShift Container Platform のサブスクライバーに Red Hat OpenShift 導入用のミラーレジストリー が提供されます。Red Hat OpenShift 導入用のミラーレジストリーはサブスクリプションに含まれており、切断されたインストールで OpenShift Container Platform で必須のコンテナーイメージのミラーリングに使用できる小規模なコンテナーレジストリーです。
2.3.2. ミラーレジストリーについて
OpenShift Container Platform のインストールとその後の製品更新に必要なイメージは、Red Hat Quay、JFrog Artifactory、Sonatype Nexus Repository、Harbor などのコンテナーミラーレジストリーにミラーリングできます。大規模なコンテナーレジストリーにアクセスできない場合は、OpenShift Container Platform サブスクリプションに含まれる小規模なコンテナーレジストリーである Red Hat OpenShift 導入用のミラーレジストリー を使用できます。
Red Hat Quay、Red Hat OpenShift 導入用のミラーレジストリー、Artifactory、Sonatype Nexus リポジトリー、Harbor など、Dockerv2-2 をサポートする任意のコンテナーレジストリーを使用できます。選択したレジストリーに関係なく、インターネット上の Red Hat がホストするサイトから分離されたイメージレジストリーにコンテンツをミラーリングする手順は同じです。コンテンツをミラーリングした後に、各クラスターをミラーレジストリーからこのコンテンツを取得するように設定します。
OpenShift イメージレジストリーはターゲットレジストリーとして使用できません。これは、ミラーリングプロセスで必要となるタグを使わないプッシュをサポートしないためです。
Red Hat OpenShift 導入用のミラーレジストリー 以外のコンテナーレジストリーを選択する場合は、プロビジョニングするクラスター内の全マシンから到達可能である必要があります。レジストリーに到達できない場合、インストール、更新、またはワークロードの再配置などの通常の操作が失敗する可能性があります。そのため、ミラーレジストリーは可用性の高い方法で実行し、ミラーレジストリーは少なくとも OpenShift Container Platform クラスターの実稼働環境の可用性の条件に一致している必要があります。
ミラーレジストリーを OpenShift Container Platform イメージで設定する場合、2 つのシナリオを実行することができます。インターネットとミラーレジストリーの両方にアクセスできるホストがあり、クラスターノードにアクセスできない場合は、そのマシンからコンテンツを直接ミラーリングできます。このプロセスは、connected mirroring (接続ミラーリング) と呼ばれます。このようなホストがない場合は、イメージをファイルシステムにミラーリングしてから、そのホストまたはリムーバブルメディアを制限された環境に配置する必要があります。このプロセスは、disconnected mirroring (非接続ミラーリング) と呼ばれます。
ミラーリングされたレジストリーの場合は、プルされたイメージのソースを表示するには、CRI-O ログで Trying to access
のログエントリーを確認する必要があります。ノードで crictl images
コマンドを使用するなど、イメージのプルソースを表示する他の方法では、イメージがミラーリングされた場所からプルされている場合でも、ミラーリングされていないイメージ名を表示します。
Red Hat は、OpenShift Container Platform を使用してサードパーティーのレジストリーをテストしません。
関連情報
CRI-O ログを表示してイメージソースを表示する方法の詳細は、Viewing the image pull source を参照してください。
2.3.3. ミラーホストの準備
ミラー手順を実行する前に、ホストを準備して、コンテンツを取得し、リモートの場所にプッシュできるようにする必要があります。
2.3.3.1. バイナリーのダウンロードによる OpenShift CLI のインストール
コマンドラインインターフェイスを使用して OpenShift Container Platform と対話するために CLI (oc
) をインストールすることができます。oc
は Linux、Windows、または macOS にインストールできます。
以前のバージョンの oc
をインストールしている場合、これを使用して OpenShift Container Platform 4.15 のすべてのコマンドを実行することはできません。新規バージョンの oc
をダウンロードし、インストールします。
Linux への OpenShift CLI のインストール
以下の手順を使用して、OpenShift CLI (oc
) バイナリーを Linux にインストールできます。
手順
- Red Hat カスタマーポータルの OpenShift Container Platform ダウンロードページ に移動します。
- Product Variant ドロップダウンリストからアーキテクチャーを選択します。
- バージョン ドロップダウンリストから適切なバージョンを選択します。
- OpenShift v4.15 Linux Client エントリーの横にある Download Now をクリックして、ファイルを保存します。
アーカイブを展開します。
Copy to Clipboard Copied! Toggle word wrap Toggle overflow tar xvf <file>
$ tar xvf <file>
oc
バイナリーを、PATH
にあるディレクトリーに配置します。PATH
を確認するには、以下のコマンドを実行します。Copy to Clipboard Copied! Toggle word wrap Toggle overflow echo $PATH
$ echo $PATH
検証
OpenShift CLI のインストール後に、
oc
コマンドを使用して利用できます。Copy to Clipboard Copied! Toggle word wrap Toggle overflow oc <command>
$ oc <command>
Windows への OpenShift CLI のインストール
以下の手順を使用して、OpenShift CLI (oc
) バイナリーを Windows にインストールできます。
手順
- Red Hat カスタマーポータルの OpenShift Container Platform ダウンロードページ に移動します。
- バージョン ドロップダウンリストから適切なバージョンを選択します。
- OpenShift v4.15 Windows Client エントリーの横にある Download Now をクリックして、ファイルを保存します。
- ZIP プログラムでアーカイブを展開します。
oc
バイナリーを、PATH
にあるディレクトリーに移動します。PATH
を確認するには、コマンドプロンプトを開いて以下のコマンドを実行します。Copy to Clipboard Copied! Toggle word wrap Toggle overflow path
C:\> path
検証
OpenShift CLI のインストール後に、
oc
コマンドを使用して利用できます。Copy to Clipboard Copied! Toggle word wrap Toggle overflow oc <command>
C:\> oc <command>
macOS への OpenShift CLI のインストール
以下の手順を使用して、OpenShift CLI (oc
) バイナリーを macOS にインストールできます。
手順
- Red Hat カスタマーポータルの OpenShift Container Platform ダウンロードページ に移動します。
- バージョン ドロップダウンリストから適切なバージョンを選択します。
OpenShift v4.15 macOS Client エントリーの横にある Download Now をクリックして、ファイルを保存します。
注記macOS arm64 の場合は、OpenShift v4.15 macOS arm64 Client エントリーを選択します。
- アーカイブを展開し、解凍します。
oc
バイナリーをパスにあるディレクトリーに移動します。PATH
を確認するには、ターミナルを開き、以下のコマンドを実行します。Copy to Clipboard Copied! Toggle word wrap Toggle overflow echo $PATH
$ echo $PATH
検証
oc
コマンドを使用してインストールを確認します。Copy to Clipboard Copied! Toggle word wrap Toggle overflow oc <command>
$ oc <command>
2.3.4. イメージのミラーリングを可能にする認証情報の設定
Red Hat からミラーへのイメージのミラーリングを可能にするコンテナーイメージレジストリーの認証情報ファイルを作成します。
クラスターのインストール時に、このイメージレジストリー認証情報ファイルをプルシークレットとして使用しないでください。クラスターのインストール時にこのファイルを指定すると、クラスター内のすべてのマシンにミラーレジストリーへの書き込みアクセスが付与されます。
このプロセスでは、ミラーレジストリーのコンテナーイメージレジストリーへの書き込みアクセスがあり、認証情報をレジストリープルシークレットに追加する必要があります。
前提条件
- 非接続環境で使用するミラーレジストリーを設定しました。
- イメージをミラーリングするミラーレジストリー上のイメージリポジトリーの場所を特定している。
- イメージのイメージリポジトリーへのアップロードを許可するミラーレジストリーアカウントをプロビジョニングしている。
手順
インストールホストで以下の手順を実行します。
-
registry.redhat.io
プルシークレットを Red Hat OpenShift Cluster Manager からダウンロードします。 JSON 形式でプルシークレットのコピーを作成します。
Copy to Clipboard Copied! Toggle word wrap Toggle overflow cat ./pull-secret | jq . > <path>/<pull_secret_file_in_json>
$ cat ./pull-secret | jq . > <path>/<pull_secret_file_in_json>
1 - 1
- プルシークレットを保存するフォルダーへのパスおよび作成する JSON ファイルの名前を指定します。
ファイルの内容は以下の例のようになります。
Copy to Clipboard Copied! Toggle word wrap Toggle overflow { "auths": { "cloud.openshift.com": { "auth": "b3BlbnNo...", "email": "you@example.com" }, "quay.io": { "auth": "b3BlbnNo...", "email": "you@example.com" }, "registry.connect.redhat.com": { "auth": "NTE3Njg5Nj...", "email": "you@example.com" }, "registry.redhat.io": { "auth": "NTE3Njg5Nj...", "email": "you@example.com" } } }
{ "auths": { "cloud.openshift.com": { "auth": "b3BlbnNo...", "email": "you@example.com" }, "quay.io": { "auth": "b3BlbnNo...", "email": "you@example.com" }, "registry.connect.redhat.com": { "auth": "NTE3Njg5Nj...", "email": "you@example.com" }, "registry.redhat.io": { "auth": "NTE3Njg5Nj...", "email": "you@example.com" } } }
ミラーレジストリーの base64 でエンコードされたユーザー名およびパスワードまたはトークンを生成します。
Copy to Clipboard Copied! Toggle word wrap Toggle overflow echo -n '<user_name>:<password>' | base64 -w0
$ echo -n '<user_name>:<password>' | base64 -w0
1 BGVtbYk3ZHAtqXs=
- 1
<user_name>
および<password>
については、レジストリーに設定したユーザー名およびパスワードを指定します。
JSON ファイルを編集し、レジストリーについて記述するセクションをこれに追加します。
Copy to Clipboard Copied! Toggle word wrap Toggle overflow "auths": { "<mirror_registry>": { "auth": "<credentials>", "email": "you@example.com" } },
"auths": { "<mirror_registry>": {
1 "auth": "<credentials>",
2 "email": "you@example.com" } },
ファイルは以下の例のようになります。
Copy to Clipboard Copied! Toggle word wrap Toggle overflow { "auths": { "registry.example.com": { "auth": "BGVtbYk3ZHAtqXs=", "email": "you@example.com" }, "cloud.openshift.com": { "auth": "b3BlbnNo...", "email": "you@example.com" }, "quay.io": { "auth": "b3BlbnNo...", "email": "you@example.com" }, "registry.connect.redhat.com": { "auth": "NTE3Njg5Nj...", "email": "you@example.com" }, "registry.redhat.io": { "auth": "NTE3Njg5Nj...", "email": "you@example.com" } } }
{ "auths": { "registry.example.com": { "auth": "BGVtbYk3ZHAtqXs=", "email": "you@example.com" }, "cloud.openshift.com": { "auth": "b3BlbnNo...", "email": "you@example.com" }, "quay.io": { "auth": "b3BlbnNo...", "email": "you@example.com" }, "registry.connect.redhat.com": { "auth": "NTE3Njg5Nj...", "email": "you@example.com" }, "registry.redhat.io": { "auth": "NTE3Njg5Nj...", "email": "you@example.com" } } }
2.3.5. OpenShift Container Platform イメージリポジトリーのミラーリング
クラスターのインストールまたはアップグレード時に使用するために、OpenShift Container Platform イメージリポジトリーをお使いのレジストリーにミラーリングします。
前提条件
- ミラーホストがインターネットにアクセスできる。
- ネットワークが制限された環境で使用するミラーレジストリーを設定し、設定した証明書および認証情報にアクセスできる。
- Red Hat OpenShift Cluster Manager からプルシークレット をダウンロードし、ミラーリポジトリーへの認証を組み込むように変更している。
- 自己署名証明書を使用する場合は、証明書にサブジェクトの別名を指定しています。
手順
ミラーホストで以下の手順を実行します。
- OpenShift Container Platform ダウンロード ページを確認し、インストールする必要のある OpenShift Container Platform のバージョンを判別し、Repository Tags ページで対応するタグを判別します。
必要な環境変数を設定します。
リリースバージョンをエクスポートします。
Copy to Clipboard Copied! Toggle word wrap Toggle overflow OCP_RELEASE=<release_version>
$ OCP_RELEASE=<release_version>
<release_version>
について、インストールする OpenShift Container Platform のバージョンに対応するタグを指定します (例:4.5.4
)。ローカルレジストリー名とホストポートをエクスポートします。
Copy to Clipboard Copied! Toggle word wrap Toggle overflow LOCAL_REGISTRY='<local_registry_host_name>:<local_registry_host_port>'
$ LOCAL_REGISTRY='<local_registry_host_name>:<local_registry_host_port>'
<local_registry_host_name>
については、ミラーレジストリーのレジストリードメイン名を指定し、<local_registry_host_port>
については、コンテンツの送信に使用するポートを指定します。ローカルリポジトリー名をエクスポートします。
Copy to Clipboard Copied! Toggle word wrap Toggle overflow LOCAL_REPOSITORY='<local_repository_name>'
$ LOCAL_REPOSITORY='<local_repository_name>'
<local_repository_name>
については、ocp4/openshift4
などのレジストリーに作成するリポジトリーの名前を指定します。ミラーリングするリポジトリーの名前をエクスポートします。
Copy to Clipboard Copied! Toggle word wrap Toggle overflow PRODUCT_REPO='openshift-release-dev'
$ PRODUCT_REPO='openshift-release-dev'
実稼働環境のリリースの場合には、
openshift-release-dev
を指定する必要があります。パスをレジストリープルシークレットにエクスポートします。
Copy to Clipboard Copied! Toggle word wrap Toggle overflow LOCAL_SECRET_JSON='<path_to_pull_secret>'
$ LOCAL_SECRET_JSON='<path_to_pull_secret>'
<path_to_pull_secret>
については、作成したミラーレジストリーのプルシークレットの絶対パスおよびファイル名を指定します。リリースミラーをエクスポートします。
Copy to Clipboard Copied! Toggle word wrap Toggle overflow RELEASE_NAME="ocp-release"
$ RELEASE_NAME="ocp-release"
実稼働環境のリリースについては、
ocp-release
を指定する必要があります。クラスターのアーキテクチャーのタイプをエクスポートします。
Copy to Clipboard Copied! Toggle word wrap Toggle overflow ARCHITECTURE=<cluster_architecture>
$ ARCHITECTURE=<cluster_architecture>
1 - 1
x86_64
、aarch64
、s390x
、またはppc64le
など、クラスターのアーキテクチャーを指定します。
ミラーリングされたイメージをホストするためにディレクトリーへのパスをエクスポートします。
Copy to Clipboard Copied! Toggle word wrap Toggle overflow REMOVABLE_MEDIA_PATH=<path>
$ REMOVABLE_MEDIA_PATH=<path>
1 - 1
- 最初のスラッシュ (/) 文字を含む完全パスを指定します。
バージョンイメージをミラーレジストリーにミラーリングします。
ミラーホストがインターネットにアクセスできない場合は、以下の操作を実行します。
- リムーバブルメディアをインターネットに接続しているシステムに接続します。
ミラーリングするイメージおよび設定マニフェストを確認します。
Copy to Clipboard Copied! Toggle word wrap Toggle overflow oc adm release mirror -a ${LOCAL_SECRET_JSON} \ --from=quay.io/${PRODUCT_REPO}/${RELEASE_NAME}:${OCP_RELEASE}-${ARCHITECTURE} \ --to=${LOCAL_REGISTRY}/${LOCAL_REPOSITORY} \ --to-release-image=${LOCAL_REGISTRY}/${LOCAL_REPOSITORY}:${OCP_RELEASE}-${ARCHITECTURE} --dry-run
$ oc adm release mirror -a ${LOCAL_SECRET_JSON} \ --from=quay.io/${PRODUCT_REPO}/${RELEASE_NAME}:${OCP_RELEASE}-${ARCHITECTURE} \ --to=${LOCAL_REGISTRY}/${LOCAL_REPOSITORY} \ --to-release-image=${LOCAL_REGISTRY}/${LOCAL_REPOSITORY}:${OCP_RELEASE}-${ARCHITECTURE} --dry-run
-
直前のコマンドの出力の
imageContentSources
セクション全体を記録します。ミラーの情報はミラーリングされたリポジトリーに一意であり、インストール時にimageContentSources
セクションをinstall-config.yaml
ファイルに追加する必要があります。 イメージをリムーバブルメディア上のディレクトリーにミラーリングします。
Copy to Clipboard Copied! Toggle word wrap Toggle overflow oc adm release mirror -a ${LOCAL_SECRET_JSON} --to-dir=${REMOVABLE_MEDIA_PATH}/mirror quay.io/${PRODUCT_REPO}/${RELEASE_NAME}:${OCP_RELEASE}-${ARCHITECTURE}
$ oc adm release mirror -a ${LOCAL_SECRET_JSON} --to-dir=${REMOVABLE_MEDIA_PATH}/mirror quay.io/${PRODUCT_REPO}/${RELEASE_NAME}:${OCP_RELEASE}-${ARCHITECTURE}
メディアをネットワークが制限された環境に移し、イメージをローカルコンテナーレジストリーにアップロードします。
Copy to Clipboard Copied! Toggle word wrap Toggle overflow oc image mirror -a ${LOCAL_SECRET_JSON} --from-dir=${REMOVABLE_MEDIA_PATH}/mirror "file://openshift/release:${OCP_RELEASE}*" ${LOCAL_REGISTRY}/${LOCAL_REPOSITORY}
$ oc image mirror -a ${LOCAL_SECRET_JSON} --from-dir=${REMOVABLE_MEDIA_PATH}/mirror "file://openshift/release:${OCP_RELEASE}*" ${LOCAL_REGISTRY}/${LOCAL_REPOSITORY}
1 - 1
REMOVABLE_MEDIA_PATH
の場合、イメージのミラーリング時に指定した同じパスを使用する必要があります。
重要oc image mirror
を実行すると、error: unable to retrieve source image
エラーが発生する場合があります。このエラーは、イメージレジストリーに存在しなくなったイメージへの参照がイメージインデックスに含まれている場合に発生します。イメージインデックスは、それらのイメージを実行しているユーザーがアップグレードグラフの新しいポイントへのアップグレードパスを実行できるように、古い参照を保持する場合があります。一時的な回避策として、--skip-missing
オプションを使用してエラーを回避し、イメージインデックスのダウンロードを続行できます。詳細は、Service Mesh Operator mirroring failed を参照してください。
ローカルコンテナーレジストリーがミラーホストに接続されている場合は、以下の操作を実行します。
以下のコマンドを使用して、リリースイメージをローカルレジストリーに直接プッシュします。
Copy to Clipboard Copied! Toggle word wrap Toggle overflow oc adm release mirror -a ${LOCAL_SECRET_JSON} \ --from=quay.io/${PRODUCT_REPO}/${RELEASE_NAME}:${OCP_RELEASE}-${ARCHITECTURE} \ --to=${LOCAL_REGISTRY}/${LOCAL_REPOSITORY} \ --to-release-image=${LOCAL_REGISTRY}/${LOCAL_REPOSITORY}:${OCP_RELEASE}-${ARCHITECTURE}
$ oc adm release mirror -a ${LOCAL_SECRET_JSON} \ --from=quay.io/${PRODUCT_REPO}/${RELEASE_NAME}:${OCP_RELEASE}-${ARCHITECTURE} \ --to=${LOCAL_REGISTRY}/${LOCAL_REPOSITORY} \ --to-release-image=${LOCAL_REGISTRY}/${LOCAL_REPOSITORY}:${OCP_RELEASE}-${ARCHITECTURE}
このコマンドは、リリース情報をダイジェストとしてプルします。その出力には、クラスターのインストール時に必要な
imageContentSources
データが含まれます。直前のコマンドの出力の
imageContentSources
セクション全体を記録します。ミラーの情報はミラーリングされたリポジトリーに一意であり、インストール時にimageContentSources
セクションをinstall-config.yaml
ファイルに追加する必要があります。注記ミラーリングプロセス中にイメージ名に Quay.io のパッチが適用され、podman イメージにはブートストラップ仮想マシンのレジストリーに Quay.io が表示されます。
ミラーリングしたコンテンツに基づくインストールプログラムを作成するために、インストールプログラムを展開してリリースに固定します。
ミラーホストがインターネットにアクセスできない場合は、以下のコマンドを実行します。
Copy to Clipboard Copied! Toggle word wrap Toggle overflow oc adm release extract -a ${LOCAL_SECRET_JSON} --icsp-file=<file> --command=openshift-install "${LOCAL_REGISTRY}/${LOCAL_REPOSITORY}:${OCP_RELEASE}-${ARCHITECTURE}" \ --insecure=true
$ oc adm release extract -a ${LOCAL_SECRET_JSON} --icsp-file=<file> --command=openshift-install "${LOCAL_REGISTRY}/${LOCAL_REPOSITORY}:${OCP_RELEASE}-${ARCHITECTURE}" \ --insecure=true
1 - 1
- オプション: ターゲットレジストリーの信頼を設定しない場合は、
--insecure=true
フラグを追加します。
ローカルコンテナーレジストリーがミラーホストに接続されている場合は、以下のコマンドを実行します。
Copy to Clipboard Copied! Toggle word wrap Toggle overflow oc adm release extract -a ${LOCAL_SECRET_JSON} --command=openshift-install "${LOCAL_REGISTRY}/${LOCAL_REPOSITORY}:${OCP_RELEASE}-${ARCHITECTURE}"
$ oc adm release extract -a ${LOCAL_SECRET_JSON} --command=openshift-install "${LOCAL_REGISTRY}/${LOCAL_REPOSITORY}:${OCP_RELEASE}-${ARCHITECTURE}"
重要選択した OpenShift Container Platform のバージョンに適したイメージを確実に使用するために、ミラーリングしたコンテンツからインストールプログラムを展開する必要があります。
インターネット接続のあるマシンで、このステップを実行する必要があります。
installer-provisioned infrastructure を使用するクラスターの場合は、以下のコマンドを実行します。
Copy to Clipboard Copied! Toggle word wrap Toggle overflow openshift-install
$ openshift-install
2.3.6. 非接続環境の Cluster Samples Operator
非接続環境で Cluster Samples Operator を設定するには、クラスターのインストール後に追加の手順を実行する必要があります。以下の情報を確認し、準備してください。
2.3.6.1. ミラーリングの Cluster Samples Operator のサポート
インストール時に、OpenShift Container Platform は imagestreamtag-to-image
という名前の設定マップを openshift-cluster-samples-operator
namespace に作成します。imagestreamtag-to-image
設定マップには、各イメージストリームタグのエントリー (設定されるイメージ) が含まれます。
設定マップの data フィールドの各エントリーのキーの形式は、<image_stream_name>_<image_stream_tag_name>
です。
OpenShift Container Platform の非接続インストール時に、Cluster Samples Operator のステータスは Removed
に設定されます。これを Managed
に変更することを選択する場合、サンプルがインストールされます。
ネットワークが制限されている環境または切断されている環境でサンプルを使用するには、ネットワークの外部のサービスにアクセスする必要がある場合があります。サービスの例には、Github、Maven Central、npm、RubyGems、PyPi などがあります。場合によっては、Cluster Samples Operator のオブジェクトが必要なサービスに到達できるようにするために、追加の手順を実行する必要があります。
この config map は、イメージストリームをインポートするためにミラーリングする必要があるイメージの参照情報として使用できます。
-
Cluster Samples Operator が
Removed
に設定される場合、ミラーリングされたレジストリーを作成するか、使用する必要のある既存のミラーリングされたレジストリーを判別できます。 - 新しい config map をガイドとして使用し、ミラーリングされたレジストリーに必要なサンプルをミラーリングします。
-
Cluster Samples Operator 設定オブジェクトの
skippedImagestreams
リストに、ミラーリングされていないイメージストリームを追加します。 -
Cluster Samples Operator 設定オブジェクトの
samplesRegistry
をミラーリングされたレジストリーに設定します。 -
次に、Cluster Samples Operator を
Managed
に設定し、ミラーリングしたイメージストリームをインストールします。
2.3.7. 非接続クラスターで使用する Operator カタログのミラーリング
oc adm catalog mirror
コマンドを使用して、Red Hat が提供するカタログまたはカスタムカタログの Operator コンテンツをコンテナーイメージレジストリーにミラーリングできます。ターゲットレジストリーは Docker v2-2 をサポートする必要があります。ネットワークが制限された環境のクラスターの場合、このレジストリーには、ネットワークが制限されたクラスターのインストール時に作成されたミラーレジストリーなど、クラスターにネットワークアクセスのあるレジストリーを使用できます。
- OpenShift イメージレジストリーはターゲットレジストリーとして使用できません。これは、ミラーリングプロセスで必要となるタグを使わないプッシュをサポートしないためです。
-
oc adm catalog mirror
を実行すると、error: unable to retrieve source image
エラーが発生する場合があります。このエラーは、イメージレジストリーに存在しなくなったイメージへの参照がイメージインデックスに含まれている場合に発生します。イメージインデックスは、それらのイメージを実行しているユーザーがアップグレードグラフの新しいポイントへのアップグレードパスを実行できるように、古い参照を保持する場合があります。一時的な回避策として、--skip-missing
オプションを使用してエラーを回避し、イメージインデックスのダウンロードを続行できます。詳細は、Service Mesh Operator mirroring failed を参照してください。
oc adm catalog mirror
コマンドは、Red Hat が提供するインデックスイメージであるか、独自のカスタムビルドされたインデックスイメージであるかに関係なく、ミラーリングプロセス中に指定されるインデックスイメージをターゲットレジストリーに自動的にミラーリングします。次に、ミラーリングされたインデックスイメージを使用して、Operator Lifecycle Manager (OLM) がミラーリングされたカタログを OpenShift Container Platform クラスターにロードできるようにするカタログソースを作成できます。
2.3.7.1. 前提条件
非接続クラスターで使用する Operator カタログのミラーリングには、以下の前提条件があります。
- ネットワークアクセスが無制限のワークステーション
-
podman
バージョン 1.9.3 以降。 既存のカタログをフィルタリングまたは プルーニング して、Operator のサブセットのみを選択的にミラーリングする場合は、次のセクションを参照してください。
Red Hat が提供するカタログをミラーリングする場合は、ネットワークアクセスが無制限のワークステーションで以下のコマンドを実行し、
registry.redhat.io
で認証します。Copy to Clipboard Copied! Toggle word wrap Toggle overflow podman login registry.redhat.io
$ podman login registry.redhat.io
- Docker v2-2 をサポートするミラーレジストリーへのアクセス。
-
ミラーレジストリーで、ミラーリングされた Operator コンテンツの保存に使用するリポジトリーまたは namespace を決定します。たとえば、
olm-mirror
リポジトリーを作成できます。 - ミラーレジストリーにインターネットアクセスがない場合は、ネットワークアクセスが無制限のワークステーションにリムーバブルメディアを接続します。
registry.redhat.io
などのプライベートレジストリーを使用している場合、後続の手順で使用するためにREG_CREDS
環境変数をレジストリー認証情報のファイルパスに設定します。たとえばpodman
CLI の場合は、以下のようになります。Copy to Clipboard Copied! Toggle word wrap Toggle overflow REG_CREDS=${XDG_RUNTIME_DIR}/containers/auth.json
$ REG_CREDS=${XDG_RUNTIME_DIR}/containers/auth.json
2.3.7.2. カタログコンテンツの抽出およびミラーリング
oc adm catalog mirror
コマンドは、インデックスイメージのコンテンツを抽出し、ミラーリングに必要なマニフェストを生成します。コマンドのデフォルト動作で、マニフェストを生成し、インデックスイメージからのすべてのイメージコンテンツを、インデックスイメージと同様にミラーレジストリーに対して自動的にミラーリングします。
または、ミラーレジストリーが完全に非接続または エアギャップ環境のホスト上にある場合、最初にコンテンツをリムーバブルメディアにミラーリングし、メディアを非接続環境に移行してから、メディアからレジストリーにコンテンツをレジストリーに対してミラーリングできます。
2.3.7.2.1. 同じネットワーク上のレジストリーへのカタログコンテンツのミラーリング
ミラーレジストリーがネットワークアクセスが無制限のワークステーションと同じネットワーク上に置かれている場合は、ワークステーションで以下のアクションを実行します。
手順
ミラーレジストリーに認証が必要な場合は、以下のコマンドを実行してレジストリーにログインします。
Copy to Clipboard Copied! Toggle word wrap Toggle overflow podman login <mirror_registry>
$ podman login <mirror_registry>
以下のコマンドを実行して、コンテンツをミラーレジストリーに対して抽出し、ミラーリングします。
Copy to Clipboard Copied! Toggle word wrap Toggle overflow oc adm catalog mirror \ <index_image> \ <index_image> \ <mirror_registry>:<port>[/<repository>] \ <mirror_registry>:<port>[/<repository>] \ [-a ${REG_CREDS}] \ [-a ${REG_CREDS}] \ [--insecure] \ [--insecure] \ [--index-filter-by-os='<platform>/<arch>'] \ [--index-filter-by-os='<platform>/<arch>'] \ [--manifests-only] [--manifests-only]
$ oc adm catalog mirror \ <index_image> \
1 <mirror_registry>:<port>[/<repository>] \
2 [-a ${REG_CREDS}] \
3 [--insecure] \
4 [--index-filter-by-os='<platform>/<arch>'] \
5 [--manifests-only]
6 - 1
- ミラーリングするカタログのインデックスイメージを指定します。
- 2
- Operator の内容をミラーリングするターゲットレジストリーの完全修飾ドメイン名 (FQDN) を指定します。ミラーレジストリー
<repository>
には、前提条件で説明したolm-mirror
など、レジストリー上の既存のリポジトリーまたは namespace を指定できます。ミラーリング中に既存のリポジトリーが見つかった場合は、そのリポジトリー名が結果のイメージ名に追加されます。イメージ名にリポジトリー名を含めたくない場合は、この行から<repository>
値を省略します (例:<mirror_registry>:<port>)
。 - 3
- オプション: 必要な場合は、レジストリー認証情報ファイルの場所を指定します。
registry.redhat.io
には、{REG_CREDS}
が必要です。 - 4
- オプション: ターゲットレジストリーの信頼を設定しない場合は、
--insecure
フラグを追加します。 - 5
- オプション: 複数のバリアントが利用可能な場合に、選択するインデックスイメージのプラットフォームおよびアーキテクチャーを指定します。イメージは
'<platform>/<arch>[/<variant>]'
として渡されます。これはインデックスで参照されるイメージには適用されません。有効な値は、linux/amd64
、linux/ppc64le
、linux/s390x
、linux/arm64
です。 - 6
- オプション: 実際にイメージコンテンツをレジストリーにミラーリングせずに、ミラーリングに必要なマニフェストのみを生成します。このオプションは、ミラーリングする内容を確認するのに役立ちます。また、パッケージのサブセットのみが必要な場合に、マッピングのリストに変更を加えることができます。次に、
mapping.txt
ファイルをoc image mirror
コマンドで使用し、後のステップでイメージの変更済みの一覧をミラーリングできます。これは、カタログからのコンテンツの高度な選択可能ミラーリングの実行に使用するためのフラグです。
出力例
Copy to Clipboard Copied! Toggle word wrap Toggle overflow src image has index label for database path: /database/index.db using database path mapping: /database/index.db:/tmp/153048078 wrote database to /tmp/153048078 ... wrote mirroring manifests to manifests-redhat-operator-index-1614211642
src image has index label for database path: /database/index.db using database path mapping: /database/index.db:/tmp/153048078 wrote database to /tmp/153048078
1 ... wrote mirroring manifests to manifests-redhat-operator-index-1614211642
2 - 1
- コマンドで生成された一時的な
index.db
データベースのディレクトリー。 - 2
- 生成される manifests ディレクトリー名を記録します。このディレクトリーは、後続の手順で参照されます。注記
Red Hat Quay では、ネストされたリポジトリーはサポート対象外です。その結果、
oc adm catalog mirror
コマンドを実行すると、401
unauthorized エラーで失敗します。回避策として、oc adm catalog mirror
コマンドを実行するときに--max-components = 2
オプションを使用して、ネストされたリポジトリーの作成を無効にすることができます。この回避策の詳細は Unauthorized error thrown while using catalog mirror command with Quay registry のナレッジソリューションを参照してください。
2.3.7.2.2. カタログコンテンツをエアギャップされたレジストリーへのミラーリング
ミラーレジストリーが完全に切断された、またはエアギャップのあるホスト上にある場合は、次のアクションを実行します。
手順
ネットワークアクセスが無制限のワークステーションで以下のコマンドを実行し、コンテンツをローカルファイルにミラーリングします。
Copy to Clipboard Copied! Toggle word wrap Toggle overflow oc adm catalog mirror \ <index_image> \ <index_image> \ file:///local/index \ file:///local/index \ -a ${REG_CREDS} \ -a ${REG_CREDS} \ --insecure \ --insecure \ --index-filter-by-os='<platform>/<arch>' --index-filter-by-os='<platform>/<arch>'
$ oc adm catalog mirror \ <index_image> \
1 file:///local/index \
2 -a ${REG_CREDS} \
3 --insecure \
4 --index-filter-by-os='<platform>/<arch>'
5 - 1
- ミラーリングするカタログのインデックスイメージを指定します。
- 2
- 現在のディレクトリーのローカルファイルにミラーリングするコンテンツを指定します。
- 3
- オプション: 必要な場合は、レジストリー認証情報ファイルの場所を指定します。
- 4
- オプション: ターゲットレジストリーの信頼を設定しない場合は、
--insecure
フラグを追加します。 - 5
- オプション: 複数のバリアントが利用可能な場合に、選択するインデックスイメージのプラットフォームおよびアーキテクチャーを指定します。イメージは
'<platform>/<arch>[/<variant>]'
として指定されます。これはインデックスで参照されるイメージには適用されません。使用できる値は、linux/amd64
、linux/ppc64le
、linux/s390x
、linux/arm64
、および.*
です。
出力例
Copy to Clipboard Copied! Toggle word wrap Toggle overflow ... info: Mirroring completed in 5.93s (5.915MB/s) wrote mirroring manifests to manifests-my-index-1614985528 To upload local images to a registry, run: oc adm catalog mirror file://local/index/myrepo/my-index:v1 REGISTRY/REPOSITORY
... info: Mirroring completed in 5.93s (5.915MB/s) wrote mirroring manifests to manifests-my-index-1614985528
1 To upload local images to a registry, run: oc adm catalog mirror file://local/index/myrepo/my-index:v1 REGISTRY/REPOSITORY
2 このコマンドにより、現在のディレクトリーに
v2/
ディレクトリーが作成されます。-
v2/
ディレクトリーをリムーバブルメディアにコピーします。 - メディアを物理的に削除して、これをミラーレジストリーにアクセスできる非接続環境のホストに割り当てます。
ミラーレジストリーに認証が必要な場合は、非接続環境のホストで以下のコマンドを実行し、レジストリーにログインします。
Copy to Clipboard Copied! Toggle word wrap Toggle overflow podman login <mirror_registry>
$ podman login <mirror_registry>
v2/
ディレクトリーを含む親ディレクトリーから以下のコマンドを実行し、ローカルファイルからミラーレジストリーにイメージをアップロードします。Copy to Clipboard Copied! Toggle word wrap Toggle overflow oc adm catalog mirror \ file://local/index/<repository>/<index_image>:<tag> \ file://local/index/<repository>/<index_image>:<tag> \ <mirror_registry>:<port>[/<repository>] \ <mirror_registry>:<port>[/<repository>] \ -a ${REG_CREDS} \ -a ${REG_CREDS} \ --insecure \ --insecure \ --index-filter-by-os='<platform>/<arch>' --index-filter-by-os='<platform>/<arch>'
$ oc adm catalog mirror \ file://local/index/<repository>/<index_image>:<tag> \
1 <mirror_registry>:<port>[/<repository>] \
2 -a ${REG_CREDS} \
3 --insecure \
4 --index-filter-by-os='<platform>/<arch>'
5 - 1
- 直前のコマンド出力の
file://
パスを指定します。 - 2
- Operator の内容をミラーリングするターゲットレジストリーの完全修飾ドメイン名 (FQDN) を指定します。ミラーレジストリー
<repository>
には、前提条件で説明したolm-mirror
など、レジストリー上の既存のリポジトリーまたは namespace を指定できます。ミラーリング中に既存のリポジトリーが見つかった場合は、そのリポジトリー名が結果のイメージ名に追加されます。イメージ名にリポジトリー名を含めたくない場合は、この行から<repository>
値を省略します (例:<mirror_registry>:<port>)
。 - 3
- オプション: 必要な場合は、レジストリー認証情報ファイルの場所を指定します。
- 4
- オプション: ターゲットレジストリーの信頼を設定しない場合は、
--insecure
フラグを追加します。 - 5
- オプション: 複数のバリアントが利用可能な場合に、選択するインデックスイメージのプラットフォームおよびアーキテクチャーを指定します。イメージは
'<platform>/<arch>[/<variant>]'
として指定されます。これはインデックスで参照されるイメージには適用されません。使用できる値は、linux/amd64
、linux/ppc64le
、linux/s390x
、linux/arm64
、および.*
です。
注記Red Hat Quay では、ネストされたリポジトリーはサポート対象外です。その結果、
oc adm catalog mirror
コマンドを実行すると、401
unauthorized エラーで失敗します。回避策として、oc adm catalog mirror
コマンドを実行するときに--max-components = 2
オプションを使用して、ネストされたリポジトリーの作成を無効にすることができます。この回避策の詳細は Unauthorized error thrown while using catalog mirror command with Quay registry のナレッジソリューションを参照してください。oc adm catalog mirror
コマンドを再度実行します。新しくミラー化されたインデックスイメージをソースとして使用し、前の手順で使用したものと同じミラーレジストリーターゲットを使用します。Copy to Clipboard Copied! Toggle word wrap Toggle overflow oc adm catalog mirror \ <mirror_registry>:<port>/<index_image> \ <mirror_registry>:<port>/<index_image> \ <mirror_registry>:<port>[/<repository>] \ <mirror_registry>:<port>[/<repository>] \ --manifests-only \ --manifests-only \ [-a ${REG_CREDS}] \ [-a ${REG_CREDS}] \ [--insecure] [--insecure]
$ oc adm catalog mirror \ <mirror_registry>:<port>/<index_image> \ <mirror_registry>:<port>[/<repository>] \ --manifests-only \
1 [-a ${REG_CREDS}] \ [--insecure]
- 1
- コマンドがミラーリングされたすべてのコンテンツを再度コピーしないように、このステップには
--manifests-only
フラグが必要です。
重要前のステップで生成された
imageContentSourcePolicy.yaml
ファイルのイメージマッピングをローカルパスから有効なミラー位置に更新する必要があるため、このステップが必要です。そうしないと、後のステップでImageContentSourcePolicy
オブジェクトを作成するときにエラーが発生します。
カタログのミラーリング後、残りのクラスターインストールを続行できます。クラスターのインストールが正常に完了した後に、この手順から manifests ディレクトリーを指定して ImageContentSourcePolicy
および CatalogSource
オブジェクトを作成する必要があります。これらのオブジェクトは、OperatorHub からの Operator のインストールを有効にするために必要になります。
2.3.7.3. 生成されたマニフェスト
Operator カタログコンテンツをミラーレジストリーにミラーリングした後に、現在のディレクトリーに manifests ディレクトリーが生成されます。
同じネットワークのレジストリーにコンテンツをミラーリングする場合、ディレクトリー名は以下のパターンになります。
manifests-<index_image_name>-<random_number>
manifests-<index_image_name>-<random_number>
直前のセクションで非接続ホストのレジストリーにコンテンツをミラーリングする場合、ディレクトリー名は以下のパターンになります。
manifests-index/<repository>/<index_image_name>-<random_number>
manifests-index/<repository>/<index_image_name>-<random_number>
manifests ディレクトリー名は、後続の手順で参照されます。
manifests ディレクトリーには以下のファイルが含まれており、これらの一部にはさらに変更が必要になる場合があります。
catalogSource.yaml
ファイルは、インデックスイメージタグおよび他の関連するメタデータで事前に設定されるCatalogSource
オブジェクトの基本的な定義です。このファイルは、カタログソースをクラスターに追加するためにそのまま使用したり、変更したりできます。重要ローカルファイルにコンテンツをミラーリングする場合は、
catalogSource.yaml
ファイルを変更してmetadata.name
フィールドからバックスラッシュ (/
) 文字を削除する必要があります。または、オブジェクトの作成を試みると、"invalid resource name" (無効なリソース名) を示すエラーを出して失敗します。これにより、
imageContentSourcePolicy.yaml
ファイルはImageContentSourcePolicy
オブジェクトを定義します。このオブジェクトは、ノードを Operator マニフェストおよびミラーリングされたレジストリーに保存されるイメージ参照間で変換できるように設定します。注記クラスターが
ImageContentSourcePolicy
オブジェクトを使用してリポジトリーのミラーリングを設定する場合、ミラーリングされたレジストリーにグローバルプルシークレットのみを使用できます。プロジェクトにプルシークレットを追加することはできません。mapping.txt
ファイルには、すべてのソースイメージが含まれ、これはそれらのイメージをターゲットレジストリー内のどこにマップするかを示します。このファイルはoc image mirror
コマンドと互換性があり、ミラーリング設定をさらにカスタマイズするために使用できます。重要ミラーリングのプロセスで
--manifests-only
フラグを使用しており、ミラーリングするパッケージのサブセットをさらにトリミングするには、mapping.txt
ファイルの変更およびoc image mirror
コマンドでのファイルの使用について、OpenShift Container Platform 4.7 ドキュメントの Package Manifest Format カタログイメージのミラーリング の手順を参照してください。
2.3.7.4. インストール後の要件
カタログのミラーリング後、残りのクラスターインストールを続行できます。クラスターのインストールが正常に完了した後に、この手順から manifests ディレクトリーを指定して ImageContentSourcePolicy
および CatalogSource
オブジェクトを作成する必要があります。これらのオブジェクトは、OperatorHub からの Operator のインストールを設定し、有効にするために必要です。
2.3.8. 次のステップ
- VMware vSphere、ベアメタル、または Amazon Web Services など、ネットワークが制限された環境でプロビジョニングするインフラストラクチャーにクラスターをインストールします。
2.3.9. 関連情報
- must-gather の使用の詳細は、特定機能に関するデータの収集 を参照してください。
2.4. oc-mirror プラグインを使用した非接続インストールのイメージのミラーリング
プライベートレジストリー内の OpenShift Container Platform コンテナーイメージのミラーリングされたセットからクラスターをインストールすることにより、インターネットに直接接続せずに制限されたネットワークでクラスターを実行することができます。このレジストリーは、クラスターが実行されている限り、常に実行されている必要があります。詳細は、前提条件 セクションを参照してください。
oc-mirror OpenShift CLI (oc
) プラグインを使用して、完全なまたは部分的な非接続環境でイメージをミラーレジストリーにミラーリングできます。公式の Red Hat レジストリーから必要なイメージをダウンロードするには、インターネット接続のあるシステムから oc-mirror を実行する必要があります。
次の手順は、oc-mirror プラグインを使用してイメージをミラーレジストリーにミラーリングする方法の概要を示しています。
- イメージセット設定ファイルを作成します。
以下のいずれかの方法を使用して、イメージセットをミラーレジストリーにミラーリングします。
- イメージセットをミラーレジストリーに直接ミラーリングします。
- イメージセットをディスクにミラーリングし、イメージセットをターゲット環境に転送してから、イメージセットをターゲットミラーレジストリーにアップロードします。
- oc-mirror プラグインが生成したリソースを使用するようにクラスターを設定します。
- これらの手順を繰り返して、必要に応じてミラーレジストリーを更新します。
2.4.1. oc-mirror プラグインについて
oc-mirror OpenShift CLI(oc
) プラグインを使用すると、単一のツールを使用して、必要なすべての OpenShift Container Platform コンテンツおよびその他のイメージをミラーレジストリーにミラーリングできます。次の機能を提供します。
- OpenShift Container Platform のリリース、Operator、ヘルムチャート、およびその他のイメージをミラーリングするための一元化された方法を提供します。
- OpenShift Container Platform および Operator の更新パスを維持します。
- 宣言型イメージセット設定ファイルを使用して、クラスターに必要な OpenShift Container Platform リリース、Operator、およびイメージのみを含めます。
- 将来のイメージセットのサイズを縮小するインクリメンタルミラーリングを実行します。
- 前回の実行以降にイメージセット設定から除外されたターゲットミラーレジストリーからのイメージをプルーニングします。
- オプションで、OpenShift Update Service (OSUS) を使用する際のサポートアーティファクトを生成します。
oc-mirror プラグインを使用する場合、イメージセット設定ファイルでミラーリングするコンテンツを指定します。この YAML ファイルでは、クラスターに必要な OpenShift Container Platform リリースと Operator のみを含めるように設定を微調整できます。これにより、ダウンロードして転送する必要のあるデータの量が減ります。oc-mirror プラグインは、任意のヘルムチャートと追加のコンテナーイメージをミラーリングして、ユーザーがワークロードをミラーレジストリーにシームレスに同期できるようにすることもできます。
oc-mirror プラグインを初めて実行すると、非接続クラスターのインストールまたは更新を実行するために必要なコンテンツがミラーレジストリーに入力されます。非接続クラスターが更新を受信し続けるには、ミラーレジストリーを更新しておく必要があります。ミラーレジストリーを更新するには、最初に実行したときと同じ設定を使用して oc-mirror プラグインを実行します。oc-mirror プラグインは、ストレージバックエンドからメタデータを参照し、ツールを最後に実行してからリリースされたもののみをダウンロードします。これにより、OpenShift Container Platform および Operator の更新パスが提供され、必要に応じて依存関係の解決が実行されます。
oc-mirror CLI プラグインを使用してミラーレジストリーにデータを入力する場合、ミラーレジストリーをさらに更新するには、oc-mirror ツールを使用する必要があります。
2.4.2. oc-mirror の互換性とサポート
oc-mirror プラグインは、OpenShift Container Platform バージョン 4.10 以降の OpenShift Container Platform ペイロードイメージと Operator カタログのミラーリングをサポートします。
aarch64
、ppc64le
、および s390x
アーキテクチャーでは、oc-mirror プラグインは OpenShift Container Platform バージョン 4.14 以降でのみサポートされます。
ミラーリングする必要がある OpenShift Container Platform のバージョンに関係なく、使用可能な最新バージョンの oc-mirror プラグインを使用してください。
OpenShift Container Platform 4.12 の oc-mirror プラグインの Technology Preview OCI ローカルカタログ機能を使用した場合、完全に切断されたクラスターへのミラーリングの最初のステップとして、ローカルにカタログをコピーして OCI 形式に変換するために oc-mirror プラグインの OCI ローカルカタログ機能を使用できないようになりました。
2.4.3. ミラーレジストリーについて
OpenShift Container Platform のインストールとその後の製品更新に必要なイメージを、Red Hat Quay などの Docker v2-2 をサポートするコンテナーミラーレジストリーにミラーリングできます。大規模なコンテナーレジストリーにアクセスできない場合は、OpenShift Container Platform サブスクリプションに含まれる小規模なコンテナーレジストリーであるRed Hat OpenShift 導入用のミラーレジストリー を使用できます。
選択したレジストリーに関係なく、インターネット上の Red Hat がホストするサイトから分離されたイメージレジストリーにコンテンツをミラーリングする手順は同じです。コンテンツをミラーリングした後に、各クラスターをミラーレジストリーからこのコンテンツを取得するように設定します。
OpenShift イメージレジストリーはターゲットレジストリーとして使用できません。これは、ミラーリングプロセスで必要となるタグを使わないプッシュをサポートしないためです。
Red Hat OpenShift 導入用のミラーレジストリー 以外のコンテナーレジストリーを選択する場合は、プロビジョニングするクラスター内の全マシンから到達可能である必要があります。レジストリーに到達できない場合、インストール、更新、またはワークロードの再配置などの通常の操作が失敗する可能性があります。そのため、ミラーレジストリーは可用性の高い方法で実行し、ミラーレジストリーは少なくとも OpenShift Container Platform クラスターの実稼働環境の可用性の条件に一致している必要があります。
ミラーレジストリーを OpenShift Container Platform イメージで設定する場合、2 つのシナリオを実行することができます。インターネットとミラーレジストリーの両方にアクセスできるホストがあり、クラスターノードにアクセスできない場合は、そのマシンからコンテンツを直接ミラーリングできます。このプロセスは、connected mirroring (接続ミラーリング) と呼ばれます。このようなホストがない場合は、イメージをファイルシステムにミラーリングしてから、そのホストまたはリムーバブルメディアを制限された環境に配置する必要があります。このプロセスは、disconnected mirroring (非接続ミラーリング) と呼ばれます。
ミラーリングされたレジストリーの場合は、プルされたイメージのソースを表示するには、CRI-O ログで Trying to access
のログエントリーを確認する必要があります。ノードで crictl images
コマンドを使用するなど、イメージのプルソースを表示する他の方法では、イメージがミラーリングされた場所からプルされている場合でも、ミラーリングされていないイメージ名を表示します。
Red Hat は、OpenShift Container Platform を使用してサードパーティーのレジストリーをテストしません。
関連情報
- CRI-O ログを表示してイメージソースを表示する方法の詳細は、Viewing the image pull source を参照してください。
2.4.4. 前提条件
Red Hat Quay など、OpenShift Container Platform クラスターをホストする場所に Docker v2-2 をサポートするコンテナーイメージレジストリーを持っている。
注記Red Hat Quay を使用する場合は、oc-mirror プラグインでバージョン 3.6 以降を使用する必要があります。Red Hat Quay のライセンスをお持ちの場合は、概念実証のため に、または Red Hat Quay Operator を使用 して Red Hat Quay をデプロイする方法を記載したドキュメントを参照してください。レジストリーの選択とインストールについてさらにサポートが必要な場合は、営業担当者または Red Hat サポートにお問い合わせください。
コンテナーイメージレジストリーの既存のソリューションがまだない場合には、OpenShift Container Platform のサブスクライバーに Red Hat OpenShift 導入用のミラーレジストリー が提供されます。Red Hat OpenShift 導入用のミラーレジストリーはサブスクリプションに含まれており、切断されたインストールで OpenShift Container Platform で必須のコンテナーイメージのミラーリングに使用できる小規模なコンテナーレジストリーです。
2.4.5. ミラーホストの準備
oc-mirror プラグインを使用してイメージをミラーリングする前に、プラグインをインストールし、コンテナーイメージレジストリーの認証情報ファイルを作成して、Red Hat からお使いのミラーへのミラーリングを許可する必要があります。
2.4.5.1. oc-mirror OpenShift CLI プラグインのインストール
oc-mirror OpenShift CLI プラグインを使用してレジストリーイメージをミラーリングするには、プラグインをインストールする必要があります。完全な非接続環境でイメージセットをミラーリングする場合は、インターネットにアクセスできるホストと、ミラーレジストリーにアクセスできる非接続環境のホストに oc-mirror プラグインをインストールしてください。
前提条件
-
OpenShift CLI (
oc
) がインストールされている。 -
oc-mirror を使用するオペレーティングシステムで、
umask
パラメーターを0022
に設定した。 - 使用している RHEL バージョンに適したバイナリーをインストールした。
手順
oc-mirror CLI プラグインをダウンロードします。
- OpenShift Cluster Manager の ダウンロード ページに移動します。
- OpenShift 切断インストールツール セクションで、OpenShift Client (oc) ミラープラグイン の ダウンロード をクリックしてファイルを保存します。
アーカイブを抽出します。
Copy to Clipboard Copied! Toggle word wrap Toggle overflow tar xvzf oc-mirror.tar.gz
$ tar xvzf oc-mirror.tar.gz
必要に応じて、プラグインファイルを更新して実行可能にします。
Copy to Clipboard Copied! Toggle word wrap Toggle overflow chmod +x oc-mirror
$ chmod +x oc-mirror
注記oc-mirror
ファイルの名前を変更しないでください。ファイルを
PATH
に配置して、oc-mirror CLI プラグインをインストールします (例:/usr/local/bin
):。Copy to Clipboard Copied! Toggle word wrap Toggle overflow sudo mv oc-mirror /usr/local/bin/.
$ sudo mv oc-mirror /usr/local/bin/.
検証
oc mirror help
を実行して、プラグインが正常にインストールされたことを確認します。Copy to Clipboard Copied! Toggle word wrap Toggle overflow oc mirror help
$ oc mirror help
2.4.5.2. イメージのミラーリングを可能にする認証情報の設定
Red Hat からミラーへのイメージのミラーリングを可能にするコンテナーイメージレジストリーの認証情報ファイルを作成します。
クラスターのインストール時に、このイメージレジストリー認証情報ファイルをプルシークレットとして使用しないでください。クラスターのインストール時にこのファイルを指定すると、クラスター内のすべてのマシンにミラーレジストリーへの書き込みアクセスが付与されます。
このプロセスでは、ミラーレジストリーのコンテナーイメージレジストリーへの書き込みアクセスがあり、認証情報をレジストリープルシークレットに追加する必要があります。
前提条件
- 非接続環境で使用するミラーレジストリーを設定しました。
- イメージをミラーリングするミラーレジストリー上のイメージリポジトリーの場所を特定している。
- イメージのイメージリポジトリーへのアップロードを許可するミラーレジストリーアカウントをプロビジョニングしている。
手順
インストールホストで以下の手順を実行します。
-
registry.redhat.io
プルシークレットを Red Hat OpenShift Cluster Manager からダウンロードします。 JSON 形式でプルシークレットのコピーを作成します。
Copy to Clipboard Copied! Toggle word wrap Toggle overflow cat ./pull-secret | jq . > <path>/<pull_secret_file_in_json>
$ cat ./pull-secret | jq . > <path>/<pull_secret_file_in_json>
1 - 1
- プルシークレットを保存するフォルダーへのパスおよび作成する JSON ファイルの名前を指定します。
ファイルの内容は以下の例のようになります。
Copy to Clipboard Copied! Toggle word wrap Toggle overflow { "auths": { "cloud.openshift.com": { "auth": "b3BlbnNo...", "email": "you@example.com" }, "quay.io": { "auth": "b3BlbnNo...", "email": "you@example.com" }, "registry.connect.redhat.com": { "auth": "NTE3Njg5Nj...", "email": "you@example.com" }, "registry.redhat.io": { "auth": "NTE3Njg5Nj...", "email": "you@example.com" } } }
{ "auths": { "cloud.openshift.com": { "auth": "b3BlbnNo...", "email": "you@example.com" }, "quay.io": { "auth": "b3BlbnNo...", "email": "you@example.com" }, "registry.connect.redhat.com": { "auth": "NTE3Njg5Nj...", "email": "you@example.com" }, "registry.redhat.io": { "auth": "NTE3Njg5Nj...", "email": "you@example.com" } } }
ファイルを、
~/.docker/config.json
または$XDG_RUNTIME_DIR/containers/auth.json
として保存します。.docker
または$XDG_RUNTIME_DIR/containers
ディレクトリーが存在しない場合は、次のコマンドを入力して作成します。Copy to Clipboard Copied! Toggle word wrap Toggle overflow mkdir -p <directory_name>
$ mkdir -p <directory_name>
この場合の
<directory_name>
は、~/.docker
または$XDG_RUNTIME_DIR/containers
のいずれかです。次のコマンドを入力して、プルシークレットを適切なディレクトリーにコピーします。
Copy to Clipboard Copied! Toggle word wrap Toggle overflow cp <path>/<pull_secret_file_in_json> <directory_name>/<auth_file>
$ cp <path>/<pull_secret_file_in_json> <directory_name>/<auth_file>
この場合の
<directory_name>
は~/.docker
または$XDG_RUNTIME_DIR/containers
、<auth_file>
はconfig.json
またはauth.json
のいずれかです。
ミラーレジストリーの base64 でエンコードされたユーザー名およびパスワードまたはトークンを生成します。
Copy to Clipboard Copied! Toggle word wrap Toggle overflow echo -n '<user_name>:<password>' | base64 -w0
$ echo -n '<user_name>:<password>' | base64 -w0
1 BGVtbYk3ZHAtqXs=
- 1
<user_name>
および<password>
については、レジストリーに設定したユーザー名およびパスワードを指定します。
JSON ファイルを編集し、レジストリーについて記述するセクションをこれに追加します。
Copy to Clipboard Copied! Toggle word wrap Toggle overflow "auths": { "<mirror_registry>": { "auth": "<credentials>", "email": "you@example.com" } },
"auths": { "<mirror_registry>": {
1 "auth": "<credentials>",
2 "email": "you@example.com" } },
ファイルは以下の例のようになります。
Copy to Clipboard Copied! Toggle word wrap Toggle overflow { "auths": { "registry.example.com": { "auth": "BGVtbYk3ZHAtqXs=", "email": "you@example.com" }, "cloud.openshift.com": { "auth": "b3BlbnNo...", "email": "you@example.com" }, "quay.io": { "auth": "b3BlbnNo...", "email": "you@example.com" }, "registry.connect.redhat.com": { "auth": "NTE3Njg5Nj...", "email": "you@example.com" }, "registry.redhat.io": { "auth": "NTE3Njg5Nj...", "email": "you@example.com" } } }
{ "auths": { "registry.example.com": { "auth": "BGVtbYk3ZHAtqXs=", "email": "you@example.com" }, "cloud.openshift.com": { "auth": "b3BlbnNo...", "email": "you@example.com" }, "quay.io": { "auth": "b3BlbnNo...", "email": "you@example.com" }, "registry.connect.redhat.com": { "auth": "NTE3Njg5Nj...", "email": "you@example.com" }, "registry.redhat.io": { "auth": "NTE3Njg5Nj...", "email": "you@example.com" } } }
2.4.6. イメージセット設定の作成
oc-mirror プラグインを使用してイメージセットをミラーリングする前に、イメージセット設定ファイルを作成する必要があります。このイメージセット設定ファイルは、ミラーリングする OpenShift Container Platform リリース、Operator、およびその他のイメージと、oc-mirror プラグインの他の設定を定義します。
イメージセット設定ファイルでストレージバックエンドを指定する必要があります。このストレージバックエンドは、Docker v2-2 をサポートするローカルディレクトリーまたはレジストリーにすることができます。oc-mirror プラグインは、イメージセットの作成中にこのストレージバックエンドにメタデータを保存します。
oc-mirror プラグインによって生成されたメタデータを削除または変更しないでください。同じミラーレジストリーに対して oc-mirror プラグインを実行するたびに、同じストレージバックエンドを使用する必要があります。
前提条件
- コンテナーイメージレジストリーの認証情報ファイルを作成している。手順については、イメージのミラーリングを可能にする認証情報の設定 を参照してください。
手順
oc mirror init
コマンドを使用して、イメージセット設定のテンプレートを作成し、それをimageset-config.yaml
というファイルに保存します。Copy to Clipboard Copied! Toggle word wrap Toggle overflow oc mirror init --registry example.com/mirror/oc-mirror-metadata > imageset-config.yaml
$ oc mirror init --registry example.com/mirror/oc-mirror-metadata > imageset-config.yaml
1 - 1
example.com/mirror/oc-mirror-metadata
をストレージバックエンドのレジストリーの場所に置き換えます。
ファイルを編集し、必要に応じて設定を調整します。
Copy to Clipboard Copied! Toggle word wrap Toggle overflow kind: ImageSetConfiguration apiVersion: mirror.openshift.io/v1alpha2 archiveSize: 4 storageConfig: registry: imageURL: example.com/mirror/oc-mirror-metadata skipTLS: false mirror: platform: channels: - name: stable-4.15 type: ocp graph: true operators: - catalog: registry.redhat.io/redhat/redhat-operator-index:v4.15 packages: - name: serverless-operator channels: - name: stable additionalImages: - name: registry.redhat.io/ubi9/ubi:latest helm: {}
kind: ImageSetConfiguration apiVersion: mirror.openshift.io/v1alpha2 archiveSize: 4
1 storageConfig:
2 registry: imageURL: example.com/mirror/oc-mirror-metadata
3 skipTLS: false mirror: platform: channels: - name: stable-4.15
4 type: ocp graph: true
5 operators: - catalog: registry.redhat.io/redhat/redhat-operator-index:v4.15
6 packages: - name: serverless-operator
7 channels: - name: stable
8 additionalImages: - name: registry.redhat.io/ubi9/ubi:latest
9 helm: {}
- 1
archiveSize
を追加して、イメージセット内の各ファイルの最大サイズを GiB 単位で設定します。- 2
- イメージセットのメタデータを保存するバックエンドの場所を設定します。この場所は、レジストリーまたはローカルディレクトリーにすることができます。
storageConfig
値を指定する必要があります。 - 3
- ストレージバックエンドのレジストリー URL を設定します。
- 4
- OpenShift Container Platform イメージを取得するためのチャネルを設定します。
- 5
graph: true
を追加して、グラフデータイメージをビルドし、ミラーレジストリーにプッシュします。OpenShift Update Service (OSUS) を作成するには、graph-data イメージが必要です。graph: true
フィールドはUpdateService
カスタムリソースマニフェストも生成します。oc
コマンドラインインターフェイス (CLI) は、UpdateService
カスタムリソースマニフェストを使用して OSUS を作成できます。詳細は、OpenShift Update Service について を参照してください。- 6
- OpenShift Container Platform イメージを取得するための Operator カタログを設定します。
- 7
- イメージセットに含める特定の Operator パッケージのみを指定します。カタログ内のすべてのパッケージを取得するには、このフィールドを削除してください。
- 8
- イメージセットに含める Operator パッケージの特定のチャネルのみを指定します。そのチャネルでバンドルを使用しない場合も、常に Operator パッケージのデフォルトチャネルを含める必要があります。
oc mirror list operators --catalog=<catalog_name> --package=<package_name>
コマンドを実行すると、デフォルトチャネルを見つけることができます。 - 9
- イメージセットに含める追加のイメージを指定します。
注記graph: true
フィールド は、他のミラーリングされたイメージとともにubi-micro
イメージもミラーリングします。OpenShift Container Platform Extended Update Support (EUS)バージョンをアップグレードする場合、現在のバージョンとターゲットバージョンの間で中間バージョンが必要になる場合があります。たとえば、現在のバージョンが
4
.
14 で、ターゲットバージョンが 4.16 の場合は、oc-mirror プラグイン v1 を使用する場合は、ImageSetConfiguration
に4.15
.8 などのバージョンを含める必要がある場合があります。oc-mirror プラグイン v1 は常にこれを自動的に検出するわけではない可能性があるため、Cincinnati グラフ Web ページ をチェックして、必要な中間バージョンを確認し、それらを設定に手動で追加します。
パラメーターの完全なリストについては、イメージセットの設定パラメーター を参照してください。また、さまざまなミラーリングのユースケースについては、イメージセットの設定例 を参照してください。
更新したファイルを保存します。
このイメージセット設定ファイルは、コンテンツをミラーリングするときに
oc mirror
コマンドで必要になります。
2.4.7. イメージセットをミラーレジストリーにミラーリングする
oc-mirror CLI プラグインを使用して、部分的な非接続環境 または 完全な非接続環境 でイメージをミラーレジストリーにミラーリングできます。
これらの手順は、ミラーレジストリーがすでに設定されていることを前提としています。
2.4.7.1. 部分的な非接続環境でのイメージセットのミラーリング
部分的な非接続環境では、イメージセットをターゲットミラーレジストリーに直接ミラーリングできます。
2.4.7.1.1. ミラーからミラーへのミラーリング
oc-mirror プラグインを使用して、イメージセットの作成中にアクセス可能なターゲットミラーレジストリーにイメージセットを直接ミラーリングできます。
イメージセット設定ファイルでストレージバックエンドを指定する必要があります。このストレージバックエンドは、ローカルディレクトリーまたは Dockerv2 レジストリーにすることができます。oc-mirror プラグインは、イメージセットの作成中にこのストレージバックエンドにメタデータを保存します。
oc-mirror プラグインによって生成されたメタデータを削除または変更しないでください。同じミラーレジストリーに対して oc-mirror プラグインを実行するたびに、同じストレージバックエンドを使用する必要があります。
前提条件
- 必要なコンテナーイメージを取得するためのインターネットへのアクセスがある。
-
OpenShift CLI (
oc
) がインストールされている。 -
oc-mirror
CLI プラグインをインストールしている。 - イメージセット設定ファイルを作成している。
手順
oc mirror
コマンドを実行して、指定されたイメージセット設定から指定されたレジストリーにイメージをミラーリングします。Copy to Clipboard Copied! Toggle word wrap Toggle overflow oc mirror --config=./<imageset-config.yaml> \ docker://registry.example:5000
$ oc mirror --config=./<imageset-config.yaml> \
1 docker://registry.example:5000
2
検証
-
生成された
oc-mirror-workspace/
ディレクトリーに移動します。 -
results ディレクトリーに移動します (例:
results-1639608409/
。 -
ImageContentSourcePolicy
およびCatalogSource
リソースに YAML ファイルが存在することを確認します。
ImageContentSourcePolicy
YAML ファイルの repositoryDigestMirrors
セクションは、インストール中に install-config.yaml
ファイルとして使用されます。
次のステップ
- oc-mirror が生成したリソースを使用するようにクラスターを設定します。
トラブルシューティング
2.4.7.2. 完全な非接続環境でのイメージセットのミラーリング
完全な非接続環境でイメージセットをミラーリングするには、最初に イメージセットをディスクにミラーリング してから、ディスク上のイメージセットファイルをミラーにミラーリング する必要があります。
2.4.7.2.1. ミラーからディスクへのミラーリング
oc-mirror プラグインを使用して、イメージセットを生成し、コンテンツをディスクに保存できます。生成されたイメージセットは、非接続環境に転送され、ターゲットレジストリーにミラーリングされます。
イメージセット設定ファイルで指定されている設定によっては、oc-mirror を使用してイメージをミラーリングすると、数百ギガバイトのデータがディスクにダウンロードされる場合があります。
多くの場合、ミラーレジストリーにデータを入力するときの最初のイメージセットのダウンロードが、最も大きなものとなります。最後にコマンドを実行した後に変更されたイメージのみをダウンロードするため、oc-mirror プラグインを再度実行すると、生成されるイメージセットは小さいことが多いです。
イメージセット設定ファイルでストレージバックエンドを指定する必要があります。このストレージバックエンドは、ローカルディレクトリーまたは docker v2 レジストリーにすることができます。oc-mirror プラグインは、イメージセットの作成中にこのストレージバックエンドにメタデータを保存します。
oc-mirror プラグインによって生成されたメタデータを削除または変更しないでください。同じミラーレジストリーに対して oc-mirror プラグインを実行するたびに、同じストレージバックエンドを使用する必要があります。
前提条件
- 必要なコンテナーイメージを取得するためのインターネットへのアクセスがある。
-
OpenShift CLI (
oc
) がインストールされている。 -
oc-mirror
CLI プラグインをインストールしている。 - イメージセット設定ファイルを作成している。
手順
oc mirror
コマンドを実行して、指定されたイメージセット設定からディスクにイメージをミラーリングします。Copy to Clipboard Copied! Toggle word wrap Toggle overflow oc mirror --config=./imageset-config.yaml \ file://<path_to_output_directory>
$ oc mirror --config=./imageset-config.yaml \
1 file://<path_to_output_directory>
2
検証
出力ディレクトリーに移動します。
Copy to Clipboard Copied! Toggle word wrap Toggle overflow cd <path_to_output_directory>
$ cd <path_to_output_directory>
イメージセットの
.tar
ファイルが作成されたことを確認します。Copy to Clipboard Copied! Toggle word wrap Toggle overflow ls
$ ls
出力例
Copy to Clipboard Copied! Toggle word wrap Toggle overflow mirror_seq1_000000.tar
mirror_seq1_000000.tar
次のステップ
- イメージセットの.tar ファイルを非接続環境に転送します。
トラブルシューティング
2.4.7.2.2. ディスクからミラーへのミラーリング
oc-mirror プラグインを使用して、生成されたイメージセットの内容をターゲットミラーレジストリーにミラーリングできます。
前提条件
-
非接続環境に OpenShift CLI (
oc
) をインストールしている。 -
非接続環境に
oc-mirror
CLI プラグインをインストールしている。 -
oc mirror
コマンドを使用してイメージセットファイルを生成している。 - イメージセットファイルを非接続環境に転送しました。
手順
oc mirror
コマンドを実行して、ディスク上のイメージセットファイルを処理し、その内容をターゲットミラーレジストリーにミラーリングします。Copy to Clipboard Copied! Toggle word wrap Toggle overflow oc mirror --from=./mirror_seq1_000000.tar \ docker://registry.example:5000
$ oc mirror --from=./mirror_seq1_000000.tar \
1 docker://registry.example:5000
2 - 1
- この例では、
mirror_seq1_000000.tar
という名前のイメージセット.tar ファイルをミラーに渡します。イメージセット設定ファイルでarchiveSize
値が指定されている場合、イメージセットは複数の.tar ファイルに分割される可能性があります。この状況では、イメージセットの.tar ファイルを含むディレクトリーを渡すことができます。 - 2
- イメージセットファイルをミラーリングするレジストリーを指定します。レジストリーは
docker://
で始まる必要があります。ミラーレジストリーに最上位の namespace を指定する場合は、これ以降の実行でもこれと同じ namespace を使用する必要があります。
このコマンドは、ミラーレジストリーをイメージセットで更新し、
ImageContentSourcePolicy
およびCatalogSource
リソースを生成します。
検証
-
生成された
oc-mirror-workspace/
ディレクトリーに移動します。 -
results ディレクトリーに移動します (例:
results-1639608409/
。 -
ImageContentSourcePolicy
およびCatalogSource
リソースに YAML ファイルが存在することを確認します。
次のステップ
- oc-mirror が生成したリソースを使用するようにクラスターを設定します。
トラブルシューティング
2.4.8. oc-mirror が生成したリソースを使用するためのクラスター設定
イメージセットをミラーレジストリーにミラーリングした後に、生成された ImageContentSourcePolicy
、CatalogSource
、およびリリースイメージの署名リソースをクラスターに適用する必要があります。
ImageContentSourcePolicy
リソースは、ミラーレジストリーをソースレジストリーに関連付け、イメージプル要求をオンラインレジストリーからミラーレジストリーにリダイレクトします。CatalogSource
リソースは、Operator Lifecycle Manager (OLM) によって使用され、ミラーレジストリーで使用可能な Operator に関する情報を取得します。リリースイメージの署名は、ミラーリングされたリリースイメージの検証に使用されます。
前提条件
- 非接続環境で、イメージセットをレジストリーミラーにミラーリングしました。
-
cluster-admin
ロールを持つユーザーとしてクラスターにアクセスできる。
手順
-
cluster-admin
ロールを持つユーザーとして OpenShift CLI にログインします。 以下のコマンドを実行して、results ディレクトリーからクラスターに YAML ファイルを適用します。
Copy to Clipboard Copied! Toggle word wrap Toggle overflow oc apply -f ./oc-mirror-workspace/results-1639608409/
$ oc apply -f ./oc-mirror-workspace/results-1639608409/
リリースイメージをミラーリングした場合は、次のコマンドを実行して、リリースイメージの署名をクラスターに適用します。
Copy to Clipboard Copied! Toggle word wrap Toggle overflow oc apply -f ./oc-mirror-workspace/results-1639608409/release-signatures/
$ oc apply -f ./oc-mirror-workspace/results-1639608409/release-signatures/
注記クラスターではなく Operator をミラーリングしている場合、
$ oc apply -f ./oc-mirror-workspace/results-1639608409/release-signatures/
を実行する必要はありません。適用するリリースイメージ署名がないため、このコマンドを実行するとエラーが返されます。
検証
以下のコマンドを実行して、
ImageContentSourcePolicy
リソースが正常にインストールされたことを確認します。Copy to Clipboard Copied! Toggle word wrap Toggle overflow oc get imagecontentsourcepolicy
$ oc get imagecontentsourcepolicy
以下のコマンドを実行して、
CatalogSource
リソースが正常にインストールされたことを確認します。Copy to Clipboard Copied! Toggle word wrap Toggle overflow oc get catalogsource -n openshift-marketplace
$ oc get catalogsource -n openshift-marketplace
2.4.9. ミラーレジストリーのコンテンツを最新の状態に保つ
ターゲットミラーレジストリーに初期イメージセットが設定された後は、定期的に更新して、最新の内容になるようにしてください。可能であれば、必要に応じて cron ジョブを設定して、ミラーレジストリーが定期的に更新されるようにすることもできます。
イメージセットの設定を更新して、必要に応じて OpenShift Container Platform および Operator リリースを追加または削除してください。削除されるすべてのイメージは、ミラーレジストリーからプルーニングされます。
2.4.9.1. ミラーレジストリーコンテンツの更新について
oc-mirror プラグインを再度実行すると、前回の実行以降に新しく更新されたイメージのみを含むイメージセットが生成されます。前に作成されたイメージセットとの違いのみを取り込むため、生成されたイメージセットは、多くの場合、最初のイメージセットよりも小さく、迅速に処理されます。
生成されたイメージセットはシーケンシャルであり、ターゲットミラーレジストリーに順番にプッシュする必要があります。シーケンス番号は、生成されたイメージセットアーカイブファイルのファイル名から取得できます。
新規イメージおよび更新されたイメージの追加
イメージセット設定の設定に応じて、oc-mirror を今後実行すると、追加の新しいイメージと更新されたイメージがミラーリングされます。イメージセット設定の設定を確認して、必要に応じて新しいバージョンを取得していることを確認します。たとえば、特定のバージョンに制限する場合は、Operator の最小バージョンと最大バージョンをミラーリングするように設定できます。または、最小バージョンをミラーリングの開始点として設定することもできますが、バージョン範囲は開いたままにして、oc-mirror の今後の実行時に新しい Operator バージョンを受け取り続けることができます。最小または最大バージョンを省略すると、チャネル内の Operator の完全なバージョン履歴が得られます。明示的に名前付けされたチャネルを省略すると、指定された Operator のすべてのチャネルのすべてのリリースが提供されます。名前付き Operator を省略すると、これまでにリリースされたすべての Operator とそのすべてのバージョンのカタログ全体が提供されます。
これらすべての制約と条件は、oc-mirror が呼び出されるたびに Red Hat によって公開されたコンテンツに対して評価されます。このようにして、新しいリリースとまったく新しい Operator を自動的にピックアップします。制約は、必要な Operator のセットをリストするだけで指定できます。これにより、新しくリリースされた他の Operator がミラーセットに自動的に追加されることはありません。特定のリリースチャネルを指定することもできます。これにより、ミラーリングは追加された新しいチャネルではなく、このチャネルのみに制限されます。これは、マイナーリリースに異なるリリースチャネルを使用する Red Hat Quay などの Operator 製品にとって重要です。最後に、特定の Operator の最大バージョンを指定できます。これにより、ツールは指定されたバージョン範囲のみをミラーリングするため、ミラーリングされた最大バージョンを超えた新しいリリースが自動的に取得されることはありません。これらのすべての場合において、イメージセット設定ファイルを更新して Operator のミラーリングの範囲を広げ、他の Operator、新しいチャネル、および Operator の新しいバージョンをターゲットレジストリーで使用できるようにする必要があります。
チャネル仕様やバージョン範囲などの制約を、特定の Operator が選択したリリースストラテジーに合わせることを推奨します。たとえば、Operator が stable
チャネルを使用している場合、ミラーリングをそのチャネルと可能ならば最小バージョンに制限し、ダウンロード量と定期的な安定した更新の取得との間の適切なバランスを見つける必要があります。Operator がリリースバージョンのチャネルスキーム (stable-3.7
など) を選択した場合、そのチャネルのすべてのリリースをミラーリングする必要があります。これにより、Operator のパッチバージョン (3.7.1
など) を引き続き受け取ることができます。また、イメージセットの設定を定期的に調整して、新製品リリース (stable-3.8
など) 用のチャネルを追加することもできます。
イメージのプルーニング
イメージは、生成およびミラーリングされた最新のイメージセットに含まれなくなった場合、ターゲットミラーレジストリーから自動的にプルーニングされます。これにより、不要なコンテンツを簡単に管理およびクリーンアップし、ストレージリソースを解放することができます。
不要になった OpenShift Container Platform リリースまたは Operator バージョンがある場合、イメージセットの設定を変更してそれらを除外できます。これらはミラーリング時にミラーレジストリーからプルーニングされます。これは、イメージセット設定ファイルで Operator ごとに最小または最大バージョン範囲の設定を調整するか、カタログからミラーリングする Operator のリストから Operator を削除することによって実行できます。Operator カタログ全体または OpenShift Container Platform リリース全体を設定ファイルから削除することもできます。
ミラーリングする新しいイメージまたは更新されたイメージがない場合、除外されたイメージはターゲットミラーレジストリーからプルーニングされません。さらに、Operator パブリッシャーがチャネルから Operator バージョンを削除すると、削除されたバージョンはターゲットミラーレジストリーからプルーニングされます。
ターゲットミラーレジストリーからのイメージの自動プルーニングを無効にするには、--skip-pruning
フラグを oc mirror
コマンドに渡します。
2.4.9.2. ミラーレジストリーコンテンツの更新
初期イメージセットをミラーレジストリーに公開した後、oc-mirror プラグインを使用して、切断されたクラスターを最新の状態に保つことができます。
イメージセットの設定に応じて、oc-mirror は、初期ミラーリングの完了後にリリースされた OpenShift Container Platform および選択した Operator の新しいリリースを自動的に検出します。たとえば、毎晩の cron ジョブなどで、定期的に oc-mirror を実行し、製品とセキュリティーの更新をタイムリーに受信することを推奨します。
前提条件
- oc-mirror プラグインを使用して、最初のイメージセットをミラーレジストリーにミラーリングしている。
oc-mirror プラグインの最初の実行に使用されたストレージバックエンドにアクセスできる。
注記同じミラーレジストリーに対して oc-mirror の最初の実行と同じストレージバックエンドを使用する必要があります。oc-mirror プラグインによって生成されたメタデータイメージを削除または変更しないでください。
手順
- 必要に応じて、イメージセット設定ファイルを更新して、新しい OpenShift Container Platform および Operator バージョンを取得します。ミラーリングの使用例については、イメージセットの設定例 を参照してください。
初期イメージセットをミラーレジストリーにミラーリングしたときと同じ手順に従います。手順については、部分的な非接続環境でのイメージセットのミラーリング または 完全な非接続環境でのイメージセットのミラーリング を参照してください。
重要- 差分イメージセットのみが作成およびミラーリングされるように、同じストレージバックエンドを提供する必要があります。
- イメージセットの最初の作成時にミラーレジストリーにトップレベルの namespace を指定した場合は、同じミラーレジストリーに対して oc-mirror プラグインを実行するたびに、この同じ namespace を使用する必要があります。
- oc-mirror が生成したリソースを使用するようにクラスターを設定します。
2.4.10. ドライランの実行
実際にイメージをミラーリングせずに、oc-mirror を使用してドライランを実行できます。これにより、ミラーリングされるイメージのリストと、ミラーレジストリーからプルーニングされるイメージを確認できます。ドライランを使用すると、イメージセット設定のエラーを早期に検出したり、生成されたイメージリストを他のツールで使用してミラーリング操作を実行したりすることもできます。
前提条件
- 必要なコンテナーイメージを取得するためのインターネットへのアクセスがある。
-
OpenShift CLI (
oc
) がインストールされている。 -
oc-mirror
CLI プラグインをインストールしている。 - イメージセット設定ファイルを作成している。
手順
--dry-run
フラグを指定してoc mirror
コマンドを実行し、ドライランを実行します。Copy to Clipboard Copied! Toggle word wrap Toggle overflow oc mirror --config=./imageset-config.yaml \ docker://registry.example:5000 \ --dry-run
$ oc mirror --config=./imageset-config.yaml \
1 docker://registry.example:5000 \
2 --dry-run
3 出力例
Copy to Clipboard Copied! Toggle word wrap Toggle overflow Checking push permissions for registry.example:5000 Creating directory: oc-mirror-workspace/src/publish Creating directory: oc-mirror-workspace/src/v2 Creating directory: oc-mirror-workspace/src/charts Creating directory: oc-mirror-workspace/src/release-signatures No metadata detected, creating new workspace wrote mirroring manifests to oc-mirror-workspace/operators.1658342351/manifests-redhat-operator-index ... info: Planning completed in 31.48s info: Dry run complete Writing image mapping to oc-mirror-workspace/mapping.txt
Checking push permissions for registry.example:5000 Creating directory: oc-mirror-workspace/src/publish Creating directory: oc-mirror-workspace/src/v2 Creating directory: oc-mirror-workspace/src/charts Creating directory: oc-mirror-workspace/src/release-signatures No metadata detected, creating new workspace wrote mirroring manifests to oc-mirror-workspace/operators.1658342351/manifests-redhat-operator-index ... info: Planning completed in 31.48s info: Dry run complete Writing image mapping to oc-mirror-workspace/mapping.txt
生成されたワークスペースディレクトリーに移動します。
Copy to Clipboard Copied! Toggle word wrap Toggle overflow cd oc-mirror-workspace/
$ cd oc-mirror-workspace/
生成された
mapping.txt
ファイルを確認します。このファイルには、ミラーリングされるすべてのイメージのリストが含まれています。
生成された
pruning-plan.json
ファイルを確認します。このファイルには、イメージセットの公開時にミラーレジストリーからプルーニングされるすべてのイメージのリストが含まれています。
注記pruning-plan.json
ファイルは、oc-mirror コマンドがミラーレジストリーを指し、プルーニングするイメージがある場合にのみ生成されます。
2.4.11. ローカルの OCI Operator カタログを含む
OpenShift Container Platform リリース、Operator カタログ、および追加イメージをレジストリーから部分的に切断されたクラスターにミラーリングするときに、ディスク上のローカルのファイルベースのカタログから Operator カタログイメージを含めることができます。ローカルカタログは Open Container Initiative (OCI) 形式である必要があります。
ローカルカタログとそのコンテンツは、イメージセット設定ファイル内のフィルタリング情報に基づいて、ターゲットミラーレジストリーにミラーリングされます。
ローカル OCI カタログをミラーリングする場合、ローカル OCI 形式のカタログとともにミラーリングする OpenShift Container Platform リリースまたは追加のイメージをレジストリーからプルする必要があります。
OCI カタログを oc-mirror イメージセットファイルと一緒にディスク上でミラーリングすることはできません。
OCI 機能を使用するユースケースの 1 つの例は、ディスク上の場所に OCI カタログを構築している CI/CD システムがあり、その OCI カタログを OpenShift Container Platform リリースとともにミラーレジストリーにミラーリングしたい場合です。
OpenShift Container Platform 4.12 の oc-mirror プラグインの Technology Preview OCI ローカルカタログ機能を使用した場合、完全に切断されたクラスターへのミラーリングの最初のステップとして、ローカルにカタログをコピーして OCI 形式に変換するために oc-mirror プラグインの OCI ローカルカタログ機能を使用できないようになりました。
前提条件
- 必要なコンテナーイメージを取得するためのインターネットへのアクセスがある。
-
OpenShift CLI (
oc
) がインストールされている。 -
oc-mirror
CLI プラグインをインストールしている。
手順
イメージセット設定ファイルを作成し、必要に応じて設定を調整します。
次のイメージセット設定例では、OpenShift Container Platform リリースおよび
registry.redhat.io
の UBI イメージとともに、ディスク上の OCI カタログをミラーリングします。Copy to Clipboard Copied! Toggle word wrap Toggle overflow kind: ImageSetConfiguration apiVersion: mirror.openshift.io/v1alpha2 storageConfig: local: path: /home/user/metadata mirror: platform: channels: - name: stable-4.15 type: ocp graph: false operators: - catalog: oci:///home/user/oc-mirror/my-oci-catalog targetCatalog: my-namespace/redhat-operator-index packages: - name: aws-load-balancer-operator - catalog: registry.redhat.io/redhat/redhat-operator-index:v4.15 packages: - name: rhacs-operator additionalImages: - name: registry.redhat.io/ubi9/ubi:latest
kind: ImageSetConfiguration apiVersion: mirror.openshift.io/v1alpha2 storageConfig: local: path: /home/user/metadata
1 mirror: platform: channels: - name: stable-4.15
2 type: ocp graph: false operators: - catalog: oci:///home/user/oc-mirror/my-oci-catalog
3 targetCatalog: my-namespace/redhat-operator-index
4 packages: - name: aws-load-balancer-operator - catalog: registry.redhat.io/redhat/redhat-operator-index:v4.15
5 packages: - name: rhacs-operator additionalImages: - name: registry.redhat.io/ubi9/ubi:latest
6 - 1
- イメージセットのメタデータを保存するバックエンドの場所を設定します。この場所は、レジストリーまたはローカルディレクトリーにすることができます。
storageConfig
値を指定する必要があります。 - 2
- オプションで、
registry.redhat.io
からミラーリングする OpenShift Container Platform リリースを含めます。 - 3
- ディスク上の OCI カタログの場所への絶対パスを指定します。OCI 機能を使用する場合、パスは
oci://
で始まる必要があります。 - 4
- 必要に応じて、カタログをミラーリングする代替の namespace と名前を指定します。
- 5
- 必要に応じて、レジストリーから取得する追加の Operator カタログを指定します。
- 6
- 必要に応じて、レジストリーからプルする追加のイメージを指定します。
oc mirror
コマンドを実行して、OCI カタログをターゲットミラーレジストリーにミラーリングします。Copy to Clipboard Copied! Toggle word wrap Toggle overflow oc mirror --config=./imageset-config.yaml \ docker://registry.example:5000
$ oc mirror --config=./imageset-config.yaml \
1 docker://registry.example:5000
2 オプションで、他のフラグを指定して OCI 機能の動作を調整できます。
--oci-insecure-signature-policy
- 署名をターゲットミラーレジストリーにプッシュしないでください。
--oci-registries-config
TOML 形式の
registries.conf
ファイルへのパスを指定します。これを使用して、イメージセット設定ファイルを変更することなく、テスト用の運用前の場所など、別のレジストリーからミラーリングできます。このフラグはローカル OCI カタログにのみ影響し、他のミラーリングされたコンテンツには影響しません。registries.conf ファイルの例
Copy to Clipboard Copied! Toggle word wrap Toggle overflow [[registry]] location = "registry.redhat.io:5000" insecure = false blocked = false mirror-by-digest-only = true prefix = "" [[registry.mirror]] location = "preprod-registry.example.com" insecure = false
[[registry]] location = "registry.redhat.io:5000" insecure = false blocked = false mirror-by-digest-only = true prefix = "" [[registry.mirror]] location = "preprod-registry.example.com" insecure = false
次のステップ
- oc-mirror が生成したリソースを使用するようにクラスターを設定します。
2.4.12. Image set configuration parameters
oc-mirror プラグインには、ミラーリングするイメージを定義するイメージセット設定ファイルが必要です。次の表に、ImageSetConfiguration
リソースで使用可能なパラメーターを示します。
パラメーター | 説明 | 値 |
---|---|---|
|
|
文字列。例: |
| イメージセット内の各アーカイブファイルの最大サイズ (GiB 単位)。 |
整数。例: |
| イメージセットの設定。 | オブジェクト |
| イメージセットの追加のイメージ設定。 | オブジェクトの配列。以下に例を示します。 additionalImages: - name: registry.redhat.io/ubi8/ubi:latest
|
| ミラーリングするイメージのタグまたはダイジェスト。 |
文字列。例: |
| ミラーリングからブロックするイメージの完全なタグ、ダイジェスト、またはパターン。 |
文字列の配列例: |
| イメージセットのヘルム設定。oc-mirror プラグインは、レンダリング時にユーザー入力を必要としないヘルムチャートのみをサポートすることに注意してください。 | オブジェクト |
| ミラーリングするローカルヘルムチャート。 | オブジェクトの配列。以下に例を示します。 local: - name: podinfo path: /test/podinfo-5.0.0.tar.gz
|
| ミラーリングするローカルヘルムチャートの名前。 |
文字列。例: |
| ミラーリングするローカルヘルムチャートのパス。 |
文字列。例: |
| ミラーリング元のリモートヘルムリポジトリー。 | オブジェクトの配列。以下に例を示します。 repositories: - name: podinfo url: https://example.github.io/podinfo charts: - name: podinfo version: 5.0.0
|
| ミラーリング元のヘルムリポジトリーの名前。 |
文字列。例: |
| ミラーリング元の helm リポジトリーの URL。 |
文字列。例: |
| ミラーリングするリモートヘルムチャート。 | オブジェクトの配列。 |
| ミラーリングするヘルムチャートの名前。 |
文字列。例: |
| ミラーリングする名前付きヘルムチャートのバージョン。 |
文字列。例: |
| イメージセットの Operators 設定。 | オブジェクトの配列。以下に例を示します。 operators: - catalog: registry.redhat.io/redhat/redhat-operator-index:v4.15 packages: - name: elasticsearch-operator minVersion: '2.4.0'
|
| イメージセットに含める Operator カタログ。 |
文字列。たとえば、 |
|
|
ブール値。デフォルト値は |
| Operator パッケージ設定 | オブジェクトの配列。以下に例を示します。 operators: - catalog: registry.redhat.io/redhat/redhat-operator-index:v4.15 packages: - name: elasticsearch-operator minVersion: '5.2.3-31'
|
| イメージセットに含める Operator パッケージ名 |
文字列。例: |
| Operator パッケージのチャネル設定。 | オブジェクト |
| イメージセットに含める、パッケージ内で一意の Operator チャネル名。 |
文字列。たとえば、 |
| Operator が存在するすべてのチャネルでミラーリングする最上位バージョンの Operator。詳細は、以下の注記を参照してください。 |
文字列。例: |
| 含める最小バンドルの名前と、チャネルヘッドへの更新グラフ内のすべてのバンドル。名前付きバンドルにセマンティックバージョンメタデータがない場合にのみ、このフィールドを設定します。 |
文字列。例: |
| 存在するすべてのチャネル間でミラーリングする Operator の最低バージョン。詳細は、以下の注記を参照してください。 |
文字列。例: |
| Operator が存在するすべてのチャネルでミラーリングする最上位バージョンの Operator。詳細は、以下の注記を参照してください。 |
文字列。例: |
| 存在するすべてのチャネル間でミラーリングする Operator の最低バージョン。詳細は、以下の注記を参照してください。 |
文字列。例: |
|
|
ブール値。デフォルト値は |
| 参照されるカタログをミラーリングするための代替名とオプションの namespace 階層。 |
文字列。例: |
| 参照されたカタログをミラーリングするための代替名。
|
文字列。例: |
|
|
文字列。例: |
| イメージセットのプラットフォーム設定。 | オブジェクト |
| ミラーリングするプラットフォームリリースペイロードのアーキテクチャー。 | 文字列の配列以下に例を示します。 architectures: - amd64 - arm64 - multi - ppc64le - s390x
デフォルト値は |
| イメージセットのプラットフォームチャネル設定。 | オブジェクトの配列。以下に例を示します。 channels: - name: stable-4.10 - name: stable-4.15
|
|
|
ブール値。デフォルト値は |
| リリースチャネルの名前。 |
文字列。たとえば、 |
| ミラーリングされる参照プラットフォームの最小バージョン。 |
文字列。例: |
| ミラーリングされる参照プラットフォームの最上位バージョン。 |
文字列。例: |
| 最短パスミラーリングまたはフルレンジミラーリングを切り替えます。 |
ブール値。デフォルト値は |
| ミラーリングするプラットフォームのタイプ。 |
文字列。例: |
| OSUS グラフがイメージセットに追加され、その後ミラーに公開されるかどうかを示します。 |
ブール値。デフォルト値は |
| イメージセットのバックエンド設定。 | オブジェクト |
| イメージセットのローカルバックエンド設定。 | オブジェクト |
| イメージセットのメタデータを含むディレクトリーのパス。 |
文字列。例: |
| イメージセットのレジストリーバックエンド設定。 | オブジェクト |
| バックエンドレジストリー URI。オプションで、URI に namespace 参照を含めることができます。 |
文字列。例: |
| オプションで、参照されるバックエンドレジストリーの TLS 検証をスキップします。 |
ブール値。デフォルト値は |
minVersion
および maxVersion
プロパティーを使用して特定の Operator バージョン範囲をフィルターすると、複数のチャネルヘッドエラーが発生する可能性があります。エラーメッセージには、multiple channel heads
があることが示されます。これは、フィルターを適用すると、Operator の更新グラフが切り捨てられるためです。
すべての Operator チャネルに、1 つのエンドポイント (つまり最新バージョンの Operator) を持つ更新グラフを構成するバージョンが含まれている必要があります。これは Operator Lifecycle Manager によって要求される要件です。フィルター範囲を適用すると、更新グラフが 2 つ以上の個別のグラフ、または複数のエンドポイントを持つグラフに変換されることがあります。
このエラーを回避するには、最新バージョンの Operator を除外しないでください。それでもエラーが発生する場合は、Operator に応じて、maxVersion
プロパティーを増やすか、minVersion
プロパティーを減らす必要があります。Operator グラフはそれぞれ異なる可能性があるため、エラーが解決するまでこれらの値を調整する必要がある場合があります。
2.4.13. Image set configuration examples
次の ImageSetConfiguration
ファイルの例は、さまざまなミラーリングのユースケースの設定を示しています。
ユースケース: 最短の OpenShift Container Platform 更新パスを含める
以下の ImageSetConfiguration
ファイルは、ローカルストレージバックエンドを使用し、最小バージョン 4.11.37
から最大バージョン 4.12.15
への最短更新パスに沿ってすべての OpenShift Container Platform バージョンを含めます。
ImageSetConfiguration
ファイルの例
apiVersion: mirror.openshift.io/v1alpha2 kind: ImageSetConfiguration storageConfig: local: path: /home/user/metadata mirror: platform: channels: - name: stable-4.12 minVersion: 4.11.37 maxVersion: 4.12.15 shortestPath: true
apiVersion: mirror.openshift.io/v1alpha2
kind: ImageSetConfiguration
storageConfig:
local:
path: /home/user/metadata
mirror:
platform:
channels:
- name: stable-4.12
minVersion: 4.11.37
maxVersion: 4.12.15
shortestPath: true
使用事例: マルチアーキテクチャーリリースの最小バージョンから最新バージョンまでの OpenShift Container Platform のすべてのバージョンを含める
以下の ImageSetConfiguration
ファイルは、レジストリーストレージバックエンドを使用し、最小バージョン 4.13.4
からチャネルの最新バージョンまでのすべての OpenShift Container Platform バージョンを含みます。このイメージセット設定で oc-mirror を呼び出すたびに、stable-4.13
チャネルの最新リリースが評価されるため、定期的に oc-mirror を実行すると、OpenShift Container Platform イメージの最新リリースを自動的に受け取ることができます。
platform.architectures
の値を multi
に設定すると、マルチアーキテクチャーリリースでミラーリングがサポートされるようになります。
ImageSetConfiguration
ファイルの例
apiVersion: mirror.openshift.io/v1alpha2 kind: ImageSetConfiguration storageConfig: registry: imageURL: example.com/mirror/oc-mirror-metadata skipTLS: false mirror: platform: architectures: - "multi" channels: - name: stable-4.13 minVersion: 4.13.4 maxVersion: 4.13.6
apiVersion: mirror.openshift.io/v1alpha2
kind: ImageSetConfiguration
storageConfig:
registry:
imageURL: example.com/mirror/oc-mirror-metadata
skipTLS: false
mirror:
platform:
architectures:
- "multi"
channels:
- name: stable-4.13
minVersion: 4.13.4
maxVersion: 4.13.6
ユースケース: 最小から最新までの Operator バージョンを含める
次のImageSetConfiguration
ファイルは、ローカルストレージバックエンドを使用し、これには、stable
チャネルの Kubernetes Operator 用の Red Hat Advanced Cluster Security (4.0.1 以降のバージョン) のみが含まれています。
最小または最大のバージョン範囲を指定した場合、その範囲内のすべての Operator バージョンを受信できない可能性があります。
デフォルトで、oc-mirror は、Operator Lifecycle Manager (OLM) 仕様でスキップされたバージョン、または新しいバージョンに置き換えられたバージョンを除外します。スキップされた Operator のバージョンは、CVE の影響を受けるか、バグが含まれている可能性があります。代わりに新しいバージョンを使用してください。スキップおよび置き換えられたバージョンの詳細は、OLM を使用した更新グラフの作成 を参照してください。
指定した範囲内のすべての Operator バージョンを受信するには、mirror.operators.full
フィールドを true
に設定します。
ImageSetConfiguration
ファイルの例
apiVersion: mirror.openshift.io/v1alpha2 kind: ImageSetConfiguration storageConfig: local: path: /home/user/metadata mirror: operators: - catalog: registry.redhat.io/redhat/redhat-operator-index:v4.15 packages: - name: rhacs-operator channels: - name: stable minVersion: 4.0.1
apiVersion: mirror.openshift.io/v1alpha2
kind: ImageSetConfiguration
storageConfig:
local:
path: /home/user/metadata
mirror:
operators:
- catalog: registry.redhat.io/redhat/redhat-operator-index:v4.15
packages:
- name: rhacs-operator
channels:
- name: stable
minVersion: 4.0.1
最新バージョンではなく最大バージョンを指定するには、mirror.operators.packages.channels.maxVersion
フィールドを設定します。
ユースケース: Nutanix CSI Operator を含める
次の ImageSetConfiguration
ファイルは、ローカルストレージバックエンドを使用します。このファイルには、Nutanix CSI Operator、OpenShift Update Service (OSUS) グラフイメージ、および追加の Red Hat Universal Base Image (UBI) が含まれます。
ImageSetConfiguration
ファイルの例
kind: ImageSetConfiguration apiVersion: mirror.openshift.io/v1alpha2 storageConfig: registry: imageURL: mylocalregistry/ocp-mirror/openshift4 skipTLS: false mirror: platform: channels: - name: stable-4.11 type: ocp graph: true operators: - catalog: registry.redhat.io/redhat/certified-operator-index:v4.15 packages: - name: nutanixcsioperator channels: - name: stable additionalImages: - name: registry.redhat.io/ubi9/ubi:latest
kind: ImageSetConfiguration
apiVersion: mirror.openshift.io/v1alpha2
storageConfig:
registry:
imageURL: mylocalregistry/ocp-mirror/openshift4
skipTLS: false
mirror:
platform:
channels:
- name: stable-4.11
type: ocp
graph: true
operators:
- catalog: registry.redhat.io/redhat/certified-operator-index:v4.15
packages:
- name: nutanixcsioperator
channels:
- name: stable
additionalImages:
- name: registry.redhat.io/ubi9/ubi:latest
ユースケース: デフォルトの Operator チャネルを含める
次の ImageSetConfiguration
ファイルには、OpenShift Elasticsearch Operator の stable-5.7
および stable
チャネルが含まれています。安定版 5.7
チャネルのパッケージのみが必要な場合でも、stable
チャネルは Operator のデフォルトチャネルであるため、ImageSetConfiguration
ファイルにも含める必要があります。そのチャネルでバンドルを使用しない場合も、常に Operator パッケージのデフォルトチャネルを含める必要があります。
oc mirror list operators --catalog=<catalog_name> --package=<package_name>
コマンドを実行すると、デフォルトチャネルを見つけることができます。
ImageSetConfiguration
ファイルの例
apiVersion: mirror.openshift.io/v1alpha2 kind: ImageSetConfiguration storageConfig: registry: imageURL: example.com/mirror/oc-mirror-metadata skipTLS: false mirror: operators: - catalog: registry.redhat.io/redhat/redhat-operator-index:v4.15 packages: - name: elasticsearch-operator channels: - name: stable-5.7 - name: stable
apiVersion: mirror.openshift.io/v1alpha2
kind: ImageSetConfiguration
storageConfig:
registry:
imageURL: example.com/mirror/oc-mirror-metadata
skipTLS: false
mirror:
operators:
- catalog: registry.redhat.io/redhat/redhat-operator-index:v4.15
packages:
- name: elasticsearch-operator
channels:
- name: stable-5.7
- name: stable
ユースケース: カタログ全体を含める (すべてのバージョン)
次の ImageSetConfiguration
ファイルは、mirror.operators.full
フィールドを true
に設定して、Operator カタログ全体のすべてのバージョンを含めます。
ImageSetConfiguration
ファイルの例
apiVersion: mirror.openshift.io/v1alpha2 kind: ImageSetConfiguration storageConfig: registry: imageURL: example.com/mirror/oc-mirror-metadata skipTLS: false mirror: operators: - catalog: registry.redhat.io/redhat/redhat-operator-index:v4.15 full: true
apiVersion: mirror.openshift.io/v1alpha2
kind: ImageSetConfiguration
storageConfig:
registry:
imageURL: example.com/mirror/oc-mirror-metadata
skipTLS: false
mirror:
operators:
- catalog: registry.redhat.io/redhat/redhat-operator-index:v4.15
full: true
ユースケース: カタログ全体を含める (チャネルヘッドのみ)
次の ImageSetConfiguration
ファイルには、Operator カタログ全体のチャネルヘッドが含まれています。
デフォルトでは、カタログ内の各 Operator において、oc-mirror にはデフォルトチャネルから Operator の最新バージョン (チャネルヘッド) が含まれています。チャネルヘッドだけでなく、すべての Operator バージョンをミラーリングする場合は、mirror.operators.full
フィールドを true
に設定する必要があります。
この例では、targetCatalog
フィールドを使用して、カタログをミラーリングする代替 namespace と名前も指定します。
ImageSetConfiguration
ファイルの例
apiVersion: mirror.openshift.io/v1alpha2 kind: ImageSetConfiguration storageConfig: registry: imageURL: example.com/mirror/oc-mirror-metadata skipTLS: false mirror: operators: - catalog: registry.redhat.io/redhat/redhat-operator-index:v4.15 targetCatalog: my-namespace/my-operator-catalog
apiVersion: mirror.openshift.io/v1alpha2
kind: ImageSetConfiguration
storageConfig:
registry:
imageURL: example.com/mirror/oc-mirror-metadata
skipTLS: false
mirror:
operators:
- catalog: registry.redhat.io/redhat/redhat-operator-index:v4.15
targetCatalog: my-namespace/my-operator-catalog
ユースケース: 任意のイメージとヘルムチャートを含む
次の ImageSetConfiguration
ファイルは、レジストリーストレージバックエンドを使用し、これにはヘルムチャートと追加の Red Hat Universal Base Image (UBI) が含まれています。
ImageSetConfiguration
ファイルの例
apiVersion: mirror.openshift.io/v1alpha2 kind: ImageSetConfiguration archiveSize: 4 storageConfig: registry: imageURL: example.com/mirror/oc-mirror-metadata skipTLS: false mirror: platform: architectures: - "s390x" channels: - name: stable-4.15 operators: - catalog: registry.redhat.io/redhat/redhat-operator-index:v4.15 helm: repositories: - name: redhat-helm-charts url: https://raw.githubusercontent.com/redhat-developer/redhat-helm-charts/master charts: - name: ibm-mongodb-enterprise-helm version: 0.2.0 additionalImages: - name: registry.redhat.io/ubi9/ubi:latest
apiVersion: mirror.openshift.io/v1alpha2
kind: ImageSetConfiguration
archiveSize: 4
storageConfig:
registry:
imageURL: example.com/mirror/oc-mirror-metadata
skipTLS: false
mirror:
platform:
architectures:
- "s390x"
channels:
- name: stable-4.15
operators:
- catalog: registry.redhat.io/redhat/redhat-operator-index:v4.15
helm:
repositories:
- name: redhat-helm-charts
url: https://raw.githubusercontent.com/redhat-developer/redhat-helm-charts/master
charts:
- name: ibm-mongodb-enterprise-helm
version: 0.2.0
additionalImages:
- name: registry.redhat.io/ubi9/ubi:latest
ユースケース:EUS リリースのアップグレードパスを含める
次の ImageSetConfiguration
ファイルには、eus-<version
> チャネルが含まれており、maxVersion
の値は minVersion
値よりも 2 つ以上のマイナーバージョンになります。
たとえば、この ImageSetConfiguration
ファイルでは、minVersion
は 4
。
.12.28
に設定され、eus-4.14
チャネルの maxVersion
は 4.14.16 に設定されます
ImageSetConfiguration
ファイルの例
kind: ImageSetConfiguration apiVersion: mirror.openshift.io/v2alpha1 mirror: platform: graph: true # Required for the OSUS Operator architectures: - amd64 channels: - name: stable-4.12 minVersion: '4.12.28' maxVersion: '4.12.28' shortestPath: true type: ocp - name: eus-4.14 minVersion: '4.12.28' maxVersion: '4.14.16' shortestPath: true type: ocp
kind: ImageSetConfiguration
apiVersion: mirror.openshift.io/v2alpha1
mirror:
platform:
graph: true # Required for the OSUS Operator
architectures:
- amd64
channels:
- name: stable-4.12
minVersion: '4.12.28'
maxVersion: '4.12.28'
shortestPath: true
type: ocp
- name: eus-4.14
minVersion: '4.12.28'
maxVersion: '4.14.16'
shortestPath: true
type: ocp
2.4.14. oc-mirror のコマンドリファレンス
以下の表は、oc mirror
サブコマンドとフラグを説明しています。
サブコマンド | 説明 |
---|---|
| 指定されたシェルのオートコンプリートスクリプトを生成します。 |
| イメージセットの内容を出力します。 |
| サブコマンドに関するヘルプを表示します。 |
| 初期イメージセット設定テンプレートを出力します。 |
| 利用可能なプラットフォームと Operator のコンテンツとそのバージョンを一覧表示します。 |
| oc-mirror バージョンを出力します。 |
フラグ | 説明 |
---|---|
| イメージセット設定ファイルへのパスを指定します。 |
| イメージのプルに関連しないエラーが発生した場合は、続行して、可能な限りミラーリングを試みます。 |
| ターゲットレジストリーの TLS 検証を無効にします。 |
| ターゲットレジストリーにはプレーン HTTP を使用します。 |
|
イメージをミラーリングせずにアクションを出力します。 |
| oc-mirror の実行によって生成されたイメージセットアーカイブへのパスを指定して、ターゲットレジストリーにロードします。 |
| ヘルプを表示します。 |
| イメージをダウンロードしてレイヤーをパックするときに、過去のミラーリングを無視します。増分ミラーリングを無効にし、より多くのデータをダウンロードする可能性があります。 |
|
|
|
ネストされたパスを制限する宛先レジストリーのネストされたパスの最大数を指定します。デフォルトは |
|
レジストリーごとに許可される同時要求の数を指定します。デフォルト値は |
|
( |
|
|
| アーティファクトディレクトリーの削除を省略します。 |
| Operator カタログのイメージタグをダイジェストピンに置き換えないでください。 |
|
イメージセットの公開時にメタデータをスキップします。これは、イメージセットが |
| イメージが見つからない場合は、エラーを報告して実行を中止する代わりにスキップします。イメージセット設定で明示的に指定されたカスタムイメージには適用されません。 |
| ターゲットミラーレジストリーからのイメージの自動プルーニングを無効にします。 |
| ダイジェストの検証を省略します。 |
| ソースレジストリーの TLS 検証を無効にします。 |
| ソースレジストリーにはプレーン HTTP を使用します。 |
|
ログレベルの詳細度の数値を指定します。有効な値は |
2.4.15. 関連情報
第3章 Alibaba へのインストール
3.1. Alibaba Cloud へのインストールの準備
OpenShift Container Platform 上の Alibaba Cloud は、テクノロジープレビュー機能としてのみ利用できます。テクノロジープレビュー機能は、Red Hat 製品のサービスレベルアグリーメント (SLA) の対象外であり、機能的に完全ではないことがあります。Red Hat は、実稼働環境でこれらを使用することを推奨していません。テクノロジープレビューの機能は、最新の製品機能をいち早く提供して、開発段階で機能のテストを行いフィードバックを提供していただくことを目的としています。
Red Hat のテクノロジープレビュー機能のサポート範囲に関する詳細は、テクノロジープレビュー機能のサポート範囲 を参照してください。
3.1.1. 前提条件
- OpenShift Container Platform のインストールおよび更新 プロセスの詳細を確認した。
- クラスターインストール方法の選択およびそのユーザー向けの準備 を確認した。
3.1.2. OpenShift Container Platform を Alibaba Cloud にインストールするための要件
OpenShift Container Platform を Alibaba Cloud にインストールする前に、ドメインを設定および登録し、インストール用の Resource Access Management (RAM) ユーザーを作成し、インストール用にサポートされている Alibaba Cloud データセンターのリージョンとゾーンを確認する必要があります。
3.1.3. Alibaba Cloud ドメインの登録と設定
OpenShift Container Platform をインストールするには、使用する Alibaba Cloud アカウントに専用のパブリックホストゾーンが必要です。このゾーンはドメインに対する権威を持っている必要があります。このサービスは、クラスターへの外部接続のためのクラスター DNS 解決および名前検索を提供します。
手順
ドメイン、またはサブドメイン、およびレジストラーを特定します。既存のドメインとレジストラーを移行するか、Alibaba Cloud または別のソースから新しいドメインを取得することができます。
注記Alibaba Cloud を介して新しいドメインを購入した場合、関連する DNS の変更が反映されるまでに時間がかかります。Alibaba Cloud を介したドメインの購入の詳細については、Alibaba Cloud ドメイン を参照してください。
- 既存のドメインとレジストラーを使用している場合は、その DNS を Alibaba Cloud に移行します。Alibaba Cloud のドキュメントの Domain name transfer を参照してください。
ドメインの DNS を設定します。これには以下が含まれます。
- ジェネリックドメイン名を登録します。
- ドメイン名の実名検証を完了します。
- インターネットコンテンツプロバイダー (ICP) のファイリングを申請します。
openshiftcorp.com
などのルートドメインや、clusters.openshiftcorp.com
などのサブドメインを使用します。
- サブドメインを使用している場合は、会社の手順に従って、その委任レコードを親ドメインに追加します。
3.1.4. サポートされている Alibaba リージョン
OpenShift Container Platform クラスターを Alibaba のリージョンとゾーンのドキュメント にリストされているリージョンにデプロイできます。
3.1.5. 次のステップ
3.2. 必要な Alibaba Cloud リソースの作成
OpenShift Container Platform をインストールする前に、Alibaba Cloud コンソールを使用して、OpenShift Container Platform を Alibaba Cloud にインストールするための十分な権限を持つ Resource Access Management (RAM) ユーザーを作成する必要があります。このユーザーには、新しい RAM ユーザーを作成するための権限も必要です。ccoctl
ツールを設定および使用して、OpenShift Container Platform コンポーネントに必要な権限を持つ新しいクレデンシャルを作成することもできます。
OpenShift Container Platform 上の Alibaba Cloud は、テクノロジープレビュー機能としてのみ利用できます。テクノロジープレビュー機能は、Red Hat 製品のサービスレベルアグリーメント (SLA) の対象外であり、機能的に完全ではないことがあります。Red Hat は、実稼働環境でこれらを使用することを推奨していません。テクノロジープレビューの機能は、最新の製品機能をいち早く提供して、開発段階で機能のテストを行いフィードバックを提供していただくことを目的としています。
Red Hat のテクノロジープレビュー機能のサポート範囲に関する詳細は、テクノロジープレビュー機能のサポート範囲 を参照してください。
3.2.1. 必要な RAM ユーザーの作成
インストールには、十分な権限を持つ Alibaba Cloud Resource Access Management (RAM) ユーザーが必要です。Alibaba Cloud Resource Access Management コンソールを使用して、新しいユーザーを作成したり、既存のユーザーを変更したりできます。後で、このユーザーの権限に基づいて、OpenShift Container Platform でクレデンシャルを作成します。
RAM ユーザーを設定するときは、次の要件を必ず考慮してください。
ユーザーは、Alibaba Cloud AccessKey ID と AccessKey シークレットのペアを持っている必要があります。
-
新規ユーザーの場合、ユーザーの作成時に Access Mode に
Open API Access
を選択できます。このモードでは、必要な AccessKey ペアが生成されます。 既存のユーザーの場合は、AccessKey ペアを追加するか、そのユーザーの AccessKey のペアを取得 できます。
注記作成されると、AccessKey シークレットは 1 回だけ表示されます。API 呼び出しには AccessKey ペアが必要であるため、AccessKey ペアをすぐに保存する必要があります。
-
新規ユーザーの場合、ユーザーの作成時に Access Mode に
AccessKey ID とシークレットをローカルコンピューターの
~/.alibabacloud/credentials
ファイル に追加します。コンソールにログインすると、Alibaba Cloud によってこのファイルが自動的に作成されます。Cloud Credential Operator (CCO) ユーティリティー (ccoutil) は、Credential Request
オブジェクトを処理するときにこれらの認証情報を使用します。以下に例を示します。
Copy to Clipboard Copied! Toggle word wrap Toggle overflow [default] # Default client type = access_key # Certification type: access_key access_key_id = LTAI5t8cefXKmt # Key access_key_secret = wYx56mszAN4Uunfh # Secret
[default] # Default client type = access_key # Certification type: access_key access_key_id = LTAI5t8cefXKmt # Key
1 access_key_secret = wYx56mszAN4Uunfh # Secret
- 1
- ここに AccessKeyID と AccessKeySecret を追加します。
RAM ユーザーは、アカウントが OpenShift Container Platform クラスターを作成するための十分なパーミッションを持っていることを確認するために
AdministratorAccess
ポリシーを持っている必要があります。このポリシーは、すべての Alibaba Cloud リソースを管理するための権限を付与します。AdministratorAccess
ポリシーを RAM ユーザーにアタッチすると、そのユーザーにすべての Alibaba Cloud サービスとリソースへのフルアクセスが許可されます。フルアクセス権を持つユーザーを作成したくない場合は、インストールのために RAM ユーザーに追加できる次のアクションを使用してカスタムポリシーを作成します。これらのアクションは、OpenShift Container Platform をインストールするのに十分です。ヒント次の JSON コードをコピーして Alibaba Cloud コンソールに貼り付け、カスタムポリシーを作成できます。カスタムポリシー作成の詳細については、Alibaba Cloud のドキュメントの Create a custom policy を参照してください。
例3.1 カスタムポリシー JSON ファイルの例
Copy to Clipboard Copied! Toggle word wrap Toggle overflow { "Version": "1", "Statement": [ { "Action": [ "tag:ListTagResources", "tag:UntagResources" ], "Resource": "*", "Effect": "Allow" }, { "Action": [ "vpc:DescribeVpcs", "vpc:DeleteVpc", "vpc:DescribeVSwitches", "vpc:DeleteVSwitch", "vpc:DescribeEipAddresses", "vpc:DescribeNatGateways", "vpc:ReleaseEipAddress", "vpc:DeleteNatGateway", "vpc:DescribeSnatTableEntries", "vpc:CreateSnatEntry", "vpc:AssociateEipAddress", "vpc:ListTagResources", "vpc:TagResources", "vpc:DescribeVSwitchAttributes", "vpc:CreateVSwitch", "vpc:CreateNatGateway", "vpc:DescribeRouteTableList", "vpc:CreateVpc", "vpc:AllocateEipAddress", "vpc:ListEnhanhcedNatGatewayAvailableZones" ], "Resource": "*", "Effect": "Allow" }, { "Action": [ "ecs:ModifyInstanceAttribute", "ecs:DescribeSecurityGroups", "ecs:DeleteSecurityGroup", "ecs:DescribeSecurityGroupReferences", "ecs:DescribeSecurityGroupAttribute", "ecs:RevokeSecurityGroup", "ecs:DescribeInstances", "ecs:DeleteInstances", "ecs:DescribeNetworkInterfaces", "ecs:DescribeInstanceRamRole", "ecs:DescribeUserData", "ecs:DescribeDisks", "ecs:ListTagResources", "ecs:AuthorizeSecurityGroup", "ecs:RunInstances", "ecs:TagResources", "ecs:ModifySecurityGroupPolicy", "ecs:CreateSecurityGroup", "ecs:DescribeAvailableResource", "ecs:DescribeRegions", "ecs:AttachInstanceRamRole" ], "Resource": "*", "Effect": "Allow" }, { "Action": [ "pvtz:DescribeRegions", "pvtz:DescribeZones", "pvtz:DeleteZone", "pvtz:DeleteZoneRecord", "pvtz:BindZoneVpc", "pvtz:DescribeZoneRecords", "pvtz:AddZoneRecord", "pvtz:SetZoneRecordStatus", "pvtz:DescribeZoneInfo", "pvtz:DescribeSyncEcsHostTask", "pvtz:AddZone" ], "Resource": "*", "Effect": "Allow" }, { "Action": [ "slb:DescribeLoadBalancers", "slb:SetLoadBalancerDeleteProtection", "slb:DeleteLoadBalancer", "slb:SetLoadBalancerModificationProtection", "slb:DescribeLoadBalancerAttribute", "slb:AddBackendServers", "slb:DescribeLoadBalancerTCPListenerAttribute", "slb:SetLoadBalancerTCPListenerAttribute", "slb:StartLoadBalancerListener", "slb:CreateLoadBalancerTCPListener", "slb:ListTagResources", "slb:TagResources", "slb:CreateLoadBalancer" ], "Resource": "*", "Effect": "Allow" }, { "Action": [ "ram:ListResourceGroups", "ram:DeleteResourceGroup", "ram:ListPolicyAttachments", "ram:DetachPolicy", "ram:GetResourceGroup", "ram:CreateResourceGroup", "ram:DeleteRole", "ram:GetPolicy", "ram:DeletePolicy", "ram:ListPoliciesForRole", "ram:CreateRole", "ram:AttachPolicyToRole", "ram:GetRole", "ram:CreatePolicy", "ram:CreateUser", "ram:DetachPolicyFromRole", "ram:CreatePolicyVersion", "ram:DetachPolicyFromUser", "ram:ListPoliciesForUser", "ram:AttachPolicyToUser", "ram:CreateUser", "ram:GetUser", "ram:DeleteUser", "ram:CreateAccessKey", "ram:ListAccessKeys", "ram:DeleteAccessKey", "ram:ListUsers", "ram:ListPolicyVersions" ], "Resource": "*", "Effect": "Allow" }, { "Action": [ "oss:DeleteBucket", "oss:DeleteBucketTagging", "oss:GetBucketTagging", "oss:GetBucketCors", "oss:GetBucketPolicy", "oss:GetBucketLifecycle", "oss:GetBucketReferer", "oss:GetBucketTransferAcceleration", "oss:GetBucketLog", "oss:GetBucketWebSite", "oss:GetBucketInfo", "oss:PutBucketTagging", "oss:PutBucket", "oss:OpenOssService", "oss:ListBuckets", "oss:GetService", "oss:PutBucketACL", "oss:GetBucketLogging", "oss:ListObjects", "oss:GetObject", "oss:PutObject", "oss:DeleteObject" ], "Resource": "*", "Effect": "Allow" }, { "Action": [ "alidns:DescribeDomainRecords", "alidns:DeleteDomainRecord", "alidns:DescribeDomains", "alidns:DescribeDomainRecordInfo", "alidns:AddDomainRecord", "alidns:SetDomainRecordStatus" ], "Resource": "*", "Effect": "Allow" }, { "Action": "bssapi:CreateInstance", "Resource": "*", "Effect": "Allow" }, { "Action": "ram:PassRole", "Resource": "*", "Effect": "Allow", "Condition": { "StringEquals": { "acs:Service": "ecs.aliyuncs.com" } } } ] }
{ "Version": "1", "Statement": [ { "Action": [ "tag:ListTagResources", "tag:UntagResources" ], "Resource": "*", "Effect": "Allow" }, { "Action": [ "vpc:DescribeVpcs", "vpc:DeleteVpc", "vpc:DescribeVSwitches", "vpc:DeleteVSwitch", "vpc:DescribeEipAddresses", "vpc:DescribeNatGateways", "vpc:ReleaseEipAddress", "vpc:DeleteNatGateway", "vpc:DescribeSnatTableEntries", "vpc:CreateSnatEntry", "vpc:AssociateEipAddress", "vpc:ListTagResources", "vpc:TagResources", "vpc:DescribeVSwitchAttributes", "vpc:CreateVSwitch", "vpc:CreateNatGateway", "vpc:DescribeRouteTableList", "vpc:CreateVpc", "vpc:AllocateEipAddress", "vpc:ListEnhanhcedNatGatewayAvailableZones" ], "Resource": "*", "Effect": "Allow" }, { "Action": [ "ecs:ModifyInstanceAttribute", "ecs:DescribeSecurityGroups", "ecs:DeleteSecurityGroup", "ecs:DescribeSecurityGroupReferences", "ecs:DescribeSecurityGroupAttribute", "ecs:RevokeSecurityGroup", "ecs:DescribeInstances", "ecs:DeleteInstances", "ecs:DescribeNetworkInterfaces", "ecs:DescribeInstanceRamRole", "ecs:DescribeUserData", "ecs:DescribeDisks", "ecs:ListTagResources", "ecs:AuthorizeSecurityGroup", "ecs:RunInstances", "ecs:TagResources", "ecs:ModifySecurityGroupPolicy", "ecs:CreateSecurityGroup", "ecs:DescribeAvailableResource", "ecs:DescribeRegions", "ecs:AttachInstanceRamRole" ], "Resource": "*", "Effect": "Allow" }, { "Action": [ "pvtz:DescribeRegions", "pvtz:DescribeZones", "pvtz:DeleteZone", "pvtz:DeleteZoneRecord", "pvtz:BindZoneVpc", "pvtz:DescribeZoneRecords", "pvtz:AddZoneRecord", "pvtz:SetZoneRecordStatus", "pvtz:DescribeZoneInfo", "pvtz:DescribeSyncEcsHostTask", "pvtz:AddZone" ], "Resource": "*", "Effect": "Allow" }, { "Action": [ "slb:DescribeLoadBalancers", "slb:SetLoadBalancerDeleteProtection", "slb:DeleteLoadBalancer", "slb:SetLoadBalancerModificationProtection", "slb:DescribeLoadBalancerAttribute", "slb:AddBackendServers", "slb:DescribeLoadBalancerTCPListenerAttribute", "slb:SetLoadBalancerTCPListenerAttribute", "slb:StartLoadBalancerListener", "slb:CreateLoadBalancerTCPListener", "slb:ListTagResources", "slb:TagResources", "slb:CreateLoadBalancer" ], "Resource": "*", "Effect": "Allow" }, { "Action": [ "ram:ListResourceGroups", "ram:DeleteResourceGroup", "ram:ListPolicyAttachments", "ram:DetachPolicy", "ram:GetResourceGroup", "ram:CreateResourceGroup", "ram:DeleteRole", "ram:GetPolicy", "ram:DeletePolicy", "ram:ListPoliciesForRole", "ram:CreateRole", "ram:AttachPolicyToRole", "ram:GetRole", "ram:CreatePolicy", "ram:CreateUser", "ram:DetachPolicyFromRole", "ram:CreatePolicyVersion", "ram:DetachPolicyFromUser", "ram:ListPoliciesForUser", "ram:AttachPolicyToUser", "ram:CreateUser", "ram:GetUser", "ram:DeleteUser", "ram:CreateAccessKey", "ram:ListAccessKeys", "ram:DeleteAccessKey", "ram:ListUsers", "ram:ListPolicyVersions" ], "Resource": "*", "Effect": "Allow" }, { "Action": [ "oss:DeleteBucket", "oss:DeleteBucketTagging", "oss:GetBucketTagging", "oss:GetBucketCors", "oss:GetBucketPolicy", "oss:GetBucketLifecycle", "oss:GetBucketReferer", "oss:GetBucketTransferAcceleration", "oss:GetBucketLog", "oss:GetBucketWebSite", "oss:GetBucketInfo", "oss:PutBucketTagging", "oss:PutBucket", "oss:OpenOssService", "oss:ListBuckets", "oss:GetService", "oss:PutBucketACL", "oss:GetBucketLogging", "oss:ListObjects", "oss:GetObject", "oss:PutObject", "oss:DeleteObject" ], "Resource": "*", "Effect": "Allow" }, { "Action": [ "alidns:DescribeDomainRecords", "alidns:DeleteDomainRecord", "alidns:DescribeDomains", "alidns:DescribeDomainRecordInfo", "alidns:AddDomainRecord", "alidns:SetDomainRecordStatus" ], "Resource": "*", "Effect": "Allow" }, { "Action": "bssapi:CreateInstance", "Resource": "*", "Effect": "Allow" }, { "Action": "ram:PassRole", "Resource": "*", "Effect": "Allow", "Condition": { "StringEquals": { "acs:Service": "ecs.aliyuncs.com" } } } ] }
RAM ユーザーの作成と権限の付与の詳細については、Alibaba Cloud のドキュメントの Create a RAM user および Grant permissions to a RAM user を参照してください。
3.2.2. Cloud Credential Operator ユーティリティーの設定
クラスター内コンポーネントごとに長寿命の RAM AccessKeys (AKs) を提供する RAM ユーザーとポリシーを割り当てるには、Cloud Credential Operator (CCO) ユーティリティー (ccoctl
) バイナリーを抽出して準備します。
ccoctl
ユーティリティーは、Linux 環境で実行する必要がある Linux バイナリーです。
前提条件
- クラスター管理者のアクセスを持つ OpenShift Container Platform アカウントを使用できる。
-
OpenShift CLI (
oc
) がインストールされている。
手順
次のコマンドを実行して、OpenShift Container Platform リリースイメージの変数を設定します。
Copy to Clipboard Copied! Toggle word wrap Toggle overflow RELEASE_IMAGE=$(./openshift-install version | awk '/release image/ {print $3}')
$ RELEASE_IMAGE=$(./openshift-install version | awk '/release image/ {print $3}')
以下のコマンドを実行して、OpenShift Container Platform リリースイメージから CCO コンテナーイメージを取得します。
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 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)
注記$RELEASE_IMAGE
のアーキテクチャーが、ccoctl
ツールを使用する環境のアーキテクチャーと一致していることを確認してください。以下のコマンドを実行して、OpenShift Container Platform リリースイメージ内の CCO コンテナーイメージから
ccoctl
バイナリーを抽出します。Copy to Clipboard Copied! Toggle word wrap Toggle overflow oc image extract $CCO_IMAGE --file="/usr/bin/ccoctl" -a ~/.pull-secret
$ oc image extract $CCO_IMAGE --file="/usr/bin/ccoctl" -a ~/.pull-secret
次のコマンドを実行して、権限を変更して
ccoctl
を実行可能にします。Copy to Clipboard Copied! Toggle word wrap Toggle overflow chmod 775 ccoctl
$ chmod 775 ccoctl
検証
ccoctl
が使用できることを確認するには、help ファイルを表示します。コマンドを実行するときは、相対ファイル名を使用します。以下に例を示します。Copy to Clipboard Copied! Toggle word wrap Toggle overflow ./ccoctl.rhel9
$ ./ccoctl.rhel9
出力例
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 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.
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.
3.2.3. 次のステップ
次のいずれかの方法を使用して、OpenShift Container Platform インストールプログラムによってプロビジョニングされた Alibaba Cloud インフラストラクチャーにクラスターをインストールします。
- Alibaba Cloud へのクラスターの迅速なインストール: デフォルトの設定オプションを使用して、クラスターを迅速にインストールできます。
- カスタマイズされたクラスターを Alibaba Cloud にインストール: インストールプログラムを使用すると、インストールの段階で一部のカスタマイズを適用することができます。その他の多くのカスタマイズオプションは、インストール後 に利用できます。
3.3. クラスターを Alibaba Cloud にすばやくインストールする
OpenShift Container Platform バージョン 4.15 では、デフォルトの設定オプションを使用するクラスターを Alibaba Cloud にインストールできます。
OpenShift Container Platform 上の Alibaba Cloud は、テクノロジープレビュー機能としてのみ利用できます。テクノロジープレビュー機能は、Red Hat 製品のサービスレベルアグリーメント (SLA) の対象外であり、機能的に完全ではないことがあります。Red Hat は、実稼働環境でこれらを使用することを推奨していません。テクノロジープレビューの機能は、最新の製品機能をいち早く提供して、開発段階で機能のテストを行いフィードバックを提供していただくことを目的としています。
Red Hat のテクノロジープレビュー機能のサポート範囲に関する詳細は、テクノロジープレビュー機能のサポート範囲 を参照してください。
3.3.1. 前提条件
- OpenShift Container Platform のインストールおよび更新 プロセスの詳細を確認した。
- クラスターインストール方法の選択およびそのユーザー向けの準備 を確認した。
- ドメインを登録 している。
- ファイアウォールを使用する場合は、クラスターがアクセスを必要とするサイトを許可するようにファイアウォールを設定する必要がある。
- 必要な Alibaba Cloud リソースを作成している。
- ご使用の環境でクラウド Resource Access Management (RAM) API にアクセスできない場合、または管理者レベルのクレデンシャルシークレットを kube-system namespace に保存したくない場合は、Resource Access Management (RAM) 認証情報を手動で作成および維持 することができます。
3.3.2. OpenShift Container Platform のインターネットアクセス
OpenShift Container Platform 4.15 では、クラスターをインストールするためにインターネットアクセスが必要になります。
インターネットへのアクセスは以下を実行するために必要です。
- OpenShift Cluster Manager にアクセスし、インストールプログラムをダウンロードし、サブスクリプション管理を実行します。クラスターにインターネットアクセスがあり、Telemetry を無効にしない場合、そのサービスは有効なサブスクリプションでクラスターを自動的に使用します。
- クラスターのインストールに必要なパッケージを取得するために Quay.io にアクセスします。
- クラスターの更新を実行するために必要なパッケージを取得します。
クラスターでインターネットに直接アクセスできない場合、プロビジョニングする一部のタイプのインフラストラクチャーでネットワークが制限されたインストールを実行できます。このプロセスで、必要なコンテンツをダウンロードし、これを使用してミラーレジストリーにインストールパッケージを設定します。インストールタイプによっては、クラスターのインストール環境でインターネットアクセスが不要となる場合があります。クラスターを更新する前に、ミラーレジストリーのコンテンツを更新します。
3.3.3. クラスターノードの 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 オペレーティングシステムを使用するコンピューターで以下のコマンドを実行します。
Copy to Clipboard Copied! Toggle word wrap Toggle overflow ssh-keygen -t ed25519 -N '' -f <path>/<file_name>
$ 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 キーを表示します。
Copy to Clipboard Copied! Toggle word wrap Toggle overflow cat <path>/<file_name>.pub
$ cat <path>/<file_name>.pub
たとえば、次のコマンドを実行して
~/.ssh/id_ed25519.pub
公開鍵を表示します。Copy to Clipboard Copied! Toggle word wrap Toggle overflow cat ~/.ssh/id_ed25519.pub
$ cat ~/.ssh/id_ed25519.pub
ローカルユーザーの SSH エージェントに SSH 秘密鍵 ID が追加されていない場合は、それを追加します。キーの SSH エージェント管理は、クラスターノードへのパスワードなしの SSH 認証、または
./openshift-install gather
コマンドを使用する場合は必要になります。注記一部のディストリビューションでは、
~/.ssh/id_rsa
および~/.ssh/id_dsa
などのデフォルトの SSH 秘密鍵のアイデンティティーは自動的に管理されます。ssh-agent
プロセスがローカルユーザーに対して実行されていない場合は、バックグラウンドタスクとして開始します。Copy to Clipboard Copied! Toggle word wrap Toggle overflow eval "$(ssh-agent -s)"
$ eval "$(ssh-agent -s)"
出力例
Copy to Clipboard Copied! Toggle word wrap Toggle overflow Agent pid 31874
Agent pid 31874
注記クラスターが FIPS モードにある場合は、FIPS 準拠のアルゴリズムのみを使用して SSH キーを生成します。鍵は RSA または ECDSA のいずれかである必要があります。
SSH プライベートキーを
ssh-agent
に追加します。Copy to Clipboard Copied! Toggle word wrap Toggle overflow ssh-add <path>/<file_name>
$ ssh-add <path>/<file_name>
1 - 1
~/.ssh/id_ed25519
などの、SSH プライベートキーのパスおよびファイル名を指定します。
出力例
Copy to Clipboard Copied! Toggle word wrap Toggle overflow Identity added: /home/<you>/<path>/<file_name> (<computer_name>)
Identity added: /home/<you>/<path>/<file_name> (<computer_name>)
次のステップ
- OpenShift Container Platform をインストールする際に、SSH パブリックキーをインストールプログラムに指定します。
3.3.4. インストールプログラムの取得
OpenShift Container Platform をインストールする前に、インストールに使用しているホストにインストールファイルをダウンロードします。
前提条件
- 500 MB のローカルディスク領域がある Linux または macOS を実行するコンピューターが必要です。
手順
- OpenShift Cluster Manager サイトの インフラストラクチャープロバイダー ページにアクセスします。Red Hat アカウントがある場合は、認証情報を使用してログインします。アカウントがない場合はこれを作成します。
- インフラストラクチャープロバイダーを選択します。
インストールタイプのページに移動し、ホストオペレーティングシステムとアーキテクチャーに対応するインストールプログラムをダウンロードして、インストール設定ファイルを保存するディレクトリーにファイルを配置します。
重要インストールプログラムは、クラスターのインストールに使用するコンピューターにいくつかのファイルを作成します。クラスターのインストール完了後は、インストールプログラムおよびインストールプログラムが作成するファイルを保持する必要があります。ファイルはいずれもクラスターを削除するために必要になります。
重要インストールプログラムで作成されたファイルを削除しても、クラスターがインストール時に失敗した場合でもクラスターは削除されません。クラスターを削除するには、特定のクラウドプロバイダー用の OpenShift Container Platform のアンインストール手順を実行します。
インストールプログラムを展開します。たとえば、Linux オペレーティングシステムを使用するコンピューターで以下のコマンドを実行します。
Copy to Clipboard Copied! Toggle word wrap Toggle overflow tar -xvf openshift-install-linux.tar.gz
$ tar -xvf openshift-install-linux.tar.gz
- Red Hat OpenShift Cluster Manager からインストールプルシークレット をダウンロードします。このプルシークレットを使用し、OpenShift Container Platform コンポーネントのコンテナーイメージを提供する Quay.io など、組み込まれた各種の認証局によって提供されるサービスで認証できます。
3.3.5. インストール設定ファイルの作成
Alibaba Cloud にインストールする OpenShift Container Platform クラスターをカスタマイズできます。
前提条件
- OpenShift Container Platform インストールプログラムおよびクラスターのプルシークレットがある。
手順
install-config.yaml
ファイルを作成します。インストールプログラムが含まれるディレクトリーに切り替え、以下のコマンドを実行します。
Copy to Clipboard Copied! Toggle word wrap Toggle overflow ./openshift-install create install-config --dir <installation_directory>
$ ./openshift-install create install-config --dir <installation_directory>
1 - 1
<installation_directory>
の場合、インストールプログラムが作成するファイルを保存するためにディレクトリー名を指定します。
ディレクトリーを指定する場合:
-
ディレクトリーに
execute
権限があることを確認します。この権限は、インストールディレクトリーで Terraform バイナリーを実行するために必要です。 - 空のディレクトリーを使用します。ブートストラップ X.509 証明書などの一部のインストールアセットは有効期限が短いため、インストールディレクトリーを再利用しないでください。別のクラスターインストールの個別のファイルを再利用する必要がある場合は、それらをディレクトリーにコピーすることができます。ただし、インストールアセットのファイル名はリリース間で変更される可能性があります。インストールファイルを以前のバージョンの OpenShift Container Platform からコピーする場合は注意してコピーを行ってください。
プロンプト時に、クラウドの設定の詳細情報を指定します。
オプション: クラスターマシンにアクセスするために使用する SSH キーを選択します。
注記インストールのデバッグまたは障害復旧を実行する必要のある実稼働用の OpenShift Container Platform クラスターでは、
ssh-agent
プロセスが使用する SSH キーを指定します。- ターゲットとするプラットフォームとして alibabacloud を選択します。
- クラスターをデプロイするリージョンを選択します。
- クラスターをデプロイするベースドメインを選択します。ベースドメインは、クラスターに作成したパブリック DNS ゾーンに対応します。
- クラスターの記述名を指定します。
クラスターを Alibaba Cloud にインストールするには、Cloud Credential Operator (CCO) が手動モードで動作する必要があります。
install-config.yaml
ファイルを変更して、credentialsMode
パラメーターをManual
に設定します。credentialsMode
がManual
に設定された install-config.yaml 設定ファイルの例Copy to Clipboard Copied! Toggle word wrap Toggle overflow apiVersion: v1 baseDomain: cluster1.example.com credentialsMode: Manual compute: - architecture: amd64 hyperthreading: Enabled ...
apiVersion: v1 baseDomain: cluster1.example.com credentialsMode: Manual
1 compute: - architecture: amd64 hyperthreading: Enabled ...
- 1
- この行を追加して、
credentialsMode
をManual
に設定します。
install-config.yaml
ファイルをバックアップし、複数のクラスターをインストールするのに使用できるようにします。重要install-config.yaml
ファイルはインストールプロセス時に使用されます。このファイルを再利用する必要がある場合は、この段階でこれをバックアップしてください。
3.3.6. 必要なインストールマニフェストの生成
クラスターがマシンを設定するために必要な Kubernetes マニフェストと Ignition 設定ファイルを生成する必要があります。
手順
インストールプログラムが含まれているディレクトリーから次のコマンドを実行して、マニフェストを生成します。
Copy to Clipboard Copied! Toggle word wrap Toggle overflow openshift-install create manifests --dir <installation_directory>
$ openshift-install create manifests --dir <installation_directory>
ここで、
<installation_directory>
- インストールプログラムがファイルを作成するディレクトリーを指定します。
3.3.7. ccoctl ツールを使用した OpenShift Container Platform コンポーネントのクレデンシャルの作成
OpenShift Container Platform Cloud Credential Operator (CCO) ユーティリティーを使用して、Alibaba Cloud RAM ユーザーとクラスター内コンポーネントごとのポリシーの作成を自動化できます。
デフォルトで、ccoctl
はコマンドが実行されるディレクトリーにオブジェクトを作成します。オブジェクトを別のディレクトリーに作成するには、--output-dir
フラグを使用します。この手順では、<path_to_ccoctl_output_dir>
を使用してこの場所を参照します。
前提条件
以下が必要になります。
-
ccoctl
バイナリーを抽出して準備している。 - OpenShift Container Platform クラスターを作成するための十分な権限を持つ RAM ユーザーを作成している。
-
その RAM ユーザーの AccessKeyID (
access_key_id
) と AccessKeySecret (access_key_secret
) をローカルコンピューターの~/.alibabacloud/credentials
ファイル に追加しました。
手順
次のコマンドを実行して、インストールファイルのリリースイメージを
$RELEASE_IMAGE
変数に設定します。Copy to Clipboard Copied! Toggle word wrap Toggle overflow RELEASE_IMAGE=$(./openshift-install version | awk '/release image/ {print $3}')
$ RELEASE_IMAGE=$(./openshift-install version | awk '/release image/ {print $3}')
以下のコマンドを実行して、OpenShift Container Platform リリースイメージから
CredentialsRequest
オブジェクトのリストを抽出します。Copy to Clipboard Copied! Toggle word wrap Toggle overflow oc adm release extract \ --from=$RELEASE_IMAGE \ --credentials-requests \ --included \ --install-config=<path_to_directory_with_installation_configuration>/install-config.yaml \ --to=<path_to_directory_for_credentials_requests>
$ 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
オブジェクトをすべて処理します。ツールを使用するには、次のコマンドを実行します。
Copy to Clipboard Copied! Toggle word wrap Toggle overflow ccoctl alibabacloud create-ram-users \ --name <name> \ --region=<alibaba_region> \ --credentials-requests-dir=<path_to_credentials_requests_directory> \ --output-dir=<path_to_ccoctl_output_dir>
$ ccoctl alibabacloud create-ram-users \ --name <name> \
1 --region=<alibaba_region> \
2 --credentials-requests-dir=<path_to_credentials_requests_directory> \
3 --output-dir=<path_to_ccoctl_output_dir>
4 注記クラスターで
TechPreviewNoUpgrade
機能セットによって有効化されたテクノロジープレビュー機能を使用している場合は、--enable-tech-preview
パラメーターを含める必要があります。出力例
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 2022/02/11 16:18:26 Created RAM User: user1-alicloud-openshift-machine-api-alibabacloud-credentials 2022/02/11 16:18:27 Ready for creating new ram policy user1-alicloud-openshift-machine-api-alibabacloud-credentials-policy-policy 2022/02/11 16:18:27 RAM policy user1-alicloud-openshift-machine-api-alibabacloud-credentials-policy-policy has created 2022/02/11 16:18:28 Policy user1-alicloud-openshift-machine-api-alibabacloud-credentials-policy-policy has attached on user user1-alicloud-openshift-machine-api-alibabacloud-credentials 2022/02/11 16:18:29 Created access keys for RAM User: user1-alicloud-openshift-machine-api-alibabacloud-credentials 2022/02/11 16:18:29 Saved credentials configuration to: user1-alicloud/manifests/openshift-machine-api-alibabacloud-credentials-credentials.yaml ...
2022/02/11 16:18:26 Created RAM User: user1-alicloud-openshift-machine-api-alibabacloud-credentials 2022/02/11 16:18:27 Ready for creating new ram policy user1-alicloud-openshift-machine-api-alibabacloud-credentials-policy-policy 2022/02/11 16:18:27 RAM policy user1-alicloud-openshift-machine-api-alibabacloud-credentials-policy-policy has created 2022/02/11 16:18:28 Policy user1-alicloud-openshift-machine-api-alibabacloud-credentials-policy-policy has attached on user user1-alicloud-openshift-machine-api-alibabacloud-credentials 2022/02/11 16:18:29 Created access keys for RAM User: user1-alicloud-openshift-machine-api-alibabacloud-credentials 2022/02/11 16:18:29 Saved credentials configuration to: user1-alicloud/manifests/openshift-machine-api-alibabacloud-credentials-credentials.yaml ...
注記RAM ユーザーは、同時に最大 2 つの AccessKey を持つことができます。
ccoctl alibabacloud create-ram-users
を 3 回以上実行すると、以前に生成されたマニフェストシークレットが古くなり、新しく生成されたシークレットを再適用する必要があります。OpenShift Container Platform シークレットが作成されていることを確認します。
Copy to Clipboard Copied! Toggle word wrap Toggle overflow ls <path_to_ccoctl_output_dir>/manifests
$ ls <path_to_ccoctl_output_dir>/manifests
出力例
Copy to Clipboard Copied! Toggle word wrap Toggle overflow openshift-cluster-csi-drivers-alibaba-disk-credentials-credentials.yaml openshift-image-registry-installer-cloud-credentials-credentials.yaml openshift-ingress-operator-cloud-credentials-credentials.yaml openshift-machine-api-alibabacloud-credentials-credentials.yaml
openshift-cluster-csi-drivers-alibaba-disk-credentials-credentials.yaml openshift-image-registry-installer-cloud-credentials-credentials.yaml openshift-ingress-operator-cloud-credentials-credentials.yaml openshift-machine-api-alibabacloud-credentials-credentials.yaml
RAM ユーザーとポリシーが Alibaba Cloud にクエリーを実行して作成されていることを確認できます。詳細については、RAM ユーザーとポリシーのリスト表示に関する Alibaba Cloud のドキュメントを参照してください。
生成されたクレデンシャルファイルをターゲットマニフェストディレクトリーにコピーします。
Copy to Clipboard Copied! Toggle word wrap Toggle overflow cp ./<path_to_ccoctl_output_dir>/manifests/*credentials.yaml ./<path_to_installation>dir>/manifests/
$ cp ./<path_to_ccoctl_output_dir>/manifests/*credentials.yaml ./<path_to_installation>dir>/manifests/
ここで、
<path_to_ccoctl_output_dir>
-
ccoctl alibabacloud create-ram-users
コマンドによって作成されるディレクトリーを指定します。 <path_to_installation_dir>
- インストールプログラムがファイルを作成するディレクトリーを指定します。
3.3.8. クラスターのデプロイ
互換性のあるクラウドプラットフォームに OpenShift Container Platform をインストールできます。
インストールプログラムの create cluster
コマンドは、初期インストール時に 1 回だけ実行できます。
前提条件
- クラスターをホストするクラウドプラットフォームでアカウントを設定しました。
- OpenShift Container Platform インストールプログラムおよびクラスターのプルシークレットがある。
- ホスト上のクラウドプロバイダーアカウントに、クラスターをデプロイするための適切な権限があることが確認されました。アカウントの権限が正しくないと、インストールプロセスが失敗し、不足している権限を示すエラーメッセージが表示されます。
手順
インストールプログラムが含まれるディレクトリーに切り替え、クラスターのデプロイメントを初期化します。
Copy to Clipboard Copied! Toggle word wrap Toggle overflow ./openshift-install create cluster --dir <installation_directory> \ --log-level=info
$ ./openshift-install create cluster --dir <installation_directory> \
1 --log-level=info
2
検証
クラスターのデプロイが正常に完了すると、次のようになります。
-
ターミナルには、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
...
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.3.9. バイナリーのダウンロードによる OpenShift CLI のインストール
コマンドラインインターフェイスを使用して OpenShift Container Platform と対話するために CLI (oc
) をインストールすることができます。oc
は Linux、Windows、または macOS にインストールできます。
以前のバージョンの oc
をインストールしている場合、これを使用して OpenShift Container Platform 4.15 のすべてのコマンドを実行することはできません。新規バージョンの oc
をダウンロードし、インストールします。
Linux への OpenShift CLI のインストール
以下の手順を使用して、OpenShift CLI (oc
) バイナリーを Linux にインストールできます。
手順
- Red Hat カスタマーポータルの OpenShift Container Platform ダウンロードページ に移動します。
- Product Variant ドロップダウンリストからアーキテクチャーを選択します。
- バージョン ドロップダウンリストから適切なバージョンを選択します。
- OpenShift v4.15 Linux Client エントリーの横にある Download Now をクリックして、ファイルを保存します。
アーカイブを展開します。
Copy to Clipboard Copied! Toggle word wrap Toggle overflow tar xvf <file>
$ tar xvf <file>
oc
バイナリーを、PATH
にあるディレクトリーに配置します。PATH
を確認するには、以下のコマンドを実行します。Copy to Clipboard Copied! Toggle word wrap Toggle overflow echo $PATH
$ echo $PATH
検証
OpenShift CLI のインストール後に、
oc
コマンドを使用して利用できます。Copy to Clipboard Copied! Toggle word wrap Toggle overflow oc <command>
$ oc <command>
Windows への OpenShift CLI のインストール
以下の手順を使用して、OpenShift CLI (oc
) バイナリーを Windows にインストールできます。
手順
- Red Hat カスタマーポータルの OpenShift Container Platform ダウンロードページ に移動します。
- バージョン ドロップダウンリストから適切なバージョンを選択します。
- OpenShift v4.15 Windows Client エントリーの横にある Download Now をクリックして、ファイルを保存します。
- ZIP プログラムでアーカイブを展開します。
oc
バイナリーを、PATH
にあるディレクトリーに移動します。PATH
を確認するには、コマンドプロンプトを開いて以下のコマンドを実行します。Copy to Clipboard Copied! Toggle word wrap Toggle overflow path
C:\> path
検証
OpenShift CLI のインストール後に、
oc
コマンドを使用して利用できます。Copy to Clipboard Copied! Toggle word wrap Toggle overflow oc <command>
C:\> oc <command>
macOS への OpenShift CLI のインストール
以下の手順を使用して、OpenShift CLI (oc
) バイナリーを macOS にインストールできます。
手順
- Red Hat カスタマーポータルの OpenShift Container Platform ダウンロードページ に移動します。
- バージョン ドロップダウンリストから適切なバージョンを選択します。
OpenShift v4.15 macOS Client エントリーの横にある Download Now をクリックして、ファイルを保存します。
注記macOS arm64 の場合は、OpenShift v4.15 macOS arm64 Client エントリーを選択します。
- アーカイブを展開し、解凍します。
oc
バイナリーをパスにあるディレクトリーに移動します。PATH
を確認するには、ターミナルを開き、以下のコマンドを実行します。Copy to Clipboard Copied! Toggle word wrap Toggle overflow echo $PATH
$ echo $PATH
検証
oc
コマンドを使用してインストールを確認します。Copy to Clipboard Copied! Toggle word wrap Toggle overflow oc <command>
$ oc <command>
3.3.10. CLI の使用によるクラスターへのログイン
クラスター kubeconfig
ファイルをエクスポートし、デフォルトシステムユーザーとしてクラスターにログインできます。kubeconfig
ファイルには、クライアントを正しいクラスターおよび API サーバーに接続するために CLI で使用されるクラスターに関する情報が含まれます。このファイルはクラスターに固有のファイルであり、OpenShift Container Platform のインストール時に作成されます。
前提条件
- OpenShift Container Platform クラスターをデプロイしていること。
-
oc
CLI をインストールしていること。
手順
kubeadmin
認証情報をエクスポートします。Copy to Clipboard Copied! Toggle word wrap Toggle overflow export KUBECONFIG=<installation_directory>/auth/kubeconfig
$ export KUBECONFIG=<installation_directory>/auth/kubeconfig
1 - 1
<installation_directory>
には、インストールファイルを保存したディレクトリーへのパスを指定します。
エクスポートされた設定を使用して、
oc
コマンドを正常に実行できることを確認します。Copy to Clipboard Copied! Toggle word wrap Toggle overflow oc whoami
$ oc whoami
出力例
Copy to Clipboard Copied! Toggle word wrap Toggle overflow system:admin
system:admin
3.3.11. Web コンソールを使用したクラスターへのログイン
kubeadmin
ユーザーは、OpenShift Container Platform のインストール後はデフォルトで存在します。OpenShift Container Platform Web コンソールを使用し、kubeadmin
ユーザーとしてクラスターにログインできます。
前提条件
- インストールホストにアクセスできる。
- クラスターのインストールを完了しており、すべてのクラスター Operator が利用可能である。
手順
インストールホストで
kubeadmin-password
ファイルからkubeadmin
ユーザーのパスワードを取得します。Copy to Clipboard Copied! Toggle word wrap Toggle overflow cat <installation_directory>/auth/kubeadmin-password
$ cat <installation_directory>/auth/kubeadmin-password
注記または、インストールホストで
<installation_directory>/.openshift_install.log
ログファイルからkubeadmin
パスワードを取得できます。OpenShift Container Platform Web コンソールルートをリスト表示します。
Copy to Clipboard Copied! Toggle word wrap Toggle overflow oc get routes -n openshift-console | grep 'console-openshift'
$ oc get routes -n openshift-console | grep 'console-openshift'
注記または、インストールホストで
<installation_directory>/.openshift_install.log
ログファイルからで OpenShift Container Platform ルートを取得できます。出力例
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 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 None
-
Web ブラウザーで前述のコマンドの出力で詳細に説明されたルートに移動し、
kubeadmin
ユーザーとしてログインします。
3.3.12. OpenShift Container Platform の Telemetry アクセス
OpenShift Container Platform 4.15 では、クラスターの健全性および正常に実行された更新についてのメトリクスを提供するためにデフォルトで実行される Telemetry サービスにも、インターネットアクセスが必要です。クラスターがインターネットに接続されている場合、Telemetry は自動的に実行され、クラスターは OpenShift Cluster Manager に登録されます。
OpenShift Cluster Manager インベントリーが正常である (Telemetry によって自動的に維持、または OpenShift Cluster Manager を使用して手動で維持) ことを確認した後に、subscription watch を使用 して、アカウントまたはマルチクラスターレベルで OpenShift Container Platform サブスクリプションを追跡します。
関連情報
- OpenShift Container Platform Web コンソールへのアクセスと理解に関する詳細は、Web コンソールへのアクセス を参照してください。
- Telemetry サービスの詳細は、リモートヘルスモニタリング を参照してください。
3.3.13. 次のステップ
- インストールを検証 します。
- クラスターをカスタマイズ します。
- 必要に応じて、リモートヘルスレポートをオプトアウト できます。
3.4. カスタマイズによる Alibaba Cloud へのクラスターのインストール
OpenShift Container Platform バージョン 4.15 では、インストールプログラムが Alibaba Cloud でプロビジョニングするインフラストラクチャーにカスタマイズされたクラスターをインストールできます。インストールをカスタマイズするには、クラスターをインストールする前に、install-config.yaml
ファイルでパラメーターを変更します。
OpenShift Container Platform インストール設定のスコープは意図的に狭められています。単純さを確保し、確実にインストールを実行できるように設計されているためです。インストールが完了した後にさらに多くの OpenShift Container Platform 設定タスクを実行することができます。
OpenShift Container Platform 上の Alibaba Cloud は、テクノロジープレビュー機能としてのみ利用できます。テクノロジープレビュー機能は、Red Hat 製品のサービスレベルアグリーメント (SLA) の対象外であり、機能的に完全ではないことがあります。Red Hat は、実稼働環境でこれらを使用することを推奨していません。テクノロジープレビューの機能は、最新の製品機能をいち早く提供して、開発段階で機能のテストを行いフィードバックを提供していただくことを目的としています。
Red Hat のテクノロジープレビュー機能のサポート範囲に関する詳細は、テクノロジープレビュー機能のサポート範囲 を参照してください。
3.4.1. 前提条件
- OpenShift Container Platform のインストールおよび更新 プロセスの詳細を確認した。
- クラスターインストール方法の選択およびそのユーザー向けの準備 を確認した。
- ドメインを登録 している。
- ファイアウォールを使用する場合は、クラスターがアクセスを必要とするサイトを許可するようにファイアウォールを設定する必要がある。
-
ご使用の環境でクラウド Resource Access Management (RAM) API にアクセスできない場合、または管理者レベルのクレデンシャルシークレットを
kube-system
namespace に保存したくない場合は、Resource Access Management (RAM) 認証情報を手動で作成および維持 することができます。
3.4.2. OpenShift Container Platform のインターネットアクセス
OpenShift Container Platform 4.15 では、クラスターをインストールするためにインターネットアクセスが必要になります。
インターネットへのアクセスは以下を実行するために必要です。
- OpenShift Cluster Manager にアクセスし、インストールプログラムをダウンロードし、サブスクリプション管理を実行します。クラスターにインターネットアクセスがあり、Telemetry を無効にしない場合、そのサービスは有効なサブスクリプションでクラスターを自動的に使用します。
- クラスターのインストールに必要なパッケージを取得するために Quay.io にアクセスします。
- クラスターの更新を実行するために必要なパッケージを取得します。
クラスターでインターネットに直接アクセスできない場合、プロビジョニングする一部のタイプのインフラストラクチャーでネットワークが制限されたインストールを実行できます。このプロセスで、必要なコンテンツをダウンロードし、これを使用してミラーレジストリーにインストールパッケージを設定します。インストールタイプによっては、クラスターのインストール環境でインターネットアクセスが不要となる場合があります。クラスターを更新する前に、ミラーレジストリーのコンテンツを更新します。
3.4.3. クラスターノードの 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 オペレーティングシステムを使用するコンピューターで以下のコマンドを実行します。
Copy to Clipboard Copied! Toggle word wrap Toggle overflow ssh-keygen -t ed25519 -N '' -f <path>/<file_name>
$ 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 キーを表示します。
Copy to Clipboard Copied! Toggle word wrap Toggle overflow cat <path>/<file_name>.pub
$ cat <path>/<file_name>.pub
たとえば、次のコマンドを実行して
~/.ssh/id_ed25519.pub
公開鍵を表示します。Copy to Clipboard Copied! Toggle word wrap Toggle overflow cat ~/.ssh/id_ed25519.pub
$ cat ~/.ssh/id_ed25519.pub
ローカルユーザーの SSH エージェントに SSH 秘密鍵 ID が追加されていない場合は、それを追加します。キーの SSH エージェント管理は、クラスターノードへのパスワードなしの SSH 認証、または
./openshift-install gather
コマンドを使用する場合は必要になります。注記一部のディストリビューションでは、
~/.ssh/id_rsa
および~/.ssh/id_dsa
などのデフォルトの SSH 秘密鍵のアイデンティティーは自動的に管理されます。ssh-agent
プロセスがローカルユーザーに対して実行されていない場合は、バックグラウンドタスクとして開始します。Copy to Clipboard Copied! Toggle word wrap Toggle overflow eval "$(ssh-agent -s)"
$ eval "$(ssh-agent -s)"
出力例
Copy to Clipboard Copied! Toggle word wrap Toggle overflow Agent pid 31874
Agent pid 31874
注記クラスターが FIPS モードにある場合は、FIPS 準拠のアルゴリズムのみを使用して SSH キーを生成します。鍵は RSA または ECDSA のいずれかである必要があります。
SSH プライベートキーを
ssh-agent
に追加します。Copy to Clipboard Copied! Toggle word wrap Toggle overflow ssh-add <path>/<file_name>
$ ssh-add <path>/<file_name>
1 - 1
~/.ssh/id_ed25519
などの、SSH プライベートキーのパスおよびファイル名を指定します。
出力例
Copy to Clipboard Copied! Toggle word wrap Toggle overflow Identity added: /home/<you>/<path>/<file_name> (<computer_name>)
Identity added: /home/<you>/<path>/<file_name> (<computer_name>)
次のステップ
- OpenShift Container Platform をインストールする際に、SSH パブリックキーをインストールプログラムに指定します。
3.4.4. インストールプログラムの取得
OpenShift Container Platform をインストールする前に、インストールに使用しているホストにインストールファイルをダウンロードします。
前提条件
- 500 MB のローカルディスク領域がある Linux または macOS を実行するコンピューターが必要です。
手順
- OpenShift Cluster Manager サイトの インフラストラクチャープロバイダー ページにアクセスします。Red Hat アカウントがある場合は、認証情報を使用してログインします。アカウントがない場合はこれを作成します。
- インフラストラクチャープロバイダーを選択します。
インストールタイプのページに移動し、ホストオペレーティングシステムとアーキテクチャーに対応するインストールプログラムをダウンロードして、インストール設定ファイルを保存するディレクトリーにファイルを配置します。
重要インストールプログラムは、クラスターのインストールに使用するコンピューターにいくつかのファイルを作成します。クラスターのインストール完了後は、インストールプログラムおよびインストールプログラムが作成するファイルを保持する必要があります。ファイルはいずれもクラスターを削除するために必要になります。
重要インストールプログラムで作成されたファイルを削除しても、クラスターがインストール時に失敗した場合でもクラスターは削除されません。クラスターを削除するには、特定のクラウドプロバイダー用の OpenShift Container Platform のアンインストール手順を実行します。
インストールプログラムを展開します。たとえば、Linux オペレーティングシステムを使用するコンピューターで以下のコマンドを実行します。
Copy to Clipboard Copied! Toggle word wrap Toggle overflow tar -xvf openshift-install-linux.tar.gz
$ tar -xvf openshift-install-linux.tar.gz
- Red Hat OpenShift Cluster Manager からインストールプルシークレット をダウンロードします。このプルシークレットを使用し、OpenShift Container Platform コンポーネントのコンテナーイメージを提供する Quay.io など、組み込まれた各種の認証局によって提供されるサービスで認証できます。
3.4.4.1. インストール設定ファイルの作成
Alibaba Cloud にインストールする OpenShift Container Platform クラスターをカスタマイズできます。
前提条件
- OpenShift Container Platform インストールプログラムおよびクラスターのプルシークレットがある。
手順
install-config.yaml
ファイルを作成します。インストールプログラムが含まれるディレクトリーに切り替え、以下のコマンドを実行します。
Copy to Clipboard Copied! Toggle word wrap Toggle overflow ./openshift-install create install-config --dir <installation_directory>
$ ./openshift-install create install-config --dir <installation_directory>
1 - 1
<installation_directory>
の場合、インストールプログラムが作成するファイルを保存するためにディレクトリー名を指定します。
ディレクトリーを指定する場合:
-
ディレクトリーに
execute
権限があることを確認します。この権限は、インストールディレクトリーで Terraform バイナリーを実行するために必要です。 - 空のディレクトリーを使用します。ブートストラップ X.509 証明書などの一部のインストールアセットは有効期限が短いため、インストールディレクトリーを再利用しないでください。別のクラスターインストールの個別のファイルを再利用する必要がある場合は、それらをディレクトリーにコピーすることができます。ただし、インストールアセットのファイル名はリリース間で変更される可能性があります。インストールファイルを以前のバージョンの OpenShift Container Platform からコピーする場合は注意してコピーを行ってください。
プロンプト時に、クラウドの設定の詳細情報を指定します。
オプション: クラスターマシンにアクセスするために使用する SSH キーを選択します。
注記インストールのデバッグまたは障害復旧を実行する必要のある実稼働用の OpenShift Container Platform クラスターでは、
ssh-agent
プロセスが使用する SSH キーを指定します。- ターゲットとするプラットフォームとして alibabacloud を選択します。
- クラスターをデプロイするリージョンを選択します。
- クラスターをデプロイするベースドメインを選択します。ベースドメインは、クラスターに作成したパブリック DNS ゾーンに対応します。
- クラスターの記述名を指定します。
クラスターを Alibaba Cloud にインストールするには、Cloud Credential Operator (CCO) が手動モードで動作する必要があります。
install-config.yaml
ファイルを変更して、credentialsMode
パラメーターをManual
に設定します。credentialsMode
がManual
に設定された install-config.yaml 設定ファイルの例Copy to Clipboard Copied! Toggle word wrap Toggle overflow apiVersion: v1 baseDomain: cluster1.example.com credentialsMode: Manual compute: - architecture: amd64 hyperthreading: Enabled ...
apiVersion: v1 baseDomain: cluster1.example.com credentialsMode: Manual
1 compute: - architecture: amd64 hyperthreading: Enabled ...
- 1
- この行を追加して、
credentialsMode
をManual
に設定します。
-
install-config.yaml
ファイルを変更します。利用可能なパラメーターの詳細は、「インストール設定パラメーター」のセクションを参照してください。 install-config.yaml
ファイルをバックアップし、複数のクラスターをインストールするのに使用できるようにします。重要install-config.yaml
ファイルはインストールプロセス時に使用されます。このファイルを再利用する必要がある場合は、この段階でこれをバックアップしてください。
3.4.4.2. 必要なインストールマニフェストの生成
クラスターがマシンを設定するために必要な Kubernetes マニフェストと Ignition 設定ファイルを生成する必要があります。
手順
インストールプログラムが含まれているディレクトリーから次のコマンドを実行して、マニフェストを生成します。
Copy to Clipboard Copied! Toggle word wrap Toggle overflow openshift-install create manifests --dir <installation_directory>
$ openshift-install create manifests --dir <installation_directory>
ここで、
<installation_directory>
- インストールプログラムがファイルを作成するディレクトリーを指定します。
3.4.4.3. ccoctl ツールを使用した OpenShift Container Platform コンポーネントのクレデンシャルの作成
OpenShift Container Platform Cloud Credential Operator (CCO) ユーティリティーを使用して、Alibaba Cloud RAM ユーザーとクラスター内コンポーネントごとのポリシーの作成を自動化できます。
デフォルトで、ccoctl
はコマンドが実行されるディレクトリーにオブジェクトを作成します。オブジェクトを別のディレクトリーに作成するには、--output-dir
フラグを使用します。この手順では、<path_to_ccoctl_output_dir>
を使用してこの場所を参照します。
前提条件
以下が必要になります。
-
ccoctl
バイナリーを抽出して準備している。 - OpenShift Container Platform クラスターを作成するための十分な権限を持つ RAM ユーザーを作成している。
-
その RAM ユーザーの AccessKeyID (
access_key_id
) と AccessKeySecret (access_key_secret
) をローカルコンピューターの~/.alibabacloud/credentials
ファイル に追加しました。
手順
次のコマンドを実行して、インストールファイルのリリースイメージを
$RELEASE_IMAGE
変数に設定します。Copy to Clipboard Copied! Toggle word wrap Toggle overflow RELEASE_IMAGE=$(./openshift-install version | awk '/release image/ {print $3}')
$ RELEASE_IMAGE=$(./openshift-install version | awk '/release image/ {print $3}')
以下のコマンドを実行して、OpenShift Container Platform リリースイメージから
CredentialsRequest
オブジェクトのリストを抽出します。Copy to Clipboard Copied! Toggle word wrap Toggle overflow oc adm release extract \ --from=$RELEASE_IMAGE \ --credentials-requests \ --included \ --install-config=<path_to_directory_with_installation_configuration>/install-config.yaml \ --to=<path_to_directory_for_credentials_requests>
$ 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
オブジェクトをすべて処理します。ツールを使用するには、次のコマンドを実行します。
Copy to Clipboard Copied! Toggle word wrap Toggle overflow ccoctl alibabacloud create-ram-users \ --name <name> \ --region=<alibaba_region> \ --credentials-requests-dir=<path_to_credentials_requests_directory> \ --output-dir=<path_to_ccoctl_output_dir>
$ ccoctl alibabacloud create-ram-users \ --name <name> \
1 --region=<alibaba_region> \
2 --credentials-requests-dir=<path_to_credentials_requests_directory> \
3 --output-dir=<path_to_ccoctl_output_dir>
4 注記クラスターで
TechPreviewNoUpgrade
機能セットによって有効化されたテクノロジープレビュー機能を使用している場合は、--enable-tech-preview
パラメーターを含める必要があります。出力例
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 2022/02/11 16:18:26 Created RAM User: user1-alicloud-openshift-machine-api-alibabacloud-credentials 2022/02/11 16:18:27 Ready for creating new ram policy user1-alicloud-openshift-machine-api-alibabacloud-credentials-policy-policy 2022/02/11 16:18:27 RAM policy user1-alicloud-openshift-machine-api-alibabacloud-credentials-policy-policy has created 2022/02/11 16:18:28 Policy user1-alicloud-openshift-machine-api-alibabacloud-credentials-policy-policy has attached on user user1-alicloud-openshift-machine-api-alibabacloud-credentials 2022/02/11 16:18:29 Created access keys for RAM User: user1-alicloud-openshift-machine-api-alibabacloud-credentials 2022/02/11 16:18:29 Saved credentials configuration to: user1-alicloud/manifests/openshift-machine-api-alibabacloud-credentials-credentials.yaml ...
2022/02/11 16:18:26 Created RAM User: user1-alicloud-openshift-machine-api-alibabacloud-credentials 2022/02/11 16:18:27 Ready for creating new ram policy user1-alicloud-openshift-machine-api-alibabacloud-credentials-policy-policy 2022/02/11 16:18:27 RAM policy user1-alicloud-openshift-machine-api-alibabacloud-credentials-policy-policy has created 2022/02/11 16:18:28 Policy user1-alicloud-openshift-machine-api-alibabacloud-credentials-policy-policy has attached on user user1-alicloud-openshift-machine-api-alibabacloud-credentials 2022/02/11 16:18:29 Created access keys for RAM User: user1-alicloud-openshift-machine-api-alibabacloud-credentials 2022/02/11 16:18:29 Saved credentials configuration to: user1-alicloud/manifests/openshift-machine-api-alibabacloud-credentials-credentials.yaml ...
注記RAM ユーザーは、同時に最大 2 つの AccessKey を持つことができます。
ccoctl alibabacloud create-ram-users
を 3 回以上実行すると、以前に生成されたマニフェストシークレットが古くなり、新しく生成されたシークレットを再適用する必要があります。OpenShift Container Platform シークレットが作成されていることを確認します。
Copy to Clipboard Copied! Toggle word wrap Toggle overflow ls <path_to_ccoctl_output_dir>/manifests
$ ls <path_to_ccoctl_output_dir>/manifests
出力例
Copy to Clipboard Copied! Toggle word wrap Toggle overflow openshift-cluster-csi-drivers-alibaba-disk-credentials-credentials.yaml openshift-image-registry-installer-cloud-credentials-credentials.yaml openshift-ingress-operator-cloud-credentials-credentials.yaml openshift-machine-api-alibabacloud-credentials-credentials.yaml
openshift-cluster-csi-drivers-alibaba-disk-credentials-credentials.yaml openshift-image-registry-installer-cloud-credentials-credentials.yaml openshift-ingress-operator-cloud-credentials-credentials.yaml openshift-machine-api-alibabacloud-credentials-credentials.yaml
RAM ユーザーとポリシーが Alibaba Cloud にクエリーを実行して作成されていることを確認できます。詳細については、RAM ユーザーとポリシーのリスト表示に関する Alibaba Cloud のドキュメントを参照してください。
生成されたクレデンシャルファイルをターゲットマニフェストディレクトリーにコピーします。
Copy to Clipboard Copied! Toggle word wrap Toggle overflow cp ./<path_to_ccoctl_output_dir>/manifests/*credentials.yaml ./<path_to_installation>dir>/manifests/
$ cp ./<path_to_ccoctl_output_dir>/manifests/*credentials.yaml ./<path_to_installation>dir>/manifests/
ここで、
<path_to_ccoctl_output_dir>
-
ccoctl alibabacloud create-ram-users
コマンドによって作成されるディレクトリーを指定します。 <path_to_installation_dir>
- インストールプログラムがファイルを作成するディレクトリーを指定します。
3.4.4.4. Alibaba Cloud 用にカスタマイズされた install-config.yaml ファイルのサンプル
インストール設定ファイル (install-config.yaml
) をカスタマイズして、クラスターのプラットフォームに関する詳細を指定したり、必要なパラメーターの値を変更したりできます。
apiVersion: v1 baseDomain: alicloud-dev.devcluster.openshift.com credentialsMode: Manual compute: - architecture: amd64 hyperthreading: Enabled name: worker platform: {} replicas: 3 controlPlane: architecture: amd64 hyperthreading: Enabled name: master platform: {} replicas: 3 metadata: creationTimestamp: null name: test-cluster networking: clusterNetwork: - cidr: 10.128.0.0/14 hostPrefix: 23 machineNetwork: - cidr: 10.0.0.0/16 networkType: OVNKubernetes serviceNetwork: - 172.30.0.0/16 platform: alibabacloud: defaultMachinePlatform: instanceType: ecs.g6.xlarge systemDiskCategory: cloud_efficiency systemDiskSize: 200 region: ap-southeast-1 resourceGroupID: rg-acfnw6j3hyai vpcID: vpc-0xifdjerdibmaqvtjob2b vswitchIDs: - vsw-0xi8ycgwc8wv5rhviwdq5 - vsw-0xiy6v3z2tedv009b4pz2 publish: External pullSecret: '{"auths": {"cloud.openshift.com": {"auth": ... }' sshKey: | ssh-rsa AAAA...
apiVersion: v1
baseDomain: alicloud-dev.devcluster.openshift.com
credentialsMode: Manual
compute:
- architecture: amd64
hyperthreading: Enabled
name: worker
platform: {}
replicas: 3
controlPlane:
architecture: amd64
hyperthreading: Enabled
name: master
platform: {}
replicas: 3
metadata:
creationTimestamp: null
name: test-cluster
networking:
clusterNetwork:
- cidr: 10.128.0.0/14
hostPrefix: 23
machineNetwork:
- cidr: 10.0.0.0/16
networkType: OVNKubernetes
serviceNetwork:
- 172.30.0.0/16
platform:
alibabacloud:
defaultMachinePlatform:
instanceType: ecs.g6.xlarge
systemDiskCategory: cloud_efficiency
systemDiskSize: 200
region: ap-southeast-1
resourceGroupID: rg-acfnw6j3hyai
vpcID: vpc-0xifdjerdibmaqvtjob2b
vswitchIDs:
- vsw-0xi8ycgwc8wv5rhviwdq5
- vsw-0xiy6v3z2tedv009b4pz2
publish: External
pullSecret: '{"auths": {"cloud.openshift.com": {"auth": ... }'
sshKey: |
ssh-rsa AAAA...
- 1
- 必須。インストールプログラムにより、クラスター名の入力を求められます。
- 2
- インストールするクラスターネットワークプラグイン。サポートされる値はデフォルト値の
OVNKubernetes
のみです。 - 3
- オプション: 独自のプラットフォーム設定を定義しないマシンプールのパラメーターを指定します。
- 4
- 必須。インストールプログラムにより、クラスターをデプロイするリージョンの入力を求められます。
- 5
- オプション。クラスターをインストールする必要がある既存のリソースグループを指定します。
- 8
- 必須。インストールプログラムは、プルシークレットの入力を求めます。
- 9
- オプション。インストールプログラムは、クラスター内のマシンへのアクセスに使用する SSH キー値の入力を求めます。
- 6 7
- オプション。これらは vswitchID 値の例です。
3.4.4.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 apiVersion: v1 baseDomain: my.domain.com proxy: httpProxy: http://<username>:<pswd>@<ip>:<port> httpsProxy: https://<username>:<pswd>@<ip>:<port> noProxy: example.com additionalTrustBundle: | -----BEGIN CERTIFICATE----- <MY_TRUSTED_CA_CERT> -----END CERTIFICATE----- additionalTrustBundlePolicy: <policy_to_add_additionalTrustBundle>
apiVersion: v1 baseDomain: my.domain.com proxy: httpProxy: http://<username>:<pswd>@<ip>:<port>
1 httpsProxy: https://<username>:<pswd>@<ip>:<port>
2 noProxy: example.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
には一致しません。*
を使用し、すべての宛先のプロキシーをバイパスします。 - 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
コマンドを使用してデプロイメントを再起動してからデプロイメントを完了します。以下に例を示します。Copy to Clipboard Copied! Toggle word wrap Toggle overflow ./openshift-install wait-for install-complete --log-level debug
$ ./openshift-install wait-for install-complete --log-level debug
- ファイルを保存し、OpenShift Container Platform のインストール時にこれを参照します。
インストールプログラムは、指定の install-config.yaml
ファイルのプロキシー設定を使用する cluster
という名前のクラスター全体のプロキシーを作成します。プロキシー設定が指定されていない場合、cluster
Proxy
オブジェクトが依然として作成されますが、これには spec
がありません。
cluster
という名前の Proxy
オブジェクトのみがサポートされ、追加のプロキシーを作成することはできません。
3.4.5. クラスターのデプロイ
互換性のあるクラウドプラットフォームに OpenShift Container Platform をインストールできます。
インストールプログラムの create cluster
コマンドは、初期インストール時に 1 回だけ実行できます。
前提条件
- クラスターをホストするクラウドプラットフォームでアカウントを設定しました。
- OpenShift Container Platform インストールプログラムおよびクラスターのプルシークレットがある。
- ホスト上のクラウドプロバイダーアカウントに、クラスターをデプロイするための適切な権限があることが確認されました。アカウントの権限が正しくないと、インストールプロセスが失敗し、不足している権限を示すエラーメッセージが表示されます。
手順
インストールプログラムが含まれるディレクトリーに切り替え、クラスターのデプロイメントを初期化します。
Copy to Clipboard Copied! Toggle word wrap Toggle overflow ./openshift-install create cluster --dir <installation_directory> \ --log-level=info
$ ./openshift-install create cluster --dir <installation_directory> \
1 --log-level=info
2
検証
クラスターのデプロイが正常に完了すると、次のようになります。
-
ターミナルには、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
...
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.4.6. バイナリーのダウンロードによる OpenShift CLI のインストール
コマンドラインインターフェイスを使用して OpenShift Container Platform と対話するために CLI (oc
) をインストールすることができます。oc
は Linux、Windows、または macOS にインストールできます。
以前のバージョンの oc
をインストールしている場合、これを使用して OpenShift Container Platform 4.15 のすべてのコマンドを実行することはできません。新規バージョンの oc
をダウンロードし、インストールします。
Linux への OpenShift CLI のインストール
以下の手順を使用して、OpenShift CLI (oc
) バイナリーを Linux にインストールできます。
手順
- Red Hat カスタマーポータルの OpenShift Container Platform ダウンロードページ に移動します。
- Product Variant ドロップダウンリストからアーキテクチャーを選択します。
- バージョン ドロップダウンリストから適切なバージョンを選択します。
- OpenShift v4.15 Linux Client エントリーの横にある Download Now をクリックして、ファイルを保存します。
アーカイブを展開します。
Copy to Clipboard Copied! Toggle word wrap Toggle overflow tar xvf <file>
$ tar xvf <file>
oc
バイナリーを、PATH
にあるディレクトリーに配置します。PATH
を確認するには、以下のコマンドを実行します。Copy to Clipboard Copied! Toggle word wrap Toggle overflow echo $PATH
$ echo $PATH
検証
OpenShift CLI のインストール後に、
oc
コマンドを使用して利用できます。Copy to Clipboard Copied! Toggle word wrap Toggle overflow oc <command>
$ oc <command>
Windows への OpenShift CLI のインストール
以下の手順を使用して、OpenShift CLI (oc
) バイナリーを Windows にインストールできます。
手順
- Red Hat カスタマーポータルの OpenShift Container Platform ダウンロードページ に移動します。
- バージョン ドロップダウンリストから適切なバージョンを選択します。
- OpenShift v4.15 Windows Client エントリーの横にある Download Now をクリックして、ファイルを保存します。
- ZIP プログラムでアーカイブを展開します。
oc
バイナリーを、PATH
にあるディレクトリーに移動します。PATH
を確認するには、コマンドプロンプトを開いて以下のコマンドを実行します。Copy to Clipboard Copied! Toggle word wrap Toggle overflow path
C:\> path
検証
OpenShift CLI のインストール後に、
oc
コマンドを使用して利用できます。Copy to Clipboard Copied! Toggle word wrap Toggle overflow oc <command>
C:\> oc <command>
macOS への OpenShift CLI のインストール
以下の手順を使用して、OpenShift CLI (oc
) バイナリーを macOS にインストールできます。
手順
- Red Hat カスタマーポータルの OpenShift Container Platform ダウンロードページ に移動します。
- バージョン ドロップダウンリストから適切なバージョンを選択します。
OpenShift v4.15 macOS Client エントリーの横にある Download Now をクリックして、ファイルを保存します。
注記macOS arm64 の場合は、OpenShift v4.15 macOS arm64 Client エントリーを選択します。
- アーカイブを展開し、解凍します。
oc
バイナリーをパスにあるディレクトリーに移動します。PATH
を確認するには、ターミナルを開き、以下のコマンドを実行します。Copy to Clipboard Copied! Toggle word wrap Toggle overflow echo $PATH
$ echo $PATH
検証
oc
コマンドを使用してインストールを確認します。Copy to Clipboard Copied! Toggle word wrap Toggle overflow oc <command>
$ oc <command>
3.4.7. CLI の使用によるクラスターへのログイン
クラスター kubeconfig
ファイルをエクスポートし、デフォルトシステムユーザーとしてクラスターにログインできます。kubeconfig
ファイルには、クライアントを正しいクラスターおよび API サーバーに接続するために CLI で使用されるクラスターに関する情報が含まれます。このファイルはクラスターに固有のファイルであり、OpenShift Container Platform のインストール時に作成されます。
前提条件
- OpenShift Container Platform クラスターをデプロイしていること。
-
oc
CLI をインストールしていること。
手順
kubeadmin
認証情報をエクスポートします。Copy to Clipboard Copied! Toggle word wrap Toggle overflow export KUBECONFIG=<installation_directory>/auth/kubeconfig
$ export KUBECONFIG=<installation_directory>/auth/kubeconfig
1 - 1
<installation_directory>
には、インストールファイルを保存したディレクトリーへのパスを指定します。
エクスポートされた設定を使用して、
oc
コマンドを正常に実行できることを確認します。Copy to Clipboard Copied! Toggle word wrap Toggle overflow oc whoami
$ oc whoami
出力例
Copy to Clipboard Copied! Toggle word wrap Toggle overflow system:admin
system:admin
3.4.8. Web コンソールを使用したクラスターへのログイン
kubeadmin
ユーザーは、OpenShift Container Platform のインストール後はデフォルトで存在します。OpenShift Container Platform Web コンソールを使用し、kubeadmin
ユーザーとしてクラスターにログインできます。
前提条件
- インストールホストにアクセスできる。
- クラスターのインストールを完了しており、すべてのクラスター Operator が利用可能である。
手順
インストールホストで
kubeadmin-password
ファイルからkubeadmin
ユーザーのパスワードを取得します。Copy to Clipboard Copied! Toggle word wrap Toggle overflow cat <installation_directory>/auth/kubeadmin-password
$ cat <installation_directory>/auth/kubeadmin-password
注記または、インストールホストで
<installation_directory>/.openshift_install.log
ログファイルからkubeadmin
パスワードを取得できます。OpenShift Container Platform Web コンソールルートをリスト表示します。
Copy to Clipboard Copied! Toggle word wrap Toggle overflow oc get routes -n openshift-console | grep 'console-openshift'
$ oc get routes -n openshift-console | grep 'console-openshift'
注記または、インストールホストで
<installation_directory>/.openshift_install.log
ログファイルからで OpenShift Container Platform ルートを取得できます。出力例
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 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 None
-
Web ブラウザーで前述のコマンドの出力で詳細に説明されたルートに移動し、
kubeadmin
ユーザーとしてログインします。
3.4.9. OpenShift Container Platform の Telemetry アクセス
OpenShift Container Platform 4.15 では、クラスターの健全性および正常に実行された更新についてのメトリクスを提供するためにデフォルトで実行される Telemetry サービスにも、インターネットアクセスが必要です。クラスターがインターネットに接続されている場合、Telemetry は自動的に実行され、クラスターは OpenShift Cluster Manager に登録されます。
OpenShift Cluster Manager インベントリーが正常である (Telemetry によって自動的に維持、または OpenShift Cluster Manager を使用して手動で維持) ことを確認した後に、subscription watch を使用 して、アカウントまたはマルチクラスターレベルで OpenShift Container Platform サブスクリプションを追跡します。
関連情報
- Telemetry サービスの詳細は、リモートヘルスモニタリング を参照してください。
- OpenShift Container Platform Web コンソールへのアクセスと理解の詳細については、Web コンソールへのアクセス を参照してください。
- OpenShift Container Platform Web コンソールへのアクセスと理解に関する詳細は、Web コンソールへのアクセス を参照してください。
3.4.10. 次のステップ
- インストールを検証 します。
- クラスターをカスタマイズ します。
- 必要に応じて、リモートヘルスレポートをオプトアウト できます。
3.5. ネットワークをカスタマイズして Alibaba Cloud にクラスターをインストールする
OpenShift Container Platform 4.15 では、カスタマイズされたネットワーク設定オプションを使用して、Alibaba Cloud にクラスターをインストールできます。ネットワーク設定をカスタマイズすることにより、クラスターは環境内の既存の IP アドレスの割り当てと共存でき、既存の MTU および VXLAN 設定と統合できます。
大半のネットワーク設定パラメーターはインストール時に設定する必要があり、実行中のクラスターで変更できるのは kubeProxy
設定パラメーターのみになります。
OpenShift Container Platform 上の Alibaba Cloud は、テクノロジープレビュー機能としてのみ利用できます。テクノロジープレビュー機能は、Red Hat 製品のサービスレベルアグリーメント (SLA) の対象外であり、機能的に完全ではないことがあります。Red Hat は、実稼働環境でこれらを使用することを推奨していません。テクノロジープレビューの機能は、最新の製品機能をいち早く提供して、開発段階で機能のテストを行いフィードバックを提供していただくことを目的としています。
Red Hat のテクノロジープレビュー機能のサポート範囲に関する詳細は、テクノロジープレビュー機能のサポート範囲 を参照してください。
3.5.1. 前提条件
- OpenShift Container Platform のインストールおよび更新 プロセスの詳細を確認した。
- クラスターインストール方法の選択およびそのユーザー向けの準備 を確認した。
- ドメインを登録 している。
- ファイアウォールを使用する場合は、クラスターがアクセスを必要とするサイトを許可するようにファイアウォールを設定する必要がある。
-
ご使用の環境でクラウド Resource Access Management (RAM) API にアクセスできない場合、または管理者レベルのクレデンシャルシークレットを
kube-system
namespace に保存したくない場合は、Resource Access Management (RAM) 認証情報を手動で作成および維持 することができます。
3.5.2. OpenShift Container Platform のインターネットアクセス
OpenShift Container Platform 4.15 では、クラスターをインストールするためにインターネットアクセスが必要になります。
インターネットへのアクセスは以下を実行するために必要です。
- OpenShift Cluster Manager にアクセスし、インストールプログラムをダウンロードし、サブスクリプション管理を実行します。クラスターにインターネットアクセスがあり、Telemetry を無効にしない場合、そのサービスは有効なサブスクリプションでクラスターを自動的に使用します。
- クラスターのインストールに必要なパッケージを取得するために Quay.io にアクセスします。
- クラスターの更新を実行するために必要なパッケージを取得します。
クラスターでインターネットに直接アクセスできない場合、プロビジョニングする一部のタイプのインフラストラクチャーでネットワークが制限されたインストールを実行できます。このプロセスで、必要なコンテンツをダウンロードし、これを使用してミラーレジストリーにインストールパッケージを設定します。インストールタイプによっては、クラスターのインストール環境でインターネットアクセスが不要となる場合があります。クラスターを更新する前に、ミラーレジストリーのコンテンツを更新します。
3.5.3. クラスターノードの 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 オペレーティングシステムを使用するコンピューターで以下のコマンドを実行します。
Copy to Clipboard Copied! Toggle word wrap Toggle overflow ssh-keygen -t ed25519 -N '' -f <path>/<file_name>
$ 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 キーを表示します。
Copy to Clipboard Copied! Toggle word wrap Toggle overflow cat <path>/<file_name>.pub
$ cat <path>/<file_name>.pub
たとえば、次のコマンドを実行して
~/.ssh/id_ed25519.pub
公開鍵を表示します。Copy to Clipboard Copied! Toggle word wrap Toggle overflow cat ~/.ssh/id_ed25519.pub
$ cat ~/.ssh/id_ed25519.pub
ローカルユーザーの SSH エージェントに SSH 秘密鍵 ID が追加されていない場合は、それを追加します。キーの SSH エージェント管理は、クラスターノードへのパスワードなしの SSH 認証、または
./openshift-install gather
コマンドを使用する場合は必要になります。注記一部のディストリビューションでは、
~/.ssh/id_rsa
および~/.ssh/id_dsa
などのデフォルトの SSH 秘密鍵のアイデンティティーは自動的に管理されます。ssh-agent
プロセスがローカルユーザーに対して実行されていない場合は、バックグラウンドタスクとして開始します。Copy to Clipboard Copied! Toggle word wrap Toggle overflow eval "$(ssh-agent -s)"
$ eval "$(ssh-agent -s)"
出力例
Copy to Clipboard Copied! Toggle word wrap Toggle overflow Agent pid 31874
Agent pid 31874
注記クラスターが FIPS モードにある場合は、FIPS 準拠のアルゴリズムのみを使用して SSH キーを生成します。鍵は RSA または ECDSA のいずれかである必要があります。
SSH プライベートキーを
ssh-agent
に追加します。Copy to Clipboard Copied! Toggle word wrap Toggle overflow ssh-add <path>/<file_name>
$ ssh-add <path>/<file_name>
1 - 1
~/.ssh/id_ed25519
などの、SSH プライベートキーのパスおよびファイル名を指定します。
出力例
Copy to Clipboard Copied! Toggle word wrap Toggle overflow Identity added: /home/<you>/<path>/<file_name> (<computer_name>)
Identity added: /home/<you>/<path>/<file_name> (<computer_name>)
次のステップ
- OpenShift Container Platform をインストールする際に、SSH パブリックキーをインストールプログラムに指定します。
3.5.4. インストールプログラムの取得
OpenShift Container Platform をインストールする前に、インストールに使用しているホストにインストールファイルをダウンロードします。
前提条件
- 500 MB のローカルディスク領域がある Linux または macOS を実行するコンピューターが必要です。
手順
- OpenShift Cluster Manager サイトの インフラストラクチャープロバイダー ページにアクセスします。Red Hat アカウントがある場合は、認証情報を使用してログインします。アカウントがない場合はこれを作成します。
- インフラストラクチャープロバイダーを選択します。
インストールタイプのページに移動し、ホストオペレーティングシステムとアーキテクチャーに対応するインストールプログラムをダウンロードして、インストール設定ファイルを保存するディレクトリーにファイルを配置します。
重要インストールプログラムは、クラスターのインストールに使用するコンピューターにいくつかのファイルを作成します。クラスターのインストール完了後は、インストールプログラムおよびインストールプログラムが作成するファイルを保持する必要があります。ファイルはいずれもクラスターを削除するために必要になります。
重要インストールプログラムで作成されたファイルを削除しても、クラスターがインストール時に失敗した場合でもクラスターは削除されません。クラスターを削除するには、特定のクラウドプロバイダー用の OpenShift Container Platform のアンインストール手順を実行します。
インストールプログラムを展開します。たとえば、Linux オペレーティングシステムを使用するコンピューターで以下のコマンドを実行します。
Copy to Clipboard Copied! Toggle word wrap Toggle overflow tar -xvf openshift-install-linux.tar.gz
$ tar -xvf openshift-install-linux.tar.gz
- Red Hat OpenShift Cluster Manager からインストールプルシークレット をダウンロードします。このプルシークレットを使用し、OpenShift Container Platform コンポーネントのコンテナーイメージを提供する Quay.io など、組み込まれた各種の認証局によって提供されるサービスで認証できます。
3.5.5. ネットワーク設定フェーズ
OpenShift Container Platform をインストールする前に、ネットワーク設定をカスタマイズできる 2 つのフェーズがあります。
- フェーズ 1
マニフェストファイルを作成する前に、
install-config.yaml
ファイルで以下のネットワーク関連のフィールドをカスタマイズできます。-
networking.networkType
-
networking.clusterNetwork
-
networking.serviceNetwork
networking.machineNetwork
これらのフィールドの詳細は、インストール設定パラメーター を参照してください。
注記優先される NIC が置かれている CIDR に一致する
networking.machineNetwork
を設定します。重要CIDR 範囲
172.17.0.0/16
は libVirt によって予約されています。この範囲、またはこの範囲と重複する範囲をクラスター内のネットワークに使用することはできません。
-
- フェーズ 2
-
openshift-install create manifests
を実行してマニフェストファイルを作成した後に、変更するフィールドのみでカスタマイズされた Cluster Network Operator マニフェストを定義できます。マニフェストを使用して、高度なネットワーク設定を指定できます。
フェーズ 2 で、install-config.yaml
ファイルのフェーズ 1 で指定した値を上書きすることはできません。ただし、フェーズ 2 でネットワークプラグインをさらにカスタマイズできます。
3.5.5.1. インストール設定ファイルの作成
インストールする OpenShift Container Platform クラスターをカスタマイズできます。
前提条件
- OpenShift Container Platform インストールプログラムおよびクラスターのプルシークレットがある。
手順
install-config.yaml
ファイルを作成します。インストールプログラムが含まれるディレクトリーに切り替え、以下のコマンドを実行します。
Copy to Clipboard Copied! Toggle word wrap Toggle overflow ./openshift-install create install-config --dir <installation_directory>
$ ./openshift-install create install-config --dir <installation_directory>
1 - 1
<installation_directory>
の場合、インストールプログラムが作成するファイルを保存するためにディレクトリー名を指定します。
ディレクトリーを指定する場合:
-
ディレクトリーに
execute
権限があることを確認します。この権限は、インストールディレクトリーで Terraform バイナリーを実行するために必要です。 - 空のディレクトリーを使用します。ブートストラップ X.509 証明書などの一部のインストールアセットは有効期限が短いため、インストールディレクトリーを再利用しないでください。別のクラスターインストールの個別のファイルを再利用する必要がある場合は、それらをディレクトリーにコピーすることができます。ただし、インストールアセットのファイル名はリリース間で変更される可能性があります。インストールファイルを以前のバージョンの OpenShift Container Platform からコピーする場合は注意してコピーを行ってください。
プロンプト時に、クラウドの設定の詳細情報を指定します。
オプション: クラスターマシンにアクセスするために使用する SSH キーを選択します。
注記インストールのデバッグまたは障害復旧を実行する必要のある実稼働用の OpenShift Container Platform クラスターでは、
ssh-agent
プロセスが使用する SSH キーを指定します。- クラスターの記述名を入力します。
-
install-config.yaml
ファイルを変更します。利用可能なパラメーターの詳細は、「インストール設定パラメーター」のセクションを参照してください。 install-config.yaml
ファイルをバックアップし、複数のクラスターをインストールするのに使用できるようにします。重要install-config.yaml
ファイルはインストールプロセス時に使用されます。このファイルを再利用する必要がある場合は、この段階でこれをバックアップしてください。
3.5.5.2. 必要なインストールマニフェストの生成
クラスターがマシンを設定するために必要な Kubernetes マニフェストと Ignition 設定ファイルを生成する必要があります。
手順
インストールプログラムが含まれているディレクトリーから次のコマンドを実行して、マニフェストを生成します。
Copy to Clipboard Copied! Toggle word wrap Toggle overflow openshift-install create manifests --dir <installation_directory>
$ openshift-install create manifests --dir <installation_directory>
ここで、
<installation_directory>
- インストールプログラムがファイルを作成するディレクトリーを指定します。
デフォルトで、ccoctl
はコマンドが実行されるディレクトリーにオブジェクトを作成します。オブジェクトを別のディレクトリーに作成するには、--output-dir
フラグを使用します。この手順では、<path_to_ccoctl_output_dir>
を使用してこの場所を参照します。
前提条件
以下が必要になります。
-
ccoctl
バイナリーを抽出して準備している。
手順
次のコマンドを実行して、インストールファイルのリリースイメージを
$RELEASE_IMAGE
変数に設定します。Copy to Clipboard Copied! Toggle word wrap Toggle overflow RELEASE_IMAGE=$(./openshift-install version | awk '/release image/ {print $3}')
$ RELEASE_IMAGE=$(./openshift-install version | awk '/release image/ {print $3}')
以下のコマンドを実行して、OpenShift Container Platform リリースイメージから
CredentialsRequest
オブジェクトのリストを抽出します。Copy to Clipboard Copied! Toggle word wrap Toggle overflow oc adm release extract \ --from=$RELEASE_IMAGE \ --credentials-requests \ --included \ --install-config=<path_to_directory_with_installation_configuration>/install-config.yaml \ --to=<path_to_directory_for_credentials_requests>
$ 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 注記このコマンドの実行には少し時間がかかる場合があります。
3.5.5.3. Alibaba Cloud 用にカスタマイズされた install-config.yaml ファイルのサンプル
インストール設定ファイル (install-config.yaml
) をカスタマイズして、クラスターのプラットフォームに関する詳細を指定したり、必要なパラメーターの値を変更したりできます。
apiVersion: v1 baseDomain: alicloud-dev.devcluster.openshift.com credentialsMode: Manual compute: - architecture: amd64 hyperthreading: Enabled name: worker platform: {} replicas: 3 controlPlane: architecture: amd64 hyperthreading: Enabled name: master platform: {} replicas: 3 metadata: creationTimestamp: null name: test-cluster networking: clusterNetwork: - cidr: 10.128.0.0/14 hostPrefix: 23 machineNetwork: - cidr: 10.0.0.0/16 networkType: OVNKubernetes serviceNetwork: - 172.30.0.0/16 platform: alibabacloud: defaultMachinePlatform: instanceType: ecs.g6.xlarge systemDiskCategory: cloud_efficiency systemDiskSize: 200 region: ap-southeast-1 resourceGroupID: rg-acfnw6j3hyai vpcID: vpc-0xifdjerdibmaqvtjob2b vswitchIDs: - vsw-0xi8ycgwc8wv5rhviwdq5 - vsw-0xiy6v3z2tedv009b4pz2 publish: External pullSecret: '{"auths": {"cloud.openshift.com": {"auth": ... }' sshKey: | ssh-rsa AAAA...
apiVersion: v1
baseDomain: alicloud-dev.devcluster.openshift.com
credentialsMode: Manual
compute:
- architecture: amd64
hyperthreading: Enabled
name: worker
platform: {}
replicas: 3
controlPlane:
architecture: amd64
hyperthreading: Enabled
name: master
platform: {}
replicas: 3
metadata:
creationTimestamp: null
name: test-cluster
networking:
clusterNetwork:
- cidr: 10.128.0.0/14
hostPrefix: 23
machineNetwork:
- cidr: 10.0.0.0/16
networkType: OVNKubernetes
serviceNetwork:
- 172.30.0.0/16
platform:
alibabacloud:
defaultMachinePlatform:
instanceType: ecs.g6.xlarge
systemDiskCategory: cloud_efficiency
systemDiskSize: 200
region: ap-southeast-1
resourceGroupID: rg-acfnw6j3hyai
vpcID: vpc-0xifdjerdibmaqvtjob2b
vswitchIDs:
- vsw-0xi8ycgwc8wv5rhviwdq5
- vsw-0xiy6v3z2tedv009b4pz2
publish: External
pullSecret: '{"auths": {"cloud.openshift.com": {"auth": ... }'
sshKey: |
ssh-rsa AAAA...
- 1
- 必須。インストールプログラムにより、クラスター名の入力を求められます。
- 2
- インストールするクラスターネットワークプラグイン。サポートされる値はデフォルト値の
OVNKubernetes
のみです。 - 3
- オプション: 独自のプラットフォーム設定を定義しないマシンプールのパラメーターを指定します。
- 4
- 必須。インストールプログラムにより、クラスターをデプロイするリージョンの入力を求められます。
- 5
- オプション。クラスターをインストールする必要がある既存のリソースグループを指定します。
- 8
- 必須。インストールプログラムは、プルシークレットの入力を求めます。
- 9
- オプション。インストールプログラムは、クラスター内のマシンへのアクセスに使用する SSH キー値の入力を求めます。
- 6 7
- オプション。これらは vswitchID 値の例です。
3.5.5.4. インストール時のクラスター全体のプロキシーの設定
実稼働環境では、インターネットへの直接アクセスを拒否し、代わりに 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 apiVersion: v1 baseDomain: my.domain.com proxy: httpProxy: http://<username>:<pswd>@<ip>:<port> httpsProxy: https://<username>:<pswd>@<ip>:<port> noProxy: example.com additionalTrustBundle: | -----BEGIN CERTIFICATE----- <MY_TRUSTED_CA_CERT> -----END CERTIFICATE----- additionalTrustBundlePolicy: <policy_to_add_additionalTrustBundle>
apiVersion: v1 baseDomain: my.domain.com proxy: httpProxy: http://<username>:<pswd>@<ip>:<port>
1 httpsProxy: https://<username>:<pswd>@<ip>:<port>
2 noProxy: example.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
には一致しません。*
を使用し、すべての宛先のプロキシーをバイパスします。 - 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
コマンドを使用してデプロイメントを再起動してからデプロイメントを完了します。以下に例を示します。Copy to Clipboard Copied! Toggle word wrap Toggle overflow ./openshift-install wait-for install-complete --log-level debug
$ ./openshift-install wait-for install-complete --log-level debug
- ファイルを保存し、OpenShift Container Platform のインストール時にこれを参照します。
インストールプログラムは、指定の install-config.yaml
ファイルのプロキシー設定を使用する cluster
という名前のクラスター全体のプロキシーを作成します。プロキシー設定が指定されていない場合、cluster
Proxy
オブジェクトが依然として作成されますが、これには spec
がありません。
cluster
という名前の Proxy
オブジェクトのみがサポートされ、追加のプロキシーを作成することはできません。
3.5.6. Cluster Network Operator (CNO) の設定
クラスターネットワークの設定は、Cluster Network Operator (CNO) 設定の一部として指定され、cluster
という名前のカスタムリソース (CR) オブジェクトに保存されます。CR は operator.openshift.io
API グループの Network
API のフィールドを指定します。
CNO 設定は、Network.config.openshift.io
API グループの Network
API からクラスターのインストール時に以下のフィールドを継承します。
clusterNetwork
- Pod IP アドレスの割り当てに使用する IP アドレスプール。
serviceNetwork
- サービスの IP アドレスプール。
defaultNetwork.type
-
クラスターネットワークプラグイン。
OVNKubernetes
は、インストール時にサポートされる唯一のプラグインです。
defaultNetwork
オブジェクトのフィールドを cluster
という名前の CNO オブジェクトに設定することにより、クラスターのクラスターネットワークプラグイン設定を指定できます。
3.5.6.1. Cluster Network Operator 設定オブジェクト
Cluster Network Operator (CNO) のフィールドは以下の表で説明されています。
フィールド | 型 | 説明 |
---|---|---|
|
|
CNO オブジェクトの名前。この名前は常に |
|
| Pod ID アドレスの割り当て、サブネット接頭辞の長さのクラスター内の個別ノードへの割り当てに使用される IP アドレスのブロックを指定するリストです。以下に例を示します。 spec: clusterNetwork: - cidr: 10.128.0.0/19 hostPrefix: 23 - cidr: 10.128.32.0/19 hostPrefix: 23
|
|
| サービスの IP アドレスのブロック。OpenShift SDN および OVN-Kubernetes ネットワークプラグインは、サービスネットワークの単一 IP アドレスブロックのみをサポートします。以下に例を示します。 spec: serviceNetwork: - 172.30.0.0/14
マニフェストを作成する前に、このフィールドを |
|
| クラスターネットワークのネットワークプラグインを設定します。 |
|
| このオブジェクトのフィールドは、kube-proxy 設定を指定します。OVN-Kubernetes クラスターネットワークプラグインを使用している場合、kube-proxy 設定は機能しません。 |
defaultNetwork オブジェクト設定
defaultNetwork
オブジェクトの値は、以下の表で定義されます。
フィールド | 型 | 説明 |
---|---|---|
|
|
注記 OpenShift Container Platform は、デフォルトで OVN-Kubernetes ネットワークプラグインを使用します。OpenShift SDN は、新しいクラスターのインストールの選択肢として利用できなくなりました。 |
|
| このオブジェクトは、OVN-Kubernetes ネットワークプラグインに対してのみ有効です。 |
OVN-Kubernetes ネットワークプラグインの設定
次の表では、OVN-Kubernetes ネットワークプラグインの設定フィールドを説明します。
フィールド | 型 | 説明 |
---|---|---|
|
| Geneve (Generic Network Virtualization Encapsulation) オーバーレイネットワークの MTU (maximum transmission unit)。これは、プライマリーネットワークインターフェイスの MTU に基づいて自動的に検出されます。通常、検出された MTU を上書きする必要はありません。 自動検出した値が予想される値ではない場合は、ノード上のプライマリーネットワークインターフェイスの MTU が正しいことを確認します。このオプションを使用して、ノード上のプライマリーネットワークインターフェイスの MTU 値を変更することはできません。
クラスターで異なるノードに異なる MTU 値が必要な場合、この値をクラスター内の最小の MTU 値よりも |
|
|
すべての Geneve パケットに使用するポート。デフォルト値は |
|
| IPsec 設定をカスタマイズするための設定オブジェクトを指定します。 |
|
| ネットワークポリシー監査ロギングをカスタマイズする設定オブジェクトを指定します。指定されていない場合は、デフォルトの監査ログ設定が使用されます。 |
|
| オプション: Egress トラフィックのノードゲートウェイへの送信方法をカスタマイズするための設定オブジェクトを指定します。 注記 Egress トラフィックの移行中は、Cluster Network Operator (CNO) が変更を正常にロールアウトするまで、ワークロードとサービストラフィックに多少の中断が発生することが予想されます。 |
|
既存のネットワークインフラストラクチャーが このフィールドは、インストール後に変更できません。 |
デフォルト値は |
|
既存のネットワークインフラストラクチャーが このフィールドは、インストール後に変更できません。 |
デフォルト値は |
フィールド | 型 | 説明 |
---|---|---|
| integer |
ノードごとに毎秒生成されるメッセージの最大数。デフォルト値は、1 秒あたり |
| integer |
監査ログの最大サイズ (バイト単位)。デフォルト値は |
| integer | 保持されるログファイルの最大数。 |
| string | 以下の追加の監査ログターゲットのいずれかになります。
|
| string |
RFC5424 で定義される |
フィールド | 型 | 説明 |
---|---|---|
|
|
Pod からホストネットワークスタックへの Egress トラフィックを送信するには、このフィールドを
このフィールドで、Open vSwitch ハードウェアオフロード機能との対話が可能になりました。このフィールドを |
|
|
|
フィールド | 型 | 説明 |
---|---|---|
|
| IPsec 実装の動作を指定します。次の値のいずれかである必要があります。
|
IPsec が有効な OVN-Kubernetes 設定の例
defaultNetwork: type: OVNKubernetes ovnKubernetesConfig: mtu: 1400 genevePort: 6081 ipsecConfig: mode: Full
defaultNetwork:
type: OVNKubernetes
ovnKubernetesConfig:
mtu: 1400
genevePort: 6081
ipsecConfig:
mode: Full
OVNKubernetes を使用すると、IBM Power® でスタック枯渇の問題が発生する可能性があります。
kubeProxyConfig オブジェクト設定 (OpenShiftSDN コンテナーネットワークインターフェイスのみ)
kubeProxyConfig
オブジェクトの値は以下の表で定義されます。
フィールド | 型 | 説明 |
---|---|---|
|
|
注記
OpenShift Container Platform 4.3 以降で強化されたパフォーマンスの向上により、 |
|
|
kubeProxyConfig: proxyArguments: iptables-min-sync-period: - 0s
|
3.5.7. 高度なネットワーク設定の指定
ネットワークプラグインに高度なネットワーク設定を使用し、クラスターを既存のネットワーク環境に統合することができます。高度なネットワーク設定は、クラスターのインストール前にのみ指定することができます。
インストールプロブラムで作成される OpenShift Container Platform マニフェストファイルを変更してネットワーク設定をカスタマイズすることは、サポートされていません。以下の手順のように、作成するマニフェストファイルを適用することがサポートされています。
前提条件
-
install-config.yaml
ファイルを作成し、これに対する変更を完了している。
手順
インストールプログラムが含まれるディレクトリーに切り替え、マニフェストを作成します。
Copy to Clipboard Copied! Toggle word wrap Toggle overflow ./openshift-install create manifests --dir <installation_directory>
$ ./openshift-install create manifests --dir <installation_directory>
1 - 1
<installation_directory>
は、クラスターのinstall-config.yaml
ファイルが含まれるディレクトリーの名前を指定します。
cluster-network-03-config.yml
という名前の、高度なネットワーク設定用のスタブマニフェストファイルを<installation_directory>/manifests/
ディレクトリーに作成します。Copy to Clipboard Copied! Toggle word wrap Toggle overflow apiVersion: operator.openshift.io/v1 kind: Network metadata: name: cluster spec:
apiVersion: operator.openshift.io/v1 kind: Network metadata: name: cluster spec:
次の例のように、
cluster-network-03-config.yml
ファイルでクラスターの高度なネットワーク設定を指定します。OVN-Kubernetes ネットワークプロバイダーの IPsec を有効にする
Copy to Clipboard Copied! Toggle word wrap Toggle overflow apiVersion: operator.openshift.io/v1 kind: Network metadata: name: cluster spec: defaultNetwork: ovnKubernetesConfig: ipsecConfig: mode: Full
apiVersion: operator.openshift.io/v1 kind: Network metadata: name: cluster spec: defaultNetwork: ovnKubernetesConfig: ipsecConfig: mode: Full
-
オプション:
manifests/cluster-network-03-config.yml
ファイルをバックアップします。インストールプログラムは、Ignition 設定ファイルの作成時にmanifests/
ディレクトリーを使用します。
3.5.8. OVN-Kubernetes を使用したハイブリッドネットワークの設定
OVN-Kubernetes ネットワークプラグインを使用してハイブリッドネットワークを使用するようにクラスターを設定できます。これにより、異なるノードのネットワーク設定をサポートするハイブリッドクラスターが可能になります。
この設定は、同じクラスター内で Linux ノードと Windows ノードの両方を実行するために必要です。
前提条件
-
install-config.yaml
ファイルでnetworking.networkType
パラメーターのOVNKubernetes
を定義していること。詳細は、選択したクラウドプロバイダーでの OpenShift Container Platform ネットワークのカスタマイズの設定に関するインストールドキュメントを参照してください。
手順
インストールプログラムが含まれるディレクトリーに切り替え、マニフェストを作成します。
Copy to Clipboard Copied! Toggle word wrap Toggle overflow ./openshift-install create manifests --dir <installation_directory>
$ ./openshift-install create manifests --dir <installation_directory>
ここでは、以下のようになります。
<installation_directory>
-
クラスターの
install-config.yaml
ファイルが含まれるディレクトリーの名前を指定します。
cluster-network-03-config.yml
という名前の、高度なネットワーク設定用のスタブマニフェストファイルを<installation_directory>/manifests/
ディレクトリーに作成します。Copy to Clipboard Copied! Toggle word wrap Toggle overflow cat <<EOF > <installation_directory>/manifests/cluster-network-03-config.yml apiVersion: operator.openshift.io/v1 kind: Network metadata: name: cluster spec: EOF
$ cat <<EOF > <installation_directory>/manifests/cluster-network-03-config.yml apiVersion: operator.openshift.io/v1 kind: Network metadata: name: cluster spec: EOF
ここでは、以下のようになります。
<installation_directory>
-
クラスターの
manifests/
ディレクトリーが含まれるディレクトリー名を指定します。
cluster-network-03-config.yml
ファイルをエディターで開き、以下の例のようにハイブリッドネットワークで OVN-Kubernetes を設定します。ハイブリッドネットワーク設定の指定
Copy to Clipboard Copied! Toggle word wrap Toggle overflow apiVersion: operator.openshift.io/v1 kind: Network metadata: name: cluster spec: defaultNetwork: ovnKubernetesConfig: hybridOverlayConfig: hybridClusterNetwork: - cidr: 10.132.0.0/14 hostPrefix: 23 hybridOverlayVXLANPort: 9898
apiVersion: operator.openshift.io/v1 kind: Network metadata: name: cluster spec: defaultNetwork: ovnKubernetesConfig: hybridOverlayConfig: hybridClusterNetwork:
1 - cidr: 10.132.0.0/14 hostPrefix: 23 hybridOverlayVXLANPort: 9898
2 - 1
- 追加のオーバーレイネットワーク上のノードに使用される CIDR 設定を指定します。
hybridClusterNetwork
CIDR はclusterNetwork
CIDR と重複できません。 - 2
- 追加のオーバーレイネットワークのカスタム VXLAN ポートを指定します。これは、vSphere にインストールされたクラスターで Windows ノードを実行するために必要であり、その他のクラウドプロバイダー用に設定することはできません。カスタムポートには、デフォルトの
4789
ポートを除くいずれかのオープンポートを使用できます。この要件の詳細は、Microsoft ドキュメントの Pod-to-pod connectivity between hosts is broken を参照してください。
注記Windows Server Long-Term Servicing Channel (LTSC): Windows Server 2019 は、カスタムの VXLAN ポートの選択をサポートしないため、カスタムの
hybridOverlayVXLANPort
値を持つクラスターではサポートされません。-
cluster-network-03-config.yml
ファイルを保存し、テキストエディターを終了します。 -
オプション:
manifests/cluster-network-03-config.yml
ファイルをバックアップします。インストールプログラムは、クラスターの作成時にmanifests/
ディレクトリーを削除します。
3.5.9. クラスターのデプロイ
互換性のあるクラウドプラットフォームに OpenShift Container Platform をインストールできます。
インストールプログラムの create cluster
コマンドは、初期インストール時に 1 回だけ実行できます。
前提条件
- クラスターをホストするクラウドプラットフォームでアカウントを設定しました。
- OpenShift Container Platform インストールプログラムおよびクラスターのプルシークレットがある。
- ホスト上のクラウドプロバイダーアカウントに、クラスターをデプロイするための適切な権限があることが確認されました。アカウントの権限が正しくないと、インストールプロセスが失敗し、不足している権限を示すエラーメッセージが表示されます。
手順
インストールプログラムが含まれるディレクトリーに切り替え、クラスターのデプロイメントを初期化します。
Copy to Clipboard Copied! Toggle word wrap Toggle overflow ./openshift-install create cluster --dir <installation_directory> \ --log-level=info
$ ./openshift-install create cluster --dir <installation_directory> \
1 --log-level=info
2
検証
クラスターのデプロイが正常に完了すると、次のようになります。
-
ターミナルには、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
...
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.5.10. バイナリーのダウンロードによる OpenShift CLI のインストール
コマンドラインインターフェイスを使用して OpenShift Container Platform と対話するために CLI (oc
) をインストールすることができます。oc
は Linux、Windows、または macOS にインストールできます。
以前のバージョンの oc
をインストールしている場合、これを使用して OpenShift Container Platform 4.15 のすべてのコマンドを実行することはできません。新規バージョンの oc
をダウンロードし、インストールします。
Linux への OpenShift CLI のインストール
以下の手順を使用して、OpenShift CLI (oc
) バイナリーを Linux にインストールできます。
手順
- Red Hat カスタマーポータルの OpenShift Container Platform ダウンロードページ に移動します。
- Product Variant ドロップダウンリストからアーキテクチャーを選択します。
- バージョン ドロップダウンリストから適切なバージョンを選択します。
- OpenShift v4.15 Linux Client エントリーの横にある Download Now をクリックして、ファイルを保存します。
アーカイブを展開します。
Copy to Clipboard Copied! Toggle word wrap Toggle overflow tar xvf <file>
$ tar xvf <file>
oc
バイナリーを、PATH
にあるディレクトリーに配置します。PATH
を確認するには、以下のコマンドを実行します。Copy to Clipboard Copied! Toggle word wrap Toggle overflow echo $PATH
$ echo $PATH
検証
OpenShift CLI のインストール後に、
oc
コマンドを使用して利用できます。Copy to Clipboard Copied! Toggle word wrap Toggle overflow oc <command>
$ oc <command>
Windows への OpenShift CLI のインストール
以下の手順を使用して、OpenShift CLI (oc
) バイナリーを Windows にインストールできます。
手順
- Red Hat カスタマーポータルの OpenShift Container Platform ダウンロードページ に移動します。
- バージョン ドロップダウンリストから適切なバージョンを選択します。
- OpenShift v4.15 Windows Client エントリーの横にある Download Now をクリックして、ファイルを保存します。
- ZIP プログラムでアーカイブを展開します。
oc
バイナリーを、PATH
にあるディレクトリーに移動します。PATH
を確認するには、コマンドプロンプトを開いて以下のコマンドを実行します。Copy to Clipboard Copied! Toggle word wrap Toggle overflow path
C:\> path
検証
OpenShift CLI のインストール後に、
oc
コマンドを使用して利用できます。Copy to Clipboard Copied! Toggle word wrap Toggle overflow oc <command>
C:\> oc <command>
macOS への OpenShift CLI のインストール
以下の手順を使用して、OpenShift CLI (oc
) バイナリーを macOS にインストールできます。
手順
- Red Hat カスタマーポータルの OpenShift Container Platform ダウンロードページ に移動します。
- バージョン ドロップダウンリストから適切なバージョンを選択します。
OpenShift v4.15 macOS Client エントリーの横にある Download Now をクリックして、ファイルを保存します。
注記macOS arm64 の場合は、OpenShift v4.15 macOS arm64 Client エントリーを選択します。
- アーカイブを展開し、解凍します。
oc
バイナリーをパスにあるディレクトリーに移動します。PATH
を確認するには、ターミナルを開き、以下のコマンドを実行します。Copy to Clipboard Copied! Toggle word wrap Toggle overflow echo $PATH
$ echo $PATH
検証
oc
コマンドを使用してインストールを確認します。Copy to Clipboard Copied! Toggle word wrap Toggle overflow oc <command>
$ oc <command>
3.5.11. CLI の使用によるクラスターへのログイン
クラスター kubeconfig
ファイルをエクスポートし、デフォルトシステムユーザーとしてクラスターにログインできます。kubeconfig
ファイルには、クライアントを正しいクラスターおよび API サーバーに接続するために CLI で使用されるクラスターに関する情報が含まれます。このファイルはクラスターに固有のファイルであり、OpenShift Container Platform のインストール時に作成されます。
前提条件
- OpenShift Container Platform クラスターをデプロイしていること。
-
oc
CLI をインストールしていること。
手順
kubeadmin
認証情報をエクスポートします。Copy to Clipboard Copied! Toggle word wrap Toggle overflow export KUBECONFIG=<installation_directory>/auth/kubeconfig
$ export KUBECONFIG=<installation_directory>/auth/kubeconfig
1 - 1
<installation_directory>
には、インストールファイルを保存したディレクトリーへのパスを指定します。
エクスポートされた設定を使用して、
oc
コマンドを正常に実行できることを確認します。Copy to Clipboard Copied! Toggle word wrap Toggle overflow oc whoami
$ oc whoami
出力例
Copy to Clipboard Copied! Toggle word wrap Toggle overflow system:admin
system:admin
3.5.12. Web コンソールを使用したクラスターへのログイン
kubeadmin
ユーザーは、OpenShift Container Platform のインストール後はデフォルトで存在します。OpenShift Container Platform Web コンソールを使用し、kubeadmin
ユーザーとしてクラスターにログインできます。
前提条件
- インストールホストにアクセスできる。
- クラスターのインストールを完了しており、すべてのクラスター Operator が利用可能である。
手順
インストールホストで
kubeadmin-password
ファイルからkubeadmin
ユーザーのパスワードを取得します。Copy to Clipboard Copied! Toggle word wrap Toggle overflow cat <installation_directory>/auth/kubeadmin-password
$ cat <installation_directory>/auth/kubeadmin-password
注記または、インストールホストで
<installation_directory>/.openshift_install.log
ログファイルからkubeadmin
パスワードを取得できます。OpenShift Container Platform Web コンソールルートをリスト表示します。
Copy to Clipboard Copied! Toggle word wrap Toggle overflow oc get routes -n openshift-console | grep 'console-openshift'
$ oc get routes -n openshift-console | grep 'console-openshift'
注記または、インストールホストで
<installation_directory>/.openshift_install.log
ログファイルからで OpenShift Container Platform ルートを取得できます。出力例
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 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 None
-
Web ブラウザーで前述のコマンドの出力で詳細に説明されたルートに移動し、
kubeadmin
ユーザーとしてログインします。
3.5.13. OpenShift Container Platform の Telemetry アクセス
OpenShift Container Platform 4.15 では、クラスターの健全性および正常に実行された更新についてのメトリクスを提供するためにデフォルトで実行される Telemetry サービスにも、インターネットアクセスが必要です。クラスターがインターネットに接続されている場合、Telemetry は自動的に実行され、クラスターは OpenShift Cluster Manager に登録されます。
OpenShift Cluster Manager インベントリーが正常である (Telemetry によって自動的に維持、または OpenShift Cluster Manager を使用して手動で維持) ことを確認した後に、subscription watch を使用 して、アカウントまたはマルチクラスターレベルで OpenShift Container Platform サブスクリプションを追跡します。
関連情報
- Telemetry サービスの詳細は、リモートヘルスモニタリング を参照してください。
- OpenShift Container Platform Web コンソールへのアクセスと理解の詳細については、Web コンソールへのアクセス を参照してください。
- OpenShift Container Platform Web コンソールへのアクセスと理解に関する詳細は、Web コンソールへのアクセス を参照してください。
3.5.14. 次のステップ
- インストールを検証 します。
- クラスターをカスタマイズ します。
- 必要に応じて、リモートヘルスレポートをオプトアウト できます。
3.6. Alibaba Cloud 上のクラスターを既存の VPC にインストールする
OpenShift Container Platform バージョン 4.15 では、Alibaba Cloud Services 上の既存の Alibaba Virtual Private Cloud (VPC) にクラスターをインストールできます。インストールプログラムは必要なインフラストラクチャーをプロビジョニングし、その後カスタマイズできます。VPC インストールをカスタマイズするには、クラスターをインストールする前に 'install-config.yaml' ファイルのパラメーターを変更します。
OpenShift Container Platform インストール設定のスコープは意図的に狭められています。単純さを確保し、確実にインストールを実行できるように設計されているためです。インストールが完了した後にさらに多くの OpenShift Container Platform 設定タスクを実行することができます。
OpenShift Container Platform 上の Alibaba Cloud は、テクノロジープレビュー機能としてのみ利用できます。テクノロジープレビュー機能は、Red Hat 製品のサービスレベルアグリーメント (SLA) の対象外であり、機能的に完全ではないことがあります。Red Hat は、実稼働環境でこれらを使用することを推奨していません。テクノロジープレビューの機能は、最新の製品機能をいち早く提供して、開発段階で機能のテストを行いフィードバックを提供していただくことを目的としています。
Red Hat のテクノロジープレビュー機能のサポート範囲に関する詳細は、テクノロジープレビュー機能のサポート範囲 を参照してください。
3.6.1. 前提条件
- OpenShift Container Platform のインストールおよび更新 プロセスの詳細を確認した。
- クラスターインストール方法の選択およびそのユーザー向けの準備 を確認した。
- ドメインを登録 している。
- ファイアウォールを使用する場合は、クラスターがアクセスを必要とするサイトを許可するようにファイアウォールを設定する必要がある。
-
ご使用の環境でクラウド Resource Access Management (RAM) API にアクセスできない場合、または管理者レベルのクレデンシャルシークレットを
kube-system
namespace に保存したくない場合は、Resource Access Management (RAM) 認証情報を手動で作成および維持 することができます。
3.6.2. カスタム VPC の使用
OpenShift Container Platform 4.15 では、Alibaba Cloud Platform の既存 Virtual Private Cloud (VPC) 内における既存のサブネットにクラスターをデプロイできます。OpenShift Container Platform を既存の Alibaba VPC にデプロイすることで、新しいアカウントの制限の制約を回避し、所属する組織の運用上の制約をより簡単に順守することができます。VPC を作成するために必要なインフラストラクチャーの作成パーミッションを取得できない場合は、このインストールオプションを使用します。vSwitch を使用してネットワークを設定する必要があります。
3.6.2.1. VPC を使用するための要件
VPC CIDR ブロックとマシンネットワーク CIDR の組み合わせは、空であってはなりません。vSwitch はマシンネットワーク内にある必要があります。
インストールプログラムでは、次のコンポーネントは作成されません。
- VPC
- vSwitch
- ルートテーブル
- NAT ゲートウェイ
インストールプログラムでは、クラウド提供の DNS サーバーを使用する必要があります。カスタム DNS サーバーの使用はサポートされていないため、インストールが失敗します。
3.6.2.2. VPC 検証
指定した vSwitch が適切であることを確認するために、インストールプログラムは次のデータを確認します。
- 指定するすべての vSwitch が存在する必要があります。
- コントロールプレーンマシンとコンピュートマシンに 1 つ以上の vSwitch を提供しました。
- vSwitch の CIDR は、指定したマシン CIDR に属します。
3.6.2.3. パーミッションの区分
一部の個人は、クラウド内に他とは異なるリソースを作成できます。たとえば、インスタンス、バケット、ロードバランサーなどのアプリケーション固有のアイテムを作成できる場合がありますが、VPC や vSwitch などのネットワーク関連のコンポーネントは作成できません。
3.6.2.4. クラスター間の分離
OpenShift Container Platform を既存のネットワークにデプロイする場合、クラスターサービスの分離は以下の方法で軽減されます。
- 複数の OpenShift Container Platform クラスターを同じ VPC にインストールできます。
- ICMP Ingress はネットワーク全体で許可されます。
- TCP 22 Ingress (SSH) はネットワーク全体に対して許可されます。
- コントロールプレーンの TCP 6443 Ingress (Kubernetes API) はネットワーク全体に対して許可されます。
- コントロールプレーンの TCP 22623 Ingress (MCS) はネットワーク全体に対して許可されます。
3.6.3. OpenShift Container Platform のインターネットアクセス
OpenShift Container Platform 4.15 では、クラスターをインストールするためにインターネットアクセスが必要になります。
インターネットへのアクセスは以下を実行するために必要です。
- OpenShift Cluster Manager にアクセスし、インストールプログラムをダウンロードし、サブスクリプション管理を実行します。クラスターにインターネットアクセスがあり、Telemetry を無効にしない場合、そのサービスは有効なサブスクリプションでクラスターを自動的に使用します。
- クラスターのインストールに必要なパッケージを取得するために Quay.io にアクセスします。
- クラスターの更新を実行するために必要なパッケージを取得します。
クラスターでインターネットに直接アクセスできない場合、プロビジョニングする一部のタイプのインフラストラクチャーでネットワークが制限されたインストールを実行できます。このプロセスで、必要なコンテンツをダウンロードし、これを使用してミラーレジストリーにインストールパッケージを設定します。インストールタイプによっては、クラスターのインストール環境でインターネットアクセスが不要となる場合があります。クラスターを更新する前に、ミラーレジストリーのコンテンツを更新します。
3.6.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 オペレーティングシステムを使用するコンピューターで以下のコマンドを実行します。
Copy to Clipboard Copied! Toggle word wrap Toggle overflow ssh-keygen -t ed25519 -N '' -f <path>/<file_name>
$ 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 キーを表示します。
Copy to Clipboard Copied! Toggle word wrap Toggle overflow cat <path>/<file_name>.pub
$ cat <path>/<file_name>.pub
たとえば、次のコマンドを実行して
~/.ssh/id_ed25519.pub
公開鍵を表示します。Copy to Clipboard Copied! Toggle word wrap Toggle overflow cat ~/.ssh/id_ed25519.pub
$ cat ~/.ssh/id_ed25519.pub
ローカルユーザーの SSH エージェントに SSH 秘密鍵 ID が追加されていない場合は、それを追加します。キーの SSH エージェント管理は、クラスターノードへのパスワードなしの SSH 認証、または
./openshift-install gather
コマンドを使用する場合は必要になります。注記一部のディストリビューションでは、
~/.ssh/id_rsa
および~/.ssh/id_dsa
などのデフォルトの SSH 秘密鍵のアイデンティティーは自動的に管理されます。ssh-agent
プロセスがローカルユーザーに対して実行されていない場合は、バックグラウンドタスクとして開始します。Copy to Clipboard Copied! Toggle word wrap Toggle overflow eval "$(ssh-agent -s)"
$ eval "$(ssh-agent -s)"
出力例
Copy to Clipboard Copied! Toggle word wrap Toggle overflow Agent pid 31874
Agent pid 31874
注記クラスターが FIPS モードにある場合は、FIPS 準拠のアルゴリズムのみを使用して SSH キーを生成します。鍵は RSA または ECDSA のいずれかである必要があります。
SSH プライベートキーを
ssh-agent
に追加します。Copy to Clipboard Copied! Toggle word wrap Toggle overflow ssh-add <path>/<file_name>
$ ssh-add <path>/<file_name>
1 - 1
~/.ssh/id_ed25519
などの、SSH プライベートキーのパスおよびファイル名を指定します。
出力例
Copy to Clipboard Copied! Toggle word wrap Toggle overflow Identity added: /home/<you>/<path>/<file_name> (<computer_name>)
Identity added: /home/<you>/<path>/<file_name> (<computer_name>)
次のステップ
- OpenShift Container Platform をインストールする際に、SSH パブリックキーをインストールプログラムに指定します。
3.6.5. インストールプログラムの取得
OpenShift Container Platform をインストールする前に、インストールに使用しているホストにインストールファイルをダウンロードします。
前提条件
- 500 MB のローカルディスク領域がある Linux または macOS を実行するコンピューターが必要です。
手順
- OpenShift Cluster Manager サイトの インフラストラクチャープロバイダー ページにアクセスします。Red Hat アカウントがある場合は、認証情報を使用してログインします。アカウントがない場合はこれを作成します。
- インフラストラクチャープロバイダーを選択します。
インストールタイプのページに移動し、ホストオペレーティングシステムとアーキテクチャーに対応するインストールプログラムをダウンロードして、インストール設定ファイルを保存するディレクトリーにファイルを配置します。
重要インストールプログラムは、クラスターのインストールに使用するコンピューターにいくつかのファイルを作成します。クラスターのインストール完了後は、インストールプログラムおよびインストールプログラムが作成するファイルを保持する必要があります。ファイルはいずれもクラスターを削除するために必要になります。
重要インストールプログラムで作成されたファイルを削除しても、クラスターがインストール時に失敗した場合でもクラスターは削除されません。クラスターを削除するには、特定のクラウドプロバイダー用の OpenShift Container Platform のアンインストール手順を実行します。
インストールプログラムを展開します。たとえば、Linux オペレーティングシステムを使用するコンピューターで以下のコマンドを実行します。
Copy to Clipboard Copied! Toggle word wrap Toggle overflow tar -xvf openshift-install-linux.tar.gz
$ tar -xvf openshift-install-linux.tar.gz
- Red Hat OpenShift Cluster Manager からインストールプルシークレット をダウンロードします。このプルシークレットを使用し、OpenShift Container Platform コンポーネントのコンテナーイメージを提供する Quay.io など、組み込まれた各種の認証局によって提供されるサービスで認証できます。
3.6.5.1. インストール設定ファイルの作成
Alibaba Cloud にインストールする OpenShift Container Platform クラスターをカスタマイズできます。
前提条件
- OpenShift Container Platform インストールプログラムおよびクラスターのプルシークレットがある。
手順
install-config.yaml
ファイルを作成します。インストールプログラムが含まれるディレクトリーに切り替え、以下のコマンドを実行します。
Copy to Clipboard Copied! Toggle word wrap Toggle overflow ./openshift-install create install-config --dir <installation_directory>
$ ./openshift-install create install-config --dir <installation_directory>
1 - 1
<installation_directory>
の場合、インストールプログラムが作成するファイルを保存するためにディレクトリー名を指定します。
ディレクトリーを指定する場合:
-
ディレクトリーに
execute
権限があることを確認します。この権限は、インストールディレクトリーで Terraform バイナリーを実行するために必要です。 - 空のディレクトリーを使用します。ブートストラップ X.509 証明書などの一部のインストールアセットは有効期限が短いため、インストールディレクトリーを再利用しないでください。別のクラスターインストールの個別のファイルを再利用する必要がある場合は、それらをディレクトリーにコピーすることができます。ただし、インストールアセットのファイル名はリリース間で変更される可能性があります。インストールファイルを以前のバージョンの OpenShift Container Platform からコピーする場合は注意してコピーを行ってください。
プロンプト時に、クラウドの設定の詳細情報を指定します。
オプション: クラスターマシンにアクセスするために使用する SSH キーを選択します。
注記インストールのデバッグまたは障害復旧を実行する必要のある実稼働用の OpenShift Container Platform クラスターでは、
ssh-agent
プロセスが使用する SSH キーを指定します。- ターゲットとするプラットフォームとして alibabacloud を選択します。
- クラスターをデプロイするリージョンを選択します。
- クラスターをデプロイするベースドメインを選択します。ベースドメインは、クラスターに作成したパブリック DNS ゾーンに対応します。
- クラスターの記述名を指定します。
クラスターを Alibaba Cloud にインストールするには、Cloud Credential Operator (CCO) が手動モードで動作する必要があります。
install-config.yaml
ファイルを変更して、credentialsMode
パラメーターをManual
に設定します。credentialsMode
がManual
に設定された install-config.yaml 設定ファイルの例Copy to Clipboard Copied! Toggle word wrap Toggle overflow apiVersion: v1 baseDomain: cluster1.example.com credentialsMode: Manual compute: - architecture: amd64 hyperthreading: Enabled ...
apiVersion: v1 baseDomain: cluster1.example.com credentialsMode: Manual
1 compute: - architecture: amd64 hyperthreading: Enabled ...
- 1
- この行を追加して、
credentialsMode
をManual
に設定します。
-
install-config.yaml
ファイルを変更します。利用可能なパラメーターの詳細は、「インストール設定パラメーター」のセクションを参照してください。 install-config.yaml
ファイルをバックアップし、複数のクラスターをインストールするのに使用できるようにします。重要install-config.yaml
ファイルはインストールプロセス時に使用されます。このファイルを再利用する必要がある場合は、この段階でこれをバックアップしてください。
3.6.5.2. Alibaba Cloud 用にカスタマイズされた install-config.yaml ファイルのサンプル
インストール設定ファイル (install-config.yaml
) をカスタマイズして、クラスターのプラットフォームに関する詳細を指定したり、必要なパラメーターの値を変更したりできます。
apiVersion: v1 baseDomain: alicloud-dev.devcluster.openshift.com credentialsMode: Manual compute: - architecture: amd64 hyperthreading: Enabled name: worker platform: {} replicas: 3 controlPlane: architecture: amd64 hyperthreading: Enabled name: master platform: {} replicas: 3 metadata: creationTimestamp: null name: test-cluster networking: clusterNetwork: - cidr: 10.128.0.0/14 hostPrefix: 23 machineNetwork: - cidr: 10.0.0.0/16 networkType: OVNKubernetes serviceNetwork: - 172.30.0.0/16 platform: alibabacloud: defaultMachinePlatform: instanceType: ecs.g6.xlarge systemDiskCategory: cloud_efficiency systemDiskSize: 200 region: ap-southeast-1 resourceGroupID: rg-acfnw6j3hyai vpcID: vpc-0xifdjerdibmaqvtjob2b vswitchIDs: - vsw-0xi8ycgwc8wv5rhviwdq5 - vsw-0xiy6v3z2tedv009b4pz2 publish: External pullSecret: '{"auths": {"cloud.openshift.com": {"auth": ... }' sshKey: | ssh-rsa AAAA...
apiVersion: v1
baseDomain: alicloud-dev.devcluster.openshift.com
credentialsMode: Manual
compute:
- architecture: amd64
hyperthreading: Enabled
name: worker
platform: {}
replicas: 3
controlPlane:
architecture: amd64
hyperthreading: Enabled
name: master
platform: {}
replicas: 3
metadata:
creationTimestamp: null
name: test-cluster
networking:
clusterNetwork:
- cidr: 10.128.0.0/14
hostPrefix: 23
machineNetwork:
- cidr: 10.0.0.0/16
networkType: OVNKubernetes
serviceNetwork:
- 172.30.0.0/16
platform:
alibabacloud:
defaultMachinePlatform:
instanceType: ecs.g6.xlarge
systemDiskCategory: cloud_efficiency
systemDiskSize: 200
region: ap-southeast-1
resourceGroupID: rg-acfnw6j3hyai
vpcID: vpc-0xifdjerdibmaqvtjob2b
vswitchIDs:
- vsw-0xi8ycgwc8wv5rhviwdq5
- vsw-0xiy6v3z2tedv009b4pz2
publish: External
pullSecret: '{"auths": {"cloud.openshift.com": {"auth": ... }'
sshKey: |
ssh-rsa AAAA...
- 1
- 必須。インストールプログラムにより、クラスター名の入力を求められます。
- 2
- インストールするクラスターネットワークプラグイン。サポートされる値はデフォルト値の
OVNKubernetes
のみです。 - 3
- オプション: 独自のプラットフォーム設定を定義しないマシンプールのパラメーターを指定します。
- 4
- 必須。インストールプログラムにより、クラスターをデプロイするリージョンの入力を求められます。
- 5
- オプション。クラスターをインストールする必要がある既存のリソースグループを指定します。
- 8
- 必須。インストールプログラムは、プルシークレットの入力を求めます。
- 9
- オプション。インストールプログラムは、クラスター内のマシンへのアクセスに使用する SSH キー値の入力を求めます。
- 6 7
- オプション。これらは vswitchID 値の例です。
3.6.5.3. 必要なインストールマニフェストの生成
クラスターがマシンを設定するために必要な Kubernetes マニフェストと Ignition 設定ファイルを生成する必要があります。
手順
インストールプログラムが含まれているディレクトリーから次のコマンドを実行して、マニフェストを生成します。
Copy to Clipboard Copied! Toggle word wrap Toggle overflow openshift-install create manifests --dir <installation_directory>
$ openshift-install create manifests --dir <installation_directory>
ここで、
<installation_directory>
- インストールプログラムがファイルを作成するディレクトリーを指定します。
3.6.5.4. Cloud Credential Operator ユーティリティーの設定
Cloud Credential Operator (CCO) が手動モードで動作しているときにクラスターの外部からクラウドクレデンシャルを作成および管理するには、CCO ユーティリティー (ccoctl
) バイナリーを抽出して準備します。
ccoctl
ユーティリティーは、Linux 環境で実行する必要がある Linux バイナリーです。
前提条件
- クラスター管理者のアクセスを持つ OpenShift Container Platform アカウントを使用できる。
-
OpenShift CLI (
oc
) がインストールされている。
手順
次のコマンドを実行して、OpenShift Container Platform リリースイメージの変数を設定します。
Copy to Clipboard Copied! Toggle word wrap Toggle overflow RELEASE_IMAGE=$(./openshift-install version | awk '/release image/ {print $3}')
$ RELEASE_IMAGE=$(./openshift-install version | awk '/release image/ {print $3}')
以下のコマンドを実行して、OpenShift Container Platform リリースイメージから CCO コンテナーイメージを取得します。
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 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)
注記$RELEASE_IMAGE
のアーキテクチャーが、ccoctl
ツールを使用する環境のアーキテクチャーと一致していることを確認してください。以下のコマンドを実行して、OpenShift Container Platform リリースイメージ内の CCO コンテナーイメージから
ccoctl
バイナリーを抽出します。Copy to Clipboard Copied! Toggle word wrap Toggle overflow oc image extract $CCO_IMAGE --file="/usr/bin/ccoctl" -a ~/.pull-secret
$ oc image extract $CCO_IMAGE --file="/usr/bin/ccoctl" -a ~/.pull-secret
次のコマンドを実行して、権限を変更して
ccoctl
を実行可能にします。Copy to Clipboard Copied! Toggle word wrap Toggle overflow chmod 775 ccoctl
$ chmod 775 ccoctl
検証
ccoctl
が使用できることを確認するには、help ファイルを表示します。コマンドを実行するときは、相対ファイル名を使用します。以下に例を示します。Copy to Clipboard Copied! Toggle word wrap Toggle overflow ./ccoctl.rhel9
$ ./ccoctl.rhel9
出力例
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 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.
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.
3.6.5.5. ccoctl ツールを使用した OpenShift Container Platform コンポーネントのクレデンシャルの作成
OpenShift Container Platform Cloud Credential Operator (CCO) ユーティリティーを使用して、Alibaba Cloud RAM ユーザーとクラスター内コンポーネントごとのポリシーの作成を自動化できます。
デフォルトで、ccoctl
はコマンドが実行されるディレクトリーにオブジェクトを作成します。オブジェクトを別のディレクトリーに作成するには、--output-dir
フラグを使用します。この手順では、<path_to_ccoctl_output_dir>
を使用してこの場所を参照します。
前提条件
以下が必要になります。
-
ccoctl
バイナリーを抽出して準備している。 - OpenShift Container Platform クラスターを作成するための十分な権限を持つ RAM ユーザーを作成している。
-
その RAM ユーザーの AccessKeyID (
access_key_id
) と AccessKeySecret (access_key_secret
) をローカルコンピューターの~/.alibabacloud/credentials
ファイル に追加しました。
手順
次のコマンドを実行して、インストールファイルのリリースイメージを
$RELEASE_IMAGE
変数に設定します。Copy to Clipboard Copied! Toggle word wrap Toggle overflow RELEASE_IMAGE=$(./openshift-install version | awk '/release image/ {print $3}')
$ RELEASE_IMAGE=$(./openshift-install version | awk '/release image/ {print $3}')
以下のコマンドを実行して、OpenShift Container Platform リリースイメージから
CredentialsRequest
オブジェクトのリストを抽出します。Copy to Clipboard Copied! Toggle word wrap Toggle overflow oc adm release extract \ --from=$RELEASE_IMAGE \ --credentials-requests \ --included \ --install-config=<path_to_directory_with_installation_configuration>/install-config.yaml \ --to=<path_to_directory_for_credentials_requests>
$ 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
オブジェクトをすべて処理します。ツールを使用するには、次のコマンドを実行します。
Copy to Clipboard Copied! Toggle word wrap Toggle overflow ccoctl alibabacloud create-ram-users \ --name <name> \ --region=<alibaba_region> \ --credentials-requests-dir=<path_to_credentials_requests_directory> \ --output-dir=<path_to_ccoctl_output_dir>
$ ccoctl alibabacloud create-ram-users \ --name <name> \
1 --region=<alibaba_region> \
2 --credentials-requests-dir=<path_to_credentials_requests_directory> \
3 --output-dir=<path_to_ccoctl_output_dir>
4 注記クラスターで
TechPreviewNoUpgrade
機能セットによって有効化されたテクノロジープレビュー機能を使用している場合は、--enable-tech-preview
パラメーターを含める必要があります。出力例
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 2022/02/11 16:18:26 Created RAM User: user1-alicloud-openshift-machine-api-alibabacloud-credentials 2022/02/11 16:18:27 Ready for creating new ram policy user1-alicloud-openshift-machine-api-alibabacloud-credentials-policy-policy 2022/02/11 16:18:27 RAM policy user1-alicloud-openshift-machine-api-alibabacloud-credentials-policy-policy has created 2022/02/11 16:18:28 Policy user1-alicloud-openshift-machine-api-alibabacloud-credentials-policy-policy has attached on user user1-alicloud-openshift-machine-api-alibabacloud-credentials 2022/02/11 16:18:29 Created access keys for RAM User: user1-alicloud-openshift-machine-api-alibabacloud-credentials 2022/02/11 16:18:29 Saved credentials configuration to: user1-alicloud/manifests/openshift-machine-api-alibabacloud-credentials-credentials.yaml ...
2022/02/11 16:18:26 Created RAM User: user1-alicloud-openshift-machine-api-alibabacloud-credentials 2022/02/11 16:18:27 Ready for creating new ram policy user1-alicloud-openshift-machine-api-alibabacloud-credentials-policy-policy 2022/02/11 16:18:27 RAM policy user1-alicloud-openshift-machine-api-alibabacloud-credentials-policy-policy has created 2022/02/11 16:18:28 Policy user1-alicloud-openshift-machine-api-alibabacloud-credentials-policy-policy has attached on user user1-alicloud-openshift-machine-api-alibabacloud-credentials 2022/02/11 16:18:29 Created access keys for RAM User: user1-alicloud-openshift-machine-api-alibabacloud-credentials 2022/02/11 16:18:29 Saved credentials configuration to: user1-alicloud/manifests/openshift-machine-api-alibabacloud-credentials-credentials.yaml ...
注記RAM ユーザーは、同時に最大 2 つの AccessKey を持つことができます。
ccoctl alibabacloud create-ram-users
を 3 回以上実行すると、以前に生成されたマニフェストシークレットが古くなり、新しく生成されたシークレットを再適用する必要があります。OpenShift Container Platform シークレットが作成されていることを確認します。
Copy to Clipboard Copied! Toggle word wrap Toggle overflow ls <path_to_ccoctl_output_dir>/manifests
$ ls <path_to_ccoctl_output_dir>/manifests
出力例
Copy to Clipboard Copied! Toggle word wrap Toggle overflow openshift-cluster-csi-drivers-alibaba-disk-credentials-credentials.yaml openshift-image-registry-installer-cloud-credentials-credentials.yaml openshift-ingress-operator-cloud-credentials-credentials.yaml openshift-machine-api-alibabacloud-credentials-credentials.yaml
openshift-cluster-csi-drivers-alibaba-disk-credentials-credentials.yaml openshift-image-registry-installer-cloud-credentials-credentials.yaml openshift-ingress-operator-cloud-credentials-credentials.yaml openshift-machine-api-alibabacloud-credentials-credentials.yaml
RAM ユーザーとポリシーが Alibaba Cloud にクエリーを実行して作成されていることを確認できます。詳細については、RAM ユーザーとポリシーのリスト表示に関する Alibaba Cloud のドキュメントを参照してください。
生成されたクレデンシャルファイルをターゲットマニフェストディレクトリーにコピーします。
Copy to Clipboard Copied! Toggle word wrap Toggle overflow cp ./<path_to_ccoctl_output_dir>/manifests/*credentials.yaml ./<path_to_installation>dir>/manifests/
$ cp ./<path_to_ccoctl_output_dir>/manifests/*credentials.yaml ./<path_to_installation>dir>/manifests/
ここで、
<path_to_ccoctl_output_dir>
-
ccoctl alibabacloud create-ram-users
コマンドによって作成されるディレクトリーを指定します。 <path_to_installation_dir>
- インストールプログラムがファイルを作成するディレクトリーを指定します。
3.6.6. クラスターのデプロイ
互換性のあるクラウドプラットフォームに OpenShift Container Platform をインストールできます。
インストールプログラムの create cluster
コマンドは、初期インストール時に 1 回だけ実行できます。
前提条件
- クラスターをホストするクラウドプラットフォームでアカウントを設定しました。
- OpenShift Container Platform インストールプログラムおよびクラスターのプルシークレットがある。
- ホスト上のクラウドプロバイダーアカウントに、クラスターをデプロイするための適切な権限があることが確認されました。アカウントの権限が正しくないと、インストールプロセスが失敗し、不足している権限を示すエラーメッセージが表示されます。
手順
インストールプログラムが含まれるディレクトリーに切り替え、クラスターのデプロイメントを初期化します。
Copy to Clipboard Copied! Toggle word wrap Toggle overflow ./openshift-install create cluster --dir <installation_directory> \ --log-level=info
$ ./openshift-install create cluster --dir <installation_directory> \
1 --log-level=info
2
検証
クラスターのデプロイが正常に完了すると、次のようになります。
-
ターミナルには、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
...
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.6.7. バイナリーのダウンロードによる OpenShift CLI のインストール
コマンドラインインターフェイスを使用して OpenShift Container Platform と対話するために CLI (oc
) をインストールすることができます。oc
は Linux、Windows、または macOS にインストールできます。
以前のバージョンの oc
をインストールしている場合、これを使用して OpenShift Container Platform 4.15 のすべてのコマンドを実行することはできません。新規バージョンの oc
をダウンロードし、インストールします。
Linux への OpenShift CLI のインストール
以下の手順を使用して、OpenShift CLI (oc
) バイナリーを Linux にインストールできます。
手順
- Red Hat カスタマーポータルの OpenShift Container Platform ダウンロードページ に移動します。
- Product Variant ドロップダウンリストからアーキテクチャーを選択します。
- バージョン ドロップダウンリストから適切なバージョンを選択します。
- OpenShift v4.15 Linux Client エントリーの横にある Download Now をクリックして、ファイルを保存します。
アーカイブを展開します。
Copy to Clipboard Copied! Toggle word wrap Toggle overflow tar xvf <file>
$ tar xvf <file>
oc
バイナリーを、PATH
にあるディレクトリーに配置します。PATH
を確認するには、以下のコマンドを実行します。Copy to Clipboard Copied! Toggle word wrap Toggle overflow echo $PATH
$ echo $PATH
検証
OpenShift CLI のインストール後に、
oc
コマンドを使用して利用できます。Copy to Clipboard Copied! Toggle word wrap Toggle overflow oc <command>
$ oc <command>
Windows への OpenShift CLI のインストール
以下の手順を使用して、OpenShift CLI (oc
) バイナリーを Windows にインストールできます。
手順
- Red Hat カスタマーポータルの OpenShift Container Platform ダウンロードページ に移動します。
- バージョン ドロップダウンリストから適切なバージョンを選択します。
- OpenShift v4.15 Windows Client エントリーの横にある Download Now をクリックして、ファイルを保存します。
- ZIP プログラムでアーカイブを展開します。
oc
バイナリーを、PATH
にあるディレクトリーに移動します。PATH
を確認するには、コマンドプロンプトを開いて以下のコマンドを実行します。Copy to Clipboard Copied! Toggle word wrap Toggle overflow path
C:\> path
検証
OpenShift CLI のインストール後に、
oc
コマンドを使用して利用できます。Copy to Clipboard Copied! Toggle word wrap Toggle overflow oc <command>
C:\> oc <command>
macOS への OpenShift CLI のインストール
以下の手順を使用して、OpenShift CLI (oc
) バイナリーを macOS にインストールできます。
手順
- Red Hat カスタマーポータルの OpenShift Container Platform ダウンロードページ に移動します。
- バージョン ドロップダウンリストから適切なバージョンを選択します。
OpenShift v4.15 macOS Client エントリーの横にある Download Now をクリックして、ファイルを保存します。
注記macOS arm64 の場合は、OpenShift v4.15 macOS arm64 Client エントリーを選択します。
- アーカイブを展開し、解凍します。
oc
バイナリーをパスにあるディレクトリーに移動します。PATH
を確認するには、ターミナルを開き、以下のコマンドを実行します。Copy to Clipboard Copied! Toggle word wrap Toggle overflow echo $PATH
$ echo $PATH
検証
oc
コマンドを使用してインストールを確認します。Copy to Clipboard Copied! Toggle word wrap Toggle overflow oc <command>
$ oc <command>
3.6.8. CLI の使用によるクラスターへのログイン
クラスター kubeconfig
ファイルをエクスポートし、デフォルトシステムユーザーとしてクラスターにログインできます。kubeconfig
ファイルには、クライアントを正しいクラスターおよび API サーバーに接続するために CLI で使用されるクラスターに関する情報が含まれます。このファイルはクラスターに固有のファイルであり、OpenShift Container Platform のインストール時に作成されます。
前提条件
- OpenShift Container Platform クラスターをデプロイしていること。
-
oc
CLI をインストールしていること。
手順
kubeadmin
認証情報をエクスポートします。Copy to Clipboard Copied! Toggle word wrap Toggle overflow export KUBECONFIG=<installation_directory>/auth/kubeconfig
$ export KUBECONFIG=<installation_directory>/auth/kubeconfig
1 - 1
<installation_directory>
には、インストールファイルを保存したディレクトリーへのパスを指定します。
エクスポートされた設定を使用して、
oc
コマンドを正常に実行できることを確認します。Copy to Clipboard Copied! Toggle word wrap Toggle overflow oc whoami
$ oc whoami
出力例
Copy to Clipboard Copied! Toggle word wrap Toggle overflow system:admin
system:admin
3.6.9. Web コンソールを使用したクラスターへのログイン
kubeadmin
ユーザーは、OpenShift Container Platform のインストール後はデフォルトで存在します。OpenShift Container Platform Web コンソールを使用し、kubeadmin
ユーザーとしてクラスターにログインできます。
前提条件
- インストールホストにアクセスできる。
- クラスターのインストールを完了しており、すべてのクラスター Operator が利用可能である。
手順
インストールホストで
kubeadmin-password
ファイルからkubeadmin
ユーザーのパスワードを取得します。Copy to Clipboard Copied! Toggle word wrap Toggle overflow cat <installation_directory>/auth/kubeadmin-password
$ cat <installation_directory>/auth/kubeadmin-password
注記または、インストールホストで
<installation_directory>/.openshift_install.log
ログファイルからkubeadmin
パスワードを取得できます。OpenShift Container Platform Web コンソールルートをリスト表示します。
Copy to Clipboard Copied! Toggle word wrap Toggle overflow oc get routes -n openshift-console | grep 'console-openshift'
$ oc get routes -n openshift-console | grep 'console-openshift'
注記または、インストールホストで
<installation_directory>/.openshift_install.log
ログファイルからで OpenShift Container Platform ルートを取得できます。出力例
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 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 None
-
Web ブラウザーで前述のコマンドの出力で詳細に説明されたルートに移動し、
kubeadmin
ユーザーとしてログインします。
3.6.10. OpenShift Container Platform の Telemetry アクセス
OpenShift Container Platform 4.15 では、クラスターの健全性および正常に実行された更新についてのメトリクスを提供するためにデフォルトで実行される Telemetry サービスにも、インターネットアクセスが必要です。クラスターがインターネットに接続されている場合、Telemetry は自動的に実行され、クラスターは OpenShift Cluster Manager に登録されます。
OpenShift Cluster Manager インベントリーが正常である (Telemetry によって自動的に維持、または OpenShift Cluster Manager を使用して手動で維持) ことを確認した後に、subscription watch を使用 して、アカウントまたはマルチクラスターレベルで OpenShift Container Platform サブスクリプションを追跡します。
関連情報
- Telemetry サービスの詳細は、リモートヘルスモニタリング を参照してください。
- OpenShift Container Platform Web コンソールへのアクセスと理解の詳細については、Web コンソールへのアクセス を参照してください。
3.6.11. 次のステップ
- インストールを検証 します。
- クラスターをカスタマイズ します。
- 必要に応じて、リモートヘルスレポートをオプトアウト できます。
3.7. Alibaba Cloud のインストール設定パラメーター
Alibaba Cloud に OpenShift Container Platform クラスターをデプロイする前に、クラスターとそれをホストするプラットフォームをカスタマイズするパラメーターを指定します。install-config.yaml
ファイルを作成するときは、コマンドラインを使用して必要なパラメーターの値を指定します。その後、install-config.yaml
ファイルを変更して、クラスターをさらにカスタマイズできます。
3.7.1. Alibaba Cloud で利用可能なインストール設定パラメーター
次の表では、インストールプロセスの一部として設定できる、必須、オプション、および Alibaba Cloud 固有のインストール設定パラメーターを指定します。
インストール後は、これらのパラメーターを install-config.yaml
ファイルで変更することはできません。
3.7.1.1. 必須設定パラメーター
必須のインストール設定パラメーターは、以下の表で説明されています。
パラメーター | 説明 | 値 |
---|---|---|
apiVersion:
|
| 文字列 |
baseDomain:
|
クラウドプロバイダーのベースドメイン。ベースドメインは、OpenShift Container Platform クラスターコンポーネントへのルートを作成するために使用されます。クラスターの完全な DNS 名は、 |
|
metadata:
|
Kubernetes リソース | オブジェクト |
metadata: name:
|
クラスターの名前。クラスターの DNS レコードはすべて |
|
platform:
|
インストールを実行する特定のプラットフォームの設定: | オブジェクト |
pullSecret:
| Red Hat OpenShift Cluster Manager からプルシークレット を取得して、Quay.io などのサービスから OpenShift Container Platform コンポーネントのコンテナーイメージをダウンロードすることを認証します。 |
{ "auths":{ "cloud.openshift.com":{ "auth":"b3Blb=", "email":"you@example.com" }, "quay.io":{ "auth":"b3Blb=", "email":"you@example.com" } } }
|
3.7.1.2. ネットワーク設定パラメーター
既存のネットワークインフラストラクチャーの要件に基づいて、インストール設定をカスタマイズできます。たとえば、クラスターネットワークの IP アドレスブロックを拡張するか、デフォルトとは異なる IP アドレスブロックを指定できます。
IPv4 アドレスのみがサポートされます。
Globalnet は、Red Hat OpenShift Data Foundation ディザスターリカバリーソリューションではサポートされていません。局地的なディザスターリカバリーのシナリオでは、各クラスター内のクラスターとサービスネットワークに重複しない範囲のプライベート IP アドレスを使用するようにしてください。
パラメーター | 説明 | 値 |
---|---|---|
networking:
| クラスターのネットワークの設定。 | オブジェクト 注記
インストール後に |
networking: networkType:
| インストールする Red Hat OpenShift Networking ネットワークプラグイン。 |
|
networking: clusterNetwork:
| Pod の IP アドレスブロック。
デフォルト値は 複数の IP アドレスブロックを指定する場合は、ブロックが重複しないようにしてください。 | オブジェクトの配列。以下に例を示します。 networking: clusterNetwork: - cidr: 10.128.0.0/14 hostPrefix: 23
|
networking: clusterNetwork: cidr:
|
IPv4 ネットワーク |
CIDR (Classless Inter-Domain Routing) 表記の IP アドレスブロック。IPv4 ブロックの接頭辞長は |
networking: clusterNetwork: hostPrefix:
|
それぞれの個別ノードに割り当てるサブネット接頭辞長。たとえば、 | サブネット接頭辞。
デフォルト値は |
networking: serviceNetwork:
|
サービスの IP アドレスブロック。デフォルト値は OVN-Kubernetes ネットワークプラグインは、サービスネットワークに対して単一の IP アドレスブロックのみをサポートします。 | CIDR 形式の IP アドレスブロックを持つ配列。以下に例を示します。 networking: serviceNetwork: - 172.30.0.0/16
|
networking: machineNetwork:
| マシンの IP アドレスブロック。 複数の IP アドレスブロックを指定する場合は、ブロックが重複しないようにしてください。 | オブジェクトの配列。以下に例を示します。 networking: machineNetwork: - cidr: 10.0.0.0/16
|
networking: machineNetwork: cidr:
|
| CIDR 表記の IP ネットワークブロック。
例: 注記
優先される NIC が置かれている CIDR に一致する |
3.7.1.3. オプションの設定パラメーター
オプションのインストール設定パラメーターは、以下の表で説明されています。
パラメーター | 説明 | 値 |
---|---|---|
additionalTrustBundle:
| ノードの信頼済み証明書ストアに追加される PEM でエンコードされた X.509 証明書バンドル。この信頼バンドルは、プロキシーが設定される際にも使用できます。 | 文字列 |
capabilities:
| オプションのコアクラスターコンポーネントのインストールを制御します。オプションのコンポーネントを無効にすることで、OpenShift Container Platform クラスターのフットプリントを削減できます。詳細は、インストール の「クラスター機能ページ」を参照してください。 | 文字列配列 |
capabilities: baselineCapabilitySet:
|
有効にするオプション機能の初期セットを選択します。有効な値は | 文字列 |
capabilities: additionalEnabledCapabilities:
|
オプションの機能のセットを、 | 文字列配列 |
cpuPartitioningMode:
| ワークロードパーティション設定を使用して、OpenShift Container Platform サービス、クラスター管理ワークロード、およびインフラストラクチャー Pod を分離し、予約された CPU セットで実行できます。ワークロードパーティショニングはインストール中にのみ有効にすることができ、インストール後に無効にすることはできません。このフィールドはワークロードのパーティショニングを有効にしますが、特定の CPU を使用するようにワークロードを設定するわけではありません。詳細は、スケーラビリティとパフォーマンス セクションの ワークロードパーティショニング ページを参照してください。 |
|
compute:
| コンピュートノードを構成するマシンの設定。 |
|
compute: architecture:
|
プール内のマシンの命令セットアーキテクチャーを決定します。現在、さまざまなアーキテクチャーのクラスターはサポートされていません。すべてのプールは同じアーキテクチャーを指定する必要があります。有効な値は | 文字列 |
compute: hyperthreading:
|
コンピュートマシンで同時マルチスレッドまたは 重要 同時スレッドを無効にする場合は、容量計画においてマシンパフォーマンスの大幅な低下が考慮に入れられていることを確認します。 |
|
compute: name:
|
|
|
compute: platform:
|
|
|
compute: replicas:
| プロビジョニングするコンピュートマシン (ワーカーマシンとしても知られる) の数。 |
|
featureSet:
| 機能セットのクラスターを有効にします。機能セットは、デフォルトで有効にされない OpenShift Container Platform 機能のコレクションです。インストール中に機能セットを有効にする方法の詳細は、「機能ゲートの使用による各種機能の有効化」を参照してください。 |
文字列。 |
controlPlane:
| コントロールプレーンを構成するマシンの設定。 |
|
controlPlane: architecture:
|
プール内のマシンの命令セットアーキテクチャーを決定します。現在、さまざまなアーキテクチャーのクラスターはサポートされていません。すべてのプールは同じアーキテクチャーを指定する必要があります。有効な値は | 文字列 |
controlPlane: hyperthreading:
|
コントロールプレーンマシンで同時マルチスレッドまたは 重要 同時スレッドを無効にする場合は、容量計画においてマシンパフォーマンスの大幅な低下が考慮に入れられていることを確認します。 |
|
controlPlane: name:
|
|
|
controlPlane: platform:
|
|
|
controlPlane: replicas:
| プロビジョニングするコントロールプレーンマシンの数。 |
サポートされる値は |
credentialsMode:
| Cloud Credential Operator (CCO) モード。モードを指定しないと、CCO は指定された認証情報の機能を動的に判別しようとします。この場合、複数のモードがサポートされるプラットフォームで Mint モードが優先されます。 |
|
fips:
|
FIPS モードを有効または無効にします。デフォルトは 重要 クラスターで FIPS モードを有効にするには、FIPS モードで動作するように設定された Red Hat Enterprise Linux (RHEL) コンピューターからインストールプログラムを実行する必要があります。RHEL での FIPS モードの設定の詳細は、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 暗号化ライブラリーを使用します。 注記 Azure File ストレージを使用している場合、FIPS モードを有効にすることはできません。 |
|
imageContentSources:
| release-image コンテンツのソースおよびリポジトリー。 |
オブジェクトの配列。この表の以下の行で説明されているように、 |
imageContentSources: source:
|
| 文字列 |
imageContentSources: mirrors:
| 同じイメージが含まれる可能性のあるリポジトリーを 1 つ以上指定します。 | 文字列の配列。 |
publish:
| Kubernetes API、OpenShift ルートなどのクラスターのユーザーに表示されるエンドポイントをパブリッシュまたは公開する方法。 |
このパラメーターを 重要
フィールドの値が |
sshKey:
| クラスターマシンへのアクセスを認証するための SSH キー。 注記
インストールのデバッグまたは障害復旧を実行する必要のある実稼働用の OpenShift Container Platform クラスターでは、 |
たとえば、 |
- すべてのクラウドプロバイダーですべての CCO モードがサポートされているわけではありません。CCO モードの詳細は、認証と認可 コンテンツの「クラウドプロバイダーの認証情報の管理」を参照してください。
3.7.1.4. 追加の Alibaba Cloud 設定パラメーター
Alibaba Cloud の追加の設定パラメーターは、以下の表で説明されています。alibabacloud
パラメーターは、Alibaba Cloud にインストールするときに使用される設定です。defaultMachinePlatform
パラメーターは、独自のプラットフォーム設定を定義しないマシンプール用に Alibaba Cloud にインストールするときに使用されるデフォルト設定です。
これらのパラメーターは、指定されているコンピュートマシンとコントロールプレーンマシンの両方に適用されます。
定義されている場合、パラメーターcompute.platform.alibabacloud
および controlPlane.platform.alibabacloud
は、コンピュートマシンおよびコントロールプレーンマシンの platform.alibabacloud.defaultMachinePlatform
設定をそれぞれ上書きします。
パラメーター | 説明 | 値 |
---|---|---|
compute: platform: alibabacloud: imageID:
| ECS インスタンスの作成に使用される imageID。ImageID はクラスターと同じリージョンに属している必要があります。 | 文字列。 |
compute: platform: alibabacloud: instanceType:
|
InstanceType は、ECS インスタンスタイプを定義します。例: | 文字列。 |
compute: platform: alibabacloud: systemDiskCategory:
|
システムディスクのカテゴリーを定義します。例: | 文字列。 |
compute: platform: alibabacloud: systemDisksize:
| システムディスクのサイズをギビバイト (GiB) 単位で定義します。 | integer |
compute: platform: alibabacloud: zones:
|
使用できるアベイラビリティーゾーンのリスト。例: | 文字列リスト。 |
controlPlane: platform: alibabacloud: imageID:
| ECS インスタンスの作成に使用される imageID。ImageID はクラスターと同じリージョンに属している必要があります。 | 文字列。 |
controlPlane: platform: alibabacloud: instanceType:
|
InstanceType は、ECS インスタンスタイプを定義します。例: | 文字列。 |
controlPlane: platform: alibabacloud: systemDiskCategory:
|
システムディスクのカテゴリーを定義します。例: | 文字列。 |
controlPlane: platform: alibabacloud: systemDisksize:
| システムディスクのサイズをギビバイト (GiB) 単位で定義します。 | integer |
controlPlane: platform: alibabacloud: zones:
|
使用できるアベイラビリティーゾーンのリスト。例: | 文字列リスト。 |
platform: alibabacloud: region:
| 必須。クラスターが作成される Alibaba Cloud リージョン。 | 文字列。 |
platform: alibabacloud: resourceGroupID:
| クラスターがインストールされる既存のリソースグループの ID。空の場合、インストールプログラムはクラスターの新しいリソースグループを作成します。 | 文字列。 |
platform: alibabacloud: tags:
| クラスター用に作成されたすべての Alibaba Cloud リソースに適用する追加のキーと値。 | オブジェクト。 |
platform: alibabacloud: vpcID:
| クラスターをインストールする必要がある既存の VPC の ID。空の場合、インストールプログラムはクラスターの新規 VPC を作成します。 | 文字列。 |
platform: alibabacloud: vswitchIDs:
| クラスターリソースが作成される既存の VSwitch の ID リスト。既存の VSwitch は、既存の VPC も使用している場合にのみ使用できます。空の場合、インストールプログラムはクラスターの新しい VSwitch を作成します。 | 文字列リスト。 |
platform: alibabacloud: defaultMachinePlatform: imageID:
| コンピュートマシンとコントロールプレーンマシンの両方で、ECS インスタンスの作成に使用する必要があるイメージ ID。設定されている場合、イメージ ID はクラスターと同じリージョンに属している必要があります。 | 文字列。 |
platform: alibabacloud: defaultMachinePlatform: instanceType:
|
コンピュートマシンとコントロールプレーンマシンの両方で、ECS インスタンスの作成に使用される ECS インスタンスタイプ。例: | 文字列。 |
platform: alibabacloud: defaultMachinePlatform: systemDiskCategory:
|
コンピュートマシンとコントロールプレーンマシンの両方におけるシステムディスクのカテゴリー。例: |
文字列、たとえば ""、 |
platform: alibabacloud: defaultMachinePlatform: systemDiskSize:
|
コンピュートマシンとコントロールプレーンマシンの両方で、ギビバイト (GiB) 単位のシステムディスクのサイズ。最小値は | integer |
platform: alibabacloud: defaultMachinePlatform: zones:
|
コンピュートマシンとコントロールプレーンマシンの両方で、使用可能なアベイラビリティーゾーンのリスト。例: | 文字列リスト。 |
platform: alibabacloud: privateZoneID:
| クラスターの内部 API の DNS レコードを追加する既存のプライベートゾーンの ID。既存のプライベートゾーンは、既存の VPC も使用している場合にのみ使用できます。プライベートゾーンは、サブネットを含む VPC に関連付ける必要があります。プライベートゾーンを未設定のままにして、インストールプログラムがプライベートゾーンを作成するようにします。 | 文字列。 |
3.8. Alibaba Cloud でのクラスターのアンインストール
Alibaba Cloud にデプロイしたクラスターを削除できます。
3.8.1. インストーラーでプロビジョニングされるインフラストラクチャーを使用するクラスターの削除
installer-provisioned infrastructure を使用するクラスターは、クラウドから削除できます。
アンインストール後に、とくに user-provisioned infrastructure (UPI) クラスターで適切に削除されていないリソースがあるかどうかについて、クラウドプロバイダーを確認します。インストーラーが作成されなかったり、インストーラーがアクセスできない場合には、リソースがある可能性があります。
前提条件
- クラスターをデプロイするために使用したインストールプログラムのコピーがあります。
- クラスター作成時にインストールプログラムが生成したファイルがあります。
手順
クラスターをインストールするために使用したコンピューターのインストールプログラムが含まれるディレクトリーから、以下のコマンドを実行します。
Copy to Clipboard Copied! Toggle word wrap Toggle overflow ./openshift-install destroy cluster \ --dir <installation_directory> --log-level info
$ ./openshift-install destroy cluster \ --dir <installation_directory> --log-level info
1 2 注記クラスターのクラスター定義ファイルが含まれるディレクトリーを指定する必要があります。クラスターを削除するには、インストールプログラムでこのディレクトリーにある
metadata.json
ファイルが必要になります。-
オプション:
<installation_directory>
ディレクトリーおよび OpenShift Container Platform インストールプログラムを削除します。
第4章 AWS へのインストール
4.1. AWS へのインストールの準備
4.1.1. 前提条件
- OpenShift Container Platform のインストールおよび更新 プロセスの詳細を確認した。
- クラスターインストール方法の選択およびそのユーザー向けの準備 を確認している。
4.1.2. OpenShift Container Platform OpenStack の AWS へのインストールについての要件
OpenShift Container Platform を Amazon Web Services (AWS) にインストールする前に、AWS アカウントを作成する必要があります。アカウント、アカウントの制限、アカウントのパーミッション、IAM ユーザーセットアップ、およびサポートされている AWS リージョンの設定についての詳細は、AWS アカウントの設定 を参照してください。
ご使用の環境でクラウド ID およびアクセス管理 (IAM) API にアクセスできない場合、または管理者レベルの認証情報シークレットを kube-system
namespace に保存したくない場合は、AWS の長期認証情報の手動作成、または Amazon Web Services セキュリティートークンサービス (AWS STS) を使用した 短期認証情報を使用するための AWS クラスターの設定 を参照してください。
4.1.3. AWS に OpenShift Container Platform をインストールする方法の選択
OpenShift Container Platform をインストーラーまたはユーザーによってプロビジョニングされるインフラストラクチャーにインストールすることができます。デフォルトのインストールタイプは、installer-provisioned infrastructure を使用します。この場合、インストールプログラムがクラスターの基礎となるインフラストラクチャーをプロビジョニングします。OpenShift Container Platform は、ユーザーがプロビジョニングするインスラストラクチャーにインストールすることもできます。インストールプログラムがプロビジョニングするインフラストラクチャーを使用しない場合は、クラスターリソースをユーザー自身で管理し、維持する必要があります。
installer-provisioned installation および user-provisioned installation のプロセスの詳細は、インストールプロセス を参照してください。
4.1.3.1. 単一ノードへのクラスターのインストール
OpenShift Container Platform を単一ノードにインストールすると、高可用性および大規模なクラスターの一部の要件が軽減されます。ただし、シングルノードにインストールするための要件 と、クラウドプロバイダーにシングルノードの OpenShift をインストールするための追加要件 に対処する必要があります。単一ノードのインストールの要件に対処した後、AWS へのカスタマイズされたクラスターのインストール 手順を使用してクラスターをインストールします。単一ノード OpenShift の手動インストール セクションには、OpenShift Container Platform クラスターを単一ノードにインストールする場合の例示的な install-config.yaml
ファイルが含まれています。
4.1.3.2. インストーラーでプロビジョニングされるインフラストラクチャーへのクラスターのインストール
以下の方法のいずれかを使用して、OpenShift Container Platform インストールプログラムでプロビジョニングされる AWS インフラストラクチャーに、クラスターをインストールできます。
- クラスターの AWS へのクイックインストール: OpenShift Container Platform インストールプログラムでプロビジョニングされる AWS インフラストラクチャーに OpenShift Container Platform をインストールできます。デフォルトの設定オプションを使用して、クラスターを迅速にインストールできます。
- カスタマイズされたクラスターの AWS へのインストール: インストールプログラムがプロビジョニングする AWS インフラストラクチャーにカスタマイズされたクラスターをインストールできます。インストールプログラムは、インストールの段階で一部のカスタマイズを適用できるようにします。その他の多くのカスタマイズオプションは、インストール後 に利用できます。
- ネットワークのカスタマイズを使用したクラスターの AWS へのインストール: インストール時に OpenShift Container Platform ネットワーク設定をカスタマイズすることで、クラスターが既存の IP アドレスの割り当てと共存でき、ネットワーク要件に準拠することができます。
- ネットワークが制限された環境での AWS へのクラスターのインストール: インストールリリースコンテンツの内部ミラーを使用して、installer-provisioned AWS インフラストラクチャーに OpenShift Container Platform をインストールできます。この方法を使用して、ソフトウェアコンポーネントを取得するためにアクティブなインターネット接続を必要としないクラスターをインストールできます。
- クラスターの既存の Virtual Private Cloud へのインストール: OpenShift Container Platform を既存の AWS Virtual Private Cloud (VPC) にインストールできます。このインストール方法は、新規アカウントまたはインフラストラクチャーを作成する際の制限など、会社のガイドラインによる制約がある場合に使用できます。
- プライベートクラスターの既存の VPC へのインストール: プライベートクラスターを既存の AWS VPC にインストールできます。この方法を使用して、インターネット上に表示されない内部ネットワークに OpenShift Container Platform をデプロイすることができます。
- クラスターの AWS の government またはシークレットリージョンへのインストール: OpenShift Container Platform は、機密ワークロードをクラウドで実行する必要のある連邦、州、地方の米国の各種の政府機関、請負業者、教育機関、およびその他の米国の顧客向けに設計されている AWS リージョンにデプロイできます。
4.1.3.3. user-provisioned infrastructure へのクラスターのインストール
以下の方法のいずれかを使用して、独自にプロビジョニングする AWS インフラストラクチャーにクラスターをインストールできます。
- クラスターの各自でプロビジョニングする AWS インフラストラクチャーへのインストール: OpenShift Container Platform を、プロビジョニングする AWS インフラストラクチャーにインストールできます。提供される CloudFormation テンプレートを使用して、OpenShift Container Platform インストールに必要な各コンポーネントを表す AWS リソースのスタックを作成できます。
- user-provisioned infrastructure を使用したネットワークが制限された環境での AWS へのクラスターのインストール: インストールリリースコンテンツの内部ミラーを使用して、独自に提供する AWS インフラストラクチャーに OpenShift Container Platform をインストールできます。この方法を使用して、ソフトウェアコンポーネントを取得するためにアクティブなインターネット接続を必要としないクラスターをインストールできます。また、このインストール方法を使用して、クラスターが外部コンテンツに対する組織の制御の条件を満たすコンテナーイメージのみを使用するようにすることもできます。ミラーリングされたコンテンツを使用して OpenShift Container Platform をインストールすることは可能ですが、クラスターが AWS API を使用するにはインターネットへのアクセスが必要です。
4.1.4. 次のステップ
4.2. AWS アカウントの設定
OpenShift Container Platform をインストールする前に、Amazon Web Services (AWS) アカウントを設定する必要があります。
4.2.1. Route 53 の設定
OpenShift Container Platform をインストールするには、使用する Amazon Web Services (AWS) アカウントに、Route 53 サービスの専用のパブリックホストゾーンが必要になります。このゾーンはドメインに対する権威を持っている必要があります。Route 53 サービスは、クラスターへの外部接続のためのクラスターの DNS 解決および名前検索を提供します。
手順
ドメイン、またはサブドメイン、およびレジストラーを特定します。既存のドメインおよびレジストラーを移行するか、AWS または他のソースから新規のものを取得できます。
注記AWS で新規ドメインを購入する場合、関連する DNS の変更が伝播するのに時間がかかります。AWS 経由でドメインを購入する方法の詳細は、AWS ドキュメントの Registering Domain Names Using Amazon Route 53 を参照してください。
- 既存のドメインおよびレジストラーを使用している場合、その DNS を AWS に移行します。AWS ドキュメントの Making Amazon Route 53 the DNS Service for an Existing Domain を参照してください。
ドメインまたはサブドメインのパブリックホストゾーンを作成します。AWS ドキュメントの Creating a Public Hosted Zone を参照してください。
openshiftcorp.com
などのルートドメインや、clusters.openshiftcorp.com
などのサブドメインを使用します。- ホストゾーンレコードから新規の権威ネームサーバーを抽出します。AWS ドキュメントの Getting the Name Servers for a Public Hosted Zone を参照してください。
- ドメインが使用する AWS Route 53 ネームサーバーのレジストラーレコードを更新します。たとえば、別のアカウントを使用してドメインを Route 53 サービスに登録している場合は、AWS ドキュメントの Adding or Changing Name Servers or Glue Records のトピックを参照してください。
- サブドメインを使用している場合は、その委任レコードを親ドメインに追加します。これにより、サブドメインの Amazon Route 53 の責任が付与されます。親ドメインの DNS プロバイダーによって要約された委任手順に従います。ハイレベルの手順の例については、AWS ドキュメントの Creating a subdomain that uses Amazon Route 53 as the DNS service without migrating the parent domain を参照してください。
4.2.1.1. AWS Route 53 の Ingress Operator エンドポイント設定
Amazon Web Services (AWS) GovCloud (US) US-West または US-East リージョンのいずれかにインストールする場合、Ingress Operator は Route53 およびタグ付けする API クライアントに us-gov-west-1
リージョンを使用します。
Ingress Operator は、タグ付けするエンドポイントが文字列 'us-gov-east-1' を含むように設定される場合、タグ付けする API エンドポイントとして https://tagging.us-gov-west-1.amazonaws.com
を使用します。
AWS GovCloud (US) エンドポイントの詳細は、GovCloud (US) に関する AWS ドキュメントの Service Endpoints を参照してください。
us-gov-east-1
リージョンにインストールする場合、プライベート、非接続インストールは AWS GovCloud ではサポートされません。
Route 53 設定の例
platform: aws: region: us-gov-west-1 serviceEndpoints: - name: ec2 url: https://ec2.us-gov-west-1.amazonaws.com - name: elasticloadbalancing url: https://elasticloadbalancing.us-gov-west-1.amazonaws.com - name: route53 url: https://route53.us-gov.amazonaws.com - name: tagging url: https://tagging.us-gov-west-1.amazonaws.com
platform:
aws:
region: us-gov-west-1
serviceEndpoints:
- name: ec2
url: https://ec2.us-gov-west-1.amazonaws.com
- name: elasticloadbalancing
url: https://elasticloadbalancing.us-gov-west-1.amazonaws.com
- name: route53
url: https://route53.us-gov.amazonaws.com
- name: tagging
url: https://tagging.us-gov-west-1.amazonaws.com
- 1
- Route 53 は、AWS GovCloud (US) リージョンの両方で
https://route53.us-gov.amazonaws.com
にデフォルト設定されます。 - 2
- US-West リージョンのみにタグ付けするためのエンドポイントがあります。クラスターが別のリージョンにある場合は、このパラメーターを省略します。
4.2.2. AWS アカウントの制限
OpenShift Container Platform クラスターは数多くの Amazon Web Services (AWS) コンポーネントを使用し、デフォルトの サービス制限 は、OpenShift Container Platform クラスターをインストールする機能に影響を与えます。特定のクラスター設定を使用し、クラスターを特定の AWS リージョンにデプロイするか、アカウントを使用して複数のクラスターを実行する場合、AWS アカウントの追加リソースを要求することが必要になる場合があります。
以下の表は、OpenShift Container Platform クラスターのインストールおよび実行機能に影響を与える可能性のある AWS コンポーネントの制限を要約しています。
コンポーネント | デフォルトで利用できるクラスターの数 | デフォルトの AWS の制限 | 説明 |
---|---|---|---|
インスタンスの制限 | 変動あり。 | 変動あり。 | デフォルトで、各クラスターは以下のインスタンスを作成します。
これらのインスタンスタイプの数は、新規アカウントのデフォルト制限内の値です。追加のワーカーノードをデプロイし、自動スケーリングを有効にし、大規模なワークロードをデプロイするか、異なるインスタンスタイプを使用するには、アカウントの制限を見直し、クラスターが必要なマシンをデプロイできることを確認します。
ほとんどのリージョンでは、ワーカーマシンは |
Elastic IP (EIP) | 0 - 1 | アカウントごとに 5 つの EIP | クラスターを高可用性設定でプロビジョニングするために、インストールプログラムはそれぞれの リージョン内のアベイラビリティーゾーン にパブリックおよびプライベートのサブネットを作成します。各プライベートサブネットには NAT ゲートウェイ が必要であり、各 NAT ゲートウェイには別個の Elastic IP が必要です。AWS リージョンマップ を確認して、各リージョンにあるアベイラビリティーゾーンの数を判別します。デフォルトの高可用性を利用するには、少なくとも 3 つのアベイラビリティーゾーンがあるリージョンにクラスターをインストールします。アベイラビリティーゾーンが 6 つ以上あるリージョンにクラスターをインストールするには、EIP 制限を引き上げる必要があります。 重要
|
Virtual Private Cloud (VPC) | 5 | リージョンごとに 5 つの VPC | 各クラスターは独自の VPC を作成します。 |
Elastic Load Balancing (ELB/NLB) | 3 | リージョンごとに 20 |
デフォルトで、各クラスターは、マスター API サーバーの内部および外部のネットワークロードバランサーおよびルーターの単一の Classic Load Balancer を作成します。追加の Kubernetes |
NAT ゲートウェイ | 5 | アベイラビリティゾーンごとに 5 つ | クラスターは各アベイラビリティーゾーンに 1 つの NAT ゲートウェイをデプロイします。 |
Elastic Network Interface (ENI) | 12 以上 | リージョンごとに 350 |
デフォルトのインストールは 21 の ENI を作成し、リージョンの各アベイラビリティーゾーンに 1 つの ENI を作成します。たとえば、 クラスターの使用量やデプロイされたワークロード別に作成された追加のマシンや ELB ロードバランサーに対して、追加の ENI が作成されます。 |
VPC ゲートウェイ | 20 | アカウントごとに 20 | 各クラスターは、S3 アクセス用の単一の VPC ゲートウェイを作成します。 |
S3 バケット | 99 | アカウントごとに 100 バケット | インストールプロセスでは 1 つの一時的なバケットを作成し、各クラスターのレジストリーコンポーネントがバケットを作成するため、AWS アカウントごとに 99 の OpenShift Container Platform クラスターのみを作成できます。 |
セキュリティーグループ | 250 | アカウントごとに 2,500 | 各クラスターは、10 の個別のセキュリティーグループを作成します。 |
4.2.3. IAM ユーザーに必要な AWS パーミッション
ベースクラスターリソースを削除するには、IAM ユーザーが領域 us-east-1
にアクセス許可 tag:GetResources
を持っている必要があります。AWS API 要件の一部として、OpenShift Container Platform インストールプログラムはこのリージョンでさまざまなアクションを実行します。
AdministratorAccess
ポリシーを、Amazon Web Services (AWS) で作成する IAM ユーザーに割り当てる場合、そのユーザーには必要なパーミッションすべてを付与します。OpenShift Container Platform クラスターのすべてのコンポーネントをデプロイするために、IAM ユーザーに以下のパーミッションが必要になります。
例4.1 インストールに必要な EC2 パーミッション
-
ec2:AttachNetworkInterface
-
ec2:AuthorizeSecurityGroupEgress
-
ec2:AuthorizeSecurityGroupIngress
-
ec2:CopyImage
-
ec2:CreateNetworkInterface
-
ec2:CreateSecurityGroup
-
ec2:CreateTags
-
ec2:CreateVolume
-
ec2:DeleteSecurityGroup
-
ec2:DeleteSnapshot
-
ec2:DeleteTags
-
ec2:DeregisterImage
-
ec2:DescribeAccountAttributes
-
ec2:DescribeAddresses
-
ec2:DescribeAvailabilityZones
-
ec2:DescribeDhcpOptions
-
ec2:DescribeImages
-
ec2:DescribeInstanceAttribute
-
ec2:DescribeInstanceCreditSpecifications
-
ec2:DescribeInstances
-
ec2:DescribeInstanceTypes
-
ec2:DescribeInternetGateways
-
ec2:DescribeKeyPairs
-
ec2:DescribeNatGateways
-
ec2:DescribeNetworkAcls
-
ec2:DescribeNetworkInterfaces
-
ec2:DescribePrefixLists
-
ec2:DescribeRegions
-
ec2:DescribeRouteTables
-
ec2:DescribeSecurityGroupRules
-
ec2:DescribeSecurityGroups
-
ec2:DescribeSubnets
-
ec2:DescribeTags
-
ec2:DescribeVolumes
-
ec2:DescribeVpcAttribute
-
ec2:DescribeVpcClassicLink
-
ec2:DescribeVpcClassicLinkDnsSupport
-
ec2:DescribeVpcEndpoints
-
ec2:DescribeVpcs
-
ec2:GetEbsDefaultKmsKeyId
-
ec2:ModifyInstanceAttribute
-
ec2:ModifyNetworkInterfaceAttribute
-
ec2:RevokeSecurityGroupEgress
-
ec2:RevokeSecurityGroupIngress
-
ec2:RunInstances
-
ec2:TerminateInstances
例4.2 インストール時のネットワークリソースの作成に必要なパーミッション
-
ec2:AllocateAddress
-
ec2:AssociateAddress
-
ec2:AssociateDhcpOptions
-
ec2:AssociateRouteTable
-
ec2:AttachInternetGateway
-
ec2:CreateDhcpOptions
-
ec2:CreateInternetGateway
-
ec2:CreateNatGateway
-
ec2:CreateRoute
-
ec2:CreateRouteTable
-
ec2:CreateSubnet
-
ec2:CreateVpc
-
ec2:CreateVpcEndpoint
-
ec2:ModifySubnetAttribute
-
ec2:ModifyVpcAttribute
既存の Virtual Private Cloud (VPC) を使用する場合、アカウントではネットワークリソースの作成にこれらのパーミッションを必要としません。
例4.3 インストールに必要な Elastic Load Balancing (ELB) のパーミッション
-
elasticloadbalancing:AddTags
-
elasticloadbalancing:ApplySecurityGroupsToLoadBalancer
-
elasticloadbalancing:AttachLoadBalancerToSubnets
-
elasticloadbalancing:ConfigureHealthCheck
-
elasticloadbalancing:CreateListener
-
elasticloadbalancing:CreateLoadBalancer
-
elasticloadbalancing:CreateLoadBalancerListeners
-
elasticloadbalancing:CreateTargetGroup
-
elasticloadbalancing:DeleteLoadBalancer
-
elasticloadbalancing:DeregisterInstancesFromLoadBalancer
-
elasticloadbalancing:DeregisterTargets
-
elasticloadbalancing:DescribeInstanceHealth
-
elasticloadbalancing:DescribeListeners
-
elasticloadbalancing:DescribeLoadBalancerAttributes
-
elasticloadbalancing:DescribeLoadBalancers
-
elasticloadbalancing:DescribeTags
-
elasticloadbalancing:DescribeTargetGroupAttributes
-
elasticloadbalancing:DescribeTargetHealth
-
elasticloadbalancing:ModifyLoadBalancerAttributes
-
elasticloadbalancing:ModifyTargetGroup
-
elasticloadbalancing:ModifyTargetGroupAttributes
-
elasticloadbalancing:RegisterInstancesWithLoadBalancer
-
elasticloadbalancing:RegisterTargets
-
elasticloadbalancing:SetLoadBalancerPoliciesOfListener
OpenShift Container Platform は、ELB と ELBv2 API サービスの両方を使用してロードバランサーをプロビジョニングします。パーミッションリストには、両方のサービスに必要なパーミッションが表示されます。AWS Web コンソールには、両方のサービスが同じ elasticloadbalancing
アクション接頭辞を使用しているにもかかわらず、同じアクションを認識しないという既知の問題が存在します。サービスが特定の elasticloadbalancing
アクションを認識しないという警告は無視できます。
例4.4 インストールに必要な IAM パーミッション
-
iam:AddRoleToInstanceProfile
-
iam:CreateInstanceProfile
-
iam:CreateRole
-
iam:DeleteInstanceProfile
-
iam:DeleteRole
-
iam:DeleteRolePolicy
-
iam:GetInstanceProfile
-
iam:GetRole
-
iam:GetRolePolicy
-
iam:GetUser
-
iam:ListInstanceProfilesForRole
-
iam:ListRoles
-
iam:ListUsers
-
iam:PassRole
-
iam:PutRolePolicy
-
iam:RemoveRoleFromInstanceProfile
-
iam:SimulatePrincipalPolicy
-
iam:TagInstanceProfile
-
iam:TagRole
AWS アカウントにロードバランサーを作成していない場合、IAM ユーザーには iam:CreateServiceLinkedRole
パーミッションも必要です。
例4.5 インストールに必要な Route 53 パーミッション
-
route53:ChangeResourceRecordSets
-
route53:ChangeTagsForResource
-
route53:CreateHostedZone
-
route53:DeleteHostedZone
-
route53:GetChange
-
route53:GetHostedZone
-
route53:ListHostedZones
-
route53:ListHostedZonesByName
-
route53:ListResourceRecordSets
-
route53:ListTagsForResource
-
route53:UpdateHostedZoneComment
例4.6 インストールに必要な Amazon Simple Storage Service (S3) パーミッション
-
s3:CreateBucket
-
s3:DeleteBucket
-
s3:GetAccelerateConfiguration
-
s3:GetBucketAcl
-
s3:GetBucketCors
-
s3:GetBucketLocation
-
s3:GetBucketLogging
-
s3:GetBucketObjectLockConfiguration
-
s3:GetBucketPolicy
-
s3:GetBucketRequestPayment
-
s3:GetBucketTagging
-
s3:GetBucketVersioning
-
s3:GetBucketWebsite
-
s3:GetEncryptionConfiguration
-
s3:GetLifecycleConfiguration
-
s3:GetReplicationConfiguration
-
s3:ListBucket
-
s3:PutBucketAcl
-
s3:PutBucketTagging
-
s3:PutEncryptionConfiguration
例4.7 クラスター Operator が必要とする S3 パーミッション
-
s3:DeleteObject
-
s3:GetObject
-
s3:GetObjectAcl
-
s3:GetObjectTagging
-
s3:GetObjectVersion
-
s3:PutObject
-
s3:PutObjectAcl
-
s3:PutObjectTagging
例4.8 ベースクラスターリソースの削除に必要なパーミッション
-
autoscaling:DescribeAutoScalingGroups
-
ec2:DeleteNetworkInterface
-
ec2:DeletePlacementGroup
-
ec2:DeleteVolume
-
elasticloadbalancing:DeleteTargetGroup
-
elasticloadbalancing:DescribeTargetGroups
-
iam:DeleteAccessKey
-
iam:DeleteUser
-
iam:DeleteUserPolicy
-
iam:ListAttachedRolePolicies
-
iam:ListInstanceProfiles
-
iam:ListRolePolicies
-
iam:ListUserPolicies
-
s3:DeleteObject
-
s3:ListBucketVersions
-
tag:GetResources
例4.9 ネットワークリソースの削除に必要なパーミッション
-
ec2:DeleteDhcpOptions
-
ec2:DeleteInternetGateway
-
ec2:DeleteNatGateway
-
ec2:DeleteRoute
-
ec2:DeleteRouteTable
-
ec2:DeleteSubnet
-
ec2:DeleteVpc
-
ec2:DeleteVpcEndpoints
-
ec2:DetachInternetGateway
-
ec2:DisassociateRouteTable
-
ec2:ReleaseAddress
-
ec2:ReplaceRouteTableAssociation
既存の VPC を使用する場合、アカウントではネットワークリソースの削除にこれらのパーミッションを必要としません。代わりに、アカウントではネットワークリソースの削除に tag:UntagResources
パーミッションのみが必要になります。
例4.10 カスタムキー管理サービス (KMS) キーを使用してクラスターをインストールするためのオプションの権限
-
kms:CreateGrant
-
kms:Decrypt
-
kms:DescribeKey
-
kms:Encrypt
-
kms:GenerateDataKey
-
kms:GenerateDataKeyWithoutPlainText
-
kms:ListGrants
-
kms:RevokeGrant
例4.11 共有インスタンスロールが割り当てられたクラスターを削除するために必要なパーミッション
-
iam:UntagRole
例4.12 マニフェストの作成に必要な追加の IAM および S3 パーミッション
-
iam:GetUserPolicy
-
iam:ListAccessKeys
-
iam:PutUserPolicy
-
iam:TagUser
-
s3:AbortMultipartUpload
-
s3:GetBucketPublicAccessBlock
-
s3:ListBucket
-
s3:ListBucketMultipartUploads
-
s3:PutBucketPublicAccessBlock
-
s3:PutLifecycleConfiguration
クラウドプロバイダーのクレデンシャルをミントモードで管理している場合に、IAM ユーザーには iam:CreateAccessKey
と iam:CreateUser
権限も必要です。
例4.13 インスタンスのオプションのパーミッションおよびインストールのクォータチェック
-
ec2:DescribeInstanceTypeOfferings
-
servicequotas:ListAWSDefaultServiceQuotas
例4.14 共有 VPC にクラスターをインストールする場合のクラスター所有者アカウントのオプションの権限
-
sts:AssumeRole
4.2.4. IAM ユーザーの作成
各 Amazon Web Services (AWS) アカウントには、アカウントの作成に使用するメールアドレスに基づく root ユーザーアカウントが含まれます。これは高度な権限が付与されたアカウントであり、初期アカウントにのみ使用し、請求設定また初期のユーザーセットの作成およびアカウントのセキュリティー保護のために使用することが推奨されています。
OpenShift Container Platform をインストールする前に、セカンダリー IAM 管理ユーザーを作成します。AWS ドキュメントの Creating an IAM User in Your AWS Account 手順を実行する際に、以下のオプションを設定します。
手順
-
IAM ユーザー名を指定し、
Programmatic access
を選択します。 AdministratorAccess
ポリシーを割り当て、アカウントにクラスターを作成するために十分なパーミッションがあることを確認します。このポリシーはクラスターに対し、各 OpenShift Container Platform コンポーネントに認証情報を付与する機能を提供します。クラスターはコンポーネントに対し、それらが必要とする認証情報のみを付与します。注記必要なすべての AWS パーミッションを付与し、これをユーザーに割り当てるポリシーを作成することは可能ですが、これは優先されるオプションではありません。クラスターには追加の認証情報を個別コンポーネントに付与する機能がないため、同じ認証情報がすべてのコンポーネントによって使用されます。
- オプション: タグを割り当て、メタデータをユーザーに追加します。
-
指定したユーザー名に
AdministratorAccess
ポリシーが付与されていることを確認します。 アクセスキー ID およびシークレットアクセスキーの値を記録します。ローカルマシンをインストールプログラムを実行するように設定する際にこれらの値を使用する必要があります。
重要クラスターのデプロイ時に、マルチファクター認証デバイスの使用中に生成した一時的なセッショントークンを使用して AWS に対する認証を行うことはできません。クラスターは継続的に現行の AWS 認証情報を使用して、クラスターの有効期間全体にわたって AWS リソースを作成するため、キーをベースとした有効期間の長い認証情報を使用する必要があります。
4.2.5. IAM ポリシーと AWS 認証
デフォルトでは、インストールプログラムは、ブートストラップ、コントロールプレーン、およびコンピュートインスタンスのインスタンスプロファイルを作成し、クラスターの動作に必要な権限を付与します。
シングルノードの OpenShift クラスターでインストール後のタスクとして Amazon Elastic Container Registry (ECR) からイメージをプルできるようにするには、クラスターのコントロールプレーンロールに関連付けられた IAM ロールに AmazonEC2ContainerRegistryReadOnly
ポリシーを追加する必要があります。
ただし、独自の IAM ロールを作成して、インストールプロセスの一部として指定できます。クラスターをデプロイするため、またはインストール後にクラスターを管理するために、独自のロールを指定する必要がある場合があります。以下に例を示します。
- 組織のセキュリティーポリシーでは、より制限的なアクセス許可セットを使用してクラスターをインストールする必要があります。
- インストール後、クラスターは、追加サービスへのアクセスを必要とする Operator で設定されます。
独自の IAM ロールを指定する場合は、次の手順を実行できます。
- デフォルトのポリシーから始めて、必要に応じて調整します。詳細は、「IAM インスタンスプロファイルのデフォルトのアクセス許可」を参照してください。
- AWS IAM Access Analyzer (Identity and Access Management Access Analyzer) を使用して、クラスターのアクティビティーに基づくポリシーテンプレートを作成します。詳細は、「AWS IAM Analyzer を使用してポリシーテンプレートの作成」を参照してください。
4.2.5.1. IAM インスタンスプロファイルのデフォルトのアクセス許可
デフォルトでは、インストールプログラムは、ブートストラップ、コントロールプレーン、およびワーカーインスタンスの IAM インスタンスプロファイルを作成し、クラスターの動作に必要な権限を付与します。
次のリストでは、コントロールプレーンとコンピュートマシンのデフォルトのアクセス許可を指定します。
例4.15 コントロールプレーンインスタンスのプロファイル向けデフォルト IAM ロールのパーミッション
-
ec2:AttachVolume
-
ec2:AuthorizeSecurityGroupIngress
-
ec2:CreateSecurityGroup
-
ec2:CreateTags
-
ec2:CreateVolume
-
ec2:DeleteSecurityGroup
-
ec2:DeleteVolume
-
ec2:Describe*
-
ec2:DetachVolume
-
ec2:ModifyInstanceAttribute
-
ec2:ModifyVolume
-
ec2:RevokeSecurityGroupIngress
-
elasticloadbalancing:AddTags
-
elasticloadbalancing:AttachLoadBalancerToSubnets
-
elasticloadbalancing:ApplySecurityGroupsToLoadBalancer
-
elasticloadbalancing:CreateListener
-
elasticloadbalancing:CreateLoadBalancer
-
elasticloadbalancing:CreateLoadBalancerPolicy
-
elasticloadbalancing:CreateLoadBalancerListeners
-
elasticloadbalancing:CreateTargetGroup
-
elasticloadbalancing:ConfigureHealthCheck
-
elasticloadbalancing:DeleteListener
-
elasticloadbalancing:DeleteLoadBalancer
-
elasticloadbalancing:DeleteLoadBalancerListeners
-
elasticloadbalancing:DeleteTargetGroup
-
elasticloadbalancing:DeregisterInstancesFromLoadBalancer
-
elasticloadbalancing:DeregisterTargets
-
elasticloadbalancing:Describe*
-
elasticloadbalancing:DetachLoadBalancerFromSubnets
-
elasticloadbalancing:ModifyListener
-
elasticloadbalancing:ModifyLoadBalancerAttributes
-
elasticloadbalancing:ModifyTargetGroup
-
elasticloadbalancing:ModifyTargetGroupAttributes
-
elasticloadbalancing:RegisterInstancesWithLoadBalancer
-
elasticloadbalancing:RegisterTargets
-
elasticloadbalancing:SetLoadBalancerPoliciesForBackendServer
-
elasticloadbalancing:SetLoadBalancerPoliciesOfListener
-
kms:DescribeKey
例4.16 コンピュートインスタンスプロファイル向けデフォルト IAM ロールのパーミッション
-
ec2:DescribeInstances
-
ec2:DescribeRegions
4.2.5.2. 既存の IAM ロールの指定
インストールプログラムがデフォルトのアクセス許可で IAM インスタンスプロファイルを作成できるようにする代わりに、install-config.yaml
ファイルを使用して、コントロールプレーンとコンピュートインスタンスの既存の IAM ロールを指定できます。
前提条件
-
既存の
install-config.yaml
ファイルがある。
手順
コンピュートマシンの既のロールを使用して
compute.platform.aws.iamRole
を更新します。コンピュートインスタンスの IAM ロールを含む
install-config.yaml
ファイルのサンプルCopy to Clipboard Copied! Toggle word wrap Toggle overflow compute: - hyperthreading: Enabled name: worker platform: aws: iamRole: ExampleRole
compute: - hyperthreading: Enabled name: worker platform: aws: iamRole: ExampleRole
コントロールプレーンマシンの既存ロールを使用して
controlPlane.platform.aws.iamRole
を更新します。コントロールプレーンインスタンスの IAM ロールを含む
install-config.yaml
ファイルのサンプルCopy to Clipboard Copied! Toggle word wrap Toggle overflow controlPlane: hyperthreading: Enabled name: master platform: aws: iamRole: ExampleRole
controlPlane: hyperthreading: Enabled name: master platform: aws: iamRole: ExampleRole
- ファイルを保存し、OpenShift Container Platform クラスターのインストール時に参照します。
クラスターのインストール後に IAM アカウントを変更または更新する場合は、RHOCP 4 AWS cloud-credentials access key is expired (Red Hat ナレッジベース) を参照してください。
関連情報
- クラスターのデプロイ を参照してください。
4.2.5.3. AWS IAM Analyzer を使用してポリシーテンプレートの作成
コントロールプレーンとコンピュートインスタンスプロファイルに必要な最小限のアクセス許可セットは、クラスターが日常の運用のためにどのように設定されているかによって異なります。
クラスターインスタンスに必要なアクセス許可を決定する 1 つの方法は、IAM Access Analyzer (AWS Identity and Access Management Access Analyzer) を使用してポリシーテンプレートを作成することです。
- ポリシーテンプレートには、クラスターが指定された期間に使用したアクセス許可が含まれています。
- その後、テンプレートを使用して、きめ細かい権限を持つポリシーを作成できます。
手順
全体的なプロセスは次のようになります。
- CloudTrail が有効になっていることを確認します。CloudTrail は、ポリシーテンプレートの作成に必要な API 呼び出しを含め、AWS アカウントのすべてのアクションとイベントを記録します。詳細は、CloudTrail の操作 に関する AWS ドキュメントを参照してください。
- コントロールプレーンインスタンスのインスタンスプロファイルとコンピューティングインスタンスのインスタンスプロファイルを作成します。PowerUserAccess などの寛容なポリシーを各ロールに割り当ててください。詳細は、インスタンスプロファイルロールの作成 に関する AWS ドキュメントを参照してください。
- クラスターを開発環境にインストールし、必要に応じて設定します。クラスターが本番環境でホストするすべてのアプリケーションを必ずデプロイしてください。
- クラスターを徹底的にテストします。クラスターをテストすると、必要なすべての API 呼び出しがログに記録されることが保証されます。
- IAM Access Analyzer を使用して、各インスタンスプロファイルのポリシーテンプレートを作成します。詳細は、CloudTrail ログに基づいてポリシーを生成する ための AWS ドキュメントを参照してください。
- きめ細かいポリシーを作成し、各インスタンスプロファイルに追加します。
- 各インスタンスプロファイルから許容ポリシーを削除します。
- 新しいポリシーで既存のインスタンスプロファイルを使用して実稼働クラスターをデプロイします。
ポリシーに IAM 条件 を追加して、ポリシーをより制限し、組織のセキュリティー要件に準拠させることができます。
4.2.6. サポートされている AWS Marketplace リージョン
北米でオファーを購入したお客様は、AWS Marketplace イメージを使用して、OpenShift Container Platform クラスターをインストールすることができます。
このオファーは北米で購入する必要がありますが、以下のサポートされているパーティションのいずれかにクラスターをデプロイできます。
- 公開
- GovCloud
AWS Marketplace イメージを使用した OpenShift Container Platform クラスターのデプロイは、AWS シークレットリージョンまたは中国リージョンではサポートされていません。
4.2.7. サポートされている AWS リージョン
OpenShift Container Platform クラスターを以下のリージョンにデプロイできます。
ベースクラスターリソースを削除するには、IAM ユーザーが領域 us-east-1
にアクセス許可 tag:GetResources
を持っている必要があります。AWS API 要件の一部として、OpenShift Container Platform インストールプログラムはこのリージョンでさまざまなアクションを実行します。
4.2.7.1. AWS パブリックリージョン
以下の AWS パブリックリージョンがサポートされます。
-
af-south-1
(Cape Town) -
ap-east-1
(Hong Kong) -
ap-northeast-1
(Tokyo) -
ap-northeast-2
(Seoul) -
ap-northeast-3
(Osaka) -
ap-south-1
(Mumbai) -
ap-south-2
(Hyderabad) -
ap-southeast-1
(Singapore) -
ap-southeast-2
(Sydney) -
ap-southeast-3
(Jakarta) -
ap-southeast-4
(Melbourne) -
ca-central-1
(Central) -
ca-west-1
(Calgary) -
eu-central-1
(Frankfurt) -
eu-central-2
(Zurich) -
eu-north-1
(Stockholm) -
eu-south-1
(Milan) -
eu-south-2
(Spain) -
eu-west-1
(Ireland) -
eu-west-2
(London) -
eu-west-3
(Paris) -
il-central-1
(Tel Aviv) -
me-central-1
(UAE) -
me-south-1
(Bahrain) -
sa-east-1
(São Paulo) -
us-east-1
(N. Virginia) -
us-east-2
(Ohio) -
us-west-1
(N. California) -
us-west-2
(Oregon)
4.2.7.2. AWS GovCloud リージョン
以下の AWS GovCloud リージョンがサポートされます。
-
us-gov-west-1
-
us-gov-east-1
4.2.7.3. AWS SC2S および C2S シークレットリージョン
以下の AWS シークレットリージョンがサポートされています。
-
us-isob-east-1
Secret Commercial Cloud Services (SC2S) -
us-iso-east-1
Commercial Cloud Services (C2S)
4.2.7.4. AWS China リージョン
以下の AWS China リージョンがサポートされます。
-
cn-north-1
(Beijing) -
cn-northwest-1
(Ningxia)
4.2.8. 次のステップ
OpenShift Container Platform クラスターをインストールします。
4.3. クラスターの AWS へのクイックインストール
OpenShift Container Platform バージョン 4.15 では、デフォルトの設定オプションを使用する Amazon Web Services (AWS) にクラスターをインストールできます。
4.3.1. 前提条件
- OpenShift Container Platform のインストールおよび更新 プロセスの詳細を確認した。
- クラスターインストール方法の選択およびそのユーザー向けの準備 を確認した。
クラスターをホストするために AWS アカウントを設定 している。
重要AWS プロファイルがご使用のコンピューターに保存されている場合、マルチファクター認証デバイスを使用中に生成した一時的なセッショントークンを使用することはできません。クラスターは継続的に現行の AWS 認証情報を使用して、クラスターの有効期間全体にわたって AWS リソースを作成するため、キーをベースとした有効期間の長い認証情報を使用する必要があります。適切なキーを生成するには、AWS ドキュメントの Managing Access Keys for IAM Users を参照してください。キーは、インストールプログラムの実行時に指定できます。
- ファイアウォールを使用する場合は、クラスターがアクセスを必要とするサイトを許可するようにファイアウォールを設定する必要がある。
4.3.2. OpenShift Container Platform のインターネットアクセス
OpenShift Container Platform 4.15 では、クラスターをインストールするためにインターネットアクセスが必要になります。
インターネットへのアクセスは以下を実行するために必要です。
- OpenShift Cluster Manager にアクセスし、インストールプログラムをダウンロードし、サブスクリプション管理を実行します。クラスターにインターネットアクセスがあり、Telemetry を無効にしない場合、そのサービスは有効なサブスクリプションでクラスターを自動的に使用します。
- クラスターのインストールに必要なパッケージを取得するために Quay.io にアクセスします。
- クラスターの更新を実行するために必要なパッケージを取得します。
クラスターでインターネットに直接アクセスできない場合、プロビジョニングする一部のタイプのインフラストラクチャーでネットワークが制限されたインストールを実行できます。このプロセスで、必要なコンテンツをダウンロードし、これを使用してミラーレジストリーにインストールパッケージを設定します。インストールタイプによっては、クラスターのインストール環境でインターネットアクセスが不要となる場合があります。クラスターを更新する前に、ミラーレジストリーのコンテンツを更新します。
4.3.3. クラスターノードの 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 オペレーティングシステムを使用するコンピューターで以下のコマンドを実行します。
Copy to Clipboard Copied! Toggle word wrap Toggle overflow ssh-keygen -t ed25519 -N '' -f <path>/<file_name>
$ 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 キーを表示します。
Copy to Clipboard Copied! Toggle word wrap Toggle overflow cat <path>/<file_name>.pub
$ cat <path>/<file_name>.pub
たとえば、次のコマンドを実行して
~/.ssh/id_ed25519.pub
公開鍵を表示します。Copy to Clipboard Copied! Toggle word wrap Toggle overflow cat ~/.ssh/id_ed25519.pub
$ cat ~/.ssh/id_ed25519.pub
ローカルユーザーの SSH エージェントに SSH 秘密鍵 ID が追加されていない場合は、それを追加します。キーの SSH エージェント管理は、クラスターノードへのパスワードなしの SSH 認証、または
./openshift-install gather
コマンドを使用する場合は必要になります。注記一部のディストリビューションでは、
~/.ssh/id_rsa
および~/.ssh/id_dsa
などのデフォルトの SSH 秘密鍵のアイデンティティーは自動的に管理されます。ssh-agent
プロセスがローカルユーザーに対して実行されていない場合は、バックグラウンドタスクとして開始します。Copy to Clipboard Copied! Toggle word wrap Toggle overflow eval "$(ssh-agent -s)"
$ eval "$(ssh-agent -s)"
出力例
Copy to Clipboard Copied! Toggle word wrap Toggle overflow Agent pid 31874
Agent pid 31874
注記クラスターが FIPS モードにある場合は、FIPS 準拠のアルゴリズムのみを使用して SSH キーを生成します。鍵は RSA または ECDSA のいずれかである必要があります。
SSH プライベートキーを
ssh-agent
に追加します。Copy to Clipboard Copied! Toggle word wrap Toggle overflow ssh-add <path>/<file_name>
$ ssh-add <path>/<file_name>
1 - 1
~/.ssh/id_ed25519
などの、SSH プライベートキーのパスおよびファイル名を指定します。
出力例
Copy to Clipboard Copied! Toggle word wrap Toggle overflow Identity added: /home/<you>/<path>/<file_name> (<computer_name>)
Identity added: /home/<you>/<path>/<file_name> (<computer_name>)
次のステップ
- OpenShift Container Platform をインストールする際に、SSH パブリックキーをインストールプログラムに指定します。
4.3.4. インストールプログラムの取得
OpenShift Container Platform をインストールする前に、インストールに使用しているホストにインストールファイルをダウンロードします。
前提条件
- 500 MB のローカルディスク領域がある Linux または macOS を実行するコンピューターが必要です。
手順
- OpenShift Cluster Manager サイトの インフラストラクチャープロバイダー ページにアクセスします。Red Hat アカウントがある場合は、認証情報を使用してログインします。アカウントがない場合はこれを作成します。
- インフラストラクチャープロバイダーを選択します。
インストールタイプのページに移動し、ホストオペレーティングシステムとアーキテクチャーに対応するインストールプログラムをダウンロードして、インストール設定ファイルを保存するディレクトリーにファイルを配置します。
重要インストールプログラムは、クラスターのインストールに使用するコンピューターにいくつかのファイルを作成します。クラスターのインストール完了後は、インストールプログラムおよびインストールプログラムが作成するファイルを保持する必要があります。ファイルはいずれもクラスターを削除するために必要になります。
重要インストールプログラムで作成されたファイルを削除しても、クラスターがインストール時に失敗した場合でもクラスターは削除されません。クラスターを削除するには、特定のクラウドプロバイダー用の OpenShift Container Platform のアンインストール手順を実行します。
インストールプログラムを展開します。たとえば、Linux オペレーティングシステムを使用するコンピューターで以下のコマンドを実行します。
Copy to Clipboard Copied! Toggle word wrap Toggle overflow tar -xvf openshift-install-linux.tar.gz
$ tar -xvf openshift-install-linux.tar.gz
- Red Hat OpenShift Cluster Manager からインストールプルシークレット をダウンロードします。このプルシークレットを使用し、OpenShift Container Platform コンポーネントのコンテナーイメージを提供する Quay.io など、組み込まれた各種の認証局によって提供されるサービスで認証できます。
4.3.5. クラスターのデプロイ
互換性のあるクラウドプラットフォームに OpenShift Container Platform をインストールできます。
インストールプログラムの create cluster
コマンドは、初期インストール時に 1 回だけ実行できます。
前提条件
- クラスターをホストするクラウドプラットフォームでアカウントを設定しました。
- OpenShift Container Platform インストールプログラムおよびクラスターのプルシークレットがある。
- ホスト上のクラウドプロバイダーアカウントに、クラスターをデプロイするための適切な権限があることが確認されました。アカウントの権限が正しくないと、インストールプロセスが失敗し、不足している権限を示すエラーメッセージが表示されます。
手順
インストールプログラムが含まれるディレクトリーに切り替え、クラスターのデプロイメントを初期化します。
Copy to Clipboard Copied! Toggle word wrap Toggle overflow ./openshift-install create cluster --dir <installation_directory> \ --log-level=info
$ ./openshift-install create cluster --dir <installation_directory> \
1 --log-level=info
2 ディレクトリーを指定する場合:
-
ディレクトリーに
execute
権限があることを確認します。この権限は、インストールディレクトリーで Terraform バイナリーを実行するために必要です。 - 空のディレクトリーを使用します。ブートストラップ X.509 証明書などの一部のインストールアセットは有効期限が短いため、インストールディレクトリーを再利用しないでください。別のクラスターインストールの個別のファイルを再利用する必要がある場合は、それらをディレクトリーにコピーすることができます。ただし、インストールアセットのファイル名はリリース間で変更される可能性があります。インストールファイルを以前のバージョンの OpenShift Container Platform からコピーする場合は注意してコピーを行ってください。
-
ディレクトリーに
プロンプト時に値を指定します。
オプション: クラスターマシンにアクセスするために使用する SSH キーを選択します。
注記インストールのデバッグまたは障害復旧を実行する必要のある実稼働用の OpenShift Container Platform クラスターでは、
ssh-agent
プロセスが使用する SSH キーを指定します。- ターゲットに設定するプラットフォームとして aws を選択します。
Amazon Web Services (AWS) プロファイルをコンピューターに保存していない場合、インストールプログラムを実行するように設定したユーザーの AWS アクセスキー ID およびシークレットアクセスキーを入力します。
注記AWS アクセスキー ID およびシークレットアクセスキーは、インストールホストの現行ユーザーのホームディレクトリーの
~/.aws/credentials
に保存されます。エクスポートされたプロファイルの認証情報がファイルにない場合は、インストールプログラムにより認証情報の入力が求めるプロンプトが出されます。インストールプログラムに指定する認証情報は、ファイルに保存されます。- クラスターのデプロイ先とする AWS リージョンを選択します。
- クラスターに設定した Route 53 サービスのベースドメインを選択します。
- クラスターの記述名を入力します。
- Red Hat OpenShift Cluster Manager からプルシークレット を貼り付けます。
オプション: クラスターのインストールに使用した 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
...
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 設定ファイルを使用することにより、インストール中に証明書の更新が実行された場合のインストールの失敗を回避できます。
関連情報
- AWS プロファイルおよび認証情報の設定についての詳細は、AWS ドキュメントの Configuration and credential file settings を参照してください。
4.3.6. バイナリーのダウンロードによる OpenShift CLI のインストール
コマンドラインインターフェイスを使用して OpenShift Container Platform と対話するために CLI (oc
) をインストールすることができます。oc
は Linux、Windows、または macOS にインストールできます。
以前のバージョンの oc
をインストールしている場合、これを使用して OpenShift Container Platform 4.15 のすべてのコマンドを実行することはできません。新規バージョンの oc
をダウンロードし、インストールします。
Linux への OpenShift CLI のインストール
以下の手順を使用して、OpenShift CLI (oc
) バイナリーを Linux にインストールできます。
手順
- Red Hat カスタマーポータルの OpenShift Container Platform ダウンロードページ に移動します。
- Product Variant ドロップダウンリストからアーキテクチャーを選択します。
- バージョン ドロップダウンリストから適切なバージョンを選択します。
- OpenShift v4.15 Linux Client エントリーの横にある Download Now をクリックして、ファイルを保存します。
アーカイブを展開します。
Copy to Clipboard Copied! Toggle word wrap Toggle overflow tar xvf <file>
$ tar xvf <file>
oc
バイナリーを、PATH
にあるディレクトリーに配置します。PATH
を確認するには、以下のコマンドを実行します。Copy to Clipboard Copied! Toggle word wrap Toggle overflow echo $PATH
$ echo $PATH
検証
OpenShift CLI のインストール後に、
oc
コマンドを使用して利用できます。Copy to Clipboard Copied! Toggle word wrap Toggle overflow oc <command>
$ oc <command>
Windows への OpenShift CLI のインストール
以下の手順を使用して、OpenShift CLI (oc
) バイナリーを Windows にインストールできます。
手順
- Red Hat カスタマーポータルの OpenShift Container Platform ダウンロードページ に移動します。
- バージョン ドロップダウンリストから適切なバージョンを選択します。
- OpenShift v4.15 Windows Client エントリーの横にある Download Now をクリックして、ファイルを保存します。
- ZIP プログラムでアーカイブを展開します。
oc
バイナリーを、PATH
にあるディレクトリーに移動します。PATH
を確認するには、コマンドプロンプトを開いて以下のコマンドを実行します。Copy to Clipboard Copied! Toggle word wrap Toggle overflow path
C:\> path
検証
OpenShift CLI のインストール後に、
oc
コマンドを使用して利用できます。Copy to Clipboard Copied! Toggle word wrap Toggle overflow oc <command>
C:\> oc <command>
macOS への OpenShift CLI のインストール
以下の手順を使用して、OpenShift CLI (oc
) バイナリーを macOS にインストールできます。
手順
- Red Hat カスタマーポータルの OpenShift Container Platform ダウンロードページ に移動します。
- バージョン ドロップダウンリストから適切なバージョンを選択します。
OpenShift v4.15 macOS Client エントリーの横にある Download Now をクリックして、ファイルを保存します。
注記macOS arm64 の場合は、OpenShift v4.15 macOS arm64 Client エントリーを選択します。
- アーカイブを展開し、解凍します。
oc
バイナリーをパスにあるディレクトリーに移動します。PATH
を確認するには、ターミナルを開き、以下のコマンドを実行します。Copy to Clipboard Copied! Toggle word wrap Toggle overflow echo $PATH
$ echo $PATH
検証
oc
コマンドを使用してインストールを確認します。Copy to Clipboard Copied! Toggle word wrap Toggle overflow oc <command>
$ oc <command>
4.3.7. CLI の使用によるクラスターへのログイン
クラスター kubeconfig
ファイルをエクスポートし、デフォルトシステムユーザーとしてクラスターにログインできます。kubeconfig
ファイルには、クライアントを正しいクラスターおよび API サーバーに接続するために CLI で使用されるクラスターに関する情報が含まれます。このファイルはクラスターに固有のファイルであり、OpenShift Container Platform のインストール時に作成されます。
前提条件
- OpenShift Container Platform クラスターをデプロイしていること。
-
oc
CLI をインストールしていること。
手順
kubeadmin
認証情報をエクスポートします。Copy to Clipboard Copied! Toggle word wrap Toggle overflow export KUBECONFIG=<installation_directory>/auth/kubeconfig
$ export KUBECONFIG=<installation_directory>/auth/kubeconfig
1 - 1
<installation_directory>
には、インストールファイルを保存したディレクトリーへのパスを指定します。
エクスポートされた設定を使用して、
oc
コマンドを正常に実行できることを確認します。Copy to Clipboard Copied! Toggle word wrap Toggle overflow oc whoami
$ oc whoami
出力例
Copy to Clipboard Copied! Toggle word wrap Toggle overflow system:admin
system:admin
4.3.8. Web コンソールを使用したクラスターへのログイン
kubeadmin
ユーザーは、OpenShift Container Platform のインストール後はデフォルトで存在します。OpenShift Container Platform Web コンソールを使用し、kubeadmin
ユーザーとしてクラスターにログインできます。
前提条件
- インストールホストにアクセスできる。
- クラスターのインストールを完了しており、すべてのクラスター Operator が利用可能である。
手順
インストールホストで
kubeadmin-password
ファイルからkubeadmin
ユーザーのパスワードを取得します。Copy to Clipboard Copied! Toggle word wrap Toggle overflow cat <installation_directory>/auth/kubeadmin-password
$ cat <installation_directory>/auth/kubeadmin-password
注記または、インストールホストで
<installation_directory>/.openshift_install.log
ログファイルからkubeadmin
パスワードを取得できます。OpenShift Container Platform Web コンソールルートをリスト表示します。
Copy to Clipboard Copied! Toggle word wrap Toggle overflow oc get routes -n openshift-console | grep 'console-openshift'
$ oc get routes -n openshift-console | grep 'console-openshift'
注記または、インストールホストで
<installation_directory>/.openshift_install.log
ログファイルからで OpenShift Container Platform ルートを取得できます。出力例
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 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 None
-
Web ブラウザーで前述のコマンドの出力で詳細に説明されたルートに移動し、
kubeadmin
ユーザーとしてログインします。
関連情報
- OpenShift Container Platform Web コンソールへのアクセスと理解に関する詳細は、Web コンソールへのアクセス を参照してください。
4.3.9. OpenShift Container Platform の Telemetry アクセス
OpenShift Container Platform 4.15 では、クラスターの健全性および正常に実行された更新についてのメトリクスを提供するためにデフォルトで実行される Telemetry サービスにも、インターネットアクセスが必要です。クラスターがインターネットに接続されている場合、Telemetry は自動的に実行され、クラスターは OpenShift Cluster Manager に登録されます。
OpenShift Cluster Manager インベントリーが正常である (Telemetry によって自動的に維持、または OpenShift Cluster Manager を使用して手動で維持) ことを確認した後に、subscription watch を使用 して、アカウントまたはマルチクラスターレベルで OpenShift Container Platform サブスクリプションを追跡します。
関連情報
- Telemetry サービスの詳細は、リモートヘルスモニタリング を参照してください。
4.3.10. 次のステップ
- インストールを検証 します。
- クラスターをカスタマイズ します。
- 必要に応じて、リモートヘルスレポートをオプトアウト できます。
- 必要に応じて、クラウドプロバイダーの認証情報を削除 できます。
4.4. カスタマイズによる AWS へのクラスターのインストール
OpenShift Container Platform バージョン 4.15 では、インストールプログラムが Amazon Web Services (AWS) 上にプロビジョニングするインフラストラクチャーにカスタマイズされたクラスターをインストールできます。インストールをカスタマイズするには、クラスターをインストールする前に、install-config.yaml
ファイルでパラメーターを変更します。
OpenShift Container Platform インストール設定のスコープは意図的に狭められています。単純さを確保し、確実にインストールを実行できるように設計されているためです。インストールが完了した後にさらに多くの OpenShift Container Platform 設定タスクを実行することができます。
4.4.1. 前提条件
- OpenShift Container Platform のインストールおよび更新 プロセスの詳細を確認した。
- クラスターインストール方法の選択およびそのユーザー向けの準備 を確認した。
クラスターをホストするために AWS アカウントを設定 している。
重要AWS プロファイルがご使用のコンピューターに保存されている場合、マルチファクター認証デバイスを使用中に生成した一時的なセッショントークンを使用することはできません。クラスターは継続的に現行の AWS 認証情報を使用して、クラスターの有効期間全体にわたって AWS リソースを作成するため、有効期間の長い認証情報を使用する必要があります。適切なキーを生成するには、AWS ドキュメントの Managing Access Keys for IAM Users を参照してください。キーは、インストールプログラムの実行時に指定できます。
- ファイアウォールを使用する場合は、クラスターがアクセスを必要とするサイトを許可するようにファイアウォールを設定する必要がある。
4.4.2. OpenShift Container Platform のインターネットアクセス
OpenShift Container Platform 4.15 では、クラスターをインストールするためにインターネットアクセスが必要になります。
インターネットへのアクセスは以下を実行するために必要です。
- OpenShift Cluster Manager にアクセスし、インストールプログラムをダウンロードし、サブスクリプション管理を実行します。クラスターにインターネットアクセスがあり、Telemetry を無効にしない場合、そのサービスは有効なサブスクリプションでクラスターを自動的に使用します。
- クラスターのインストールに必要なパッケージを取得するために Quay.io にアクセスします。
- クラスターの更新を実行するために必要なパッケージを取得します。
クラスターでインターネットに直接アクセスできない場合、プロビジョニングする一部のタイプのインフラストラクチャーでネットワークが制限されたインストールを実行できます。このプロセスで、必要なコンテンツをダウンロードし、これを使用してミラーレジストリーにインストールパッケージを設定します。インストールタイプによっては、クラスターのインストール環境でインターネットアクセスが不要となる場合があります。クラスターを更新する前に、ミラーレジストリーのコンテンツを更新します。
4.4.3. クラスターノードの 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 オペレーティングシステムを使用するコンピューターで以下のコマンドを実行します。
Copy to Clipboard Copied! Toggle word wrap Toggle overflow ssh-keygen -t ed25519 -N '' -f <path>/<file_name>
$ 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 キーを表示します。
Copy to Clipboard Copied! Toggle word wrap Toggle overflow cat <path>/<file_name>.pub
$ cat <path>/<file_name>.pub
たとえば、次のコマンドを実行して
~/.ssh/id_ed25519.pub
公開鍵を表示します。Copy to Clipboard Copied! Toggle word wrap Toggle overflow cat ~/.ssh/id_ed25519.pub
$ cat ~/.ssh/id_ed25519.pub
ローカルユーザーの SSH エージェントに SSH 秘密鍵 ID が追加されていない場合は、それを追加します。キーの SSH エージェント管理は、クラスターノードへのパスワードなしの SSH 認証、または
./openshift-install gather
コマンドを使用する場合は必要になります。注記一部のディストリビューションでは、
~/.ssh/id_rsa
および~/.ssh/id_dsa
などのデフォルトの SSH 秘密鍵のアイデンティティーは自動的に管理されます。ssh-agent
プロセスがローカルユーザーに対して実行されていない場合は、バックグラウンドタスクとして開始します。Copy to Clipboard Copied! Toggle word wrap Toggle overflow eval "$(ssh-agent -s)"
$ eval "$(ssh-agent -s)"
出力例
Copy to Clipboard Copied! Toggle word wrap Toggle overflow Agent pid 31874
Agent pid 31874
注記クラスターが FIPS モードにある場合は、FIPS 準拠のアルゴリズムのみを使用して SSH キーを生成します。鍵は RSA または ECDSA のいずれかである必要があります。
SSH プライベートキーを
ssh-agent
に追加します。Copy to Clipboard Copied! Toggle word wrap Toggle overflow ssh-add <path>/<file_name>
$ ssh-add <path>/<file_name>
1 - 1
~/.ssh/id_ed25519
などの、SSH プライベートキーのパスおよびファイル名を指定します。
出力例
Copy to Clipboard Copied! Toggle word wrap Toggle overflow Identity added: /home/<you>/<path>/<file_name> (<computer_name>)
Identity added: /home/<you>/<path>/<file_name> (<computer_name>)
次のステップ
- OpenShift Container Platform をインストールする際に、SSH パブリックキーをインストールプログラムに指定します。
4.4.4. 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
ファイルのサンプルCopy to Clipboard Copied! Toggle word wrap Toggle overflow apiVersion: v1 baseDomain: example.com compute: - hyperthreading: Enabled name: worker platform: aws: amiID: ami-06c4d345f7c207239 type: m5.4xlarge replicas: 3 metadata: name: test-cluster platform: aws: region: us-east-2 sshKey: ssh-ed25519 AAAA... pullSecret: '{"auths": ...}'
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": ...}'
4.4.5. インストールプログラムの取得
OpenShift Container Platform をインストールする前に、インストールに使用しているホストにインストールファイルをダウンロードします。
前提条件
- 500 MB のローカルディスク領域がある Linux または macOS を実行するコンピューターが必要です。
手順
- OpenShift Cluster Manager サイトの インフラストラクチャープロバイダー ページにアクセスします。Red Hat アカウントがある場合は、認証情報を使用してログインします。アカウントがない場合はこれを作成します。
- インフラストラクチャープロバイダーを選択します。
インストールタイプのページに移動し、ホストオペレーティングシステムとアーキテクチャーに対応するインストールプログラムをダウンロードして、インストール設定ファイルを保存するディレクトリーにファイルを配置します。
重要インストールプログラムは、クラスターのインストールに使用するコンピューターにいくつかのファイルを作成します。クラスターのインストール完了後は、インストールプログラムおよびインストールプログラムが作成するファイルを保持する必要があります。ファイルはいずれもクラスターを削除するために必要になります。
重要インストールプログラムで作成されたファイルを削除しても、クラスターがインストール時に失敗した場合でもクラスターは削除されません。クラスターを削除するには、特定のクラウドプロバイダー用の OpenShift Container Platform のアンインストール手順を実行します。
インストールプログラムを展開します。たとえば、Linux オペレーティングシステムを使用するコンピューターで以下のコマンドを実行します。
Copy to Clipboard Copied! Toggle word wrap Toggle overflow tar -xvf openshift-install-linux.tar.gz
$ tar -xvf openshift-install-linux.tar.gz
- Red Hat OpenShift Cluster Manager からインストールプルシークレット をダウンロードします。このプルシークレットを使用し、OpenShift Container Platform コンポーネントのコンテナーイメージを提供する Quay.io など、組み込まれた各種の認証局によって提供されるサービスで認証できます。
4.4.6. インストール設定ファイルの作成
Amazon Web Services (AWS) での OpenShift Container Platform のインストールをカスタマイズできます。
前提条件
- OpenShift Container Platform インストールプログラムおよびクラスターのプルシークレットがある。
手順
install-config.yaml
ファイルを作成します。インストールプログラムが含まれるディレクトリーに切り替え、以下のコマンドを実行します。
Copy to Clipboard Copied! Toggle word wrap Toggle overflow ./openshift-install create install-config --dir <installation_directory>
$ ./openshift-install create install-config --dir <installation_directory>
1 - 1
<installation_directory>
の場合、インストールプログラムが作成するファイルを保存するためにディレクトリー名を指定します。
ディレクトリーを指定する場合:
-
ディレクトリーに
execute
権限があることを確認します。この権限は、インストールディレクトリーで Terraform バイナリーを実行するために必要です。 - 空のディレクトリーを使用します。ブートストラップ X.509 証明書などの一部のインストールアセットは有効期限が短いため、インストールディレクトリーを再利用しないでください。別のクラスターインストールの個別のファイルを再利用する必要がある場合は、それらをディレクトリーにコピーすることができます。ただし、インストールアセットのファイル名はリリース間で変更される可能性があります。インストールファイルを以前のバージョンの OpenShift Container Platform からコピーする場合は注意してコピーを行ってください。
プロンプト時に、クラウドの設定の詳細情報を指定します。
オプション: クラスターマシンにアクセスするために使用する SSH キーを選択します。
注記インストールのデバッグまたは障害復旧を実行する必要のある実稼働用の OpenShift Container Platform クラスターでは、
ssh-agent
プロセスが使用する SSH キーを指定します。- ターゲットに設定するプラットフォームとして AWS を選択します。
- Amazon Web Services (AWS) プロファイルをコンピューターに保存していない場合、インストールプログラムを実行するように設定したユーザーの AWS アクセスキー ID およびシークレットアクセスキーを入力します。
- クラスターのデプロイ先とする AWS リージョンを選択します。
- クラスターに設定した Route 53 サービスのベースドメインを選択します。
- クラスターの記述名を入力します。
install-config.yaml
ファイルを変更します。利用可能なパラメーターの詳細は、「インストール設定パラメーター」のセクションを参照してください。注記3 ノードクラスターをインストールする場合は、必ず
compute.replicas
パラメーターを0
に設定してください。これにより、クラスターのコントロールプレーンがスケジュール可能になります。詳細については、「AWS に 3 ノードクラスターをインストールする」を参照してください。install-config.yaml
ファイルをバックアップし、複数のクラスターをインストールするのに使用できるようにします。重要install-config.yaml
ファイルはインストールプロセス時に使用されます。このファイルを再利用する必要がある場合は、この段階でこれをバックアップしてください。
関連情報
4.4.6.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 で使用することがサポートされます。
関連情報
4.4.6.2. AWS のテスト済みインスタンスタイプ
以下の Amazon Web Services (AWS) インスタンスタイプは OpenShift Container Platform でテストされています。
AWS インスタンスには、次の表に記載されているマシンタイプを使用してください。表に記載されていないインスタンスタイプを使用する場合は、使用するインスタンスサイズが、「クラスターインストールの最小リソース要件」セクションに記載されている最小リソース要件と一致していることを確認してください。
例4.17 64 ビット x86 アーキテクチャーに基づくマシンタイプ
-
c4.*
-
c5.*
-
c5a.*
-
i3.*
-
m4.*
-
m5.*
-
m5a.*
-
m6a.*
-
m6i.*
-
r4.*
-
r5.*
-
r5a.*
-
r6i.*
-
t3.*
-
t3a.*
4.4.6.3. 64 ビット ARM インフラストラクチャー上の AWS のテスト済みインスタンスタイプ
次の Amazon Web Services (AWS) 64 ビット ARM インスタンスタイプは、OpenShift Container Platform でテストされています。
AWS ARM インスタンスには、次のチャートに含まれるマシンタイプを使用してください。チャートに記載されていないインスタンスタイプを使用する場合は、使用するインスタンスサイズが、「クラスターインストールの最小リソース要件」に記載されている最小リソース要件と一致していることを確認してください。
例4.18 64 ビット ARM アーキテクチャーに基づくマシンタイプ
-
c6g.*
-
c7g.*
-
m6g.*
-
m7g.*
-
r8g.*
4.4.6.4. AWS のカスタマイズされた install-config.yaml ファイルのサンプル
インストール設定ファイル install-config.yaml
をカスタマイズして、OpenShift Container Platform クラスターのプラットフォームに関する詳細を指定するか、必要なパラメーターの値を変更することができます。
このサンプルの YAML ファイルは参照用にのみ提供されます。インストールプログラムを使用して install-config.yaml
ファイルを取得し、これを変更する必要があります。
apiVersion: v1 baseDomain: example.com credentialsMode: Mint controlPlane: hyperthreading: Enabled name: master platform: aws: zones: - us-west-2a - us-west-2b rootVolume: iops: 4000 size: 500 type: io1 metadataService: authentication: Optional type: m6i.xlarge replicas: 3 compute: - hyperthreading: Enabled name: worker platform: aws: rootVolume: iops: 2000 size: 500 type: io1 metadataService: authentication: Optional type: c5.4xlarge zones: - us-west-2c replicas: 3 metadata: name: test-cluster networking: clusterNetwork: - cidr: 10.128.0.0/14 hostPrefix: 23 machineNetwork: - cidr: 10.0.0.0/16 networkType: OVNKubernetes serviceNetwork: - 172.30.0.0/16 platform: aws: region: us-west-2 propagateUserTags: true userTags: adminContact: jdoe costCenter: 7536 amiID: ami-0c5d3e03c0ab9b19a serviceEndpoints: - name: ec2 url: https://vpce-id.ec2.us-west-2.vpce.amazonaws.com fips: false sshKey: ssh-ed25519 AAAA... pullSecret: '{"auths": ...}'
apiVersion: v1
baseDomain: example.com
credentialsMode: Mint
controlPlane:
hyperthreading: Enabled
name: master
platform:
aws:
zones:
- us-west-2a
- us-west-2b
rootVolume:
iops: 4000
size: 500
type: io1
metadataService:
authentication: Optional
type: m6i.xlarge
replicas: 3
compute:
- hyperthreading: Enabled
name: worker
platform:
aws:
rootVolume:
iops: 2000
size: 500
type: io1
metadataService:
authentication: Optional
type: c5.4xlarge
zones:
- us-west-2c
replicas: 3
metadata:
name: test-cluster
networking:
clusterNetwork:
- cidr: 10.128.0.0/14
hostPrefix: 23
machineNetwork:
- cidr: 10.0.0.0/16
networkType: OVNKubernetes
serviceNetwork:
- 172.30.0.0/16
platform:
aws:
region: us-west-2
propagateUserTags: true
userTags:
adminContact: jdoe
costCenter: 7536
amiID: ami-0c5d3e03c0ab9b19a
serviceEndpoints:
- name: ec2
url: https://vpce-id.ec2.us-west-2.vpce.amazonaws.com
fips: false
sshKey: ssh-ed25519 AAAA...
pullSecret: '{"auths": ...}'
- 1 12 14 20
- 必須。インストールプログラムはこの値の入力を求めるプロンプトを出します。
- 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
- クラスターのマシンを起動するために使用される AMI の ID。これが設定されている場合、AMI はクラスターと同じリージョンに属する必要があります。
- 17
- AWS サービスエンドポイント。未確認の AWS リージョンにインストールする場合は、カスタムエンドポイントが必要です。エンドポイントの URL は
https
プロトコルを使用しなければならず、ホストは証明書を信頼する必要があります。 - 18
- FIPS モードを有効または無効にするかどうか。デフォルトでは、FIPS モードは有効にされません。FIPS モードが有効にされている場合、OpenShift Container Platform が実行される Red Hat Enterprise Linux CoreOS (RHCOS) マシンがデフォルトの Kubernetes 暗号スイートをバイパスし、代わりに RHCOS で提供される暗号モジュールを使用します。重要
クラスターで FIPS モードを有効にするには、FIPS モードで動作するように設定された Red Hat Enterprise Linux (RHEL) コンピューターからインストールプログラムを実行する必要があります。RHEL での FIPS モードの設定の詳細は、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 暗号化ライブラリーを使用します。
- 19
- クラスター内のマシンにアクセスするために使用する
sshKey
値をオプションで指定できます。注記インストールのデバッグまたは障害復旧を実行する必要のある実稼働用の OpenShift Container Platform クラスターでは、
ssh-agent
プロセスが使用する SSH キーを指定します。
4.4.6.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 apiVersion: v1 baseDomain: my.domain.com proxy: httpProxy: http://<username>:<pswd>@<ip>:<port> httpsProxy: https://<username>:<pswd>@<ip>:<port> noProxy: ec2.<aws_region>.amazonaws.com,elasticloadbalancing.<aws_region>.amazonaws.com,s3.<aws_region>.amazonaws.com additionalTrustBundle: | -----BEGIN CERTIFICATE----- <MY_TRUSTED_CA_CERT> -----END CERTIFICATE----- additionalTrustBundlePolicy: <policy_to_add_additionalTrustBundle>
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
コマンドを使用してデプロイメントを再起動してからデプロイメントを完了します。以下に例を示します。Copy to Clipboard Copied! Toggle word wrap Toggle overflow ./openshift-install wait-for install-complete --log-level debug
$ ./openshift-install wait-for install-complete --log-level debug
- ファイルを保存し、OpenShift Container Platform のインストール時にこれを参照します。
インストールプログラムは、指定の install-config.yaml
ファイルのプロキシー設定を使用する cluster
という名前のクラスター全体のプロキシーを作成します。プロキシー設定が指定されていない場合、cluster
Proxy
オブジェクトが依然として作成されますが、これには spec
がありません。
cluster
という名前の Proxy
オブジェクトのみがサポートされ、追加のプロキシーを作成することはできません。
4.4.7. バイナリーのダウンロードによる OpenShift CLI のインストール
コマンドラインインターフェイスを使用して OpenShift Container Platform と対話するために CLI (oc
) をインストールすることができます。oc
は Linux、Windows、または macOS にインストールできます。
以前のバージョンの oc
をインストールしている場合、これを使用して OpenShift Container Platform 4.15 のすべてのコマンドを実行することはできません。新規バージョンの oc
をダウンロードし、インストールします。
Linux への OpenShift CLI のインストール
以下の手順を使用して、OpenShift CLI (oc
) バイナリーを Linux にインストールできます。
手順
- Red Hat カスタマーポータルの OpenShift Container Platform ダウンロードページ に移動します。
- Product Variant ドロップダウンリストからアーキテクチャーを選択します。
- バージョン ドロップダウンリストから適切なバージョンを選択します。
- OpenShift v4.15 Linux Client エントリーの横にある Download Now をクリックして、ファイルを保存します。
アーカイブを展開します。
Copy to Clipboard Copied! Toggle word wrap Toggle overflow tar xvf <file>
$ tar xvf <file>
oc
バイナリーを、PATH
にあるディレクトリーに配置します。PATH
を確認するには、以下のコマンドを実行します。Copy to Clipboard Copied! Toggle word wrap Toggle overflow echo $PATH
$ echo $PATH
検証
OpenShift CLI のインストール後に、
oc
コマンドを使用して利用できます。Copy to Clipboard Copied! Toggle word wrap Toggle overflow oc <command>
$ oc <command>
Windows への OpenShift CLI のインストール
以下の手順を使用して、OpenShift CLI (oc
) バイナリーを Windows にインストールできます。
手順
- Red Hat カスタマーポータルの OpenShift Container Platform ダウンロードページ に移動します。
- バージョン ドロップダウンリストから適切なバージョンを選択します。
- OpenShift v4.15 Windows Client エントリーの横にある Download Now をクリックして、ファイルを保存します。
- ZIP プログラムでアーカイブを展開します。
oc
バイナリーを、PATH
にあるディレクトリーに移動します。PATH
を確認するには、コマンドプロンプトを開いて以下のコマンドを実行します。Copy to Clipboard Copied! Toggle word wrap Toggle overflow path
C:\> path
検証
OpenShift CLI のインストール後に、
oc
コマンドを使用して利用できます。Copy to Clipboard Copied! Toggle word wrap Toggle overflow oc <command>
C:\> oc <command>
macOS への OpenShift CLI のインストール
以下の手順を使用して、OpenShift CLI (oc
) バイナリーを macOS にインストールできます。
手順
- Red Hat カスタマーポータルの OpenShift Container Platform ダウンロードページ に移動します。
- バージョン ドロップダウンリストから適切なバージョンを選択します。
OpenShift v4.15 macOS Client エントリーの横にある Download Now をクリックして、ファイルを保存します。
注記macOS arm64 の場合は、OpenShift v4.15 macOS arm64 Client エントリーを選択します。
- アーカイブを展開し、解凍します。
oc
バイナリーをパスにあるディレクトリーに移動します。PATH
を確認するには、ターミナルを開き、以下のコマンドを実行します。Copy to Clipboard Copied! Toggle word wrap Toggle overflow echo $PATH
$ echo $PATH
検証
oc
コマンドを使用してインストールを確認します。Copy to Clipboard Copied! Toggle word wrap Toggle overflow oc <command>
$ oc <command>
4.4.8. 管理者レベルのシークレットを kube-system プロジェクトに保存する代替方法
デフォルトでは、管理者のシークレットは kube-system
プロジェクトに保存されます。install-config.yaml
ファイルの credentialsMode
パラメーターを Manual
に設定した場合は、次のいずれかの代替手段を使用する必要があります。
- 長期クラウド認証情報を手動で管理するには、長期認証情報を手動で作成する の手順に従ってください。
- クラスターの外部で管理される短期認証情報を個々のコンポーネントに対して実装するには、短期認証情報を使用するように AWS クラスターを設定する の手順に従ってください。
4.4.8.1. 長期認証情報を手動で作成する
Cloud Credential Operator (CCO) は、クラウドアイデンティティーおよびアクセス管理 (IAM) API に到達できない環境にインストールする前に手動モードに配置できます。管理者はクラスター kube-system
namespace に管理者レベルの認証情報シークレットを保存しないようにします。
手順
install-config.yaml
設定ファイルのcredentialsMode
パラメーターをManual
に設定しなかった場合は、次のように値を変更します。設定ファイルのサンプルスニペット
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 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>
ここで、
<installation_directory>
は、インストールプログラムがファイルを作成するディレクトリーに置き換えます。次のコマンドを実行して、インストールファイルのリリースイメージを
$RELEASE_IMAGE
変数に設定します。Copy to Clipboard Copied! Toggle word wrap Toggle overflow RELEASE_IMAGE=$(./openshift-install version | awk '/release image/ {print $3}')
$ RELEASE_IMAGE=$(./openshift-install version | awk '/release image/ {print $3}')
以下のコマンドを実行して、OpenShift Container Platform リリースイメージから
CredentialsRequest
カスタムリソース (CR) のリストを抽出します。Copy to Clipboard Copied! Toggle word wrap Toggle overflow oc adm release extract \ --from=$RELEASE_IMAGE \ --credentials-requests \ --included \ --install-config=<path_to_directory_with_installation_configuration>/install-config.yaml \ --to=<path_to_directory_for_credentials_requests>
$ 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
オブジェクトCopy to Clipboard Copied! Toggle word wrap Toggle overflow 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: "*" ...
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
オブジェクトのサンプルCopy to Clipboard Copied! Toggle word wrap Toggle overflow 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> ...
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
オブジェクトCopy to Clipboard Copied! Toggle word wrap Toggle overflow 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>
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.4.8.2. 短期認証情報を使用するように AWS クラスターを設定
AWS Security Token Service (STS) を使用するように設定されたクラスターをインストールするには、CCO ユーティリティーを設定し、クラスターに必要な AWS リソースを作成する必要があります。
4.4.8.2.1. Cloud Credential Operator ユーティリティーの設定
Cloud Credential Operator (CCO) が手動モードで動作しているときにクラスターの外部からクラウドクレデンシャルを作成および管理するには、CCO ユーティリティー (ccoctl
) バイナリーを抽出して準備します。
ccoctl
ユーティリティーは、Linux 環境で実行する必要がある Linux バイナリーです。
前提条件
- クラスター管理者のアクセスを持つ OpenShift Container Platform アカウントを使用できる。
-
OpenShift CLI (
oc
) がインストールされている。
ccoctl
ユーティリティー用の AWS アカウントを作成し、次の権限で使用できるようにしました。例4.19 必要な 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.20 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 リリースイメージの変数を設定します。
Copy to Clipboard Copied! Toggle word wrap Toggle overflow RELEASE_IMAGE=$(./openshift-install version | awk '/release image/ {print $3}')
$ RELEASE_IMAGE=$(./openshift-install version | awk '/release image/ {print $3}')
以下のコマンドを実行して、OpenShift Container Platform リリースイメージから CCO コンテナーイメージを取得します。
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 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)
注記$RELEASE_IMAGE
のアーキテクチャーが、ccoctl
ツールを使用する環境のアーキテクチャーと一致していることを確認してください。以下のコマンドを実行して、OpenShift Container Platform リリースイメージ内の CCO コンテナーイメージから
ccoctl
バイナリーを抽出します。Copy to Clipboard Copied! Toggle word wrap Toggle overflow oc image extract $CCO_IMAGE --file="/usr/bin/ccoctl" -a ~/.pull-secret
$ oc image extract $CCO_IMAGE --file="/usr/bin/ccoctl" -a ~/.pull-secret
次のコマンドを実行して、権限を変更して
ccoctl
を実行可能にします。Copy to Clipboard Copied! Toggle word wrap Toggle overflow chmod 775 ccoctl
$ chmod 775 ccoctl
検証
ccoctl
が使用できることを確認するには、help ファイルを表示します。コマンドを実行するときは、相対ファイル名を使用します。以下に例を示します。Copy to Clipboard Copied! Toggle word wrap Toggle overflow ./ccoctl.rhel9
$ ./ccoctl.rhel9
出力例
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 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.
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.4.8.2.2. Cloud Credential Operator ユーティリティーを使用した AWS リソースの作成
AWS リソースを作成するときは、次のオプションがあります。
-
ccoctl aws create-all
コマンドを使用して AWS リソースを自動的に作成できます。これはリソースを作成する最も簡単な方法です。単一コマンドでの AWS リソースの作成 を参照してください。 -
AWS リソースの変更前に
ccoctl
ツールが作成する JSON ファイルを確認する必要がある場合や、ccoctl
ツールが AWS リソースを自動作成するために使用するプロセスが組織の要件を満たさない場合は、AWS リソースを個別に作成できます。AWS リソースの個別の作成 を参照してください。
4.4.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
変数に設定します。Copy to Clipboard Copied! Toggle word wrap Toggle overflow RELEASE_IMAGE=$(./openshift-install version | awk '/release image/ {print $3}')
$ RELEASE_IMAGE=$(./openshift-install version | awk '/release image/ {print $3}')
以下のコマンドを実行して、OpenShift Container Platform リリースイメージから
CredentialsRequest
オブジェクトのリストを抽出します。Copy to Clipboard Copied! Toggle word wrap Toggle overflow oc adm release extract \ --from=$RELEASE_IMAGE \ --credentials-requests \ --included \ --install-config=<path_to_directory_with_installation_configuration>/install-config.yaml \ --to=<path_to_directory_for_credentials_requests>
$ 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
オブジェクトをすべて処理します。Copy to Clipboard Copied! Toggle word wrap Toggle overflow ccoctl aws create-all \ --name=<name> \ --region=<aws_region> \ --credentials-requests-dir=<path_to_credentials_requests_directory> \ --output-dir=<path_to_ccoctl_output_dir> \ --create-private-s3-bucket
$ 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
ディレクトリーのファイルを一覧表示します。Copy to Clipboard Copied! Toggle word wrap Toggle overflow ls <path_to_ccoctl_output_dir>/manifests
$ ls <path_to_ccoctl_output_dir>/manifests
出力例
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 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
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.4.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 キーファイルを生成します。
Copy to Clipboard Copied! Toggle word wrap Toggle overflow ccoctl aws create-key-pair
$ ccoctl aws create-key-pair
出力例
Copy 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 installer
serviceaccount-signer.private
およびserviceaccount-signer.public
は、生成されるキーファイルです。このコマンドは、クラスターがインストール時に必要とするプライベートキーを
/<path_to_ccoctl_output_dir>/tls/bound-service-account-signing-key.key
に作成します。次のコマンドを実行して、AWS 上に OpenID Connect ID プロバイダーと S3 バケットを作成します。
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 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.public
3 出力例
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.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
変数に設定します。Copy to Clipboard Copied! Toggle word wrap Toggle overflow RELEASE_IMAGE=$(./openshift-install version | awk '/release image/ {print $3}')
$ RELEASE_IMAGE=$(./openshift-install version | awk '/release image/ {print $3}')
OpenShift Container Platform リリースイメージから
CredentialsRequest
オブジェクトの一覧を抽出します。Copy to Clipboard Copied! Toggle word wrap Toggle overflow oc adm release extract \ --from=$RELEASE_IMAGE \ --credentials-requests \ --included \ --install-config=<path_to_directory_with_installation_configuration>/install-config.yaml \ --to=<path_to_directory_for_credentials_requests>
$ 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
オブジェクトをすべて処理します。Copy to Clipboard Copied! Toggle word wrap Toggle overflow 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.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
ディレクトリーのファイルを一覧表示します。Copy to Clipboard Copied! Toggle word wrap Toggle overflow ls <path_to_ccoctl_output_dir>/manifests
$ ls <path_to_ccoctl_output_dir>/manifests
出力例
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 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
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.4.8.2.3. Cloud Credential Operator ユーティリティーマニフェストの組み込み
個々のコンポーネントに対してクラスターの外部で管理される短期セキュリティー認証情報を実装するには、Cloud Credential Operator ユーティリティー (ccoctl
) が作成したマニフェストファイルを、インストールプログラムの正しいディレクトリーに移動する必要があります。
前提条件
- クラスターをホストするクラウドプラットフォームでアカウントを設定しました。
-
Cloud Credential Operator ユーティリティー (
ccoctl
) が設定されている。 -
ccoctl
ユーティリティーを使用して、クラスターに必要なクラウドプロバイダーリソースを作成している。
手順
install-config.yaml
設定ファイルのcredentialsMode
パラメーターをManual
に設定しなかった場合は、次のように値を変更します。設定ファイルのサンプルスニペット
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 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>
ここで、
<installation_directory>
は、インストールプログラムがファイルを作成するディレクトリーに置き換えます。次のコマンドを実行して、
ccoctl
ユーティリティーが生成したマニフェストを、インストールプログラムが作成したmanifests
ディレクトリーにコピーします。Copy to Clipboard Copied! Toggle word wrap Toggle overflow cp /<path_to_ccoctl_output_dir>/manifests/* ./manifests/
$ cp /<path_to_ccoctl_output_dir>/manifests/* ./manifests/
秘密鍵を含む
tls
ディレクトリーをインストールディレクトリーにコピーします。Copy to Clipboard Copied! Toggle word wrap Toggle overflow cp -a /<path_to_ccoctl_output_dir>/tls .
$ cp -a /<path_to_ccoctl_output_dir>/tls .
4.4.9. クラスターのデプロイ
互換性のあるクラウドプラットフォームに OpenShift Container Platform をインストールできます。
インストールプログラムの create cluster
コマンドは、初期インストール時に 1 回だけ実行できます。
前提条件
- クラスターをホストするクラウドプラットフォームでアカウントを設定しました。
- OpenShift Container Platform インストールプログラムおよびクラスターのプルシークレットがある。
- ホスト上のクラウドプロバイダーアカウントに、クラスターをデプロイするための適切な権限があることが確認されました。アカウントの権限が正しくないと、インストールプロセスが失敗し、不足している権限を示すエラーメッセージが表示されます。
手順
インストールプログラムが含まれるディレクトリーに切り替え、クラスターのデプロイメントを初期化します。
Copy to Clipboard Copied! Toggle word wrap Toggle overflow ./openshift-install create cluster --dir <installation_directory> \ --log-level=info
$ ./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
...
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.4.10. CLI の使用によるクラスターへのログイン
クラスター kubeconfig
ファイルをエクスポートし、デフォルトシステムユーザーとしてクラスターにログインできます。kubeconfig
ファイルには、クライアントを正しいクラスターおよび API サーバーに接続するために CLI で使用されるクラスターに関する情報が含まれます。このファイルはクラスターに固有のファイルであり、OpenShift Container Platform のインストール時に作成されます。
前提条件
- OpenShift Container Platform クラスターをデプロイしていること。
-
oc
CLI をインストールしていること。
手順
kubeadmin
認証情報をエクスポートします。Copy to Clipboard Copied! Toggle word wrap Toggle overflow export KUBECONFIG=<installation_directory>/auth/kubeconfig
$ export KUBECONFIG=<installation_directory>/auth/kubeconfig
1 - 1
<installation_directory>
には、インストールファイルを保存したディレクトリーへのパスを指定します。
エクスポートされた設定を使用して、
oc
コマンドを正常に実行できることを確認します。Copy to Clipboard Copied! Toggle word wrap Toggle overflow oc whoami
$ oc whoami
出力例
Copy to Clipboard Copied! Toggle word wrap Toggle overflow system:admin
system:admin
4.4.11. Web コンソールを使用したクラスターへのログイン
kubeadmin
ユーザーは、OpenShift Container Platform のインストール後はデフォルトで存在します。OpenShift Container Platform Web コンソールを使用し、kubeadmin
ユーザーとしてクラスターにログインできます。
前提条件
- インストールホストにアクセスできる。
- クラスターのインストールを完了しており、すべてのクラスター Operator が利用可能である。
手順
インストールホストで
kubeadmin-password
ファイルからkubeadmin
ユーザーのパスワードを取得します。Copy to Clipboard Copied! Toggle word wrap Toggle overflow cat <installation_directory>/auth/kubeadmin-password
$ cat <installation_directory>/auth/kubeadmin-password
注記または、インストールホストで
<installation_directory>/.openshift_install.log
ログファイルからkubeadmin
パスワードを取得できます。OpenShift Container Platform Web コンソールルートをリスト表示します。
Copy to Clipboard Copied! Toggle word wrap Toggle overflow oc get routes -n openshift-console | grep 'console-openshift'
$ oc get routes -n openshift-console | grep 'console-openshift'
注記または、インストールホストで
<installation_directory>/.openshift_install.log
ログファイルからで OpenShift Container Platform ルートを取得できます。出力例
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 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 None
-
Web ブラウザーで前述のコマンドの出力で詳細に説明されたルートに移動し、
kubeadmin
ユーザーとしてログインします。
関連情報
- OpenShift Container Platform Web コンソールへのアクセスと理解に関する詳細は、Web コンソールへのアクセス を参照してください。
4.4.12. OpenShift Container Platform の Telemetry アクセス
OpenShift Container Platform 4.15 では、クラスターの健全性および正常に実行された更新についてのメトリクスを提供するためにデフォルトで実行される Telemetry サービスにも、インターネットアクセスが必要です。クラスターがインターネットに接続されている場合、Telemetry は自動的に実行され、クラスターは OpenShift Cluster Manager に登録されます。
OpenShift Cluster Manager インベントリーが正常である (Telemetry によって自動的に維持、または OpenShift Cluster Manager を使用して手動で維持) ことを確認した後に、subscription watch を使用 して、アカウントまたはマルチクラスターレベルで OpenShift Container Platform サブスクリプションを追跡します。
関連情報
- Telemetry サービスの詳細は、リモートヘルスモニタリング を参照してください。
4.4.13. 次のステップ
- インストールを検証 します。
- クラスターをカスタマイズ します。
- 必要に応じて、リモートヘルスレポートをオプトアウト できます。
- 必要に応じて、クラウドプロバイダーの認証情報を削除 できます。
4.5. ネットワークのカスタマイズによる AWS へのクラスターのインストール
OpenShift Container Platform バージョン 4.15 では、カスタマイズされたネットワーク設定オプションを使用して、Amazon Web Services (AWS) にクラスターをインストールできます。ネットワーク設定をカスタマイズすることにより、クラスターは環境内の既存の IP アドレスの割り当てと共存でき、既存の MTU および VXLAN 設定と統合できます。
大半のネットワーク設定パラメーターはインストール時に設定する必要があり、実行中のクラスターで変更できるのは kubeProxy
設定パラメーターのみになります。
4.5.1. 前提条件
- OpenShift Container Platform のインストールおよび更新 プロセスの詳細を確認した。
- クラスターインストール方法の選択およびそのユーザー向けの準備 を確認した。
クラスターをホストするために AWS アカウントを設定 している。
重要AWS プロファイルがご使用のコンピューターに保存されている場合、マルチファクター認証デバイスを使用中に生成した一時的なセッショントークンを使用することはできません。クラスターは継続的に現行の AWS 認証情報を使用して、クラスターの有効期間全体にわたって AWS リソースを作成するため、キーをベースとした有効期間の長い認証情報を使用する必要があります。適切なキーを生成するには、AWS ドキュメントの Managing Access Keys for IAM Users を参照してください。キーは、インストールプログラムの実行時に指定できます。
- ファイアウォールを使用する場合は、クラスターがアクセスを必要とするサイトを許可するようにファイアウォールを設定する必要がある。
4.5.2. OpenShift Container Platform のインターネットアクセス
OpenShift Container Platform 4.15 では、クラスターをインストールするためにインターネットアクセスが必要になります。
インターネットへのアクセスは以下を実行するために必要です。
- OpenShift Cluster Manager にアクセスし、インストールプログラムをダウンロードし、サブスクリプション管理を実行します。クラスターにインターネットアクセスがあり、Telemetry を無効にしない場合、そのサービスは有効なサブスクリプションでクラスターを自動的に使用します。
- クラスターのインストールに必要なパッケージを取得するために Quay.io にアクセスします。
- クラスターの更新を実行するために必要なパッケージを取得します。
クラスターでインターネットに直接アクセスできない場合、プロビジョニングする一部のタイプのインフラストラクチャーでネットワークが制限されたインストールを実行できます。このプロセスで、必要なコンテンツをダウンロードし、これを使用してミラーレジストリーにインストールパッケージを設定します。インストールタイプによっては、クラスターのインストール環境でインターネットアクセスが不要となる場合があります。クラスターを更新する前に、ミラーレジストリーのコンテンツを更新します。
4.5.3. クラスターノードの 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 オペレーティングシステムを使用するコンピューターで以下のコマンドを実行します。
Copy to Clipboard Copied! Toggle word wrap Toggle overflow ssh-keygen -t ed25519 -N '' -f <path>/<file_name>
$ 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 キーを表示します。
Copy to Clipboard Copied! Toggle word wrap Toggle overflow cat <path>/<file_name>.pub
$ cat <path>/<file_name>.pub
たとえば、次のコマンドを実行して
~/.ssh/id_ed25519.pub
公開鍵を表示します。Copy to Clipboard Copied! Toggle word wrap Toggle overflow cat ~/.ssh/id_ed25519.pub
$ cat ~/.ssh/id_ed25519.pub
ローカルユーザーの SSH エージェントに SSH 秘密鍵 ID が追加されていない場合は、それを追加します。キーの SSH エージェント管理は、クラスターノードへのパスワードなしの SSH 認証、または
./openshift-install gather
コマンドを使用する場合は必要になります。注記一部のディストリビューションでは、
~/.ssh/id_rsa
および~/.ssh/id_dsa
などのデフォルトの SSH 秘密鍵のアイデンティティーは自動的に管理されます。ssh-agent
プロセスがローカルユーザーに対して実行されていない場合は、バックグラウンドタスクとして開始します。Copy to Clipboard Copied! Toggle word wrap Toggle overflow eval "$(ssh-agent -s)"
$ eval "$(ssh-agent -s)"
出力例
Copy to Clipboard Copied! Toggle word wrap Toggle overflow Agent pid 31874
Agent pid 31874
注記クラスターが FIPS モードにある場合は、FIPS 準拠のアルゴリズムのみを使用して SSH キーを生成します。鍵は RSA または ECDSA のいずれかである必要があります。
SSH プライベートキーを
ssh-agent
に追加します。Copy to Clipboard Copied! Toggle word wrap Toggle overflow ssh-add <path>/<file_name>
$ ssh-add <path>/<file_name>
1 - 1
~/.ssh/id_ed25519
などの、SSH プライベートキーのパスおよびファイル名を指定します。
出力例
Copy to Clipboard Copied! Toggle word wrap Toggle overflow Identity added: /home/<you>/<path>/<file_name> (<computer_name>)
Identity added: /home/<you>/<path>/<file_name> (<computer_name>)
次のステップ
- OpenShift Container Platform をインストールする際に、SSH パブリックキーをインストールプログラムに指定します。
4.5.4. インストールプログラムの取得
OpenShift Container Platform をインストールする前に、インストールに使用しているホストにインストールファイルをダウンロードします。
前提条件
- 500 MB のローカルディスク領域がある Linux または macOS を実行するコンピューターが必要です。
手順
- OpenShift Cluster Manager サイトの インフラストラクチャープロバイダー ページにアクセスします。Red Hat アカウントがある場合は、認証情報を使用してログインします。アカウントがない場合はこれを作成します。
- インフラストラクチャープロバイダーを選択します。
インストールタイプのページに移動し、ホストオペレーティングシステムとアーキテクチャーに対応するインストールプログラムをダウンロードして、インストール設定ファイルを保存するディレクトリーにファイルを配置します。
重要インストールプログラムは、クラスターのインストールに使用するコンピューターにいくつかのファイルを作成します。クラスターのインストール完了後は、インストールプログラムおよびインストールプログラムが作成するファイルを保持する必要があります。ファイルはいずれもクラスターを削除するために必要になります。
重要インストールプログラムで作成されたファイルを削除しても、クラスターがインストール時に失敗した場合でもクラスターは削除されません。クラスターを削除するには、特定のクラウドプロバイダー用の OpenShift Container Platform のアンインストール手順を実行します。
インストールプログラムを展開します。たとえば、Linux オペレーティングシステムを使用するコンピューターで以下のコマンドを実行します。
Copy to Clipboard Copied! Toggle word wrap Toggle overflow tar -xvf openshift-install-linux.tar.gz
$ tar -xvf openshift-install-linux.tar.gz
- Red Hat OpenShift Cluster Manager からインストールプルシークレット をダウンロードします。このプルシークレットを使用し、OpenShift Container Platform コンポーネントのコンテナーイメージを提供する Quay.io など、組み込まれた各種の認証局によって提供されるサービスで認証できます。
4.5.5. ネットワーク設定フェーズ
OpenShift Container Platform をインストールする前に、ネットワーク設定をカスタマイズできる 2 つのフェーズがあります。
- フェーズ 1
マニフェストファイルを作成する前に、
install-config.yaml
ファイルで以下のネットワーク関連のフィールドをカスタマイズできます。-
networking.networkType
-
networking.clusterNetwork
-
networking.serviceNetwork
networking.machineNetwork
これらのフィールドの詳細は、インストール設定パラメーター を参照してください。
注記優先される NIC が置かれている CIDR に一致する
networking.machineNetwork
を設定します。重要CIDR 範囲
172.17.0.0/16
は libVirt によって予約されています。この範囲、またはこの範囲と重複する範囲をクラスター内のネットワークに使用することはできません。
-
- フェーズ 2
-
openshift-install create manifests
を実行してマニフェストファイルを作成した後に、変更するフィールドのみでカスタマイズされた Cluster Network Operator マニフェストを定義できます。マニフェストを使用して、高度なネットワーク設定を指定できます。
フェーズ 2 で、install-config.yaml
ファイルのフェーズ 1 で指定した値を上書きすることはできません。ただし、フェーズ 2 でネットワークプラグインをさらにカスタマイズできます。
4.5.6. インストール設定ファイルの作成
Amazon Web Services (AWS) での OpenShift Container Platform のインストールをカスタマイズできます。
前提条件
- OpenShift Container Platform インストールプログラムおよびクラスターのプルシークレットがある。
手順
install-config.yaml
ファイルを作成します。インストールプログラムが含まれるディレクトリーに切り替え、以下のコマンドを実行します。
Copy to Clipboard Copied! Toggle word wrap Toggle overflow ./openshift-install create install-config --dir <installation_directory>
$ ./openshift-install create install-config --dir <installation_directory>
1 - 1
<installation_directory>
の場合、インストールプログラムが作成するファイルを保存するためにディレクトリー名を指定します。
ディレクトリーを指定する場合:
-
ディレクトリーに
execute
権限があることを確認します。この権限は、インストールディレクトリーで Terraform バイナリーを実行するために必要です。 - 空のディレクトリーを使用します。ブートストラップ X.509 証明書などの一部のインストールアセットは有効期限が短いため、インストールディレクトリーを再利用しないでください。別のクラスターインストールの個別のファイルを再利用する必要がある場合は、それらをディレクトリーにコピーすることができます。ただし、インストールアセットのファイル名はリリース間で変更される可能性があります。インストールファイルを以前のバージョンの OpenShift Container Platform からコピーする場合は注意してコピーを行ってください。
プロンプト時に、クラウドの設定の詳細情報を指定します。
オプション: クラスターマシンにアクセスするために使用する SSH キーを選択します。
注記インストールのデバッグまたは障害復旧を実行する必要のある実稼働用の OpenShift Container Platform クラスターでは、
ssh-agent
プロセスが使用する SSH キーを指定します。- ターゲットに設定するプラットフォームとして AWS を選択します。
- Amazon Web Services (AWS) プロファイルをコンピューターに保存していない場合、インストールプログラムを実行するように設定したユーザーの AWS アクセスキー ID およびシークレットアクセスキーを入力します。
- クラスターのデプロイ先とする AWS リージョンを選択します。
- クラスターに設定した Route 53 サービスのベースドメインを選択します。
- クラスターの記述名を入力します。
-
install-config.yaml
ファイルを変更します。利用可能なパラメーターの詳細は、「インストール設定パラメーター」のセクションを参照してください。 install-config.yaml
ファイルをバックアップし、複数のクラスターをインストールするのに使用できるようにします。重要install-config.yaml
ファイルはインストールプロセス時に使用されます。このファイルを再利用する必要がある場合は、この段階でこれをバックアップしてください。
関連情報
4.5.6.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 で使用することがサポートされます。
関連情報
4.5.6.2. AWS のテスト済みインスタンスタイプ
以下の Amazon Web Services (AWS) インスタンスタイプは OpenShift Container Platform でテストされています。
AWS インスタンスには、次の表に記載されているマシンタイプを使用してください。表に記載されていないインスタンスタイプを使用する場合は、使用するインスタンスサイズが、「クラスターインストールの最小リソース要件」セクションに記載されている最小リソース要件と一致していることを確認してください。
例4.21 64 ビット x86 アーキテクチャーに基づくマシンタイプ
-
c4.*
-
c5.*
-
c5a.*
-
i3.*
-
m4.*
-
m5.*
-
m5a.*
-
m6a.*
-
m6i.*
-
r4.*
-
r5.*
-
r5a.*
-
r6i.*
-
t3.*
-
t3a.*
4.5.6.3. 64 ビット ARM インフラストラクチャー上の AWS のテスト済みインスタンスタイプ
次の Amazon Web Services (AWS) 64 ビット ARM インスタンスタイプは、OpenShift Container Platform でテストされています。
AWS ARM インスタンスには、次のチャートに含まれるマシンタイプを使用してください。チャートに記載されていないインスタンスタイプを使用する場合は、使用するインスタンスサイズが、「クラスターインストールの最小リソース要件」に記載されている最小リソース要件と一致していることを確認してください。
例4.22 64 ビット ARM アーキテクチャーに基づくマシンタイプ
-
c6g.*
-
c7g.*
-
m6g.*
-
m7g.*
-
r8g.*
4.5.6.4. AWS のカスタマイズされた install-config.yaml ファイルのサンプル
インストール設定ファイル install-config.yaml
をカスタマイズして、OpenShift Container Platform クラスターのプラットフォームに関する詳細を指定するか、必要なパラメーターの値を変更することができます。
このサンプルの YAML ファイルは参照用にのみ提供されます。インストールプログラムを使用して install-config.yaml
ファイルを取得し、これを変更する必要があります。
apiVersion: v1 baseDomain: example.com credentialsMode: Mint controlPlane: hyperthreading: Enabled name: master platform: aws: zones: - us-west-2a - us-west-2b rootVolume: iops: 4000 size: 500 type: io1 metadataService: authentication: Optional type: m6i.xlarge replicas: 3 compute: - hyperthreading: Enabled name: worker platform: aws: rootVolume: iops: 2000 size: 500 type: io1 metadataService: authentication: Optional type: c5.4xlarge zones: - us-west-2c replicas: 3 metadata: name: test-cluster networking: clusterNetwork: - cidr: 10.128.0.0/14 hostPrefix: 23 machineNetwork: - cidr: 10.0.0.0/16 networkType: OVNKubernetes serviceNetwork: - 172.30.0.0/16 platform: aws: region: us-west-2 propagateUserTags: true userTags: adminContact: jdoe costCenter: 7536 amiID: ami-0c5d3e03c0ab9b19a serviceEndpoints: - name: ec2 url: https://vpce-id.ec2.us-west-2.vpce.amazonaws.com fips: false sshKey: ssh-ed25519 AAAA... pullSecret: '{"auths": ...}'
apiVersion: v1
baseDomain: example.com
credentialsMode: Mint
controlPlane:
hyperthreading: Enabled
name: master
platform:
aws:
zones:
- us-west-2a
- us-west-2b
rootVolume:
iops: 4000
size: 500
type: io1
metadataService:
authentication: Optional
type: m6i.xlarge
replicas: 3
compute:
- hyperthreading: Enabled
name: worker
platform:
aws:
rootVolume:
iops: 2000
size: 500
type: io1
metadataService:
authentication: Optional
type: c5.4xlarge
zones:
- us-west-2c
replicas: 3
metadata:
name: test-cluster
networking:
clusterNetwork:
- cidr: 10.128.0.0/14
hostPrefix: 23
machineNetwork:
- cidr: 10.0.0.0/16
networkType: OVNKubernetes
serviceNetwork:
- 172.30.0.0/16
platform:
aws:
region: us-west-2
propagateUserTags: true
userTags:
adminContact: jdoe
costCenter: 7536
amiID: ami-0c5d3e03c0ab9b19a
serviceEndpoints:
- name: ec2
url: https://vpce-id.ec2.us-west-2.vpce.amazonaws.com
fips: false
sshKey: ssh-ed25519 AAAA...
pullSecret: '{"auths": ...}'
- 1 12 15 21
- 必須。インストールプログラムはこの値の入力を求めるプロンプトを出します。
- 2
- オプション: Cloud Credential Operator (CCO) に指定されたモードの使用を強制するには、このパラメーターを追加します。デフォルトでは、CCO は
kube-system
namespace のルート認証情報を使用して、認証情報の機能を動的に判断しようとします。CCO モードの詳細は、認証および認可 ガイドの「Cloud Credential Operator について」セクションを参照してください。 - 3 8 13 16
- これらのパラメーターおよび値を指定しない場合、インストールプログラムはデフォルトの値を指定します。
- 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 設定は、コンピュートマシンセットを使用して変更できます。
- 14
- インストールするクラスターネットワークプラグイン。サポートされる値はデフォルト値の
OVNKubernetes
のみです。 - 17
- クラスターのマシンを起動するために使用される AMI の ID。これが設定されている場合、AMI はクラスターと同じリージョンに属する必要があります。
- 18
- AWS サービスエンドポイント。未確認の AWS リージョンにインストールする場合は、カスタムエンドポイントが必要です。エンドポイントの URL は
https
プロトコルを使用しなければならず、ホストは証明書を信頼する必要があります。 - 19
- FIPS モードを有効または無効にするかどうか。デフォルトでは、FIPS モードは有効にされません。FIPS モードが有効にされている場合、OpenShift Container Platform が実行される Red Hat Enterprise Linux CoreOS (RHCOS) マシンがデフォルトの Kubernetes 暗号スイートをバイパスし、代わりに RHCOS で提供される暗号モジュールを使用します。重要
クラスターで FIPS モードを有効にするには、FIPS モードで動作するように設定された Red Hat Enterprise Linux (RHEL) コンピューターからインストールプログラムを実行する必要があります。RHEL での FIPS モードの設定の詳細は、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 暗号化ライブラリーを使用します。
- 20
- クラスター内のマシンにアクセスするために使用する
sshKey
値をオプションで指定できます。注記インストールのデバッグまたは障害復旧を実行する必要のある実稼働用の OpenShift Container Platform クラスターでは、
ssh-agent
プロセスが使用する SSH キーを指定します。
4.5.6.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 apiVersion: v1 baseDomain: my.domain.com proxy: httpProxy: http://<username>:<pswd>@<ip>:<port> httpsProxy: https://<username>:<pswd>@<ip>:<port> noProxy: ec2.<aws_region>.amazonaws.com,elasticloadbalancing.<aws_region>.amazonaws.com,s3.<aws_region>.amazonaws.com additionalTrustBundle: | -----BEGIN CERTIFICATE----- <MY_TRUSTED_CA_CERT> -----END CERTIFICATE----- additionalTrustBundlePolicy: <policy_to_add_additionalTrustBundle>
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
コマンドを使用してデプロイメントを再起動してからデプロイメントを完了します。以下に例を示します。Copy to Clipboard Copied! Toggle word wrap Toggle overflow ./openshift-install wait-for install-complete --log-level debug
$ ./openshift-install wait-for install-complete --log-level debug
- ファイルを保存し、OpenShift Container Platform のインストール時にこれを参照します。
インストールプログラムは、指定の install-config.yaml
ファイルのプロキシー設定を使用する cluster
という名前のクラスター全体のプロキシーを作成します。プロキシー設定が指定されていない場合、cluster
Proxy
オブジェクトが依然として作成されますが、これには spec
がありません。
cluster
という名前の Proxy
オブジェクトのみがサポートされ、追加のプロキシーを作成することはできません。
4.5.7. バイナリーのダウンロードによる OpenShift CLI のインストール
コマンドラインインターフェイスを使用して OpenShift Container Platform と対話するために CLI (oc
) をインストールすることができます。oc
は Linux、Windows、または macOS にインストールできます。
以前のバージョンの oc
をインストールしている場合、これを使用して OpenShift Container Platform 4.15 のすべてのコマンドを実行することはできません。新規バージョンの oc
をダウンロードし、インストールします。
Linux への OpenShift CLI のインストール
以下の手順を使用して、OpenShift CLI (oc
) バイナリーを Linux にインストールできます。
手順
- Red Hat カスタマーポータルの OpenShift Container Platform ダウンロードページ に移動します。
- Product Variant ドロップダウンリストからアーキテクチャーを選択します。
- バージョン ドロップダウンリストから適切なバージョンを選択します。
- OpenShift v4.15 Linux Client エントリーの横にある Download Now をクリックして、ファイルを保存します。
アーカイブを展開します。
Copy to Clipboard Copied! Toggle word wrap Toggle overflow tar xvf <file>
$ tar xvf <file>
oc
バイナリーを、PATH
にあるディレクトリーに配置します。PATH
を確認するには、以下のコマンドを実行します。Copy to Clipboard Copied! Toggle word wrap Toggle overflow echo $PATH
$ echo $PATH
検証
OpenShift CLI のインストール後に、
oc
コマンドを使用して利用できます。Copy to Clipboard Copied! Toggle word wrap Toggle overflow oc <command>
$ oc <command>
Windows への OpenShift CLI のインストール
以下の手順を使用して、OpenShift CLI (oc
) バイナリーを Windows にインストールできます。
手順
- Red Hat カスタマーポータルの OpenShift Container Platform ダウンロードページ に移動します。
- バージョン ドロップダウンリストから適切なバージョンを選択します。
- OpenShift v4.15 Windows Client エントリーの横にある Download Now をクリックして、ファイルを保存します。
- ZIP プログラムでアーカイブを展開します。
oc
バイナリーを、PATH
にあるディレクトリーに移動します。PATH
を確認するには、コマンドプロンプトを開いて以下のコマンドを実行します。Copy to Clipboard Copied! Toggle word wrap Toggle overflow path
C:\> path
検証
OpenShift CLI のインストール後に、
oc
コマンドを使用して利用できます。Copy to Clipboard Copied! Toggle word wrap Toggle overflow oc <command>
C:\> oc <command>
macOS への OpenShift CLI のインストール
以下の手順を使用して、OpenShift CLI (oc
) バイナリーを macOS にインストールできます。
手順
- Red Hat カスタマーポータルの OpenShift Container Platform ダウンロードページ に移動します。
- バージョン ドロップダウンリストから適切なバージョンを選択します。
OpenShift v4.15 macOS Client エントリーの横にある Download Now をクリックして、ファイルを保存します。
注記macOS arm64 の場合は、OpenShift v4.15 macOS arm64 Client エントリーを選択します。
- アーカイブを展開し、解凍します。
oc
バイナリーをパスにあるディレクトリーに移動します。PATH
を確認するには、ターミナルを開き、以下のコマンドを実行します。Copy to Clipboard Copied! Toggle word wrap Toggle overflow echo $PATH
$ echo $PATH
検証
oc
コマンドを使用してインストールを確認します。Copy to Clipboard Copied! Toggle word wrap Toggle overflow oc <command>
$ oc <command>
4.5.8. 管理者レベルのシークレットを kube-system プロジェクトに保存する代替方法
デフォルトでは、管理者のシークレットは kube-system
プロジェクトに保存されます。install-config.yaml
ファイルの credentialsMode
パラメーターを Manual
に設定した場合は、次のいずれかの代替手段を使用する必要があります。
- 長期クラウド認証情報を手動で管理するには、長期認証情報を手動で作成する の手順に従ってください。
- クラスターの外部で管理される短期認証情報を個々のコンポーネントに対して実装するには、短期認証情報を使用するように AWS クラスターを設定する の手順に従ってください。
4.5.8.1. 長期認証情報を手動で作成する
Cloud Credential Operator (CCO) は、クラウドアイデンティティーおよびアクセス管理 (IAM) API に到達できない環境にインストールする前に手動モードに配置できます。管理者はクラスター kube-system
namespace に管理者レベルの認証情報シークレットを保存しないようにします。
手順
install-config.yaml
設定ファイルのcredentialsMode
パラメーターをManual
に設定しなかった場合は、次のように値を変更します。設定ファイルのサンプルスニペット
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 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>
ここで、
<installation_directory>
は、インストールプログラムがファイルを作成するディレクトリーに置き換えます。次のコマンドを実行して、インストールファイルのリリースイメージを
$RELEASE_IMAGE
変数に設定します。Copy to Clipboard Copied! Toggle word wrap Toggle overflow RELEASE_IMAGE=$(./openshift-install version | awk '/release image/ {print $3}')
$ RELEASE_IMAGE=$(./openshift-install version | awk '/release image/ {print $3}')
以下のコマンドを実行して、OpenShift Container Platform リリースイメージから
CredentialsRequest
カスタムリソース (CR) のリストを抽出します。Copy to Clipboard Copied! Toggle word wrap Toggle overflow oc adm release extract \ --from=$RELEASE_IMAGE \ --credentials-requests \ --included \ --install-config=<path_to_directory_with_installation_configuration>/install-config.yaml \ --to=<path_to_directory_for_credentials_requests>
$ 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
オブジェクトCopy to Clipboard Copied! Toggle word wrap Toggle overflow 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: "*" ...
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
オブジェクトのサンプルCopy to Clipboard Copied! Toggle word wrap Toggle overflow 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> ...
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
オブジェクトCopy to Clipboard Copied! Toggle word wrap Toggle overflow 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>
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.5.8.2. 短期認証情報を使用するように AWS クラスターを設定
AWS Security Token Service (STS) を使用するように設定されたクラスターをインストールするには、CCO ユーティリティーを設定し、クラスターに必要な AWS リソースを作成する必要があります。
4.5.8.2.1. Cloud Credential Operator ユーティリティーの設定
Cloud Credential Operator (CCO) が手動モードで動作しているときにクラスターの外部からクラウドクレデンシャルを作成および管理するには、CCO ユーティリティー (ccoctl
) バイナリーを抽出して準備します。
ccoctl
ユーティリティーは、Linux 環境で実行する必要がある Linux バイナリーです。
前提条件
- クラスター管理者のアクセスを持つ OpenShift Container Platform アカウントを使用できる。
-
OpenShift CLI (
oc
) がインストールされている。
ccoctl
ユーティリティー用の AWS アカウントを作成し、次の権限で使用できるようにしました。例4.23 必要な 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.24 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 リリースイメージの変数を設定します。
Copy to Clipboard Copied! Toggle word wrap Toggle overflow RELEASE_IMAGE=$(./openshift-install version | awk '/release image/ {print $3}')
$ RELEASE_IMAGE=$(./openshift-install version | awk '/release image/ {print $3}')
以下のコマンドを実行して、OpenShift Container Platform リリースイメージから CCO コンテナーイメージを取得します。
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 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)
注記$RELEASE_IMAGE
のアーキテクチャーが、ccoctl
ツールを使用する環境のアーキテクチャーと一致していることを確認してください。以下のコマンドを実行して、OpenShift Container Platform リリースイメージ内の CCO コンテナーイメージから
ccoctl
バイナリーを抽出します。Copy to Clipboard Copied! Toggle word wrap Toggle overflow oc image extract $CCO_IMAGE --file="/usr/bin/ccoctl" -a ~/.pull-secret
$ oc image extract $CCO_IMAGE --file="/usr/bin/ccoctl" -a ~/.pull-secret
次のコマンドを実行して、権限を変更して
ccoctl
を実行可能にします。Copy to Clipboard Copied! Toggle word wrap Toggle overflow chmod 775 ccoctl
$ chmod 775 ccoctl
検証
ccoctl
が使用できることを確認するには、help ファイルを表示します。コマンドを実行するときは、相対ファイル名を使用します。以下に例を示します。Copy to Clipboard Copied! Toggle word wrap Toggle overflow ./ccoctl.rhel9
$ ./ccoctl.rhel9
出力例
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 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.
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.5.8.2.2. Cloud Credential Operator ユーティリティーを使用した AWS リソースの作成
AWS リソースを作成するときは、次のオプションがあります。
-
ccoctl aws create-all
コマンドを使用して AWS リソースを自動的に作成できます。これはリソースを作成する最も簡単な方法です。単一コマンドでの AWS リソースの作成 を参照してください。 -
AWS リソースの変更前に
ccoctl
ツールが作成する JSON ファイルを確認する必要がある場合や、ccoctl
ツールが AWS リソースを自動作成するために使用するプロセスが組織の要件を満たさない場合は、AWS リソースを個別に作成できます。AWS リソースの個別の作成 を参照してください。
4.5.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
変数に設定します。Copy to Clipboard Copied! Toggle word wrap Toggle overflow RELEASE_IMAGE=$(./openshift-install version | awk '/release image/ {print $3}')
$ RELEASE_IMAGE=$(./openshift-install version | awk '/release image/ {print $3}')
以下のコマンドを実行して、OpenShift Container Platform リリースイメージから
CredentialsRequest
オブジェクトのリストを抽出します。Copy to Clipboard Copied! Toggle word wrap Toggle overflow oc adm release extract \ --from=$RELEASE_IMAGE \ --credentials-requests \ --included \ --install-config=<path_to_directory_with_installation_configuration>/install-config.yaml \ --to=<path_to_directory_for_credentials_requests>
$ 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
オブジェクトをすべて処理します。Copy to Clipboard Copied! Toggle word wrap Toggle overflow ccoctl aws create-all \ --name=<name> \ --region=<aws_region> \ --credentials-requests-dir=<path_to_credentials_requests_directory> \ --output-dir=<path_to_ccoctl_output_dir> \ --create-private-s3-bucket
$ 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
ディレクトリーのファイルを一覧表示します。Copy to Clipboard Copied! Toggle word wrap Toggle overflow ls <path_to_ccoctl_output_dir>/manifests
$ ls <path_to_ccoctl_output_dir>/manifests
出力例
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 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
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.5.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 キーファイルを生成します。
Copy to Clipboard Copied! Toggle word wrap Toggle overflow ccoctl aws create-key-pair
$ ccoctl aws create-key-pair
出力例
Copy 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 installer
serviceaccount-signer.private
およびserviceaccount-signer.public
は、生成されるキーファイルです。このコマンドは、クラスターがインストール時に必要とするプライベートキーを
/<path_to_ccoctl_output_dir>/tls/bound-service-account-signing-key.key
に作成します。次のコマンドを実行して、AWS 上に OpenID Connect ID プロバイダーと S3 バケットを作成します。
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 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.public
3 出力例
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.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
変数に設定します。Copy to Clipboard Copied! Toggle word wrap Toggle overflow RELEASE_IMAGE=$(./openshift-install version | awk '/release image/ {print $3}')
$ RELEASE_IMAGE=$(./openshift-install version | awk '/release image/ {print $3}')
OpenShift Container Platform リリースイメージから
CredentialsRequest
オブジェクトの一覧を抽出します。Copy to Clipboard Copied! Toggle word wrap Toggle overflow oc adm release extract \ --from=$RELEASE_IMAGE \ --credentials-requests \ --included \ --install-config=<path_to_directory_with_installation_configuration>/install-config.yaml \ --to=<path_to_directory_for_credentials_requests>
$ 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
オブジェクトをすべて処理します。Copy to Clipboard Copied! Toggle word wrap Toggle overflow 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.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
ディレクトリーのファイルを一覧表示します。Copy to Clipboard Copied! Toggle word wrap Toggle overflow ls <path_to_ccoctl_output_dir>/manifests
$ ls <path_to_ccoctl_output_dir>/manifests
出力例
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 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
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.5.8.2.3. Cloud Credential Operator ユーティリティーマニフェストの組み込み
個々のコンポーネントに対してクラスターの外部で管理される短期セキュリティー認証情報を実装するには、Cloud Credential Operator ユーティリティー (ccoctl
) が作成したマニフェストファイルを、インストールプログラムの正しいディレクトリーに移動する必要があります。
前提条件
- クラスターをホストするクラウドプラットフォームでアカウントを設定しました。
-
Cloud Credential Operator ユーティリティー (
ccoctl
) が設定されている。 -
ccoctl
ユーティリティーを使用して、クラスターに必要なクラウドプロバイダーリソースを作成している。
手順
install-config.yaml
設定ファイルのcredentialsMode
パラメーターをManual
に設定しなかった場合は、次のように値を変更します。設定ファイルのサンプルスニペット
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 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>
ここで、
<installation_directory>
は、インストールプログラムがファイルを作成するディレクトリーに置き換えます。次のコマンドを実行して、
ccoctl
ユーティリティーが生成したマニフェストを、インストールプログラムが作成したmanifests
ディレクトリーにコピーします。Copy to Clipboard Copied! Toggle word wrap Toggle overflow cp /<path_to_ccoctl_output_dir>/manifests/* ./manifests/
$ cp /<path_to_ccoctl_output_dir>/manifests/* ./manifests/
秘密鍵を含む
tls
ディレクトリーをインストールディレクトリーにコピーします。Copy to Clipboard Copied! Toggle word wrap Toggle overflow cp -a /<path_to_ccoctl_output_dir>/tls .
$ cp -a /<path_to_ccoctl_output_dir>/tls .
4.5.9. Cluster Network Operator (CNO) の設定
クラスターネットワークの設定は、Cluster Network Operator (CNO) 設定の一部として指定され、cluster
という名前のカスタムリソース (CR) オブジェクトに保存されます。CR は operator.openshift.io
API グループの Network
API のフィールドを指定します。
CNO 設定は、Network.config.openshift.io
API グループの Network
API からクラスターのインストール時に以下のフィールドを継承します。
clusterNetwork
- Pod IP アドレスの割り当てに使用する IP アドレスプール。
serviceNetwork
- サービスの IP アドレスプール。
defaultNetwork.type
-
クラスターネットワークプラグイン。
OVNKubernetes
は、インストール時にサポートされる唯一のプラグインです。
defaultNetwork
オブジェクトのフィールドを cluster
という名前の CNO オブジェクトに設定することにより、クラスターのクラスターネットワークプラグイン設定を指定できます。
4.5.9.1. Cluster Network Operator 設定オブジェクト
Cluster Network Operator (CNO) のフィールドは以下の表で説明されています。
フィールド | 型 | 説明 |
---|---|---|
|
|
CNO オブジェクトの名前。この名前は常に |
|
| Pod ID アドレスの割り当て、サブネット接頭辞の長さのクラスター内の個別ノードへの割り当てに使用される IP アドレスのブロックを指定するリストです。以下に例を示します。 spec: clusterNetwork: - cidr: 10.128.0.0/19 hostPrefix: 23 - cidr: 10.128.32.0/19 hostPrefix: 23
|
|
| サービスの IP アドレスのブロック。OpenShift SDN および OVN-Kubernetes ネットワークプラグインは、サービスネットワークの単一 IP アドレスブロックのみをサポートします。以下に例を示します。 spec: serviceNetwork: - 172.30.0.0/14
マニフェストを作成する前に、このフィールドを |
|
| クラスターネットワークのネットワークプラグインを設定します。 |
|
| このオブジェクトのフィールドは、kube-proxy 設定を指定します。OVN-Kubernetes クラスターネットワークプラグインを使用している場合、kube-proxy 設定は機能しません。 |
defaultNetwork オブジェクト設定
defaultNetwork
オブジェクトの値は、以下の表で定義されます。
フィールド | 型 | 説明 |
---|---|---|
|
|
注記 OpenShift Container Platform は、デフォルトで OVN-Kubernetes ネットワークプラグインを使用します。OpenShift SDN は、新しいクラスターのインストールの選択肢として利用できなくなりました。 |
|
| このオブジェクトは、OVN-Kubernetes ネットワークプラグインに対してのみ有効です。 |
OVN-Kubernetes ネットワークプラグインの設定
次の表では、OVN-Kubernetes ネットワークプラグインの設定フィールドを説明します。
フィールド | 型 | 説明 |
---|---|---|
|
| Geneve (Generic Network Virtualization Encapsulation) オーバーレイネットワークの MTU (maximum transmission unit)。これは、プライマリーネットワークインターフェイスの MTU に基づいて自動的に検出されます。通常、検出された MTU を上書きする必要はありません。 自動検出した値が予想される値ではない場合は、ノード上のプライマリーネットワークインターフェイスの MTU が正しいことを確認します。このオプションを使用して、ノード上のプライマリーネットワークインターフェイスの MTU 値を変更することはできません。
クラスターで異なるノードに異なる MTU 値が必要な場合、この値をクラスター内の最小の MTU 値よりも |
|
|
すべての Geneve パケットに使用するポート。デフォルト値は |
|
| IPsec 設定をカスタマイズするための設定オブジェクトを指定します。 |
|
| ネットワークポリシー監査ロギングをカスタマイズする設定オブジェクトを指定します。指定されていない場合は、デフォルトの監査ログ設定が使用されます。 |
|
| オプション: Egress トラフィックのノードゲートウェイへの送信方法をカスタマイズするための設定オブジェクトを指定します。 注記 Egress トラフィックの移行中は、Cluster Network Operator (CNO) が変更を正常にロールアウトするまで、ワークロードとサービストラフィックに多少の中断が発生することが予想されます。 |
|
既存のネットワークインフラストラクチャーが このフィールドは、インストール後に変更できません。 |
デフォルト値は |
|
既存のネットワークインフラストラクチャーが このフィールドは、インストール後に変更できません。 |
デフォルト値は |
フィールド | 型 | 説明 |
---|---|---|
| integer |
ノードごとに毎秒生成されるメッセージの最大数。デフォルト値は、1 秒あたり |
| integer |
監査ログの最大サイズ (バイト単位)。デフォルト値は |
| integer | 保持されるログファイルの最大数。 |
| string | 以下の追加の監査ログターゲットのいずれかになります。
|
| string |
RFC5424 で定義される |
フィールド | 型 | 説明 |
---|---|---|
|
|
Pod からホストネットワークスタックへの Egress トラフィックを送信するには、このフィールドを
このフィールドで、Open vSwitch ハードウェアオフロード機能との対話が可能になりました。このフィールドを |
|
|
|
フィールド | 型 | 説明 |
---|---|---|
|
| IPsec 実装の動作を指定します。次の値のいずれかである必要があります。
|
IPsec が有効な OVN-Kubernetes 設定の例
defaultNetwork: type: OVNKubernetes ovnKubernetesConfig: mtu: 1400 genevePort: 6081 ipsecConfig: mode: Full
defaultNetwork:
type: OVNKubernetes
ovnKubernetesConfig:
mtu: 1400
genevePort: 6081
ipsecConfig:
mode: Full
OVNKubernetes を使用すると、IBM Power® でスタック枯渇の問題が発生する可能性があります。
kubeProxyConfig オブジェクト設定 (OpenShiftSDN コンテナーネットワークインターフェイスのみ)
kubeProxyConfig
オブジェクトの値は以下の表で定義されます。
フィールド | 型 | 説明 |
---|---|---|
|
|
注記
OpenShift Container Platform 4.3 以降で強化されたパフォーマンスの向上により、 |
|
|
kubeProxyConfig: proxyArguments: iptables-min-sync-period: - 0s
|
4.5.10. 高度なネットワーク設定の指定
ネットワークプラグインに高度なネットワーク設定を使用し、クラスターを既存のネットワーク環境に統合することができます。高度なネットワーク設定は、クラスターのインストール前にのみ指定することができます。
インストールプロブラムで作成される OpenShift Container Platform マニフェストファイルを変更してネットワーク設定をカスタマイズすることは、サポートされていません。以下の手順のように、作成するマニフェストファイルを適用することがサポートされています。
前提条件
-
install-config.yaml
ファイルを作成し、これに対する変更を完了している。
手順
インストールプログラムが含まれるディレクトリーに切り替え、マニフェストを作成します。
Copy to Clipboard Copied! Toggle word wrap Toggle overflow ./openshift-install create manifests --dir <installation_directory>
$ ./openshift-install create manifests --dir <installation_directory>
1 - 1
<installation_directory>
は、クラスターのinstall-config.yaml
ファイルが含まれるディレクトリーの名前を指定します。
cluster-network-03-config.yml
という名前の、高度なネットワーク設定用のスタブマニフェストファイルを<installation_directory>/manifests/
ディレクトリーに作成します。Copy to Clipboard Copied! Toggle word wrap Toggle overflow apiVersion: operator.openshift.io/v1 kind: Network metadata: name: cluster spec:
apiVersion: operator.openshift.io/v1 kind: Network metadata: name: cluster spec:
次の例のように、
cluster-network-03-config.yml
ファイルでクラスターの高度なネットワーク設定を指定します。OVN-Kubernetes ネットワークプロバイダーの IPsec を有効にする
Copy to Clipboard Copied! Toggle word wrap Toggle overflow apiVersion: operator.openshift.io/v1 kind: Network metadata: name: cluster spec: defaultNetwork: ovnKubernetesConfig: ipsecConfig: mode: Full
apiVersion: operator.openshift.io/v1 kind: Network metadata: name: cluster spec: defaultNetwork: ovnKubernetesConfig: ipsecConfig: mode: Full
-
オプション:
manifests/cluster-network-03-config.yml
ファイルをバックアップします。インストールプログラムは、Ignition 設定ファイルの作成時にmanifests/
ディレクトリーを使用します。
AWS で Network Load Balancer (NLB) を使用する方法の詳細は、Network Load Balancer を使用した AWS での Ingress クラスタートラフィックの設定 を参照してください。
4.5.11. 新規 AWS クラスターでの Ingress コントローラーネットワークロードバランサーの設定
新規クラスターに AWS Network Load Balancer (NLB) がサポートする Ingress Controller を作成できます。
前提条件
-
install-config.yaml
ファイルを作成し、これに対する変更を完了します。
手順
新規クラスターの AWS NLB がサポートする Ingress Controller を作成します。
インストールプログラムが含まれるディレクトリーに切り替え、マニフェストを作成します。
Copy to Clipboard Copied! Toggle word wrap Toggle overflow ./openshift-install create manifests --dir <installation_directory>
$ ./openshift-install create manifests --dir <installation_directory>
1 - 1
<installation_directory>
については、クラスターのinstall-config.yaml
ファイルが含まれるディレクトリーの名前を指定します。
cluster-ingress-default-ingresscontroller.yaml
という名前のファイルを<installation_directory>/manifests/
ディレクトリーに作成します。Copy to Clipboard Copied! Toggle word wrap Toggle overflow touch <installation_directory>/manifests/cluster-ingress-default-ingresscontroller.yaml
$ touch <installation_directory>/manifests/cluster-ingress-default-ingresscontroller.yaml
1 - 1
<installation_directory>
については、クラスターのmanifests/
ディレクトリーが含まれるディレクトリー名を指定します。
ファイルの作成後は、以下のようにいくつかのネットワーク設定ファイルが
manifests/
ディレクトリーに置かれます。Copy to Clipboard Copied! Toggle word wrap Toggle overflow ls <installation_directory>/manifests/cluster-ingress-default-ingresscontroller.yaml
$ ls <installation_directory>/manifests/cluster-ingress-default-ingresscontroller.yaml
出力例
Copy to Clipboard Copied! Toggle word wrap Toggle overflow cluster-ingress-default-ingresscontroller.yaml
cluster-ingress-default-ingresscontroller.yaml
エディターで
cluster-ingress-default-ingresscontroller.yaml
ファイルを開き、必要な Operator 設定を記述するカスタムリソース (CR) を入力します。Copy to Clipboard Copied! Toggle word wrap Toggle overflow apiVersion: operator.openshift.io/v1 kind: IngressController metadata: creationTimestamp: null name: default namespace: openshift-ingress-operator spec: endpointPublishingStrategy: loadBalancer: scope: External providerParameters: type: AWS aws: type: NLB type: LoadBalancerService
apiVersion: operator.openshift.io/v1 kind: IngressController metadata: creationTimestamp: null name: default namespace: openshift-ingress-operator spec: endpointPublishingStrategy: loadBalancer: scope: External providerParameters: type: AWS aws: type: NLB type: LoadBalancerService
-
cluster-ingress-default-ingresscontroller.yaml
ファイルを保存し、テキストエディターを終了します。 -
オプション:
manifests/cluster-ingress-default-ingresscontroller.yaml
ファイルをバックアップします。インストールプログラムは、クラスターの作成時にmanifests/
ディレクトリーを削除します。
4.5.12. OVN-Kubernetes を使用したハイブリッドネットワークの設定
OVN-Kubernetes ネットワークプラグインを使用してハイブリッドネットワークを使用するようにクラスターを設定できます。これにより、異なるノードのネットワーク設定をサポートするハイブリッドクラスターが可能になります。
この設定は、同じクラスター内で Linux ノードと Windows ノードの両方を実行するために必要です。
前提条件
-
install-config.yaml
ファイルでnetworking.networkType
パラメーターのOVNKubernetes
を定義していること。詳細は、選択したクラウドプロバイダーでの OpenShift Container Platform ネットワークのカスタマイズの設定に関するインストールドキュメントを参照してください。
手順
インストールプログラムが含まれるディレクトリーに切り替え、マニフェストを作成します。
Copy to Clipboard Copied! Toggle word wrap Toggle overflow ./openshift-install create manifests --dir <installation_directory>
$ ./openshift-install create manifests --dir <installation_directory>
ここでは、以下のようになります。
<installation_directory>
-
クラスターの
install-config.yaml
ファイルが含まれるディレクトリーの名前を指定します。
cluster-network-03-config.yml
という名前の、高度なネットワーク設定用のスタブマニフェストファイルを<installation_directory>/manifests/
ディレクトリーに作成します。Copy to Clipboard Copied! Toggle word wrap Toggle overflow cat <<EOF > <installation_directory>/manifests/cluster-network-03-config.yml apiVersion: operator.openshift.io/v1 kind: Network metadata: name: cluster spec: EOF
$ cat <<EOF > <installation_directory>/manifests/cluster-network-03-config.yml apiVersion: operator.openshift.io/v1 kind: Network metadata: name: cluster spec: EOF
ここでは、以下のようになります。
<installation_directory>
-
クラスターの
manifests/
ディレクトリーが含まれるディレクトリー名を指定します。
cluster-network-03-config.yml
ファイルをエディターで開き、以下の例のようにハイブリッドネットワークで OVN-Kubernetes を設定します。ハイブリッドネットワーク設定の指定
Copy to Clipboard Copied! Toggle word wrap Toggle overflow apiVersion: operator.openshift.io/v1 kind: Network metadata: name: cluster spec: defaultNetwork: ovnKubernetesConfig: hybridOverlayConfig: hybridClusterNetwork: - cidr: 10.132.0.0/14 hostPrefix: 23 hybridOverlayVXLANPort: 9898
apiVersion: operator.openshift.io/v1 kind: Network metadata: name: cluster spec: defaultNetwork: ovnKubernetesConfig: hybridOverlayConfig: hybridClusterNetwork:
1 - cidr: 10.132.0.0/14 hostPrefix: 23 hybridOverlayVXLANPort: 9898
2 - 1
- 追加のオーバーレイネットワーク上のノードに使用される CIDR 設定を指定します。
hybridClusterNetwork
CIDR はclusterNetwork
CIDR と重複できません。 - 2
- 追加のオーバーレイネットワークのカスタム VXLAN ポートを指定します。これは、vSphere にインストールされたクラスターで Windows ノードを実行するために必要であり、その他のクラウドプロバイダー用に設定することはできません。カスタムポートには、デフォルトの
4789
ポートを除くいずれかのオープンポートを使用できます。この要件の詳細は、Microsoft ドキュメントの Pod-to-pod connectivity between hosts is broken を参照してください。
注記Windows Server Long-Term Servicing Channel (LTSC): Windows Server 2019 は、カスタムの VXLAN ポートの選択をサポートしないため、カスタムの
hybridOverlayVXLANPort
値を持つクラスターではサポートされません。-
cluster-network-03-config.yml
ファイルを保存し、テキストエディターを終了します。 -
オプション:
manifests/cluster-network-03-config.yml
ファイルをバックアップします。インストールプログラムは、クラスターの作成時にmanifests/
ディレクトリーを削除します。
同じクラスターで Linux ノードと Windows ノードを使用する方法の詳細は、Windows コンテナーワークロードについて を参照してください。
4.5.13. クラスターのデプロイ
互換性のあるクラウドプラットフォームに OpenShift Container Platform をインストールできます。
インストールプログラムの create cluster
コマンドは、初期インストール時に 1 回だけ実行できます。
前提条件
- クラスターをホストするクラウドプラットフォームでアカウントを設定しました。
- OpenShift Container Platform インストールプログラムおよびクラスターのプルシークレットがある。
- ホスト上のクラウドプロバイダーアカウントに、クラスターをデプロイするための適切な権限があることが確認されました。アカウントの権限が正しくないと、インストールプロセスが失敗し、不足している権限を示すエラーメッセージが表示されます。
手順
インストールプログラムが含まれるディレクトリーに切り替え、クラスターのデプロイメントを初期化します。
Copy to Clipboard Copied! Toggle word wrap Toggle overflow ./openshift-install create cluster --dir <installation_directory> \ --log-level=info
$ ./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
...
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.5.14. CLI の使用によるクラスターへのログイン
クラスター kubeconfig
ファイルをエクスポートし、デフォルトシステムユーザーとしてクラスターにログインできます。kubeconfig
ファイルには、クライアントを正しいクラスターおよび API サーバーに接続するために CLI で使用されるクラスターに関する情報が含まれます。このファイルはクラスターに固有のファイルであり、OpenShift Container Platform のインストール時に作成されます。
前提条件
- OpenShift Container Platform クラスターをデプロイしていること。
-
oc
CLI をインストールしていること。
手順
kubeadmin
認証情報をエクスポートします。Copy to Clipboard Copied! Toggle word wrap Toggle overflow export KUBECONFIG=<installation_directory>/auth/kubeconfig
$ export KUBECONFIG=<installation_directory>/auth/kubeconfig
1 - 1
<installation_directory>
には、インストールファイルを保存したディレクトリーへのパスを指定します。
エクスポートされた設定を使用して、
oc
コマンドを正常に実行できることを確認します。Copy to Clipboard Copied! Toggle word wrap Toggle overflow oc whoami
$ oc whoami
出力例
Copy to Clipboard Copied! Toggle word wrap Toggle overflow system:admin
system:admin
4.5.15. Web コンソールを使用したクラスターへのログイン
kubeadmin
ユーザーは、OpenShift Container Platform のインストール後はデフォルトで存在します。OpenShift Container Platform Web コンソールを使用し、kubeadmin
ユーザーとしてクラスターにログインできます。
前提条件
- インストールホストにアクセスできる。
- クラスターのインストールを完了しており、すべてのクラスター Operator が利用可能である。
手順
インストールホストで
kubeadmin-password
ファイルからkubeadmin
ユーザーのパスワードを取得します。Copy to Clipboard Copied! Toggle word wrap Toggle overflow cat <installation_directory>/auth/kubeadmin-password
$ cat <installation_directory>/auth/kubeadmin-password
注記または、インストールホストで
<installation_directory>/.openshift_install.log
ログファイルからkubeadmin
パスワードを取得できます。OpenShift Container Platform Web コンソールルートをリスト表示します。
Copy to Clipboard Copied! Toggle word wrap Toggle overflow oc get routes -n openshift-console | grep 'console-openshift'
$ oc get routes -n openshift-console | grep 'console-openshift'
注記または、インストールホストで
<installation_directory>/.openshift_install.log
ログファイルからで OpenShift Container Platform ルートを取得できます。出力例
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 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 None
-
Web ブラウザーで前述のコマンドの出力で詳細に説明されたルートに移動し、
kubeadmin
ユーザーとしてログインします。
関連情報
- OpenShift Container Platform Web コンソールへのアクセスと理解に関する詳細は、Web コンソールへのアクセス を参照してください。
4.5.16. OpenShift Container Platform の Telemetry アクセス
OpenShift Container Platform 4.15 では、クラスターの健全性および正常に実行された更新についてのメトリクスを提供するためにデフォルトで実行される Telemetry サービスにも、インターネットアクセスが必要です。クラスターがインターネットに接続されている場合、Telemetry は自動的に実行され、クラスターは OpenShift Cluster Manager に登録されます。
OpenShift Cluster Manager インベントリーが正常である (Telemetry によって自動的に維持、または OpenShift Cluster Manager を使用して手動で維持) ことを確認した後に、subscription watch を使用 して、アカウントまたはマルチクラスターレベルで OpenShift Container Platform サブスクリプションを追跡します。
関連情報
- Telemetry サービスの詳細は、リモートヘルスモニタリング を参照してください。
4.5.17. 次のステップ
- インストールを検証 します。
- クラスターをカスタマイズ します。
- 必要に応じて、リモートヘルスレポートをオプトアウト できます。
- 必要に応じて、クラウドプロバイダーの認証情報を削除 できます。
4.6. ネットワークが制限された環境での AWS へのクラスターのインストール
OpenShift Container Platform バージョン 4.15 では、既存の Amazon Virtual Private Cloud (VPC) にインストールリリースコンテンツの内部ミラーを作成することにより、制限付きネットワーク内の Amazon Web Services (AWS) にクラスターをインストールできます。
4.6.1. 前提条件
- OpenShift Container Platform のインストールおよび更新 プロセスの詳細を確認した。
- クラスターインストール方法の選択およびそのユーザー向けの準備 を確認した。
非接続インストールのイメージのミラーリング をレジストリーに対して行っており、使用しているバージョンの OpenShift Container Platform の
imageContentSources
データを取得している。重要インストールメディアはミラーホストにあるため、そのコンピューターを使用してすべてのインストール手順を完了することができます。
AWS に既存の VPC が必要です。installer-provisioned infrastructure を使用してネットワークが制限された環境にインストールする場合は、installer-provisioned VPC を使用することはできません。以下の要件のいずれかを満たす user-provisioned VPC を使用する必要があります。
- ミラーレジストリーが含まれる。
- 別の場所でホストされるミラーレジストリーにアクセスするためのファイアウォールルールまたはピアリング接続がある。
クラスターをホストするために AWS アカウントを設定 している。
重要AWS プロファイルがご使用のコンピューターに保存されている場合、マルチファクター認証デバイスを使用中に生成した一時的なセッショントークンを使用することはできません。クラスターは継続的に現行の AWS 認証情報を使用して、クラスターの有効期間全体にわたって AWS リソースを作成するため、キーをベースとした有効期間の長い認証情報を使用する必要があります。適切なキーを生成するには、AWS ドキュメントの Managing Access Keys for IAM Users を参照してください。キーは、インストールプログラムの実行時に指定できます。
- AWS CLI をダウンロードし、これをコンピューターにインストールしている。AWS ドキュメントの Install the AWS CLI Using the Bundled Installer (Linux, macOS, or Unix) を参照してください。
クラスターがアクセスを必要とする サイトを許可するようにファイアウォールを設定 している (ファイアウォールを使用し、Telemetry サービスを使用する予定の場合)。
注記プロキシーを設定する場合は、このサイトリストも確認してください。
4.6.2. ネットワークが制限された環境でのインストールについて
OpenShift Container Platform 4.15 では、ソフトウェアコンポーネントを取得するためにインターネットへのアクティブな接続を必要としないインストールを実行できます。ネットワークが制限された環境のインストールは、クラスターのインストール先となるクラウドプラットフォームに応じて、インストーラーでプロビジョニングされるインフラストラクチャーまたはユーザーによってプロビジョニングされるインフラストラクチャーを使用して実行できます。
クラウドプラットフォーム上でネットワークが制限されたインストールの実行を選択した場合でも、そのクラウド API へのアクセスが必要になります。Amazon Web Service の Route 53 DNS や IAM サービスなどの一部のクラウド機能には、インターネットアクセスが必要です。ネットワークによっては、ベアメタルハードウェア、Nutanix、または VMware vSphere へのインストールに必要なインターネットアクセスが少なくて済む場合があります。
ネットワークが制限されたインストールを完了するには、OpenShift イメージレジストリーのコンテンツをミラーリングし、インストールメディアを含むレジストリーを作成する必要があります。このミラーは、インターネットと制限されたネットワークの両方にアクセスできるミラーホストで、または制限に対応する他の方法を使用して作成できます。
4.6.2.1. その他の制限
ネットワークが制限された環境のクラスターには、以下の追加の制限および制約があります。
-
ClusterVersion
ステータスにはUnable to retrieve available updates
エラーが含まれます。 - デフォルトで、開発者カタログのコンテンツは、必要とされるイメージストリームタグにアクセスできないために使用できません。
4.6.3. カスタム VPC の使用について
OpenShift Container Platform 4.15 では、Amazon Web Services (AWS) の既存の Amazon Virtual Private Cloud (VPC) における既存サブネットにクラスターをデプロイできます。OpenShift Container Platform を既存の AWS VPC にデプロイすると、新規アカウントの制限を回避したり、会社のガイドラインによる運用上の制約をより容易に遵守することが可能になる場合があります。VPC を作成するために必要なインフラストラクチャーの作成パーミッションを取得できない場合は、このインストールオプションを使用します。
インストールプログラムは既存のサブネットにある他のコンポーネントを把握できないため、ユーザーの代わりにサブネットの CIDR を選択することはできません。クラスターをインストールするサブネットのネットワークを独自に設定する必要があります。
4.6.3.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 アベイラビリティーゾーンのプライベートサブネットを作成できます。プライベートサブネットを使用できる場合は、それらの適切なルートおよびテーブルを指定する必要があります。 |
4.6.3.2. VPC 検証
指定するサブネットが適切であることを確認するには、インストールプログラムが以下のデータを確認します。
- 指定したサブネットすべてが存在します。
- プライベートサブネットを指定します。
- サブネットの CIDR は指定されたマシン CIDR に属します。
- 各アベイラビリティーゾーンのサブネットを指定します。それぞれのアベイラビリティーゾーンには、複数のパブリックおよびプライベートサブネットがありません。プライベートクラスターを使用する場合、各アベイラビリティーゾーンのプライベートサブネットのみを指定します。それ以外の場合は、各アベイラビリティーゾーンのパブリックサブネットおよびプライベートサブネットを指定します。
- 各プライベートサブネットアベイラビリティーゾーンのパブリックサブネットを指定します。マシンは、プライベートサブネットを指定しないアベイラビリティーゾーンにはプロビジョニングされません。
既存の VPC を使用するクラスターを破棄しても、VPC は削除されません。VPC から OpenShift Container Platform クラスターを削除する場合、kubernetes.io/cluster/.*: shared
タグは、それが使用したサブネットから削除されます。
4.6.3.3. パーミッションの区分
OpenShift Container Platform 4.3 以降、クラスターのデプロイに、インストールプログラムがプロビジョニングするインフラストラクチャークラスターに必要なすべてのパーミッションを必要としなくなりました。この変更は、ある会社で個人がクラウドで他とは異なるリソースを作成できるようにパーミッションが区分された状態に類似するものです。たとえば、インスタンス、バケット、ロードバランサーなどのアプリケーション固有のアイテムを作成することはできますが、VPC、サブネット、または Ingress ルールなどのネットワーク関連のコンポーネントは作成できない可能性があります。
クラスターの作成時に使用する AWS の認証情報には、VPC、およびサブネット、ルーティングテーブル、インターネットゲートウェイ、NAT、VPN などの VPC 内のコアとなるネットワークコンポーネントの作成に必要なネットワークのパーミッションは必要ありません。ELB、セキュリティーグループ、S3 バケットおよびノードなどの、クラスター内でマシンに必要なアプリケーションリソースを作成するパーミッションは依然として必要になります。
4.6.3.4. クラスター間の分離
OpenShift Container Platform を既存のネットワークにデプロイする場合、クラスターサービスの分離の規模は以下の方法で縮小されます。
- 複数の OpenShift Container Platform クラスターを同じ VPC にインストールできます。
- ICMP Ingress はネットワーク全体から許可されます。
- TCP 22 Ingress (SSH) はネットワーク全体に対して許可されます。
- コントロールプレーンの TCP 6443 Ingress (Kubernetes API) はネットワーク全体に対して許可されます。
- コントロールプレーンの TCP 22623 Ingress (MCS) はネットワーク全体に対して許可されます。
4.6.4. OpenShift Container Platform のインターネットアクセス
OpenShift Container Platform 4.15 では、クラスターのインストールに必要なイメージを取得するために、インターネットにアクセスする必要があります。
インターネットへのアクセスは以下を実行するために必要です。
- OpenShift Cluster Manager にアクセスし、インストールプログラムをダウンロードし、サブスクリプション管理を実行します。クラスターにインターネットアクセスがあり、Telemetry を無効にしない場合、そのサービスは有効なサブスクリプションでクラスターを自動的に使用します。
- クラスターのインストールに必要なパッケージを取得するために Quay.io にアクセスします。
- クラスターの更新を実行するために必要なパッケージを取得します。
4.6.5. クラスターノードの 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 オペレーティングシステムを使用するコンピューターで以下のコマンドを実行します。
Copy to Clipboard Copied! Toggle word wrap Toggle overflow ssh-keygen -t ed25519 -N '' -f <path>/<file_name>
$ 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 キーを表示します。
Copy to Clipboard Copied! Toggle word wrap Toggle overflow cat <path>/<file_name>.pub
$ cat <path>/<file_name>.pub
たとえば、次のコマンドを実行して
~/.ssh/id_ed25519.pub
公開鍵を表示します。Copy to Clipboard Copied! Toggle word wrap Toggle overflow cat ~/.ssh/id_ed25519.pub
$ cat ~/.ssh/id_ed25519.pub
ローカルユーザーの SSH エージェントに SSH 秘密鍵 ID が追加されていない場合は、それを追加します。キーの SSH エージェント管理は、クラスターノードへのパスワードなしの SSH 認証、または
./openshift-install gather
コマンドを使用する場合は必要になります。注記一部のディストリビューションでは、
~/.ssh/id_rsa
および~/.ssh/id_dsa
などのデフォルトの SSH 秘密鍵のアイデンティティーは自動的に管理されます。ssh-agent
プロセスがローカルユーザーに対して実行されていない場合は、バックグラウンドタスクとして開始します。Copy to Clipboard Copied! Toggle word wrap Toggle overflow eval "$(ssh-agent -s)"
$ eval "$(ssh-agent -s)"
出力例
Copy to Clipboard Copied! Toggle word wrap Toggle overflow Agent pid 31874
Agent pid 31874
注記クラスターが FIPS モードにある場合は、FIPS 準拠のアルゴリズムのみを使用して SSH キーを生成します。鍵は RSA または ECDSA のいずれかである必要があります。
SSH プライベートキーを
ssh-agent
に追加します。Copy to Clipboard Copied! Toggle word wrap Toggle overflow ssh-add <path>/<file_name>
$ ssh-add <path>/<file_name>
1 - 1
~/.ssh/id_ed25519
などの、SSH プライベートキーのパスおよびファイル名を指定します。
出力例
Copy to Clipboard Copied! Toggle word wrap Toggle overflow Identity added: /home/<you>/<path>/<file_name> (<computer_name>)
Identity added: /home/<you>/<path>/<file_name> (<computer_name>)
次のステップ
- OpenShift Container Platform をインストールする際に、SSH パブリックキーをインストールプログラムに指定します。
4.6.6. インストール設定ファイルの作成
Amazon Web Services (AWS) での OpenShift Container Platform のインストールをカスタマイズできます。
前提条件
- OpenShift Container Platform インストールプログラムおよびクラスターのプルシークレットがある。ネットワークが制限されたインストールでは、これらのファイルがミラーホスト上に置かれます。
-
ミラーレジストリーの作成時に生成された
imageContentSources
値がある。 - ミラーレジストリーの証明書の内容を取得している。
手順
install-config.yaml
ファイルを作成します。インストールプログラムが含まれるディレクトリーに切り替え、以下のコマンドを実行します。
Copy to Clipboard Copied! Toggle word wrap Toggle overflow ./openshift-install create install-config --dir <installation_directory>
$ ./openshift-install create install-config --dir <installation_directory>
1 - 1
<installation_directory>
の場合、インストールプログラムが作成するファイルを保存するためにディレクトリー名を指定します。
ディレクトリーを指定する場合:
-
ディレクトリーに
execute
権限があることを確認します。この権限は、インストールディレクトリーで Terraform バイナリーを実行するために必要です。 - 空のディレクトリーを使用します。ブートストラップ X.509 証明書などの一部のインストールアセットは有効期限が短いため、インストールディレクトリーを再利用しないでください。別のクラスターインストールの個別のファイルを再利用する必要がある場合は、それらをディレクトリーにコピーすることができます。ただし、インストールアセットのファイル名はリリース間で変更される可能性があります。インストールファイルを以前のバージョンの OpenShift Container Platform からコピーする場合は注意してコピーを行ってください。
プロンプト時に、クラウドの設定の詳細情報を指定します。
オプション: クラスターマシンにアクセスするために使用する SSH キーを選択します。
注記インストールのデバッグまたは障害復旧を実行する必要のある実稼働用の OpenShift Container Platform クラスターでは、
ssh-agent
プロセスが使用する SSH キーを指定します。- ターゲットに設定するプラットフォームとして AWS を選択します。
- Amazon Web Services (AWS) プロファイルをコンピューターに保存していない場合、インストールプログラムを実行するように設定したユーザーの AWS アクセスキー ID およびシークレットアクセスキーを入力します。
- クラスターのデプロイ先とする AWS リージョンを選択します。
- クラスターに設定した Route 53 サービスのベースドメインを選択します。
- クラスターの記述名を入力します。
install-config.yaml
ファイルを編集し、ネットワークが制限された環境でのインストールに必要な追加の情報を提供します。pullSecret
の値を更新して、レジストリーの認証情報を追加します。Copy to Clipboard Copied! Toggle word wrap Toggle overflow pullSecret: '{"auths":{"<mirror_host_name>:5000": {"auth": "<credentials>","email": "you@example.com"}}}'
pullSecret: '{"auths":{"<mirror_host_name>:5000": {"auth": "<credentials>","email": "you@example.com"}}}'
<mirror_host_name>
の場合、ミラーレジストリーの証明書で指定したレジストリードメイン名を指定し、<credentials>
の場合は、ミラーレジストリーの base64 でエンコードされたユーザー名およびパスワードを指定します。additionalTrustBundle
パラメーターおよび値を追加します。Copy to Clipboard Copied! Toggle word wrap Toggle overflow additionalTrustBundle: | -----BEGIN CERTIFICATE----- ZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZ -----END CERTIFICATE-----
additionalTrustBundle: | -----BEGIN CERTIFICATE----- ZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZ -----END CERTIFICATE-----
この値は、ミラーレジストリーに使用した証明書ファイルの内容である必要があります。証明書ファイルは、既存の信頼できる認証局、またはミラーレジストリー用に生成した自己署名証明書のいずれかです。
クラスターをインストールする VPC のサブネットを定義します。
Copy to Clipboard Copied! Toggle word wrap Toggle overflow subnets: - subnet-1 - subnet-2 - subnet-3
subnets: - subnet-1 - subnet-2 - subnet-3
次の YAML の抜粋のようなイメージコンテンツリソースを追加します。
Copy to Clipboard Copied! Toggle word wrap Toggle overflow imageContentSources: - mirrors: - <mirror_host_name>:5000/<repo_name>/release source: quay.io/openshift-release-dev/ocp-release - mirrors: - <mirror_host_name>:5000/<repo_name>/release source: registry.redhat.io/ocp/release
imageContentSources: - mirrors: - <mirror_host_name>:5000/<repo_name>/release source: quay.io/openshift-release-dev/ocp-release - mirrors: - <mirror_host_name>:5000/<repo_name>/release source: registry.redhat.io/ocp/release
これらの値には、ミラーレジストリーの作成時に記録された
imageContentSources
を使用します。オプション: パブリッシュストラテジーを
Internal
に設定します。Copy to Clipboard Copied! Toggle word wrap Toggle overflow publish: Internal
publish: Internal
このオプションを設定すると、内部 Ingress コントローラーおよびプライベートロードバランサーを作成します。
必要な
install-config.yaml
ファイルに他の変更を加えます。パラメーターの詳細は、「インストール設定パラメーター」を参照してください。
install-config.yaml
ファイルをバックアップし、複数のクラスターをインストールするのに使用できるようにします。重要install-config.yaml
ファイルはインストールプロセス時に使用されます。このファイルを再利用する必要がある場合は、この段階でこれをバックアップしてください。
関連情報
4.6.6.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 で使用することがサポートされます。
関連情報
4.6.6.2. AWS のカスタマイズされた install-config.yaml ファイルのサンプル
インストール設定ファイル install-config.yaml
をカスタマイズして、OpenShift Container Platform クラスターのプラットフォームに関する詳細を指定するか、必要なパラメーターの値を変更することができます。
このサンプルの YAML ファイルは参照用にのみ提供されます。インストールプログラムを使用して install-config.yaml
ファイルを取得し、これを変更する必要があります。
apiVersion: v1 baseDomain: example.com credentialsMode: Mint controlPlane: hyperthreading: Enabled name: master platform: aws: zones: - us-west-2a - us-west-2b rootVolume: iops: 4000 size: 500 type: io1 metadataService: authentication: Optional type: m6i.xlarge replicas: 3 compute: - hyperthreading: Enabled name: worker platform: aws: rootVolume: iops: 2000 size: 500 type: io1 metadataService: authentication: Optional type: c5.4xlarge zones: - us-west-2c replicas: 3 metadata: name: test-cluster networking: clusterNetwork: - cidr: 10.128.0.0/14 hostPrefix: 23 machineNetwork: - cidr: 10.0.0.0/16 networkType: OVNKubernetes serviceNetwork: - 172.30.0.0/16 platform: aws: region: us-west-2 propagateUserTags: true userTags: adminContact: jdoe costCenter: 7536 subnets: - subnet-1 - subnet-2 - subnet-3 amiID: ami-0c5d3e03c0ab9b19a serviceEndpoints: - name: ec2 url: https://vpce-id.ec2.us-west-2.vpce.amazonaws.com hostedZone: Z3URY6TWQ91KVV fips: false sshKey: ssh-ed25519 AAAA... pullSecret: '{"auths":{"<local_registry>": {"auth": "<credentials>","email": "you@example.com"}}}' additionalTrustBundle: | -----BEGIN CERTIFICATE----- <MY_TRUSTED_CA_CERT> -----END CERTIFICATE----- imageContentSources: - mirrors: - <local_registry>/<local_repository_name>/release source: quay.io/openshift-release-dev/ocp-release - mirrors: - <local_registry>/<local_repository_name>/release source: quay.io/openshift-release-dev/ocp-v4.0-art-dev
apiVersion: v1
baseDomain: example.com
credentialsMode: Mint
controlPlane:
hyperthreading: Enabled
name: master
platform:
aws:
zones:
- us-west-2a
- us-west-2b
rootVolume:
iops: 4000
size: 500
type: io1
metadataService:
authentication: Optional
type: m6i.xlarge
replicas: 3
compute:
- hyperthreading: Enabled
name: worker
platform:
aws:
rootVolume:
iops: 2000
size: 500
type: io1
metadataService:
authentication: Optional
type: c5.4xlarge
zones:
- us-west-2c
replicas: 3
metadata:
name: test-cluster
networking:
clusterNetwork:
- cidr: 10.128.0.0/14
hostPrefix: 23
machineNetwork:
- cidr: 10.0.0.0/16
networkType: OVNKubernetes
serviceNetwork:
- 172.30.0.0/16
platform:
aws:
region: us-west-2
propagateUserTags: true
userTags:
adminContact: jdoe
costCenter: 7536
subnets:
- subnet-1
- subnet-2
- subnet-3
amiID: ami-0c5d3e03c0ab9b19a
serviceEndpoints:
- name: ec2
url: https://vpce-id.ec2.us-west-2.vpce.amazonaws.com
hostedZone: Z3URY6TWQ91KVV
fips: false
sshKey: ssh-ed25519 AAAA...
pullSecret: '{"auths":{"<local_registry>": {"auth": "<credentials>","email": "you@example.com"}}}'
additionalTrustBundle: |
-----BEGIN CERTIFICATE-----
<MY_TRUSTED_CA_CERT>
-----END CERTIFICATE-----
imageContentSources:
- mirrors:
- <local_registry>/<local_repository_name>/release
source: quay.io/openshift-release-dev/ocp-release
- mirrors:
- <local_registry>/<local_repository_name>/release
source: quay.io/openshift-release-dev/ocp-v4.0-art-dev
- 1 12 14
- 必須。インストールプログラムはこの値の入力を求めるプロンプトを出します。
- 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 モードの設定の詳細は、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
<local_registry>
については、レジストリードメイン名と、ミラーレジストリーがコンテンツを提供するために使用するポートをオプションで指定します。例:registry.example.com
またはregistry.example.com:5000
<credentials>
について、ミラーレジストリーの base64 でエンコードされたユーザー名およびパスワードを指定します。- 23
- ミラーレジストリーに使用した証明書ファイルの内容を指定します。
- 24
- リポジトリーのミラーリングに使用するコマンドの出力の
imageContentSources
セクションを指定します。
4.6.6.3. インストール時のクラスター全体のプロキシーの設定
実稼働環境では、インターネットへの直接アクセスを拒否し、代わりに 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 apiVersion: v1 baseDomain: my.domain.com proxy: httpProxy: http://<username>:<pswd>@<ip>:<port> httpsProxy: https://<username>:<pswd>@<ip>:<port> noProxy: ec2.<aws_region>.amazonaws.com,elasticloadbalancing.<aws_region>.amazonaws.com,s3.<aws_region>.amazonaws.com additionalTrustBundle: | -----BEGIN CERTIFICATE----- <MY_TRUSTED_CA_CERT> -----END CERTIFICATE----- additionalTrustBundlePolicy: <policy_to_add_additionalTrustBundle>
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
コマンドを使用してデプロイメントを再起動してからデプロイメントを完了します。以下に例を示します。Copy to Clipboard Copied! Toggle word wrap Toggle overflow ./openshift-install wait-for install-complete --log-level debug
$ ./openshift-install wait-for install-complete --log-level debug
- ファイルを保存し、OpenShift Container Platform のインストール時にこれを参照します。
インストールプログラムは、指定の install-config.yaml
ファイルのプロキシー設定を使用する cluster
という名前のクラスター全体のプロキシーを作成します。プロキシー設定が指定されていない場合、cluster
Proxy
オブジェクトが依然として作成されますが、これには spec
がありません。
cluster
という名前の Proxy
オブジェクトのみがサポートされ、追加のプロキシーを作成することはできません。
4.6.7. バイナリーのダウンロードによる OpenShift CLI のインストール
コマンドラインインターフェイスを使用して OpenShift Container Platform と対話するために CLI (oc
) をインストールすることができます。oc
は Linux、Windows、または macOS にインストールできます。
以前のバージョンの oc
をインストールしている場合、これを使用して OpenShift Container Platform 4.15 のすべてのコマンドを実行することはできません。新規バージョンの oc
をダウンロードし、インストールします。
Linux への OpenShift CLI のインストール
以下の手順を使用して、OpenShift CLI (oc
) バイナリーを Linux にインストールできます。
手順
- Red Hat カスタマーポータルの OpenShift Container Platform ダウンロードページ に移動します。
- Product Variant ドロップダウンリストからアーキテクチャーを選択します。
- バージョン ドロップダウンリストから適切なバージョンを選択します。
- OpenShift v4.15 Linux Client エントリーの横にある Download Now をクリックして、ファイルを保存します。
アーカイブを展開します。
Copy to Clipboard Copied! Toggle word wrap Toggle overflow tar xvf <file>
$ tar xvf <file>
oc
バイナリーを、PATH
にあるディレクトリーに配置します。PATH
を確認するには、以下のコマンドを実行します。Copy to Clipboard Copied! Toggle word wrap Toggle overflow echo $PATH
$ echo $PATH
検証
OpenShift CLI のインストール後に、
oc
コマンドを使用して利用できます。Copy to Clipboard Copied! Toggle word wrap Toggle overflow oc <command>
$ oc <command>
Windows への OpenShift CLI のインストール
以下の手順を使用して、OpenShift CLI (oc
) バイナリーを Windows にインストールできます。
手順
- Red Hat カスタマーポータルの OpenShift Container Platform ダウンロードページ に移動します。
- バージョン ドロップダウンリストから適切なバージョンを選択します。
- OpenShift v4.15 Windows Client エントリーの横にある Download Now をクリックして、ファイルを保存します。
- ZIP プログラムでアーカイブを展開します。
oc
バイナリーを、PATH
にあるディレクトリーに移動します。PATH
を確認するには、コマンドプロンプトを開いて以下のコマンドを実行します。Copy to Clipboard Copied! Toggle word wrap Toggle overflow path
C:\> path
検証
OpenShift CLI のインストール後に、
oc
コマンドを使用して利用できます。Copy to Clipboard Copied! Toggle word wrap Toggle overflow oc <command>
C:\> oc <command>
macOS への OpenShift CLI のインストール
以下の手順を使用して、OpenShift CLI (oc
) バイナリーを macOS にインストールできます。
手順
- Red Hat カスタマーポータルの OpenShift Container Platform ダウンロードページ に移動します。
- バージョン ドロップダウンリストから適切なバージョンを選択します。
OpenShift v4.15 macOS Client エントリーの横にある Download Now をクリックして、ファイルを保存します。
注記macOS arm64 の場合は、OpenShift v4.15 macOS arm64 Client エントリーを選択します。
- アーカイブを展開し、解凍します。
oc
バイナリーをパスにあるディレクトリーに移動します。PATH
を確認するには、ターミナルを開き、以下のコマンドを実行します。Copy to Clipboard Copied! Toggle word wrap Toggle overflow echo $PATH
$ echo $PATH
検証
oc
コマンドを使用してインストールを確認します。Copy to Clipboard Copied! Toggle word wrap Toggle overflow oc <command>
$ oc <command>
4.6.8. 管理者レベルのシークレットを kube-system プロジェクトに保存する代替方法
デフォルトでは、管理者のシークレットは kube-system
プロジェクトに保存されます。install-config.yaml
ファイルの credentialsMode
パラメーターを Manual
に設定した場合は、次のいずれかの代替手段を使用する必要があります。
- 長期クラウド認証情報を手動で管理するには、長期認証情報を手動で作成する の手順に従ってください。
- クラスターの外部で管理される短期認証情報を個々のコンポーネントに対して実装するには、短期認証情報を使用するように AWS クラスターを設定する の手順に従ってください。
4.6.8.1. 長期認証情報を手動で作成する
Cloud Credential Operator (CCO) は、クラウドアイデンティティーおよびアクセス管理 (IAM) API に到達できない環境にインストールする前に手動モードに配置できます。管理者はクラスター kube-system
namespace に管理者レベルの認証情報シークレットを保存しないようにします。
手順
install-config.yaml
設定ファイルのcredentialsMode
パラメーターをManual
に設定しなかった場合は、次のように値を変更します。設定ファイルのサンプルスニペット
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 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>
ここで、
<installation_directory>
は、インストールプログラムがファイルを作成するディレクトリーに置き換えます。次のコマンドを実行して、インストールファイルのリリースイメージを
$RELEASE_IMAGE
変数に設定します。Copy to Clipboard Copied! Toggle word wrap Toggle overflow RELEASE_IMAGE=$(./openshift-install version | awk '/release image/ {print $3}')
$ RELEASE_IMAGE=$(./openshift-install version | awk '/release image/ {print $3}')
以下のコマンドを実行して、OpenShift Container Platform リリースイメージから
CredentialsRequest
カスタムリソース (CR) のリストを抽出します。Copy to Clipboard Copied! Toggle word wrap Toggle overflow oc adm release extract \ --from=$RELEASE_IMAGE \ --credentials-requests \ --included \ --install-config=<path_to_directory_with_installation_configuration>/install-config.yaml \ --to=<path_to_directory_for_credentials_requests>
$ 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
オブジェクトCopy to Clipboard Copied! Toggle word wrap Toggle overflow 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: "*" ...
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
オブジェクトのサンプルCopy to Clipboard Copied! Toggle word wrap Toggle overflow 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> ...
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
オブジェクトCopy to Clipboard Copied! Toggle word wrap Toggle overflow 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>
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.6.8.2. 短期認証情報を使用するように AWS クラスターを設定
AWS Security Token Service (STS) を使用するように設定されたクラスターをインストールするには、CCO ユーティリティーを設定し、クラスターに必要な AWS リソースを作成する必要があります。
4.6.8.2.1. Cloud Credential Operator ユーティリティーの設定
Cloud Credential Operator (CCO) が手動モードで動作しているときにクラスターの外部からクラウドクレデンシャルを作成および管理するには、CCO ユーティリティー (ccoctl
) バイナリーを抽出して準備します。
ccoctl
ユーティリティーは、Linux 環境で実行する必要がある Linux バイナリーです。
前提条件
- クラスター管理者のアクセスを持つ OpenShift Container Platform アカウントを使用できる。
-
OpenShift CLI (
oc
) がインストールされている。
ccoctl
ユーティリティー用の AWS アカウントを作成し、次の権限で使用できるようにしました。例4.25 必要な 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.26 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 リリースイメージの変数を設定します。
Copy to Clipboard Copied! Toggle word wrap Toggle overflow RELEASE_IMAGE=$(./openshift-install version | awk '/release image/ {print $3}')
$ RELEASE_IMAGE=$(./openshift-install version | awk '/release image/ {print $3}')
以下のコマンドを実行して、OpenShift Container Platform リリースイメージから CCO コンテナーイメージを取得します。
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 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)
注記$RELEASE_IMAGE
のアーキテクチャーが、ccoctl
ツールを使用する環境のアーキテクチャーと一致していることを確認してください。以下のコマンドを実行して、OpenShift Container Platform リリースイメージ内の CCO コンテナーイメージから
ccoctl
バイナリーを抽出します。Copy to Clipboard Copied! Toggle word wrap Toggle overflow oc image extract $CCO_IMAGE --file="/usr/bin/ccoctl" -a ~/.pull-secret
$ oc image extract $CCO_IMAGE --file="/usr/bin/ccoctl" -a ~/.pull-secret
次のコマンドを実行して、権限を変更して
ccoctl
を実行可能にします。Copy to Clipboard Copied! Toggle word wrap Toggle overflow chmod 775 ccoctl
$ chmod 775 ccoctl
検証
ccoctl
が使用できることを確認するには、help ファイルを表示します。コマンドを実行するときは、相対ファイル名を使用します。以下に例を示します。Copy to Clipboard Copied! Toggle word wrap Toggle overflow ./ccoctl.rhel9
$ ./ccoctl.rhel9
出力例
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 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.
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.6.8.2.2. Cloud Credential Operator ユーティリティーを使用した AWS リソースの作成
AWS リソースを作成するときは、次のオプションがあります。
-
ccoctl aws create-all
コマンドを使用して AWS リソースを自動的に作成できます。これはリソースを作成する最も簡単な方法です。単一コマンドでの AWS リソースの作成 を参照してください。 -
AWS リソースの変更前に
ccoctl
ツールが作成する JSON ファイルを確認する必要がある場合や、ccoctl
ツールが AWS リソースを自動作成するために使用するプロセスが組織の要件を満たさない場合は、AWS リソースを個別に作成できます。AWS リソースの個別の作成 を参照してください。
4.6.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
変数に設定します。Copy to Clipboard Copied! Toggle word wrap Toggle overflow RELEASE_IMAGE=$(./openshift-install version | awk '/release image/ {print $3}')
$ RELEASE_IMAGE=$(./openshift-install version | awk '/release image/ {print $3}')
以下のコマンドを実行して、OpenShift Container Platform リリースイメージから
CredentialsRequest
オブジェクトのリストを抽出します。Copy to Clipboard Copied! Toggle word wrap Toggle overflow oc adm release extract \ --from=$RELEASE_IMAGE \ --credentials-requests \ --included \ --install-config=<path_to_directory_with_installation_configuration>/install-config.yaml \ --to=<path_to_directory_for_credentials_requests>
$ 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
オブジェクトをすべて処理します。Copy to Clipboard Copied! Toggle word wrap Toggle overflow ccoctl aws create-all \ --name=<name> \ --region=<aws_region> \ --credentials-requests-dir=<path_to_credentials_requests_directory> \ --output-dir=<path_to_ccoctl_output_dir> \ --create-private-s3-bucket
$ 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
ディレクトリーのファイルを一覧表示します。Copy to Clipboard Copied! Toggle word wrap Toggle overflow ls <path_to_ccoctl_output_dir>/manifests
$ ls <path_to_ccoctl_output_dir>/manifests
出力例
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 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
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.6.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 キーファイルを生成します。
Copy to Clipboard Copied! Toggle word wrap Toggle overflow ccoctl aws create-key-pair
$ ccoctl aws create-key-pair
出力例
Copy 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 installer
serviceaccount-signer.private
およびserviceaccount-signer.public
は、生成されるキーファイルです。このコマンドは、クラスターがインストール時に必要とするプライベートキーを
/<path_to_ccoctl_output_dir>/tls/bound-service-account-signing-key.key
に作成します。次のコマンドを実行して、AWS 上に OpenID Connect ID プロバイダーと S3 バケットを作成します。
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 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.public
3 出力例
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.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
変数に設定します。Copy to Clipboard Copied! Toggle word wrap Toggle overflow RELEASE_IMAGE=$(./openshift-install version | awk '/release image/ {print $3}')
$ RELEASE_IMAGE=$(./openshift-install version | awk '/release image/ {print $3}')
OpenShift Container Platform リリースイメージから
CredentialsRequest
オブジェクトの一覧を抽出します。Copy to Clipboard Copied! Toggle word wrap Toggle overflow oc adm release extract \ --from=$RELEASE_IMAGE \ --credentials-requests \ --included \ --install-config=<path_to_directory_with_installation_configuration>/install-config.yaml \ --to=<path_to_directory_for_credentials_requests>
$ 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
オブジェクトをすべて処理します。Copy to Clipboard Copied! Toggle word wrap Toggle overflow 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.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
ディレクトリーのファイルを一覧表示します。Copy to Clipboard Copied! Toggle word wrap Toggle overflow ls <path_to_ccoctl_output_dir>/manifests
$ ls <path_to_ccoctl_output_dir>/manifests
出力例
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 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
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.6.8.2.3. Cloud Credential Operator ユーティリティーマニフェストの組み込み
個々のコンポーネントに対してクラスターの外部で管理される短期セキュリティー認証情報を実装するには、Cloud Credential Operator ユーティリティー (ccoctl
) が作成したマニフェストファイルを、インストールプログラムの正しいディレクトリーに移動する必要があります。
前提条件
- クラスターをホストするクラウドプラットフォームでアカウントを設定しました。
-
Cloud Credential Operator ユーティリティー (
ccoctl
) が設定されている。 -
ccoctl
ユーティリティーを使用して、クラスターに必要なクラウドプロバイダーリソースを作成している。
手順
install-config.yaml
設定ファイルのcredentialsMode
パラメーターをManual
に設定しなかった場合は、次のように値を変更します。設定ファイルのサンプルスニペット
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 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>
ここで、
<installation_directory>
は、インストールプログラムがファイルを作成するディレクトリーに置き換えます。次のコマンドを実行して、
ccoctl
ユーティリティーが生成したマニフェストを、インストールプログラムが作成したmanifests
ディレクトリーにコピーします。Copy to Clipboard Copied! Toggle word wrap Toggle overflow cp /<path_to_ccoctl_output_dir>/manifests/* ./manifests/
$ cp /<path_to_ccoctl_output_dir>/manifests/* ./manifests/
秘密鍵を含む
tls
ディレクトリーをインストールディレクトリーにコピーします。Copy to Clipboard Copied! Toggle word wrap Toggle overflow cp -a /<path_to_ccoctl_output_dir>/tls .
$ cp -a /<path_to_ccoctl_output_dir>/tls .
4.6.9. クラスターのデプロイ
互換性のあるクラウドプラットフォームに OpenShift Container Platform をインストールできます。
インストールプログラムの create cluster
コマンドは、初期インストール時に 1 回だけ実行できます。
前提条件
- クラスターをホストするクラウドプラットフォームでアカウントを設定しました。
- OpenShift Container Platform インストールプログラムおよびクラスターのプルシークレットがある。
- ホスト上のクラウドプロバイダーアカウントに、クラスターをデプロイするための適切な権限があることが確認されました。アカウントの権限が正しくないと、インストールプロセスが失敗し、不足している権限を示すエラーメッセージが表示されます。
手順
インストールプログラムが含まれるディレクトリーに切り替え、クラスターのデプロイメントを初期化します。
Copy to Clipboard Copied! Toggle word wrap Toggle overflow ./openshift-install create cluster --dir <installation_directory> \ --log-level=info
$ ./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
...
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.6.10. CLI の使用によるクラスターへのログイン
クラスター kubeconfig
ファイルをエクスポートし、デフォルトシステムユーザーとしてクラスターにログインできます。kubeconfig
ファイルには、クライアントを正しいクラスターおよび API サーバーに接続するために CLI で使用されるクラスターに関する情報が含まれます。このファイルはクラスターに固有のファイルであり、OpenShift Container Platform のインストール時に作成されます。
前提条件
- OpenShift Container Platform クラスターをデプロイしていること。
-
oc
CLI をインストールしていること。
手順
kubeadmin
認証情報をエクスポートします。Copy to Clipboard Copied! Toggle word wrap Toggle overflow export KUBECONFIG=<installation_directory>/auth/kubeconfig
$ export KUBECONFIG=<installation_directory>/auth/kubeconfig
1 - 1
<installation_directory>
には、インストールファイルを保存したディレクトリーへのパスを指定します。
エクスポートされた設定を使用して、
oc
コマンドを正常に実行できることを確認します。Copy to Clipboard Copied! Toggle word wrap Toggle overflow oc whoami
$ oc whoami
出力例
Copy to Clipboard Copied! Toggle word wrap Toggle overflow system:admin
system:admin
4.6.11. デフォルトの OperatorHub カタログソースの無効化
Red Hat によって提供されるコンテンツを調達する Operator カタログおよびコミュニティープロジェクトは、OpenShift Container Platform のインストール時にデフォルトで OperatorHub に設定されます。ネットワークが制限された環境では、クラスター管理者としてデフォルトのカタログを無効にする必要があります。
手順
disableAllDefaultSources: true
をOperatorHub
オブジェクトに追加して、デフォルトカタログのソースを無効にします。Copy to Clipboard Copied! Toggle word wrap Toggle overflow oc patch OperatorHub cluster --type json \ -p '[{"op": "add", "path": "/spec/disableAllDefaultSources", "value": true}]'
$ oc patch OperatorHub cluster --type json \ -p '[{"op": "add", "path": "/spec/disableAllDefaultSources", "value": true}]'
または、Web コンソールを使用してカタログソースを管理できます。Administration → Cluster Settings → Configuration → OperatorHub ページから、Sources タブをクリックして、個別のソースを作成、更新、削除、無効化、有効化できます。
4.6.12. OpenShift Container Platform の Telemetry アクセス
OpenShift Container Platform 4.15 では、クラスターの健全性および正常に実行された更新についてのメトリクスを提供するためにデフォルトで実行される Telemetry サービスにも、インターネットアクセスが必要です。クラスターがインターネットに接続されている場合、Telemetry は自動的に実行され、クラスターは OpenShift Cluster Manager に登録されます。
OpenShift Cluster Manager インベントリーが正常である (Telemetry によって自動的に維持、または OpenShift Cluster Manager を使用して手動で維持) ことを確認した後に、subscription watch を使用 して、アカウントまたはマルチクラスターレベルで OpenShift Container Platform サブスクリプションを追跡します。
関連情報
- Telemetry サービスの詳細は、リモートヘルスモニタリング を参照してください。
4.6.13. 次のステップ
- インストールを検証 します。
- クラスターをカスタマイズ します。
-
Cluster Samples Operator および
must-gather
ツールの イメージストリームを設定 します。 - ネットワークが制限された環境での Operator Lifecycle Manager (OLM) の使用 方法について参照します。
- クラスターのインストールに使用したミラーレジストリーに信頼された CA がある場合は、追加のトラストストアを設定 してクラスターに追加します。
- 必要に応じて、リモートヘルスレポートをオプトアウト できます。
4.7. AWS のクラスターの既存 VPC へのインストール
OpenShift Container Platform バージョン 4.15 では、Amazon Web Services (AWS) 上の既存の Amazon Virtual Private Cloud (VPC) にクラスターをインストールできます。インストールプログラムは、カスタマイズ可能な残りの必要なインフラストラクチャーをプロビジョニングします。インストールをカスタマイズするには、クラスターをインストールする前に、install-config.yaml
ファイルでパラメーターを変更します。
4.7.1. 前提条件
- OpenShift Container Platform のインストールおよび更新 プロセスの詳細を確認した。
- クラスターインストール方法の選択およびそのユーザー向けの準備 を確認した。
- クラスターをホストするために AWS アカウントを設定 している。
既存の VPC がクラスターとは異なるアカウントによって所有されている場合は、アカウント間で VPC を共有 しています。
重要AWS プロファイルがご使用のコンピューターに保存されている場合、マルチファクター認証デバイスを使用中に生成した一時的なセッショントークンを使用することはできません。クラスターは継続的に現行の AWS 認証情報を使用して、クラスターの有効期間全体にわたって AWS リソースを作成するため、有効期間の長い認証情報を使用する必要があります。適切なキーを生成するには、AWS ドキュメントの Managing Access Keys for IAM Users を参照してください。キーは、インストールプログラムの実行時に指定できます。
- ファイアウォールを使用する場合は、クラスターがアクセスを必要とするサイトを許可するようにファイアウォールを設定する必要がある。
4.7.2. カスタム VPC の使用について
OpenShift Container Platform 4.15 では、Amazon Web Services (AWS) の既存の Amazon Virtual Private Cloud (VPC) における既存サブネットにクラスターをデプロイできます。OpenShift Container Platform を既存の AWS VPC にデプロイすると、新規アカウントの制限を回避したり、会社のガイドラインによる運用上の制約をより容易に遵守することが可能になる場合があります。VPC を作成するために必要なインフラストラクチャーの作成パーミッションを取得できない場合は、このインストールオプションを使用します。
インストールプログラムは既存のサブネットにある他のコンポーネントを把握できないため、ユーザーの代わりにサブネットの CIDR を選択することはできません。クラスターをインストールするサブネットのネットワークを独自に設定する必要があります。
4.7.2.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 は以下の特性を満たす必要があります。
クラスターが使用するアベイラビリティーゾーンごとにパブリックサブネットとプライベートサブネットを作成します。それぞれのアベイラビリティーゾーンには、複数のパブリックおよびプライベートサブネットがありません。このタイプの設定の例は、AWS ドキュメントの パブリックサブネットとプライベートサブネット (NAT) を使用した VPC を参照してください。
各サブネット ID を記録します。インストールを完了するには、
install-config.yaml
ファイルのプラットフォーム
セクションにこれらの値を入力する必要があります。AWS ドキュメントの サブネット ID の検索 を参照してください。-
VPC の CIDR ブロックには、クラスターマシンの IP アドレスプールである
Networking.MachineCIDR
範囲が含まれている必要があります。サブネット CIDR ブロックは、指定したマシン CIDR に属している必要があります。 VPC には、パブリックインターネットゲートウェイが接続されている必要があります。アベイラビリティーゾーンごとに以下が必要です。
- パブリックサブネットには、インターネットゲートウェイへのルートが必要です。
- パブリックサブネットには、EIP アドレスが割り当てられた NAT ゲートウェイが必要です。
- プライベートサブネットには、パブリックサブネットの NAT ゲートウェイへのルートが必要です。
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 アベイラビリティーゾーンのプライベートサブネットを作成できます。プライベートサブネットを使用できる場合は、それらの適切なルートおよびテーブルを指定する必要があります。 |
4.7.2.2. VPC 検証
指定するサブネットが適切であることを確認するには、インストールプログラムが以下のデータを確認します。
- 指定したサブネットすべてが存在します。
- プライベートサブネットを指定します。
- サブネットの CIDR は指定されたマシン CIDR に属します。
- 各アベイラビリティーゾーンのサブネットを指定します。それぞれのアベイラビリティーゾーンには、複数のパブリックおよびプライベートサブネットがありません。プライベートクラスターを使用する場合、各アベイラビリティーゾーンのプライベートサブネットのみを指定します。それ以外の場合は、各アベイラビリティーゾーンのパブリックサブネットおよびプライベートサブネットを指定します。
- 各プライベートサブネットアベイラビリティーゾーンのパブリックサブネットを指定します。マシンは、プライベートサブネットを指定しないアベイラビリティーゾーンにはプロビジョニングされません。
既存の VPC を使用するクラスターを破棄しても、VPC は削除されません。VPC から OpenShift Container Platform クラスターを削除する場合、kubernetes.io/cluster/.*: shared
タグは、それが使用したサブネットから削除されます。
4.7.2.3. パーミッションの区分
OpenShift Container Platform 4.3 以降、クラスターのデプロイに、インストールプログラムがプロビジョニングするインフラストラクチャークラスターに必要なすべてのパーミッションを必要としなくなりました。この変更は、ある会社で個人がクラウドで他とは異なるリソースを作成できるようにパーミッションが区分された状態に類似するものです。たとえば、インスタンス、バケット、ロードバランサーなどのアプリケーション固有のアイテムを作成することはできますが、VPC、サブネット、または Ingress ルールなどのネットワーク関連のコンポーネントは作成できない可能性があります。
クラスターの作成時に使用する AWS の認証情報には、VPC、およびサブネット、ルーティングテーブル、インターネットゲートウェイ、NAT、VPN などの VPC 内のコアとなるネットワークコンポーネントの作成に必要なネットワークのパーミッションは必要ありません。ELB、セキュリティーグループ、S3 バケットおよびノードなどの、クラスター内でマシンに必要なアプリケーションリソースを作成するパーミッションは依然として必要になります。
4.7.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.7.2.5. オプション: AWS セキュリティーグループ
デフォルトでは、インストールプログラムは、セキュリティーグループを作成し、コントロールプレーンとコンピュートマシンに接続します。デフォルトのセキュリティーグループに関連付けられたルールは変更できません。
ただし、既存の VPC に関連付けられている追加の既存の AWS セキュリティーグループをコントロールプレーンとコンピュートマシンに適用できます。カスタムセキュリティーグループを適用すると、これらのマシンの受信トラフィックまたは送信トラフィックを制御する必要がある場合に、組織のセキュリティーニーズを満たすことができます。
インストールプロセスの一環として、クラスターをデプロイする前に install-config.yaml
ファイルを変更してカスタムセキュリティーグループを適用します。
詳細は、「既存の AWS セキュリティーグループのクラスターへの適用」を参照してください。
4.7.3. OpenShift Container Platform のインターネットアクセス
OpenShift Container Platform 4.15 では、クラスターをインストールするためにインターネットアクセスが必要になります。
インターネットへのアクセスは以下を実行するために必要です。
- OpenShift Cluster Manager にアクセスし、インストールプログラムをダウンロードし、サブスクリプション管理を実行します。クラスターにインターネットアクセスがあり、Telemetry を無効にしない場合、そのサービスは有効なサブスクリプションでクラスターを自動的に使用します。
- クラスターのインストールに必要なパッケージを取得するために Quay.io にアクセスします。
- クラスターの更新を実行するために必要なパッケージを取得します。
クラスターでインターネットに直接アクセスできない場合、プロビジョニングする一部のタイプのインフラストラクチャーでネットワークが制限されたインストールを実行できます。このプロセスで、必要なコンテンツをダウンロードし、これを使用してミラーレジストリーにインストールパッケージを設定します。インストールタイプによっては、クラスターのインストール環境でインターネットアクセスが不要となる場合があります。クラスターを更新する前に、ミラーレジストリーのコンテンツを更新します。
4.7.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 オペレーティングシステムを使用するコンピューターで以下のコマンドを実行します。
Copy to Clipboard Copied! Toggle word wrap Toggle overflow ssh-keygen -t ed25519 -N '' -f <path>/<file_name>
$ 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 キーを表示します。
Copy to Clipboard Copied! Toggle word wrap Toggle overflow cat <path>/<file_name>.pub
$ cat <path>/<file_name>.pub
たとえば、次のコマンドを実行して
~/.ssh/id_ed25519.pub
公開鍵を表示します。Copy to Clipboard Copied! Toggle word wrap Toggle overflow cat ~/.ssh/id_ed25519.pub
$ cat ~/.ssh/id_ed25519.pub
ローカルユーザーの SSH エージェントに SSH 秘密鍵 ID が追加されていない場合は、それを追加します。キーの SSH エージェント管理は、クラスターノードへのパスワードなしの SSH 認証、または
./openshift-install gather
コマンドを使用する場合は必要になります。注記一部のディストリビューションでは、
~/.ssh/id_rsa
および~/.ssh/id_dsa
などのデフォルトの SSH 秘密鍵のアイデンティティーは自動的に管理されます。ssh-agent
プロセスがローカルユーザーに対して実行されていない場合は、バックグラウンドタスクとして開始します。Copy to Clipboard Copied! Toggle word wrap Toggle overflow eval "$(ssh-agent -s)"
$ eval "$(ssh-agent -s)"
出力例
Copy to Clipboard Copied! Toggle word wrap Toggle overflow Agent pid 31874
Agent pid 31874
注記クラスターが FIPS モードにある場合は、FIPS 準拠のアルゴリズムのみを使用して SSH キーを生成します。鍵は RSA または ECDSA のいずれかである必要があります。
SSH プライベートキーを
ssh-agent
に追加します。Copy to Clipboard Copied! Toggle word wrap Toggle overflow ssh-add <path>/<file_name>
$ ssh-add <path>/<file_name>
1 - 1
~/.ssh/id_ed25519
などの、SSH プライベートキーのパスおよびファイル名を指定します。
出力例
Copy to Clipboard Copied! Toggle word wrap Toggle overflow Identity added: /home/<you>/<path>/<file_name> (<computer_name>)
Identity added: /home/<you>/<path>/<file_name> (<computer_name>)
次のステップ
- OpenShift Container Platform をインストールする際に、SSH パブリックキーをインストールプログラムに指定します。
4.7.5. インストールプログラムの取得
OpenShift Container Platform をインストールする前に、インストールに使用しているホストにインストールファイルをダウンロードします。
前提条件
- 500 MB のローカルディスク領域がある Linux または macOS を実行するコンピューターが必要です。
手順
- OpenShift Cluster Manager サイトの インフラストラクチャープロバイダー ページにアクセスします。Red Hat アカウントがある場合は、認証情報を使用してログインします。アカウントがない場合はこれを作成します。
- インフラストラクチャープロバイダーを選択します。
インストールタイプのページに移動し、ホストオペレーティングシステムとアーキテクチャーに対応するインストールプログラムをダウンロードして、インストール設定ファイルを保存するディレクトリーにファイルを配置します。
重要インストールプログラムは、クラスターのインストールに使用するコンピューターにいくつかのファイルを作成します。クラスターのインストール完了後は、インストールプログラムおよびインストールプログラムが作成するファイルを保持する必要があります。ファイルはいずれもクラスターを削除するために必要になります。
重要インストールプログラムで作成されたファイルを削除しても、クラスターがインストール時に失敗した場合でもクラスターは削除されません。クラスターを削除するには、特定のクラウドプロバイダー用の OpenShift Container Platform のアンインストール手順を実行します。
インストールプログラムを展開します。たとえば、Linux オペレーティングシステムを使用するコンピューターで以下のコマンドを実行します。
Copy to Clipboard Copied! Toggle word wrap Toggle overflow tar -xvf openshift-install-linux.tar.gz
$ tar -xvf openshift-install-linux.tar.gz
- Red Hat OpenShift Cluster Manager からインストールプルシークレット をダウンロードします。このプルシークレットを使用し、OpenShift Container Platform コンポーネントのコンテナーイメージを提供する Quay.io など、組み込まれた各種の認証局によって提供されるサービスで認証できます。
4.7.6. インストール設定ファイルの作成
Amazon Web Services (AWS) での OpenShift Container Platform のインストールをカスタマイズできます。
前提条件
- OpenShift Container Platform インストールプログラムおよびクラスターのプルシークレットがある。
手順
install-config.yaml
ファイルを作成します。インストールプログラムが含まれるディレクトリーに切り替え、以下のコマンドを実行します。
Copy to Clipboard Copied! Toggle word wrap Toggle overflow ./openshift-install create install-config --dir <installation_directory>
$ ./openshift-install create install-config --dir <installation_directory>
1 - 1
<installation_directory>
の場合、インストールプログラムが作成するファイルを保存するためにディレクトリー名を指定します。
ディレクトリーを指定する場合:
-
ディレクトリーに
execute
権限があることを確認します。この権限は、インストールディレクトリーで Terraform バイナリーを実行するために必要です。 - 空のディレクトリーを使用します。ブートストラップ X.509 証明書などの一部のインストールアセットは有効期限が短いため、インストールディレクトリーを再利用しないでください。別のクラスターインストールの個別のファイルを再利用する必要がある場合は、それらをディレクトリーにコピーすることができます。ただし、インストールアセットのファイル名はリリース間で変更される可能性があります。インストールファイルを以前のバージョンの OpenShift Container Platform からコピーする場合は注意してコピーを行ってください。
プロンプト時に、クラウドの設定の詳細情報を指定します。
オプション: クラスターマシンにアクセスするために使用する SSH キーを選択します。
注記インストールのデバッグまたは障害復旧を実行する必要のある実稼働用の OpenShift Container Platform クラスターでは、
ssh-agent
プロセスが使用する SSH キーを指定します。- ターゲットに設定するプラットフォームとして AWS を選択します。
- Amazon Web Services (AWS) プロファイルをコンピューターに保存していない場合、インストールプログラムを実行するように設定したユーザーの AWS アクセスキー ID およびシークレットアクセスキーを入力します。
- クラスターのデプロイ先とする AWS リージョンを選択します。
- クラスターに設定した Route 53 サービスのベースドメインを選択します。
- クラスターの記述名を入力します。
-
install-config.yaml
ファイルを変更します。利用可能なパラメーターの詳細は、「インストール設定パラメーター」のセクションを参照してください。 install-config.yaml
ファイルをバックアップし、複数のクラスターをインストールするのに使用できるようにします。重要install-config.yaml
ファイルはインストールプロセス時に使用されます。このファイルを再利用する必要がある場合は、この段階でこれをバックアップしてください。
関連情報
4.7.6.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 で使用することがサポートされます。
関連情報
4.7.6.2. AWS のテスト済みインスタンスタイプ
以下の Amazon Web Services (AWS) インスタンスタイプは OpenShift Container Platform でテストされています。
AWS インスタンスには、次の表に記載されているマシンタイプを使用してください。表に記載されていないインスタンスタイプを使用する場合は、使用するインスタンスサイズが、「クラスターインストールの最小リソース要件」セクションに記載されている最小リソース要件と一致していることを確認してください。
例4.28 64 ビット x86 アーキテクチャーに基づくマシンタイプ
-
c4.*
-
c5.*
-
c5a.*
-
i3.*
-
m4.*
-
m5.*
-
m5a.*
-
m6a.*
-
m6i.*
-
r4.*
-
r5.*
-
r5a.*
-
r6i.*
-
t3.*
-
t3a.*
4.7.6.3. 64 ビット ARM インフラストラクチャー上の AWS のテスト済みインスタンスタイプ
次の Amazon Web Services (AWS) 64 ビット ARM インスタンスタイプは、OpenShift Container Platform でテストされています。
AWS ARM インスタンスには、次のチャートに含まれるマシンタイプを使用してください。チャートに記載されていないインスタンスタイプを使用する場合は、使用するインスタンスサイズが、「クラスターインストールの最小リソース要件」に記載されている最小リソース要件と一致していることを確認してください。
例4.29 64 ビット ARM アーキテクチャーに基づくマシンタイプ
-
c6g.*
-
c7g.*
-
m6g.*
-
m7g.*
-
r8g.*
4.7.6.4. AWS のカスタマイズされた install-config.yaml ファイルのサンプル
インストール設定ファイル install-config.yaml
をカスタマイズして、OpenShift Container Platform クラスターのプラットフォームに関する詳細を指定するか、必要なパラメーターの値を変更することができます。
このサンプルの YAML ファイルは参照用にのみ提供されます。インストールプログラムを使用して install-config.yaml
ファイルを取得し、これを変更する必要があります。
apiVersion: v1 baseDomain: example.com credentialsMode: Mint controlPlane: hyperthreading: Enabled name: master platform: aws: zones: - us-west-2a - us-west-2b rootVolume: iops: 4000 size: 500 type: io1 metadataService: authentication: Optional type: m6i.xlarge replicas: 3 compute: - hyperthreading: Enabled name: worker platform: aws: rootVolume: iops: 2000 size: 500 type: io1 metadataService: authentication: Optional type: c5.4xlarge zones: - us-west-2c replicas: 3 metadata: name: test-cluster networking: clusterNetwork: - cidr: 10.128.0.0/14 hostPrefix: 23 machineNetwork: - cidr: 10.0.0.0/16 networkType: OVNKubernetes serviceNetwork: - 172.30.0.0/16 platform: aws: region: us-west-2 propagateUserTags: true userTags: adminContact: jdoe costCenter: 7536 subnets: - subnet-1 - subnet-2 - subnet-3 amiID: ami-0c5d3e03c0ab9b19a serviceEndpoints: - name: ec2 url: https://vpce-id.ec2.us-west-2.vpce.amazonaws.com hostedZone: Z3URY6TWQ91KVV fips: false sshKey: ssh-ed25519 AAAA... pullSecret: '{"auths": ...}'
apiVersion: v1
baseDomain: example.com
credentialsMode: Mint
controlPlane:
hyperthreading: Enabled
name: master
platform:
aws:
zones:
- us-west-2a
- us-west-2b
rootVolume:
iops: 4000
size: 500
type: io1
metadataService:
authentication: Optional
type: m6i.xlarge
replicas: 3
compute:
- hyperthreading: Enabled
name: worker
platform:
aws:
rootVolume:
iops: 2000
size: 500
type: io1
metadataService:
authentication: Optional
type: c5.4xlarge
zones:
- us-west-2c
replicas: 3
metadata:
name: test-cluster
networking:
clusterNetwork:
- cidr: 10.128.0.0/14
hostPrefix: 23
machineNetwork:
- cidr: 10.0.0.0/16
networkType: OVNKubernetes
serviceNetwork:
- 172.30.0.0/16
platform:
aws:
region: us-west-2
propagateUserTags: true
userTags:
adminContact: jdoe
costCenter: 7536
subnets:
- subnet-1
- subnet-2
- subnet-3
amiID: ami-0c5d3e03c0ab9b19a
serviceEndpoints:
- name: ec2
url: https://vpce-id.ec2.us-west-2.vpce.amazonaws.com
hostedZone: Z3URY6TWQ91KVV
fips: false
sshKey: ssh-ed25519 AAAA...
pullSecret: '{"auths": ...}'
- 1 12 14 22
- 必須。インストールプログラムはこの値の入力を求めるプロンプトを出します。
- 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 モードの設定の詳細は、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 キーを指定します。
4.7.6.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 apiVersion: v1 baseDomain: my.domain.com proxy: httpProxy: http://<username>:<pswd>@<ip>:<port> httpsProxy: https://<username>:<pswd>@<ip>:<port> noProxy: ec2.<aws_region>.amazonaws.com,elasticloadbalancing.<aws_region>.amazonaws.com,s3.<aws_region>.amazonaws.com additionalTrustBundle: | -----BEGIN CERTIFICATE----- <MY_TRUSTED_CA_CERT> -----END CERTIFICATE----- additionalTrustBundlePolicy: <policy_to_add_additionalTrustBundle>
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
コマンドを使用してデプロイメントを再起動してからデプロイメントを完了します。以下に例を示します。Copy to Clipboard Copied! Toggle word wrap Toggle overflow ./openshift-install wait-for install-complete --log-level debug
$ ./openshift-install wait-for install-complete --log-level debug
- ファイルを保存し、OpenShift Container Platform のインストール時にこれを参照します。
インストールプログラムは、指定の install-config.yaml
ファイルのプロキシー設定を使用する cluster
という名前のクラスター全体のプロキシーを作成します。プロキシー設定が指定されていない場合、cluster
Proxy
オブジェクトが依然として作成されますが、これには spec
がありません。
cluster
という名前の Proxy
オブジェクトのみがサポートされ、追加のプロキシーを作成することはできません。
4.7.6.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
- 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:
- subnet-1
- subnet-2
- subnet-3
4.7.7. バイナリーのダウンロードによる OpenShift CLI のインストール
コマンドラインインターフェイスを使用して OpenShift Container Platform と対話するために CLI (oc
) をインストールすることができます。oc
は Linux、Windows、または macOS にインストールできます。
以前のバージョンの oc
をインストールしている場合、これを使用して OpenShift Container Platform 4.15 のすべてのコマンドを実行することはできません。新規バージョンの oc
をダウンロードし、インストールします。
Linux への OpenShift CLI のインストール
以下の手順を使用して、OpenShift CLI (oc
) バイナリーを Linux にインストールできます。
手順
- Red Hat カスタマーポータルの OpenShift Container Platform ダウンロードページ に移動します。
- Product Variant ドロップダウンリストからアーキテクチャーを選択します。
- バージョン ドロップダウンリストから適切なバージョンを選択します。
- OpenShift v4.15 Linux Client エントリーの横にある Download Now をクリックして、ファイルを保存します。
アーカイブを展開します。
Copy to Clipboard Copied! Toggle word wrap Toggle overflow tar xvf <file>
$ tar xvf <file>
oc
バイナリーを、PATH
にあるディレクトリーに配置します。PATH
を確認するには、以下のコマンドを実行します。Copy to Clipboard Copied! Toggle word wrap Toggle overflow echo $PATH
$ echo $PATH
検証
OpenShift CLI のインストール後に、
oc
コマンドを使用して利用できます。Copy to Clipboard Copied! Toggle word wrap Toggle overflow oc <command>
$ oc <command>
Windows への OpenShift CLI のインストール
以下の手順を使用して、OpenShift CLI (oc
) バイナリーを Windows にインストールできます。
手順
- Red Hat カスタマーポータルの OpenShift Container Platform ダウンロードページ に移動します。
- バージョン ドロップダウンリストから適切なバージョンを選択します。
- OpenShift v4.15 Windows Client エントリーの横にある Download Now をクリックして、ファイルを保存します。
- ZIP プログラムでアーカイブを展開します。
oc
バイナリーを、PATH
にあるディレクトリーに移動します。PATH
を確認するには、コマンドプロンプトを開いて以下のコマンドを実行します。Copy to Clipboard Copied! Toggle word wrap Toggle overflow path
C:\> path
検証
OpenShift CLI のインストール後に、
oc
コマンドを使用して利用できます。Copy to Clipboard Copied! Toggle word wrap Toggle overflow oc <command>
C:\> oc <command>
macOS への OpenShift CLI のインストール
以下の手順を使用して、OpenShift CLI (oc
) バイナリーを macOS にインストールできます。
手順
- Red Hat カスタマーポータルの OpenShift Container Platform ダウンロードページ に移動します。
- バージョン ドロップダウンリストから適切なバージョンを選択します。
OpenShift v4.15 macOS Client エントリーの横にある Download Now をクリックして、ファイルを保存します。
注記macOS arm64 の場合は、OpenShift v4.15 macOS arm64 Client エントリーを選択します。
- アーカイブを展開し、解凍します。
oc
バイナリーをパスにあるディレクトリーに移動します。PATH
を確認するには、ターミナルを開き、以下のコマンドを実行します。Copy to Clipboard Copied! Toggle word wrap Toggle overflow echo $PATH
$ echo $PATH
検証
oc
コマンドを使用してインストールを確認します。Copy to Clipboard Copied! Toggle word wrap Toggle overflow oc <command>
$ oc <command>
4.7.8. 管理者レベルのシークレットを kube-system プロジェクトに保存する代替方法
デフォルトでは、管理者のシークレットは kube-system
プロジェクトに保存されます。install-config.yaml
ファイルの credentialsMode
パラメーターを Manual
に設定した場合は、次のいずれかの代替手段を使用する必要があります。
- 長期クラウド認証情報を手動で管理するには、長期認証情報を手動で作成する の手順に従ってください。
- クラスターの外部で管理される短期認証情報を個々のコンポーネントに対して実装するには、短期認証情報を使用するように AWS クラスターを設定する の手順に従ってください。
4.7.8.1. 長期認証情報を手動で作成する
Cloud Credential Operator (CCO) は、クラウドアイデンティティーおよびアクセス管理 (IAM) API に到達できない環境にインストールする前に手動モードに配置できます。管理者はクラスター kube-system
namespace に管理者レベルの認証情報シークレットを保存しないようにします。
手順
install-config.yaml
設定ファイルのcredentialsMode
パラメーターをManual
に設定しなかった場合は、次のように値を変更します。設定ファイルのサンプルスニペット
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 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>
ここで、
<installation_directory>
は、インストールプログラムがファイルを作成するディレクトリーに置き換えます。次のコマンドを実行して、インストールファイルのリリースイメージを
$RELEASE_IMAGE
変数に設定します。Copy to Clipboard Copied! Toggle word wrap Toggle overflow RELEASE_IMAGE=$(./openshift-install version | awk '/release image/ {print $3}')
$ RELEASE_IMAGE=$(./openshift-install version | awk '/release image/ {print $3}')
以下のコマンドを実行して、OpenShift Container Platform リリースイメージから
CredentialsRequest
カスタムリソース (CR) のリストを抽出します。Copy to Clipboard Copied! Toggle word wrap Toggle overflow oc adm release extract \ --from=$RELEASE_IMAGE \ --credentials-requests \ --included \ --install-config=<path_to_directory_with_installation_configuration>/install-config.yaml \ --to=<path_to_directory_for_credentials_requests>
$ 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
オブジェクトCopy to Clipboard Copied! Toggle word wrap Toggle overflow 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: "*" ...
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
オブジェクトのサンプルCopy to Clipboard Copied! Toggle word wrap Toggle overflow 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> ...
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
オブジェクトCopy to Clipboard Copied! Toggle word wrap Toggle overflow 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>
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.7.8.2. 短期認証情報を使用するように AWS クラスターを設定
AWS Security Token Service (STS) を使用するように設定されたクラスターをインストールするには、CCO ユーティリティーを設定し、クラスターに必要な AWS リソースを作成する必要があります。
4.7.8.2.1. Cloud Credential Operator ユーティリティーの設定
Cloud Credential Operator (CCO) が手動モードで動作しているときにクラスターの外部からクラウドクレデンシャルを作成および管理するには、CCO ユーティリティー (ccoctl
) バイナリーを抽出して準備します。
ccoctl
ユーティリティーは、Linux 環境で実行する必要がある Linux バイナリーです。
前提条件
- クラスター管理者のアクセスを持つ OpenShift Container Platform アカウントを使用できる。
-
OpenShift CLI (
oc
) がインストールされている。
ccoctl
ユーティリティー用の AWS アカウントを作成し、次の権限で使用できるようにしました。例4.30 必要な 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.31 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 リリースイメージの変数を設定します。
Copy to Clipboard Copied! Toggle word wrap Toggle overflow RELEASE_IMAGE=$(./openshift-install version | awk '/release image/ {print $3}')
$ RELEASE_IMAGE=$(./openshift-install version | awk '/release image/ {print $3}')
以下のコマンドを実行して、OpenShift Container Platform リリースイメージから CCO コンテナーイメージを取得します。
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 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)
注記$RELEASE_IMAGE
のアーキテクチャーが、ccoctl
ツールを使用する環境のアーキテクチャーと一致していることを確認してください。以下のコマンドを実行して、OpenShift Container Platform リリースイメージ内の CCO コンテナーイメージから
ccoctl
バイナリーを抽出します。Copy to Clipboard Copied! Toggle word wrap Toggle overflow oc image extract $CCO_IMAGE --file="/usr/bin/ccoctl" -a ~/.pull-secret
$ oc image extract $CCO_IMAGE --file="/usr/bin/ccoctl" -a ~/.pull-secret
次のコマンドを実行して、権限を変更して
ccoctl
を実行可能にします。Copy to Clipboard Copied! Toggle word wrap Toggle overflow chmod 775 ccoctl
$ chmod 775 ccoctl
検証
ccoctl
が使用できることを確認するには、help ファイルを表示します。コマンドを実行するときは、相対ファイル名を使用します。以下に例を示します。Copy to Clipboard Copied! Toggle word wrap Toggle overflow ./ccoctl.rhel9
$ ./ccoctl.rhel9
出力例
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 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.
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.7.8.2.2. Cloud Credential Operator ユーティリティーを使用した AWS リソースの作成
AWS リソースを作成するときは、次のオプションがあります。
-
ccoctl aws create-all
コマンドを使用して AWS リソースを自動的に作成できます。これはリソースを作成する最も簡単な方法です。単一コマンドでの AWS リソースの作成 を参照してください。 -
AWS リソースの変更前に
ccoctl
ツールが作成する JSON ファイルを確認する必要がある場合や、ccoctl
ツールが AWS リソースを自動作成するために使用するプロセスが組織の要件を満たさない場合は、AWS リソースを個別に作成できます。AWS リソースの個別の作成 を参照してください。
4.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
変数に設定します。Copy to Clipboard Copied! Toggle word wrap Toggle overflow RELEASE_IMAGE=$(./openshift-install version | awk '/release image/ {print $3}')
$ RELEASE_IMAGE=$(./openshift-install version | awk '/release image/ {print $3}')
以下のコマンドを実行して、OpenShift Container Platform リリースイメージから
CredentialsRequest
オブジェクトのリストを抽出します。Copy to Clipboard Copied! Toggle word wrap Toggle overflow oc adm release extract \ --from=$RELEASE_IMAGE \ --credentials-requests \ --included \ --install-config=<path_to_directory_with_installation_configuration>/install-config.yaml \ --to=<path_to_directory_for_credentials_requests>
$ 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
オブジェクトをすべて処理します。Copy to Clipboard Copied! Toggle word wrap Toggle overflow ccoctl aws create-all \ --name=<name> \ --region=<aws_region> \ --credentials-requests-dir=<path_to_credentials_requests_directory> \ --output-dir=<path_to_ccoctl_output_dir> \ --create-private-s3-bucket
$ 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
ディレクトリーのファイルを一覧表示します。Copy to Clipboard Copied! Toggle word wrap Toggle overflow ls <path_to_ccoctl_output_dir>/manifests
$ ls <path_to_ccoctl_output_dir>/manifests
出力例
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 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
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.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 キーファイルを生成します。
Copy to Clipboard Copied! Toggle word wrap Toggle overflow ccoctl aws create-key-pair
$ ccoctl aws create-key-pair
出力例
Copy 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 installer
serviceaccount-signer.private
およびserviceaccount-signer.public
は、生成されるキーファイルです。このコマンドは、クラスターがインストール時に必要とするプライベートキーを
/<path_to_ccoctl_output_dir>/tls/bound-service-account-signing-key.key
に作成します。次のコマンドを実行して、AWS 上に OpenID Connect ID プロバイダーと S3 バケットを作成します。
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 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.public
3 出力例
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.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
変数に設定します。Copy to Clipboard Copied! Toggle word wrap Toggle overflow RELEASE_IMAGE=$(./openshift-install version | awk '/release image/ {print $3}')
$ RELEASE_IMAGE=$(./openshift-install version | awk '/release image/ {print $3}')
OpenShift Container Platform リリースイメージから
CredentialsRequest
オブジェクトの一覧を抽出します。Copy to Clipboard Copied! Toggle word wrap Toggle overflow oc adm release extract \ --from=$RELEASE_IMAGE \ --credentials-requests \ --included \ --install-config=<path_to_directory_with_installation_configuration>/install-config.yaml \ --to=<path_to_directory_for_credentials_requests>
$ 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
オブジェクトをすべて処理します。Copy to Clipboard Copied! Toggle word wrap Toggle overflow 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.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
ディレクトリーのファイルを一覧表示します。Copy to Clipboard Copied! Toggle word wrap Toggle overflow ls <path_to_ccoctl_output_dir>/manifests
$ ls <path_to_ccoctl_output_dir>/manifests
出力例
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 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
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.7.8.2.3. Cloud Credential Operator ユーティリティーマニフェストの組み込み
個々のコンポーネントに対してクラスターの外部で管理される短期セキュリティー認証情報を実装するには、Cloud Credential Operator ユーティリティー (ccoctl
) が作成したマニフェストファイルを、インストールプログラムの正しいディレクトリーに移動する必要があります。
前提条件
- クラスターをホストするクラウドプラットフォームでアカウントを設定しました。
-
Cloud Credential Operator ユーティリティー (
ccoctl
) が設定されている。 -
ccoctl
ユーティリティーを使用して、クラスターに必要なクラウドプロバイダーリソースを作成している。
手順
install-config.yaml
設定ファイルのcredentialsMode
パラメーターをManual
に設定しなかった場合は、次のように値を変更します。設定ファイルのサンプルスニペット
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 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>
ここで、
<installation_directory>
は、インストールプログラムがファイルを作成するディレクトリーに置き換えます。次のコマンドを実行して、
ccoctl
ユーティリティーが生成したマニフェストを、インストールプログラムが作成したmanifests
ディレクトリーにコピーします。Copy to Clipboard Copied! Toggle word wrap Toggle overflow cp /<path_to_ccoctl_output_dir>/manifests/* ./manifests/
$ cp /<path_to_ccoctl_output_dir>/manifests/* ./manifests/
秘密鍵を含む
tls
ディレクトリーをインストールディレクトリーにコピーします。Copy to Clipboard Copied! Toggle word wrap Toggle overflow cp -a /<path_to_ccoctl_output_dir>/tls .
$ cp -a /<path_to_ccoctl_output_dir>/tls .
4.7.9. クラスターのデプロイ
互換性のあるクラウドプラットフォームに OpenShift Container Platform をインストールできます。
インストールプログラムの create cluster
コマンドは、初期インストール時に 1 回だけ実行できます。
前提条件
- クラスターをホストするクラウドプラットフォームでアカウントを設定しました。
- OpenShift Container Platform インストールプログラムおよびクラスターのプルシークレットがある。
- ホスト上のクラウドプロバイダーアカウントに、クラスターをデプロイするための適切な権限があることが確認されました。アカウントの権限が正しくないと、インストールプロセスが失敗し、不足している権限を示すエラーメッセージが表示されます。
手順
インストールプログラムが含まれるディレクトリーに切り替え、クラスターのデプロイメントを初期化します。
Copy to Clipboard Copied! Toggle word wrap Toggle overflow ./openshift-install create cluster --dir <installation_directory> \ --log-level=info
$ ./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
...
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.7.10. CLI の使用によるクラスターへのログイン
クラスター kubeconfig
ファイルをエクスポートし、デフォルトシステムユーザーとしてクラスターにログインできます。kubeconfig
ファイルには、クライアントを正しいクラスターおよび API サーバーに接続するために CLI で使用されるクラスターに関する情報が含まれます。このファイルはクラスターに固有のファイルであり、OpenShift Container Platform のインストール時に作成されます。
前提条件
- OpenShift Container Platform クラスターをデプロイしていること。
-
oc
CLI をインストールしていること。
手順
kubeadmin
認証情報をエクスポートします。Copy to Clipboard Copied! Toggle word wrap Toggle overflow export KUBECONFIG=<installation_directory>/auth/kubeconfig
$ export KUBECONFIG=<installation_directory>/auth/kubeconfig
1 - 1
<installation_directory>
には、インストールファイルを保存したディレクトリーへのパスを指定します。
エクスポートされた設定を使用して、
oc
コマンドを正常に実行できることを確認します。Copy to Clipboard Copied! Toggle word wrap Toggle overflow oc whoami
$ oc whoami
出力例
Copy to Clipboard Copied! Toggle word wrap Toggle overflow system:admin
system:admin
4.7.11. Web コンソールを使用したクラスターへのログイン
kubeadmin
ユーザーは、OpenShift Container Platform のインストール後はデフォルトで存在します。OpenShift Container Platform Web コンソールを使用し、kubeadmin
ユーザーとしてクラスターにログインできます。
前提条件
- インストールホストにアクセスできる。
- クラスターのインストールを完了しており、すべてのクラスター Operator が利用可能である。
手順
インストールホストで
kubeadmin-password
ファイルからkubeadmin
ユーザーのパスワードを取得します。Copy to Clipboard Copied! Toggle word wrap Toggle overflow cat <installation_directory>/auth/kubeadmin-password
$ cat <installation_directory>/auth/kubeadmin-password
注記または、インストールホストで
<installation_directory>/.openshift_install.log
ログファイルからkubeadmin
パスワードを取得できます。OpenShift Container Platform Web コンソールルートをリスト表示します。
Copy to Clipboard Copied! Toggle word wrap Toggle overflow oc get routes -n openshift-console | grep 'console-openshift'
$ oc get routes -n openshift-console | grep 'console-openshift'
注記または、インストールホストで
<installation_directory>/.openshift_install.log
ログファイルからで OpenShift Container Platform ルートを取得できます。出力例
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 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 None
-
Web ブラウザーで前述のコマンドの出力で詳細に説明されたルートに移動し、
kubeadmin
ユーザーとしてログインします。
関連情報
- OpenShift Container Platform Web コンソールへのアクセスと理解に関する詳細は、Web コンソールへのアクセス を参照してください。
4.7.12. OpenShift Container Platform の Telemetry アクセス
OpenShift Container Platform 4.15 では、クラスターの健全性および正常に実行された更新についてのメトリクスを提供するためにデフォルトで実行される Telemetry サービスにも、インターネットアクセスが必要です。クラスターがインターネットに接続されている場合、Telemetry は自動的に実行され、クラスターは OpenShift Cluster Manager に登録されます。
OpenShift Cluster Manager インベントリーが正常である (Telemetry によって自動的に維持、または OpenShift Cluster Manager を使用して手動で維持) ことを確認した後に、subscription watch を使用 して、アカウントまたはマルチクラスターレベルで OpenShift Container Platform サブスクリプションを追跡します。
関連情報
- Telemetry サービスの詳細は、リモートヘルスモニタリング を参照してください。
4.7.13. 次のステップ
- インストールを検証 します。
- クラスターをカスタマイズ します。
- 必要に応じて、リモートヘルスレポートをオプトアウト できます。
- 必要に応じて、クラウドプロバイダーの認証情報を削除 できます。
- AWS 上の既存の VPC にクラスターをインストールした後、AWS VPC クラスターを AWS Outpost に拡張 できます。
4.8. プライベートクラスターの AWS へのインストール
OpenShift Container Platform バージョン 4.15 では、Amazon Web Services (AWS) 上の既存の VPC にプライベートクラスターをインストールできます。インストールプログラムは、カスタマイズ可能な残りの必要なインフラストラクチャーをプロビジョニングします。インストールをカスタマイズするには、クラスターをインストールする前に、install-config.yaml
ファイルでパラメーターを変更します。
4.8.1. 前提条件
- OpenShift Container Platform のインストールおよび更新 プロセスの詳細を確認した。
- クラスターインストール方法の選択およびそのユーザー向けの準備 を確認した。
クラスターをホストするために AWS アカウントを設定 している。
重要AWS プロファイルがご使用のコンピューターに保存されている場合、マルチファクター認証デバイスを使用中に生成した一時的なセッショントークンを使用することはできません。クラスターは継続的に現行の AWS 認証情報を使用して、クラスターの有効期間全体にわたって AWS リソースを作成するため、有効期間の長い認証情報を使用する必要があります。適切なキーを生成するには、AWS ドキュメントの Managing Access Keys for IAM Users を参照してください。キーは、インストールプログラムの実行時に指定できます。
- ファイアウォールを使用する場合は、クラスターがアクセスを必要とするサイトを許可するようにファイアウォールを設定する必要がある。
4.8.2. プライベートクラスター
外部エンドポイントを公開しないプライベート OpenShift Container Platform クラスターをデプロイすることができます。プライベートクラスターは内部ネットワークからのみアクセスでき、インターネット上では表示されません。
デフォルトで、OpenShift Container Platform はパブリックにアクセス可能な DNS およびエンドポイントを使用できるようにプロビジョニングされます。プライベートクラスターは、クラスターのデプロイ時に DNS、Ingress コントローラー、および API サーバーを private に設定します。つまり、クラスターリソースは内部ネットワークからのみアクセスでき、インターネット上では表示されません。
クラスターにパブリックサブネットがある場合、管理者により作成されたロードバランサーサービスはパブリックにアクセスできる可能性があります。クラスターのセキュリティーを確保するには、これらのサービスに明示的にプライベートアノテーションが付けられていることを確認してください。
プライベートクラスターをデプロイするには、以下を行う必要があります。
- 要件を満たす既存のネットワークを使用します。クラスターリソースはネットワーク上の他のクラスター間で共有される可能性があります。
以下にアクセスできるマシンからデプロイ。
- プロビジョニングするクラウドの API サービス。
- プロビジョニングするネットワーク上のホスト。
- インストールメディアを取得するインターネット。
これらのアクセス要件を満たし、所属する会社のガイドラインに準拠したすべてのマシンを使用することができます。たとえば、このマシンには、クラウドネットワーク上の bastion ホスト、または VPN 経由でネットワークにアクセスできるマシンを使用できます。
4.8.2.1. AWS のプライベートクラスター
Amazon Web Services (AWS) でプライベートクラスターを作成するには、クラスターをホストするために既存のプライベート VPC およびサブネットを指定する必要があります。インストールプログラムは、クラスターが必要とする DNS レコードを解決できる必要もあります。インストールプログラムは、プライベートネットワークからのみアクセスできるように Ingress Operator および API サーバーを設定します。
クラスターには、引き続き AWS API にアクセスするためにインターネットへのアクセスが必要になります。
以下のアイテムは、プライベートクラスターのインストール時に必要ではなく、作成されません。
- パブリックサブネット
- パブリック Ingress をサポートするパブリックロードバランサー
-
クラスターの
baseDomain
に一致するパブリック Route 53 ゾーン
インストールプログラムは、プライベート Route 53 ゾーンを作成するために指定する baseDomain
とクラスターに必要なレコードを使用します。クラスターは、Operator がクラスターのパブリックレコードを作成せず、すべてのクラスターマシンが指定するプライベートサブネットに配置されるように設定されます。
4.8.2.1.1. 制限事項
プライベートクラスターにパブリック機能を追加する機能には制限があります。
- Kubernetes API エンドポイントは、追加のアクションを実行せずにインストールする場合はパブリックにすることができません。これらのアクションには、使用中のアベイラビリティーゾーンごとに VPC でパブリックサブネットやパブリックのロードバランサーを作成することや、6443 のインターネットからのトラフィックを許可するようにコントロールプレーンのセキュリティーグループを設定することなどが含まれます。
-
パブリックのサービスタイプのロードバランサーを使用する場合には、各アベイラビリティーゾーンのパブリックサブネットに
kubernetes.io/cluster/<cluster-infra-id>: shared
のタグを付け、AWS がそれらを使用してパブリックロードバランサーを作成できるようにします。
4.8.3. カスタム VPC の使用について
OpenShift Container Platform 4.15 では、Amazon Web Services (AWS) の既存の Amazon Virtual Private Cloud (VPC) における既存サブネットにクラスターをデプロイできます。OpenShift Container Platform を既存の AWS VPC にデプロイすると、新規アカウントの制限を回避したり、会社のガイドラインによる運用上の制約をより容易に遵守することが可能になる場合があります。VPC を作成するために必要なインフラストラクチャーの作成パーミッションを取得できない場合は、このインストールオプションを使用します。
インストールプログラムは既存のサブネットにある他のコンポーネントを把握できないため、ユーザーの代わりにサブネットの CIDR を選択することはできません。クラスターをインストールするサブネットのネットワークを独自に設定する必要があります。
4.8.3.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 アベイラビリティーゾーンのプライベートサブネットを作成できます。プライベートサブネットを使用できる場合は、それらの適切なルートおよびテーブルを指定する必要があります。 |
4.8.3.2. VPC 検証
指定するサブネットが適切であることを確認するには、インストールプログラムが以下のデータを確認します。
- 指定したサブネットすべてが存在します。
- プライベートサブネットを指定します。
- サブネットの CIDR は指定されたマシン CIDR に属します。
- 各アベイラビリティーゾーンのサブネットを指定します。それぞれのアベイラビリティーゾーンには、複数のパブリックおよびプライベートサブネットがありません。プライベートクラスターを使用する場合、各アベイラビリティーゾーンのプライベートサブネットのみを指定します。それ以外の場合は、各アベイラビリティーゾーンのパブリックサブネットおよびプライベートサブネットを指定します。
- 各プライベートサブネットアベイラビリティーゾーンのパブリックサブネットを指定します。マシンは、プライベートサブネットを指定しないアベイラビリティーゾーンにはプロビジョニングされません。
既存の VPC を使用するクラスターを破棄しても、VPC は削除されません。VPC から OpenShift Container Platform クラスターを削除する場合、kubernetes.io/cluster/.*: shared
タグは、それが使用したサブネットから削除されます。
4.8.3.3. パーミッションの区分
OpenShift Container Platform 4.3 以降、クラスターのデプロイに、インストールプログラムがプロビジョニングするインフラストラクチャークラスターに必要なすべてのパーミッションを必要としなくなりました。この変更は、ある会社で個人がクラウドで他とは異なるリソースを作成できるようにパーミッションが区分された状態に類似するものです。たとえば、インスタンス、バケット、ロードバランサーなどのアプリケーション固有のアイテムを作成することはできますが、VPC、サブネット、または Ingress ルールなどのネットワーク関連のコンポーネントは作成できない可能性があります。
クラスターの作成時に使用する AWS の認証情報には、VPC、およびサブネット、ルーティングテーブル、インターネットゲートウェイ、NAT、VPN などの VPC 内のコアとなるネットワークコンポーネントの作成に必要なネットワークのパーミッションは必要ありません。ELB、セキュリティーグループ、S3 バケットおよびノードなどの、クラスター内でマシンに必要なアプリケーションリソースを作成するパーミッションは依然として必要になります。
4.8.3.4. クラスター間の分離
OpenShift Container Platform を既存のネットワークにデプロイする場合、クラスターサービスの分離の規模は以下の方法で縮小されます。
- 複数の OpenShift Container Platform クラスターを同じ VPC にインストールできます。
- ICMP Ingress はネットワーク全体から許可されます。
- TCP 22 Ingress (SSH) はネットワーク全体に対して許可されます。
- コントロールプレーンの TCP 6443 Ingress (Kubernetes API) はネットワーク全体に対して許可されます。
- コントロールプレーンの TCP 22623 Ingress (MCS) はネットワーク全体に対して許可されます。
4.8.3.5. オプション: AWS セキュリティーグループ
デフォルトでは、インストールプログラムは、セキュリティーグループを作成し、コントロールプレーンとコンピュートマシンに接続します。デフォルトのセキュリティーグループに関連付けられたルールは変更できません。
ただし、既存の VPC に関連付けられている追加の既存の AWS セキュリティーグループをコントロールプレーンとコンピュートマシンに適用できます。カスタムセキュリティーグループを適用すると、これらのマシンの受信トラフィックまたは送信トラフィックを制御する必要がある場合に、組織のセキュリティーニーズを満たすことができます。
インストールプロセスの一環として、クラスターをデプロイする前に install-config.yaml
ファイルを変更してカスタムセキュリティーグループを適用します。
詳細は、「既存の AWS セキュリティーグループのクラスターへの適用」を参照してください。
4.8.4. OpenShift Container Platform のインターネットアクセス
OpenShift Container Platform 4.15 では、クラスターをインストールするためにインターネットアクセスが必要になります。
インターネットへのアクセスは以下を実行するために必要です。
- OpenShift Cluster Manager にアクセスし、インストールプログラムをダウンロードし、サブスクリプション管理を実行します。クラスターにインターネットアクセスがあり、Telemetry を無効にしない場合、そのサービスは有効なサブスクリプションでクラスターを自動的に使用します。
- クラスターのインストールに必要なパッケージを取得するために Quay.io にアクセスします。
- クラスターの更新を実行するために必要なパッケージを取得します。
クラスターでインターネットに直接アクセスできない場合、プロビジョニングする一部のタイプのインフラストラクチャーでネットワークが制限されたインストールを実行できます。このプロセスで、必要なコンテンツをダウンロードし、これを使用してミラーレジストリーにインストールパッケージを設定します。インストールタイプによっては、クラスターのインストール環境でインターネットアクセスが不要となる場合があります。クラスターを更新する前に、ミラーレジストリーのコンテンツを更新します。
4.8.5. クラスターノードの 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 オペレーティングシステムを使用するコンピューターで以下のコマンドを実行します。
Copy to Clipboard Copied! Toggle word wrap Toggle overflow ssh-keygen -t ed25519 -N '' -f <path>/<file_name>
$ 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 キーを表示します。
Copy to Clipboard Copied! Toggle word wrap Toggle overflow cat <path>/<file_name>.pub
$ cat <path>/<file_name>.pub
たとえば、次のコマンドを実行して
~/.ssh/id_ed25519.pub
公開鍵を表示します。Copy to Clipboard Copied! Toggle word wrap Toggle overflow cat ~/.ssh/id_ed25519.pub
$ cat ~/.ssh/id_ed25519.pub
ローカルユーザーの SSH エージェントに SSH 秘密鍵 ID が追加されていない場合は、それを追加します。キーの SSH エージェント管理は、クラスターノードへのパスワードなしの SSH 認証、または
./openshift-install gather
コマンドを使用する場合は必要になります。注記一部のディストリビューションでは、
~/.ssh/id_rsa
および~/.ssh/id_dsa
などのデフォルトの SSH 秘密鍵のアイデンティティーは自動的に管理されます。ssh-agent
プロセスがローカルユーザーに対して実行されていない場合は、バックグラウンドタスクとして開始します。Copy to Clipboard Copied! Toggle word wrap Toggle overflow eval "$(ssh-agent -s)"
$ eval "$(ssh-agent -s)"
出力例
Copy to Clipboard Copied! Toggle word wrap Toggle overflow Agent pid 31874
Agent pid 31874
注記クラスターが FIPS モードにある場合は、FIPS 準拠のアルゴリズムのみを使用して SSH キーを生成します。鍵は RSA または ECDSA のいずれかである必要があります。
SSH プライベートキーを
ssh-agent
に追加します。Copy to Clipboard Copied! Toggle word wrap Toggle overflow ssh-add <path>/<file_name>
$ ssh-add <path>/<file_name>
1 - 1
~/.ssh/id_ed25519
などの、SSH プライベートキーのパスおよびファイル名を指定します。
出力例
Copy to Clipboard Copied! Toggle word wrap Toggle overflow Identity added: /home/<you>/<path>/<file_name> (<computer_name>)
Identity added: /home/<you>/<path>/<file_name> (<computer_name>)
次のステップ
- OpenShift Container Platform をインストールする際に、SSH パブリックキーをインストールプログラムに指定します。
4.8.6. インストールプログラムの取得
OpenShift Container Platform をインストールする前に、インストールに使用しているホストにインストールファイルをダウンロードします。
前提条件
- 500 MB のローカルディスク領域がある Linux または macOS を実行するコンピューターが必要です。
手順
- OpenShift Cluster Manager サイトの インフラストラクチャープロバイダー ページにアクセスします。Red Hat アカウントがある場合は、認証情報を使用してログインします。アカウントがない場合はこれを作成します。
- インフラストラクチャープロバイダーを選択します。
インストールタイプのページに移動し、ホストオペレーティングシステムとアーキテクチャーに対応するインストールプログラムをダウンロードして、インストール設定ファイルを保存するディレクトリーにファイルを配置します。
重要インストールプログラムは、クラスターのインストールに使用するコンピューターにいくつかのファイルを作成します。クラスターのインストール完了後は、インストールプログラムおよびインストールプログラムが作成するファイルを保持する必要があります。ファイルはいずれもクラスターを削除するために必要になります。
重要インストールプログラムで作成されたファイルを削除しても、クラスターがインストール時に失敗した場合でもクラスターは削除されません。クラスターを削除するには、特定のクラウドプロバイダー用の OpenShift Container Platform のアンインストール手順を実行します。
インストールプログラムを展開します。たとえば、Linux オペレーティングシステムを使用するコンピューターで以下のコマンドを実行します。
Copy to Clipboard Copied! Toggle word wrap Toggle overflow tar -xvf openshift-install-linux.tar.gz
$ tar -xvf openshift-install-linux.tar.gz
- Red Hat OpenShift Cluster Manager からインストールプルシークレット をダウンロードします。このプルシークレットを使用し、OpenShift Container Platform コンポーネントのコンテナーイメージを提供する Quay.io など、組み込まれた各種の認証局によって提供されるサービスで認証できます。
4.8.7. インストール設定ファイルの手動作成
クラスターをインストールするには、インストール設定ファイルを手動で作成する必要があります。
前提条件
- ローカルマシンには、インストールプログラムに提供する SSH 公開鍵があります。このキーは、デバッグおよび障害復旧のためにクラスターノードへの SSH 認証に使用されます。
- OpenShift Container Platform インストールプログラムおよびクラスターのプルシークレットを取得しています。
手順
必要なインストールアセットを保存するためのインストールディレクトリーを作成します。
Copy to Clipboard Copied! Toggle word wrap Toggle overflow mkdir <installation_directory>
$ mkdir <installation_directory>
重要ディレクトリーを作成する必要があります。ブートストラップ X.509 証明書などの一部のインストールアセットの有効期限は短く設定されているため、インストールディレクトリーを再利用することができません。別のクラスターインストールの個別のファイルを再利用する必要がある場合は、それらをディレクトリーにコピーすることができます。ただし、インストールアセットのファイル名はリリース間で変更される可能性があります。インストールファイルを以前のバージョンの OpenShift Container Platform からコピーする場合は注意してコピーを行ってください。
提供されるサンプルの
install-config.yaml
ファイルテンプレートをカスタマイズし、これを<installation_directory>
に保存します。注記この設定ファイルの名前を
install-config.yaml
と付ける必要があります。install-config.yaml
ファイルをバックアップし、複数のクラスターをインストールするのに使用できるようにします。重要install-config.yaml
ファイルは、インストールプロセスの次の手順で使用されます。この時点でこれをバックアップする必要があります。
関連情報
4.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 で使用することがサポートされます。
関連情報
4.8.7.2. AWS のテスト済みインスタンスタイプ
以下の Amazon Web Services (AWS) インスタンスタイプは OpenShift Container Platform でテストされています。
AWS インスタンスには、次の表に記載されているマシンタイプを使用してください。表に記載されていないインスタンスタイプを使用する場合は、使用するインスタンスサイズが、「クラスターインストールの最小リソース要件」セクションに記載されている最小リソース要件と一致していることを確認してください。
例4.32 64 ビット x86 アーキテクチャーに基づくマシンタイプ
-
c4.*
-
c5.*
-
c5a.*
-
i3.*
-
m4.*
-
m5.*
-
m5a.*
-
m6a.*
-
m6i.*
-
r4.*
-
r5.*
-
r5a.*
-
r6i.*
-
t3.*
-
t3a.*
4.8.7.3. 64 ビット ARM インフラストラクチャー上の AWS のテスト済みインスタンスタイプ
次の Amazon Web Services (AWS) 64 ビット ARM インスタンスタイプは、OpenShift Container Platform でテストされています。
AWS ARM インスタンスには、次のチャートに含まれるマシンタイプを使用してください。チャートに記載されていないインスタンスタイプを使用する場合は、使用するインスタンスサイズが、「クラスターインストールの最小リソース要件」に記載されている最小リソース要件と一致していることを確認してください。
例4.33 64 ビット ARM アーキテクチャーに基づくマシンタイプ
-
c6g.*
-
c7g.*
-
m6g.*
-
m7g.*
-
r8g.*
4.8.7.4. AWS のカスタマイズされた install-config.yaml ファイルのサンプル
インストール設定ファイル install-config.yaml
をカスタマイズして、OpenShift Container Platform クラスターのプラットフォームに関する詳細を指定するか、必要なパラメーターの値を変更することができます。
このサンプルの YAML ファイルは参照用にのみ提供されます。インストールプログラムを使用して install-config.yaml
ファイルを取得し、これを変更する必要があります。
apiVersion: v1 baseDomain: example.com credentialsMode: Mint controlPlane: hyperthreading: Enabled name: master platform: aws: zones: - us-west-2a - us-west-2b rootVolume: iops: 4000 size: 500 type: io1 metadataService: authentication: Optional type: m6i.xlarge replicas: 3 compute: - hyperthreading: Enabled name: worker platform: aws: rootVolume: iops: 2000 size: 500 type: io1 metadataService: authentication: Optional type: c5.4xlarge zones: - us-west-2c replicas: 3 metadata: name: test-cluster networking: clusterNetwork: - cidr: 10.128.0.0/14 hostPrefix: 23 machineNetwork: - cidr: 10.0.0.0/16 networkType: OVNKubernetes serviceNetwork: - 172.30.0.0/16 platform: aws: region: us-west-2 propagateUserTags: true userTags: adminContact: jdoe costCenter: 7536 subnets: - subnet-1 - subnet-2 - subnet-3 amiID: ami-0c5d3e03c0ab9b19a serviceEndpoints: - name: ec2 url: https://vpce-id.ec2.us-west-2.vpce.amazonaws.com hostedZone: Z3URY6TWQ91KVV fips: false sshKey: ssh-ed25519 AAAA... publish: Internal pullSecret: '{"auths": ...}'
apiVersion: v1
baseDomain: example.com
credentialsMode: Mint
controlPlane:
hyperthreading: Enabled
name: master
platform:
aws:
zones:
- us-west-2a
- us-west-2b
rootVolume:
iops: 4000
size: 500
type: io1
metadataService:
authentication: Optional
type: m6i.xlarge
replicas: 3
compute:
- hyperthreading: Enabled
name: worker
platform:
aws:
rootVolume:
iops: 2000
size: 500
type: io1
metadataService:
authentication: Optional
type: c5.4xlarge
zones:
- us-west-2c
replicas: 3
metadata:
name: test-cluster
networking:
clusterNetwork:
- cidr: 10.128.0.0/14
hostPrefix: 23
machineNetwork:
- cidr: 10.0.0.0/16
networkType: OVNKubernetes
serviceNetwork:
- 172.30.0.0/16
platform:
aws:
region: us-west-2
propagateUserTags: true
userTags:
adminContact: jdoe
costCenter: 7536
subnets:
- subnet-1
- subnet-2
- subnet-3
amiID: ami-0c5d3e03c0ab9b19a
serviceEndpoints:
- name: ec2
url: https://vpce-id.ec2.us-west-2.vpce.amazonaws.com
hostedZone: Z3URY6TWQ91KVV
fips: false
sshKey: ssh-ed25519 AAAA...
publish: Internal
pullSecret: '{"auths": ...}'
- 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 モードの設定の詳細は、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
です。
4.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
ファイルを編集し、プロキシー設定を追加します。以下に例を示します。Copy to Clipboard Copied! Toggle word wrap Toggle overflow apiVersion: v1 baseDomain: my.domain.com proxy: httpProxy: http://<username>:<pswd>@<ip>:<port> httpsProxy: https://<username>:<pswd>@<ip>:<port> noProxy: ec2.<aws_region>.amazonaws.com,elasticloadbalancing.<aws_region>.amazonaws.com,s3.<aws_region>.amazonaws.com additionalTrustBundle: | -----BEGIN CERTIFICATE----- <MY_TRUSTED_CA_CERT> -----END CERTIFICATE----- additionalTrustBundlePolicy: <policy_to_add_additionalTrustBundle>
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
コマンドを使用してデプロイメントを再起動してからデプロイメントを完了します。以下に例を示します。Copy to Clipboard Copied! Toggle word wrap Toggle overflow ./openshift-install wait-for install-complete --log-level debug
$ ./openshift-install wait-for install-complete --log-level debug
- ファイルを保存し、OpenShift Container Platform のインストール時にこれを参照します。
インストールプログラムは、指定の install-config.yaml
ファイルのプロキシー設定を使用する cluster
という名前のクラスター全体のプロキシーを作成します。プロキシー設定が指定されていない場合、cluster
Proxy
オブジェクトが依然として作成されますが、これには spec
がありません。
cluster
という名前の Proxy
オブジェクトのみがサポートされ、追加のプロキシーを作成することはできません。
4.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
- 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:
- subnet-1
- subnet-2
- subnet-3
4.8.8. バイナリーのダウンロードによる OpenShift CLI のインストール
コマンドラインインターフェイスを使用して OpenShift Container Platform と対話するために CLI (oc
) をインストールすることができます。oc
は Linux、Windows、または macOS にインストールできます。
以前のバージョンの oc
をインストールしている場合、これを使用して OpenShift Container Platform 4.15 のすべてのコマンドを実行することはできません。新規バージョンの oc
をダウンロードし、インストールします。
Linux への OpenShift CLI のインストール
以下の手順を使用して、OpenShift CLI (oc
) バイナリーを Linux にインストールできます。
手順
- Red Hat カスタマーポータルの OpenShift Container Platform ダウンロードページ に移動します。
- Product Variant ドロップダウンリストからアーキテクチャーを選択します。
- バージョン ドロップダウンリストから適切なバージョンを選択します。
- OpenShift v4.15 Linux Client エントリーの横にある Download Now をクリックして、ファイルを保存します。
アーカイブを展開します。
Copy to Clipboard Copied! Toggle word wrap Toggle overflow tar xvf <file>
$ tar xvf <file>
oc
バイナリーを、PATH
にあるディレクトリーに配置します。PATH
を確認するには、以下のコマンドを実行します。Copy to Clipboard Copied! Toggle word wrap Toggle overflow echo $PATH
$ echo $PATH
検証
OpenShift CLI のインストール後に、
oc
コマンドを使用して利用できます。Copy to Clipboard Copied! Toggle word wrap Toggle overflow oc <command>
$ oc <command>
Windows への OpenShift CLI のインストール
以下の手順を使用して、OpenShift CLI (oc
) バイナリーを Windows にインストールできます。
手順
- Red Hat カスタマーポータルの OpenShift Container Platform ダウンロードページ に移動します。
- バージョン ドロップダウンリストから適切なバージョンを選択します。
- OpenShift v4.15 Windows Client エントリーの横にある Download Now をクリックして、ファイルを保存します。
- ZIP プログラムでアーカイブを展開します。
oc
バイナリーを、PATH
にあるディレクトリーに移動します。PATH
を確認するには、コマンドプロンプトを開いて以下のコマンドを実行します。Copy to Clipboard Copied! Toggle word wrap Toggle overflow path
C:\> path
検証
OpenShift CLI のインストール後に、
oc
コマンドを使用して利用できます。Copy to Clipboard Copied! Toggle word wrap Toggle overflow oc <command>
C:\> oc <command>
macOS への OpenShift CLI のインストール
以下の手順を使用して、OpenShift CLI (oc
) バイナリーを macOS にインストールできます。
手順
- Red Hat カスタマーポータルの OpenShift Container Platform ダウンロードページ に移動します。
- バージョン ドロップダウンリストから適切なバージョンを選択します。
OpenShift v4.15 macOS Client エントリーの横にある Download Now をクリックして、ファイルを保存します。
注記macOS arm64 の場合は、OpenShift v4.15 macOS arm64 Client エントリーを選択します。
- アーカイブを展開し、解凍します。
oc
バイナリーをパスにあるディレクトリーに移動します。PATH
を確認するには、ターミナルを開き、以下のコマンドを実行します。Copy to Clipboard Copied! Toggle word wrap Toggle overflow echo $PATH
$ echo $PATH
検証
oc
コマンドを使用してインストールを確認します。Copy to Clipboard Copied! Toggle word wrap Toggle overflow oc <command>
$ oc <command>
4.8.9. 管理者レベルのシークレットを kube-system プロジェクトに保存する代替方法
デフォルトでは、管理者のシークレットは kube-system
プロジェクトに保存されます。install-config.yaml
ファイルの credentialsMode
パラメーターを Manual
に設定した場合は、次のいずれかの代替手段を使用する必要があります。
- 長期クラウド認証情報を手動で管理するには、長期認証情報を手動で作成する の手順に従ってください。
- クラスターの外部で管理される短期認証情報を個々のコンポーネントに対して実装するには、短期認証情報を使用するように AWS クラスターを設定する の手順に従ってください。
4.8.9.1. 長期認証情報を手動で作成する
Cloud Credential Operator (CCO) は、クラウドアイデンティティーおよびアクセス管理 (IAM) API に到達できない環境にインストールする前に手動モードに配置できます。管理者はクラスター kube-system
namespace に管理者レベルの認証情報シークレットを保存しないようにします。
手順
install-config.yaml
設定ファイルのcredentialsMode
パラメーターをManual
に設定しなかった場合は、次のように値を変更します。設定ファイルのサンプルスニペット
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 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>
ここで、
<installation_directory>
は、インストールプログラムがファイルを作成するディレクトリーに置き換えます。次のコマンドを実行して、インストールファイルのリリースイメージを
$RELEASE_IMAGE
変数に設定します。Copy to Clipboard Copied! Toggle word wrap Toggle overflow RELEASE_IMAGE=$(./openshift-install version | awk '/release image/ {print $3}')
$ RELEASE_IMAGE=$(./openshift-install version | awk '/release image/ {print $3}')
以下のコマンドを実行して、OpenShift Container Platform リリースイメージから
CredentialsRequest
カスタムリソース (CR) のリストを抽出します。Copy to Clipboard Copied! Toggle word wrap Toggle overflow oc adm release extract \ --from=$RELEASE_IMAGE \ --credentials-requests \ --included \ --install-config=<path_to_directory_with_installation_configuration>/install-config.yaml \ --to=<path_to_directory_for_credentials_requests>
$ 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
オブジェクトCopy to Clipboard Copied! Toggle word wrap Toggle overflow 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: "*" ...
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
オブジェクトのサンプルCopy to Clipboard Copied! Toggle word wrap Toggle overflow 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> ...
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
オブジェクトCopy to Clipboard Copied! Toggle word wrap Toggle overflow 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>
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.8.9.2. 短期認証情報を使用するように AWS クラスターを設定
AWS Security Token Service (STS) を使用するように設定されたクラスターをインストールするには、CCO ユーティリティーを設定し、クラスターに必要な AWS リソースを作成する必要があります。
4.8.9.2.1. Cloud Credential Operator ユーティリティーの設定
Cloud Credential Operator (CCO) が手動モードで動作しているときにクラスターの外部からクラウドクレデンシャルを作成および管理するには、CCO ユーティリティー (ccoctl
) バイナリーを抽出して準備します。
ccoctl
ユーティリティーは、Linux 環境で実行する必要がある Linux バイナリーです。
前提条件
- クラスター管理者のアクセスを持つ OpenShift Container Platform アカウントを使用できる。
-
OpenShift CLI (
oc
) がインストールされている。
ccoctl
ユーティリティー用の AWS アカウントを作成し、次の権限で使用できるようにしました。例4.34 必要な 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.35 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 リリースイメージの変数を設定します。
Copy to Clipboard Copied! Toggle word wrap Toggle overflow RELEASE_IMAGE=$(./openshift-install version | awk '/release image/ {print $3}')
$ RELEASE_IMAGE=$(./openshift-install version | awk '/release image/ {print $3}')
以下のコマンドを実行して、OpenShift Container Platform リリースイメージから CCO コンテナーイメージを取得します。
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 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)
注記$RELEASE_IMAGE
のアーキテクチャーが、ccoctl
ツールを使用する環境のアーキテクチャーと一致していることを確認してください。以下のコマンドを実行して、OpenShift Container Platform リリースイメージ内の CCO コンテナーイメージから
ccoctl
バイナリーを抽出します。Copy to Clipboard Copied! Toggle word wrap Toggle overflow oc image extract $CCO_IMAGE --file="/usr/bin/ccoctl" -a ~/.pull-secret
$ oc image extract $CCO_IMAGE --file="/usr/bin/ccoctl" -a ~/.pull-secret
次のコマンドを実行して、権限を変更して
ccoctl
を実行可能にします。Copy to Clipboard Copied! Toggle word wrap Toggle overflow chmod 775 ccoctl
$ chmod 775 ccoctl
検証
ccoctl
が使用できることを確認するには、help ファイルを表示します。コマンドを実行するときは、相対ファイル名を使用します。以下に例を示します。Copy to Clipboard Copied! Toggle word wrap Toggle overflow ./ccoctl.rhel9
$ ./ccoctl.rhel9
出力例
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 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.
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.8.9.2.2. Cloud Credential Operator ユーティリティーを使用した AWS リソースの作成
AWS リソースを作成するときは、次のオプションがあります。
-
ccoctl aws create-all
コマンドを使用して AWS リソースを自動的に作成できます。これはリソースを作成する最も簡単な方法です。単一コマンドでの AWS リソースの作成 を参照してください。 -
AWS リソースの変更前に
ccoctl
ツールが作成する JSON ファイルを確認する必要がある場合や、ccoctl
ツールが AWS リソースを自動作成するために使用するプロセスが組織の要件を満たさない場合は、AWS リソースを個別に作成できます。AWS リソースの個別の作成 を参照してください。
4.8.9.2.2.1. 単一コマンドでの AWS リソースの作成
ccoctl
ツールが AWS リソースの作成に使用するプロセスが組織の要件を自動的に満たす場合は、ccoctl aws create-all
コマンドを使用して AWS リソースの作成を自動化できます。
それ以外の場合は、AWS リソースを個別に作成できます。詳細は、「AWS リソースの個別の作成」を参照してください。
デフォルトで、ccoctl
はコマンドが実行されるディレクトリーにオブジェクトを作成します。オブジェクトを別のディレクトリーに作成するには、--output-dir
フラグを使用します。この手順では、<path_to_ccoctl_output_dir>
を使用してこの場所を参照します。
前提条件
以下が必要になります。
-
ccoctl
バイナリーを抽出して準備している。
手順
次のコマンドを実行して、インストールファイルのリリースイメージを
$RELEASE_IMAGE
変数に設定します。Copy to Clipboard Copied! Toggle word wrap Toggle overflow RELEASE_IMAGE=$(./openshift-install version | awk '/release image/ {print $3}')
$ RELEASE_IMAGE=$(./openshift-install version | awk '/release image/ {print $3}')
以下のコマンドを実行して、OpenShift Container Platform リリースイメージから
CredentialsRequest
オブジェクトのリストを抽出します。Copy to Clipboard Copied! Toggle word wrap Toggle overflow oc adm release extract \ --from=$RELEASE_IMAGE \ --credentials-requests \ --included \ --install-config=<path_to_directory_with_installation_configuration>/install-config.yaml \ --to=<path_to_directory_for_credentials_requests>
$ 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
オブジェクトをすべて処理します。Copy to Clipboard Copied! Toggle word wrap Toggle overflow ccoctl aws create-all \ --name=<name> \ --region=<aws_region> \ --credentials-requests-dir=<path_to_credentials_requests_directory> \ --output-dir=<path_to_ccoctl_output_dir> \ --create-private-s3-bucket
$ 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
ディレクトリーのファイルを一覧表示します。Copy to Clipboard Copied! Toggle word wrap Toggle overflow ls <path_to_ccoctl_output_dir>/manifests
$ ls <path_to_ccoctl_output_dir>/manifests
出力例
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 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
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.8.9.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 キーファイルを生成します。
Copy to Clipboard Copied! Toggle word wrap Toggle overflow ccoctl aws create-key-pair
$ ccoctl aws create-key-pair
出力例
Copy 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 installer
serviceaccount-signer.private
およびserviceaccount-signer.public
は、生成されるキーファイルです。このコマンドは、クラスターがインストール時に必要とするプライベートキーを
/<path_to_ccoctl_output_dir>/tls/bound-service-account-signing-key.key
に作成します。次のコマンドを実行して、AWS 上に OpenID Connect ID プロバイダーと S3 バケットを作成します。
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 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.public
3 出力例
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.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
変数に設定します。Copy to Clipboard Copied! Toggle word wrap Toggle overflow RELEASE_IMAGE=$(./openshift-install version | awk '/release image/ {print $3}')
$ RELEASE_IMAGE=$(./openshift-install version | awk '/release image/ {print $3}')
OpenShift Container Platform リリースイメージから
CredentialsRequest
オブジェクトの一覧を抽出します。Copy to Clipboard Copied! Toggle word wrap Toggle overflow oc adm release extract \ --from=$RELEASE_IMAGE \ --credentials-requests \ --included \ --install-config=<path_to_directory_with_installation_configuration>/install-config.yaml \ --to=<path_to_directory_for_credentials_requests>
$ 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
オブジェクトをすべて処理します。Copy to Clipboard Copied! Toggle word wrap Toggle overflow 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.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
ディレクトリーのファイルを一覧表示します。Copy to Clipboard Copied! Toggle word wrap Toggle overflow ls <path_to_ccoctl_output_dir>/manifests
$ ls <path_to_ccoctl_output_dir>/manifests
出力例
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 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
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.8.9.2.3. Cloud Credential Operator ユーティリティーマニフェストの組み込み
個々のコンポーネントに対してクラスターの外部で管理される短期セキュリティー認証情報を実装するには、Cloud Credential Operator ユーティリティー (ccoctl
) が作成したマニフェストファイルを、インストールプログラムの正しいディレクトリーに移動する必要があります。
前提条件
- クラスターをホストするクラウドプラットフォームでアカウントを設定しました。
-
Cloud Credential Operator ユーティリティー (
ccoctl
) が設定されている。 -
ccoctl
ユーティリティーを使用して、クラスターに必要なクラウドプロバイダーリソースを作成している。
手順
install-config.yaml
設定ファイルのcredentialsMode
パラメーターをManual
に設定しなかった場合は、次のように値を変更します。設定ファイルのサンプルスニペット
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 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>
ここで、
<installation_directory>
は、インストールプログラムがファイルを作成するディレクトリーに置き換えます。次のコマンドを実行して、
ccoctl
ユーティリティーが生成したマニフェストを、インストールプログラムが作成したmanifests
ディレクトリーにコピーします。Copy to Clipboard Copied! Toggle word wrap Toggle overflow cp /<path_to_ccoctl_output_dir>/manifests/* ./manifests/
$ cp /<path_to_ccoctl_output_dir>/manifests/* ./manifests/
秘密鍵を含む
tls
ディレクトリーをインストールディレクトリーにコピーします。Copy to Clipboard Copied! Toggle word wrap Toggle overflow cp -a /<path_to_ccoctl_output_dir>/tls .
$ cp -a /<path_to_ccoctl_output_dir>/tls .
4.8.10. クラスターのデプロイ
互換性のあるクラウドプラットフォームに OpenShift Container Platform をインストールできます。
インストールプログラムの create cluster
コマンドは、初期インストール時に 1 回だけ実行できます。
前提条件
- クラスターをホストするクラウドプラットフォームでアカウントを設定しました。
- OpenShift Container Platform インストールプログラムおよびクラスターのプルシークレットがある。
- ホスト上のクラウドプロバイダーアカウントに、クラスターをデプロイするための適切な権限があることが確認されました。アカウントの権限が正しくないと、インストールプロセスが失敗し、不足している権限を示すエラーメッセージが表示されます。
手順
インストールプログラムが含まれるディレクトリーに切り替え、クラスターのデプロイメントを初期化します。
Copy to Clipboard Copied! Toggle word wrap Toggle overflow ./openshift-install create cluster --dir <installation_directory> \ --log-level=info
$ ./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
...
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.8.11. CLI の使用によるクラスターへのログイン
クラスター kubeconfig
ファイルをエクスポートし、デフォルトシステムユーザーとしてクラスターにログインできます。kubeconfig
ファイルには、クライアントを正しいクラスターおよび API サーバーに接続するために CLI で使用されるクラスターに関する情報が含まれます。このファイルはクラスターに固有のファイルであり、OpenShift Container Platform のインストール時に作成されます。
前提条件
- OpenShift Container Platform クラスターをデプロイしていること。
-
oc
CLI をインストールしていること。
手順
kubeadmin
認証情報をエクスポートします。Copy to Clipboard Copied! Toggle word wrap Toggle overflow export KUBECONFIG=<installation_directory>/auth/kubeconfig
$ export KUBECONFIG=<installation_directory>/auth/kubeconfig
1 - 1
<installation_directory>
には、インストールファイルを保存したディレクトリーへのパスを指定します。
エクスポートされた設定を使用して、
oc
コマンドを正常に実行できることを確認します。Copy to Clipboard Copied! Toggle word wrap Toggle overflow oc whoami
$ oc whoami
出力例
Copy to Clipboard Copied! Toggle word wrap Toggle overflow system:admin
system:admin
4.8.12. Web コンソールを使用したクラスターへのログイン
kubeadmin
ユーザーは、OpenShift Container Platform のインストール後はデフォルトで存在します。OpenShift Container Platform Web コンソールを使用し、kubeadmin
ユーザーとしてクラスターにログインできます。
前提条件
- インストールホストにアクセスできる。
- クラスターのインストールを完了しており、すべてのクラスター Operator が利用可能である。
手順
インストールホストで
kubeadmin-password
ファイルからkubeadmin
ユーザーのパスワードを取得します。Copy to Clipboard Copied! Toggle word wrap Toggle overflow cat <installation_directory>/auth/kubeadmin-password
$ cat <installation_directory>/auth/kubeadmin-password
注記または、インストールホストで
<installation_directory>/.openshift_install.log
ログファイルからkubeadmin
パスワードを取得できます。OpenShift Container Platform Web コンソールルートをリスト表示します。
Copy to Clipboard Copied! Toggle word wrap Toggle overflow oc get routes -n openshift-console | grep 'console-openshift'
$ oc get routes -n openshift-console | grep 'console-openshift'
注記または、インストールホストで
<installation_directory>/.openshift_install.log
ログファイルからで OpenShift Container Platform ルートを取得できます。出力例
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 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 None
-
Web ブラウザーで前述のコマンドの出力で詳細に説明されたルートに移動し、
kubeadmin
ユーザーとしてログインします。
関連情報
- OpenShift Container Platform Web コンソールへのアクセスと理解に関する詳細は、Web コンソールへのアクセス を参照してください。
4.8.13. OpenShift Container Platform の Telemetry アクセス
OpenShift Container Platform 4.15 では、クラスターの健全性および正常に実行された更新についてのメトリクスを提供するためにデフォルトで実行される Telemetry サービスにも、インターネットアクセスが必要です。クラスターがインターネットに接続されている場合、Telemetry は自動的に実行され、クラスターは OpenShift Cluster Manager に登録されます。
OpenShift Cluster Manager インベントリーが正常である (Telemetry によって自動的に維持、または OpenShift Cluster Manager を使用して手動で維持) ことを確認した後に、subscription watch を使用 して、アカウントまたはマルチクラスターレベルで OpenShift Container Platform サブスクリプションを追跡します。
関連情報
- Telemetry サービスの詳細は、リモートヘルスモニタリング を参照してください。
4.8.14. 次のステップ
- インストールを検証 します。
- クラスターをカスタマイズ します。
- 必要に応じて、リモートヘルスレポートをオプトアウト できます。
- 必要に応じて、クラウドプロバイダーの認証情報を削除 できます。
4.9. AWS の government リージョンへのクラスターのインストール
OpenShift Container Platform バージョン 4.15 では、Amazon Web Services (AWS) 上のクラスターを government リージョンにインストールできます。リージョンを設定するには、クラスターをインストールする前に、install-config.yaml
ファイルでパラメーターを変更します。
4.9.1. 前提条件
- OpenShift Container Platform のインストールおよび更新 プロセスの詳細を確認した。
- クラスターインストール方法の選択およびそのユーザー向けの準備 を確認した。
クラスターをホストするために AWS アカウントを設定 している。
重要AWS プロファイルがご使用のコンピューターに保存されている場合、マルチファクター認証デバイスを使用中に生成した一時的なセッショントークンを使用することはできません。クラスターは継続的に現行の AWS 認証情報を使用して、クラスターの有効期間全体にわたって AWS リソースを作成するため、有効期間の長い認証情報を使用する必要があります。適切なキーを生成するには、AWS ドキュメントの Managing Access Keys for IAM Users を参照してください。キーは、インストールプログラムの実行時に指定できます。
- ファイアウォールを使用する場合は、クラスターがアクセスを必要とするサイトを許可するようにファイアウォールを設定する必要がある。
4.9.2. AWS government リージョン
OpenShift Container Platform は、AWS GovCloud (US) リージョンへのクラスターのデプロイをサポートします。
以下の AWS GovCloud パーティションがサポートされます。
-
us-gov-east-1
-
us-gov-west-1
4.9.3. インストール要件
クラスターをインストールする前に、以下を行う必要があります。
クラスターをホストするために、既存のプライベート AWS VPC とサブネットを提供します。
パブリックゾーンは、AWS GovCloud の Route 53 ではサポートされません。その結果、AWS government リージョンにデプロイする場合、クラスターはプライベートである必要があります。
-
インストール設定ファイル (
install-config.yaml
) を手動で作成します。
4.9.4. プライベートクラスター
外部エンドポイントを公開しないプライベート OpenShift Container Platform クラスターをデプロイすることができます。プライベートクラスターは内部ネットワークからのみアクセスでき、インターネット上では表示されません。
パブリックゾーンは、AWS GovCloud リージョンの Route 53 ではサポートされていません。したがって、クラスターを AWS GovCloud リージョンにデプロイする場合は、クラスターをプライベートにする必要があります。
デフォルトで、OpenShift Container Platform はパブリックにアクセス可能な DNS およびエンドポイントを使用できるようにプロビジョニングされます。プライベートクラスターは、クラスターのデプロイ時に DNS、Ingress コントローラー、および API サーバーを private に設定します。つまり、クラスターリソースは内部ネットワークからのみアクセスでき、インターネット上では表示されません。
クラスターにパブリックサブネットがある場合、管理者により作成されたロードバランサーサービスはパブリックにアクセスできる可能性があります。クラスターのセキュリティーを確保するには、これらのサービスに明示的にプライベートアノテーションが付けられていることを確認してください。
プライベートクラスターをデプロイするには、以下を行う必要があります。
- 要件を満たす既存のネットワークを使用します。クラスターリソースはネットワーク上の他のクラスター間で共有される可能性があります。
以下にアクセスできるマシンからデプロイ。
- プロビジョニングするクラウドの API サービス。
- プロビジョニングするネットワーク上のホスト。
- インストールメディアを取得するインターネット。
これらのアクセス要件を満たし、所属する会社のガイドラインに準拠したすべてのマシンを使用することができます。たとえば、このマシンには、クラウドネットワーク上の bastion ホスト、または VPN 経由でネットワークにアクセスできるマシンを使用できます。
4.9.4.1. AWS のプライベートクラスター
Amazon Web Services (AWS) でプライベートクラスターを作成するには、クラスターをホストするために既存のプライベート VPC およびサブネットを指定する必要があります。インストールプログラムは、クラスターが必要とする DNS レコードを解決できる必要もあります。インストールプログラムは、プライベートネットワークからのみアクセスできるように Ingress Operator および API サーバーを設定します。
クラスターには、引き続き AWS API にアクセスするためにインターネットへのアクセスが必要になります。
以下のアイテムは、プライベートクラスターのインストール時に必要ではなく、作成されません。
- パブリックサブネット
- パブリック Ingress をサポートするパブリックロードバランサー
-
クラスターの
baseDomain
に一致するパブリック Route 53 ゾーン
インストールプログラムは、プライベート Route 53 ゾーンを作成するために指定する baseDomain
とクラスターに必要なレコードを使用します。クラスターは、Operator がクラスターのパブリックレコードを作成せず、すべてのクラスターマシンが指定するプライベートサブネットに配置されるように設定されます。
4.9.4.1.1. 制限事項
プライベートクラスターにパブリック機能を追加する機能には制限があります。
- Kubernetes API エンドポイントは、追加のアクションを実行せずにインストールする場合はパブリックにすることができません。これらのアクションには、使用中のアベイラビリティーゾーンごとに VPC でパブリックサブネットやパブリックのロードバランサーを作成することや、6443 のインターネットからのトラフィックを許可するようにコントロールプレーンのセキュリティーグループを設定することなどが含まれます。
-
パブリックのサービスタイプのロードバランサーを使用する場合には、各アベイラビリティーゾーンのパブリックサブネットに
kubernetes.io/cluster/<cluster-infra-id>: shared
のタグを付け、AWS がそれらを使用してパブリックロードバランサーを作成できるようにします。
4.9.5. カスタム VPC の使用について
OpenShift Container Platform 4.15 では、Amazon Web Services (AWS) の既存の Amazon Virtual Private Cloud (VPC) における既存サブネットにクラスターをデプロイできます。OpenShift Container Platform を既存の AWS VPC にデプロイすると、新規アカウントの制限を回避したり、会社のガイドラインによる運用上の制約をより容易に遵守することが可能になる場合があります。VPC を作成するために必要なインフラストラクチャーの作成パーミッションを取得できない場合は、このインストールオプションを使用します。
インストールプログラムは既存のサブネットにある他のコンポーネントを把握できないため、ユーザーの代わりにサブネットの CIDR を選択することはできません。クラスターをインストールするサブネットのネットワークを独自に設定する必要があります。
4.9.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 アベイラビリティーゾーンのプライベートサブネットを作成できます。プライベートサブネットを使用できる場合は、それらの適切なルートおよびテーブルを指定する必要があります。 |
4.9.5.2. VPC 検証
指定するサブネットが適切であることを確認するには、インストールプログラムが以下のデータを確認します。
- 指定したサブネットすべてが存在します。
- プライベートサブネットを指定します。
- サブネットの CIDR は指定されたマシン CIDR に属します。
- 各アベイラビリティーゾーンのサブネットを指定します。それぞれのアベイラビリティーゾーンには、複数のパブリックおよびプライベートサブネットがありません。プライベートクラスターを使用する場合、各アベイラビリティーゾーンのプライベートサブネットのみを指定します。それ以外の場合は、各アベイラビリティーゾーンのパブリックサブネットおよびプライベートサブネットを指定します。
- 各プライベートサブネットアベイラビリティーゾーンのパブリックサブネットを指定します。マシンは、プライベートサブネットを指定しないアベイラビリティーゾーンにはプロビジョニングされません。
既存の VPC を使用するクラスターを破棄しても、VPC は削除されません。VPC から OpenShift Container Platform クラスターを削除する場合、kubernetes.io/cluster/.*: shared
タグは、それが使用したサブネットから削除されます。
4.9.5.3. パーミッションの区分
OpenShift Container Platform 4.3 以降、クラスターのデプロイに、インストールプログラムがプロビジョニングするインフラストラクチャークラスターに必要なすべてのパーミッションを必要としなくなりました。この変更は、ある会社で個人がクラウドで他とは異なるリソースを作成できるようにパーミッションが区分された状態に類似するものです。たとえば、インスタンス、バケット、ロードバランサーなどのアプリケーション固有のアイテムを作成することはできますが、VPC、サブネット、または Ingress ルールなどのネットワーク関連のコンポーネントは作成できない可能性があります。
クラスターの作成時に使用する AWS の認証情報には、VPC、およびサブネット、ルーティングテーブル、インターネットゲートウェイ、NAT、VPN などの VPC 内のコアとなるネットワークコンポーネントの作成に必要なネットワークのパーミッションは必要ありません。ELB、セキュリティーグループ、S3 バケットおよびノードなどの、クラスター内でマシンに必要なアプリケーションリソースを作成するパーミッションは依然として必要になります。
4.9.5.4. クラスター間の分離
OpenShift Container Platform を既存のネットワークにデプロイする場合、クラスターサービスの分離の規模は以下の方法で縮小されます。
- 複数の OpenShift Container Platform クラスターを同じ VPC にインストールできます。
- ICMP Ingress はネットワーク全体から許可されます。
- TCP 22 Ingress (SSH) はネットワーク全体に対して許可されます。
- コントロールプレーンの TCP 6443 Ingress (Kubernetes API) はネットワーク全体に対して許可されます。
- コントロールプレーンの TCP 22623 Ingress (MCS) はネットワーク全体に対して許可されます。
4.9.5.5. オプション: AWS セキュリティーグループ
デフォルトでは、インストールプログラムは、セキュリティーグループを作成し、コントロールプレーンとコンピュートマシンに接続します。デフォルトのセキュリティーグループに関連付けられたルールは変更できません。
ただし、既存の VPC に関連付けられている追加の既存の AWS セキュリティーグループをコントロールプレーンとコンピュートマシンに適用できます。カスタムセキュリティーグループを適用すると、これらのマシンの受信トラフィックまたは送信トラフィックを制御する必要がある場合に、組織のセキュリティーニーズを満たすことができます。
インストールプロセスの一環として、クラスターをデプロイする前に install-config.yaml
ファイルを変更してカスタムセキュリティーグループを適用します。
詳細は、「既存の AWS セキュリティーグループのクラスターへの適用」を参照してください。
4.9.6. OpenShift Container Platform のインターネットアクセス
OpenShift Container Platform 4.15 では、クラスターをインストールするためにインターネットアクセスが必要になります。
インターネットへのアクセスは以下を実行するために必要です。
- OpenShift Cluster Manager にアクセスし、インストールプログラムをダウンロードし、サブスクリプション管理を実行します。クラスターにインターネットアクセスがあり、Telemetry を無効にしない場合、そのサービスは有効なサブスクリプションでクラスターを自動的に使用します。
- クラスターのインストールに必要なパッケージを取得するために Quay.io にアクセスします。
- クラスターの更新を実行するために必要なパッケージを取得します。
クラスターでインターネットに直接アクセスできない場合、プロビジョニングする一部のタイプのインフラストラクチャーでネットワークが制限されたインストールを実行できます。このプロセスで、必要なコンテンツをダウンロードし、これを使用してミラーレジストリーにインストールパッケージを設定します。インストールタイプによっては、クラスターのインストール環境でインターネットアクセスが不要となる場合があります。クラスターを更新する前に、ミラーレジストリーのコンテンツを更新します。
4.9.7. クラスターノードの 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 オペレーティングシステムを使用するコンピューターで以下のコマンドを実行します。
Copy to Clipboard Copied! Toggle word wrap Toggle overflow ssh-keygen -t ed25519 -N '' -f <path>/<file_name>
$ 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 キーを表示します。
Copy to Clipboard Copied! Toggle word wrap Toggle overflow cat <path>/<file_name>.pub
$ cat <path>/<file_name>.pub
たとえば、次のコマンドを実行して
~/.ssh/id_ed25519.pub
公開鍵を表示します。Copy to Clipboard Copied! Toggle word wrap Toggle overflow cat ~/.ssh/id_ed25519.pub
$ cat ~/.ssh/id_ed25519.pub
ローカルユーザーの SSH エージェントに SSH 秘密鍵 ID が追加されていない場合は、それを追加します。キーの SSH エージェント管理は、クラスターノードへのパスワードなしの SSH 認証、または
./openshift-install gather
コマンドを使用する場合は必要になります。注記一部のディストリビューションでは、
~/.ssh/id_rsa
および~/.ssh/id_dsa
などのデフォルトの SSH 秘密鍵のアイデンティティーは自動的に管理されます。ssh-agent
プロセスがローカルユーザーに対して実行されていない場合は、バックグラウンドタスクとして開始します。Copy to Clipboard Copied! Toggle word wrap Toggle overflow eval "$(ssh-agent -s)"
$ eval "$(ssh-agent -s)"
出力例
Copy to Clipboard Copied! Toggle word wrap Toggle overflow Agent pid 31874
Agent pid 31874
注記クラスターが FIPS モードにある場合は、FIPS 準拠のアルゴリズムのみを使用して SSH キーを生成します。鍵は RSA または ECDSA のいずれかである必要があります。
SSH プライベートキーを
ssh-agent
に追加します。Copy to Clipboard Copied! Toggle word wrap Toggle overflow ssh-add <path>/<file_name>
$ ssh-add <path>/<file_name>
1 - 1
~/.ssh/id_ed25519
などの、SSH プライベートキーのパスおよびファイル名を指定します。
出力例
Copy to Clipboard Copied! Toggle word wrap Toggle overflow Identity added: /home/<you>/<path>/<file_name> (<computer_name>)
Identity added: /home/<you>/<path>/<file_name> (<computer_name>)
次のステップ
- OpenShift Container Platform をインストールする際に、SSH パブリックキーをインストールプログラムに指定します。
4.9.8. 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
ファイルのサンプルCopy to Clipboard Copied! Toggle word wrap Toggle overflow apiVersion: v1 baseDomain: example.com compute: - hyperthreading: Enabled name: worker platform: aws: amiID: ami-06c4d345f7c207239 type: m5.4xlarge replicas: 3 metadata: name: test-cluster platform: aws: region: us-east-2 sshKey: ssh-ed25519 AAAA... pullSecret: '{"auths": ...}'
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": ...}'
4.9.9. インストールプログラムの取得
OpenShift Container Platform をインストールする前に、インストールに使用しているホストにインストールファイルをダウンロードします。
前提条件
- 500 MB のローカルディスク領域がある Linux または macOS を実行するコンピューターが必要です。
手順
- OpenShift Cluster Manager サイトの インフラストラクチャープロバイダー ページにアクセスします。Red Hat アカウントがある場合は、認証情報を使用してログインします。アカウントがない場合はこれを作成します。
- インフラストラクチャープロバイダーを選択します。
インストールタイプのページに移動し、ホストオペレーティングシステムとアーキテクチャーに対応するインストールプログラムをダウンロードして、インストール設定ファイルを保存するディレクトリーにファイルを配置します。
重要インストールプログラムは、クラスターのインストールに使用するコンピューターにいくつかのファイルを作成します。クラスターのインストール完了後は、インストールプログラムおよびインストールプログラムが作成するファイルを保持する必要があります。ファイルはいずれもクラスターを削除するために必要になります。
重要インストールプログラムで作成されたファイルを削除しても、クラスターがインストール時に失敗した場合でもクラスターは削除されません。クラスターを削除するには、特定のクラウドプロバイダー用の OpenShift Container Platform のアンインストール手順を実行します。
インストールプログラムを展開します。たとえば、Linux オペレーティングシステムを使用するコンピューターで以下のコマンドを実行します。
Copy to Clipboard Copied! Toggle word wrap Toggle overflow tar -xvf openshift-install-linux.tar.gz
$ tar -xvf openshift-install-linux.tar.gz
- Red Hat OpenShift Cluster Manager からインストールプルシークレット をダウンロードします。このプルシークレットを使用し、OpenShift Container Platform コンポーネントのコンテナーイメージを提供する Quay.io など、組み込まれた各種の認証局によって提供されるサービスで認証できます。
4.9.10. インストール設定ファイルの手動作成
クラスターをインストールするには、インストール設定ファイルを手動で作成する必要があります。
前提条件
- ローカルマシンには、インストールプログラムに提供する SSH 公開鍵があります。このキーは、デバッグおよび障害復旧のためにクラスターノードへの SSH 認証に使用されます。
- OpenShift Container Platform インストールプログラムおよびクラスターのプルシークレットを取得しています。
手順
必要なインストールアセットを保存するためのインストールディレクトリーを作成します。
Copy to Clipboard Copied! Toggle word wrap Toggle overflow mkdir <installation_directory>
$ mkdir <installation_directory>
重要ディレクトリーを作成する必要があります。ブートストラップ X.509 証明書などの一部のインストールアセットの有効期限は短く設定されているため、インストールディレクトリーを再利用することができません。別のクラスターインストールの個別のファイルを再利用する必要がある場合は、それらをディレクトリーにコピーすることができます。ただし、インストールアセットのファイル名はリリース間で変更される可能性があります。インストールファイルを以前のバージョンの OpenShift Container Platform からコピーする場合は注意してコピーを行ってください。
提供されるサンプルの
install-config.yaml
ファイルテンプレートをカスタマイズし、これを<installation_directory>
に保存します。注記この設定ファイルの名前を
install-config.yaml
と付ける必要があります。install-config.yaml
ファイルをバックアップし、複数のクラスターをインストールするのに使用できるようにします。重要install-config.yaml
ファイルは、インストールプロセスの次の手順で使用されます。この時点でこれをバックアップする必要があります。
関連情報
4.9.10.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 で使用することがサポートされます。
関連情報
4.9.10.2. AWS のテスト済みインスタンスタイプ
以下の Amazon Web Services (AWS) インスタンスタイプは OpenShift Container Platform でテストされています。
AWS インスタンスには、次の表に記載されているマシンタイプを使用してください。表に記載されていないインスタンスタイプを使用する場合は、使用するインスタンスサイズが、「クラスターインストールの最小リソース要件」セクションに記載されている最小リソース要件と一致していることを確認してください。
例4.36 64 ビット x86 アーキテクチャーに基づくマシンタイプ
-
c4.*
-
c5.*
-
c5a.*
-
i3.*
-
m4.*
-
m5.*
-
m5a.*
-
m6a.*
-
m6i.*
-
r4.*
-
r5.*
-
r5a.*
-
r6i.*
-
t3.*
-
t3a.*
4.9.10.3. 64 ビット ARM インフラストラクチャー上の AWS のテスト済みインスタンスタイプ
次の Amazon Web Services (AWS) 64 ビット ARM インスタンスタイプは、OpenShift Container Platform でテストされています。
AWS ARM インスタンスには、次のチャートに含まれるマシンタイプを使用してください。チャートに記載されていないインスタンスタイプを使用する場合は、使用するインスタンスサイズが、「クラスターインストールの最小リソース要件」に記載されている最小リソース要件と一致していることを確認してください。
例4.37 64 ビット ARM アーキテクチャーに基づくマシンタイプ
-
c6g.*
-
c7g.*
-
m6g.*
-
m7g.*
-
r8g.*
4.9.10.4. AWS のカスタマイズされた install-config.yaml ファイルのサンプル
インストール設定ファイル install-config.yaml
をカスタマイズして、OpenShift Container Platform クラスターのプラットフォームに関する詳細を指定するか、必要なパラメーターの値を変更することができます。
このサンプルの YAML ファイルは参照用にのみ提供されます。これを使用して、手動で作成したインストール設定ファイルにパラメーター値を入力します。
apiVersion: v1 baseDomain: example.com credentialsMode: Mint controlPlane: hyperthreading: Enabled name: master platform: aws: zones: - us-gov-west-1a - us-gov-west-1b rootVolume: iops: 4000 size: 500 type: io1 metadataService: authentication: Optional type: m6i.xlarge replicas: 3 compute: - hyperthreading: Enabled name: worker platform: aws: rootVolume: iops: 2000 size: 500 type: io1 metadataService: authentication: Optional type: c5.4xlarge zones: - us-gov-west-1c replicas: 3 metadata: name: test-cluster networking: clusterNetwork: - cidr: 10.128.0.0/14 hostPrefix: 23 machineNetwork: - cidr: 10.0.0.0/16 networkType: OVNKubernetes serviceNetwork: - 172.30.0.0/16 platform: aws: region: us-gov-west-1 propagateUserTags: true userTags: adminContact: jdoe costCenter: 7536 subnets: - subnet-1 - subnet-2 - subnet-3 amiID: ami-0c5d3e03c0ab9b19a serviceEndpoints: - name: ec2 url: https://vpce-id.ec2.us-west-2.vpce.amazonaws.com hostedZone: Z3URY6TWQ91KVV fips: false sshKey: ssh-ed25519 AAAA... publish: Internal pullSecret: '{"auths": ...}'
apiVersion: v1
baseDomain: example.com
credentialsMode: Mint
controlPlane:
hyperthreading: Enabled
name: master
platform:
aws:
zones:
- us-gov-west-1a
- us-gov-west-1b
rootVolume:
iops: 4000
size: 500
type: io1
metadataService:
authentication: Optional
type: m6i.xlarge
replicas: 3
compute:
- hyperthreading: Enabled
name: worker
platform:
aws:
rootVolume:
iops: 2000
size: 500
type: io1
metadataService:
authentication: Optional
type: c5.4xlarge
zones:
- us-gov-west-1c
replicas: 3
metadata:
name: test-cluster
networking:
clusterNetwork:
- cidr: 10.128.0.0/14
hostPrefix: 23
machineNetwork:
- cidr: 10.0.0.0/16
networkType: OVNKubernetes
serviceNetwork:
- 172.30.0.0/16
platform:
aws:
region: us-gov-west-1
propagateUserTags: true
userTags:
adminContact: jdoe
costCenter: 7536
subnets:
- subnet-1
- subnet-2
- subnet-3
amiID: ami-0c5d3e03c0ab9b19a
serviceEndpoints:
- name: ec2
url: https://vpce-id.ec2.us-west-2.vpce.amazonaws.com
hostedZone: Z3URY6TWQ91KVV
fips: false
sshKey: ssh-ed25519 AAAA...
publish: Internal
pullSecret: '{"auths": ...}'