インストール


OpenShift Container Platform 4.15

OpenShift Container Platform クラスターのインストールおよび設定

Red Hat OpenShift Documentation Team

概要

このドキュメントでは、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 インストールのターゲットおよび依存関係

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 設定ファイルを使用することにより、インストール中に証明書の更新が実行された場合のインストールの失敗を回避できます。

クラスターのブートストラップには、以下のステップが関係します。

  1. ブートストラップマシンが起動し、コントロールプレーンマシンの起動に必要なリモートリソースのホスティングを開始します。インフラストラクチャーをプロビジョニングする場合、この手順では人的介入が必要になります。
  2. ブートストラップマシンは、単一ノードの etcd クラスターと一時的な Kubernetes コントロールプレーンを起動します。
  3. コントロールプレーンマシンは、ブートストラップマシンからリモートリソースをフェッチし、起動を終了します。インフラストラクチャーをプロビジョニングする場合、この手順では人的介入が必要になります。
  4. 一時的なコントロールプレーンは、実稼働コントロールプレーンマシンに対して実稼働コントロールプレーンをスケジュールします。
  5. Cluster Version Operator (CVO) はオンラインになり、etcd Operator をインストールします。etcd Operator はすべてのコントロールプレーンノードで etcd をスケールアップします。
  6. 一時的なコントロールプレーンはシャットダウンし、コントロールを実稼働コントロールプレーンに渡します。
  7. ブートストラップマシンは OpenShift Container Platform コンポーネントを実稼働コントロールプレーンに挿入します。
  8. インストールプログラムはブートストラップマシンをシャットダウンします。インフラストラクチャーをプロビジョニングする場合、この手順では人的介入が必要になります。
  9. コントロールプレーンはコンピュートノードを設定します。
  10. コントロールプレーンは一連の Operator の形式で追加のサービスをインストールします。

このブートストラッププロセスの結果として、OpenShift Container Platform クラスターが実行されます。次に、クラスターはサポートされる環境でのコンピュートマシンの作成など、日常の操作に必要な残りのコンポーネントをダウンロードし、設定します。

1.1.1.5. インストール後のノード状態の確認

以下のインストールヘルスチェックが正常に行われると、OpenShift Container Platform のインストールが完了します。

  • プロビジョナーは、OpenShift Container Platform Web コンソールにアクセスできます。
  • すべてのコントロールプレーンノードが準備状態にある。
  • すべてのクラスター Operator が利用可能です。
注記

インストールが完了すると、ワーカーノードを実行する特定のクラスター Operator が継続的にすべてのワーカーノードのプロビジョニングを試みます。すべてのワーカーノードが READY と報告されるまで、多少時間がかかります。ベアメタルへのインストールの場合、ワーカーノードのトラブルシューティングを行う前に、少なくとも 60 分間待機してください。他のすべてのプラットフォームへのインストールの場合は、ワーカーノードのトラブルシューティングを行う前に、少なくとも 40 分間待機してください。ワーカーノードを実行するクラスター Operator の DEGRADED 状態は、ノードの状態ではなく、Operator 自体のリソースに依存します。

インストールが完了したら、引き続きクラスター内におけるノードの状態を監視できます。

前提条件

  • インストールプログラムはターミナルで正常に解決されます。

手順

  1. すべてのワーカーノードのステータスを表示します。

    Copy to Clipboard Toggle word wrap
    $ oc get nodes

    出力例

    Copy to Clipboard Toggle word wrap
    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

  2. すべてのワーカーマシンノードのフェーズを表示します。

    Copy to Clipboard Toggle word wrap
    $ oc get machines -A

    出力例

    Copy to Clipboard Toggle word wrap
    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 インストールプログラムのスコープは意図的に狭められています。単純さを確保し、確実にインストールを実行できるように設計されているためです。インストールが完了した後に数多くの設定タスクを実行することができます。

関連情報

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 のページには、各種プラットフォームの統合テストの詳細が記載されています。

関連情報

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 CloudAWSAzureAzure Stack HubGCP、または Nutanix へのカスタマイズを指定することなく、インストーラーでプロビジョニングされたインフラストラクチャークラスターをデプロイできます。

インストーラーでプロビジョニングされたインフラストラクチャークラスターの基本設定 (クラスターマシンのインスタンスタイプなど) を実行する必要がある場合は、Alibaba CloudAWSAzureGCP、または Nutanix のインストールをカスタマイズできます。

インストーラーでプロビジョニングされるインフラストラクチャーのインストールの場合、AWS の既存の VPCAzure の vNet、または GCP の VPC を使用できます。ネットワークインフラストラクチャーの一部を再利用して、AWSAzure、または 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 のインストールを実行できます。これらのインストールでは、インストールプロセス時にクラスターに必要なマシンを手動でデプロイします。AWSAzure、および Azure Stack Hub で user-provisioned infrastructure を実行する場合、提供されるテンプレートを使用して必要なすべてのコンポーネントを起動できます。共有 VPC on GCP を再利用することもできます。それ以外の場合は、プロバイダーに依存しない インストール方法を使用して、クラスターを他のクラウドにデプロイすることができます。

user-provisioned infrastructure は、既存のハードウェアで実行することもできます。RHOSPIBM Z® または IBM® LinuxONERHEL KVM が搭載された IBM Z® および IBM® LinuxONEIBM Power、または vSphere を使用する場合は、特定のインストール手順に従ってクラスターをデプロイします。サポートされる他のハードウェアを使用する場合は、ベアメタルのインストール 手順に従います。vSphereベアメタル などの一部のプラットフラォームの場合は、インストール時に追加のネットワークパラメーターをカスタマイズすることもできます。

1.2.1.4. クラスターに追加のセキュリティーが必要ですか ?

user-provisioned installation 方法を使用する場合、クラスターのプロキシーを設定できます。この手順は各インストール手順に含まれています。

パブリッククラウドのクラスターがエンドポイントを外部に公開するのを防ぐ必要がある場合、AWSAzure、または GCP の installer-provisioned infrastructure を使用してプライベートクラスターをデプロイすることができます。

非接続のクラスターまたはネットワークが制限されたクラスターなど、インターネットへのアクセスが限定されたクラスターをインストールする必要がある場合、インストールパッケージをミラーリング し、そこからクラスターをインストールできます。user-provisioned infrastructure によるインストールの詳細な手順を実行して、AWSGCPIBM Z® または IBM® LinuxONERHEL KVM が搭載された IBM Z® または IBM® LinuxONEIBM Power®vSphere、または ベアメタル のネットワークが制限された環境にインストールしてください。ネットワークが制限された環境へのクラスターのインストールは、installer-provisioned infrastructure を使用して、AWSGCPIBM Cloud®NutanixRHOSP、および 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. 各種プラットフォームのサポートされているインストール方法

各種のプラットフォームで各種のインストールを実行できます。

注記

以下の表にあるように、すべてのプラットフォームですべてのインストールオプションがサポートされている訳ではありません。チェックマークは、オプションがサポートされていることを示し、関連するセクションにリンクしています。

表1.1 インストーラーでプロビジョニングされるインフラストラクチャーのオプション
 AlibabaAWS (64 ビット x86)AWS (64 ビット ARM)Azure (64 ビット x86)Azure (64 ビット ARM)Azure Stack HubGCP (64-bit x86)GCP (64 ビット ARM)NutanixRHOSPベアメタル (64 ビット x86)ベアメタル (64 ビット ARM)vSphereIBM Cloud®IBM Z®IBM Power®IBM Power® Virtual Server

デフォルト

 

   

カスタム

  

  

ネットワークのカスタマイズ

    

   

ネットワークが制限されたインストール

 

 

  

プライベートクラスター

 

 

     

  

既存の仮想プライベートネットワーク

 

 

     

  

government リージョン

 

 

             

秘密の地域

 

               

China リージョン

 

               
表1.2 ユーザーによってプロビジョニングされるインフラストラクチャーのオプション
 AlibabaAWS (64 ビット x86)AWS (64 ビット ARM)Azure (64 ビット x86)Azure (64 ビット ARM)Azure Stack HubGCP (64-bit x86)GCP (64 ビット ARM)NutanixRHOSPベアメタル (64 ビット x86)ベアメタル (64 ビット ARM)vSphereIBM 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 ファイルを定期的に更新することも検討してください。

次の設定パラメーターを使用して、クラスター機能を選択できます。

Copy to Clipboard Toggle word wrap
capabilities:
  baselineCapabilitySet: v4.11 
1

  additionalEnabledCapabilities: 
2

  - CSISnapshot
  - Console
  - Storage
1
インストールする機能のベースラインセットを定義します。有効な値は NonevCurrentv4.x です。None を選択すると、すべてのオプション機能が無効になります。デフォルト値は vCurrent で、すべてのオプション機能が有効になります。
注記

v4.x は、現在のクラスターバージョン以前の任意の値を参照します。たとえば、OpenShift Container Platform 4.12 クラスターでの有効値は v4.11v4.12 です。

2
明示的に有効にする機能のリストを定義します。これらの機能は、baselineCapabilitySet で指定された機能に加えて有効になります。
注記

この例では、デフォルトで v4.11 に設定されています。additionalEnabledCapabilities フィールドでは、デフォルトの v4.11 機能セット以外を有効にできます。

次の表では、baselineCapabilitySet の値を説明します。

表1.3 クラスター機能の baselineCapabilitySet 値の説明
説明

vCurrent

新しいリリースで導入される新しいデフォルト機能を自動的に追加する場合、このオプションを指定します。

v4.11

OpenShift Container Platform 4.11 のデフォルト機能を有効にする場合、このオプションを指定します。v4.11 を指定すると、それ以降のバージョンの OpenShift Container Platform で導入された機能が有効になりません。OpenShift Container Platform 4.11 のデフォルト機能は、baremetalMachineAPImarketplace、および openshift-samples です。

v4.12

OpenShift Container Platform 4.12 のデフォルト機能を有効にする場合、このオプションを指定します。v4.12 を指定すると、それ以降のバージョンの OpenShift Container Platform で導入された機能が有効になりません。OpenShift Container Platform 4.12 のデフォルト機能は、baremetalMachineAPImarketplaceopenshift-samplesConsoleInsightsStorage、および CSISnapshot です。

v4.13

OpenShift Container Platform 4.13 のデフォルト機能を有効にする場合、このオプションを指定します。v4.13 を指定すると、それ以降のバージョンの OpenShift Container Platform で導入された機能が有効になりません。OpenShift Container Platform 4.13 のデフォルト機能は、baremetalMachineAPImarketplaceopenshift-samplesConsoleInsightsStorageCSISnapshot、および NodeTuning です。

v4.14

OpenShift Container Platform 4.14 のデフォルト機能を有効にする場合、このオプションを指定します。v4.14 を指定すると、それ以降のバージョンの OpenShift Container Platform で導入された機能が有効になりません。OpenShift Container Platform 4.14 のデフォルト機能は、baremetalMachineAPImarketplaceopenshift-samplesConsoleInsightsStorageCSISnapshotNodeTuningImageRegistryBuild、および DeploymentConfig です。

v4.15

OpenShift Container Platform 4.15 のデフォルト機能を有効にする場合、このオプションを指定します。v4.15 を指定すると、それ以降のバージョンの OpenShift Container Platform で導入された機能が有効になりません。OpenShift Container Platform 4.15 のデフォルト機能は、baremetalMachineAPImarketplaceOperatorLifecycleManageropenshift-samplesConsoleInsightsStorageCSISnapshotNodeTuningImageRegistryBuildCloudCredential、および DeploymentConfig です。

なし

他のセットが大きすぎる場合や、機能が必要ない場合、additionalEnabledCapabilities を介して微調整する場合に指定します。

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-operatorcluster-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 の全体的なリソースフットプリントを削減できます。デプロイメントに応じて、このコンポーネントが必要ない場合は無効にすることができます。

プロジェクト

cluster-image-registry-operator

1.3.3. クラスター機能の表示

クラスター管理者は、clusterversion リソースの状態を使用して機能を表示できます。

前提条件

  • OpenShift CLI (oc) がインストールされている。

手順

  • クラスター機能のステータスを表示するには、次のコマンドを実行します。

    Copy to Clipboard Toggle word wrap
    $ oc get clusterversion version -o jsonpath='{.spec.capabilities}{"\n"}{.status.capabilities}{"\n"}'

    出力例

    Copy to Clipboard Toggle word wrap
    {"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 Toggle word wrap
    $ oc patch clusterversion version --type merge -p '{"spec":{"capabilities":{"baselineCapabilitySet":"vCurrent"}}}' 
    1
    1
    baselineCapabilitySet には、vCurrentv4.15、または None を指定できます。

1.3.5. 追加で有効な機能を設定することによるクラスター機能の有効化

クラスター管理者は、OpenShift Container Platform のインストール後、additionalEnabledCapabilities 設定パラメーターを設定することで、いつでもクラスター機能を有効にできます。

前提条件

  • OpenShift CLI (oc) がインストールされている。

手順

  1. 次のコマンドを実行して、追加の有効な機能を表示します。

    Copy to Clipboard Toggle word wrap
    $ oc get clusterversion version -o jsonpath='{.spec.capabilities.additionalEnabledCapabilities}{"\n"}'

    出力例

    Copy to Clipboard Toggle word wrap
    ["openshift-samples"]

  2. additionalEnabledCapabilities 設定パラメーターを設定するには、次のコマンドを実行します。

    Copy to Clipboard Toggle word wrap
    $ oc patch clusterversion/version --type merge -p '{"spec":{"capabilities":{"additionalEnabledCapabilities":["openshift-samples", "marketplace"]}}}'
重要

クラスターですでに有効になっている機能を無効にすることはできません。クラスターバージョン Operator (CVO) は、クラスターですでに有効になっている機能を調整し続けます。

機能を無効にしようとすると、CVO は異なる仕様を示します。

Copy to Clipboard Toggle word wrap
$ oc get clusterversion version -o jsonpath='{.status.conditions[?(@.type=="ImplicitlyEnabledCapabilities")]}{"\n"}'

出力例

Copy to Clipboard Toggle word wrap
{"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 暗号ライブラリーを呼び出します。

表1.4 OpenShift Container Platform 4.15 における FIPS モード属性と制限
属性制限事項

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 は現在、x86_64ppc64le、および s390x アーキテクチャーを使用する OpenShift Container Platform デプロイメントでのみサポートされています。

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: trueinstall-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 という名前の初期ユーザーが、自動生成されたパスワードを使用して作成されます。すべてのアクセス認証情報は、インストール操作の最後に出力されます。

手順

  1. OpenShift コンソールの ダウンロード ページにある Red Hat OpenShift 導入用のミラーレジストリー の最新バージョンは、mirror-registry.tar.gz パッケージをダウンロードしてください。
  2. mirror-registry ツールを使用して、現在のユーザーアカウントでローカルホストにRed Hat OpenShift 導入用のミラーレジストリー をインストールします。使用可能なフラグの完全なリストは、「Red Hat OpenShift フラグのミラーレジストリー」を参照してください。

    Copy to Clipboard Toggle word wrap
    $ ./mirror-registry install \
      --quayHostname <host_example_com> \
      --quayRoot <example_directory_name>
  3. インストール中に生成されたユーザー名とパスワードを使用して、次のコマンドを実行してレジストリーにログインします。

    Copy to Clipboard Toggle word wrap
    $ 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 にアクセスしてログインすることもできます。

  4. ログイン後、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 Toggle word wrap
    $ 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> でインストールした場合、ミラーレジストリーを適切にアップグレードするには、その文字列を含める必要があります。
  • mirror registry for Red Hat OpenShift を 1.3 → 2.y にアップグレードする場合、1.y デプロイメントでカスタムの quay 設定とストレージディレクトリーを使用していた場合は、--quayRoot フラグと --quayStorage フラグを渡す必要があります。以下に例を示します。

    Copy to Clipboard Toggle word wrap
    $ 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 Toggle word wrap
    $ 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 という名前の初期ユーザーが、自動生成されたパスワードを使用して作成されます。すべてのアクセス認証情報は、インストール操作の最後に出力されます。

手順

  1. OpenShift コンソールの ダウンロード ページにある Red Hat OpenShift 導入用のミラーレジストリー の最新バージョンは、mirror-registry.tar.gz パッケージをダウンロードしてください。
  2. mirror-registry ツールを使用して、現在のユーザーアカウントでローカルホストにRed Hat OpenShift 導入用のミラーレジストリー をインストールします。使用可能なフラグの完全なリストは、「Red Hat OpenShift フラグのミラーレジストリー」を参照してください。

    Copy to Clipboard Toggle word wrap
    $ ./mirror-registry install -v \
      --targetHostname <host_example_com> \
      --targetUsername <example_user> \
      -k ~/.ssh/my_ssh_key \
      --quayHostname <host_example_com> \
      --quayRoot <example_directory_name>
  3. インストール中に生成されたユーザー名とパスワードを使用して、次のコマンドを実行してミラーレジストリーにログインします。

    Copy to Clipboard Toggle word wrap
    $ 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 にアクセスしてログインすることもできます。

  4. ログイン後、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 Toggle word wrap
    $ ./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 Toggle word wrap
    $ ./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 証明書を置き換えるには、次の手順を使用します。

前提条件

手順

  1. 次のコマンドを入力して、Red Hat OpenShift のミラーレジストリー をインストールします。

    Copy to Clipboard Toggle word wrap
    $ ./mirror-registry install \
    --quayHostname <host_example_com> \
    --quayRoot <example_directory_name>

    Red Hat OpenShift のミラーレジストリー$HOME/quay-install ディレクトリーにインストールされます。

  2. 新しい認証局 (CA) バンドルを準備し、新しい ssl.key および ssl.crt キーファイルを生成します。詳細は、Red Hat Quay への接続を保護するための SSL/TLS の使用 を参照してください。
  3. 次のコマンドを入力して、/$HOME/quay-install に環境変数 (QUAY など) を割り当てます。

    Copy to Clipboard Toggle word wrap
    $ export QUAY=/$HOME/quay-install
  4. 次のコマンドを入力して、新しい ssl.crt ファイルを /$HOME/quay-install ディレクトリーにコピーします。

    Copy to Clipboard Toggle word wrap
    $ cp ~/ssl.crt $QUAY/quay-config
  5. 次のコマンドを入力して、新しい ssl.key ファイルを /$HOME/quay-install ディレクトリーにコピーします。

    Copy to Clipboard Toggle word wrap
    $ cp ~/ssl.key $QUAY/quay-config
  6. 次のコマンドを入力して、quay-app アプリケーション Pod を再起動します。

    Copy to Clipboard Toggle word wrap
    $ systemctl restart quay-app

2.2.8. Red Hat OpenShift 導入用のミラーレジストリーのアンインストール

  • 次のコマンドを実行して、ローカルホストから Red Hat OpenShift 導入用のミラーレジストリー をアンインストールできます。

    Copy to Clipboard Toggle word wrap
    $ ./mirror-registry uninstall -v \
      --quayRoot <example_directory_name>
    注記
    • Red Hat OpenShift 導入用のミラーレジストリー を削除しようとと、削除前にユーザーにプロンプトが表示されます。--autoApprove を使用して、このプロンプトをスキップできます。
    • --quayRoot フラグを指定して Red Hat OpenShift 導入用のミラーレジストリー をインストールした場合には、アンインストール時に --quayRoot フラグを含める必要があります。たとえば、Red Hat OpenShift 導入用のミラーレジストリー のインストールで --quayRoot example_directory_name を指定した場合には、この文字列を追加して、ミラーレジストリーを適切にアンインストールする必要があります。

2.2.9. mirror registry for Red Hat OpenShift のフラグ

mirror registry for Red Hat OpenShift では、次のフラグを使用できます。

Flags説明

--autoApprove

対話型プロンプトを無効にするブール値。true に設定すると、ミラーレジストリーをアンインストールするときに quayRoot ディレクトリーが自動的に削除されます。指定しない場合には、デフォルトは false に設定されます。

--initPassword

Quay のインストール中に作成された init ユーザーのパスワード。空白を含まず、8 文字以上にする必要があります。

--initUser string

初期ユーザーのユーザー名を表示します。指定しない場合、デフォルトで init になります。

--no-color, -c

インストール、アンインストール、およびアップグレードコマンドの実行時に、ユーザーがカラーシーケンスを無効にして、それを Ansible に伝播できるようにします。

--quayHostname

クライアントがレジストリーへの接続に使用するミラーレジストリーの完全修飾ドメイン名。Quay config.yamlSERVER_HOSTNAME に相当します。DNS で解決する必要があります。指定しない場合は、デフォルトは <targetHostname>:8443 です。[1]

--quayStorage

Quay 永続ストレージデータが保存されるフォルダー。デフォルトは quay-storage Podman ボリュームです。アンインストールには root 権限が必要です。

--quayRoot, -r

rootCA.keyrootCA.pemrootCA.srl 証明書など、コンテナーイメージレイヤーと設定データが保存されるディレクトリー。指定しない場合、デフォルトは $HOME/quay-install です。

--sqliteStorage

SQLite データベースデータが保存されるフォルダー。指定されていない場合は、デフォルトで sqlite-storage Podman ボリュームになります。アンインストールするには root が必要です。

--ssh-key, -k

SSH ID キーのパス。指定しない場合、デフォルトは ~/.ssh/quay_installer です。

--sslCert

SSL/TLS 公開鍵/証明書へのパス。デフォルトは {quayRoot}/quay-config で、指定しない場合は自動生成されます。

--sslCheckSkip

config.yaml ファイルの SERVER_HOSTNAME に対する証明書のホスト名のチェックをスキップします。[2]

--sslKey

HTTPS 通信に使用される SSL/TLS 秘密鍵へのパス。デフォルトは {quayRoot}/quay-config で、指定しない場合は自動生成されます。

--targetHostname, -H

Quay のインストール先のホスト名。デフォルトは $HOST になります。たとえば、指定していない場合にはローカルホストになります。

--targetUsername, -u

SSH に使用するターゲットホストのユーザー。デフォルトは $USER です。たとえば、指定しない場合は現在のユーザーになります。

--verbose, -v

デバッグログと Ansible Playbook の出力を表示します。

--version

mirror registry for Red Hat OpenShift のバージョンを表示します。

  1. システムのパブリック DNS 名がローカルホスト名と異なる場合は、--quayHostname を変更する必要があります。さらに、--quayHostname フラグは、IP アドレスを使用したインストールをサポートしていません。ホスト名を使用してインストールする必要があります。
  2. --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 がない場合に、ローカルホスト名がデフォルトになることはありませんでした。今回の更新により、quayHostnametargetHostname がない場合は、ローカルホスト名がデフォルトになります。(PROJQUAY-3079)
  • 以前は、コマンド ./mirror-registry --versionunknown 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 Toggle word wrap
    $ sudo systemctl status <service>
  • 標準ユーザーとして Red Hat OpenShift のミラーレジストリー をインストールした場合は、次のコマンドを入力して systemd サービスのステータス情報を取得できます。

    Copy to Clipboard Toggle word wrap
    $ 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 にインストールできます。

手順

  1. Red Hat カスタマーポータルの OpenShift Container Platform ダウンロードページ に移動します。
  2. Product Variant ドロップダウンリストからアーキテクチャーを選択します。
  3. バージョン ドロップダウンリストから適切なバージョンを選択します。
  4. OpenShift v4.15 Linux Client エントリーの横にある Download Now をクリックして、ファイルを保存します。
  5. アーカイブを展開します。

    Copy to Clipboard Toggle word wrap
    $ tar xvf <file>
  6. oc バイナリーを、PATH にあるディレクトリーに配置します。

    PATH を確認するには、以下のコマンドを実行します。

    Copy to Clipboard Toggle word wrap
    $ echo $PATH

検証

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

    Copy to Clipboard Toggle word wrap
    $ oc <command>
Windows への OpenShift CLI のインストール

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

手順

  1. Red Hat カスタマーポータルの OpenShift Container Platform ダウンロードページ に移動します。
  2. バージョン ドロップダウンリストから適切なバージョンを選択します。
  3. OpenShift v4.15 Windows Client エントリーの横にある Download Now をクリックして、ファイルを保存します。
  4. ZIP プログラムでアーカイブを展開します。
  5. oc バイナリーを、PATH にあるディレクトリーに移動します。

    PATH を確認するには、コマンドプロンプトを開いて以下のコマンドを実行します。

    Copy to Clipboard Toggle word wrap
    C:\> path

検証

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

    Copy to Clipboard Toggle word wrap
    C:\> oc <command>
macOS への OpenShift CLI のインストール

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

手順

  1. Red Hat カスタマーポータルの OpenShift Container Platform ダウンロードページ に移動します。
  2. バージョン ドロップダウンリストから適切なバージョンを選択します。
  3. OpenShift v4.15 macOS Client エントリーの横にある Download Now をクリックして、ファイルを保存します。

    注記

    macOS arm64 の場合は、OpenShift v4.15 macOS arm64 Client エントリーを選択します。

  4. アーカイブを展開し、解凍します。
  5. oc バイナリーをパスにあるディレクトリーに移動します。

    PATH を確認するには、ターミナルを開き、以下のコマンドを実行します。

    Copy to Clipboard Toggle word wrap
    $ echo $PATH

検証

  • oc コマンドを使用してインストールを確認します。

    Copy to Clipboard Toggle word wrap
    $ oc <command>

2.3.4. イメージのミラーリングを可能にする認証情報の設定

Red Hat からミラーへのイメージのミラーリングを可能にするコンテナーイメージレジストリーの認証情報ファイルを作成します。

警告

クラスターのインストール時に、このイメージレジストリー認証情報ファイルをプルシークレットとして使用しないでください。クラスターのインストール時にこのファイルを指定すると、クラスター内のすべてのマシンにミラーレジストリーへの書き込みアクセスが付与されます。

警告

このプロセスでは、ミラーレジストリーのコンテナーイメージレジストリーへの書き込みアクセスがあり、認証情報をレジストリープルシークレットに追加する必要があります。

前提条件

  • 非接続環境で使用するミラーレジストリーを設定しました。
  • イメージをミラーリングするミラーレジストリー上のイメージリポジトリーの場所を特定している。
  • イメージのイメージリポジトリーへのアップロードを許可するミラーレジストリーアカウントをプロビジョニングしている。

手順

インストールホストで以下の手順を実行します。

  1. registry.redhat.io プルシークレットを Red Hat OpenShift Cluster Manager からダウンロードします。
  2. JSON 形式でプルシークレットのコピーを作成します。

    Copy to Clipboard Toggle word wrap
    $ cat ./pull-secret | jq . > <path>/<pull_secret_file_in_json> 
    1
    1
    プルシークレットを保存するフォルダーへのパスおよび作成する JSON ファイルの名前を指定します。

    ファイルの内容は以下の例のようになります。

    Copy to Clipboard Toggle word wrap
    {
      "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"
        }
      }
    }
  3. ミラーレジストリーの base64 でエンコードされたユーザー名およびパスワードまたはトークンを生成します。

    Copy to Clipboard Toggle word wrap
    $ echo -n '<user_name>:<password>' | base64 -w0 
    1
    
    BGVtbYk3ZHAtqXs=
    1
    <user_name> および <password> については、レジストリーに設定したユーザー名およびパスワードを指定します。
  4. JSON ファイルを編集し、レジストリーについて記述するセクションをこれに追加します。

    Copy to Clipboard Toggle word wrap
      "auths": {
        "<mirror_registry>": { 
    1
    
          "auth": "<credentials>", 
    2
    
          "email": "you@example.com"
        }
      },
    1
    <mirror_registry> については、レジストリードメイン名と、ミラーレジストリーがコンテンツを提供するために使用するポートをオプションで指定します。例: registry.example.com または registry.example.com:8443
    2
    <credentials> については、ミラーレジストリーの base64 でエンコードされたユーザー名およびパスワードを指定します。

    ファイルは以下の例のようになります。

    Copy to Clipboard Toggle word wrap
    {
      "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 からプルシークレット をダウンロードし、ミラーリポジトリーへの認証を組み込むように変更している。
  • 自己署名証明書を使用する場合は、証明書にサブジェクトの別名を指定しています。

手順

ミラーホストで以下の手順を実行します。

  1. OpenShift Container Platform ダウンロード ページを確認し、インストールする必要のある OpenShift Container Platform のバージョンを判別し、Repository Tags ページで対応するタグを判別します。
  2. 必要な環境変数を設定します。

    1. リリースバージョンをエクスポートします。

      Copy to Clipboard Toggle word wrap
      $ OCP_RELEASE=<release_version>

      <release_version> について、インストールする OpenShift Container Platform のバージョンに対応するタグを指定します (例: 4.5.4)。

    2. ローカルレジストリー名とホストポートをエクスポートします。

      Copy to Clipboard Toggle word wrap
      $ LOCAL_REGISTRY='<local_registry_host_name>:<local_registry_host_port>'

      <local_registry_host_name> については、ミラーレジストリーのレジストリードメイン名を指定し、<local_registry_host_port> については、コンテンツの送信に使用するポートを指定します。

    3. ローカルリポジトリー名をエクスポートします。

      Copy to Clipboard Toggle word wrap
      $ LOCAL_REPOSITORY='<local_repository_name>'

      <local_repository_name> については、ocp4/openshift4 などのレジストリーに作成するリポジトリーの名前を指定します。

    4. ミラーリングするリポジトリーの名前をエクスポートします。

      Copy to Clipboard Toggle word wrap
      $ PRODUCT_REPO='openshift-release-dev'

      実稼働環境のリリースの場合には、openshift-release-dev を指定する必要があります。

    5. パスをレジストリープルシークレットにエクスポートします。

      Copy to Clipboard Toggle word wrap
      $ LOCAL_SECRET_JSON='<path_to_pull_secret>'

      <path_to_pull_secret> については、作成したミラーレジストリーのプルシークレットの絶対パスおよびファイル名を指定します。

    6. リリースミラーをエクスポートします。

      Copy to Clipboard Toggle word wrap
      $ RELEASE_NAME="ocp-release"

      実稼働環境のリリースについては、ocp-release を指定する必要があります。

    7. クラスターのアーキテクチャーのタイプをエクスポートします。

      Copy to Clipboard Toggle word wrap
      $ ARCHITECTURE=<cluster_architecture> 
      1
      1
      x86_64aarch64s390x、または ppc64le など、クラスターのアーキテクチャーを指定します。
    8. ミラーリングされたイメージをホストするためにディレクトリーへのパスをエクスポートします。

      Copy to Clipboard Toggle word wrap
      $ REMOVABLE_MEDIA_PATH=<path> 
      1
      1
      最初のスラッシュ (/) 文字を含む完全パスを指定します。
  3. バージョンイメージをミラーレジストリーにミラーリングします。

    • ミラーホストがインターネットにアクセスできない場合は、以下の操作を実行します。

      1. リムーバブルメディアをインターネットに接続しているシステムに接続します。
      2. ミラーリングするイメージおよび設定マニフェストを確認します。

        Copy to Clipboard Toggle word wrap
        $ 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
      3. 直前のコマンドの出力の imageContentSources セクション全体を記録します。ミラーの情報はミラーリングされたリポジトリーに一意であり、インストール時に imageContentSources セクションを install-config.yaml ファイルに追加する必要があります。
      4. イメージをリムーバブルメディア上のディレクトリーにミラーリングします。

        Copy to Clipboard Toggle word wrap
        $ oc adm release mirror -a ${LOCAL_SECRET_JSON} --to-dir=${REMOVABLE_MEDIA_PATH}/mirror quay.io/${PRODUCT_REPO}/${RELEASE_NAME}:${OCP_RELEASE}-${ARCHITECTURE}
      5. メディアをネットワークが制限された環境に移し、イメージをローカルコンテナーレジストリーにアップロードします。

        Copy to Clipboard Toggle word wrap
        $ 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 を参照してください。

    • ローカルコンテナーレジストリーがミラーホストに接続されている場合は、以下の操作を実行します。

      1. 以下のコマンドを使用して、リリースイメージをローカルレジストリーに直接プッシュします。

        Copy to Clipboard Toggle word wrap
        $ 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 データが含まれます。

      2. 直前のコマンドの出力の imageContentSources セクション全体を記録します。ミラーの情報はミラーリングされたリポジトリーに一意であり、インストール時に imageContentSources セクションを install-config.yaml ファイルに追加する必要があります。

        注記

        ミラーリングプロセス中にイメージ名に Quay.io のパッチが適用され、podman イメージにはブートストラップ仮想マシンのレジストリーに Quay.io が表示されます。

  4. ミラーリングしたコンテンツに基づくインストールプログラムを作成するために、インストールプログラムを展開してリリースに固定します。

    • ミラーホストがインターネットにアクセスできない場合は、以下のコマンドを実行します。

      Copy to Clipboard Toggle word wrap
      $ 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 Toggle word wrap
      $ oc adm release extract -a ${LOCAL_SECRET_JSON} --command=openshift-install "${LOCAL_REGISTRY}/${LOCAL_REPOSITORY}:${OCP_RELEASE}-${ARCHITECTURE}"
      重要

      選択した OpenShift Container Platform のバージョンに適したイメージを確実に使用するために、ミラーリングしたコンテンツからインストールプログラムを展開する必要があります。

      インターネット接続のあるマシンで、このステップを実行する必要があります。

  5. installer-provisioned infrastructure を使用するクラスターの場合は、以下のコマンドを実行します。

    Copy to Clipboard Toggle word wrap
    $ 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 Toggle word wrap
    $ podman login registry.redhat.io
  • Docker v2-2 をサポートするミラーレジストリーへのアクセス。
  • ミラーレジストリーで、ミラーリングされた Operator コンテンツの保存に使用するリポジトリーまたは namespace を決定します。たとえば、olm-mirror リポジトリーを作成できます。
  • ミラーレジストリーにインターネットアクセスがない場合は、ネットワークアクセスが無制限のワークステーションにリムーバブルメディアを接続します。
  • registry.redhat.io などのプライベートレジストリーを使用している場合、後続の手順で使用するために REG_CREDS 環境変数をレジストリー認証情報のファイルパスに設定します。たとえば podman CLI の場合は、以下のようになります。

    Copy to Clipboard Toggle word wrap
    $ REG_CREDS=${XDG_RUNTIME_DIR}/containers/auth.json
2.3.7.2. カタログコンテンツの抽出およびミラーリング

oc adm catalog mirror コマンドは、インデックスイメージのコンテンツを抽出し、ミラーリングに必要なマニフェストを生成します。コマンドのデフォルト動作で、マニフェストを生成し、インデックスイメージからのすべてのイメージコンテンツを、インデックスイメージと同様にミラーレジストリーに対して自動的にミラーリングします。

または、ミラーレジストリーが完全に非接続または エアギャップ環境のホスト上にある場合、最初にコンテンツをリムーバブルメディアにミラーリングし、メディアを非接続環境に移行してから、メディアからレジストリーにコンテンツをレジストリーに対してミラーリングできます。

2.3.7.2.1. 同じネットワーク上のレジストリーへのカタログコンテンツのミラーリング

ミラーレジストリーがネットワークアクセスが無制限のワークステーションと同じネットワーク上に置かれている場合は、ワークステーションで以下のアクションを実行します。

手順

  1. ミラーレジストリーに認証が必要な場合は、以下のコマンドを実行してレジストリーにログインします。

    Copy to Clipboard Toggle word wrap
    $ podman login <mirror_registry>
  2. 以下のコマンドを実行して、コンテンツをミラーレジストリーに対して抽出し、ミラーリングします。

    Copy to Clipboard Toggle word wrap
    $ 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/amd64linux/ppc64lelinux/s390xlinux/arm64 です。
    6
    オプション: 実際にイメージコンテンツをレジストリーにミラーリングせずに、ミラーリングに必要なマニフェストのみを生成します。このオプションは、ミラーリングする内容を確認するのに役立ちます。また、パッケージのサブセットのみが必要な場合に、マッピングのリストに変更を加えることができます。次に、mapping.txt ファイルを oc image mirror コマンドで使用し、後のステップでイメージの変更済みの一覧をミラーリングできます。これは、カタログからのコンテンツの高度な選択可能ミラーリングの実行に使用するためのフラグです。

    出力例

    Copy to Clipboard Toggle word wrap
    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. カタログコンテンツをエアギャップされたレジストリーへのミラーリング

ミラーレジストリーが完全に切断された、またはエアギャップのあるホスト上にある場合は、次のアクションを実行します。

手順

  1. ネットワークアクセスが無制限のワークステーションで以下のコマンドを実行し、コンテンツをローカルファイルにミラーリングします。

    Copy to Clipboard Toggle word wrap
    $ 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/amd64linux/ppc64lelinux/s390xlinux/arm64、および .*です。

    出力例

    Copy to Clipboard Toggle word wrap
    ...
    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

    1
    生成される manifests ディレクトリー名を記録します。このディレクトリーは、後続の手順で参照されます。
    2
    提供されたインデックスイメージをベースとする、拡張された file:// パスを記録します。このパスは、後続のステップで参照されます。

    このコマンドにより、現在のディレクトリーに v2/ ディレクトリーが作成されます。

  2. v2/ ディレクトリーをリムーバブルメディアにコピーします。
  3. メディアを物理的に削除して、これをミラーレジストリーにアクセスできる非接続環境のホストに割り当てます。
  4. ミラーレジストリーに認証が必要な場合は、非接続環境のホストで以下のコマンドを実行し、レジストリーにログインします。

    Copy to Clipboard Toggle word wrap
    $ podman login <mirror_registry>
  5. v2/ ディレクトリーを含む親ディレクトリーから以下のコマンドを実行し、ローカルファイルからミラーレジストリーにイメージをアップロードします。

    Copy to Clipboard Toggle word wrap
    $ 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/amd64linux/ppc64lelinux/s390xlinux/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 のナレッジソリューションを参照してください。

  6. oc adm catalog mirror コマンドを再度実行します。新しくミラー化されたインデックスイメージをソースとして使用し、前の手順で使用したものと同じミラーレジストリーターゲットを使用します。

    Copy to Clipboard Toggle word wrap
    $ 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 ディレクトリーが生成されます。

同じネットワークのレジストリーにコンテンツをミラーリングする場合、ディレクトリー名は以下のパターンになります。

Copy to Clipboard Toggle word wrap
manifests-<index_image_name>-<random_number>

直前のセクションで非接続ホストのレジストリーにコンテンツをミラーリングする場合、ディレクトリー名は以下のパターンになります。

Copy to Clipboard Toggle word wrap
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. 次のステップ

2.3.9. 関連情報

2.4. oc-mirror プラグインを使用した非接続インストールのイメージのミラーリング

プライベートレジストリー内の OpenShift Container Platform コンテナーイメージのミラーリングされたセットからクラスターをインストールすることにより、インターネットに直接接続せずに制限されたネットワークでクラスターを実行することができます。このレジストリーは、クラスターが実行されている限り、常に実行されている必要があります。詳細は、前提条件 セクションを参照してください。

oc-mirror OpenShift CLI (oc) プラグインを使用して、完全なまたは部分的な非接続環境でイメージをミラーレジストリーにミラーリングできます。公式の Red Hat レジストリーから必要なイメージをダウンロードするには、インターネット接続のあるシステムから oc-mirror を実行する必要があります。

次の手順は、oc-mirror プラグインを使用してイメージをミラーレジストリーにミラーリングする方法の概要を示しています。

  1. イメージセット設定ファイルを作成します。
  2. 以下のいずれかの方法を使用して、イメージセットをミラーレジストリーにミラーリングします。

    • イメージセットをミラーレジストリーに直接ミラーリングします。
    • イメージセットをディスクにミラーリングし、イメージセットをターゲット環境に転送してから、イメージセットをターゲットミラーレジストリーにアップロードします。
  3. oc-mirror プラグインが生成したリソースを使用するようにクラスターを設定します。
  4. これらの手順を繰り返して、必要に応じてミラーレジストリーを更新します。

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 カタログのミラーリングをサポートします。

注記

aarch64ppc64le、および 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 バージョンに適したバイナリーをインストールした。

手順

  1. oc-mirror CLI プラグインをダウンロードします。

    1. OpenShift Cluster Managerダウンロード ページに移動します。
    2. OpenShift 切断インストールツール セクションで、OpenShift Client (oc) ミラープラグインダウンロード をクリックしてファイルを保存します。
  2. アーカイブを抽出します。

    Copy to Clipboard Toggle word wrap
    $ tar xvzf oc-mirror.tar.gz
  3. 必要に応じて、プラグインファイルを更新して実行可能にします。

    Copy to Clipboard Toggle word wrap
    $ chmod +x oc-mirror
    注記

    oc-mirror ファイルの名前を変更しないでください。

  4. ファイルを PATH に配置して、oc-mirror CLI プラグインをインストールします (例: /usr/local/bin):。

    Copy to Clipboard Toggle word wrap
    $ sudo mv oc-mirror /usr/local/bin/.

検証

  • oc mirror help を実行して、プラグインが正常にインストールされたことを確認します。

    Copy to Clipboard Toggle word wrap
    $ oc mirror help
2.4.5.2. イメージのミラーリングを可能にする認証情報の設定

Red Hat からミラーへのイメージのミラーリングを可能にするコンテナーイメージレジストリーの認証情報ファイルを作成します。

警告

クラスターのインストール時に、このイメージレジストリー認証情報ファイルをプルシークレットとして使用しないでください。クラスターのインストール時にこのファイルを指定すると、クラスター内のすべてのマシンにミラーレジストリーへの書き込みアクセスが付与されます。

警告

このプロセスでは、ミラーレジストリーのコンテナーイメージレジストリーへの書き込みアクセスがあり、認証情報をレジストリープルシークレットに追加する必要があります。

前提条件

  • 非接続環境で使用するミラーレジストリーを設定しました。
  • イメージをミラーリングするミラーレジストリー上のイメージリポジトリーの場所を特定している。
  • イメージのイメージリポジトリーへのアップロードを許可するミラーレジストリーアカウントをプロビジョニングしている。

手順

インストールホストで以下の手順を実行します。

  1. registry.redhat.io プルシークレットを Red Hat OpenShift Cluster Manager からダウンロードします。
  2. JSON 形式でプルシークレットのコピーを作成します。

    Copy to Clipboard Toggle word wrap
    $ cat ./pull-secret | jq . > <path>/<pull_secret_file_in_json> 
    1
    1
    プルシークレットを保存するフォルダーへのパスおよび作成する JSON ファイルの名前を指定します。

    ファイルの内容は以下の例のようになります。

    Copy to Clipboard Toggle word wrap
    {
      "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"
        }
      }
    }
  3. ファイルを、~/.docker/config.json または $XDG_RUNTIME_DIR/containers/auth.json として保存します。

    1. .docker または $XDG_RUNTIME_DIR/containers ディレクトリーが存在しない場合は、次のコマンドを入力して作成します。

      Copy to Clipboard Toggle word wrap
      $ mkdir -p <directory_name>

      この場合の <directory_name> は、~/.docker または $XDG_RUNTIME_DIR/containers のいずれかです。

    2. 次のコマンドを入力して、プルシークレットを適切なディレクトリーにコピーします。

      Copy to Clipboard Toggle word wrap
      $ cp <path>/<pull_secret_file_in_json> <directory_name>/<auth_file>

      この場合の <directory_name>~/.docker または $XDG_RUNTIME_DIR/containers<auth_file>config.json または auth.json のいずれかです。

  4. ミラーレジストリーの base64 でエンコードされたユーザー名およびパスワードまたはトークンを生成します。

    Copy to Clipboard Toggle word wrap
    $ echo -n '<user_name>:<password>' | base64 -w0 
    1
    
    BGVtbYk3ZHAtqXs=
    1
    <user_name> および <password> については、レジストリーに設定したユーザー名およびパスワードを指定します。
  5. JSON ファイルを編集し、レジストリーについて記述するセクションをこれに追加します。

    Copy to Clipboard Toggle word wrap
      "auths": {
        "<mirror_registry>": { 
    1
    
          "auth": "<credentials>", 
    2
    
          "email": "you@example.com"
        }
      },
    1
    <mirror_registry> については、レジストリードメイン名と、ミラーレジストリーがコンテンツを提供するために使用するポートをオプションで指定します。例: registry.example.com または registry.example.com:8443
    2
    <credentials> については、ミラーレジストリーの base64 でエンコードされたユーザー名およびパスワードを指定します。

    ファイルは以下の例のようになります。

    Copy to Clipboard Toggle word wrap
    {
      "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 プラグインを実行するたびに、同じストレージバックエンドを使用する必要があります。

前提条件

  • コンテナーイメージレジストリーの認証情報ファイルを作成している。手順については、イメージのミラーリングを可能にする認証情報の設定 を参照してください。

手順

  1. oc mirror init コマンドを使用して、イメージセット設定のテンプレートを作成し、それを imageset-config.yaml というファイルに保存します。

    Copy to Clipboard Toggle word wrap
    $ oc mirror init --registry example.com/mirror/oc-mirror-metadata > imageset-config.yaml 
    1
    1
    example.com/mirror/oc-mirror-metadata をストレージバックエンドのレジストリーの場所に置き換えます。
  2. ファイルを編集し、必要に応じて設定を調整します。

    Copy to Clipboard Toggle word wrap
    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 を使用する場合は、ImageSetConfiguration4.15.8 などのバージョンを含める必要がある場合があります。

    oc-mirror プラグイン v1 は常にこれを自動的に検出するわけではない可能性があるため、Cincinnati グラフ Web ページ をチェックして、必要な中間バージョンを確認し、それらを設定に手動で追加します。

    パラメーターの完全なリストについては、イメージセットの設定パラメーター を参照してください。また、さまざまなミラーリングのユースケースについては、イメージセットの設定例 を参照してください。

  3. 更新したファイルを保存します。

    このイメージセット設定ファイルは、コンテンツをミラーリングするときに 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 Toggle word wrap
    $ oc mirror --config=./<imageset-config.yaml> \
    1
    
      docker://registry.example:5000             
    2
    1
    作成したイメージセット設定ファイルを指定します。たとえば、imageset-config.yaml です。
    2
    イメージセットファイルをミラーリングするレジストリーを指定します。レジストリーは docker:// で始まる必要があります。ミラーレジストリーに最上位の namespace を指定する場合は、これ以降の実行でもこれと同じ namespace を使用する必要があります。

検証

  1. 生成された oc-mirror-workspace/ ディレクトリーに移動します。
  2. results ディレクトリーに移動します (例: results-1639608409/
  3. 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 Toggle word wrap
    $ oc mirror --config=./imageset-config.yaml \
    1
    
      file://<path_to_output_directory>          
    2
    1
    作成されたイメージセット設定ファイルを渡します。この手順では、imageset-config.yaml という名前であることを前提としています。
    2
    イメージセットファイルを出力するターゲットディレクトリーを指定します。ターゲットディレクトリーのパスは、file:// で始まる必要があります。

検証

  1. 出力ディレクトリーに移動します。

    Copy to Clipboard Toggle word wrap
    $ cd <path_to_output_directory>
  2. イメージセットの .tar ファイルが作成されたことを確認します。

    Copy to Clipboard Toggle word wrap
    $ ls

    出力例

    Copy to Clipboard Toggle word wrap
    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 Toggle word wrap
    $ 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 リソースを生成します。

検証

  1. 生成された oc-mirror-workspace/ ディレクトリーに移動します。
  2. results ディレクトリーに移動します (例: results-1639608409/
  3. ImageContentSourcePolicy および CatalogSource リソースに YAML ファイルが存在することを確認します。

次のステップ

  • oc-mirror が生成したリソースを使用するようにクラスターを設定します。

トラブルシューティング

2.4.8. oc-mirror が生成したリソースを使用するためのクラスター設定

イメージセットをミラーレジストリーにミラーリングした後に、生成された ImageContentSourcePolicyCatalogSource、およびリリースイメージの署名リソースをクラスターに適用する必要があります。

ImageContentSourcePolicy リソースは、ミラーレジストリーをソースレジストリーに関連付け、イメージプル要求をオンラインレジストリーからミラーレジストリーにリダイレクトします。CatalogSource リソースは、Operator Lifecycle Manager (OLM) によって使用され、ミラーレジストリーで使用可能な Operator に関する情報を取得します。リリースイメージの署名は、ミラーリングされたリリースイメージの検証に使用されます。

前提条件

  • 非接続環境で、イメージセットをレジストリーミラーにミラーリングしました。
  • cluster-admin ロールを持つユーザーとしてクラスターにアクセスできる。

手順

  1. cluster-admin ロールを持つユーザーとして OpenShift CLI にログインします。
  2. 以下のコマンドを実行して、results ディレクトリーからクラスターに YAML ファイルを適用します。

    Copy to Clipboard Toggle word wrap
    $ oc apply -f ./oc-mirror-workspace/results-1639608409/
  3. リリースイメージをミラーリングした場合は、次のコマンドを実行して、リリースイメージの署名をクラスターに適用します。

    Copy to Clipboard Toggle word wrap
    $ oc apply -f ./oc-mirror-workspace/results-1639608409/release-signatures/
    注記

    クラスターではなく Operator をミラーリングしている場合、$ oc apply -f ./oc-mirror-workspace/results-1639608409/release-signatures/ を実行する必要はありません。適用するリリースイメージ署名がないため、このコマンドを実行するとエラーが返されます。

検証

  1. 以下のコマンドを実行して、ImageContentSourcePolicy リソースが正常にインストールされたことを確認します。

    Copy to Clipboard Toggle word wrap
    $ oc get imagecontentsourcepolicy
  2. 以下のコマンドを実行して、CatalogSource リソースが正常にインストールされたことを確認します。

    Copy to Clipboard Toggle word wrap
    $ 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 プラグインによって生成されたメタデータイメージを削除または変更しないでください。

手順

  1. 必要に応じて、イメージセット設定ファイルを更新して、新しい OpenShift Container Platform および Operator バージョンを取得します。ミラーリングの使用例については、イメージセットの設定例 を参照してください。
  2. 初期イメージセットをミラーレジストリーにミラーリングしたときと同じ手順に従います。手順については、部分的な非接続環境でのイメージセットのミラーリング または 完全な非接続環境でのイメージセットのミラーリング を参照してください。

    重要
    • 差分イメージセットのみが作成およびミラーリングされるように、同じストレージバックエンドを提供する必要があります。
    • イメージセットの最初の作成時にミラーレジストリーにトップレベルの namespace を指定した場合は、同じミラーレジストリーに対して oc-mirror プラグインを実行するたびに、この同じ namespace を使用する必要があります。
  3. oc-mirror が生成したリソースを使用するようにクラスターを設定します。

2.4.10. ドライランの実行

実際にイメージをミラーリングせずに、oc-mirror を使用してドライランを実行できます。これにより、ミラーリングされるイメージのリストと、ミラーレジストリーからプルーニングされるイメージを確認できます。ドライランを使用すると、イメージセット設定のエラーを早期に検出したり、生成されたイメージリストを他のツールで使用してミラーリング操作を実行したりすることもできます。

前提条件

  • 必要なコンテナーイメージを取得するためのインターネットへのアクセスがある。
  • OpenShift CLI (oc) がインストールされている。
  • oc-mirror CLI プラグインをインストールしている。
  • イメージセット設定ファイルを作成している。

手順

  1. --dry-run フラグを指定して oc mirror コマンドを実行し、ドライランを実行します。

    Copy to Clipboard Toggle word wrap
    $ oc mirror --config=./imageset-config.yaml \
    1
    
      docker://registry.example:5000            \
    2
    
      --dry-run                                  
    3
    1
    作成されたイメージセット設定ファイルを渡します。この手順では、imageset-config.yaml という名前であることを前提としています。
    2
    ミラーレジストリーを指定します。--dry-run フラグを使用している限り、このレジストリーには何もミラーリングされません。
    3
    --dry-run フラグを使用して、実際のイメージセットファイルではなく、ドライランアーティファクトを生成します。

    出力例

    Copy to Clipboard Toggle word wrap
    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

  2. 生成されたワークスペースディレクトリーに移動します。

    Copy to Clipboard Toggle word wrap
    $ cd oc-mirror-workspace/
  3. 生成された mapping.txt ファイルを確認します。

    このファイルには、ミラーリングされるすべてのイメージのリストが含まれています。

  4. 生成された 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 プラグインをインストールしている。

手順

  1. イメージセット設定ファイルを作成し、必要に応じて設定を調整します。

    次のイメージセット設定例では、OpenShift Container Platform リリースおよび registry.redhat.io の UBI イメージとともに、ディスク上の OCI カタログをミラーリングします。

    Copy to Clipboard Toggle word wrap
    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
    必要に応じて、レジストリーからプルする追加のイメージを指定します。
  2. oc mirror コマンドを実行して、OCI カタログをターゲットミラーレジストリーにミラーリングします。

    Copy to Clipboard Toggle word wrap
    $ oc mirror --config=./imageset-config.yaml \ 
    1
    
      docker://registry.example:5000              
    2
    1
    イメージセット設定ファイルを渡します。この手順では、imageset-config.yaml という名前であることを前提としています。
    2
    コンテンツをミラーリングするレジストリーを指定します。レジストリーは docker:// で始まる必要があります。ミラーレジストリーに最上位の namespace を指定する場合は、これ以降の実行でもこれと同じ namespace を使用する必要があります。

    オプションで、他のフラグを指定して OCI 機能の動作を調整できます。

    --oci-insecure-signature-policy
    署名をターゲットミラーレジストリーにプッシュしないでください。
    --oci-registries-config

    TOML 形式の registries.conf ファイルへのパスを指定します。これを使用して、イメージセット設定ファイルを変更することなく、テスト用の運用前の場所など、別のレジストリーからミラーリングできます。このフラグはローカル OCI カタログにのみ影響し、他のミラーリングされたコンテンツには影響しません。

    registries.conf ファイルの例

    Copy to Clipboard Toggle word wrap
    [[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 リソースで使用可能なパラメーターを示します。

表2.1 ImageSetConfiguration パラメーター
パラメーター説明

apiVersion

ImageSetConfiguration コンテンツの API バージョン。

文字列。例: mirror.openshift.io/v1alpha2

archiveSize

イメージセット内の各アーカイブファイルの最大サイズ (GiB 単位)。

整数。例: 4

mirror

イメージセットの設定。

オブジェクト

mirror.additionalImages

イメージセットの追加のイメージ設定。

オブジェクトの配列。以下に例を示します。

Copy to Clipboard Toggle word wrap
additionalImages:
  - name: registry.redhat.io/ubi8/ubi:latest

mirror.additionalImages.name

ミラーリングするイメージのタグまたはダイジェスト。

文字列。例: registry.redhat.io/ubi8/ubi:latest

mirror.blockedImages

ミラーリングからブロックするイメージの完全なタグ、ダイジェスト、またはパターン。

文字列の配列例: docker.io/library/alpine

mirror.helm

イメージセットのヘルム設定。oc-mirror プラグインは、レンダリング時にユーザー入力を必要としないヘルムチャートのみをサポートすることに注意してください。

オブジェクト

mirror.helm.local

ミラーリングするローカルヘルムチャート。

オブジェクトの配列。以下に例を示します。

Copy to Clipboard Toggle word wrap
local:
  - name: podinfo
    path: /test/podinfo-5.0.0.tar.gz

mirror.helm.local.name

ミラーリングするローカルヘルムチャートの名前。

文字列。例: podinfo

mirror.helm.local.path

ミラーリングするローカルヘルムチャートのパス。

文字列。例: /test/podinfo-5.0.0.tar.gz

mirror.helm.repositories

ミラーリング元のリモートヘルムリポジトリー。

オブジェクトの配列。以下に例を示します。

Copy to Clipboard Toggle word wrap
repositories:
  - name: podinfo
    url: https://example.github.io/podinfo
    charts:
      - name: podinfo
        version: 5.0.0

mirror.helm.repositories.name

ミラーリング元のヘルムリポジトリーの名前。

文字列。例: podinfo

mirror.helm.repositories.url

ミラーリング元の helm リポジトリーの URL。

文字列。例: https://example.github.io/podinfo

mirror.helm.repositories.charts

ミラーリングするリモートヘルムチャート。

オブジェクトの配列。

mirror.helm.repositories.charts.name

ミラーリングするヘルムチャートの名前。

文字列。例: podinfo

mirror.helm.repositories.charts.version

ミラーリングする名前付きヘルムチャートのバージョン。

文字列。例: 5.0.0

mirror.operators

イメージセットの Operators 設定。

オブジェクトの配列。以下に例を示します。

Copy to Clipboard Toggle word wrap
operators:
  - catalog: registry.redhat.io/redhat/redhat-operator-index:v4.15
    packages:
      - name: elasticsearch-operator
        minVersion: '2.4.0'

mirror.operators.catalog

イメージセットに含める Operator カタログ。

文字列。たとえば、registry.redhat.io/redhat/redhat-operator-index:v4.15 です。

mirror.operators.full

true の場合、完全なカタログ、Operator パッケージ、または Operator チャネルをダウンロードします。

ブール値。デフォルト値は false です。

mirror.operators.packages

Operator パッケージ設定

オブジェクトの配列。以下に例を示します。

Copy to Clipboard Toggle word wrap
operators:
  - catalog: registry.redhat.io/redhat/redhat-operator-index:v4.15
    packages:
      - name: elasticsearch-operator
        minVersion: '5.2.3-31'

mirror.operators.packages.name

イメージセットに含める Operator パッケージ名

文字列。例: elasticsearch-operator

mirror.operators.packages.channels

Operator パッケージのチャネル設定。

オブジェクト

mirror.operators.packages.channels.name

イメージセットに含める、パッケージ内で一意の Operator チャネル名。

文字列。たとえば、fast または stable-v4.15 です。

mirror.operators.packages.channels.maxVersion

Operator が存在するすべてのチャネルでミラーリングする最上位バージョンの Operator。詳細は、以下の注記を参照してください。

文字列。例: 5.2.3-31

mirror.operators.packages.channels.minBundle

含める最小バンドルの名前と、チャネルヘッドへの更新グラフ内のすべてのバンドル。名前付きバンドルにセマンティックバージョンメタデータがない場合にのみ、このフィールドを設定します。

文字列。例: bundleName

mirror.operators.packages.channels.minVersion

存在するすべてのチャネル間でミラーリングする Operator の最低バージョン。詳細は、以下の注記を参照してください。

文字列。例: 5.2.3-31

mirror.operators.packages.maxVersion

Operator が存在するすべてのチャネルでミラーリングする最上位バージョンの Operator。詳細は、以下の注記を参照してください。

文字列。例: 5.2.3-31

mirror.operators.packages.minVersion

存在するすべてのチャネル間でミラーリングする Operator の最低バージョン。詳細は、以下の注記を参照してください。

文字列。例: 5.2.3-31

mirror.operators.skipDependencies

true の場合、バンドルの依存関係は含まれません。

ブール値。デフォルト値は false です。

mirror.operators.targetCatalog

参照されるカタログをミラーリングするための代替名とオプションの namespace 階層。

文字列。例: my-namespace/my-operator-catalog

mirror.operators.targetName

参照されたカタログをミラーリングするための代替名。

targetName パラメーターは非推奨になりました。代わりに targetCatalog パラメーターを使用してください。

文字列。例: my-operator-catalog

mirror.operators.targetTag

targetName または targetCatalog に追加する代替タグ。

文字列。例: v1

mirror.platform

イメージセットのプラットフォーム設定。

オブジェクト

mirror.platform.architectures

ミラーリングするプラットフォームリリースペイロードのアーキテクチャー。

文字列の配列以下に例を示します。

Copy to Clipboard Toggle word wrap
architectures:
  - amd64
  - arm64
  - multi
  - ppc64le
  - s390x

デフォルト値は amd64 です。値 multi を指定すると、使用可能なすべてのアーキテクチャーでミラーリングがサポートされ、個別のアーキテクチャーを指定する必要がなくなります。

mirror.platform.channels

イメージセットのプラットフォームチャネル設定。

オブジェクトの配列。以下に例を示します。

Copy to Clipboard Toggle word wrap
channels:
  - name: stable-4.10
  - name: stable-4.15

mirror.platform.channels.full

true の場合、minVersion をチャネルの最初のリリースに設定し、maxVersion をチャネルの最後のリリースに設定します。

ブール値。デフォルト値は false です。

mirror.platform.channels.name

リリースチャネルの名前。

文字列。たとえば、stable-4.15 です。

mirror.platform.channels.minVersion

ミラーリングされる参照プラットフォームの最小バージョン。

文字列。例: 4.12.6

mirror.platform.channels.maxVersion

ミラーリングされる参照プラットフォームの最上位バージョン。

文字列。例: 4.15.1

mirror.platform.channels.shortestPath

最短パスミラーリングまたはフルレンジミラーリングを切り替えます。

ブール値。デフォルト値は false です。

mirror.platform.channels.type

ミラーリングするプラットフォームのタイプ。

文字列。例: ocp または okd。デフォルトは ocp です。

mirror.platform.graph

OSUS グラフがイメージセットに追加され、その後ミラーに公開されるかどうかを示します。

ブール値。デフォルト値は false です。

storageConfig

イメージセットのバックエンド設定。

オブジェクト

storageConfig.local

イメージセットのローカルバックエンド設定。

オブジェクト

storageConfig.local.path

イメージセットのメタデータを含むディレクトリーのパス。

文字列。例: ./path/to/dir/

storageConfig.registry

イメージセットのレジストリーバックエンド設定。

オブジェクト

storageConfig.registry.imageURL

バックエンドレジストリー URI。オプションで、URI に namespace 参照を含めることができます。

文字列。例: quay.io/myuser/imageset:metadata

storageConfig.registry.skipTLS

オプションで、参照されるバックエンドレジストリーの TLS 検証をスキップします。

ブール値。デフォルト値は false です。

注記

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ファイルの例

Copy to Clipboard Toggle word wrap
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ファイルの例

Copy to Clipboard Toggle word wrap
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ファイルの例

Copy to Clipboard Toggle word wrap
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ファイルの例

Copy to Clipboard Toggle word wrap
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ファイルの例

Copy to Clipboard Toggle word wrap
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ファイルの例

Copy to Clipboard Toggle word wrap
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ファイルの例

Copy to Clipboard Toggle word wrap
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ファイルの例

Copy to Clipboard Toggle word wrap
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 ファイルでは、minVersion4 .12.28 に設定され、eus-4.14 チャネルの maxVersion は 4.14.16 に設定されます

ImageSetConfigurationファイルの例

Copy to Clipboard Toggle word wrap
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 サブコマンドとフラグを説明しています。

表2.2 oc mirror サブコマンド
サブコマンド説明

completion

指定されたシェルのオートコンプリートスクリプトを生成します。

describe

イメージセットの内容を出力します。

help

サブコマンドに関するヘルプを表示します。

init

初期イメージセット設定テンプレートを出力します。

list

利用可能なプラットフォームと Operator のコンテンツとそのバージョンを一覧表示します。

version

oc-mirror バージョンを出力します。

表2.3 oc mirror フラグ
フラグ説明

-c, --config <string>

イメージセット設定ファイルへのパスを指定します。

--continue-on-error

イメージのプルに関連しないエラーが発生した場合は、続行して、可能な限りミラーリングを試みます。

--dest-skip-tls

ターゲットレジストリーの TLS 検証を無効にします。

--dest-use-http

ターゲットレジストリーにはプレーン HTTP を使用します。

--dry-run

イメージをミラーリングせずにアクションを出力します。mapping.txt ファイルおよび pruning-plan.json ファイルを生成します。

--from <string>

oc-mirror の実行によって生成されたイメージセットアーカイブへのパスを指定して、ターゲットレジストリーにロードします。

-h--help

ヘルプを表示します。

--ignore-history

イメージをダウンロードしてレイヤーをパックするときに、過去のミラーリングを無視します。増分ミラーリングを無効にし、より多くのデータをダウンロードする可能性があります。

--manifests-only

ImageContentSourcePolicy オブジェクトのマニフェストを生成して、ミラーレジストリーを使用するようにクラスターを設定しますが、実際にはイメージをミラーリングしません。このフラグを使用するには、--from フラグでイメージセットアーカイブを渡す必要があります。

--max-nested-paths <int>

ネストされたパスを制限する宛先レジストリーのネストされたパスの最大数を指定します。デフォルトは 0 です。

--max-per-registry <int>

レジストリーごとに許可される同時要求の数を指定します。デフォルト値は 6 です。

--oci-insecure-signature-policy

(--include-local-oci-catalogs を使用して) ローカル OCI カタログをミラーリングする場合は、署名をプッシュしないでください。

--oci-registries-config

(--include-local-oci-catalogs を使用して) ローカル OCI カタログをミラーリングするときに、コピー元の代替レジストリーの場所を指定するためのレジストリー設定ファイルを提供します。

--skip-cleanup

アーティファクトディレクトリーの削除を省略します。

--skip-image-pin

Operator カタログのイメージタグをダイジェストピンに置き換えないでください。

--skip-metadata-check

イメージセットの公開時にメタデータをスキップします。これは、イメージセットが --ignore-history で作成された場合にのみ推奨されます。

--skip-missing

イメージが見つからない場合は、エラーを報告して実行を中止する代わりにスキップします。イメージセット設定で明示的に指定されたカスタムイメージには適用されません。

--skip-pruning

ターゲットミラーレジストリーからのイメージの自動プルーニングを無効にします。

--skip-verification

ダイジェストの検証を省略します。

--source-skip-tls

ソースレジストリーの TLS 検証を無効にします。

--source-use-http

ソースレジストリーにはプレーン HTTP を使用します。

-v, --verbose <int>

ログレベルの詳細度の数値を指定します。有効な値は 0 - 9 です。デフォルトは 0 です。

2.4.15. 関連情報

第3章 Alibaba へのインストール

3.1. Alibaba Cloud へのインストールの準備

重要

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

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

3.1.1. 前提条件

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 解決および名前検索を提供します。

手順

  1. ドメイン、またはサブドメイン、およびレジストラーを特定します。既存のドメインとレジストラーを移行するか、Alibaba Cloud または別のソースから新しいドメインを取得することができます。

    注記

    Alibaba Cloud を介して新しいドメインを購入した場合、関連する DNS の変更が反映されるまでに時間がかかります。Alibaba Cloud を介したドメインの購入の詳細については、Alibaba Cloud ドメイン を参照してください。

  2. 既存のドメインとレジストラーを使用している場合は、その DNS を Alibaba Cloud に移行します。Alibaba Cloud のドキュメントの Domain name transfer を参照してください。
  3. ドメインの DNS を設定します。これには以下が含まれます。

  4. サブドメインを使用している場合は、会社の手順に従って、その委任レコードを親ドメインに追加します。

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 ペアをすぐに保存する必要があります。

  • AccessKey ID とシークレットをローカルコンピューターの ~/.alibabacloud/credentials ファイル に追加します。コンソールにログインすると、Alibaba Cloud によってこのファイルが自動的に作成されます。Cloud Credential Operator (CCO) ユーティリティー (ccoutil) は、Credential Request オブジェクトを処理するときにこれらの認証情報を使用します。

    以下に例を示します。

    Copy to Clipboard Toggle word wrap
    [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 Toggle word wrap
    {
      "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) がインストールされている。

手順

  1. 次のコマンドを実行して、OpenShift Container Platform リリースイメージの変数を設定します。

    Copy to Clipboard Toggle word wrap
    $ RELEASE_IMAGE=$(./openshift-install version | awk '/release image/ {print $3}')
  2. 以下のコマンドを実行して、OpenShift Container Platform リリースイメージから CCO コンテナーイメージを取得します。

    Copy to Clipboard Toggle word wrap
    $ CCO_IMAGE=$(oc adm release info --image-for='cloud-credential-operator' $RELEASE_IMAGE -a ~/.pull-secret)
    注記

    $RELEASE_IMAGE のアーキテクチャーが、ccoctlツールを使用する環境のアーキテクチャーと一致していることを確認してください。

  3. 以下のコマンドを実行して、OpenShift Container Platform リリースイメージ内の CCO コンテナーイメージから ccoctl バイナリーを抽出します。

    Copy to Clipboard Toggle word wrap
    $ oc image extract $CCO_IMAGE --file="/usr/bin/ccoctl" -a ~/.pull-secret
  4. 次のコマンドを実行して、権限を変更して ccoctl を実行可能にします。

    Copy to Clipboard Toggle word wrap
    $ chmod 775 ccoctl

検証

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

    Copy to Clipboard Toggle word wrap
    $ ./ccoctl.rhel9

    出力例

    Copy to Clipboard Toggle word wrap
    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 インフラストラクチャーにクラスターをインストールします。

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. 前提条件

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

手順

  1. クラスターノードへの認証に使用するローカルマシンに既存の SSH キーペアがない場合は、これを作成します。たとえば、Linux オペレーティングシステムを使用するコンピューターで以下のコマンドを実行します。

    Copy to Clipboard Toggle word wrap
    $ ssh-keygen -t ed25519 -N '' -f <path>/<file_name> 
    1
    1
    新しい SSH キーのパスとファイル名 (~/.ssh/id_ed25519 など) を指定します。既存のキーペアがある場合は、公開鍵が ~/.ssh ディレクトリーにあることを確認します。
    注記

    x86_64ppc64le、および s390x アーキテクチャーのみで FIPS 140-2/140-3 検証のために NIST に提出された RHEL 暗号化ライブラリーを使用する OpenShift Container Platform クラスターをインストールする予定がある場合は、ed25519 アルゴリズムを使用するキーを作成しないでください。代わりに、rsa アルゴリズムまたは ecdsa アルゴリズムを使用するキーを作成します。

  2. 公開 SSH キーを表示します。

    Copy to Clipboard Toggle word wrap
    $ cat <path>/<file_name>.pub

    たとえば、次のコマンドを実行して ~/.ssh/id_ed25519.pub 公開鍵を表示します。

    Copy to Clipboard Toggle word wrap
    $ cat ~/.ssh/id_ed25519.pub
  3. ローカルユーザーの SSH エージェントに SSH 秘密鍵 ID が追加されていない場合は、それを追加します。キーの SSH エージェント管理は、クラスターノードへのパスワードなしの SSH 認証、または ./openshift-install gather コマンドを使用する場合は必要になります。

    注記

    一部のディストリビューションでは、~/.ssh/id_rsa および ~/.ssh/id_dsa などのデフォルトの SSH 秘密鍵のアイデンティティーは自動的に管理されます。

    1. ssh-agent プロセスがローカルユーザーに対して実行されていない場合は、バックグラウンドタスクとして開始します。

      Copy to Clipboard Toggle word wrap
      $ eval "$(ssh-agent -s)"

      出力例

      Copy to Clipboard Toggle word wrap
      Agent pid 31874

      注記

      クラスターが FIPS モードにある場合は、FIPS 準拠のアルゴリズムのみを使用して SSH キーを生成します。鍵は RSA または ECDSA のいずれかである必要があります。

  4. SSH プライベートキーを ssh-agent に追加します。

    Copy to Clipboard Toggle word wrap
    $ ssh-add <path>/<file_name> 
    1
    1
    ~/.ssh/id_ed25519 などの、SSH プライベートキーのパスおよびファイル名を指定します。

    出力例

    Copy to Clipboard Toggle word wrap
    Identity added: /home/<you>/<path>/<file_name> (<computer_name>)

次のステップ

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

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

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

前提条件

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

手順

  1. OpenShift Cluster Manager サイトの インフラストラクチャープロバイダー ページにアクセスします。Red Hat アカウントがある場合は、認証情報を使用してログインします。アカウントがない場合はこれを作成します。
  2. インフラストラクチャープロバイダーを選択します。
  3. インストールタイプのページに移動し、ホストオペレーティングシステムとアーキテクチャーに対応するインストールプログラムをダウンロードして、インストール設定ファイルを保存するディレクトリーにファイルを配置します。

    重要

    インストールプログラムは、クラスターのインストールに使用するコンピューターにいくつかのファイルを作成します。クラスターのインストール完了後は、インストールプログラムおよびインストールプログラムが作成するファイルを保持する必要があります。ファイルはいずれもクラスターを削除するために必要になります。

    重要

    インストールプログラムで作成されたファイルを削除しても、クラスターがインストール時に失敗した場合でもクラスターは削除されません。クラスターを削除するには、特定のクラウドプロバイダー用の OpenShift Container Platform のアンインストール手順を実行します。

  4. インストールプログラムを展開します。たとえば、Linux オペレーティングシステムを使用するコンピューターで以下のコマンドを実行します。

    Copy to Clipboard Toggle word wrap
    $ tar -xvf openshift-install-linux.tar.gz
  5. Red Hat OpenShift Cluster Manager からインストールプルシークレット をダウンロードします。このプルシークレットを使用し、OpenShift Container Platform コンポーネントのコンテナーイメージを提供する Quay.io など、組み込まれた各種の認証局によって提供されるサービスで認証できます。

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

Alibaba Cloud にインストールする OpenShift Container Platform クラスターをカスタマイズできます。

前提条件

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

手順

  1. install-config.yaml ファイルを作成します。

    1. インストールプログラムが含まれるディレクトリーに切り替え、以下のコマンドを実行します。

      Copy to Clipboard Toggle word wrap
      $ ./openshift-install create install-config --dir <installation_directory> 
      1
      1
      <installation_directory> の場合、インストールプログラムが作成するファイルを保存するためにディレクトリー名を指定します。

      ディレクトリーを指定する場合:

      • ディレクトリーに execute 権限があることを確認します。この権限は、インストールディレクトリーで Terraform バイナリーを実行するために必要です。
      • 空のディレクトリーを使用します。ブートストラップ X.509 証明書などの一部のインストールアセットは有効期限が短いため、インストールディレクトリーを再利用しないでください。別のクラスターインストールの個別のファイルを再利用する必要がある場合は、それらをディレクトリーにコピーすることができます。ただし、インストールアセットのファイル名はリリース間で変更される可能性があります。インストールファイルを以前のバージョンの OpenShift Container Platform からコピーする場合は注意してコピーを行ってください。
    2. プロンプト時に、クラウドの設定の詳細情報を指定します。

      1. オプション: クラスターマシンにアクセスするために使用する SSH キーを選択します。

        注記

        インストールのデバッグまたは障害復旧を実行する必要のある実稼働用の OpenShift Container Platform クラスターでは、ssh-agent プロセスが使用する SSH キーを指定します。

      2. ターゲットとするプラットフォームとして alibabacloud を選択します。
      3. クラスターをデプロイするリージョンを選択します。
      4. クラスターをデプロイするベースドメインを選択します。ベースドメインは、クラスターに作成したパブリック DNS ゾーンに対応します。
      5. クラスターの記述名を指定します。
  2. クラスターを Alibaba Cloud にインストールするには、Cloud Credential Operator (CCO) が手動モードで動作する必要があります。install-config.yaml ファイルを変更して、credentialsMode パラメーターを Manual に設定します。

    credentialsModeManual に設定された install-config.yaml 設定ファイルの例

    Copy to Clipboard Toggle word wrap
    apiVersion: v1
    baseDomain: cluster1.example.com
    credentialsMode: Manual 
    1
    
    compute:
    - architecture: amd64
      hyperthreading: Enabled
     ...

    1
    この行を追加して、 credentialsModeManual に設定します。
  3. install-config.yaml ファイルをバックアップし、複数のクラスターをインストールするのに使用できるようにします。

    重要

    install-config.yaml ファイルはインストールプロセス時に使用されます。このファイルを再利用する必要がある場合は、この段階でこれをバックアップしてください。

3.3.6. 必要なインストールマニフェストの生成

クラスターがマシンを設定するために必要な Kubernetes マニフェストと Ignition 設定ファイルを生成する必要があります。

手順

  1. インストールプログラムが含まれているディレクトリーから次のコマンドを実行して、マニフェストを生成します。

    Copy to Clipboard Toggle word wrap
    $ 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 ファイル に追加しました。

手順

  1. 次のコマンドを実行して、インストールファイルのリリースイメージを $RELEASE_IMAGE 変数に設定します。

    Copy to Clipboard Toggle word wrap
    $ RELEASE_IMAGE=$(./openshift-install version | awk '/release image/ {print $3}')
  2. 以下のコマンドを実行して、OpenShift Container Platform リリースイメージから CredentialsRequest オブジェクトのリストを抽出します。

    Copy to Clipboard Toggle word wrap
    $ oc adm release extract \
      --from=$RELEASE_IMAGE \
      --credentials-requests \
      --included \
    1
    
      --install-config=<path_to_directory_with_installation_configuration>/install-config.yaml \
    2
    
      --to=<path_to_directory_for_credentials_requests> 
    3
    1
    --included パラメーターには、特定のクラスター設定に必要なマニフェストのみが含まれます。
    2
    install-config.yaml ファイルの場所を指定します。
    3
    CredentialsRequest オブジェクトを保存するディレクトリーへのパスを指定します。指定したディレクトリーが存在しない場合は、このコマンドによって作成されます。
    注記

    このコマンドの実行には少し時間がかかる場合があります。

  3. 次のコマンドを実行し、ccoctl ツールを使用して CredentialsRequest オブジェクトをすべて処理します。

    1. ツールを使用するには、次のコマンドを実行します。

      Copy to Clipboard Toggle word wrap
      $ 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
      1
      追跡用に作成されたクラウドリソースにタグを付けるために使用される名前です。
      2
      クラウドリソースが作成される Alibaba Cloud リージョンを指定します。
      3
      コンポーネント CredentialsRequest オブジェクトのファイルを含むディレクトリーを指定します。
      4
      生成されたコンポーネント認証情報シークレットが配置されるディレクトリーを指定します。
      注記

      クラスターで TechPreviewNoUpgrade 機能セットによって有効化されたテクノロジープレビュー機能を使用している場合は、--enable-tech-preview パラメーターを含める必要があります。

      出力例

      Copy to Clipboard Toggle word wrap
      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 回以上実行すると、以前に生成されたマニフェストシークレットが古くなり、新しく生成されたシークレットを再適用する必要があります。

    2. OpenShift Container Platform シークレットが作成されていることを確認します。

      Copy to Clipboard Toggle word wrap
      $ ls <path_to_ccoctl_output_dir>/manifests

      出力例

      Copy to Clipboard Toggle word wrap
      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 のドキュメントを参照してください。

  4. 生成されたクレデンシャルファイルをターゲットマニフェストディレクトリーにコピーします。

    Copy to Clipboard Toggle word wrap
    $ 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 Toggle word wrap
    $ ./openshift-install create cluster --dir <installation_directory> \ 
    1
    
        --log-level=info 
    2
    1
    <installation_directory> については、カスタマイズした ./install-config.yaml ファイルの場所を指定します。
    2
    異なるインストールの詳細情報を表示するには、info ではなく、warndebug、または error を指定します。

検証

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

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

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

出力例

Copy to Clipboard Toggle word wrap
...
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 にインストールできます。

手順

  1. Red Hat カスタマーポータルの OpenShift Container Platform ダウンロードページ に移動します。
  2. Product Variant ドロップダウンリストからアーキテクチャーを選択します。
  3. バージョン ドロップダウンリストから適切なバージョンを選択します。
  4. OpenShift v4.15 Linux Client エントリーの横にある Download Now をクリックして、ファイルを保存します。
  5. アーカイブを展開します。

    Copy to Clipboard Toggle word wrap
    $ tar xvf <file>
  6. oc バイナリーを、PATH にあるディレクトリーに配置します。

    PATH を確認するには、以下のコマンドを実行します。

    Copy to Clipboard Toggle word wrap
    $ echo $PATH

検証

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

    Copy to Clipboard Toggle word wrap
    $ oc <command>
Windows への OpenShift CLI のインストール

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

手順

  1. Red Hat カスタマーポータルの OpenShift Container Platform ダウンロードページ に移動します。
  2. バージョン ドロップダウンリストから適切なバージョンを選択します。
  3. OpenShift v4.15 Windows Client エントリーの横にある Download Now をクリックして、ファイルを保存します。
  4. ZIP プログラムでアーカイブを展開します。
  5. oc バイナリーを、PATH にあるディレクトリーに移動します。

    PATH を確認するには、コマンドプロンプトを開いて以下のコマンドを実行します。

    Copy to Clipboard Toggle word wrap
    C:\> path

検証

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

    Copy to Clipboard Toggle word wrap
    C:\> oc <command>
macOS への OpenShift CLI のインストール

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

手順

  1. Red Hat カスタマーポータルの OpenShift Container Platform ダウンロードページ に移動します。
  2. バージョン ドロップダウンリストから適切なバージョンを選択します。
  3. OpenShift v4.15 macOS Client エントリーの横にある Download Now をクリックして、ファイルを保存します。

    注記

    macOS arm64 の場合は、OpenShift v4.15 macOS arm64 Client エントリーを選択します。

  4. アーカイブを展開し、解凍します。
  5. oc バイナリーをパスにあるディレクトリーに移動します。

    PATH を確認するには、ターミナルを開き、以下のコマンドを実行します。

    Copy to Clipboard Toggle word wrap
    $ echo $PATH

検証

  • oc コマンドを使用してインストールを確認します。

    Copy to Clipboard Toggle word wrap
    $ oc <command>

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

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

前提条件

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

手順

  1. kubeadmin 認証情報をエクスポートします。

    Copy to Clipboard Toggle word wrap
    $ export KUBECONFIG=<installation_directory>/auth/kubeconfig 
    1
    1
    <installation_directory> には、インストールファイルを保存したディレクトリーへのパスを指定します。
  2. エクスポートされた設定を使用して、oc コマンドを正常に実行できることを確認します。

    Copy to Clipboard Toggle word wrap
    $ oc whoami

    出力例

    Copy to Clipboard Toggle word wrap
    system:admin

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

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

前提条件

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

手順

  1. インストールホストで kubeadmin-password ファイルから kubeadmin ユーザーのパスワードを取得します。

    Copy to Clipboard Toggle word wrap
    $ cat <installation_directory>/auth/kubeadmin-password
    注記

    または、インストールホストで <installation_directory>/.openshift_install.log ログファイルから kubeadmin パスワードを取得できます。

  2. OpenShift Container Platform Web コンソールルートをリスト表示します。

    Copy to Clipboard Toggle word wrap
    $ oc get routes -n openshift-console | grep 'console-openshift'
    注記

    または、インストールホストで <installation_directory>/.openshift_install.log ログファイルからで OpenShift Container Platform ルートを取得できます。

    出力例

    Copy to Clipboard Toggle word wrap
    console     console-openshift-console.apps.<cluster_name>.<base_domain>            console     https   reencrypt/Redirect   None

  3. 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 サブスクリプションを追跡します。

関連情報

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. 前提条件

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

手順

  1. クラスターノードへの認証に使用するローカルマシンに既存の SSH キーペアがない場合は、これを作成します。たとえば、Linux オペレーティングシステムを使用するコンピューターで以下のコマンドを実行します。

    Copy to Clipboard Toggle word wrap
    $ ssh-keygen -t ed25519 -N '' -f <path>/<file_name> 
    1
    1
    新しい SSH キーのパスとファイル名 (~/.ssh/id_ed25519 など) を指定します。既存のキーペアがある場合は、公開鍵が ~/.ssh ディレクトリーにあることを確認します。
    注記

    x86_64ppc64le、および s390x アーキテクチャーのみで FIPS 140-2/140-3 検証のために NIST に提出された RHEL 暗号化ライブラリーを使用する OpenShift Container Platform クラスターをインストールする予定がある場合は、ed25519 アルゴリズムを使用するキーを作成しないでください。代わりに、rsa アルゴリズムまたは ecdsa アルゴリズムを使用するキーを作成します。

  2. 公開 SSH キーを表示します。

    Copy to Clipboard Toggle word wrap
    $ cat <path>/<file_name>.pub

    たとえば、次のコマンドを実行して ~/.ssh/id_ed25519.pub 公開鍵を表示します。

    Copy to Clipboard Toggle word wrap
    $ cat ~/.ssh/id_ed25519.pub
  3. ローカルユーザーの SSH エージェントに SSH 秘密鍵 ID が追加されていない場合は、それを追加します。キーの SSH エージェント管理は、クラスターノードへのパスワードなしの SSH 認証、または ./openshift-install gather コマンドを使用する場合は必要になります。

    注記

    一部のディストリビューションでは、~/.ssh/id_rsa および ~/.ssh/id_dsa などのデフォルトの SSH 秘密鍵のアイデンティティーは自動的に管理されます。

    1. ssh-agent プロセスがローカルユーザーに対して実行されていない場合は、バックグラウンドタスクとして開始します。

      Copy to Clipboard Toggle word wrap
      $ eval "$(ssh-agent -s)"

      出力例

      Copy to Clipboard Toggle word wrap
      Agent pid 31874

      注記

      クラスターが FIPS モードにある場合は、FIPS 準拠のアルゴリズムのみを使用して SSH キーを生成します。鍵は RSA または ECDSA のいずれかである必要があります。

  4. SSH プライベートキーを ssh-agent に追加します。

    Copy to Clipboard Toggle word wrap
    $ ssh-add <path>/<file_name> 
    1
    1
    ~/.ssh/id_ed25519 などの、SSH プライベートキーのパスおよびファイル名を指定します。

    出力例

    Copy to Clipboard Toggle word wrap
    Identity added: /home/<you>/<path>/<file_name> (<computer_name>)

次のステップ

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

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

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

前提条件

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

手順

  1. OpenShift Cluster Manager サイトの インフラストラクチャープロバイダー ページにアクセスします。Red Hat アカウントがある場合は、認証情報を使用してログインします。アカウントがない場合はこれを作成します。
  2. インフラストラクチャープロバイダーを選択します。
  3. インストールタイプのページに移動し、ホストオペレーティングシステムとアーキテクチャーに対応するインストールプログラムをダウンロードして、インストール設定ファイルを保存するディレクトリーにファイルを配置します。

    重要

    インストールプログラムは、クラスターのインストールに使用するコンピューターにいくつかのファイルを作成します。クラスターのインストール完了後は、インストールプログラムおよびインストールプログラムが作成するファイルを保持する必要があります。ファイルはいずれもクラスターを削除するために必要になります。

    重要

    インストールプログラムで作成されたファイルを削除しても、クラスターがインストール時に失敗した場合でもクラスターは削除されません。クラスターを削除するには、特定のクラウドプロバイダー用の OpenShift Container Platform のアンインストール手順を実行します。

  4. インストールプログラムを展開します。たとえば、Linux オペレーティングシステムを使用するコンピューターで以下のコマンドを実行します。

    Copy to Clipboard Toggle word wrap
    $ tar -xvf openshift-install-linux.tar.gz
  5. Red Hat OpenShift Cluster Manager からインストールプルシークレット をダウンロードします。このプルシークレットを使用し、OpenShift Container Platform コンポーネントのコンテナーイメージを提供する Quay.io など、組み込まれた各種の認証局によって提供されるサービスで認証できます。
3.4.4.1. インストール設定ファイルの作成

Alibaba Cloud にインストールする OpenShift Container Platform クラスターをカスタマイズできます。

前提条件

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

手順

  1. install-config.yaml ファイルを作成します。

    1. インストールプログラムが含まれるディレクトリーに切り替え、以下のコマンドを実行します。

      Copy to Clipboard Toggle word wrap
      $ ./openshift-install create install-config --dir <installation_directory> 
      1
      1
      <installation_directory> の場合、インストールプログラムが作成するファイルを保存するためにディレクトリー名を指定します。

      ディレクトリーを指定する場合:

      • ディレクトリーに execute 権限があることを確認します。この権限は、インストールディレクトリーで Terraform バイナリーを実行するために必要です。
      • 空のディレクトリーを使用します。ブートストラップ X.509 証明書などの一部のインストールアセットは有効期限が短いため、インストールディレクトリーを再利用しないでください。別のクラスターインストールの個別のファイルを再利用する必要がある場合は、それらをディレクトリーにコピーすることができます。ただし、インストールアセットのファイル名はリリース間で変更される可能性があります。インストールファイルを以前のバージョンの OpenShift Container Platform からコピーする場合は注意してコピーを行ってください。
    2. プロンプト時に、クラウドの設定の詳細情報を指定します。

      1. オプション: クラスターマシンにアクセスするために使用する SSH キーを選択します。

        注記

        インストールのデバッグまたは障害復旧を実行する必要のある実稼働用の OpenShift Container Platform クラスターでは、ssh-agent プロセスが使用する SSH キーを指定します。

      2. ターゲットとするプラットフォームとして alibabacloud を選択します。
      3. クラスターをデプロイするリージョンを選択します。
      4. クラスターをデプロイするベースドメインを選択します。ベースドメインは、クラスターに作成したパブリック DNS ゾーンに対応します。
      5. クラスターの記述名を指定します。
  2. クラスターを Alibaba Cloud にインストールするには、Cloud Credential Operator (CCO) が手動モードで動作する必要があります。install-config.yaml ファイルを変更して、credentialsMode パラメーターを Manual に設定します。

    credentialsModeManual に設定された install-config.yaml 設定ファイルの例

    Copy to Clipboard Toggle word wrap
    apiVersion: v1
    baseDomain: cluster1.example.com
    credentialsMode: Manual 
    1
    
    compute:
    - architecture: amd64
      hyperthreading: Enabled
     ...

    1
    この行を追加して、 credentialsModeManual に設定します。
  3. install-config.yaml ファイルを変更します。利用可能なパラメーターの詳細は、「インストール設定パラメーター」のセクションを参照してください。
  4. install-config.yaml ファイルをバックアップし、複数のクラスターをインストールするのに使用できるようにします。

    重要

    install-config.yaml ファイルはインストールプロセス時に使用されます。このファイルを再利用する必要がある場合は、この段階でこれをバックアップしてください。

3.4.4.2. 必要なインストールマニフェストの生成

クラスターがマシンを設定するために必要な Kubernetes マニフェストと Ignition 設定ファイルを生成する必要があります。

手順

  1. インストールプログラムが含まれているディレクトリーから次のコマンドを実行して、マニフェストを生成します。

    Copy to Clipboard Toggle word wrap
    $ 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 ファイル に追加しました。

手順

  1. 次のコマンドを実行して、インストールファイルのリリースイメージを $RELEASE_IMAGE 変数に設定します。

    Copy to Clipboard Toggle word wrap
    $ RELEASE_IMAGE=$(./openshift-install version | awk '/release image/ {print $3}')
  2. 以下のコマンドを実行して、OpenShift Container Platform リリースイメージから CredentialsRequest オブジェクトのリストを抽出します。

    Copy to Clipboard Toggle word wrap
    $ oc adm release extract \
      --from=$RELEASE_IMAGE \
      --credentials-requests \
      --included \
    1
    
      --install-config=<path_to_directory_with_installation_configuration>/install-config.yaml \
    2
    
      --to=<path_to_directory_for_credentials_requests> 
    3
    1
    --included パラメーターには、特定のクラスター設定に必要なマニフェストのみが含まれます。
    2
    install-config.yaml ファイルの場所を指定します。
    3
    CredentialsRequest オブジェクトを保存するディレクトリーへのパスを指定します。指定したディレクトリーが存在しない場合は、このコマンドによって作成されます。
    注記

    このコマンドの実行には少し時間がかかる場合があります。

  3. 次のコマンドを実行し、ccoctl ツールを使用して CredentialsRequest オブジェクトをすべて処理します。

    1. ツールを使用するには、次のコマンドを実行します。

      Copy to Clipboard Toggle word wrap
      $ 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
      1
      追跡用に作成されたクラウドリソースにタグを付けるために使用される名前です。
      2
      クラウドリソースが作成される Alibaba Cloud リージョンを指定します。
      3
      コンポーネント CredentialsRequest オブジェクトのファイルを含むディレクトリーを指定します。
      4
      生成されたコンポーネント認証情報シークレットが配置されるディレクトリーを指定します。
      注記

      クラスターで TechPreviewNoUpgrade 機能セットによって有効化されたテクノロジープレビュー機能を使用している場合は、--enable-tech-preview パラメーターを含める必要があります。

      出力例

      Copy to Clipboard Toggle word wrap
      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 回以上実行すると、以前に生成されたマニフェストシークレットが古くなり、新しく生成されたシークレットを再適用する必要があります。

    2. OpenShift Container Platform シークレットが作成されていることを確認します。

      Copy to Clipboard Toggle word wrap
      $ ls <path_to_ccoctl_output_dir>/manifests

      出力例

      Copy to Clipboard Toggle word wrap
      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 のドキュメントを参照してください。

  4. 生成されたクレデンシャルファイルをターゲットマニフェストディレクトリーにコピーします。

    Copy to Clipboard Toggle word wrap
    $ 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) をカスタマイズして、クラスターのプラットフォームに関する詳細を指定したり、必要なパラメーターの値を変更したりできます。

Copy to Clipboard Toggle word wrap
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 
1

 networking:
  clusterNetwork:
  - cidr: 10.128.0.0/14
    hostPrefix: 23
  machineNetwork:
  - cidr: 10.0.0.0/16
  networkType: OVNKubernetes 
2

  serviceNetwork:
  - 172.30.0.0/16
platform:
  alibabacloud:
    defaultMachinePlatform: 
3

      instanceType: ecs.g6.xlarge
      systemDiskCategory: cloud_efficiency
      systemDiskSize: 200
    region: ap-southeast-1 
4

    resourceGroupID: rg-acfnw6j3hyai 
5

    vpcID: vpc-0xifdjerdibmaqvtjob2b 
6

    vswitchIDs: 
7

    - vsw-0xi8ycgwc8wv5rhviwdq5
    - vsw-0xiy6v3z2tedv009b4pz2
publish: External
pullSecret: '{"auths": {"cloud.openshift.com": {"auth": ... }' 
8

sshKey: |
  ssh-rsa AAAA... 
9
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[].cidrnetworking.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) も設定されます。

手順

  1. install-config.yaml ファイルを編集し、プロキシー設定を追加します。以下に例を示します。

    Copy to Clipboard Toggle word wrap
    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.comx.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 Toggle word wrap
    $ ./openshift-install wait-for install-complete --log-level debug
  2. ファイルを保存し、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 Toggle word wrap
    $ ./openshift-install create cluster --dir <installation_directory> \ 
    1
    
        --log-level=info 
    2
    1
    <installation_directory> については、カスタマイズした ./install-config.yaml ファイルの場所を指定します。
    2
    異なるインストールの詳細情報を表示するには、info ではなく、warndebug、または error を指定します。

検証

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

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

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

出力例

Copy to Clipboard Toggle word wrap
...
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 にインストールできます。

手順

  1. Red Hat カスタマーポータルの OpenShift Container Platform ダウンロードページ に移動します。
  2. Product Variant ドロップダウンリストからアーキテクチャーを選択します。
  3. バージョン ドロップダウンリストから適切なバージョンを選択します。
  4. OpenShift v4.15 Linux Client エントリーの横にある Download Now をクリックして、ファイルを保存します。
  5. アーカイブを展開します。

    Copy to Clipboard Toggle word wrap
    $ tar xvf <file>
  6. oc バイナリーを、PATH にあるディレクトリーに配置します。

    PATH を確認するには、以下のコマンドを実行します。

    Copy to Clipboard Toggle word wrap
    $ echo $PATH

検証

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

    Copy to Clipboard Toggle word wrap
    $ oc <command>
Windows への OpenShift CLI のインストール

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

手順

  1. Red Hat カスタマーポータルの OpenShift Container Platform ダウンロードページ に移動します。
  2. バージョン ドロップダウンリストから適切なバージョンを選択します。
  3. OpenShift v4.15 Windows Client エントリーの横にある Download Now をクリックして、ファイルを保存します。
  4. ZIP プログラムでアーカイブを展開します。
  5. oc バイナリーを、PATH にあるディレクトリーに移動します。

    PATH を確認するには、コマンドプロンプトを開いて以下のコマンドを実行します。

    Copy to Clipboard Toggle word wrap
    C:\> path

検証

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

    Copy to Clipboard Toggle word wrap
    C:\> oc <command>
macOS への OpenShift CLI のインストール

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

手順

  1. Red Hat カスタマーポータルの OpenShift Container Platform ダウンロードページ に移動します。
  2. バージョン ドロップダウンリストから適切なバージョンを選択します。
  3. OpenShift v4.15 macOS Client エントリーの横にある Download Now をクリックして、ファイルを保存します。

    注記

    macOS arm64 の場合は、OpenShift v4.15 macOS arm64 Client エントリーを選択します。

  4. アーカイブを展開し、解凍します。
  5. oc バイナリーをパスにあるディレクトリーに移動します。

    PATH を確認するには、ターミナルを開き、以下のコマンドを実行します。

    Copy to Clipboard Toggle word wrap
    $ echo $PATH

検証

  • oc コマンドを使用してインストールを確認します。

    Copy to Clipboard Toggle word wrap
    $ oc <command>

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

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

前提条件

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

手順

  1. kubeadmin 認証情報をエクスポートします。

    Copy to Clipboard Toggle word wrap
    $ export KUBECONFIG=<installation_directory>/auth/kubeconfig 
    1
    1
    <installation_directory> には、インストールファイルを保存したディレクトリーへのパスを指定します。
  2. エクスポートされた設定を使用して、oc コマンドを正常に実行できることを確認します。

    Copy to Clipboard Toggle word wrap
    $ oc whoami

    出力例

    Copy to Clipboard Toggle word wrap
    system:admin

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

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

前提条件

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

手順

  1. インストールホストで kubeadmin-password ファイルから kubeadmin ユーザーのパスワードを取得します。

    Copy to Clipboard Toggle word wrap
    $ cat <installation_directory>/auth/kubeadmin-password
    注記

    または、インストールホストで <installation_directory>/.openshift_install.log ログファイルから kubeadmin パスワードを取得できます。

  2. OpenShift Container Platform Web コンソールルートをリスト表示します。

    Copy to Clipboard Toggle word wrap
    $ oc get routes -n openshift-console | grep 'console-openshift'
    注記

    または、インストールホストで <installation_directory>/.openshift_install.log ログファイルからで OpenShift Container Platform ルートを取得できます。

    出力例

    Copy to Clipboard Toggle word wrap
    console     console-openshift-console.apps.<cluster_name>.<base_domain>            console     https   reencrypt/Redirect   None

  3. 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 サブスクリプションを追跡します。

関連情報

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. 前提条件

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

手順

  1. クラスターノードへの認証に使用するローカルマシンに既存の SSH キーペアがない場合は、これを作成します。たとえば、Linux オペレーティングシステムを使用するコンピューターで以下のコマンドを実行します。

    Copy to Clipboard Toggle word wrap
    $ ssh-keygen -t ed25519 -N '' -f <path>/<file_name> 
    1
    1
    新しい SSH キーのパスとファイル名 (~/.ssh/id_ed25519 など) を指定します。既存のキーペアがある場合は、公開鍵が ~/.ssh ディレクトリーにあることを確認します。
    注記

    x86_64ppc64le、および s390x アーキテクチャーのみで FIPS 140-2/140-3 検証のために NIST に提出された RHEL 暗号化ライブラリーを使用する OpenShift Container Platform クラスターをインストールする予定がある場合は、ed25519 アルゴリズムを使用するキーを作成しないでください。代わりに、rsa アルゴリズムまたは ecdsa アルゴリズムを使用するキーを作成します。

  2. 公開 SSH キーを表示します。

    Copy to Clipboard Toggle word wrap
    $ cat <path>/<file_name>.pub

    たとえば、次のコマンドを実行して ~/.ssh/id_ed25519.pub 公開鍵を表示します。

    Copy to Clipboard Toggle word wrap
    $ cat ~/.ssh/id_ed25519.pub
  3. ローカルユーザーの SSH エージェントに SSH 秘密鍵 ID が追加されていない場合は、それを追加します。キーの SSH エージェント管理は、クラスターノードへのパスワードなしの SSH 認証、または ./openshift-install gather コマンドを使用する場合は必要になります。

    注記

    一部のディストリビューションでは、~/.ssh/id_rsa および ~/.ssh/id_dsa などのデフォルトの SSH 秘密鍵のアイデンティティーは自動的に管理されます。

    1. ssh-agent プロセスがローカルユーザーに対して実行されていない場合は、バックグラウンドタスクとして開始します。

      Copy to Clipboard Toggle word wrap
      $ eval "$(ssh-agent -s)"

      出力例

      Copy to Clipboard Toggle word wrap
      Agent pid 31874

      注記

      クラスターが FIPS モードにある場合は、FIPS 準拠のアルゴリズムのみを使用して SSH キーを生成します。鍵は RSA または ECDSA のいずれかである必要があります。

  4. SSH プライベートキーを ssh-agent に追加します。

    Copy to Clipboard Toggle word wrap
    $ ssh-add <path>/<file_name> 
    1
    1
    ~/.ssh/id_ed25519 などの、SSH プライベートキーのパスおよびファイル名を指定します。

    出力例

    Copy to Clipboard Toggle word wrap
    Identity added: /home/<you>/<path>/<file_name> (<computer_name>)

次のステップ

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

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

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

前提条件

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

手順

  1. OpenShift Cluster Manager サイトの インフラストラクチャープロバイダー ページにアクセスします。Red Hat アカウントがある場合は、認証情報を使用してログインします。アカウントがない場合はこれを作成します。
  2. インフラストラクチャープロバイダーを選択します。
  3. インストールタイプのページに移動し、ホストオペレーティングシステムとアーキテクチャーに対応するインストールプログラムをダウンロードして、インストール設定ファイルを保存するディレクトリーにファイルを配置します。

    重要

    インストールプログラムは、クラスターのインストールに使用するコンピューターにいくつかのファイルを作成します。クラスターのインストール完了後は、インストールプログラムおよびインストールプログラムが作成するファイルを保持する必要があります。ファイルはいずれもクラスターを削除するために必要になります。

    重要

    インストールプログラムで作成されたファイルを削除しても、クラスターがインストール時に失敗した場合でもクラスターは削除されません。クラスターを削除するには、特定のクラウドプロバイダー用の OpenShift Container Platform のアンインストール手順を実行します。

  4. インストールプログラムを展開します。たとえば、Linux オペレーティングシステムを使用するコンピューターで以下のコマンドを実行します。

    Copy to Clipboard Toggle word wrap
    $ tar -xvf openshift-install-linux.tar.gz
  5. 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 インストールプログラムおよびクラスターのプルシークレットがある。

手順

  1. install-config.yaml ファイルを作成します。

    1. インストールプログラムが含まれるディレクトリーに切り替え、以下のコマンドを実行します。

      Copy to Clipboard Toggle word wrap
      $ ./openshift-install create install-config --dir <installation_directory> 
      1
      1
      <installation_directory> の場合、インストールプログラムが作成するファイルを保存するためにディレクトリー名を指定します。

      ディレクトリーを指定する場合:

      • ディレクトリーに execute 権限があることを確認します。この権限は、インストールディレクトリーで Terraform バイナリーを実行するために必要です。
      • 空のディレクトリーを使用します。ブートストラップ X.509 証明書などの一部のインストールアセットは有効期限が短いため、インストールディレクトリーを再利用しないでください。別のクラスターインストールの個別のファイルを再利用する必要がある場合は、それらをディレクトリーにコピーすることができます。ただし、インストールアセットのファイル名はリリース間で変更される可能性があります。インストールファイルを以前のバージョンの OpenShift Container Platform からコピーする場合は注意してコピーを行ってください。
    2. プロンプト時に、クラウドの設定の詳細情報を指定します。

      1. オプション: クラスターマシンにアクセスするために使用する SSH キーを選択します。

        注記

        インストールのデバッグまたは障害復旧を実行する必要のある実稼働用の OpenShift Container Platform クラスターでは、ssh-agent プロセスが使用する SSH キーを指定します。

      2. クラスターの記述名を入力します。
  2. install-config.yaml ファイルを変更します。利用可能なパラメーターの詳細は、「インストール設定パラメーター」のセクションを参照してください。
  3. install-config.yaml ファイルをバックアップし、複数のクラスターをインストールするのに使用できるようにします。

    重要

    install-config.yaml ファイルはインストールプロセス時に使用されます。このファイルを再利用する必要がある場合は、この段階でこれをバックアップしてください。

3.5.5.2. 必要なインストールマニフェストの生成

クラスターがマシンを設定するために必要な Kubernetes マニフェストと Ignition 設定ファイルを生成する必要があります。

手順

  1. インストールプログラムが含まれているディレクトリーから次のコマンドを実行して、マニフェストを生成します。

    Copy to Clipboard Toggle word wrap
    $ openshift-install create manifests --dir <installation_directory>

    ここで、

    <installation_directory>
    インストールプログラムがファイルを作成するディレクトリーを指定します。
注記

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

前提条件

以下が必要になります。

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

手順

  1. 次のコマンドを実行して、インストールファイルのリリースイメージを $RELEASE_IMAGE 変数に設定します。

    Copy to Clipboard Toggle word wrap
    $ RELEASE_IMAGE=$(./openshift-install version | awk '/release image/ {print $3}')
  2. 以下のコマンドを実行して、OpenShift Container Platform リリースイメージから CredentialsRequest オブジェクトのリストを抽出します。

    Copy to Clipboard Toggle word wrap
    $ oc adm release extract \
      --from=$RELEASE_IMAGE \
      --credentials-requests \
      --included \
    1
    
      --install-config=<path_to_directory_with_installation_configuration>/install-config.yaml \
    2
    
      --to=<path_to_directory_for_credentials_requests> 
    3
    1
    --included パラメーターには、特定のクラスター設定に必要なマニフェストのみが含まれます。
    2
    install-config.yaml ファイルの場所を指定します。
    3
    CredentialsRequest オブジェクトを保存するディレクトリーへのパスを指定します。指定したディレクトリーが存在しない場合は、このコマンドによって作成されます。
    注記

    このコマンドの実行には少し時間がかかる場合があります。

3.5.5.3. Alibaba Cloud 用にカスタマイズされた install-config.yaml ファイルのサンプル

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

Copy to Clipboard Toggle word wrap
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 
1

 networking:
  clusterNetwork:
  - cidr: 10.128.0.0/14
    hostPrefix: 23
  machineNetwork:
  - cidr: 10.0.0.0/16
  networkType: OVNKubernetes 
2

  serviceNetwork:
  - 172.30.0.0/16
platform:
  alibabacloud:
    defaultMachinePlatform: 
3

      instanceType: ecs.g6.xlarge
      systemDiskCategory: cloud_efficiency
      systemDiskSize: 200
    region: ap-southeast-1 
4

    resourceGroupID: rg-acfnw6j3hyai 
5

    vpcID: vpc-0xifdjerdibmaqvtjob2b 
6

    vswitchIDs: 
7

    - vsw-0xi8ycgwc8wv5rhviwdq5
    - vsw-0xiy6v3z2tedv009b4pz2
publish: External
pullSecret: '{"auths": {"cloud.openshift.com": {"auth": ... }' 
8

sshKey: |
  ssh-rsa AAAA... 
9
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[].cidrnetworking.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) も設定されます。

手順

  1. install-config.yaml ファイルを編集し、プロキシー設定を追加します。以下に例を示します。

    Copy to Clipboard Toggle word wrap
    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.comx.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 Toggle word wrap
    $ ./openshift-install wait-for install-complete --log-level debug
  2. ファイルを保存し、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) のフィールドは以下の表で説明されています。

表3.1 Cluster Network Operator 設定オブジェクト
フィールド説明

metadata.name

string

CNO オブジェクトの名前。この名前は常に cluster です。

spec.clusterNetwork

array

Pod ID アドレスの割り当て、サブネット接頭辞の長さのクラスター内の個別ノードへの割り当てに使用される IP アドレスのブロックを指定するリストです。以下に例を示します。

Copy to Clipboard Toggle word wrap
spec:
  clusterNetwork:
  - cidr: 10.128.0.0/19
    hostPrefix: 23
  - cidr: 10.128.32.0/19
    hostPrefix: 23

spec.serviceNetwork

array

サービスの IP アドレスのブロック。OpenShift SDN および OVN-Kubernetes ネットワークプラグインは、サービスネットワークの単一 IP アドレスブロックのみをサポートします。以下に例を示します。

Copy to Clipboard Toggle word wrap
spec:
  serviceNetwork:
  - 172.30.0.0/14

マニフェストを作成する前に、このフィールドを install-config.yaml ファイルでのみカスタマイズすることができます。この値は、マニフェストファイルでは読み取り専用です。

spec.defaultNetwork

object

クラスターネットワークのネットワークプラグインを設定します。

spec.kubeProxyConfig

object

このオブジェクトのフィールドは、kube-proxy 設定を指定します。OVN-Kubernetes クラスターネットワークプラグインを使用している場合、kube-proxy 設定は機能しません。

defaultNetwork オブジェクト設定

defaultNetwork オブジェクトの値は、以下の表で定義されます。

表3.2 defaultNetwork オブジェクト
フィールド説明

type

string

OVNKubernetes。Red Hat OpenShift Networking ネットワークプラグインは、インストール中に選択されます。この値は、クラスターのインストール後は変更できません。

注記

OpenShift Container Platform は、デフォルトで OVN-Kubernetes ネットワークプラグインを使用します。OpenShift SDN は、新しいクラスターのインストールの選択肢として利用できなくなりました。

ovnKubernetesConfig

object

このオブジェクトは、OVN-Kubernetes ネットワークプラグインに対してのみ有効です。

OVN-Kubernetes ネットワークプラグインの設定

次の表では、OVN-Kubernetes ネットワークプラグインの設定フィールドを説明します。

表3.3 ovnKubernetesConfig オブジェクト
フィールド説明

mtu

integer

Geneve (Generic Network Virtualization Encapsulation) オーバーレイネットワークの MTU (maximum transmission unit)。これは、プライマリーネットワークインターフェイスの MTU に基づいて自動的に検出されます。通常、検出された MTU を上書きする必要はありません。

自動検出した値が予想される値ではない場合は、ノード上のプライマリーネットワークインターフェイスの MTU が正しいことを確認します。このオプションを使用して、ノード上のプライマリーネットワークインターフェイスの MTU 値を変更することはできません。

クラスターで異なるノードに異なる MTU 値が必要な場合、この値をクラスター内の最小の MTU 値よりも 100 小さく設定する必要があります。たとえば、クラスター内の一部のノードでは MTU が 9001 であり、MTU が 1500 のクラスターもある場合には、この値を 1400 に設定する必要があります。

genevePort

integer

すべての Geneve パケットに使用するポート。デフォルト値は 6081 です。この値は、クラスターのインストール後は変更できません。

ipsecConfig

object

IPsec 設定をカスタマイズするための設定オブジェクトを指定します。

policyAuditConfig

object

ネットワークポリシー監査ロギングをカスタマイズする設定オブジェクトを指定します。指定されていない場合は、デフォルトの監査ログ設定が使用されます。

gatewayConfig

object

オプション: Egress トラフィックのノードゲートウェイへの送信方法をカスタマイズするための設定オブジェクトを指定します。

注記

Egress トラフィックの移行中は、Cluster Network Operator (CNO) が変更を正常にロールアウトするまで、ワークロードとサービストラフィックに多少の中断が発生することが予想されます。

v4InternalSubnet

既存のネットワークインフラストラクチャーが 100.64.0.0/16 IPv4 サブネットと重複している場合は、OVN-Kubernetes による内部使用のために別の IP アドレス範囲を指定できます。IP アドレス範囲が、OpenShift Container Platform インストールで使用される他のサブネットと重複しないようにする必要があります。IP アドレス範囲は、クラスターに追加できるノードの最大数より大きくする必要があります。たとえば、clusterNetwork.cidr 値が 10.128.0.0/14 で、clusterNetwork.hostPrefix 値が /23 の場合、ノードの最大数は 2^(23-14)=512 です。

このフィールドは、インストール後に変更できません。

デフォルト値は 100.64.0.0/16 です。

v6InternalSubnet

既存のネットワークインフラストラクチャーが fd98::/48 IPv6 サブネットと重複する場合は、OVN-Kubernetes による内部使用のために別の IP アドレス範囲を指定できます。IP アドレス範囲が、OpenShift Container Platform インストールで使用される他のサブネットと重複しないようにする必要があります。IP アドレス範囲は、クラスターに追加できるノードの最大数より大きくする必要があります。

このフィールドは、インストール後に変更できません。

デフォルト値は fd98::/48 です。

表3.4 policyAuditConfig オブジェクト
フィールド説明

rateLimit

integer

ノードごとに毎秒生成されるメッセージの最大数。デフォルト値は、1 秒あたり 20 メッセージです。

maxFileSize

integer

監査ログの最大サイズ (バイト単位)。デフォルト値は 50000000 (50MB) です。

maxLogFiles

integer

保持されるログファイルの最大数。

比較先

string

以下の追加の監査ログターゲットのいずれかになります。

libc
ホスト上の journald プロセスの libc syslog() 関数。
udp:<host>:<port>
syslog サーバー。<host>:<port> を syslog サーバーのホストおよびポートに置き換えます。
unix:<file>
<file> で指定された Unix ドメインソケットファイル。
null
監査ログを追加のターゲットに送信しないでください。

syslogFacility

string

RFC5424 で定義される kern などの syslog ファシリティー。デフォルト値は local0 です。

表3.5 gatewayConfig オブジェクト
フィールド説明

routingViaHost

boolean

Pod からホストネットワークスタックへの Egress トラフィックを送信するには、このフィールドを true に設定します。インストールおよびアプリケーションがカーネルルーティングテーブルに手動設定されたルートに依存するなど非常に特化されている場合には、Egress トラフィックをホストネットワークスタックにルーティングすることを推奨します。デフォルトでは、Egress トラフィックは OVN で処理され、クラスターを終了するために処理され、トラフィックはカーネルルーティングテーブルの特殊なルートによる影響を受けません。デフォルト値は false です。

このフィールドで、Open vSwitch ハードウェアオフロード機能との対話が可能になりました。このフィールドをtrueに設定すると、Egress トラフィックがホストネットワークスタックで処理されるため、パフォーマンス的に、オフロードによる利点は得られません。

ipForwarding

object

Network リソースの ipForwarding 仕様を使用して、OVN-Kubernetes マネージドインターフェイス上のすべてのトラフィックの IP フォワーディングを制御できます。Kubernetes 関連のトラフィックの IP フォワーディングのみを許可するには、Restricted を指定します。すべての IP トラフィックの転送を許可するには、Global を指定します。新規インストールの場合、デフォルトは Restricted です。OpenShift Container Platform 4.14 以降に更新する場合、デフォルトは Global です。

表3.6 ipsecConfig オブジェクト
フィールド説明

mode

string

IPsec 実装の動作を指定します。次の値のいずれかである必要があります。

  • Disabled: クラスターノードで IPsec が有効になりません。
  • External: 外部ホストとのネットワークトラフィックに対して IPsec が有効になります。
  • Full: Pod トラフィックおよび外部ホストとのネットワークトラフィックに対して IPsec が有効になります。

IPsec が有効な OVN-Kubernetes 設定の例

Copy to Clipboard Toggle word wrap
defaultNetwork:
  type: OVNKubernetes
  ovnKubernetesConfig:
    mtu: 1400
    genevePort: 6081
      ipsecConfig:
        mode: Full

重要

OVNKubernetes を使用すると、IBM Power® でスタック枯渇の問題が発生する可能性があります。

kubeProxyConfig オブジェクト設定 (OpenShiftSDN コンテナーネットワークインターフェイスのみ)

kubeProxyConfig オブジェクトの値は以下の表で定義されます。

表3.7 kubeProxyConfig オブジェクト
フィールド説明

iptablesSyncPeriod

string

iptables ルールの更新期間。デフォルト値は 30s です。有効な接尾辞には、sm、および h などが含まれ、これらについては、Go time パッケージ ドキュメントで説明されています。

注記

OpenShift Container Platform 4.3 以降で強化されたパフォーマンスの向上により、iptablesSyncPeriod パラメーターを調整する必要はなくなりました。

proxyArguments.iptables-min-sync-period

array

iptables ルールを更新する前の最小期間。このフィールドにより、更新の頻度が高くなり過ぎないようにできます。有効な接尾辞には、sm、および h などが含まれ、これらについては、Go time パッケージ で説明されています。デフォルト値:

Copy to Clipboard Toggle word wrap
kubeProxyConfig:
  proxyArguments:
    iptables-min-sync-period:
    - 0s

3.5.7. 高度なネットワーク設定の指定

ネットワークプラグインに高度なネットワーク設定を使用し、クラスターを既存のネットワーク環境に統合することができます。高度なネットワーク設定は、クラスターのインストール前にのみ指定することができます。

重要

インストールプロブラムで作成される OpenShift Container Platform マニフェストファイルを変更してネットワーク設定をカスタマイズすることは、サポートされていません。以下の手順のように、作成するマニフェストファイルを適用することがサポートされています。

前提条件

  • install-config.yaml ファイルを作成し、これに対する変更を完了している。

手順

  1. インストールプログラムが含まれるディレクトリーに切り替え、マニフェストを作成します。

    Copy to Clipboard Toggle word wrap
    $ ./openshift-install create manifests --dir <installation_directory> 
    1
    1
    <installation_directory> は、クラスターの install-config.yaml ファイルが含まれるディレクトリーの名前を指定します。
  2. cluster-network-03-config.yml という名前の、高度なネットワーク設定用のスタブマニフェストファイルを <installation_directory>/manifests/ ディレクトリーに作成します。

    Copy to Clipboard Toggle word wrap
    apiVersion: operator.openshift.io/v1
    kind: Network
    metadata:
      name: cluster
    spec:
  3. 次の例のように、cluster-network-03-config.yml ファイルでクラスターの高度なネットワーク設定を指定します。

    OVN-Kubernetes ネットワークプロバイダーの IPsec を有効にする

    Copy to Clipboard Toggle word wrap
    apiVersion: operator.openshift.io/v1
    kind: Network
    metadata:
      name: cluster
    spec:
      defaultNetwork:
        ovnKubernetesConfig:
          ipsecConfig:
            mode: Full

  4. オプション: 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 ネットワークのカスタマイズの設定に関するインストールドキュメントを参照してください。

手順

  1. インストールプログラムが含まれるディレクトリーに切り替え、マニフェストを作成します。

    Copy to Clipboard Toggle word wrap
    $ ./openshift-install create manifests --dir <installation_directory>

    ここでは、以下のようになります。

    <installation_directory>
    クラスターの install-config.yaml ファイルが含まれるディレクトリーの名前を指定します。
  2. cluster-network-03-config.yml という名前の、高度なネットワーク設定用のスタブマニフェストファイルを <installation_directory>/manifests/ ディレクトリーに作成します。

    Copy to Clipboard Toggle word wrap
    $ 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/ ディレクトリーが含まれるディレクトリー名を指定します。
  3. cluster-network-03-config.yml ファイルをエディターで開き、以下の例のようにハイブリッドネットワークで OVN-Kubernetes を設定します。

    ハイブリッドネットワーク設定の指定

    Copy to Clipboard Toggle word wrap
    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 値を持つクラスターではサポートされません。

  4. cluster-network-03-config.yml ファイルを保存し、テキストエディターを終了します。
  5. オプション: manifests/cluster-network-03-config.yml ファイルをバックアップします。インストールプログラムは、クラスターの作成時に manifests/ ディレクトリーを削除します。

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

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

重要

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

前提条件

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

手順

  • インストールプログラムが含まれるディレクトリーに切り替え、クラスターのデプロイメントを初期化します。

    Copy to Clipboard Toggle word wrap
    $ ./openshift-install create cluster --dir <installation_directory> \ 
    1
    
        --log-level=info 
    2
    1
    <installation_directory> については、カスタマイズした ./install-config.yaml ファイルの場所を指定します。
    2
    異なるインストールの詳細情報を表示するには、info ではなく、warndebug、または error を指定します。

検証

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

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

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

出力例

Copy to Clipboard Toggle word wrap
...
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 にインストールできます。

手順

  1. Red Hat カスタマーポータルの OpenShift Container Platform ダウンロードページ に移動します。
  2. Product Variant ドロップダウンリストからアーキテクチャーを選択します。
  3. バージョン ドロップダウンリストから適切なバージョンを選択します。
  4. OpenShift v4.15 Linux Client エントリーの横にある Download Now をクリックして、ファイルを保存します。
  5. アーカイブを展開します。

    Copy to Clipboard Toggle word wrap
    $ tar xvf <file>
  6. oc バイナリーを、PATH にあるディレクトリーに配置します。

    PATH を確認するには、以下のコマンドを実行します。

    Copy to Clipboard Toggle word wrap
    $ echo $PATH

検証

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

    Copy to Clipboard Toggle word wrap
    $ oc <command>
Windows への OpenShift CLI のインストール

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

手順

  1. Red Hat カスタマーポータルの OpenShift Container Platform ダウンロードページ に移動します。
  2. バージョン ドロップダウンリストから適切なバージョンを選択します。
  3. OpenShift v4.15 Windows Client エントリーの横にある Download Now をクリックして、ファイルを保存します。
  4. ZIP プログラムでアーカイブを展開します。
  5. oc バイナリーを、PATH にあるディレクトリーに移動します。

    PATH を確認するには、コマンドプロンプトを開いて以下のコマンドを実行します。

    Copy to Clipboard Toggle word wrap
    C:\> path

検証

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

    Copy to Clipboard Toggle word wrap
    C:\> oc <command>
macOS への OpenShift CLI のインストール

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

手順

  1. Red Hat カスタマーポータルの OpenShift Container Platform ダウンロードページ に移動します。
  2. バージョン ドロップダウンリストから適切なバージョンを選択します。
  3. OpenShift v4.15 macOS Client エントリーの横にある Download Now をクリックして、ファイルを保存します。

    注記

    macOS arm64 の場合は、OpenShift v4.15 macOS arm64 Client エントリーを選択します。

  4. アーカイブを展開し、解凍します。
  5. oc バイナリーをパスにあるディレクトリーに移動します。

    PATH を確認するには、ターミナルを開き、以下のコマンドを実行します。

    Copy to Clipboard Toggle word wrap
    $ echo $PATH

検証

  • oc コマンドを使用してインストールを確認します。

    Copy to Clipboard Toggle word wrap
    $ oc <command>

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

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

前提条件

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

手順

  1. kubeadmin 認証情報をエクスポートします。

    Copy to Clipboard Toggle word wrap
    $ export KUBECONFIG=<installation_directory>/auth/kubeconfig 
    1
    1
    <installation_directory> には、インストールファイルを保存したディレクトリーへのパスを指定します。
  2. エクスポートされた設定を使用して、oc コマンドを正常に実行できることを確認します。

    Copy to Clipboard Toggle word wrap
    $ oc whoami

    出力例

    Copy to Clipboard Toggle word wrap
    system:admin

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

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

前提条件

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

手順

  1. インストールホストで kubeadmin-password ファイルから kubeadmin ユーザーのパスワードを取得します。

    Copy to Clipboard Toggle word wrap
    $ cat <installation_directory>/auth/kubeadmin-password
    注記

    または、インストールホストで <installation_directory>/.openshift_install.log ログファイルから kubeadmin パスワードを取得できます。

  2. OpenShift Container Platform Web コンソールルートをリスト表示します。

    Copy to Clipboard Toggle word wrap
    $ oc get routes -n openshift-console | grep 'console-openshift'
    注記

    または、インストールホストで <installation_directory>/.openshift_install.log ログファイルからで OpenShift Container Platform ルートを取得できます。

    出力例

    Copy to Clipboard Toggle word wrap
    console     console-openshift-console.apps.<cluster_name>.<base_domain>            console     https   reencrypt/Redirect   None

  3. 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 サブスクリプションを追跡します。

関連情報

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. 前提条件

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

手順

  1. クラスターノードへの認証に使用するローカルマシンに既存の SSH キーペアがない場合は、これを作成します。たとえば、Linux オペレーティングシステムを使用するコンピューターで以下のコマンドを実行します。

    Copy to Clipboard Toggle word wrap
    $ ssh-keygen -t ed25519 -N '' -f <path>/<file_name> 
    1
    1
    新しい SSH キーのパスとファイル名 (~/.ssh/id_ed25519 など) を指定します。既存のキーペアがある場合は、公開鍵が ~/.ssh ディレクトリーにあることを確認します。
    注記

    x86_64ppc64le、および s390x アーキテクチャーのみで FIPS 140-2/140-3 検証のために NIST に提出された RHEL 暗号化ライブラリーを使用する OpenShift Container Platform クラスターをインストールする予定がある場合は、ed25519 アルゴリズムを使用するキーを作成しないでください。代わりに、rsa アルゴリズムまたは ecdsa アルゴリズムを使用するキーを作成します。

  2. 公開 SSH キーを表示します。

    Copy to Clipboard Toggle word wrap
    $ cat <path>/<file_name>.pub

    たとえば、次のコマンドを実行して ~/.ssh/id_ed25519.pub 公開鍵を表示します。

    Copy to Clipboard Toggle word wrap
    $ cat ~/.ssh/id_ed25519.pub
  3. ローカルユーザーの SSH エージェントに SSH 秘密鍵 ID が追加されていない場合は、それを追加します。キーの SSH エージェント管理は、クラスターノードへのパスワードなしの SSH 認証、または ./openshift-install gather コマンドを使用する場合は必要になります。

    注記

    一部のディストリビューションでは、~/.ssh/id_rsa および ~/.ssh/id_dsa などのデフォルトの SSH 秘密鍵のアイデンティティーは自動的に管理されます。

    1. ssh-agent プロセスがローカルユーザーに対して実行されていない場合は、バックグラウンドタスクとして開始します。

      Copy to Clipboard Toggle word wrap
      $ eval "$(ssh-agent -s)"

      出力例

      Copy to Clipboard Toggle word wrap
      Agent pid 31874

      注記

      クラスターが FIPS モードにある場合は、FIPS 準拠のアルゴリズムのみを使用して SSH キーを生成します。鍵は RSA または ECDSA のいずれかである必要があります。

  4. SSH プライベートキーを ssh-agent に追加します。

    Copy to Clipboard Toggle word wrap
    $ ssh-add <path>/<file_name> 
    1
    1
    ~/.ssh/id_ed25519 などの、SSH プライベートキーのパスおよびファイル名を指定します。

    出力例

    Copy to Clipboard Toggle word wrap
    Identity added: /home/<you>/<path>/<file_name> (<computer_name>)

次のステップ

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

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

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

前提条件

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

手順

  1. OpenShift Cluster Manager サイトの インフラストラクチャープロバイダー ページにアクセスします。Red Hat アカウントがある場合は、認証情報を使用してログインします。アカウントがない場合はこれを作成します。
  2. インフラストラクチャープロバイダーを選択します。
  3. インストールタイプのページに移動し、ホストオペレーティングシステムとアーキテクチャーに対応するインストールプログラムをダウンロードして、インストール設定ファイルを保存するディレクトリーにファイルを配置します。

    重要

    インストールプログラムは、クラスターのインストールに使用するコンピューターにいくつかのファイルを作成します。クラスターのインストール完了後は、インストールプログラムおよびインストールプログラムが作成するファイルを保持する必要があります。ファイルはいずれもクラスターを削除するために必要になります。

    重要

    インストールプログラムで作成されたファイルを削除しても、クラスターがインストール時に失敗した場合でもクラスターは削除されません。クラスターを削除するには、特定のクラウドプロバイダー用の OpenShift Container Platform のアンインストール手順を実行します。

  4. インストールプログラムを展開します。たとえば、Linux オペレーティングシステムを使用するコンピューターで以下のコマンドを実行します。

    Copy to Clipboard Toggle word wrap
    $ tar -xvf openshift-install-linux.tar.gz
  5. Red Hat OpenShift Cluster Manager からインストールプルシークレット をダウンロードします。このプルシークレットを使用し、OpenShift Container Platform コンポーネントのコンテナーイメージを提供する Quay.io など、組み込まれた各種の認証局によって提供されるサービスで認証できます。
3.6.5.1. インストール設定ファイルの作成

Alibaba Cloud にインストールする OpenShift Container Platform クラスターをカスタマイズできます。

前提条件

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

手順

  1. install-config.yaml ファイルを作成します。

    1. インストールプログラムが含まれるディレクトリーに切り替え、以下のコマンドを実行します。

      Copy to Clipboard Toggle word wrap
      $ ./openshift-install create install-config --dir <installation_directory> 
      1
      1
      <installation_directory> の場合、インストールプログラムが作成するファイルを保存するためにディレクトリー名を指定します。

      ディレクトリーを指定する場合:

      • ディレクトリーに execute 権限があることを確認します。この権限は、インストールディレクトリーで Terraform バイナリーを実行するために必要です。
      • 空のディレクトリーを使用します。ブートストラップ X.509 証明書などの一部のインストールアセットは有効期限が短いため、インストールディレクトリーを再利用しないでください。別のクラスターインストールの個別のファイルを再利用する必要がある場合は、それらをディレクトリーにコピーすることができます。ただし、インストールアセットのファイル名はリリース間で変更される可能性があります。インストールファイルを以前のバージョンの OpenShift Container Platform からコピーする場合は注意してコピーを行ってください。
    2. プロンプト時に、クラウドの設定の詳細情報を指定します。

      1. オプション: クラスターマシンにアクセスするために使用する SSH キーを選択します。

        注記

        インストールのデバッグまたは障害復旧を実行する必要のある実稼働用の OpenShift Container Platform クラスターでは、ssh-agent プロセスが使用する SSH キーを指定します。

      2. ターゲットとするプラットフォームとして alibabacloud を選択します。
      3. クラスターをデプロイするリージョンを選択します。
      4. クラスターをデプロイするベースドメインを選択します。ベースドメインは、クラスターに作成したパブリック DNS ゾーンに対応します。
      5. クラスターの記述名を指定します。
  2. クラスターを Alibaba Cloud にインストールするには、Cloud Credential Operator (CCO) が手動モードで動作する必要があります。install-config.yaml ファイルを変更して、credentialsMode パラメーターを Manual に設定します。

    credentialsModeManual に設定された install-config.yaml 設定ファイルの例

    Copy to Clipboard Toggle word wrap
    apiVersion: v1
    baseDomain: cluster1.example.com
    credentialsMode: Manual 
    1
    
    compute:
    - architecture: amd64
      hyperthreading: Enabled
     ...

    1
    この行を追加して、 credentialsModeManual に設定します。
  3. install-config.yaml ファイルを変更します。利用可能なパラメーターの詳細は、「インストール設定パラメーター」のセクションを参照してください。
  4. install-config.yaml ファイルをバックアップし、複数のクラスターをインストールするのに使用できるようにします。

    重要

    install-config.yaml ファイルはインストールプロセス時に使用されます。このファイルを再利用する必要がある場合は、この段階でこれをバックアップしてください。

3.6.5.2. Alibaba Cloud 用にカスタマイズされた install-config.yaml ファイルのサンプル

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

Copy to Clipboard Toggle word wrap
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 
1

 networking:
  clusterNetwork:
  - cidr: 10.128.0.0/14
    hostPrefix: 23
  machineNetwork:
  - cidr: 10.0.0.0/16
  networkType: OVNKubernetes 
2

  serviceNetwork:
  - 172.30.0.0/16
platform:
  alibabacloud:
    defaultMachinePlatform: 
3

      instanceType: ecs.g6.xlarge
      systemDiskCategory: cloud_efficiency
      systemDiskSize: 200
    region: ap-southeast-1 
4

    resourceGroupID: rg-acfnw6j3hyai 
5

    vpcID: vpc-0xifdjerdibmaqvtjob2b 
6

    vswitchIDs: 
7

    - vsw-0xi8ycgwc8wv5rhviwdq5
    - vsw-0xiy6v3z2tedv009b4pz2
publish: External
pullSecret: '{"auths": {"cloud.openshift.com": {"auth": ... }' 
8

sshKey: |
  ssh-rsa AAAA... 
9
1
必須。インストールプログラムにより、クラスター名の入力を求められます。
2
インストールするクラスターネットワークプラグイン。サポートされる値はデフォルト値の OVNKubernetes のみです。
3
オプション: 独自のプラットフォーム設定を定義しないマシンプールのパラメーターを指定します。
4
必須。インストールプログラムにより、クラスターをデプロイするリージョンの入力を求められます。
5
オプション。クラスターをインストールする必要がある既存のリソースグループを指定します。
8
必須。インストールプログラムは、プルシークレットの入力を求めます。
9
オプション。インストールプログラムは、クラスター内のマシンへのアクセスに使用する SSH キー値の入力を求めます。
6 7
オプション。これらは vswitchID 値の例です。
3.6.5.3. 必要なインストールマニフェストの生成

クラスターがマシンを設定するために必要な Kubernetes マニフェストと Ignition 設定ファイルを生成する必要があります。

手順

  1. インストールプログラムが含まれているディレクトリーから次のコマンドを実行して、マニフェストを生成します。

    Copy to Clipboard Toggle word wrap
    $ 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) がインストールされている。

手順

  1. 次のコマンドを実行して、OpenShift Container Platform リリースイメージの変数を設定します。

    Copy to Clipboard Toggle word wrap
    $ RELEASE_IMAGE=$(./openshift-install version | awk '/release image/ {print $3}')
  2. 以下のコマンドを実行して、OpenShift Container Platform リリースイメージから CCO コンテナーイメージを取得します。

    Copy to Clipboard Toggle word wrap
    $ CCO_IMAGE=$(oc adm release info --image-for='cloud-credential-operator' $RELEASE_IMAGE -a ~/.pull-secret)
    注記

    $RELEASE_IMAGE のアーキテクチャーが、ccoctlツールを使用する環境のアーキテクチャーと一致していることを確認してください。

  3. 以下のコマンドを実行して、OpenShift Container Platform リリースイメージ内の CCO コンテナーイメージから ccoctl バイナリーを抽出します。

    Copy to Clipboard Toggle word wrap
    $ oc image extract $CCO_IMAGE --file="/usr/bin/ccoctl" -a ~/.pull-secret
  4. 次のコマンドを実行して、権限を変更して ccoctl を実行可能にします。

    Copy to Clipboard Toggle word wrap
    $ chmod 775 ccoctl

検証

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

    Copy to Clipboard Toggle word wrap
    $ ./ccoctl.rhel9

    出力例

    Copy to Clipboard Toggle word wrap
    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 ファイル に追加しました。

手順

  1. 次のコマンドを実行して、インストールファイルのリリースイメージを $RELEASE_IMAGE 変数に設定します。

    Copy to Clipboard Toggle word wrap
    $ RELEASE_IMAGE=$(./openshift-install version | awk '/release image/ {print $3}')
  2. 以下のコマンドを実行して、OpenShift Container Platform リリースイメージから CredentialsRequest オブジェクトのリストを抽出します。

    Copy to Clipboard Toggle word wrap
    $ oc adm release extract \
      --from=$RELEASE_IMAGE \
      --credentials-requests \
      --included \
    1
    
      --install-config=<path_to_directory_with_installation_configuration>/install-config.yaml \
    2
    
      --to=<path_to_directory_for_credentials_requests> 
    3
    1
    --included パラメーターには、特定のクラスター設定に必要なマニフェストのみが含まれます。
    2
    install-config.yaml ファイルの場所を指定します。
    3
    CredentialsRequest オブジェクトを保存するディレクトリーへのパスを指定します。指定したディレクトリーが存在しない場合は、このコマンドによって作成されます。
    注記

    このコマンドの実行には少し時間がかかる場合があります。

  3. 次のコマンドを実行し、ccoctl ツールを使用して CredentialsRequest オブジェクトをすべて処理します。

    1. ツールを使用するには、次のコマンドを実行します。

      Copy to Clipboard Toggle word wrap
      $ 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
      1
      追跡用に作成されたクラウドリソースにタグを付けるために使用される名前です。
      2
      クラウドリソースが作成される Alibaba Cloud リージョンを指定します。
      3
      コンポーネント CredentialsRequest オブジェクトのファイルを含むディレクトリーを指定します。
      4
      生成されたコンポーネント認証情報シークレットが配置されるディレクトリーを指定します。
      注記

      クラスターで TechPreviewNoUpgrade 機能セットによって有効化されたテクノロジープレビュー機能を使用している場合は、--enable-tech-preview パラメーターを含める必要があります。

      出力例

      Copy to Clipboard Toggle word wrap
      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 回以上実行すると、以前に生成されたマニフェストシークレットが古くなり、新しく生成されたシークレットを再適用する必要があります。

    2. OpenShift Container Platform シークレットが作成されていることを確認します。

      Copy to Clipboard Toggle word wrap
      $ ls <path_to_ccoctl_output_dir>/manifests

      出力例

      Copy to Clipboard Toggle word wrap
      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 のドキュメントを参照してください。

  4. 生成されたクレデンシャルファイルをターゲットマニフェストディレクトリーにコピーします。

    Copy to Clipboard Toggle word wrap
    $ 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 Toggle word wrap
    $ ./openshift-install create cluster --dir <installation_directory> \ 
    1
    
        --log-level=info 
    2
    1
    <installation_directory> については、カスタマイズした ./install-config.yaml ファイルの場所を指定します。
    2
    異なるインストールの詳細情報を表示するには、info ではなく、warndebug、または error を指定します。

検証

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

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

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

出力例

Copy to Clipboard Toggle word wrap
...
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 にインストールできます。

手順

  1. Red Hat カスタマーポータルの OpenShift Container Platform ダウンロードページ に移動します。
  2. Product Variant ドロップダウンリストからアーキテクチャーを選択します。
  3. バージョン ドロップダウンリストから適切なバージョンを選択します。
  4. OpenShift v4.15 Linux Client エントリーの横にある Download Now をクリックして、ファイルを保存します。
  5. アーカイブを展開します。

    Copy to Clipboard Toggle word wrap
    $ tar xvf <file>
  6. oc バイナリーを、PATH にあるディレクトリーに配置します。

    PATH を確認するには、以下のコマンドを実行します。

    Copy to Clipboard Toggle word wrap
    $ echo $PATH

検証

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

    Copy to Clipboard Toggle word wrap
    $ oc <command>
Windows への OpenShift CLI のインストール

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

手順

  1. Red Hat カスタマーポータルの OpenShift Container Platform ダウンロードページ に移動します。
  2. バージョン ドロップダウンリストから適切なバージョンを選択します。
  3. OpenShift v4.15 Windows Client エントリーの横にある Download Now をクリックして、ファイルを保存します。
  4. ZIP プログラムでアーカイブを展開します。
  5. oc バイナリーを、PATH にあるディレクトリーに移動します。

    PATH を確認するには、コマンドプロンプトを開いて以下のコマンドを実行します。

    Copy to Clipboard Toggle word wrap
    C:\> path

検証

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

    Copy to Clipboard Toggle word wrap
    C:\> oc <command>
macOS への OpenShift CLI のインストール

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

手順

  1. Red Hat カスタマーポータルの OpenShift Container Platform ダウンロードページ に移動します。
  2. バージョン ドロップダウンリストから適切なバージョンを選択します。
  3. OpenShift v4.15 macOS Client エントリーの横にある Download Now をクリックして、ファイルを保存します。

    注記

    macOS arm64 の場合は、OpenShift v4.15 macOS arm64 Client エントリーを選択します。

  4. アーカイブを展開し、解凍します。
  5. oc バイナリーをパスにあるディレクトリーに移動します。

    PATH を確認するには、ターミナルを開き、以下のコマンドを実行します。

    Copy to Clipboard Toggle word wrap
    $ echo $PATH

検証

  • oc コマンドを使用してインストールを確認します。

    Copy to Clipboard Toggle word wrap
    $ oc <command>

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

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

前提条件

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

手順

  1. kubeadmin 認証情報をエクスポートします。

    Copy to Clipboard Toggle word wrap
    $ export KUBECONFIG=<installation_directory>/auth/kubeconfig 
    1
    1
    <installation_directory> には、インストールファイルを保存したディレクトリーへのパスを指定します。
  2. エクスポートされた設定を使用して、oc コマンドを正常に実行できることを確認します。

    Copy to Clipboard Toggle word wrap
    $ oc whoami

    出力例

    Copy to Clipboard Toggle word wrap
    system:admin

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

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

前提条件

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

手順

  1. インストールホストで kubeadmin-password ファイルから kubeadmin ユーザーのパスワードを取得します。

    Copy to Clipboard Toggle word wrap
    $ cat <installation_directory>/auth/kubeadmin-password
    注記

    または、インストールホストで <installation_directory>/.openshift_install.log ログファイルから kubeadmin パスワードを取得できます。

  2. OpenShift Container Platform Web コンソールルートをリスト表示します。

    Copy to Clipboard Toggle word wrap
    $ oc get routes -n openshift-console | grep 'console-openshift'
    注記

    または、インストールホストで <installation_directory>/.openshift_install.log ログファイルからで OpenShift Container Platform ルートを取得できます。

    出力例

    Copy to Clipboard Toggle word wrap
    console     console-openshift-console.apps.<cluster_name>.<base_domain>            console     https   reencrypt/Redirect   None

  3. 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 サブスクリプションを追跡します。

関連情報

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. 必須設定パラメーター

必須のインストール設定パラメーターは、以下の表で説明されています。

表3.8 必須パラメーター
パラメーター説明
Copy to Clipboard Toggle word wrap
apiVersion:

install-config.yaml コンテンツの API バージョン。現在のバージョンは v1 です。インストールプログラムは、古い API バージョンもサポートしている場合があります。

文字列

Copy to Clipboard Toggle word wrap
baseDomain:

クラウドプロバイダーのベースドメイン。ベースドメインは、OpenShift Container Platform クラスターコンポーネントへのルートを作成するために使用されます。クラスターの完全な DNS 名は、baseDomain<metadata.name>.<baseDomain> 形式を使用する metadata.name パラメーターの値の組み合わせです。

example.com などの完全修飾ドメインまたはサブドメイン名。

Copy to Clipboard Toggle word wrap
metadata:

Kubernetes リソース ObjectMeta。ここからは name パラメーターのみが消費されます。

オブジェクト

Copy to Clipboard Toggle word wrap
metadata:
  name:

クラスターの名前。クラスターの DNS レコードはすべて {{.metadata.name}}.{{.baseDomain}} のサブドメインです。

dev などの小文字、ハイフン (-)、およびピリオド (.) が含まれる文字列。

Copy to Clipboard Toggle word wrap
platform:

インストールを実行する特定のプラットフォームの設定: alibabacloudawsbaremetalazuregcpibmcloudnutanixopenstackpowervsvsphere、または {}platform.<platform> パラメーターに関する追加情報は、以下の表で特定のプラットフォームを参照してください。

オブジェクト

Copy to Clipboard Toggle word wrap
pullSecret:

Red Hat OpenShift Cluster Manager からプルシークレット を取得して、Quay.io などのサービスから OpenShift Container Platform コンポーネントのコンテナーイメージをダウンロードすることを認証します。

Copy to Clipboard Toggle word wrap
{
   "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 アドレスを使用するようにしてください。

表3.9 ネットワークパラメーター
パラメーター説明
Copy to Clipboard Toggle word wrap
networking:

クラスターのネットワークの設定。

オブジェクト

注記

インストール後に networking オブジェクトで指定したパラメーターを変更することはできません。

Copy to Clipboard Toggle word wrap
networking:
  networkType:

インストールする Red Hat OpenShift Networking ネットワークプラグイン。

OVNKubernetesOVNKubernetes は、Linux ネットワークと、Linux サーバーと Windows サーバーの両方を含む Linux ネットワークおよびハイブリッドネットワーク用の CNI プラグインです。デフォルトの値は OVNKubernetes です。

Copy to Clipboard Toggle word wrap
networking:
  clusterNetwork:

Pod の IP アドレスブロック。

デフォルト値は 10.128.0.0/14 で、ホストの接頭辞は /23 です。

複数の IP アドレスブロックを指定する場合は、ブロックが重複しないようにしてください。

オブジェクトの配列。以下に例を示します。

Copy to Clipboard Toggle word wrap
networking:
  clusterNetwork:
  - cidr: 10.128.0.0/14
    hostPrefix: 23
Copy to Clipboard Toggle word wrap
networking:
  clusterNetwork:
    cidr:

networking.clusterNetwork を使用する場合に必須です。IP アドレスブロック。

IPv4 ネットワーク

CIDR (Classless Inter-Domain Routing) 表記の IP アドレスブロック。IPv4 ブロックの接頭辞長は 0 から 32 の間になります。

Copy to Clipboard Toggle word wrap
networking:
  clusterNetwork:
    hostPrefix:

それぞれの個別ノードに割り当てるサブネット接頭辞長。たとえば、hostPrefix23 に設定される場合、各ノードに指定の cidr から /23 サブネットが割り当てられます。hostPrefix 値の 23 は、510 (2^(32 - 23) - 2) Pod IP アドレスを提供します。

サブネット接頭辞。

デフォルト値は 23 です。

Copy to Clipboard Toggle word wrap
networking:
  serviceNetwork:

サービスの IP アドレスブロック。デフォルト値は 172.30.0.0/16 です。

OVN-Kubernetes ネットワークプラグインは、サービスネットワークに対して単一の IP アドレスブロックのみをサポートします。

CIDR 形式の IP アドレスブロックを持つ配列。以下に例を示します。

Copy to Clipboard Toggle word wrap
networking:
  serviceNetwork:
   - 172.30.0.0/16
Copy to Clipboard Toggle word wrap
networking:
  machineNetwork:

マシンの IP アドレスブロック。

複数の IP アドレスブロックを指定する場合は、ブロックが重複しないようにしてください。

オブジェクトの配列。以下に例を示します。

Copy to Clipboard Toggle word wrap
networking:
  machineNetwork:
  - cidr: 10.0.0.0/16
Copy to Clipboard Toggle word wrap
networking:
  machineNetwork:
    cidr:

networking.machineNetwork を使用する場合に必須です。IP アドレスブロック。libvirt と IBM Power® Virtual Server を除くすべてのプラットフォームのデフォルト値は 10.0.0.0/16 です。libvirt の場合、デフォルト値は 192.168.126.0/24 です。IBM Power® Virtual Server の場合、デフォルト値は 192.168.0.0/24 です。

CIDR 表記の IP ネットワークブロック。

例: 10.0.0.0/16

注記

優先される NIC が置かれている CIDR に一致する networking.machineNetwork を設定します。

3.7.1.3. オプションの設定パラメーター

オプションのインストール設定パラメーターは、以下の表で説明されています。

表3.10 オプションのパラメーター
パラメーター説明
Copy to Clipboard Toggle word wrap
additionalTrustBundle:

ノードの信頼済み証明書ストアに追加される PEM でエンコードされた X.509 証明書バンドル。この信頼バンドルは、プロキシーが設定される際にも使用できます。

文字列

Copy to Clipboard Toggle word wrap
capabilities:

オプションのコアクラスターコンポーネントのインストールを制御します。オプションのコンポーネントを無効にすることで、OpenShift Container Platform クラスターのフットプリントを削減できます。詳細は、インストール の「クラスター機能ページ」を参照してください。

文字列配列

Copy to Clipboard Toggle word wrap
capabilities:
  baselineCapabilitySet:

有効にするオプション機能の初期セットを選択します。有効な値は Nonev4.11v4.12vCurrent です。デフォルト値は vCurrent です。

文字列

Copy to Clipboard Toggle word wrap
capabilities:
  additionalEnabledCapabilities:

オプションの機能のセットを、baselineCapabilitySet で指定したものを超えて拡張します。このパラメーターで複数の機能を指定できます。

文字列配列

Copy to Clipboard Toggle word wrap
cpuPartitioningMode:

ワークロードパーティション設定を使用して、OpenShift Container Platform サービス、クラスター管理ワークロード、およびインフラストラクチャー Pod を分離し、予約された CPU セットで実行できます。ワークロードパーティショニングはインストール中にのみ有効にすることができ、インストール後に無効にすることはできません。このフィールドはワークロードのパーティショニングを有効にしますが、特定の CPU を使用するようにワークロードを設定するわけではありません。詳細は、スケーラビリティとパフォーマンス セクションの ワークロードパーティショニング ページを参照してください。

None または AllNodes。デフォルト値は None です。

Copy to Clipboard Toggle word wrap
compute:

コンピュートノードを構成するマシンの設定。

MachinePool オブジェクトの配列。

Copy to Clipboard Toggle word wrap
compute:
  architecture:

プール内のマシンの命令セットアーキテクチャーを決定します。現在、さまざまなアーキテクチャーのクラスターはサポートされていません。すべてのプールは同じアーキテクチャーを指定する必要があります。有効な値は amd64 (デフォルト) です。

文字列

Copy to Clipboard Toggle word wrap
compute:
  hyperthreading:

コンピュートマシンで同時マルチスレッドまたは hyperthreading を有効/無効にするかどうか。デフォルトでは、同時スレッドはマシンのコアのパフォーマンスを上げるために有効にされます。

重要

同時スレッドを無効にする場合は、容量計画においてマシンパフォーマンスの大幅な低下が考慮に入れられていることを確認します。

Enabled または Disabled

Copy to Clipboard Toggle word wrap
compute:
  name:

compute を使用する場合に必須です。マシンプールの名前。

worker

Copy to Clipboard Toggle word wrap
compute:
  platform:

compute を使用する場合に必須です。このパラメーターを使用して、ワーカーマシンをホストするクラウドプロバイダーを指定します。このパラメーターの値は controlPlane.platform パラメーターの値に一致する必要があります。

alibabacloudawsazuregcpibmcloudnutanixopenstackpowervsvsphere、または {}

Copy to Clipboard Toggle word wrap
compute:
  replicas:

プロビジョニングするコンピュートマシン (ワーカーマシンとしても知られる) の数。

2 以上の正の整数。デフォルト値は 3 です。

Copy to Clipboard Toggle word wrap
featureSet:

機能セットのクラスターを有効にします。機能セットは、デフォルトで有効にされない OpenShift Container Platform 機能のコレクションです。インストール中に機能セットを有効にする方法の詳細は、「機能ゲートの使用による各種機能の有効化」を参照してください。

文字列。TechPreviewNoUpgrade など、有効にする機能セットの名前。

Copy to Clipboard Toggle word wrap
controlPlane:

コントロールプレーンを構成するマシンの設定。

MachinePool オブジェクトの配列。

Copy to Clipboard Toggle word wrap
controlPlane:
  architecture:

プール内のマシンの命令セットアーキテクチャーを決定します。現在、さまざまなアーキテクチャーのクラスターはサポートされていません。すべてのプールは同じアーキテクチャーを指定する必要があります。有効な値は amd64 (デフォルト) です。

文字列

Copy to Clipboard Toggle word wrap
controlPlane:
  hyperthreading:

コントロールプレーンマシンで同時マルチスレッドまたは hyperthreading を有効/無効にするかどうか。デフォルトでは、同時スレッドはマシンのコアのパフォーマンスを上げるために有効にされます。

重要

同時スレッドを無効にする場合は、容量計画においてマシンパフォーマンスの大幅な低下が考慮に入れられていることを確認します。

Enabled または Disabled

Copy to Clipboard Toggle word wrap
controlPlane:
  name:

controlPlane を使用する場合に必須です。マシンプールの名前。

master

Copy to Clipboard Toggle word wrap
controlPlane:
  platform:

controlPlane を使用する場合に必須です。このパラメーターを使用して、コントロールプレーンマシンをホストするクラウドプロバイダーを指定します。このパラメーターの値は compute.platform パラメーターの値に一致する必要があります。

alibabacloudawsazuregcpibmcloudnutanixopenstackpowervsvsphere、または {}

Copy to Clipboard Toggle word wrap
controlPlane:
  replicas:

プロビジョニングするコントロールプレーンマシンの数。

サポートされる値は 3、シングルノード OpenShift をデプロイする場合は 1 です。

Copy to Clipboard Toggle word wrap
credentialsMode:

Cloud Credential Operator (CCO) モード。モードを指定しないと、CCO は指定された認証情報の機能を動的に判別しようとします。この場合、複数のモードがサポートされるプラットフォームで Mint モードが優先されます。

MintPassthroughManual、または空の文字列 ("")。[1]

Copy to Clipboard Toggle word wrap
fips:

FIPS モードを有効または無効にします。デフォルトは false (無効) です。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 暗号化ライブラリーを使用します。

注記

Azure File ストレージを使用している場合、FIPS モードを有効にすることはできません。

false または true

Copy to Clipboard Toggle word wrap
imageContentSources:

release-image コンテンツのソースおよびリポジトリー。

オブジェクトの配列。この表の以下の行で説明されているように、source およびオプションで mirrors が含まれます。

Copy to Clipboard Toggle word wrap
imageContentSources:
  source:

imageContentSources を使用する場合に必須です。ユーザーが参照するリポジトリーを指定します (例: イメージプル仕様)。

文字列

Copy to Clipboard Toggle word wrap
imageContentSources:
  mirrors:

同じイメージが含まれる可能性のあるリポジトリーを 1 つ以上指定します。

文字列の配列。

Copy to Clipboard Toggle word wrap
publish:

Kubernetes API、OpenShift ルートなどのクラスターのユーザーに表示されるエンドポイントをパブリッシュまたは公開する方法。

Internal または External。デフォルト値は External です。

このパラメーターを Internal に設定することは、クラウド以外のプラットフォームではサポートされません。

重要

フィールドの値が Internal に設定されている場合、クラスターは機能しなくなります。詳細は、BZ#1953035 を参照してください。

Copy to Clipboard Toggle word wrap
sshKey:

クラスターマシンへのアクセスを認証するための SSH キー。

注記

インストールのデバッグまたは障害復旧を実行する必要のある実稼働用の OpenShift Container Platform クラスターでは、ssh-agent プロセスが使用する SSH キーを指定します。

たとえば、sshKey: ssh-ed25519 AAAA.. です。

  1. すべてのクラウドプロバイダーですべての 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 設定をそれぞれ上書きします。

表3.11 オプションの Alibaba Cloud パラメーター
パラメーター説明
Copy to Clipboard Toggle word wrap
compute:
  platform:
    alibabacloud:
      imageID:

ECS インスタンスの作成に使用される imageID。ImageID はクラスターと同じリージョンに属している必要があります。

文字列。

Copy to Clipboard Toggle word wrap
compute:
  platform:
    alibabacloud:
      instanceType:

InstanceType は、ECS インスタンスタイプを定義します。例: ecs.g6.large

文字列。

Copy to Clipboard Toggle word wrap
compute:
  platform:
    alibabacloud:
      systemDiskCategory:

システムディスクのカテゴリーを定義します。例: cloud_efficiencycloud_essd

文字列。

Copy to Clipboard Toggle word wrap
compute:
  platform:
    alibabacloud:
      systemDisksize:

システムディスクのサイズをギビバイト (GiB) 単位で定義します。

integer

Copy to Clipboard Toggle word wrap
compute:
  platform:
    alibabacloud:
      zones:

使用できるアベイラビリティーゾーンのリスト。例: cn-hangzhou-hcn-hangzhou-j

文字列リスト。

Copy to Clipboard Toggle word wrap
controlPlane:
  platform:
    alibabacloud:
      imageID:

ECS インスタンスの作成に使用される imageID。ImageID はクラスターと同じリージョンに属している必要があります。

文字列。

Copy to Clipboard Toggle word wrap
controlPlane:
  platform:
    alibabacloud:
      instanceType:

InstanceType は、ECS インスタンスタイプを定義します。例: ecs.g6.xlarge

文字列。

Copy to Clipboard Toggle word wrap
controlPlane:
  platform:
    alibabacloud:
      systemDiskCategory:

システムディスクのカテゴリーを定義します。例: cloud_efficiencycloud_essd

文字列。

Copy to Clipboard Toggle word wrap
controlPlane:
  platform:
    alibabacloud:
      systemDisksize:

システムディスクのサイズをギビバイト (GiB) 単位で定義します。

integer

Copy to Clipboard Toggle word wrap
controlPlane:
  platform:
    alibabacloud:
      zones:

使用できるアベイラビリティーゾーンのリスト。例: cn-hangzhou-hcn-hangzhou-j

文字列リスト。

Copy to Clipboard Toggle word wrap
platform:
  alibabacloud:
    region:

必須。クラスターが作成される Alibaba Cloud リージョン。

文字列。

Copy to Clipboard Toggle word wrap
platform:
  alibabacloud:
    resourceGroupID:

クラスターがインストールされる既存のリソースグループの ID。空の場合、インストールプログラムはクラスターの新しいリソースグループを作成します。

文字列。

Copy to Clipboard Toggle word wrap
platform:
  alibabacloud:
    tags:

クラスター用に作成されたすべての Alibaba Cloud リソースに適用する追加のキーと値。

オブジェクト。

Copy to Clipboard Toggle word wrap
platform:
  alibabacloud:
    vpcID:

クラスターをインストールする必要がある既存の VPC の ID。空の場合、インストールプログラムはクラスターの新規 VPC を作成します。

文字列。

Copy to Clipboard Toggle word wrap
platform:
  alibabacloud:
    vswitchIDs:

クラスターリソースが作成される既存の VSwitch の ID リスト。既存の VSwitch は、既存の VPC も使用している場合にのみ使用できます。空の場合、インストールプログラムはクラスターの新しい VSwitch を作成します。

文字列リスト。

Copy to Clipboard Toggle word wrap
platform:
  alibabacloud:
    defaultMachinePlatform:
      imageID:

コンピュートマシンとコントロールプレーンマシンの両方で、ECS インスタンスの作成に使用する必要があるイメージ ID。設定されている場合、イメージ ID はクラスターと同じリージョンに属している必要があります。

文字列。

Copy to Clipboard Toggle word wrap
platform:
  alibabacloud:
    defaultMachinePlatform:
      instanceType:

コンピュートマシンとコントロールプレーンマシンの両方で、ECS インスタンスの作成に使用される ECS インスタンスタイプ。例: ecs.g6.xlarge

文字列。

Copy to Clipboard Toggle word wrap
platform:
  alibabacloud:
    defaultMachinePlatform:
      systemDiskCategory:

コンピュートマシンとコントロールプレーンマシンの両方におけるシステムディスクのカテゴリー。例: cloud_efficiencycloud_essd

文字列、たとえば ""、cloud_efficiencycloud_essd

Copy to Clipboard Toggle word wrap
platform:
  alibabacloud:
    defaultMachinePlatform:
      systemDiskSize:

コンピュートマシンとコントロールプレーンマシンの両方で、ギビバイト (GiB) 単位のシステムディスクのサイズ。最小値は 120 です。

integer

Copy to Clipboard Toggle word wrap
platform:
  alibabacloud:
    defaultMachinePlatform:
      zones:

コンピュートマシンとコントロールプレーンマシンの両方で、使用可能なアベイラビリティーゾーンのリスト。例: cn-hangzhou-hcn-hangzhou-j

文字列リスト。

Copy to Clipboard Toggle word wrap
platform:
  alibabacloud:
    privateZoneID:

クラスターの内部 API の DNS レコードを追加する既存のプライベートゾーンの ID。既存のプライベートゾーンは、既存の VPC も使用している場合にのみ使用できます。プライベートゾーンは、サブネットを含む VPC に関連付ける必要があります。プライベートゾーンを未設定のままにして、インストールプログラムがプライベートゾーンを作成するようにします。

文字列。

3.8. Alibaba Cloud でのクラスターのアンインストール

Alibaba Cloud にデプロイしたクラスターを削除できます。

3.8.1. インストーラーでプロビジョニングされるインフラストラクチャーを使用するクラスターの削除

installer-provisioned infrastructure を使用するクラスターは、クラウドから削除できます。

注記

アンインストール後に、とくに user-provisioned infrastructure (UPI) クラスターで適切に削除されていないリソースがあるかどうかについて、クラウドプロバイダーを確認します。インストーラーが作成されなかったり、インストーラーがアクセスできない場合には、リソースがある可能性があります。

前提条件

  • クラスターをデプロイするために使用したインストールプログラムのコピーがあります。
  • クラスター作成時にインストールプログラムが生成したファイルがあります。

手順

  1. クラスターをインストールするために使用したコンピューターのインストールプログラムが含まれるディレクトリーから、以下のコマンドを実行します。

    Copy to Clipboard Toggle word wrap
    $ ./openshift-install destroy cluster \
    --dir <installation_directory> --log-level info 
    1
     
    2
    1
    <installation_directory> には、インストールファイルを保存したディレクトリーへのパスを指定します。
    2
    異なる詳細情報を表示するには、info ではなく、warndebug、または error を指定します。
    注記

    クラスターのクラスター定義ファイルが含まれるディレクトリーを指定する必要があります。クラスターを削除するには、インストールプログラムでこのディレクトリーにある metadata.json ファイルが必要になります。

  2. オプション: <installation_directory> ディレクトリーおよび OpenShift Container Platform インストールプログラムを削除します。

第4章 AWS へのインストール

4.1. AWS へのインストールの準備

4.1.1. 前提条件

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 解決および名前検索を提供します。

手順

  1. ドメイン、またはサブドメイン、およびレジストラーを特定します。既存のドメインおよびレジストラーを移行するか、AWS または他のソースから新規のものを取得できます。

    注記

    AWS で新規ドメインを購入する場合、関連する DNS の変更が伝播するのに時間がかかります。AWS 経由でドメインを購入する方法の詳細は、AWS ドキュメントの Registering Domain Names Using Amazon Route 53 を参照してください。

  2. 既存のドメインおよびレジストラーを使用している場合、その DNS を AWS に移行します。AWS ドキュメントの Making Amazon Route 53 the DNS Service for an Existing Domain を参照してください。
  3. ドメインまたはサブドメインのパブリックホストゾーンを作成します。AWS ドキュメントの Creating a Public Hosted Zone を参照してください。

    openshiftcorp.com などのルートドメインや、clusters.openshiftcorp.com などのサブドメインを使用します。

  4. ホストゾーンレコードから新規の権威ネームサーバーを抽出します。AWS ドキュメントの Getting the Name Servers for a Public Hosted Zone を参照してください。
  5. ドメインが使用する AWS Route 53 ネームサーバーのレジストラーレコードを更新します。たとえば、別のアカウントを使用してドメインを Route 53 サービスに登録している場合は、AWS ドキュメントの Adding or Changing Name Servers or Glue Records のトピックを参照してください。
  6. サブドメインを使用している場合は、その委任レコードを親ドメインに追加します。これにより、サブドメインの 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 設定の例

Copy to Clipboard Toggle word wrap
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 
1

    - name: tagging
      url: https://tagging.us-gov-west-1.amazonaws.com 
2

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 の制限説明

インスタンスの制限

変動あり。

変動あり。

デフォルトで、各クラスターは以下のインスタンスを作成します。

  • 1 つのブートストラップマシン。これはインストール後に削除されます。
  • 3 つのコントロールプレーンノード
  • 3 つのワーカーノード

これらのインスタンスタイプの数は、新規アカウントのデフォルト制限内の値です。追加のワーカーノードをデプロイし、自動スケーリングを有効にし、大規模なワークロードをデプロイするか、異なるインスタンスタイプを使用するには、アカウントの制限を見直し、クラスターが必要なマシンをデプロイできることを確認します。

ほとんどのリージョンでは、ワーカーマシンは m6i.large インスタンスを使用し、ブートストラップおよびコントロールプレーンマシンは m6i.xlarge インスタンスを使用します。これらのインスタンスタイプをサポートしないすべてのリージョンを含む一部のリージョンでは、m5.large および m5.xlarge インスタンスが代わりに使用されます。

Elastic IP (EIP)

0 - 1

アカウントごとに 5 つの EIP

クラスターを高可用性設定でプロビジョニングするために、インストールプログラムはそれぞれの リージョン内のアベイラビリティーゾーン にパブリックおよびプライベートのサブネットを作成します。各プライベートサブネットには NAT ゲートウェイ が必要であり、各 NAT ゲートウェイには別個の Elastic IP が必要です。AWS リージョンマップ を確認して、各リージョンにあるアベイラビリティーゾーンの数を判別します。デフォルトの高可用性を利用するには、少なくとも 3 つのアベイラビリティーゾーンがあるリージョンにクラスターをインストールします。アベイラビリティーゾーンが 6 つ以上あるリージョンにクラスターをインストールするには、EIP 制限を引き上げる必要があります。

重要

us-east-1 リージョンを使用するには、アカウントの EIP 制限を引き上げる必要があります。

Virtual Private Cloud (VPC)

5

リージョンごとに 5 つの VPC

各クラスターは独自の VPC を作成します。

Elastic Load Balancing (ELB/NLB)

3

リージョンごとに 20

デフォルトで、各クラスターは、マスター API サーバーの内部および外部のネットワークロードバランサーおよびルーターの単一の Classic Load Balancer を作成します。追加の Kubernetes Service オブジェクトをタイプ LoadBalancer を指定してデプロイすると、追加の ロードバランサー が作成されます。

NAT ゲートウェイ

5

アベイラビリティゾーンごとに 5 つ

クラスターは各アベイラビリティーゾーンに 1 つの NAT ゲートウェイをデプロイします。

Elastic Network Interface (ENI)

12 以上

リージョンごとに 350

デフォルトのインストールは 21 の ENI を作成し、リージョンの各アベイラビリティーゾーンに 1 つの ENI を作成します。たとえば、us-east-1 リージョンには 6 つのアベイラビリティーゾーンが含まれるため、そのゾーンにデプロイされるクラスターは 27 の ENI を使用します。AWS リージョンマップ を確認して、各リージョンにあるアベイラビリティーゾーンの数を判別します。

クラスターの使用量やデプロイされたワークロード別に作成された追加のマシンや 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:CreateAccessKeyiam: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 手順を実行する際に、以下のオプションを設定します。

手順

  1. IAM ユーザー名を指定し、Programmatic access を選択します。
  2. AdministratorAccess ポリシーを割り当て、アカウントにクラスターを作成するために十分なパーミッションがあることを確認します。このポリシーはクラスターに対し、各 OpenShift Container Platform コンポーネントに認証情報を付与する機能を提供します。クラスターはコンポーネントに対し、それらが必要とする認証情報のみを付与します。

    注記

    必要なすべての AWS パーミッションを付与し、これをユーザーに割り当てるポリシーを作成することは可能ですが、これは優先されるオプションではありません。クラスターには追加の認証情報を個別コンポーネントに付与する機能がないため、同じ認証情報がすべてのコンポーネントによって使用されます。

  3. オプション: タグを割り当て、メタデータをユーザーに追加します。
  4. 指定したユーザー名に AdministratorAccess ポリシーが付与されていることを確認します。
  5. アクセスキー 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 ファイルがある。

手順

  1. コンピュートマシンの既のロールを使用して compute.platform.aws.iamRole を更新します。

    コンピュートインスタンスの IAM ロールを含む install-config.yaml ファイルのサンプル

    Copy to Clipboard Toggle word wrap
    compute:
    - hyperthreading: Enabled
      name: worker
      platform:
        aws:
          iamRole: ExampleRole

  2. コントロールプレーンマシンの既存ロールを使用して controlPlane.platform.aws.iamRole を更新します。

    コントロールプレーンインスタンスの IAM ロールを含む install-config.yaml ファイルのサンプル

    Copy to Clipboard Toggle word wrap
    controlPlane:
      hyperthreading: Enabled
      name: master
      platform:
        aws:
          iamRole: ExampleRole

  3. ファイルを保存し、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) を使用してポリシーテンプレートを作成することです。

  • ポリシーテンプレートには、クラスターが指定された期間に使用したアクセス許可が含まれています。
  • その後、テンプレートを使用して、きめ細かい権限を持つポリシーを作成できます。

手順

全体的なプロセスは次のようになります。

  1. CloudTrail が有効になっていることを確認します。CloudTrail は、ポリシーテンプレートの作成に必要な API 呼び出しを含め、AWS アカウントのすべてのアクションとイベントを記録します。詳細は、CloudTrail の操作 に関する AWS ドキュメントを参照してください。
  2. コントロールプレーンインスタンスのインスタンスプロファイルとコンピューティングインスタンスのインスタンスプロファイルを作成します。PowerUserAccess などの寛容なポリシーを各ロールに割り当ててください。詳細は、インスタンスプロファイルロールの作成 に関する AWS ドキュメントを参照してください。
  3. クラスターを開発環境にインストールし、必要に応じて設定します。クラスターが本番環境でホストするすべてのアプリケーションを必ずデプロイしてください。
  4. クラスターを徹底的にテストします。クラスターをテストすると、必要なすべての API 呼び出しがログに記録されることが保証されます。
  5. IAM Access Analyzer を使用して、各インスタンスプロファイルのポリシーテンプレートを作成します。詳細は、CloudTrail ログに基づいてポリシーを生成する ための AWS ドキュメントを参照してください。
  6. きめ細かいポリシーを作成し、各インスタンスプロファイルに追加します。
  7. 各インスタンスプロファイルから許容ポリシーを削除します。
  8. 新しいポリシーで既存のインスタンスプロファイルを使用して実稼働クラスターをデプロイします。
注記

ポリシーに 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. 次のステップ

4.3. クラスターの AWS へのクイックインストール

OpenShift Container Platform バージョン 4.15 では、デフォルトの設定オプションを使用する Amazon Web Services (AWS) にクラスターをインストールできます。

4.3.1. 前提条件

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

手順

  1. クラスターノードへの認証に使用するローカルマシンに既存の SSH キーペアがない場合は、これを作成します。たとえば、Linux オペレーティングシステムを使用するコンピューターで以下のコマンドを実行します。

    Copy to Clipboard Toggle word wrap
    $ ssh-keygen -t ed25519 -N '' -f <path>/<file_name> 
    1
    1
    新しい SSH キーのパスとファイル名 (~/.ssh/id_ed25519 など) を指定します。既存のキーペアがある場合は、公開鍵が ~/.ssh ディレクトリーにあることを確認します。
    注記

    x86_64ppc64le、および s390x アーキテクチャーのみで FIPS 140-2/140-3 検証のために NIST に提出された RHEL 暗号化ライブラリーを使用する OpenShift Container Platform クラスターをインストールする予定がある場合は、ed25519 アルゴリズムを使用するキーを作成しないでください。代わりに、rsa アルゴリズムまたは ecdsa アルゴリズムを使用するキーを作成します。

  2. 公開 SSH キーを表示します。

    Copy to Clipboard Toggle word wrap
    $ cat <path>/<file_name>.pub

    たとえば、次のコマンドを実行して ~/.ssh/id_ed25519.pub 公開鍵を表示します。

    Copy to Clipboard Toggle word wrap
    $ cat ~/.ssh/id_ed25519.pub
  3. ローカルユーザーの SSH エージェントに SSH 秘密鍵 ID が追加されていない場合は、それを追加します。キーの SSH エージェント管理は、クラスターノードへのパスワードなしの SSH 認証、または ./openshift-install gather コマンドを使用する場合は必要になります。

    注記

    一部のディストリビューションでは、~/.ssh/id_rsa および ~/.ssh/id_dsa などのデフォルトの SSH 秘密鍵のアイデンティティーは自動的に管理されます。

    1. ssh-agent プロセスがローカルユーザーに対して実行されていない場合は、バックグラウンドタスクとして開始します。

      Copy to Clipboard Toggle word wrap
      $ eval "$(ssh-agent -s)"

      出力例

      Copy to Clipboard Toggle word wrap
      Agent pid 31874

      注記

      クラスターが FIPS モードにある場合は、FIPS 準拠のアルゴリズムのみを使用して SSH キーを生成します。鍵は RSA または ECDSA のいずれかである必要があります。

  4. SSH プライベートキーを ssh-agent に追加します。

    Copy to Clipboard Toggle word wrap
    $ ssh-add <path>/<file_name> 
    1
    1
    ~/.ssh/id_ed25519 などの、SSH プライベートキーのパスおよびファイル名を指定します。

    出力例

    Copy to Clipboard Toggle word wrap
    Identity added: /home/<you>/<path>/<file_name> (<computer_name>)

次のステップ

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

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

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

前提条件

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

手順

  1. OpenShift Cluster Manager サイトの インフラストラクチャープロバイダー ページにアクセスします。Red Hat アカウントがある場合は、認証情報を使用してログインします。アカウントがない場合はこれを作成します。
  2. インフラストラクチャープロバイダーを選択します。
  3. インストールタイプのページに移動し、ホストオペレーティングシステムとアーキテクチャーに対応するインストールプログラムをダウンロードして、インストール設定ファイルを保存するディレクトリーにファイルを配置します。

    重要

    インストールプログラムは、クラスターのインストールに使用するコンピューターにいくつかのファイルを作成します。クラスターのインストール完了後は、インストールプログラムおよびインストールプログラムが作成するファイルを保持する必要があります。ファイルはいずれもクラスターを削除するために必要になります。

    重要

    インストールプログラムで作成されたファイルを削除しても、クラスターがインストール時に失敗した場合でもクラスターは削除されません。クラスターを削除するには、特定のクラウドプロバイダー用の OpenShift Container Platform のアンインストール手順を実行します。

  4. インストールプログラムを展開します。たとえば、Linux オペレーティングシステムを使用するコンピューターで以下のコマンドを実行します。

    Copy to Clipboard Toggle word wrap
    $ tar -xvf openshift-install-linux.tar.gz
  5. Red Hat OpenShift Cluster Manager からインストールプルシークレット をダウンロードします。このプルシークレットを使用し、OpenShift Container Platform コンポーネントのコンテナーイメージを提供する Quay.io など、組み込まれた各種の認証局によって提供されるサービスで認証できます。

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

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

重要

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

前提条件

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

手順

  1. インストールプログラムが含まれるディレクトリーに切り替え、クラスターのデプロイメントを初期化します。

    Copy to Clipboard Toggle word wrap
    $ ./openshift-install create cluster --dir <installation_directory> \ 
    1
    
        --log-level=info 
    2
    1
    <installation_directory> の場合、インストールプログラムが作成するファイルを保存するためにディレクトリー名を指定します。
    2
    異なるインストールの詳細情報を表示するには、info ではなく、warndebug、または error を指定します。

    ディレクトリーを指定する場合:

    • ディレクトリーに execute 権限があることを確認します。この権限は、インストールディレクトリーで Terraform バイナリーを実行するために必要です。
    • 空のディレクトリーを使用します。ブートストラップ X.509 証明書などの一部のインストールアセットは有効期限が短いため、インストールディレクトリーを再利用しないでください。別のクラスターインストールの個別のファイルを再利用する必要がある場合は、それらをディレクトリーにコピーすることができます。ただし、インストールアセットのファイル名はリリース間で変更される可能性があります。インストールファイルを以前のバージョンの OpenShift Container Platform からコピーする場合は注意してコピーを行ってください。
  2. プロンプト時に値を指定します。

    1. オプション: クラスターマシンにアクセスするために使用する SSH キーを選択します。

      注記

      インストールのデバッグまたは障害復旧を実行する必要のある実稼働用の OpenShift Container Platform クラスターでは、ssh-agent プロセスが使用する SSH キーを指定します。

    2. ターゲットに設定するプラットフォームとして aws を選択します。
    3. Amazon Web Services (AWS) プロファイルをコンピューターに保存していない場合、インストールプログラムを実行するように設定したユーザーの AWS アクセスキー ID およびシークレットアクセスキーを入力します。

      注記

      AWS アクセスキー ID およびシークレットアクセスキーは、インストールホストの現行ユーザーのホームディレクトリーの ~/.aws/credentials に保存されます。エクスポートされたプロファイルの認証情報がファイルにない場合は、インストールプログラムにより認証情報の入力が求めるプロンプトが出されます。インストールプログラムに指定する認証情報は、ファイルに保存されます。

    4. クラスターのデプロイ先とする AWS リージョンを選択します。
    5. クラスターに設定した Route 53 サービスのベースドメインを選択します。
    6. クラスターの記述名を入力します。
    7. Red Hat OpenShift Cluster Manager からプルシークレット を貼り付けます。
  3. オプション: クラスターのインストールに使用した IAM アカウントから AdministratorAccess ポリシーを削除するか、無効にします。

    注記

    AdministratorAccess ポリシーが提供する昇格したパーミッションはインストール時にのみ必要です。

検証

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

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

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

出力例

Copy to Clipboard Toggle word wrap
...
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.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 にインストールできます。

手順

  1. Red Hat カスタマーポータルの OpenShift Container Platform ダウンロードページ に移動します。
  2. Product Variant ドロップダウンリストからアーキテクチャーを選択します。
  3. バージョン ドロップダウンリストから適切なバージョンを選択します。
  4. OpenShift v4.15 Linux Client エントリーの横にある Download Now をクリックして、ファイルを保存します。
  5. アーカイブを展開します。

    Copy to Clipboard Toggle word wrap
    $ tar xvf <file>
  6. oc バイナリーを、PATH にあるディレクトリーに配置します。

    PATH を確認するには、以下のコマンドを実行します。

    Copy to Clipboard Toggle word wrap
    $ echo $PATH

検証

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

    Copy to Clipboard Toggle word wrap
    $ oc <command>
Windows への OpenShift CLI のインストール

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

手順

  1. Red Hat カスタマーポータルの OpenShift Container Platform ダウンロードページ に移動します。
  2. バージョン ドロップダウンリストから適切なバージョンを選択します。
  3. OpenShift v4.15 Windows Client エントリーの横にある Download Now をクリックして、ファイルを保存します。
  4. ZIP プログラムでアーカイブを展開します。
  5. oc バイナリーを、PATH にあるディレクトリーに移動します。

    PATH を確認するには、コマンドプロンプトを開いて以下のコマンドを実行します。

    Copy to Clipboard Toggle word wrap
    C:\> path

検証

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

    Copy to Clipboard Toggle word wrap
    C:\> oc <command>
macOS への OpenShift CLI のインストール

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

手順

  1. Red Hat カスタマーポータルの OpenShift Container Platform ダウンロードページ に移動します。
  2. バージョン ドロップダウンリストから適切なバージョンを選択します。
  3. OpenShift v4.15 macOS Client エントリーの横にある Download Now をクリックして、ファイルを保存します。

    注記

    macOS arm64 の場合は、OpenShift v4.15 macOS arm64 Client エントリーを選択します。

  4. アーカイブを展開し、解凍します。
  5. oc バイナリーをパスにあるディレクトリーに移動します。

    PATH を確認するには、ターミナルを開き、以下のコマンドを実行します。

    Copy to Clipboard Toggle word wrap
    $ echo $PATH

検証

  • oc コマンドを使用してインストールを確認します。

    Copy to Clipboard Toggle word wrap
    $ oc <command>

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

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

前提条件

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

手順

  1. kubeadmin 認証情報をエクスポートします。

    Copy to Clipboard Toggle word wrap
    $ export KUBECONFIG=<installation_directory>/auth/kubeconfig 
    1
    1
    <installation_directory> には、インストールファイルを保存したディレクトリーへのパスを指定します。
  2. エクスポートされた設定を使用して、oc コマンドを正常に実行できることを確認します。

    Copy to Clipboard Toggle word wrap
    $ oc whoami

    出力例

    Copy to Clipboard Toggle word wrap
    system:admin

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

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

前提条件

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

手順

  1. インストールホストで kubeadmin-password ファイルから kubeadmin ユーザーのパスワードを取得します。

    Copy to Clipboard Toggle word wrap
    $ cat <installation_directory>/auth/kubeadmin-password
    注記

    または、インストールホストで <installation_directory>/.openshift_install.log ログファイルから kubeadmin パスワードを取得できます。

  2. OpenShift Container Platform Web コンソールルートをリスト表示します。

    Copy to Clipboard Toggle word wrap
    $ oc get routes -n openshift-console | grep 'console-openshift'
    注記

    または、インストールホストで <installation_directory>/.openshift_install.log ログファイルからで OpenShift Container Platform ルートを取得できます。

    出力例

    Copy to Clipboard Toggle word wrap
    console     console-openshift-console.apps.<cluster_name>.<base_domain>            console     https   reencrypt/Redirect   None

  3. Web ブラウザーで前述のコマンドの出力で詳細に説明されたルートに移動し、kubeadmin ユーザーとしてログインします。

関連情報

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 サブスクリプションを追跡します。

関連情報

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. 前提条件

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

手順

  1. クラスターノードへの認証に使用するローカルマシンに既存の SSH キーペアがない場合は、これを作成します。たとえば、Linux オペレーティングシステムを使用するコンピューターで以下のコマンドを実行します。

    Copy to Clipboard Toggle word wrap
    $ ssh-keygen -t ed25519 -N '' -f <path>/<file_name> 
    1
    1
    新しい SSH キーのパスとファイル名 (~/.ssh/id_ed25519 など) を指定します。既存のキーペアがある場合は、公開鍵が ~/.ssh ディレクトリーにあることを確認します。
    注記

    x86_64ppc64le、および s390x アーキテクチャーのみで FIPS 140-2/140-3 検証のために NIST に提出された RHEL 暗号化ライブラリーを使用する OpenShift Container Platform クラスターをインストールする予定がある場合は、ed25519 アルゴリズムを使用するキーを作成しないでください。代わりに、rsa アルゴリズムまたは ecdsa アルゴリズムを使用するキーを作成します。

  2. 公開 SSH キーを表示します。

    Copy to Clipboard Toggle word wrap
    $ cat <path>/<file_name>.pub

    たとえば、次のコマンドを実行して ~/.ssh/id_ed25519.pub 公開鍵を表示します。

    Copy to Clipboard Toggle word wrap
    $ cat ~/.ssh/id_ed25519.pub
  3. ローカルユーザーの SSH エージェントに SSH 秘密鍵 ID が追加されていない場合は、それを追加します。キーの SSH エージェント管理は、クラスターノードへのパスワードなしの SSH 認証、または ./openshift-install gather コマンドを使用する場合は必要になります。

    注記

    一部のディストリビューションでは、~/.ssh/id_rsa および ~/.ssh/id_dsa などのデフォルトの SSH 秘密鍵のアイデンティティーは自動的に管理されます。

    1. ssh-agent プロセスがローカルユーザーに対して実行されていない場合は、バックグラウンドタスクとして開始します。

      Copy to Clipboard Toggle word wrap
      $ eval "$(ssh-agent -s)"

      出力例

      Copy to Clipboard Toggle word wrap
      Agent pid 31874

      注記

      クラスターが FIPS モードにある場合は、FIPS 準拠のアルゴリズムのみを使用して SSH キーを生成します。鍵は RSA または ECDSA のいずれかである必要があります。

  4. SSH プライベートキーを ssh-agent に追加します。

    Copy to Clipboard Toggle word wrap
    $ ssh-add <path>/<file_name> 
    1
    1
    ~/.ssh/id_ed25519 などの、SSH プライベートキーのパスおよびファイル名を指定します。

    出力例

    Copy to Clipboard Toggle word wrap
    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 アカウントを持っている。このアカウントは、クラスターのインストールに使用されるアカウントと同じである必要はありません。

手順

  1. AWS Marketplace で OpenShift Container Platform サブスクリプションを完了します。
  2. ご使用の AWS リージョンの AMI ID を記録します。インストールプロセスの一環として、クラスターをデプロイする前に、この値で install-config.yaml ファイルを更新する必要があります。

    AWS Marketplace コンピュートノードを含む install-config.yaml ファイルのサンプル

    Copy to Clipboard Toggle word wrap
    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": ...}'

    1
    AWS Marketplace サブスクリプションの AMI ID。
    2
    AMI ID は特定の AWS リージョンに関連付けられています。インストール設定ファイルを作成するときは、サブスクリプションの設定時に指定したものと同じ AWS リージョンを選択してください。

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

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

前提条件

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

手順

  1. OpenShift Cluster Manager サイトの インフラストラクチャープロバイダー ページにアクセスします。Red Hat アカウントがある場合は、認証情報を使用してログインします。アカウントがない場合はこれを作成します。
  2. インフラストラクチャープロバイダーを選択します。
  3. インストールタイプのページに移動し、ホストオペレーティングシステムとアーキテクチャーに対応するインストールプログラムをダウンロードして、インストール設定ファイルを保存するディレクトリーにファイルを配置します。

    重要

    インストールプログラムは、クラスターのインストールに使用するコンピューターにいくつかのファイルを作成します。クラスターのインストール完了後は、インストールプログラムおよびインストールプログラムが作成するファイルを保持する必要があります。ファイルはいずれもクラスターを削除するために必要になります。

    重要

    インストールプログラムで作成されたファイルを削除しても、クラスターがインストール時に失敗した場合でもクラスターは削除されません。クラスターを削除するには、特定のクラウドプロバイダー用の OpenShift Container Platform のアンインストール手順を実行します。

  4. インストールプログラムを展開します。たとえば、Linux オペレーティングシステムを使用するコンピューターで以下のコマンドを実行します。

    Copy to Clipboard Toggle word wrap
    $ tar -xvf openshift-install-linux.tar.gz
  5. Red Hat OpenShift Cluster Manager からインストールプルシークレット をダウンロードします。このプルシークレットを使用し、OpenShift Container Platform コンポーネントのコンテナーイメージを提供する Quay.io など、組み込まれた各種の認証局によって提供されるサービスで認証できます。

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

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

前提条件

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

手順

  1. install-config.yaml ファイルを作成します。

    1. インストールプログラムが含まれるディレクトリーに切り替え、以下のコマンドを実行します。

      Copy to Clipboard Toggle word wrap
      $ ./openshift-install create install-config --dir <installation_directory> 
      1
      1
      <installation_directory> の場合、インストールプログラムが作成するファイルを保存するためにディレクトリー名を指定します。

      ディレクトリーを指定する場合:

      • ディレクトリーに execute 権限があることを確認します。この権限は、インストールディレクトリーで Terraform バイナリーを実行するために必要です。
      • 空のディレクトリーを使用します。ブートストラップ X.509 証明書などの一部のインストールアセットは有効期限が短いため、インストールディレクトリーを再利用しないでください。別のクラスターインストールの個別のファイルを再利用する必要がある場合は、それらをディレクトリーにコピーすることができます。ただし、インストールアセットのファイル名はリリース間で変更される可能性があります。インストールファイルを以前のバージョンの OpenShift Container Platform からコピーする場合は注意してコピーを行ってください。
    2. プロンプト時に、クラウドの設定の詳細情報を指定します。

      1. オプション: クラスターマシンにアクセスするために使用する SSH キーを選択します。

        注記

        インストールのデバッグまたは障害復旧を実行する必要のある実稼働用の OpenShift Container Platform クラスターでは、ssh-agent プロセスが使用する SSH キーを指定します。

      2. ターゲットに設定するプラットフォームとして AWS を選択します。
      3. Amazon Web Services (AWS) プロファイルをコンピューターに保存していない場合、インストールプログラムを実行するように設定したユーザーの AWS アクセスキー ID およびシークレットアクセスキーを入力します。
      4. クラスターのデプロイ先とする AWS リージョンを選択します。
      5. クラスターに設定した Route 53 サービスのベースドメインを選択します。
      6. クラスターの記述名を入力します。
  2. install-config.yaml ファイルを変更します。利用可能なパラメーターの詳細は、「インストール設定パラメーター」のセクションを参照してください。

    注記

    3 ノードクラスターをインストールする場合は、必ず compute.replicas パラメーターを 0 に設定してください。これにより、クラスターのコントロールプレーンがスケジュール可能になります。詳細については、「AWS に 3 ノードクラスターをインストールする」を参照してください。

  3. install-config.yaml ファイルをバックアップし、複数のクラスターをインストールするのに使用できるようにします。

    重要

    install-config.yaml ファイルはインストールプロセス時に使用されます。このファイルを再利用する必要がある場合は、この段階でこれをバックアップしてください。

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

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

表4.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. 1 vCPU は、同時マルチスレッド (SMT) またはハイパースレッディングが有効にされていない場合に 1 つの物理コアと同等です。これが有効にされている場合、数式「(コアごとのスレッド × コア数) × ソケット数 = 仮想 CPU」を使用して対応する比率を計算します。
  2. OpenShift Container Platform および Kubernetes はディスクのパフォーマンスに敏感であり、特に 10 ms p99 fsync 期間を必要とするコントロールプレーンノード上の etcd については、高速ストレージが推奨されます。多くのクラウドプラットフォームでは、ストレージサイズと IOPS スケールが一緒にあるため、十分なパフォーマンスを得るためにストレージボリュームの割り当てが必要になる場合があります。
  3. すべての 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 ファイルを取得し、これを変更する必要があります。

Copy to Clipboard Toggle word wrap
apiVersion: v1
baseDomain: example.com 
1

credentialsMode: Mint 
2

controlPlane: 
3
 
4

  hyperthreading: Enabled 
5

  name: master
  platform:
    aws:
      zones:
      - us-west-2a
      - us-west-2b
      rootVolume:
        iops: 4000
        size: 500
        type: io1 
6

      metadataService:
        authentication: Optional 
7

      type: m6i.xlarge
  replicas: 3
compute: 
8

- hyperthreading: Enabled 
9

  name: worker
  platform:
    aws:
      rootVolume:
        iops: 2000
        size: 500
        type: io1 
10

      metadataService:
        authentication: Optional 
11

      type: c5.4xlarge
      zones:
      - us-west-2c
  replicas: 3
metadata:
  name: test-cluster 
12

networking:
  clusterNetwork:
  - cidr: 10.128.0.0/14
    hostPrefix: 23
  machineNetwork:
  - cidr: 10.0.0.0/16
  networkType: OVNKubernetes 
13

  serviceNetwork:
  - 172.30.0.0/16
platform:
  aws:
    region: us-west-2 
14

    propagateUserTags: true 
15

    userTags:
      adminContact: jdoe
      costCenter: 7536
    amiID: ami-0c5d3e03c0ab9b19a 
16

    serviceEndpoints: 
17

      - name: ec2
        url: https://vpce-id.ec2.us-west-2.vpce.amazonaws.com
fips: false 
18

sshKey: ssh-ed25519 AAAA... 
19

pullSecret: '{"auths": ...}' 
20
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 として設定し、iops2000 に設定します。
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[].cidrnetworking.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) も設定されます。

手順

  1. install-config.yaml ファイルを編集し、プロキシー設定を追加します。以下に例を示します。

    Copy to Clipboard Toggle word wrap
    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.comx.y.com に一致しますが、y.com には一致しません。* を使用し、すべての宛先のプロキシーをバイパスします。Amazon EC2Elastic 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 Toggle word wrap
    $ ./openshift-install wait-for install-complete --log-level debug
  2. ファイルを保存し、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 にインストールできます。

手順

  1. Red Hat カスタマーポータルの OpenShift Container Platform ダウンロードページ に移動します。
  2. Product Variant ドロップダウンリストからアーキテクチャーを選択します。
  3. バージョン ドロップダウンリストから適切なバージョンを選択します。
  4. OpenShift v4.15 Linux Client エントリーの横にある Download Now をクリックして、ファイルを保存します。
  5. アーカイブを展開します。

    Copy to Clipboard Toggle word wrap
    $ tar xvf <file>
  6. oc バイナリーを、PATH にあるディレクトリーに配置します。

    PATH を確認するには、以下のコマンドを実行します。

    Copy to Clipboard Toggle word wrap
    $ echo $PATH

検証

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

    Copy to Clipboard Toggle word wrap
    $ oc <command>
Windows への OpenShift CLI のインストール

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

手順

  1. Red Hat カスタマーポータルの OpenShift Container Platform ダウンロードページ に移動します。
  2. バージョン ドロップダウンリストから適切なバージョンを選択します。
  3. OpenShift v4.15 Windows Client エントリーの横にある Download Now をクリックして、ファイルを保存します。
  4. ZIP プログラムでアーカイブを展開します。
  5. oc バイナリーを、PATH にあるディレクトリーに移動します。

    PATH を確認するには、コマンドプロンプトを開いて以下のコマンドを実行します。

    Copy to Clipboard Toggle word wrap
    C:\> path

検証

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

    Copy to Clipboard Toggle word wrap
    C:\> oc <command>
macOS への OpenShift CLI のインストール

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

手順

  1. Red Hat カスタマーポータルの OpenShift Container Platform ダウンロードページ に移動します。
  2. バージョン ドロップダウンリストから適切なバージョンを選択します。
  3. OpenShift v4.15 macOS Client エントリーの横にある Download Now をクリックして、ファイルを保存します。

    注記

    macOS arm64 の場合は、OpenShift v4.15 macOS arm64 Client エントリーを選択します。

  4. アーカイブを展開し、解凍します。
  5. oc バイナリーをパスにあるディレクトリーに移動します。

    PATH を確認するには、ターミナルを開き、以下のコマンドを実行します。

    Copy to Clipboard Toggle word wrap
    $ echo $PATH

検証

  • oc コマンドを使用してインストールを確認します。

    Copy to Clipboard Toggle word wrap
    $ oc <command>

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

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

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

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

手順

  1. install-config.yaml 設定ファイルの credentialsMode パラメーターを Manual に設定しなかった場合は、次のように値を変更します。

    設定ファイルのサンプルスニペット

    Copy to Clipboard Toggle word wrap
    apiVersion: v1
    baseDomain: example.com
    credentialsMode: Manual
    # ...

  2. インストールマニフェストファイルをまだ作成していない場合は、次のコマンドを実行して作成します。

    Copy to Clipboard Toggle word wrap
    $ openshift-install create manifests --dir <installation_directory>

    ここで、<installation_directory> は、インストールプログラムがファイルを作成するディレクトリーに置き換えます。

  3. 次のコマンドを実行して、インストールファイルのリリースイメージを $RELEASE_IMAGE 変数に設定します。

    Copy to Clipboard Toggle word wrap
    $ RELEASE_IMAGE=$(./openshift-install version | awk '/release image/ {print $3}')
  4. 以下のコマンドを実行して、OpenShift Container Platform リリースイメージから CredentialsRequest カスタムリソース (CR) のリストを抽出します。

    Copy to Clipboard Toggle word wrap
    $ oc adm release extract \
      --from=$RELEASE_IMAGE \
      --credentials-requests \
      --included \
    1
    
      --install-config=<path_to_directory_with_installation_configuration>/install-config.yaml \
    2
    
      --to=<path_to_directory_for_credentials_requests> 
    3
    1
    --included パラメーターには、特定のクラスター設定に必要なマニフェストのみが含まれます。
    2
    install-config.yaml ファイルの場所を指定します。
    3
    CredentialsRequest オブジェクトを保存するディレクトリーへのパスを指定します。指定したディレクトリーが存在しない場合は、このコマンドによって作成されます。

    このコマンドにより、それぞれの CredentialsRequest オブジェクトに YAML ファイルが作成されます。

    サンプル CredentialsRequest オブジェクト

    Copy to Clipboard Toggle word wrap
    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: "*"
      ...

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

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

    Copy to Clipboard Toggle word wrap
    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 Toggle word wrap
    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 オプションの使用をサポートします。

手順

  1. 次のコマンドを実行して、OpenShift Container Platform リリースイメージの変数を設定します。

    Copy to Clipboard Toggle word wrap
    $ RELEASE_IMAGE=$(./openshift-install version | awk '/release image/ {print $3}')
  2. 以下のコマンドを実行して、OpenShift Container Platform リリースイメージから CCO コンテナーイメージを取得します。

    Copy to Clipboard Toggle word wrap
    $ CCO_IMAGE=$(oc adm release info --image-for='cloud-credential-operator' $RELEASE_IMAGE -a ~/.pull-secret)
    注記

    $RELEASE_IMAGE のアーキテクチャーが、ccoctlツールを使用する環境のアーキテクチャーと一致していることを確認してください。

  3. 以下のコマンドを実行して、OpenShift Container Platform リリースイメージ内の CCO コンテナーイメージから ccoctl バイナリーを抽出します。

    Copy to Clipboard Toggle word wrap
    $ oc image extract $CCO_IMAGE --file="/usr/bin/ccoctl" -a ~/.pull-secret
  4. 次のコマンドを実行して、権限を変更して ccoctl を実行可能にします。

    Copy to Clipboard Toggle word wrap
    $ chmod 775 ccoctl

検証

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

    Copy to Clipboard Toggle word wrap
    $ ./ccoctl.rhel9

    出力例

    Copy to Clipboard Toggle word wrap
    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 バイナリーを抽出して準備している。

手順

  1. 次のコマンドを実行して、インストールファイルのリリースイメージを $RELEASE_IMAGE 変数に設定します。

    Copy to Clipboard Toggle word wrap
    $ RELEASE_IMAGE=$(./openshift-install version | awk '/release image/ {print $3}')
  2. 以下のコマンドを実行して、OpenShift Container Platform リリースイメージから CredentialsRequest オブジェクトのリストを抽出します。

    Copy to Clipboard Toggle word wrap
    $ oc adm release extract \
      --from=$RELEASE_IMAGE \
      --credentials-requests \
      --included \
    1
    
      --install-config=<path_to_directory_with_installation_configuration>/install-config.yaml \
    2
    
      --to=<path_to_directory_for_credentials_requests> 
    3
    1
    --included パラメーターには、特定のクラスター設定に必要なマニフェストのみが含まれます。
    2
    install-config.yaml ファイルの場所を指定します。
    3
    CredentialsRequest オブジェクトを保存するディレクトリーへのパスを指定します。指定したディレクトリーが存在しない場合は、このコマンドによって作成されます。
    注記

    このコマンドの実行には少し時間がかかる場合があります。

  3. 次のコマンドを実行し、ccoctl ツールを使用して CredentialsRequest オブジェクトをすべて処理します。

    Copy to Clipboard Toggle word wrap
    $ 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 Toggle word wrap
    $ ls <path_to_ccoctl_output_dir>/manifests

    出力例

    Copy to Clipboard Toggle word wrap
    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 バイナリーを展開して準備しておく。

手順

  1. 次のコマンドを実行して、クラスターの OpenID Connect プロバイダーを設定するために使用されるパブリックおよびプライベート RSA キーファイルを生成します。

    Copy to Clipboard Toggle word wrap
    $ ccoctl aws create-key-pair

    出力例

    Copy to Clipboard Toggle word wrap
    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 に作成します。

  2. 次のコマンドを実行して、AWS 上に OpenID Connect ID プロバイダーと S3 バケットを作成します。

    Copy to Clipboard Toggle word wrap
    $ ccoctl aws create-identity-provider \
      --name=<name> \
    1
    
      --region=<aws_region> \
    2
    
      --public-key-file=<path_to_ccoctl_output_dir>/serviceaccount-signer.public 
    3
    1
    <name> は、追跡用に作成されたクラウドリソースにタグを付けるために使用される名前です。
    2
    <aws_region> は、クラウドリソースが作成される AWS リージョンです。
    3
    <path_to_ccoctl_output_dir> は、ccoctl aws create-key-pair コマンドが生成したパブリックキーファイルへのパスです。

    出力例

    Copy to Clipboard Toggle word wrap
    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 フィールドを設定します。

  3. クラスターの各コンポーネントについて IAM ロールを作成します。

    1. 次のコマンドを実行して、インストールファイルのリリースイメージを $RELEASE_IMAGE 変数に設定します。

      Copy to Clipboard Toggle word wrap
      $ RELEASE_IMAGE=$(./openshift-install version | awk '/release image/ {print $3}')
    2. OpenShift Container Platform リリースイメージから CredentialsRequest オブジェクトの一覧を抽出します。

      Copy to Clipboard Toggle word wrap
      $ oc adm release extract \
        --from=$RELEASE_IMAGE \
        --credentials-requests \
        --included \
      1
      
        --install-config=<path_to_directory_with_installation_configuration>/install-config.yaml \
      2
      
        --to=<path_to_directory_for_credentials_requests> 
      3
      1
      --included パラメーターには、特定のクラスター設定に必要なマニフェストのみが含まれます。
      2
      install-config.yaml ファイルの場所を指定します。
      3
      CredentialsRequest オブジェクトを保存するディレクトリーへのパスを指定します。指定したディレクトリーが存在しない場合は、このコマンドによって作成されます。
    3. 次のコマンドを実行し、ccoctl ツールを使用して CredentialsRequest オブジェクトをすべて処理します。

      Copy to Clipboard Toggle word wrap
      $ 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 Toggle word wrap
    $ ls <path_to_ccoctl_output_dir>/manifests

    出力例

    Copy to Clipboard Toggle word wrap
    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 ユーティリティーを使用して、クラスターに必要なクラウドプロバイダーリソースを作成している。

手順

  1. install-config.yaml 設定ファイルの credentialsMode パラメーターを Manual に設定しなかった場合は、次のように値を変更します。

    設定ファイルのサンプルスニペット

    Copy to Clipboard Toggle word wrap
    apiVersion: v1
    baseDomain: example.com
    credentialsMode: Manual
    # ...

  2. インストールマニフェストファイルをまだ作成していない場合は、次のコマンドを実行して作成します。

    Copy to Clipboard Toggle word wrap
    $ openshift-install create manifests --dir <installation_directory>

    ここで、<installation_directory> は、インストールプログラムがファイルを作成するディレクトリーに置き換えます。

  3. 次のコマンドを実行して、ccoctl ユーティリティーが生成したマニフェストを、インストールプログラムが作成した manifests ディレクトリーにコピーします。

    Copy to Clipboard Toggle word wrap
    $ cp /<path_to_ccoctl_output_dir>/manifests/* ./manifests/
  4. 秘密鍵を含む tls ディレクトリーをインストールディレクトリーにコピーします。

    Copy to Clipboard Toggle word wrap
    $ cp -a /<path_to_ccoctl_output_dir>/tls .

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

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

重要

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

前提条件

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

手順

  1. インストールプログラムが含まれるディレクトリーに切り替え、クラスターのデプロイメントを初期化します。

    Copy to Clipboard Toggle word wrap
    $ ./openshift-install create cluster --dir <installation_directory> \ 
    1
    
        --log-level=info 
    2
    1
    <installation_directory> については、カスタマイズした ./install-config.yaml ファイルの場所を指定します。
    2
    異なるインストールの詳細情報を表示するには、info ではなく、warndebug、または error を指定します。
  2. オプション: クラスターのインストールに使用した IAM アカウントから AdministratorAccess ポリシーを削除するか、無効にします。

    注記

    AdministratorAccess ポリシーが提供する昇格したパーミッションはインストール時にのみ必要です。

検証

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

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

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

出力例

Copy to Clipboard Toggle word wrap
...
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 をインストールしていること。

手順

  1. kubeadmin 認証情報をエクスポートします。

    Copy to Clipboard Toggle word wrap
    $ export KUBECONFIG=<installation_directory>/auth/kubeconfig 
    1
    1
    <installation_directory> には、インストールファイルを保存したディレクトリーへのパスを指定します。
  2. エクスポートされた設定を使用して、oc コマンドを正常に実行できることを確認します。

    Copy to Clipboard Toggle word wrap
    $ oc whoami

    出力例

    Copy to Clipboard Toggle word wrap
    system:admin

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

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

前提条件

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

手順

  1. インストールホストで kubeadmin-password ファイルから kubeadmin ユーザーのパスワードを取得します。

    Copy to Clipboard Toggle word wrap
    $ cat <installation_directory>/auth/kubeadmin-password
    注記

    または、インストールホストで <installation_directory>/.openshift_install.log ログファイルから kubeadmin パスワードを取得できます。

  2. OpenShift Container Platform Web コンソールルートをリスト表示します。

    Copy to Clipboard Toggle word wrap
    $ oc get routes -n openshift-console | grep 'console-openshift'
    注記

    または、インストールホストで <installation_directory>/.openshift_install.log ログファイルからで OpenShift Container Platform ルートを取得できます。

    出力例

    Copy to Clipboard Toggle word wrap
    console     console-openshift-console.apps.<cluster_name>.<base_domain>            console     https   reencrypt/Redirect   None

  3. Web ブラウザーで前述のコマンドの出力で詳細に説明されたルートに移動し、kubeadmin ユーザーとしてログインします。

関連情報

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 サブスクリプションを追跡します。

関連情報

4.4.13. 次のステップ

4.5. ネットワークのカスタマイズによる AWS へのクラスターのインストール

OpenShift Container Platform バージョン 4.15 では、カスタマイズされたネットワーク設定オプションを使用して、Amazon Web Services (AWS) にクラスターをインストールできます。ネットワーク設定をカスタマイズすることにより、クラスターは環境内の既存の IP アドレスの割り当てと共存でき、既存の MTU および VXLAN 設定と統合できます。

大半のネットワーク設定パラメーターはインストール時に設定する必要があり、実行中のクラスターで変更できるのは kubeProxy 設定パラメーターのみになります。

4.5.1. 前提条件

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

手順

  1. クラスターノードへの認証に使用するローカルマシンに既存の SSH キーペアがない場合は、これを作成します。たとえば、Linux オペレーティングシステムを使用するコンピューターで以下のコマンドを実行します。

    Copy to Clipboard Toggle word wrap
    $ ssh-keygen -t ed25519 -N '' -f <path>/<file_name> 
    1
    1
    新しい SSH キーのパスとファイル名 (~/.ssh/id_ed25519 など) を指定します。既存のキーペアがある場合は、公開鍵が ~/.ssh ディレクトリーにあることを確認します。
    注記

    x86_64ppc64le、および s390x アーキテクチャーのみで FIPS 140-2/140-3 検証のために NIST に提出された RHEL 暗号化ライブラリーを使用する OpenShift Container Platform クラスターをインストールする予定がある場合は、ed25519 アルゴリズムを使用するキーを作成しないでください。代わりに、rsa アルゴリズムまたは ecdsa アルゴリズムを使用するキーを作成します。

  2. 公開 SSH キーを表示します。

    Copy to Clipboard Toggle word wrap
    $ cat <path>/<file_name>.pub

    たとえば、次のコマンドを実行して ~/.ssh/id_ed25519.pub 公開鍵を表示します。

    Copy to Clipboard Toggle word wrap
    $ cat ~/.ssh/id_ed25519.pub
  3. ローカルユーザーの SSH エージェントに SSH 秘密鍵 ID が追加されていない場合は、それを追加します。キーの SSH エージェント管理は、クラスターノードへのパスワードなしの SSH 認証、または ./openshift-install gather コマンドを使用する場合は必要になります。

    注記

    一部のディストリビューションでは、~/.ssh/id_rsa および ~/.ssh/id_dsa などのデフォルトの SSH 秘密鍵のアイデンティティーは自動的に管理されます。

    1. ssh-agent プロセスがローカルユーザーに対して実行されていない場合は、バックグラウンドタスクとして開始します。

      Copy to Clipboard Toggle word wrap
      $ eval "$(ssh-agent -s)"

      出力例

      Copy to Clipboard Toggle word wrap
      Agent pid 31874

      注記

      クラスターが FIPS モードにある場合は、FIPS 準拠のアルゴリズムのみを使用して SSH キーを生成します。鍵は RSA または ECDSA のいずれかである必要があります。

  4. SSH プライベートキーを ssh-agent に追加します。

    Copy to Clipboard Toggle word wrap
    $ ssh-add <path>/<file_name> 
    1
    1
    ~/.ssh/id_ed25519 などの、SSH プライベートキーのパスおよびファイル名を指定します。

    出力例

    Copy to Clipboard Toggle word wrap
    Identity added: /home/<you>/<path>/<file_name> (<computer_name>)

次のステップ

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

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

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

前提条件

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

手順

  1. OpenShift Cluster Manager サイトの インフラストラクチャープロバイダー ページにアクセスします。Red Hat アカウントがある場合は、認証情報を使用してログインします。アカウントがない場合はこれを作成します。
  2. インフラストラクチャープロバイダーを選択します。
  3. インストールタイプのページに移動し、ホストオペレーティングシステムとアーキテクチャーに対応するインストールプログラムをダウンロードして、インストール設定ファイルを保存するディレクトリーにファイルを配置します。

    重要

    インストールプログラムは、クラスターのインストールに使用するコンピューターにいくつかのファイルを作成します。クラスターのインストール完了後は、インストールプログラムおよびインストールプログラムが作成するファイルを保持する必要があります。ファイルはいずれもクラスターを削除するために必要になります。

    重要

    インストールプログラムで作成されたファイルを削除しても、クラスターがインストール時に失敗した場合でもクラスターは削除されません。クラスターを削除するには、特定のクラウドプロバイダー用の OpenShift Container Platform のアンインストール手順を実行します。

  4. インストールプログラムを展開します。たとえば、Linux オペレーティングシステムを使用するコンピューターで以下のコマンドを実行します。

    Copy to Clipboard Toggle word wrap
    $ tar -xvf openshift-install-linux.tar.gz
  5. 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 インストールプログラムおよびクラスターのプルシークレットがある。

手順

  1. install-config.yaml ファイルを作成します。

    1. インストールプログラムが含まれるディレクトリーに切り替え、以下のコマンドを実行します。

      Copy to Clipboard Toggle word wrap
      $ ./openshift-install create install-config --dir <installation_directory> 
      1
      1
      <installation_directory> の場合、インストールプログラムが作成するファイルを保存するためにディレクトリー名を指定します。

      ディレクトリーを指定する場合:

      • ディレクトリーに execute 権限があることを確認します。この権限は、インストールディレクトリーで Terraform バイナリーを実行するために必要です。
      • 空のディレクトリーを使用します。ブートストラップ X.509 証明書などの一部のインストールアセットは有効期限が短いため、インストールディレクトリーを再利用しないでください。別のクラスターインストールの個別のファイルを再利用する必要がある場合は、それらをディレクトリーにコピーすることができます。ただし、インストールアセットのファイル名はリリース間で変更される可能性があります。インストールファイルを以前のバージョンの OpenShift Container Platform からコピーする場合は注意してコピーを行ってください。
    2. プロンプト時に、クラウドの設定の詳細情報を指定します。

      1. オプション: クラスターマシンにアクセスするために使用する SSH キーを選択します。

        注記

        インストールのデバッグまたは障害復旧を実行する必要のある実稼働用の OpenShift Container Platform クラスターでは、ssh-agent プロセスが使用する SSH キーを指定します。

      2. ターゲットに設定するプラットフォームとして AWS を選択します。
      3. Amazon Web Services (AWS) プロファイルをコンピューターに保存していない場合、インストールプログラムを実行するように設定したユーザーの AWS アクセスキー ID およびシークレットアクセスキーを入力します。
      4. クラスターのデプロイ先とする AWS リージョンを選択します。
      5. クラスターに設定した Route 53 サービスのベースドメインを選択します。
      6. クラスターの記述名を入力します。
  2. install-config.yaml ファイルを変更します。利用可能なパラメーターの詳細は、「インストール設定パラメーター」のセクションを参照してください。
  3. install-config.yaml ファイルをバックアップし、複数のクラスターをインストールするのに使用できるようにします。

    重要

    install-config.yaml ファイルはインストールプロセス時に使用されます。このファイルを再利用する必要がある場合は、この段階でこれをバックアップしてください。

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

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

表4.2 最小リソース要件
マシンオペレーティングシステムvCPU [1]仮想 RAMストレージ1 秒あたりの入出力 (IOPS) [2]

ブートストラップ

RHCOS

4

16 GB

100 GB

300

コントロールプレーン

RHCOS

4

16 GB

100 GB

300

Compute

RHCOS、RHEL 8.6 以降 [3]

2

8 GB

100 GB

300

  1. 1 vCPU は、同時マルチスレッド (SMT) またはハイパースレッディングが有効にされていない場合に 1 つの物理コアと同等です。これが有効にされている場合、数式「(コアごとのスレッド × コア数) × ソケット数 = 仮想 CPU」を使用して対応する比率を計算します。
  2. OpenShift Container Platform および Kubernetes はディスクのパフォーマンスに敏感であり、特に 10 ms p99 fsync 期間を必要とするコントロールプレーンノード上の etcd については、高速ストレージが推奨されます。多くのクラウドプラットフォームでは、ストレージサイズと IOPS スケールが一緒にあるため、十分なパフォーマンスを得るためにストレージボリュームの割り当てが必要になる場合があります。
  3. すべての 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 ファイルを取得し、これを変更する必要があります。

Copy to Clipboard Toggle word wrap
apiVersion: v1
baseDomain: example.com 
1

credentialsMode: Mint 
2

controlPlane: 
3
 
4

  hyperthreading: Enabled 
5

  name: master
  platform:
    aws:
      zones:
      - us-west-2a
      - us-west-2b
      rootVolume:
        iops: 4000
        size: 500
        type: io1 
6

      metadataService:
        authentication: Optional 
7

      type: m6i.xlarge
  replicas: 3
compute: 
8

- hyperthreading: Enabled 
9

  name: worker
  platform:
    aws:
      rootVolume:
        iops: 2000
        size: 500
        type: io1 
10

      metadataService:
        authentication: Optional 
11

      type: c5.4xlarge
      zones:
      - us-west-2c
  replicas: 3
metadata:
  name: test-cluster 
12

networking: 
13

  clusterNetwork:
  - cidr: 10.128.0.0/14
    hostPrefix: 23
  machineNetwork:
  - cidr: 10.0.0.0/16
  networkType: OVNKubernetes 
14

  serviceNetwork:
  - 172.30.0.0/16
platform:
  aws:
    region: us-west-2 
15

    propagateUserTags: true 
16

    userTags:
      adminContact: jdoe
      costCenter: 7536
    amiID: ami-0c5d3e03c0ab9b19a 
17

    serviceEndpoints: 
18

      - name: ec2
        url: https://vpce-id.ec2.us-west-2.vpce.amazonaws.com
fips: false 
19

sshKey: ssh-ed25519 AAAA... 
20

pullSecret: '{"auths": ...}' 
21
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 として設定し、iops2000 に設定します。
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[].cidrnetworking.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) も設定されます。

手順

  1. install-config.yaml ファイルを編集し、プロキシー設定を追加します。以下に例を示します。

    Copy to Clipboard Toggle word wrap
    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.comx.y.com に一致しますが、y.com には一致しません。* を使用し、すべての宛先のプロキシーをバイパスします。Amazon EC2Elastic 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 Toggle word wrap
    $ ./openshift-install wait-for install-complete --log-level debug
  2. ファイルを保存し、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 にインストールできます。

手順

  1. Red Hat カスタマーポータルの OpenShift Container Platform ダウンロードページ に移動します。
  2. Product Variant ドロップダウンリストからアーキテクチャーを選択します。
  3. バージョン ドロップダウンリストから適切なバージョンを選択します。
  4. OpenShift v4.15 Linux Client エントリーの横にある Download Now をクリックして、ファイルを保存します。
  5. アーカイブを展開します。

    Copy to Clipboard Toggle word wrap
    $ tar xvf <file>
  6. oc バイナリーを、PATH にあるディレクトリーに配置します。

    PATH を確認するには、以下のコマンドを実行します。

    Copy to Clipboard Toggle word wrap
    $ echo $PATH

検証

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

    Copy to Clipboard Toggle word wrap
    $ oc <command>
Windows への OpenShift CLI のインストール

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

手順

  1. Red Hat カスタマーポータルの OpenShift Container Platform ダウンロードページ に移動します。
  2. バージョン ドロップダウンリストから適切なバージョンを選択します。
  3. OpenShift v4.15 Windows Client エントリーの横にある Download Now をクリックして、ファイルを保存します。
  4. ZIP プログラムでアーカイブを展開します。
  5. oc バイナリーを、PATH にあるディレクトリーに移動します。

    PATH を確認するには、コマンドプロンプトを開いて以下のコマンドを実行します。

    Copy to Clipboard Toggle word wrap
    C:\> path

検証

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

    Copy to Clipboard Toggle word wrap
    C:\> oc <command>
macOS への OpenShift CLI のインストール

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

手順

  1. Red Hat カスタマーポータルの OpenShift Container Platform ダウンロードページ に移動します。
  2. バージョン ドロップダウンリストから適切なバージョンを選択します。
  3. OpenShift v4.15 macOS Client エントリーの横にある Download Now をクリックして、ファイルを保存します。

    注記

    macOS arm64 の場合は、OpenShift v4.15 macOS arm64 Client エントリーを選択します。

  4. アーカイブを展開し、解凍します。
  5. oc バイナリーをパスにあるディレクトリーに移動します。

    PATH を確認するには、ターミナルを開き、以下のコマンドを実行します。

    Copy to Clipboard Toggle word wrap
    $ echo $PATH

検証

  • oc コマンドを使用してインストールを確認します。

    Copy to Clipboard Toggle word wrap
    $ oc <command>

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

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

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

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

手順

  1. install-config.yaml 設定ファイルの credentialsMode パラメーターを Manual に設定しなかった場合は、次のように値を変更します。

    設定ファイルのサンプルスニペット

    Copy to Clipboard Toggle word wrap
    apiVersion: v1
    baseDomain: example.com
    credentialsMode: Manual
    # ...

  2. インストールマニフェストファイルをまだ作成していない場合は、次のコマンドを実行して作成します。

    Copy to Clipboard Toggle word wrap
    $ openshift-install create manifests --dir <installation_directory>

    ここで、<installation_directory> は、インストールプログラムがファイルを作成するディレクトリーに置き換えます。

  3. 次のコマンドを実行して、インストールファイルのリリースイメージを $RELEASE_IMAGE 変数に設定します。

    Copy to Clipboard Toggle word wrap
    $ RELEASE_IMAGE=$(./openshift-install version | awk '/release image/ {print $3}')
  4. 以下のコマンドを実行して、OpenShift Container Platform リリースイメージから CredentialsRequest カスタムリソース (CR) のリストを抽出します。

    Copy to Clipboard Toggle word wrap
    $ oc adm release extract \
      --from=$RELEASE_IMAGE \
      --credentials-requests \
      --included \
    1
    
      --install-config=<path_to_directory_with_installation_configuration>/install-config.yaml \
    2
    
      --to=<path_to_directory_for_credentials_requests> 
    3
    1
    --included パラメーターには、特定のクラスター設定に必要なマニフェストのみが含まれます。
    2
    install-config.yaml ファイルの場所を指定します。
    3
    CredentialsRequest オブジェクトを保存するディレクトリーへのパスを指定します。指定したディレクトリーが存在しない場合は、このコマンドによって作成されます。

    このコマンドにより、それぞれの CredentialsRequest オブジェクトに YAML ファイルが作成されます。

    サンプル CredentialsRequest オブジェクト

    Copy to Clipboard Toggle word wrap
    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: "*"
      ...

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

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

    Copy to Clipboard Toggle word wrap
    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 Toggle word wrap
    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 オプションの使用をサポートします。

手順

  1. 次のコマンドを実行して、OpenShift Container Platform リリースイメージの変数を設定します。

    Copy to Clipboard Toggle word wrap
    $ RELEASE_IMAGE=$(./openshift-install version | awk '/release image/ {print $3}')
  2. 以下のコマンドを実行して、OpenShift Container Platform リリースイメージから CCO コンテナーイメージを取得します。

    Copy to Clipboard Toggle word wrap
    $ CCO_IMAGE=$(oc adm release info --image-for='cloud-credential-operator' $RELEASE_IMAGE -a ~/.pull-secret)
    注記

    $RELEASE_IMAGE のアーキテクチャーが、ccoctlツールを使用する環境のアーキテクチャーと一致していることを確認してください。

  3. 以下のコマンドを実行して、OpenShift Container Platform リリースイメージ内の CCO コンテナーイメージから ccoctl バイナリーを抽出します。

    Copy to Clipboard Toggle word wrap
    $ oc image extract $CCO_IMAGE --file="/usr/bin/ccoctl" -a ~/.pull-secret
  4. 次のコマンドを実行して、権限を変更して ccoctl を実行可能にします。

    Copy to Clipboard Toggle word wrap
    $ chmod 775 ccoctl

検証

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

    Copy to Clipboard Toggle word wrap
    $ ./ccoctl.rhel9

    出力例

    Copy to Clipboard Toggle word wrap
    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 バイナリーを抽出して準備している。

手順

  1. 次のコマンドを実行して、インストールファイルのリリースイメージを $RELEASE_IMAGE 変数に設定します。

    Copy to Clipboard Toggle word wrap
    $ RELEASE_IMAGE=$(./openshift-install version | awk '/release image/ {print $3}')
  2. 以下のコマンドを実行して、OpenShift Container Platform リリースイメージから CredentialsRequest オブジェクトのリストを抽出します。

    Copy to Clipboard Toggle word wrap
    $ oc adm release extract \
      --from=$RELEASE_IMAGE \
      --credentials-requests \
      --included \
    1
    
      --install-config=<path_to_directory_with_installation_configuration>/install-config.yaml \
    2
    
      --to=<path_to_directory_for_credentials_requests> 
    3
    1
    --included パラメーターには、特定のクラスター設定に必要なマニフェストのみが含まれます。
    2
    install-config.yaml ファイルの場所を指定します。
    3
    CredentialsRequest オブジェクトを保存するディレクトリーへのパスを指定します。指定したディレクトリーが存在しない場合は、このコマンドによって作成されます。
    注記

    このコマンドの実行には少し時間がかかる場合があります。

  3. 次のコマンドを実行し、ccoctl ツールを使用して CredentialsRequest オブジェクトをすべて処理します。

    Copy to Clipboard Toggle word wrap
    $ 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 Toggle word wrap
    $ ls <path_to_ccoctl_output_dir>/manifests

    出力例

    Copy to Clipboard Toggle word wrap
    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 バイナリーを展開して準備しておく。

手順

  1. 次のコマンドを実行して、クラスターの OpenID Connect プロバイダーを設定するために使用されるパブリックおよびプライベート RSA キーファイルを生成します。

    Copy to Clipboard Toggle word wrap
    $ ccoctl aws create-key-pair

    出力例

    Copy to Clipboard Toggle word wrap
    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 に作成します。

  2. 次のコマンドを実行して、AWS 上に OpenID Connect ID プロバイダーと S3 バケットを作成します。

    Copy to Clipboard Toggle word wrap
    $ ccoctl aws create-identity-provider \
      --name=<name> \
    1
    
      --region=<aws_region> \
    2
    
      --public-key-file=<path_to_ccoctl_output_dir>/serviceaccount-signer.public 
    3
    1
    <name> は、追跡用に作成されたクラウドリソースにタグを付けるために使用される名前です。
    2
    <aws_region> は、クラウドリソースが作成される AWS リージョンです。
    3
    <path_to_ccoctl_output_dir> は、ccoctl aws create-key-pair コマンドが生成したパブリックキーファイルへのパスです。

    出力例

    Copy to Clipboard Toggle word wrap
    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 フィールドを設定します。

  3. クラスターの各コンポーネントについて IAM ロールを作成します。

    1. 次のコマンドを実行して、インストールファイルのリリースイメージを $RELEASE_IMAGE 変数に設定します。

      Copy to Clipboard Toggle word wrap
      $ RELEASE_IMAGE=$(./openshift-install version | awk '/release image/ {print $3}')
    2. OpenShift Container Platform リリースイメージから CredentialsRequest オブジェクトの一覧を抽出します。

      Copy to Clipboard Toggle word wrap
      $ oc adm release extract \
        --from=$RELEASE_IMAGE \
        --credentials-requests \
        --included \
      1
      
        --install-config=<path_to_directory_with_installation_configuration>/install-config.yaml \
      2
      
        --to=<path_to_directory_for_credentials_requests> 
      3
      1
      --included パラメーターには、特定のクラスター設定に必要なマニフェストのみが含まれます。
      2
      install-config.yaml ファイルの場所を指定します。
      3
      CredentialsRequest オブジェクトを保存するディレクトリーへのパスを指定します。指定したディレクトリーが存在しない場合は、このコマンドによって作成されます。
    3. 次のコマンドを実行し、ccoctl ツールを使用して CredentialsRequest オブジェクトをすべて処理します。

      Copy to Clipboard Toggle word wrap
      $ 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 Toggle word wrap
    $ ls <path_to_ccoctl_output_dir>/manifests

    出力例

    Copy to Clipboard Toggle word wrap
    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 ユーティリティーを使用して、クラスターに必要なクラウドプロバイダーリソースを作成している。

手順

  1. install-config.yaml 設定ファイルの credentialsMode パラメーターを Manual に設定しなかった場合は、次のように値を変更します。

    設定ファイルのサンプルスニペット

    Copy to Clipboard Toggle word wrap
    apiVersion: v1
    baseDomain: example.com
    credentialsMode: Manual
    # ...

  2. インストールマニフェストファイルをまだ作成していない場合は、次のコマンドを実行して作成します。

    Copy to Clipboard Toggle word wrap
    $ openshift-install create manifests --dir <installation_directory>

    ここで、<installation_directory> は、インストールプログラムがファイルを作成するディレクトリーに置き換えます。

  3. 次のコマンドを実行して、ccoctl ユーティリティーが生成したマニフェストを、インストールプログラムが作成した manifests ディレクトリーにコピーします。

    Copy to Clipboard Toggle word wrap
    $ cp /<path_to_ccoctl_output_dir>/manifests/* ./manifests/
  4. 秘密鍵を含む tls ディレクトリーをインストールディレクトリーにコピーします。

    Copy to Clipboard Toggle word wrap
    $ 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) のフィールドは以下の表で説明されています。

表4.3 Cluster Network Operator 設定オブジェクト
フィールド説明

metadata.name

string

CNO オブジェクトの名前。この名前は常に cluster です。

spec.clusterNetwork

array

Pod ID アドレスの割り当て、サブネット接頭辞の長さのクラスター内の個別ノードへの割り当てに使用される IP アドレスのブロックを指定するリストです。以下に例を示します。

Copy to Clipboard Toggle word wrap
spec:
  clusterNetwork:
  - cidr: 10.128.0.0/19
    hostPrefix: 23
  - cidr: 10.128.32.0/19
    hostPrefix: 23

spec.serviceNetwork

array

サービスの IP アドレスのブロック。OpenShift SDN および OVN-Kubernetes ネットワークプラグインは、サービスネットワークの単一 IP アドレスブロックのみをサポートします。以下に例を示します。

Copy to Clipboard Toggle word wrap
spec:
  serviceNetwork:
  - 172.30.0.0/14

マニフェストを作成する前に、このフィールドを install-config.yaml ファイルでのみカスタマイズすることができます。この値は、マニフェストファイルでは読み取り専用です。

spec.defaultNetwork

object

クラスターネットワークのネットワークプラグインを設定します。

spec.kubeProxyConfig

object

このオブジェクトのフィールドは、kube-proxy 設定を指定します。OVN-Kubernetes クラスターネットワークプラグインを使用している場合、kube-proxy 設定は機能しません。

defaultNetwork オブジェクト設定

defaultNetwork オブジェクトの値は、以下の表で定義されます。

表4.4 defaultNetwork オブジェクト
フィールド説明

type

string

OVNKubernetes。Red Hat OpenShift Networking ネットワークプラグインは、インストール中に選択されます。この値は、クラスターのインストール後は変更できません。

注記

OpenShift Container Platform は、デフォルトで OVN-Kubernetes ネットワークプラグインを使用します。OpenShift SDN は、新しいクラスターのインストールの選択肢として利用できなくなりました。

ovnKubernetesConfig

object

このオブジェクトは、OVN-Kubernetes ネットワークプラグインに対してのみ有効です。

OVN-Kubernetes ネットワークプラグインの設定

次の表では、OVN-Kubernetes ネットワークプラグインの設定フィールドを説明します。

表4.5 ovnKubernetesConfig オブジェクト
フィールド説明

mtu

integer

Geneve (Generic Network Virtualization Encapsulation) オーバーレイネットワークの MTU (maximum transmission unit)。これは、プライマリーネットワークインターフェイスの MTU に基づいて自動的に検出されます。通常、検出された MTU を上書きする必要はありません。

自動検出した値が予想される値ではない場合は、ノード上のプライマリーネットワークインターフェイスの MTU が正しいことを確認します。このオプションを使用して、ノード上のプライマリーネットワークインターフェイスの MTU 値を変更することはできません。

クラスターで異なるノードに異なる MTU 値が必要な場合、この値をクラスター内の最小の MTU 値よりも 100 小さく設定する必要があります。たとえば、クラスター内の一部のノードでは MTU が 9001 であり、MTU が 1500 のクラスターもある場合には、この値を 1400 に設定する必要があります。

genevePort

integer

すべての Geneve パケットに使用するポート。デフォルト値は 6081 です。この値は、クラスターのインストール後は変更できません。

ipsecConfig

object

IPsec 設定をカスタマイズするための設定オブジェクトを指定します。

policyAuditConfig

object

ネットワークポリシー監査ロギングをカスタマイズする設定オブジェクトを指定します。指定されていない場合は、デフォルトの監査ログ設定が使用されます。

gatewayConfig

object

オプション: Egress トラフィックのノードゲートウェイへの送信方法をカスタマイズするための設定オブジェクトを指定します。

注記

Egress トラフィックの移行中は、Cluster Network Operator (CNO) が変更を正常にロールアウトするまで、ワークロードとサービストラフィックに多少の中断が発生することが予想されます。

v4InternalSubnet

既存のネットワークインフラストラクチャーが 100.64.0.0/16 IPv4 サブネットと重複している場合は、OVN-Kubernetes による内部使用のために別の IP アドレス範囲を指定できます。IP アドレス範囲が、OpenShift Container Platform インストールで使用される他のサブネットと重複しないようにする必要があります。IP アドレス範囲は、クラスターに追加できるノードの最大数より大きくする必要があります。たとえば、clusterNetwork.cidr 値が 10.128.0.0/14 で、clusterNetwork.hostPrefix 値が /23 の場合、ノードの最大数は 2^(23-14)=512 です。

このフィールドは、インストール後に変更できません。

デフォルト値は 100.64.0.0/16 です。

v6InternalSubnet

既存のネットワークインフラストラクチャーが fd98::/48 IPv6 サブネットと重複する場合は、OVN-Kubernetes による内部使用のために別の IP アドレス範囲を指定できます。IP アドレス範囲が、OpenShift Container Platform インストールで使用される他のサブネットと重複しないようにする必要があります。IP アドレス範囲は、クラスターに追加できるノードの最大数より大きくする必要があります。

このフィールドは、インストール後に変更できません。

デフォルト値は fd98::/48 です。

表4.6 policyAuditConfig オブジェクト
フィールド説明

rateLimit

integer

ノードごとに毎秒生成されるメッセージの最大数。デフォルト値は、1 秒あたり 20 メッセージです。

maxFileSize

integer

監査ログの最大サイズ (バイト単位)。デフォルト値は 50000000 (50MB) です。

maxLogFiles

integer

保持されるログファイルの最大数。

比較先

string

以下の追加の監査ログターゲットのいずれかになります。

libc
ホスト上の journald プロセスの libc syslog() 関数。
udp:<host>:<port>
syslog サーバー。<host>:<port> を syslog サーバーのホストおよびポートに置き換えます。
unix:<file>
<file> で指定された Unix ドメインソケットファイル。
null
監査ログを追加のターゲットに送信しないでください。

syslogFacility

string

RFC5424 で定義される kern などの syslog ファシリティー。デフォルト値は local0 です。

表4.7 gatewayConfig オブジェクト
フィールド説明

routingViaHost

boolean

Pod からホストネットワークスタックへの Egress トラフィックを送信するには、このフィールドを true に設定します。インストールおよびアプリケーションがカーネルルーティングテーブルに手動設定されたルートに依存するなど非常に特化されている場合には、Egress トラフィックをホストネットワークスタックにルーティングすることを推奨します。デフォルトでは、Egress トラフィックは OVN で処理され、クラスターを終了するために処理され、トラフィックはカーネルルーティングテーブルの特殊なルートによる影響を受けません。デフォルト値は false です。

このフィールドで、Open vSwitch ハードウェアオフロード機能との対話が可能になりました。このフィールドをtrueに設定すると、Egress トラフィックがホストネットワークスタックで処理されるため、パフォーマンス的に、オフロードによる利点は得られません。

ipForwarding

object

Network リソースの ipForwarding 仕様を使用して、OVN-Kubernetes マネージドインターフェイス上のすべてのトラフィックの IP フォワーディングを制御できます。Kubernetes 関連のトラフィックの IP フォワーディングのみを許可するには、Restricted を指定します。すべての IP トラフィックの転送を許可するには、Global を指定します。新規インストールの場合、デフォルトは Restricted です。OpenShift Container Platform 4.14 以降に更新する場合、デフォルトは Global です。

表4.8 ipsecConfig オブジェクト
フィールド説明

mode

string

IPsec 実装の動作を指定します。次の値のいずれかである必要があります。

  • Disabled: クラスターノードで IPsec が有効になりません。
  • External: 外部ホストとのネットワークトラフィックに対して IPsec が有効になります。
  • Full: Pod トラフィックおよび外部ホストとのネットワークトラフィックに対して IPsec が有効になります。

IPsec が有効な OVN-Kubernetes 設定の例

Copy to Clipboard Toggle word wrap
defaultNetwork:
  type: OVNKubernetes
  ovnKubernetesConfig:
    mtu: 1400
    genevePort: 6081
      ipsecConfig:
        mode: Full

重要

OVNKubernetes を使用すると、IBM Power® でスタック枯渇の問題が発生する可能性があります。

kubeProxyConfig オブジェクト設定 (OpenShiftSDN コンテナーネットワークインターフェイスのみ)

kubeProxyConfig オブジェクトの値は以下の表で定義されます。

表4.9 kubeProxyConfig オブジェクト
フィールド説明

iptablesSyncPeriod

string

iptables ルールの更新期間。デフォルト値は 30s です。有効な接尾辞には、sm、および h などが含まれ、これらについては、Go time パッケージ ドキュメントで説明されています。

注記

OpenShift Container Platform 4.3 以降で強化されたパフォーマンスの向上により、iptablesSyncPeriod パラメーターを調整する必要はなくなりました。

proxyArguments.iptables-min-sync-period

array

iptables ルールを更新する前の最小期間。このフィールドにより、更新の頻度が高くなり過ぎないようにできます。有効な接尾辞には、sm、および h などが含まれ、これらについては、Go time パッケージ で説明されています。デフォルト値:

Copy to Clipboard Toggle word wrap
kubeProxyConfig:
  proxyArguments:
    iptables-min-sync-period:
    - 0s

4.5.10. 高度なネットワーク設定の指定

ネットワークプラグインに高度なネットワーク設定を使用し、クラスターを既存のネットワーク環境に統合することができます。高度なネットワーク設定は、クラスターのインストール前にのみ指定することができます。

重要

インストールプロブラムで作成される OpenShift Container Platform マニフェストファイルを変更してネットワーク設定をカスタマイズすることは、サポートされていません。以下の手順のように、作成するマニフェストファイルを適用することがサポートされています。

前提条件

  • install-config.yaml ファイルを作成し、これに対する変更を完了している。

手順

  1. インストールプログラムが含まれるディレクトリーに切り替え、マニフェストを作成します。

    Copy to Clipboard Toggle word wrap
    $ ./openshift-install create manifests --dir <installation_directory> 
    1
    1
    <installation_directory> は、クラスターの install-config.yaml ファイルが含まれるディレクトリーの名前を指定します。
  2. cluster-network-03-config.yml という名前の、高度なネットワーク設定用のスタブマニフェストファイルを <installation_directory>/manifests/ ディレクトリーに作成します。

    Copy to Clipboard Toggle word wrap
    apiVersion: operator.openshift.io/v1
    kind: Network
    metadata:
      name: cluster
    spec:
  3. 次の例のように、cluster-network-03-config.yml ファイルでクラスターの高度なネットワーク設定を指定します。

    OVN-Kubernetes ネットワークプロバイダーの IPsec を有効にする

    Copy to Clipboard Toggle word wrap
    apiVersion: operator.openshift.io/v1
    kind: Network
    metadata:
      name: cluster
    spec:
      defaultNetwork:
        ovnKubernetesConfig:
          ipsecConfig:
            mode: Full

  4. オプション: 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 を作成します。

  1. インストールプログラムが含まれるディレクトリーに切り替え、マニフェストを作成します。

    Copy to Clipboard Toggle word wrap
    $ ./openshift-install create manifests --dir <installation_directory> 
    1
    1
    <installation_directory> については、クラスターの install-config.yaml ファイルが含まれるディレクトリーの名前を指定します。
  2. cluster-ingress-default-ingresscontroller.yaml という名前のファイルを <installation_directory>/manifests/ ディレクトリーに作成します。

    Copy to Clipboard Toggle word wrap
    $ touch <installation_directory>/manifests/cluster-ingress-default-ingresscontroller.yaml 
    1
    1
    <installation_directory> については、クラスターの manifests/ ディレクトリーが含まれるディレクトリー名を指定します。

    ファイルの作成後は、以下のようにいくつかのネットワーク設定ファイルが manifests/ ディレクトリーに置かれます。

    Copy to Clipboard Toggle word wrap
    $ ls <installation_directory>/manifests/cluster-ingress-default-ingresscontroller.yaml

    出力例

    Copy to Clipboard Toggle word wrap
    cluster-ingress-default-ingresscontroller.yaml

  3. エディターで cluster-ingress-default-ingresscontroller.yaml ファイルを開き、必要な Operator 設定を記述するカスタムリソース (CR) を入力します。

    Copy to Clipboard Toggle word wrap
    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
  4. cluster-ingress-default-ingresscontroller.yaml ファイルを保存し、テキストエディターを終了します。
  5. オプション: 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 ネットワークのカスタマイズの設定に関するインストールドキュメントを参照してください。

手順

  1. インストールプログラムが含まれるディレクトリーに切り替え、マニフェストを作成します。

    Copy to Clipboard Toggle word wrap
    $ ./openshift-install create manifests --dir <installation_directory>

    ここでは、以下のようになります。

    <installation_directory>
    クラスターの install-config.yaml ファイルが含まれるディレクトリーの名前を指定します。
  2. cluster-network-03-config.yml という名前の、高度なネットワーク設定用のスタブマニフェストファイルを <installation_directory>/manifests/ ディレクトリーに作成します。

    Copy to Clipboard Toggle word wrap
    $ 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/ ディレクトリーが含まれるディレクトリー名を指定します。
  3. cluster-network-03-config.yml ファイルをエディターで開き、以下の例のようにハイブリッドネットワークで OVN-Kubernetes を設定します。

    ハイブリッドネットワーク設定の指定

    Copy to Clipboard Toggle word wrap
    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 値を持つクラスターではサポートされません。

  4. cluster-network-03-config.yml ファイルを保存し、テキストエディターを終了します。
  5. オプション: manifests/cluster-network-03-config.yml ファイルをバックアップします。インストールプログラムは、クラスターの作成時に manifests/ ディレクトリーを削除します。
注記

同じクラスターで Linux ノードと Windows ノードを使用する方法の詳細は、Windows コンテナーワークロードについて を参照してください。

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

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

重要

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

前提条件

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

手順

  1. インストールプログラムが含まれるディレクトリーに切り替え、クラスターのデプロイメントを初期化します。

    Copy to Clipboard Toggle word wrap
    $ ./openshift-install create cluster --dir <installation_directory> \ 
    1
    
        --log-level=info 
    2
    1
    <installation_directory> については、カスタマイズした ./install-config.yaml ファイルの場所を指定します。
    2
    異なるインストールの詳細情報を表示するには、info ではなく、warndebug、または error を指定します。
  2. オプション: クラスターのインストールに使用した IAM アカウントから AdministratorAccess ポリシーを削除するか、無効にします。

    注記

    AdministratorAccess ポリシーが提供する昇格したパーミッションはインストール時にのみ必要です。

検証

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

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

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

出力例

Copy to Clipboard Toggle word wrap
...
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 をインストールしていること。

手順

  1. kubeadmin 認証情報をエクスポートします。

    Copy to Clipboard Toggle word wrap
    $ export KUBECONFIG=<installation_directory>/auth/kubeconfig 
    1
    1
    <installation_directory> には、インストールファイルを保存したディレクトリーへのパスを指定します。
  2. エクスポートされた設定を使用して、oc コマンドを正常に実行できることを確認します。

    Copy to Clipboard Toggle word wrap
    $ oc whoami

    出力例

    Copy to Clipboard Toggle word wrap
    system:admin

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

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

前提条件

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

手順

  1. インストールホストで kubeadmin-password ファイルから kubeadmin ユーザーのパスワードを取得します。

    Copy to Clipboard Toggle word wrap
    $ cat <installation_directory>/auth/kubeadmin-password
    注記

    または、インストールホストで <installation_directory>/.openshift_install.log ログファイルから kubeadmin パスワードを取得できます。

  2. OpenShift Container Platform Web コンソールルートをリスト表示します。

    Copy to Clipboard Toggle word wrap
    $ oc get routes -n openshift-console | grep 'console-openshift'
    注記

    または、インストールホストで <installation_directory>/.openshift_install.log ログファイルからで OpenShift Container Platform ルートを取得できます。

    出力例

    Copy to Clipboard Toggle word wrap
    console     console-openshift-console.apps.<cluster_name>.<base_domain>            console     https   reencrypt/Redirect   None

  3. Web ブラウザーで前述のコマンドの出力で詳細に説明されたルートに移動し、kubeadmin ユーザーとしてログインします。

関連情報

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 サブスクリプションを追跡します。

関連情報

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/.*: ownedNameopenshift.io/cluster タグを使用できません。

    インストールプログラムは kubernetes.io/cluster/.*: shared タグを追加するようにサブネットを変更するため、サブネットでは 1 つ以上の空のタグスロットが利用可能である必要があります。AWS ドキュメントで タグ制限 を確認し、インストールプログラムでタグを指定する各サブネットに追加できるようにします。Name タグは EC2 Name フィールドと重複し、その結果インストールが失敗するため、使用できません。

  • 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

  • AWS::EC2::VPC
  • AWS::EC2::VPCEndpoint

使用するクラスターのパブリック VPC を指定する必要があります。VPC は、各サブネットのルートテーブルを参照するエンドポイントを使用して、S3 でホストされているレジストリーとの通信を強化します。

パブリックサブネット

  • AWS::EC2::Subnet
  • AWS::EC2::SubnetNetworkAclAssociation

VPC には 1 から 3 のアベイラビリティーゾーンのパブリックサブネットが必要であり、それらを適切な Ingress ルールに関連付ける必要があります。

インターネットゲートウェイ

  • AWS::EC2::InternetGateway
  • AWS::EC2::VPCGatewayAttachment
  • AWS::EC2::RouteTable
  • AWS::EC2::Route
  • AWS::EC2::SubnetRouteTableAssociation
  • AWS::EC2::NatGateway
  • AWS::EC2::EIP

VPC に割り当てられたパブリックルートを持つパブリックインターネットゲートウェイが必要です。提供されるテンプレートでは、各パブリックサブネットに EIP アドレスと NAT ゲートウェイがあります。これらの NAT ゲートウェイは、プライベートサブネットインスタンスなどのクラスターリソースがインターネットに到達できるようにするもので、一部のネットワークが制限された環境またはプロキシーのシナリオでは必要ありません。

ネットワークアクセス制御

  • AWS::EC2::NetworkAcl
  • AWS::EC2::NetworkAclEntry

VPC が以下のポートにアクセスできるようにする必要があります。

ポート

理由

80

インバウンド HTTP トラフィック

443

インバウンド HTTPS トラフィック

22

インバウンド SSH トラフィック

1024 - 65535

インバウンド一時 (ephemeral) トラフィック

0 - 65535

アウトバウンド一時 (ephemeral) トラフィック

プライベートサブネット

  • AWS::EC2::Subnet
  • AWS::EC2::RouteTable
  • AWS::EC2::SubnetRouteTableAssociation

VPC にはプライベートサブネットを使用できます。提供される CloudFormation テンプレートは 1 から 3 アベイラビリティーゾーンのプライベートサブネットを作成できます。プライベートサブネットを使用できる場合は、それらの適切なルートおよびテーブルを指定する必要があります。

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

手順

  1. クラスターノードへの認証に使用するローカルマシンに既存の SSH キーペアがない場合は、これを作成します。たとえば、Linux オペレーティングシステムを使用するコンピューターで以下のコマンドを実行します。

    Copy to Clipboard Toggle word wrap
    $ ssh-keygen -t ed25519 -N '' -f <path>/<file_name> 
    1
    1
    新しい SSH キーのパスとファイル名 (~/.ssh/id_ed25519 など) を指定します。既存のキーペアがある場合は、公開鍵が ~/.ssh ディレクトリーにあることを確認します。
    注記

    x86_64ppc64le、および s390x アーキテクチャーのみで FIPS 140-2/140-3 検証のために NIST に提出された RHEL 暗号化ライブラリーを使用する OpenShift Container Platform クラスターをインストールする予定がある場合は、ed25519 アルゴリズムを使用するキーを作成しないでください。代わりに、rsa アルゴリズムまたは ecdsa アルゴリズムを使用するキーを作成します。

  2. 公開 SSH キーを表示します。

    Copy to Clipboard Toggle word wrap
    $ cat <path>/<file_name>.pub

    たとえば、次のコマンドを実行して ~/.ssh/id_ed25519.pub 公開鍵を表示します。

    Copy to Clipboard Toggle word wrap
    $ cat ~/.ssh/id_ed25519.pub
  3. ローカルユーザーの SSH エージェントに SSH 秘密鍵 ID が追加されていない場合は、それを追加します。キーの SSH エージェント管理は、クラスターノードへのパスワードなしの SSH 認証、または ./openshift-install gather コマンドを使用する場合は必要になります。

    注記

    一部のディストリビューションでは、~/.ssh/id_rsa および ~/.ssh/id_dsa などのデフォルトの SSH 秘密鍵のアイデンティティーは自動的に管理されます。

    1. ssh-agent プロセスがローカルユーザーに対して実行されていない場合は、バックグラウンドタスクとして開始します。

      Copy to Clipboard Toggle word wrap
      $ eval "$(ssh-agent -s)"

      出力例

      Copy to Clipboard Toggle word wrap
      Agent pid 31874

      注記

      クラスターが FIPS モードにある場合は、FIPS 準拠のアルゴリズムのみを使用して SSH キーを生成します。鍵は RSA または ECDSA のいずれかである必要があります。

  4. SSH プライベートキーを ssh-agent に追加します。

    Copy to Clipboard Toggle word wrap
    $ ssh-add <path>/<file_name> 
    1
    1
    ~/.ssh/id_ed25519 などの、SSH プライベートキーのパスおよびファイル名を指定します。

    出力例

    Copy to Clipboard Toggle word wrap
    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 値がある。
  • ミラーレジストリーの証明書の内容を取得している。

手順

  1. install-config.yaml ファイルを作成します。

    1. インストールプログラムが含まれるディレクトリーに切り替え、以下のコマンドを実行します。

      Copy to Clipboard Toggle word wrap
      $ ./openshift-install create install-config --dir <installation_directory> 
      1
      1
      <installation_directory> の場合、インストールプログラムが作成するファイルを保存するためにディレクトリー名を指定します。

      ディレクトリーを指定する場合:

      • ディレクトリーに execute 権限があることを確認します。この権限は、インストールディレクトリーで Terraform バイナリーを実行するために必要です。
      • 空のディレクトリーを使用します。ブートストラップ X.509 証明書などの一部のインストールアセットは有効期限が短いため、インストールディレクトリーを再利用しないでください。別のクラスターインストールの個別のファイルを再利用する必要がある場合は、それらをディレクトリーにコピーすることができます。ただし、インストールアセットのファイル名はリリース間で変更される可能性があります。インストールファイルを以前のバージョンの OpenShift Container Platform からコピーする場合は注意してコピーを行ってください。
    2. プロンプト時に、クラウドの設定の詳細情報を指定します。

      1. オプション: クラスターマシンにアクセスするために使用する SSH キーを選択します。

        注記

        インストールのデバッグまたは障害復旧を実行する必要のある実稼働用の OpenShift Container Platform クラスターでは、ssh-agent プロセスが使用する SSH キーを指定します。

      2. ターゲットに設定するプラットフォームとして AWS を選択します。
      3. Amazon Web Services (AWS) プロファイルをコンピューターに保存していない場合、インストールプログラムを実行するように設定したユーザーの AWS アクセスキー ID およびシークレットアクセスキーを入力します。
      4. クラスターのデプロイ先とする AWS リージョンを選択します。
      5. クラスターに設定した Route 53 サービスのベースドメインを選択します。
      6. クラスターの記述名を入力します。
  2. install-config.yaml ファイルを編集し、ネットワークが制限された環境でのインストールに必要な追加の情報を提供します。

    1. pullSecret の値を更新して、レジストリーの認証情報を追加します。

      Copy to Clipboard Toggle word wrap
      pullSecret: '{"auths":{"<mirror_host_name>:5000": {"auth": "<credentials>","email": "you@example.com"}}}'

      <mirror_host_name> の場合、ミラーレジストリーの証明書で指定したレジストリードメイン名を指定し、<credentials> の場合は、ミラーレジストリーの base64 でエンコードされたユーザー名およびパスワードを指定します。

    2. additionalTrustBundle パラメーターおよび値を追加します。

      Copy to Clipboard Toggle word wrap
      additionalTrustBundle: |
        -----BEGIN CERTIFICATE-----
        ZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZ
        -----END CERTIFICATE-----

      この値は、ミラーレジストリーに使用した証明書ファイルの内容である必要があります。証明書ファイルは、既存の信頼できる認証局、またはミラーレジストリー用に生成した自己署名証明書のいずれかです。

    3. クラスターをインストールする VPC のサブネットを定義します。

      Copy to Clipboard Toggle word wrap
      subnets:
      - subnet-1
      - subnet-2
      - subnet-3
    4. 次の YAML の抜粋のようなイメージコンテンツリソースを追加します。

      Copy to Clipboard Toggle word wrap
      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 を使用します。

    5. オプション: パブリッシュストラテジーを Internal に設定します。

      Copy to Clipboard Toggle word wrap
      publish: Internal

      このオプションを設定すると、内部 Ingress コントローラーおよびプライベートロードバランサーを作成します。

  3. 必要な install-config.yaml ファイルに他の変更を加えます。

    パラメーターの詳細は、「インストール設定パラメーター」を参照してください。

  4. install-config.yaml ファイルをバックアップし、複数のクラスターをインストールするのに使用できるようにします。

    重要

    install-config.yaml ファイルはインストールプロセス時に使用されます。このファイルを再利用する必要がある場合は、この段階でこれをバックアップしてください。

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

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

表4.10 最小リソース要件
マシンオペレーティングシステム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. 1 vCPU は、同時マルチスレッド (SMT) またはハイパースレッディングが有効にされていない場合に 1 つの物理コアと同等です。これが有効にされている場合、数式「(コアごとのスレッド × コア数) × ソケット数 = 仮想 CPU」を使用して対応する比率を計算します。
  2. OpenShift Container Platform および Kubernetes はディスクのパフォーマンスに敏感であり、特に 10 ms p99 fsync 期間を必要とするコントロールプレーンノード上の etcd については、高速ストレージが推奨されます。多くのクラウドプラットフォームでは、ストレージサイズと IOPS スケールが一緒にあるため、十分なパフォーマンスを得るためにストレージボリュームの割り当てが必要になる場合があります。
  3. すべての 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 ファイルを取得し、これを変更する必要があります。

Copy to Clipboard Toggle word wrap
apiVersion: v1
baseDomain: example.com 
1

credentialsMode: Mint 
2

controlPlane: 
3
 
4

  hyperthreading: Enabled 
5

  name: master
  platform:
    aws:
      zones:
      - us-west-2a
      - us-west-2b
      rootVolume:
        iops: 4000
        size: 500
        type: io1 
6

      metadataService:
        authentication: Optional 
7

      type: m6i.xlarge
  replicas: 3
compute: 
8

- hyperthreading: Enabled 
9

  name: worker
  platform:
    aws:
      rootVolume:
        iops: 2000
        size: 500
        type: io1 
10

      metadataService:
        authentication: Optional 
11

      type: c5.4xlarge
      zones:
      - us-west-2c
  replicas: 3
metadata:
  name: test-cluster 
12

networking:
  clusterNetwork:
  - cidr: 10.128.0.0/14
    hostPrefix: 23
  machineNetwork:
  - cidr: 10.0.0.0/16
  networkType: OVNKubernetes 
13

  serviceNetwork:
  - 172.30.0.0/16
platform:
  aws:
    region: us-west-2 
14

    propagateUserTags: true 
15

    userTags:
      adminContact: jdoe
      costCenter: 7536
    subnets: 
16

    - subnet-1
    - subnet-2
    - subnet-3
    amiID: ami-0c5d3e03c0ab9b19a 
17

    serviceEndpoints: 
18

      - name: ec2
        url: https://vpce-id.ec2.us-west-2.vpce.amazonaws.com
    hostedZone: Z3URY6TWQ91KVV 
19

fips: false 
20

sshKey: ssh-ed25519 AAAA... 
21

pullSecret: '{"auths":{"<local_registry>": {"auth": "<credentials>","email": "you@example.com"}}}' 
22

additionalTrustBundle: | 
23

    -----BEGIN CERTIFICATE-----
    <MY_TRUSTED_CA_CERT>
    -----END CERTIFICATE-----
imageContentSources: 
24

- 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 として設定し、iops2000 に設定します。
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[].cidrnetworking.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) も設定されます。

手順

  1. install-config.yaml ファイルを編集し、プロキシー設定を追加します。以下に例を示します。

    Copy to Clipboard Toggle word wrap
    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.comx.y.com に一致しますが、y.com には一致しません。* を使用し、すべての宛先のプロキシーをバイパスします。Amazon EC2Elastic 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 Toggle word wrap
    $ ./openshift-install wait-for install-complete --log-level debug
  2. ファイルを保存し、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 にインストールできます。

手順

  1. Red Hat カスタマーポータルの OpenShift Container Platform ダウンロードページ に移動します。
  2. Product Variant ドロップダウンリストからアーキテクチャーを選択します。
  3. バージョン ドロップダウンリストから適切なバージョンを選択します。
  4. OpenShift v4.15 Linux Client エントリーの横にある Download Now をクリックして、ファイルを保存します。
  5. アーカイブを展開します。

    Copy to Clipboard Toggle word wrap
    $ tar xvf <file>
  6. oc バイナリーを、PATH にあるディレクトリーに配置します。

    PATH を確認するには、以下のコマンドを実行します。

    Copy to Clipboard Toggle word wrap
    $ echo $PATH

検証

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

    Copy to Clipboard Toggle word wrap
    $ oc <command>
Windows への OpenShift CLI のインストール

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

手順

  1. Red Hat カスタマーポータルの OpenShift Container Platform ダウンロードページ に移動します。
  2. バージョン ドロップダウンリストから適切なバージョンを選択します。
  3. OpenShift v4.15 Windows Client エントリーの横にある Download Now をクリックして、ファイルを保存します。
  4. ZIP プログラムでアーカイブを展開します。
  5. oc バイナリーを、PATH にあるディレクトリーに移動します。

    PATH を確認するには、コマンドプロンプトを開いて以下のコマンドを実行します。

    Copy to Clipboard Toggle word wrap
    C:\> path

検証

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

    Copy to Clipboard Toggle word wrap
    C:\> oc <command>
macOS への OpenShift CLI のインストール

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

手順

  1. Red Hat カスタマーポータルの OpenShift Container Platform ダウンロードページ に移動します。
  2. バージョン ドロップダウンリストから適切なバージョンを選択します。
  3. OpenShift v4.15 macOS Client エントリーの横にある Download Now をクリックして、ファイルを保存します。

    注記

    macOS arm64 の場合は、OpenShift v4.15 macOS arm64 Client エントリーを選択します。

  4. アーカイブを展開し、解凍します。
  5. oc バイナリーをパスにあるディレクトリーに移動します。

    PATH を確認するには、ターミナルを開き、以下のコマンドを実行します。

    Copy to Clipboard Toggle word wrap
    $ echo $PATH

検証

  • oc コマンドを使用してインストールを確認します。

    Copy to Clipboard Toggle word wrap
    $ oc <command>

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

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

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

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

手順

  1. install-config.yaml 設定ファイルの credentialsMode パラメーターを Manual に設定しなかった場合は、次のように値を変更します。

    設定ファイルのサンプルスニペット

    Copy to Clipboard Toggle word wrap
    apiVersion: v1
    baseDomain: example.com
    credentialsMode: Manual
    # ...

  2. インストールマニフェストファイルをまだ作成していない場合は、次のコマンドを実行して作成します。

    Copy to Clipboard Toggle word wrap
    $ openshift-install create manifests --dir <installation_directory>

    ここで、<installation_directory> は、インストールプログラムがファイルを作成するディレクトリーに置き換えます。

  3. 次のコマンドを実行して、インストールファイルのリリースイメージを $RELEASE_IMAGE 変数に設定します。

    Copy to Clipboard Toggle word wrap
    $ RELEASE_IMAGE=$(./openshift-install version | awk '/release image/ {print $3}')
  4. 以下のコマンドを実行して、OpenShift Container Platform リリースイメージから CredentialsRequest カスタムリソース (CR) のリストを抽出します。

    Copy to Clipboard Toggle word wrap
    $ oc adm release extract \
      --from=$RELEASE_IMAGE \
      --credentials-requests \
      --included \
    1
    
      --install-config=<path_to_directory_with_installation_configuration>/install-config.yaml \
    2
    
      --to=<path_to_directory_for_credentials_requests> 
    3
    1
    --included パラメーターには、特定のクラスター設定に必要なマニフェストのみが含まれます。
    2
    install-config.yaml ファイルの場所を指定します。
    3
    CredentialsRequest オブジェクトを保存するディレクトリーへのパスを指定します。指定したディレクトリーが存在しない場合は、このコマンドによって作成されます。

    このコマンドにより、それぞれの CredentialsRequest オブジェクトに YAML ファイルが作成されます。

    サンプル CredentialsRequest オブジェクト

    Copy to Clipboard Toggle word wrap
    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: "*"
      ...

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

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

    Copy to Clipboard Toggle word wrap
    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 Toggle word wrap
    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 オプションの使用をサポートします。

手順

  1. 次のコマンドを実行して、OpenShift Container Platform リリースイメージの変数を設定します。

    Copy to Clipboard Toggle word wrap
    $ RELEASE_IMAGE=$(./openshift-install version | awk '/release image/ {print $3}')
  2. 以下のコマンドを実行して、OpenShift Container Platform リリースイメージから CCO コンテナーイメージを取得します。

    Copy to Clipboard Toggle word wrap
    $ CCO_IMAGE=$(oc adm release info --image-for='cloud-credential-operator' $RELEASE_IMAGE -a ~/.pull-secret)
    注記

    $RELEASE_IMAGE のアーキテクチャーが、ccoctlツールを使用する環境のアーキテクチャーと一致していることを確認してください。

  3. 以下のコマンドを実行して、OpenShift Container Platform リリースイメージ内の CCO コンテナーイメージから ccoctl バイナリーを抽出します。

    Copy to Clipboard Toggle word wrap
    $ oc image extract $CCO_IMAGE --file="/usr/bin/ccoctl" -a ~/.pull-secret
  4. 次のコマンドを実行して、権限を変更して ccoctl を実行可能にします。

    Copy to Clipboard Toggle word wrap
    $ chmod 775 ccoctl

検証

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

    Copy to Clipboard Toggle word wrap
    $ ./ccoctl.rhel9

    出力例

    Copy to Clipboard Toggle word wrap
    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 バイナリーを抽出して準備している。

手順

  1. 次のコマンドを実行して、インストールファイルのリリースイメージを $RELEASE_IMAGE 変数に設定します。

    Copy to Clipboard Toggle word wrap
    $ RELEASE_IMAGE=$(./openshift-install version | awk '/release image/ {print $3}')
  2. 以下のコマンドを実行して、OpenShift Container Platform リリースイメージから CredentialsRequest オブジェクトのリストを抽出します。

    Copy to Clipboard Toggle word wrap
    $ oc adm release extract \
      --from=$RELEASE_IMAGE \
      --credentials-requests \
      --included \
    1
    
      --install-config=<path_to_directory_with_installation_configuration>/install-config.yaml \
    2
    
      --to=<path_to_directory_for_credentials_requests> 
    3
    1
    --included パラメーターには、特定のクラスター設定に必要なマニフェストのみが含まれます。
    2
    install-config.yaml ファイルの場所を指定します。
    3
    CredentialsRequest オブジェクトを保存するディレクトリーへのパスを指定します。指定したディレクトリーが存在しない場合は、このコマンドによって作成されます。
    注記

    このコマンドの実行には少し時間がかかる場合があります。

  3. 次のコマンドを実行し、ccoctl ツールを使用して CredentialsRequest オブジェクトをすべて処理します。

    Copy to Clipboard Toggle word wrap
    $ 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 Toggle word wrap
    $ ls <path_to_ccoctl_output_dir>/manifests

    出力例

    Copy to Clipboard Toggle word wrap
    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 バイナリーを展開して準備しておく。

手順

  1. 次のコマンドを実行して、クラスターの OpenID Connect プロバイダーを設定するために使用されるパブリックおよびプライベート RSA キーファイルを生成します。

    Copy to Clipboard Toggle word wrap
    $ ccoctl aws create-key-pair

    出力例

    Copy to Clipboard Toggle word wrap
    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 に作成します。

  2. 次のコマンドを実行して、AWS 上に OpenID Connect ID プロバイダーと S3 バケットを作成します。

    Copy to Clipboard Toggle word wrap
    $ ccoctl aws create-identity-provider \
      --name=<name> \
    1
    
      --region=<aws_region> \
    2
    
      --public-key-file=<path_to_ccoctl_output_dir>/serviceaccount-signer.public 
    3
    1
    <name> は、追跡用に作成されたクラウドリソースにタグを付けるために使用される名前です。
    2
    <aws_region> は、クラウドリソースが作成される AWS リージョンです。
    3
    <path_to_ccoctl_output_dir> は、ccoctl aws create-key-pair コマンドが生成したパブリックキーファイルへのパスです。

    出力例

    Copy to Clipboard Toggle word wrap
    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 フィールドを設定します。

  3. クラスターの各コンポーネントについて IAM ロールを作成します。

    1. 次のコマンドを実行して、インストールファイルのリリースイメージを $RELEASE_IMAGE 変数に設定します。

      Copy to Clipboard Toggle word wrap
      $ RELEASE_IMAGE=$(./openshift-install version | awk '/release image/ {print $3}')
    2. OpenShift Container Platform リリースイメージから CredentialsRequest オブジェクトの一覧を抽出します。

      Copy to Clipboard Toggle word wrap
      $ oc adm release extract \
        --from=$RELEASE_IMAGE \
        --credentials-requests \
        --included \
      1
      
        --install-config=<path_to_directory_with_installation_configuration>/install-config.yaml \
      2
      
        --to=<path_to_directory_for_credentials_requests> 
      3
      1
      --included パラメーターには、特定のクラスター設定に必要なマニフェストのみが含まれます。
      2
      install-config.yaml ファイルの場所を指定します。
      3
      CredentialsRequest オブジェクトを保存するディレクトリーへのパスを指定します。指定したディレクトリーが存在しない場合は、このコマンドによって作成されます。
    3. 次のコマンドを実行し、ccoctl ツールを使用して CredentialsRequest オブジェクトをすべて処理します。

      Copy to Clipboard Toggle word wrap
      $ 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 Toggle word wrap
    $ ls <path_to_ccoctl_output_dir>/manifests

    出力例

    Copy to Clipboard Toggle word wrap
    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 ユーティリティーを使用して、クラスターに必要なクラウドプロバイダーリソースを作成している。

手順

  1. install-config.yaml 設定ファイルの credentialsMode パラメーターを Manual に設定しなかった場合は、次のように値を変更します。

    設定ファイルのサンプルスニペット

    Copy to Clipboard Toggle word wrap
    apiVersion: v1
    baseDomain: example.com
    credentialsMode: Manual
    # ...

  2. インストールマニフェストファイルをまだ作成していない場合は、次のコマンドを実行して作成します。

    Copy to Clipboard Toggle word wrap
    $ openshift-install create manifests --dir <installation_directory>

    ここで、<installation_directory> は、インストールプログラムがファイルを作成するディレクトリーに置き換えます。

  3. 次のコマンドを実行して、ccoctl ユーティリティーが生成したマニフェストを、インストールプログラムが作成した manifests ディレクトリーにコピーします。

    Copy to Clipboard Toggle word wrap
    $ cp /<path_to_ccoctl_output_dir>/manifests/* ./manifests/
  4. 秘密鍵を含む tls ディレクトリーをインストールディレクトリーにコピーします。

    Copy to Clipboard Toggle word wrap
    $ cp -a /<path_to_ccoctl_output_dir>/tls .

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

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

重要

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

前提条件

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

手順

  1. インストールプログラムが含まれるディレクトリーに切り替え、クラスターのデプロイメントを初期化します。

    Copy to Clipboard Toggle word wrap
    $ ./openshift-install create cluster --dir <installation_directory> \ 
    1
    
        --log-level=info 
    2
    1
    <installation_directory> については、カスタマイズした ./install-config.yaml ファイルの場所を指定します。
    2
    異なるインストールの詳細情報を表示するには、info ではなく、warndebug、または error を指定します。
  2. オプション: クラスターのインストールに使用した IAM アカウントから AdministratorAccess ポリシーを削除するか、無効にします。

    注記

    AdministratorAccess ポリシーが提供する昇格したパーミッションはインストール時にのみ必要です。

検証

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

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

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

出力例

Copy to Clipboard Toggle word wrap
...
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 をインストールしていること。

手順

  1. kubeadmin 認証情報をエクスポートします。

    Copy to Clipboard Toggle word wrap
    $ export KUBECONFIG=<installation_directory>/auth/kubeconfig 
    1
    1
    <installation_directory> には、インストールファイルを保存したディレクトリーへのパスを指定します。
  2. エクスポートされた設定を使用して、oc コマンドを正常に実行できることを確認します。

    Copy to Clipboard Toggle word wrap
    $ oc whoami

    出力例

    Copy to Clipboard Toggle word wrap
    system:admin

4.6.11. デフォルトの OperatorHub カタログソースの無効化

Red Hat によって提供されるコンテンツを調達する Operator カタログおよびコミュニティープロジェクトは、OpenShift Container Platform のインストール時にデフォルトで OperatorHub に設定されます。ネットワークが制限された環境では、クラスター管理者としてデフォルトのカタログを無効にする必要があります。

手順

  • disableAllDefaultSources: trueOperatorHub オブジェクトに追加して、デフォルトカタログのソースを無効にします。

    Copy to Clipboard Toggle word wrap
    $ oc patch OperatorHub cluster --type json \
        -p '[{"op": "add", "path": "/spec/disableAllDefaultSources", "value": true}]'
ヒント

または、Web コンソールを使用してカタログソースを管理できます。AdministrationCluster SettingsConfigurationOperatorHub ページから、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 サブスクリプションを追跡します。

関連情報

4.6.13. 次のステップ

4.7. AWS のクラスターの既存 VPC へのインストール

OpenShift Container Platform バージョン 4.15 では、Amazon Web Services (AWS) 上の既存の Amazon Virtual Private Cloud (VPC) にクラスターをインストールできます。インストールプログラムは、カスタマイズ可能な残りの必要なインフラストラクチャーをプロビジョニングします。インストールをカスタマイズするには、クラスターをインストールする前に、install-config.yaml ファイルでパラメーターを変更します。

4.7.1. 前提条件

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/.*: ownedNameopenshift.io/cluster タグを使用できません。

    インストールプログラムは kubernetes.io/cluster/.*: shared タグを追加するようにサブネットを変更するため、サブネットでは 1 つ以上の空のタグスロットが利用可能である必要があります。AWS ドキュメントで タグ制限 を確認し、インストールプログラムでタグを指定する各サブネットに追加できるようにします。Name タグは EC2 Name フィールドと重複し、その結果インストールが失敗するため、使用できません。

  • 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

  • AWS::EC2::VPC
  • AWS::EC2::VPCEndpoint

使用するクラスターのパブリック VPC を指定する必要があります。VPC は、各サブネットのルートテーブルを参照するエンドポイントを使用して、S3 でホストされているレジストリーとの通信を強化します。

パブリックサブネット

  • AWS::EC2::Subnet
  • AWS::EC2::SubnetNetworkAclAssociation

VPC には 1 から 3 のアベイラビリティーゾーンのパブリックサブネットが必要であり、それらを適切な Ingress ルールに関連付ける必要があります。

インターネットゲートウェイ

  • AWS::EC2::InternetGateway
  • AWS::EC2::VPCGatewayAttachment
  • AWS::EC2::RouteTable
  • AWS::EC2::Route
  • AWS::EC2::SubnetRouteTableAssociation
  • AWS::EC2::NatGateway
  • AWS::EC2::EIP

VPC に割り当てられたパブリックルートを持つパブリックインターネットゲートウェイが必要です。提供されるテンプレートでは、各パブリックサブネットに EIP アドレスと NAT ゲートウェイがあります。これらの NAT ゲートウェイは、プライベートサブネットインスタンスなどのクラスターリソースがインターネットに到達できるようにするもので、一部のネットワークが制限された環境またはプロキシーのシナリオでは必要ありません。

ネットワークアクセス制御

  • AWS::EC2::NetworkAcl
  • AWS::EC2::NetworkAclEntry

VPC が以下のポートにアクセスできるようにする必要があります。

ポート

理由

80

インバウンド HTTP トラフィック

443

インバウンド HTTPS トラフィック

22

インバウンド SSH トラフィック

1024 - 65535

インバウンド一時 (ephemeral) トラフィック

0 - 65535

アウトバウンド一時 (ephemeral) トラフィック

プライベートサブネット

  • AWS::EC2::Subnet
  • AWS::EC2::RouteTable
  • AWS::EC2::SubnetRouteTableAssociation

VPC にはプライベートサブネットを使用できます。提供される CloudFormation テンプレートは 1 から 3 アベイラビリティーゾーンのプライベートサブネットを作成できます。プライベートサブネットを使用できる場合は、それらの適切なルートおよびテーブルを指定する必要があります。

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.2.6. 共有 VPC にインストールする場合の信頼ポリシーの変更

共有 VPC を使用してクラスターをインストールする場合は、Passthrough または Manual 認証情報モードを使用できます。クラスターをインストールするために使用される IAM ロールを、VPC を所有するアカウントの信頼ポリシーのプリンシパルとして追加する必要があります。

Passthrough モードを使用する場合は、クラスターを作成するアカウントの Amazon Resource Name (ARN) (arn:aws:iam::123456789012:user/clustercreator など) をプリンシパルとして信頼ポリシーに追加します。

Manual モードを使用する場合は、クラスターを作成するアカウントの ARN と、クラスター所有者アカウントの Ingress オペレーターロールの ARN (arn:aws:iam::123456789012:role/<cluster-name>-openshift-ingress-operator-cloud-credentials など) をプリンシパルとして信頼ポリシーに追加します。

次のアクションをポリシーに追加する必要があります。

例4.27 共有 VPC のインストールに必要なアクション

  • route53:ChangeResourceRecordSets
  • route53:ListHostedZones
  • route53:ListHostedZonesByName
  • route53:ListResourceRecordSets
  • route53:ChangeTagsForResource
  • route53:GetAccountLimit
  • route53:GetChange
  • route53:GetHostedZone
  • route53:ListTagsForResource
  • route53:UpdateHostedZoneComment
  • tag:GetResources
  • tag:UntagResources

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

手順

  1. クラスターノードへの認証に使用するローカルマシンに既存の SSH キーペアがない場合は、これを作成します。たとえば、Linux オペレーティングシステムを使用するコンピューターで以下のコマンドを実行します。

    Copy to Clipboard Toggle word wrap
    $ ssh-keygen -t ed25519 -N '' -f <path>/<file_name> 
    1
    1
    新しい SSH キーのパスとファイル名 (~/.ssh/id_ed25519 など) を指定します。既存のキーペアがある場合は、公開鍵が ~/.ssh ディレクトリーにあることを確認します。
    注記

    x86_64ppc64le、および s390x アーキテクチャーのみで FIPS 140-2/140-3 検証のために NIST に提出された RHEL 暗号化ライブラリーを使用する OpenShift Container Platform クラスターをインストールする予定がある場合は、ed25519 アルゴリズムを使用するキーを作成しないでください。代わりに、rsa アルゴリズムまたは ecdsa アルゴリズムを使用するキーを作成します。

  2. 公開 SSH キーを表示します。

    Copy to Clipboard Toggle word wrap
    $ cat <path>/<file_name>.pub

    たとえば、次のコマンドを実行して ~/.ssh/id_ed25519.pub 公開鍵を表示します。

    Copy to Clipboard Toggle word wrap
    $ cat ~/.ssh/id_ed25519.pub
  3. ローカルユーザーの SSH エージェントに SSH 秘密鍵 ID が追加されていない場合は、それを追加します。キーの SSH エージェント管理は、クラスターノードへのパスワードなしの SSH 認証、または ./openshift-install gather コマンドを使用する場合は必要になります。

    注記

    一部のディストリビューションでは、~/.ssh/id_rsa および ~/.ssh/id_dsa などのデフォルトの SSH 秘密鍵のアイデンティティーは自動的に管理されます。

    1. ssh-agent プロセスがローカルユーザーに対して実行されていない場合は、バックグラウンドタスクとして開始します。

      Copy to Clipboard Toggle word wrap
      $ eval "$(ssh-agent -s)"

      出力例

      Copy to Clipboard Toggle word wrap
      Agent pid 31874

      注記

      クラスターが FIPS モードにある場合は、FIPS 準拠のアルゴリズムのみを使用して SSH キーを生成します。鍵は RSA または ECDSA のいずれかである必要があります。

  4. SSH プライベートキーを ssh-agent に追加します。

    Copy to Clipboard Toggle word wrap
    $ ssh-add <path>/<file_name> 
    1
    1
    ~/.ssh/id_ed25519 などの、SSH プライベートキーのパスおよびファイル名を指定します。

    出力例

    Copy to Clipboard Toggle word wrap
    Identity added: /home/<you>/<path>/<file_name> (<computer_name>)

次のステップ

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

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

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

前提条件

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

手順

  1. OpenShift Cluster Manager サイトの インフラストラクチャープロバイダー ページにアクセスします。Red Hat アカウントがある場合は、認証情報を使用してログインします。アカウントがない場合はこれを作成します。
  2. インフラストラクチャープロバイダーを選択します。
  3. インストールタイプのページに移動し、ホストオペレーティングシステムとアーキテクチャーに対応するインストールプログラムをダウンロードして、インストール設定ファイルを保存するディレクトリーにファイルを配置します。

    重要

    インストールプログラムは、クラスターのインストールに使用するコンピューターにいくつかのファイルを作成します。クラスターのインストール完了後は、インストールプログラムおよびインストールプログラムが作成するファイルを保持する必要があります。ファイルはいずれもクラスターを削除するために必要になります。

    重要

    インストールプログラムで作成されたファイルを削除しても、クラスターがインストール時に失敗した場合でもクラスターは削除されません。クラスターを削除するには、特定のクラウドプロバイダー用の OpenShift Container Platform のアンインストール手順を実行します。

  4. インストールプログラムを展開します。たとえば、Linux オペレーティングシステムを使用するコンピューターで以下のコマンドを実行します。

    Copy to Clipboard Toggle word wrap
    $ tar -xvf openshift-install-linux.tar.gz
  5. Red Hat OpenShift Cluster Manager からインストールプルシークレット をダウンロードします。このプルシークレットを使用し、OpenShift Container Platform コンポーネントのコンテナーイメージを提供する Quay.io など、組み込まれた各種の認証局によって提供されるサービスで認証できます。

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

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

前提条件

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

手順

  1. install-config.yaml ファイルを作成します。

    1. インストールプログラムが含まれるディレクトリーに切り替え、以下のコマンドを実行します。

      Copy to Clipboard Toggle word wrap
      $ ./openshift-install create install-config --dir <installation_directory> 
      1
      1
      <installation_directory> の場合、インストールプログラムが作成するファイルを保存するためにディレクトリー名を指定します。

      ディレクトリーを指定する場合:

      • ディレクトリーに execute 権限があることを確認します。この権限は、インストールディレクトリーで Terraform バイナリーを実行するために必要です。
      • 空のディレクトリーを使用します。ブートストラップ X.509 証明書などの一部のインストールアセットは有効期限が短いため、インストールディレクトリーを再利用しないでください。別のクラスターインストールの個別のファイルを再利用する必要がある場合は、それらをディレクトリーにコピーすることができます。ただし、インストールアセットのファイル名はリリース間で変更される可能性があります。インストールファイルを以前のバージョンの OpenShift Container Platform からコピーする場合は注意してコピーを行ってください。
    2. プロンプト時に、クラウドの設定の詳細情報を指定します。

      1. オプション: クラスターマシンにアクセスするために使用する SSH キーを選択します。

        注記

        インストールのデバッグまたは障害復旧を実行する必要のある実稼働用の OpenShift Container Platform クラスターでは、ssh-agent プロセスが使用する SSH キーを指定します。

      2. ターゲットに設定するプラットフォームとして AWS を選択します。
      3. Amazon Web Services (AWS) プロファイルをコンピューターに保存していない場合、インストールプログラムを実行するように設定したユーザーの AWS アクセスキー ID およびシークレットアクセスキーを入力します。
      4. クラスターのデプロイ先とする AWS リージョンを選択します。
      5. クラスターに設定した Route 53 サービスのベースドメインを選択します。
      6. クラスターの記述名を入力します。
  2. install-config.yaml ファイルを変更します。利用可能なパラメーターの詳細は、「インストール設定パラメーター」のセクションを参照してください。
  3. install-config.yaml ファイルをバックアップし、複数のクラスターをインストールするのに使用できるようにします。

    重要

    install-config.yaml ファイルはインストールプロセス時に使用されます。このファイルを再利用する必要がある場合は、この段階でこれをバックアップしてください。

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

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

表4.11 最小リソース要件
マシンオペレーティングシステム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. 1 vCPU は、同時マルチスレッド (SMT) またはハイパースレッディングが有効にされていない場合に 1 つの物理コアと同等です。これが有効にされている場合、数式「(コアごとのスレッド × コア数) × ソケット数 = 仮想 CPU」を使用して対応する比率を計算します。
  2. OpenShift Container Platform および Kubernetes はディスクのパフォーマンスに敏感であり、特に 10 ms p99 fsync 期間を必要とするコントロールプレーンノード上の etcd については、高速ストレージが推奨されます。多くのクラウドプラットフォームでは、ストレージサイズと IOPS スケールが一緒にあるため、十分なパフォーマンスを得るためにストレージボリュームの割り当てが必要になる場合があります。
  3. すべての 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 ファイルを取得し、これを変更する必要があります。

Copy to Clipboard Toggle word wrap
apiVersion: v1
baseDomain: example.com 
1

credentialsMode: Mint 
2

controlPlane: 
3
 
4

  hyperthreading: Enabled 
5

  name: master
  platform:
    aws:
      zones:
      - us-west-2a
      - us-west-2b
      rootVolume:
        iops: 4000
        size: 500
        type: io1 
6

      metadataService:
        authentication: Optional 
7

      type: m6i.xlarge
  replicas: 3
compute: 
8

- hyperthreading: Enabled 
9

  name: worker
  platform:
    aws:
      rootVolume:
        iops: 2000
        size: 500
        type: io1 
10

      metadataService:
        authentication: Optional 
11

      type: c5.4xlarge
      zones:
      - us-west-2c
  replicas: 3
metadata:
  name: test-cluster 
12

networking:
  clusterNetwork:
  - cidr: 10.128.0.0/14
    hostPrefix: 23
  machineNetwork:
  - cidr: 10.0.0.0/16
  networkType: OVNKubernetes 
13

  serviceNetwork:
  - 172.30.0.0/16
platform:
  aws:
    region: us-west-2 
14

    propagateUserTags: true 
15

    userTags:
      adminContact: jdoe
      costCenter: 7536
    subnets: 
16

    - subnet-1
    - subnet-2
    - subnet-3
    amiID: ami-0c5d3e03c0ab9b19a 
17

    serviceEndpoints: 
18

      - name: ec2
        url: https://vpce-id.ec2.us-west-2.vpce.amazonaws.com
    hostedZone: Z3URY6TWQ91KVV 
19

fips: false 
20

sshKey: ssh-ed25519 AAAA... 
21

pullSecret: '{"auths": ...}' 
22
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 として設定し、iops2000 に設定します。
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[].cidrnetworking.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) も設定されます。

手順

  1. install-config.yaml ファイルを編集し、プロキシー設定を追加します。以下に例を示します。

    Copy to Clipboard Toggle word wrap
    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.comx.y.com に一致しますが、y.com には一致しません。* を使用し、すべての宛先のプロキシーをバイパスします。Amazon EC2Elastic 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 Toggle word wrap
    $ ./openshift-install wait-for install-complete --log-level debug
  2. ファイルを保存し、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 ファイルがある。

手順

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

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

Copy to Clipboard Toggle word wrap
# ...
compute:
- hyperthreading: Enabled
  name: worker
  platform:
    aws:
      additionalSecurityGroupIDs:
        - sg-1 
1

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

      - subnet-1
      - subnet-2
      - subnet-3

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

4.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 にインストールできます。

手順

  1. Red Hat カスタマーポータルの OpenShift Container Platform ダウンロードページ に移動します。
  2. Product Variant ドロップダウンリストからアーキテクチャーを選択します。
  3. バージョン ドロップダウンリストから適切なバージョンを選択します。
  4. OpenShift v4.15 Linux Client エントリーの横にある Download Now をクリックして、ファイルを保存します。
  5. アーカイブを展開します。

    Copy to Clipboard Toggle word wrap
    $ tar xvf <file>
  6. oc バイナリーを、PATH にあるディレクトリーに配置します。

    PATH を確認するには、以下のコマンドを実行します。

    Copy to Clipboard Toggle word wrap
    $ echo $PATH

検証

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

    Copy to Clipboard Toggle word wrap
    $ oc <command>
Windows への OpenShift CLI のインストール

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

手順

  1. Red Hat カスタマーポータルの OpenShift Container Platform ダウンロードページ に移動します。
  2. バージョン ドロップダウンリストから適切なバージョンを選択します。
  3. OpenShift v4.15 Windows Client エントリーの横にある Download Now をクリックして、ファイルを保存します。
  4. ZIP プログラムでアーカイブを展開します。
  5. oc バイナリーを、PATH にあるディレクトリーに移動します。

    PATH を確認するには、コマンドプロンプトを開いて以下のコマンドを実行します。

    Copy to Clipboard Toggle word wrap
    C:\> path

検証

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

    Copy to Clipboard Toggle word wrap
    C:\> oc <command>
macOS への OpenShift CLI のインストール

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

手順

  1. Red Hat カスタマーポータルの OpenShift Container Platform ダウンロードページ に移動します。
  2. バージョン ドロップダウンリストから適切なバージョンを選択します。
  3. OpenShift v4.15 macOS Client エントリーの横にある Download Now をクリックして、ファイルを保存します。

    注記

    macOS arm64 の場合は、OpenShift v4.15 macOS arm64 Client エントリーを選択します。

  4. アーカイブを展開し、解凍します。
  5. oc バイナリーをパスにあるディレクトリーに移動します。

    PATH を確認するには、ターミナルを開き、以下のコマンドを実行します。

    Copy to Clipboard Toggle word wrap
    $ echo $PATH

検証

  • oc コマンドを使用してインストールを確認します。

    Copy to Clipboard Toggle word wrap
    $ oc <command>

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

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

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

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

手順

  1. install-config.yaml 設定ファイルの credentialsMode パラメーターを Manual に設定しなかった場合は、次のように値を変更します。

    設定ファイルのサンプルスニペット

    Copy to Clipboard Toggle word wrap
    apiVersion: v1
    baseDomain: example.com
    credentialsMode: Manual
    # ...

  2. インストールマニフェストファイルをまだ作成していない場合は、次のコマンドを実行して作成します。

    Copy to Clipboard Toggle word wrap
    $ openshift-install create manifests --dir <installation_directory>

    ここで、<installation_directory> は、インストールプログラムがファイルを作成するディレクトリーに置き換えます。

  3. 次のコマンドを実行して、インストールファイルのリリースイメージを $RELEASE_IMAGE 変数に設定します。

    Copy to Clipboard Toggle word wrap
    $ RELEASE_IMAGE=$(./openshift-install version | awk '/release image/ {print $3}')
  4. 以下のコマンドを実行して、OpenShift Container Platform リリースイメージから CredentialsRequest カスタムリソース (CR) のリストを抽出します。

    Copy to Clipboard Toggle word wrap
    $ oc adm release extract \
      --from=$RELEASE_IMAGE \
      --credentials-requests \
      --included \
    1
    
      --install-config=<path_to_directory_with_installation_configuration>/install-config.yaml \
    2
    
      --to=<path_to_directory_for_credentials_requests> 
    3
    1
    --included パラメーターには、特定のクラスター設定に必要なマニフェストのみが含まれます。
    2
    install-config.yaml ファイルの場所を指定します。
    3
    CredentialsRequest オブジェクトを保存するディレクトリーへのパスを指定します。指定したディレクトリーが存在しない場合は、このコマンドによって作成されます。

    このコマンドにより、それぞれの CredentialsRequest オブジェクトに YAML ファイルが作成されます。

    サンプル CredentialsRequest オブジェクト

    Copy to Clipboard Toggle word wrap
    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: "*"
      ...

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

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

    Copy to Clipboard Toggle word wrap
    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 Toggle word wrap
    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 オプションの使用をサポートします。

手順

  1. 次のコマンドを実行して、OpenShift Container Platform リリースイメージの変数を設定します。

    Copy to Clipboard Toggle word wrap
    $ RELEASE_IMAGE=$(./openshift-install version | awk '/release image/ {print $3}')
  2. 以下のコマンドを実行して、OpenShift Container Platform リリースイメージから CCO コンテナーイメージを取得します。

    Copy to Clipboard Toggle word wrap
    $ CCO_IMAGE=$(oc adm release info --image-for='cloud-credential-operator' $RELEASE_IMAGE -a ~/.pull-secret)
    注記

    $RELEASE_IMAGE のアーキテクチャーが、ccoctlツールを使用する環境のアーキテクチャーと一致していることを確認してください。

  3. 以下のコマンドを実行して、OpenShift Container Platform リリースイメージ内の CCO コンテナーイメージから ccoctl バイナリーを抽出します。

    Copy to Clipboard Toggle word wrap
    $ oc image extract $CCO_IMAGE --file="/usr/bin/ccoctl" -a ~/.pull-secret
  4. 次のコマンドを実行して、権限を変更して ccoctl を実行可能にします。

    Copy to Clipboard Toggle word wrap
    $ chmod 775 ccoctl

検証

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

    Copy to Clipboard Toggle word wrap
    $ ./ccoctl.rhel9

    出力例

    Copy to Clipboard Toggle word wrap
    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 バイナリーを抽出して準備している。

手順

  1. 次のコマンドを実行して、インストールファイルのリリースイメージを $RELEASE_IMAGE 変数に設定します。

    Copy to Clipboard Toggle word wrap
    $ RELEASE_IMAGE=$(./openshift-install version | awk '/release image/ {print $3}')
  2. 以下のコマンドを実行して、OpenShift Container Platform リリースイメージから CredentialsRequest オブジェクトのリストを抽出します。

    Copy to Clipboard Toggle word wrap
    $ oc adm release extract \
      --from=$RELEASE_IMAGE \
      --credentials-requests \
      --included \
    1
    
      --install-config=<path_to_directory_with_installation_configuration>/install-config.yaml \
    2
    
      --to=<path_to_directory_for_credentials_requests> 
    3
    1
    --included パラメーターには、特定のクラスター設定に必要なマニフェストのみが含まれます。
    2
    install-config.yaml ファイルの場所を指定します。
    3
    CredentialsRequest オブジェクトを保存するディレクトリーへのパスを指定します。指定したディレクトリーが存在しない場合は、このコマンドによって作成されます。
    注記

    このコマンドの実行には少し時間がかかる場合があります。

  3. 次のコマンドを実行し、ccoctl ツールを使用して CredentialsRequest オブジェクトをすべて処理します。

    Copy to Clipboard Toggle word wrap
    $ 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 Toggle word wrap
    $ ls <path_to_ccoctl_output_dir>/manifests

    出力例

    Copy to Clipboard Toggle word wrap
    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 バイナリーを展開して準備しておく。

手順

  1. 次のコマンドを実行して、クラスターの OpenID Connect プロバイダーを設定するために使用されるパブリックおよびプライベート RSA キーファイルを生成します。

    Copy to Clipboard Toggle word wrap
    $ ccoctl aws create-key-pair

    出力例

    Copy to Clipboard Toggle word wrap
    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 に作成します。

  2. 次のコマンドを実行して、AWS 上に OpenID Connect ID プロバイダーと S3 バケットを作成します。

    Copy to Clipboard Toggle word wrap
    $ ccoctl aws create-identity-provider \
      --name=<name> \
    1
    
      --region=<aws_region> \
    2
    
      --public-key-file=<path_to_ccoctl_output_dir>/serviceaccount-signer.public 
    3
    1
    <name> は、追跡用に作成されたクラウドリソースにタグを付けるために使用される名前です。
    2
    <aws_region> は、クラウドリソースが作成される AWS リージョンです。
    3
    <path_to_ccoctl_output_dir> は、ccoctl aws create-key-pair コマンドが生成したパブリックキーファイルへのパスです。

    出力例

    Copy to Clipboard Toggle word wrap
    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 フィールドを設定します。

  3. クラスターの各コンポーネントについて IAM ロールを作成します。

    1. 次のコマンドを実行して、インストールファイルのリリースイメージを $RELEASE_IMAGE 変数に設定します。

      Copy to Clipboard Toggle word wrap
      $ RELEASE_IMAGE=$(./openshift-install version | awk '/release image/ {print $3}')
    2. OpenShift Container Platform リリースイメージから CredentialsRequest オブジェクトの一覧を抽出します。

      Copy to Clipboard Toggle word wrap
      $ oc adm release extract \
        --from=$RELEASE_IMAGE \
        --credentials-requests \
        --included \
      1
      
        --install-config=<path_to_directory_with_installation_configuration>/install-config.yaml \
      2
      
        --to=<path_to_directory_for_credentials_requests> 
      3
      1
      --included パラメーターには、特定のクラスター設定に必要なマニフェストのみが含まれます。
      2
      install-config.yaml ファイルの場所を指定します。
      3
      CredentialsRequest オブジェクトを保存するディレクトリーへのパスを指定します。指定したディレクトリーが存在しない場合は、このコマンドによって作成されます。
    3. 次のコマンドを実行し、ccoctl ツールを使用して CredentialsRequest オブジェクトをすべて処理します。

      Copy to Clipboard Toggle word wrap
      $ 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 Toggle word wrap
    $ ls <path_to_ccoctl_output_dir>/manifests

    出力例

    Copy to Clipboard Toggle word wrap
    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 ユーティリティーを使用して、クラスターに必要なクラウドプロバイダーリソースを作成している。

手順

  1. install-config.yaml 設定ファイルの credentialsMode パラメーターを Manual に設定しなかった場合は、次のように値を変更します。

    設定ファイルのサンプルスニペット

    Copy to Clipboard Toggle word wrap
    apiVersion: v1
    baseDomain: example.com
    credentialsMode: Manual
    # ...

  2. インストールマニフェストファイルをまだ作成していない場合は、次のコマンドを実行して作成します。

    Copy to Clipboard Toggle word wrap
    $ openshift-install create manifests --dir <installation_directory>

    ここで、<installation_directory> は、インストールプログラムがファイルを作成するディレクトリーに置き換えます。

  3. 次のコマンドを実行して、ccoctl ユーティリティーが生成したマニフェストを、インストールプログラムが作成した manifests ディレクトリーにコピーします。

    Copy to Clipboard Toggle word wrap
    $ cp /<path_to_ccoctl_output_dir>/manifests/* ./manifests/
  4. 秘密鍵を含む tls ディレクトリーをインストールディレクトリーにコピーします。

    Copy to Clipboard Toggle word wrap
    $ cp -a /<path_to_ccoctl_output_dir>/tls .

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

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

重要

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

前提条件

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

手順

  1. インストールプログラムが含まれるディレクトリーに切り替え、クラスターのデプロイメントを初期化します。

    Copy to Clipboard Toggle word wrap
    $ ./openshift-install create cluster --dir <installation_directory> \ 
    1
    
        --log-level=info 
    2
    1
    <installation_directory> については、カスタマイズした ./install-config.yaml ファイルの場所を指定します。
    2
    異なるインストールの詳細情報を表示するには、info ではなく、warndebug、または error を指定します。
  2. オプション: クラスターのインストールに使用した IAM アカウントから AdministratorAccess ポリシーを削除するか、無効にします。

    注記

    AdministratorAccess ポリシーが提供する昇格したパーミッションはインストール時にのみ必要です。

検証

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

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

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

出力例

Copy to Clipboard Toggle word wrap
...
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 をインストールしていること。

手順

  1. kubeadmin 認証情報をエクスポートします。

    Copy to Clipboard Toggle word wrap
    $ export KUBECONFIG=<installation_directory>/auth/kubeconfig 
    1
    1
    <installation_directory> には、インストールファイルを保存したディレクトリーへのパスを指定します。
  2. エクスポートされた設定を使用して、oc コマンドを正常に実行できることを確認します。

    Copy to Clipboard Toggle word wrap
    $ oc whoami

    出力例

    Copy to Clipboard Toggle word wrap
    system:admin

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

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

前提条件

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

手順

  1. インストールホストで kubeadmin-password ファイルから kubeadmin ユーザーのパスワードを取得します。

    Copy to Clipboard Toggle word wrap
    $ cat <installation_directory>/auth/kubeadmin-password
    注記

    または、インストールホストで <installation_directory>/.openshift_install.log ログファイルから kubeadmin パスワードを取得できます。

  2. OpenShift Container Platform Web コンソールルートをリスト表示します。

    Copy to Clipboard Toggle word wrap
    $ oc get routes -n openshift-console | grep 'console-openshift'
    注記

    または、インストールホストで <installation_directory>/.openshift_install.log ログファイルからで OpenShift Container Platform ルートを取得できます。

    出力例

    Copy to Clipboard Toggle word wrap
    console     console-openshift-console.apps.<cluster_name>.<base_domain>            console     https   reencrypt/Redirect   None

  3. Web ブラウザーで前述のコマンドの出力で詳細に説明されたルートに移動し、kubeadmin ユーザーとしてログインします。

関連情報

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 サブスクリプションを追跡します。

関連情報

4.7.13. 次のステップ

4.8. プライベートクラスターの AWS へのインストール

OpenShift Container Platform バージョン 4.15 では、Amazon Web Services (AWS) 上の既存の VPC にプライベートクラスターをインストールできます。インストールプログラムは、カスタマイズ可能な残りの必要なインフラストラクチャーをプロビジョニングします。インストールをカスタマイズするには、クラスターをインストールする前に、install-config.yaml ファイルでパラメーターを変更します。

4.8.1. 前提条件

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/.*: ownedNameopenshift.io/cluster タグを使用できません。

    インストールプログラムは kubernetes.io/cluster/.*: shared タグを追加するようにサブネットを変更するため、サブネットでは 1 つ以上の空のタグスロットが利用可能である必要があります。AWS ドキュメントで タグ制限 を確認し、インストールプログラムでタグを指定する各サブネットに追加できるようにします。Name タグは EC2 Name フィールドと重複し、その結果インストールが失敗するため、使用できません。

  • 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

  • AWS::EC2::VPC
  • AWS::EC2::VPCEndpoint

使用するクラスターのパブリック VPC を指定する必要があります。VPC は、各サブネットのルートテーブルを参照するエンドポイントを使用して、S3 でホストされているレジストリーとの通信を強化します。

パブリックサブネット

  • AWS::EC2::Subnet
  • AWS::EC2::SubnetNetworkAclAssociation

VPC には 1 から 3 のアベイラビリティーゾーンのパブリックサブネットが必要であり、それらを適切な Ingress ルールに関連付ける必要があります。

インターネットゲートウェイ

  • AWS::EC2::InternetGateway
  • AWS::EC2::VPCGatewayAttachment
  • AWS::EC2::RouteTable
  • AWS::EC2::Route
  • AWS::EC2::SubnetRouteTableAssociation
  • AWS::EC2::NatGateway
  • AWS::EC2::EIP

VPC に割り当てられたパブリックルートを持つパブリックインターネットゲートウェイが必要です。提供されるテンプレートでは、各パブリックサブネットに EIP アドレスと NAT ゲートウェイがあります。これらの NAT ゲートウェイは、プライベートサブネットインスタンスなどのクラスターリソースがインターネットに到達できるようにするもので、一部のネットワークが制限された環境またはプロキシーのシナリオでは必要ありません。

ネットワークアクセス制御

  • AWS::EC2::NetworkAcl
  • AWS::EC2::NetworkAclEntry

VPC が以下のポートにアクセスできるようにする必要があります。

ポート

理由

80

インバウンド HTTP トラフィック

443

インバウンド HTTPS トラフィック

22

インバウンド SSH トラフィック

1024 - 65535

インバウンド一時 (ephemeral) トラフィック

0 - 65535

アウトバウンド一時 (ephemeral) トラフィック

プライベートサブネット

  • AWS::EC2::Subnet
  • AWS::EC2::RouteTable
  • AWS::EC2::SubnetRouteTableAssociation

VPC にはプライベートサブネットを使用できます。提供される CloudFormation テンプレートは 1 から 3 アベイラビリティーゾーンのプライベートサブネットを作成できます。プライベートサブネットを使用できる場合は、それらの適切なルートおよびテーブルを指定する必要があります。

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

手順

  1. クラスターノードへの認証に使用するローカルマシンに既存の SSH キーペアがない場合は、これを作成します。たとえば、Linux オペレーティングシステムを使用するコンピューターで以下のコマンドを実行します。

    Copy to Clipboard Toggle word wrap
    $ ssh-keygen -t ed25519 -N '' -f <path>/<file_name> 
    1
    1
    新しい SSH キーのパスとファイル名 (~/.ssh/id_ed25519 など) を指定します。既存のキーペアがある場合は、公開鍵が ~/.ssh ディレクトリーにあることを確認します。
    注記

    x86_64ppc64le、および s390x アーキテクチャーのみで FIPS 140-2/140-3 検証のために NIST に提出された RHEL 暗号化ライブラリーを使用する OpenShift Container Platform クラスターをインストールする予定がある場合は、ed25519 アルゴリズムを使用するキーを作成しないでください。代わりに、rsa アルゴリズムまたは ecdsa アルゴリズムを使用するキーを作成します。

  2. 公開 SSH キーを表示します。

    Copy to Clipboard Toggle word wrap
    $ cat <path>/<file_name>.pub

    たとえば、次のコマンドを実行して ~/.ssh/id_ed25519.pub 公開鍵を表示します。

    Copy to Clipboard Toggle word wrap
    $ cat ~/.ssh/id_ed25519.pub
  3. ローカルユーザーの SSH エージェントに SSH 秘密鍵 ID が追加されていない場合は、それを追加します。キーの SSH エージェント管理は、クラスターノードへのパスワードなしの SSH 認証、または ./openshift-install gather コマンドを使用する場合は必要になります。

    注記

    一部のディストリビューションでは、~/.ssh/id_rsa および ~/.ssh/id_dsa などのデフォルトの SSH 秘密鍵のアイデンティティーは自動的に管理されます。

    1. ssh-agent プロセスがローカルユーザーに対して実行されていない場合は、バックグラウンドタスクとして開始します。

      Copy to Clipboard Toggle word wrap
      $ eval "$(ssh-agent -s)"

      出力例

      Copy to Clipboard Toggle word wrap
      Agent pid 31874

      注記

      クラスターが FIPS モードにある場合は、FIPS 準拠のアルゴリズムのみを使用して SSH キーを生成します。鍵は RSA または ECDSA のいずれかである必要があります。

  4. SSH プライベートキーを ssh-agent に追加します。

    Copy to Clipboard Toggle word wrap
    $ ssh-add <path>/<file_name> 
    1
    1
    ~/.ssh/id_ed25519 などの、SSH プライベートキーのパスおよびファイル名を指定します。

    出力例

    Copy to Clipboard Toggle word wrap
    Identity added: /home/<you>/<path>/<file_name> (<computer_name>)

次のステップ

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

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

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

前提条件

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

手順

  1. OpenShift Cluster Manager サイトの インフラストラクチャープロバイダー ページにアクセスします。Red Hat アカウントがある場合は、認証情報を使用してログインします。アカウントがない場合はこれを作成します。
  2. インフラストラクチャープロバイダーを選択します。
  3. インストールタイプのページに移動し、ホストオペレーティングシステムとアーキテクチャーに対応するインストールプログラムをダウンロードして、インストール設定ファイルを保存するディレクトリーにファイルを配置します。

    重要

    インストールプログラムは、クラスターのインストールに使用するコンピューターにいくつかのファイルを作成します。クラスターのインストール完了後は、インストールプログラムおよびインストールプログラムが作成するファイルを保持する必要があります。ファイルはいずれもクラスターを削除するために必要になります。

    重要

    インストールプログラムで作成されたファイルを削除しても、クラスターがインストール時に失敗した場合でもクラスターは削除されません。クラスターを削除するには、特定のクラウドプロバイダー用の OpenShift Container Platform のアンインストール手順を実行します。

  4. インストールプログラムを展開します。たとえば、Linux オペレーティングシステムを使用するコンピューターで以下のコマンドを実行します。

    Copy to Clipboard Toggle word wrap
    $ tar -xvf openshift-install-linux.tar.gz
  5. Red Hat OpenShift Cluster Manager からインストールプルシークレット をダウンロードします。このプルシークレットを使用し、OpenShift Container Platform コンポーネントのコンテナーイメージを提供する Quay.io など、組み込まれた各種の認証局によって提供されるサービスで認証できます。

4.8.7. インストール設定ファイルの手動作成

クラスターをインストールするには、インストール設定ファイルを手動で作成する必要があります。

前提条件

  • ローカルマシンには、インストールプログラムに提供する SSH 公開鍵があります。このキーは、デバッグおよび障害復旧のためにクラスターノードへの SSH 認証に使用されます。
  • OpenShift Container Platform インストールプログラムおよびクラスターのプルシークレットを取得しています。

手順

  1. 必要なインストールアセットを保存するためのインストールディレクトリーを作成します。

    Copy to Clipboard Toggle word wrap
    $ mkdir <installation_directory>
    重要

    ディレクトリーを作成する必要があります。ブートストラップ X.509 証明書などの一部のインストールアセットの有効期限は短く設定されているため、インストールディレクトリーを再利用することができません。別のクラスターインストールの個別のファイルを再利用する必要がある場合は、それらをディレクトリーにコピーすることができます。ただし、インストールアセットのファイル名はリリース間で変更される可能性があります。インストールファイルを以前のバージョンの OpenShift Container Platform からコピーする場合は注意してコピーを行ってください。

  2. 提供されるサンプルの install-config.yaml ファイルテンプレートをカスタマイズし、これを <installation_directory> に保存します。

    注記

    この設定ファイルの名前を install-config.yaml と付ける必要があります。

  3. install-config.yaml ファイルをバックアップし、複数のクラスターをインストールするのに使用できるようにします。

    重要

    install-config.yaml ファイルは、インストールプロセスの次の手順で使用されます。この時点でこれをバックアップする必要があります。

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

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

表4.12 最小リソース要件
マシンオペレーティングシステム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. 1 vCPU は、同時マルチスレッド (SMT) またはハイパースレッディングが有効にされていない場合に 1 つの物理コアと同等です。これが有効にされている場合、数式「(コアごとのスレッド × コア数) × ソケット数 = 仮想 CPU」を使用して対応する比率を計算します。
  2. OpenShift Container Platform および Kubernetes はディスクのパフォーマンスに敏感であり、特に 10 ms p99 fsync 期間を必要とするコントロールプレーンノード上の etcd については、高速ストレージが推奨されます。多くのクラウドプラットフォームでは、ストレージサイズと IOPS スケールが一緒にあるため、十分なパフォーマンスを得るためにストレージボリュームの割り当てが必要になる場合があります。
  3. すべての 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 ファイルを取得し、これを変更する必要があります。

Copy to Clipboard Toggle word wrap
apiVersion: v1
baseDomain: example.com 
1

credentialsMode: Mint 
2

controlPlane: 
3
 
4

  hyperthreading: Enabled 
5

  name: master
  platform:
    aws:
      zones:
      - us-west-2a
      - us-west-2b
      rootVolume:
        iops: 4000
        size: 500
        type: io1 
6

      metadataService:
        authentication: Optional 
7

      type: m6i.xlarge
  replicas: 3
compute: 
8

- hyperthreading: Enabled 
9

  name: worker
  platform:
    aws:
      rootVolume:
        iops: 2000
        size: 500
        type: io1 
10

      metadataService:
        authentication: Optional 
11

      type: c5.4xlarge
      zones:
      - us-west-2c
  replicas: 3
metadata:
  name: test-cluster 
12

networking:
  clusterNetwork:
  - cidr: 10.128.0.0/14
    hostPrefix: 23
  machineNetwork:
  - cidr: 10.0.0.0/16
  networkType: OVNKubernetes 
13

  serviceNetwork:
  - 172.30.0.0/16
platform:
  aws:
    region: us-west-2 
14

    propagateUserTags: true 
15

    userTags:
      adminContact: jdoe
      costCenter: 7536
    subnets: 
16

    - subnet-1
    - subnet-2
    - subnet-3
    amiID: ami-0c5d3e03c0ab9b19a 
17

    serviceEndpoints: 
18

      - name: ec2
        url: https://vpce-id.ec2.us-west-2.vpce.amazonaws.com
    hostedZone: Z3URY6TWQ91KVV 
19

fips: false 
20

sshKey: ssh-ed25519 AAAA... 
21

publish: Internal 
22

pullSecret: '{"auths": ...}' 
23
1 12 14 23
必須。インストールプログラムはこの値の入力を求めるプロンプトを出します。
2
オプション: Cloud Credential Operator (CCO) に指定されたモードの使用を強制するには、このパラメーターを追加します。デフォルトでは、CCO は kube-system namespace のルート認証情報を使用して、認証情報の機能を動的に判断しようとします。CCO モードの詳細は、認証および認可 ガイドの「Cloud Credential Operator について」セクションを参照してください。
3 8 15
これらのパラメーターおよび値を指定しない場合、インストールプログラムはデフォルトの値を指定します。
4
controlPlane セクションは単一マッピングですが、compute セクションはマッピングのシーケンスになります。複数の異なるデータ構造の要件を満たすには、compute セクションの最初の行はハイフン - で始め、controlPlane セクションの最初の行はハイフンで始めることができません。1 つのコントロールプレーンプールのみが使用されます。
5 9
同時マルチスレッドまたは hyperthreading を有効/無効にするかどうか。デフォルトでは、同時スレッドはマシンのコアのパフォーマンスを上げるために有効にされます。パラメーター値を Disabled に設定するとこれを無効にすることができます。一部のクラスターマシンで同時マルチスレッドを無効にする場合は、これをすべてのクラスターマシンで無効にする必要があります。
重要

同時スレッドを無効にする場合は、容量計画においてマシンパフォーマンスの大幅な低下が考慮に入れられていることを確認します。同時マルチスレッドを無効にする場合は、マシンに対して m4.2xlarge または m5.2xlarge などの大規模なインスタンスタイプを使用します。

6 10
大規模なクラスターの場合などに etcd の高速のストレージを設定するには、ストレージタイプを io1 として設定し、iops2000 に設定します。
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
クラスターのユーザーに表示されるエンドポイントをパブリッシュする方法。プライベートクラスターをデプロイするには、publishInternal に設定します。これはインターネットからアクセスできません。デフォルト値は 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[].cidrnetworking.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) も設定されます。

手順

  1. install-config.yaml ファイルを編集し、プロキシー設定を追加します。以下に例を示します。

    Copy to Clipboard Toggle word wrap
    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.comx.y.com に一致しますが、y.com には一致しません。* を使用し、すべての宛先のプロキシーをバイパスします。Amazon EC2Elastic 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 Toggle word wrap
    $ ./openshift-install wait-for install-complete --log-level debug
  2. ファイルを保存し、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 ファイルがある。

手順

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

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

Copy to Clipboard Toggle word wrap
# ...
compute:
- hyperthreading: Enabled
  name: worker
  platform:
    aws:
      additionalSecurityGroupIDs:
        - sg-1 
1

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

      - subnet-1
      - subnet-2
      - subnet-3

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

4.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 にインストールできます。

手順

  1. Red Hat カスタマーポータルの OpenShift Container Platform ダウンロードページ に移動します。
  2. Product Variant ドロップダウンリストからアーキテクチャーを選択します。
  3. バージョン ドロップダウンリストから適切なバージョンを選択します。
  4. OpenShift v4.15 Linux Client エントリーの横にある Download Now をクリックして、ファイルを保存します。
  5. アーカイブを展開します。

    Copy to Clipboard Toggle word wrap
    $ tar xvf <file>
  6. oc バイナリーを、PATH にあるディレクトリーに配置します。

    PATH を確認するには、以下のコマンドを実行します。

    Copy to Clipboard Toggle word wrap
    $ echo $PATH

検証

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

    Copy to Clipboard Toggle word wrap
    $ oc <command>
Windows への OpenShift CLI のインストール

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

手順

  1. Red Hat カスタマーポータルの OpenShift Container Platform ダウンロードページ に移動します。
  2. バージョン ドロップダウンリストから適切なバージョンを選択します。
  3. OpenShift v4.15 Windows Client エントリーの横にある Download Now をクリックして、ファイルを保存します。
  4. ZIP プログラムでアーカイブを展開します。
  5. oc バイナリーを、PATH にあるディレクトリーに移動します。

    PATH を確認するには、コマンドプロンプトを開いて以下のコマンドを実行します。

    Copy to Clipboard Toggle word wrap
    C:\> path

検証

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

    Copy to Clipboard Toggle word wrap
    C:\> oc <command>
macOS への OpenShift CLI のインストール

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

手順

  1. Red Hat カスタマーポータルの OpenShift Container Platform ダウンロードページ に移動します。
  2. バージョン ドロップダウンリストから適切なバージョンを選択します。
  3. OpenShift v4.15 macOS Client エントリーの横にある Download Now をクリックして、ファイルを保存します。

    注記

    macOS arm64 の場合は、OpenShift v4.15 macOS arm64 Client エントリーを選択します。

  4. アーカイブを展開し、解凍します。
  5. oc バイナリーをパスにあるディレクトリーに移動します。

    PATH を確認するには、ターミナルを開き、以下のコマンドを実行します。

    Copy to Clipboard Toggle word wrap
    $ echo $PATH

検証

  • oc コマンドを使用してインストールを確認します。

    Copy to Clipboard Toggle word wrap
    $ oc <command>

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

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

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

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

手順

  1. install-config.yaml 設定ファイルの credentialsMode パラメーターを Manual に設定しなかった場合は、次のように値を変更します。

    設定ファイルのサンプルスニペット

    Copy to Clipboard Toggle word wrap
    apiVersion: v1
    baseDomain: example.com
    credentialsMode: Manual
    # ...

  2. インストールマニフェストファイルをまだ作成していない場合は、次のコマンドを実行して作成します。

    Copy to Clipboard Toggle word wrap
    $ openshift-install create manifests --dir <installation_directory>

    ここで、<installation_directory> は、インストールプログラムがファイルを作成するディレクトリーに置き換えます。

  3. 次のコマンドを実行して、インストールファイルのリリースイメージを $RELEASE_IMAGE 変数に設定します。

    Copy to Clipboard Toggle word wrap
    $ RELEASE_IMAGE=$(./openshift-install version | awk '/release image/ {print $3}')
  4. 以下のコマンドを実行して、OpenShift Container Platform リリースイメージから CredentialsRequest カスタムリソース (CR) のリストを抽出します。

    Copy to Clipboard Toggle word wrap
    $ oc adm release extract \
      --from=$RELEASE_IMAGE \
      --credentials-requests \
      --included \
    1
    
      --install-config=<path_to_directory_with_installation_configuration>/install-config.yaml \
    2
    
      --to=<path_to_directory_for_credentials_requests> 
    3
    1
    --included パラメーターには、特定のクラスター設定に必要なマニフェストのみが含まれます。
    2
    install-config.yaml ファイルの場所を指定します。
    3
    CredentialsRequest オブジェクトを保存するディレクトリーへのパスを指定します。指定したディレクトリーが存在しない場合は、このコマンドによって作成されます。

    このコマンドにより、それぞれの CredentialsRequest オブジェクトに YAML ファイルが作成されます。

    サンプル CredentialsRequest オブジェクト

    Copy to Clipboard Toggle word wrap
    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: "*"
      ...

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

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

    Copy to Clipboard Toggle word wrap
    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 Toggle word wrap
    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 オプションの使用をサポートします。

手順

  1. 次のコマンドを実行して、OpenShift Container Platform リリースイメージの変数を設定します。

    Copy to Clipboard Toggle word wrap
    $ RELEASE_IMAGE=$(./openshift-install version | awk '/release image/ {print $3}')
  2. 以下のコマンドを実行して、OpenShift Container Platform リリースイメージから CCO コンテナーイメージを取得します。

    Copy to Clipboard Toggle word wrap
    $ CCO_IMAGE=$(oc adm release info --image-for='cloud-credential-operator' $RELEASE_IMAGE -a ~/.pull-secret)
    注記

    $RELEASE_IMAGE のアーキテクチャーが、ccoctlツールを使用する環境のアーキテクチャーと一致していることを確認してください。

  3. 以下のコマンドを実行して、OpenShift Container Platform リリースイメージ内の CCO コンテナーイメージから ccoctl バイナリーを抽出します。

    Copy to Clipboard Toggle word wrap
    $ oc image extract $CCO_IMAGE --file="/usr/bin/ccoctl" -a ~/.pull-secret
  4. 次のコマンドを実行して、権限を変更して ccoctl を実行可能にします。

    Copy to Clipboard Toggle word wrap
    $ chmod 775 ccoctl

検証

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

    Copy to Clipboard Toggle word wrap
    $ ./ccoctl.rhel9

    出力例

    Copy to Clipboard Toggle word wrap
    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 バイナリーを抽出して準備している。

手順

  1. 次のコマンドを実行して、インストールファイルのリリースイメージを $RELEASE_IMAGE 変数に設定します。

    Copy to Clipboard Toggle word wrap
    $ RELEASE_IMAGE=$(./openshift-install version | awk '/release image/ {print $3}')
  2. 以下のコマンドを実行して、OpenShift Container Platform リリースイメージから CredentialsRequest オブジェクトのリストを抽出します。

    Copy to Clipboard Toggle word wrap
    $ oc adm release extract \
      --from=$RELEASE_IMAGE \
      --credentials-requests \
      --included \
    1
    
      --install-config=<path_to_directory_with_installation_configuration>/install-config.yaml \
    2
    
      --to=<path_to_directory_for_credentials_requests> 
    3
    1
    --included パラメーターには、特定のクラスター設定に必要なマニフェストのみが含まれます。
    2
    install-config.yaml ファイルの場所を指定します。
    3
    CredentialsRequest オブジェクトを保存するディレクトリーへのパスを指定します。指定したディレクトリーが存在しない場合は、このコマンドによって作成されます。
    注記

    このコマンドの実行には少し時間がかかる場合があります。

  3. 次のコマンドを実行し、ccoctl ツールを使用して CredentialsRequest オブジェクトをすべて処理します。

    Copy to Clipboard Toggle word wrap
    $ 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 Toggle word wrap
    $ ls <path_to_ccoctl_output_dir>/manifests

    出力例

    Copy to Clipboard Toggle word wrap
    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 バイナリーを展開して準備しておく。

手順

  1. 次のコマンドを実行して、クラスターの OpenID Connect プロバイダーを設定するために使用されるパブリックおよびプライベート RSA キーファイルを生成します。

    Copy to Clipboard Toggle word wrap
    $ ccoctl aws create-key-pair

    出力例

    Copy to Clipboard Toggle word wrap
    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 に作成します。

  2. 次のコマンドを実行して、AWS 上に OpenID Connect ID プロバイダーと S3 バケットを作成します。

    Copy to Clipboard Toggle word wrap
    $ ccoctl aws create-identity-provider \
      --name=<name> \
    1
    
      --region=<aws_region> \
    2
    
      --public-key-file=<path_to_ccoctl_output_dir>/serviceaccount-signer.public 
    3
    1
    <name> は、追跡用に作成されたクラウドリソースにタグを付けるために使用される名前です。
    2
    <aws_region> は、クラウドリソースが作成される AWS リージョンです。
    3
    <path_to_ccoctl_output_dir> は、ccoctl aws create-key-pair コマンドが生成したパブリックキーファイルへのパスです。

    出力例

    Copy to Clipboard Toggle word wrap
    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 フィールドを設定します。

  3. クラスターの各コンポーネントについて IAM ロールを作成します。

    1. 次のコマンドを実行して、インストールファイルのリリースイメージを $RELEASE_IMAGE 変数に設定します。

      Copy to Clipboard Toggle word wrap
      $ RELEASE_IMAGE=$(./openshift-install version | awk '/release image/ {print $3}')
    2. OpenShift Container Platform リリースイメージから CredentialsRequest オブジェクトの一覧を抽出します。

      Copy to Clipboard Toggle word wrap
      $ oc adm release extract \
        --from=$RELEASE_IMAGE \
        --credentials-requests \
        --included \
      1
      
        --install-config=<path_to_directory_with_installation_configuration>/install-config.yaml \
      2
      
        --to=<path_to_directory_for_credentials_requests> 
      3
      1
      --included パラメーターには、特定のクラスター設定に必要なマニフェストのみが含まれます。
      2
      install-config.yaml ファイルの場所を指定します。
      3
      CredentialsRequest オブジェクトを保存するディレクトリーへのパスを指定します。指定したディレクトリーが存在しない場合は、このコマンドによって作成されます。
    3. 次のコマンドを実行し、ccoctl ツールを使用して CredentialsRequest オブジェクトをすべて処理します。

      Copy to Clipboard Toggle word wrap
      $ 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 Toggle word wrap
    $ ls <path_to_ccoctl_output_dir>/manifests

    出力例

    Copy to Clipboard Toggle word wrap
    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 ユーティリティーを使用して、クラスターに必要なクラウドプロバイダーリソースを作成している。

手順

  1. install-config.yaml 設定ファイルの credentialsMode パラメーターを Manual に設定しなかった場合は、次のように値を変更します。

    設定ファイルのサンプルスニペット

    Copy to Clipboard Toggle word wrap
    apiVersion: v1
    baseDomain: example.com
    credentialsMode: Manual
    # ...

  2. インストールマニフェストファイルをまだ作成していない場合は、次のコマンドを実行して作成します。

    Copy to Clipboard Toggle word wrap
    $ openshift-install create manifests --dir <installation_directory>

    ここで、<installation_directory> は、インストールプログラムがファイルを作成するディレクトリーに置き換えます。

  3. 次のコマンドを実行して、ccoctl ユーティリティーが生成したマニフェストを、インストールプログラムが作成した manifests ディレクトリーにコピーします。

    Copy to Clipboard Toggle word wrap
    $ cp /<path_to_ccoctl_output_dir>/manifests/* ./manifests/
  4. 秘密鍵を含む tls ディレクトリーをインストールディレクトリーにコピーします。

    Copy to Clipboard Toggle word wrap
    $ cp -a /<path_to_ccoctl_output_dir>/tls .

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

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

重要

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

前提条件

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

手順

  1. インストールプログラムが含まれるディレクトリーに切り替え、クラスターのデプロイメントを初期化します。

    Copy to Clipboard Toggle word wrap
    $ ./openshift-install create cluster --dir <installation_directory> \ 
    1
    
        --log-level=info 
    2
    1
    <installation_directory> については、カスタマイズした ./install-config.yaml ファイルの場所を指定します。
    2
    異なるインストールの詳細情報を表示するには、info ではなく、warndebug、または error を指定します。
  2. オプション: クラスターのインストールに使用した IAM アカウントから AdministratorAccess ポリシーを削除するか、無効にします。

    注記

    AdministratorAccess ポリシーが提供する昇格したパーミッションはインストール時にのみ必要です。

検証

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

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

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

出力例

Copy to Clipboard Toggle word wrap
...
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 をインストールしていること。

手順

  1. kubeadmin 認証情報をエクスポートします。

    Copy to Clipboard Toggle word wrap
    $ export KUBECONFIG=<installation_directory>/auth/kubeconfig 
    1
    1
    <installation_directory> には、インストールファイルを保存したディレクトリーへのパスを指定します。
  2. エクスポートされた設定を使用して、oc コマンドを正常に実行できることを確認します。

    Copy to Clipboard Toggle word wrap
    $ oc whoami

    出力例

    Copy to Clipboard Toggle word wrap
    system:admin

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

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

前提条件

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

手順

  1. インストールホストで kubeadmin-password ファイルから kubeadmin ユーザーのパスワードを取得します。

    Copy to Clipboard Toggle word wrap
    $ cat <installation_directory>/auth/kubeadmin-password
    注記

    または、インストールホストで <installation_directory>/.openshift_install.log ログファイルから kubeadmin パスワードを取得できます。

  2. OpenShift Container Platform Web コンソールルートをリスト表示します。

    Copy to Clipboard Toggle word wrap
    $ oc get routes -n openshift-console | grep 'console-openshift'
    注記

    または、インストールホストで <installation_directory>/.openshift_install.log ログファイルからで OpenShift Container Platform ルートを取得できます。

    出力例

    Copy to Clipboard Toggle word wrap
    console     console-openshift-console.apps.<cluster_name>.<base_domain>            console     https   reencrypt/Redirect   None

  3. Web ブラウザーで前述のコマンドの出力で詳細に説明されたルートに移動し、kubeadmin ユーザーとしてログインします。

関連情報

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 サブスクリプションを追跡します。

関連情報

4.8.14. 次のステップ

4.9. AWS の government リージョンへのクラスターのインストール

OpenShift Container Platform バージョン 4.15 では、Amazon Web Services (AWS) 上のクラスターを government リージョンにインストールできます。リージョンを設定するには、クラスターをインストールする前に、install-config.yaml ファイルでパラメーターを変更します。

4.9.1. 前提条件

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/.*: ownedNameopenshift.io/cluster タグを使用できません。

    インストールプログラムは kubernetes.io/cluster/.*: shared タグを追加するようにサブネットを変更するため、サブネットでは 1 つ以上の空のタグスロットが利用可能である必要があります。AWS ドキュメントで タグ制限 を確認し、インストールプログラムでタグを指定する各サブネットに追加できるようにします。Name タグは EC2 Name フィールドと重複し、その結果インストールが失敗するため、使用できません。

  • 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

  • AWS::EC2::VPC
  • AWS::EC2::VPCEndpoint

使用するクラスターのパブリック VPC を指定する必要があります。VPC は、各サブネットのルートテーブルを参照するエンドポイントを使用して、S3 でホストされているレジストリーとの通信を強化します。

パブリックサブネット

  • AWS::EC2::Subnet
  • AWS::EC2::SubnetNetworkAclAssociation

VPC には 1 から 3 のアベイラビリティーゾーンのパブリックサブネットが必要であり、それらを適切な Ingress ルールに関連付ける必要があります。

インターネットゲートウェイ

  • AWS::EC2::InternetGateway
  • AWS::EC2::VPCGatewayAttachment
  • AWS::EC2::RouteTable
  • AWS::EC2::Route
  • AWS::EC2::SubnetRouteTableAssociation
  • AWS::EC2::NatGateway
  • AWS::EC2::EIP

VPC に割り当てられたパブリックルートを持つパブリックインターネットゲートウェイが必要です。提供されるテンプレートでは、各パブリックサブネットに EIP アドレスと NAT ゲートウェイがあります。これらの NAT ゲートウェイは、プライベートサブネットインスタンスなどのクラスターリソースがインターネットに到達できるようにするもので、一部のネットワークが制限された環境またはプロキシーのシナリオでは必要ありません。

ネットワークアクセス制御

  • AWS::EC2::NetworkAcl
  • AWS::EC2::NetworkAclEntry

VPC が以下のポートにアクセスできるようにする必要があります。

ポート

理由

80

インバウンド HTTP トラフィック

443

インバウンド HTTPS トラフィック

22

インバウンド SSH トラフィック

1024 - 65535

インバウンド一時 (ephemeral) トラフィック

0 - 65535

アウトバウンド一時 (ephemeral) トラフィック

プライベートサブネット

  • AWS::EC2::Subnet
  • AWS::EC2::RouteTable
  • AWS::EC2::SubnetRouteTableAssociation

VPC にはプライベートサブネットを使用できます。提供される CloudFormation テンプレートは 1 から 3 アベイラビリティーゾーンのプライベートサブネットを作成できます。プライベートサブネットを使用できる場合は、それらの適切なルートおよびテーブルを指定する必要があります。

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

手順

  1. クラスターノードへの認証に使用するローカルマシンに既存の SSH キーペアがない場合は、これを作成します。たとえば、Linux オペレーティングシステムを使用するコンピューターで以下のコマンドを実行します。

    Copy to Clipboard Toggle word wrap
    $ ssh-keygen -t ed25519 -N '' -f <path>/<file_name> 
    1
    1
    新しい SSH キーのパスとファイル名 (~/.ssh/id_ed25519 など) を指定します。既存のキーペアがある場合は、公開鍵が ~/.ssh ディレクトリーにあることを確認します。
    注記

    x86_64ppc64le、および s390x アーキテクチャーのみで FIPS 140-2/140-3 検証のために NIST に提出された RHEL 暗号化ライブラリーを使用する OpenShift Container Platform クラスターをインストールする予定がある場合は、ed25519 アルゴリズムを使用するキーを作成しないでください。代わりに、rsa アルゴリズムまたは ecdsa アルゴリズムを使用するキーを作成します。

  2. 公開 SSH キーを表示します。

    Copy to Clipboard Toggle word wrap
    $ cat <path>/<file_name>.pub

    たとえば、次のコマンドを実行して ~/.ssh/id_ed25519.pub 公開鍵を表示します。

    Copy to Clipboard Toggle word wrap
    $ cat ~/.ssh/id_ed25519.pub
  3. ローカルユーザーの SSH エージェントに SSH 秘密鍵 ID が追加されていない場合は、それを追加します。キーの SSH エージェント管理は、クラスターノードへのパスワードなしの SSH 認証、または ./openshift-install gather コマンドを使用する場合は必要になります。

    注記

    一部のディストリビューションでは、~/.ssh/id_rsa および ~/.ssh/id_dsa などのデフォルトの SSH 秘密鍵のアイデンティティーは自動的に管理されます。

    1. ssh-agent プロセスがローカルユーザーに対して実行されていない場合は、バックグラウンドタスクとして開始します。

      Copy to Clipboard Toggle word wrap
      $ eval "$(ssh-agent -s)"

      出力例

      Copy to Clipboard Toggle word wrap
      Agent pid 31874

      注記

      クラスターが FIPS モードにある場合は、FIPS 準拠のアルゴリズムのみを使用して SSH キーを生成します。鍵は RSA または ECDSA のいずれかである必要があります。

  4. SSH プライベートキーを ssh-agent に追加します。

    Copy to Clipboard Toggle word wrap
    $ ssh-add <path>/<file_name> 
    1
    1
    ~/.ssh/id_ed25519 などの、SSH プライベートキーのパスおよびファイル名を指定します。

    出力例

    Copy to Clipboard Toggle word wrap
    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 アカウントを持っている。このアカウントは、クラスターのインストールに使用されるアカウントと同じである必要はありません。

手順

  1. AWS Marketplace で OpenShift Container Platform サブスクリプションを完了します。
  2. ご使用の AWS リージョンの AMI ID を記録します。インストールプロセスの一環として、クラスターをデプロイする前に、この値で install-config.yaml ファイルを更新する必要があります。

    AWS Marketplace コンピュートノードを含む install-config.yaml ファイルのサンプル

    Copy to Clipboard Toggle word wrap
    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": ...}'

    1
    AWS Marketplace サブスクリプションの AMI ID。
    2
    AMI ID は特定の AWS リージョンに関連付けられています。インストール設定ファイルを作成するときは、サブスクリプションの設定時に指定したものと同じ AWS リージョンを選択してください。

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

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

前提条件

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

手順

  1. OpenShift Cluster Manager サイトの インフラストラクチャープロバイダー ページにアクセスします。Red Hat アカウントがある場合は、認証情報を使用してログインします。アカウントがない場合はこれを作成します。
  2. インフラストラクチャープロバイダーを選択します。
  3. インストールタイプのページに移動し、ホストオペレーティングシステムとアーキテクチャーに対応するインストールプログラムをダウンロードして、インストール設定ファイルを保存するディレクトリーにファイルを配置します。

    重要

    インストールプログラムは、クラスターのインストールに使用するコンピューターにいくつかのファイルを作成します。クラスターのインストール完了後は、インストールプログラムおよびインストールプログラムが作成するファイルを保持する必要があります。ファイルはいずれもクラスターを削除するために必要になります。

    重要

    インストールプログラムで作成されたファイルを削除しても、クラスターがインストール時に失敗した場合でもクラスターは削除されません。クラスターを削除するには、特定のクラウドプロバイダー用の OpenShift Container Platform のアンインストール手順を実行します。

  4. インストールプログラムを展開します。たとえば、Linux オペレーティングシステムを使用するコンピューターで以下のコマンドを実行します。

    Copy to Clipboard Toggle word wrap
    $ tar -xvf openshift-install-linux.tar.gz
  5. Red Hat OpenShift Cluster Manager からインストールプルシークレット をダウンロードします。このプルシークレットを使用し、OpenShift Container Platform コンポーネントのコンテナーイメージを提供する Quay.io など、組み込まれた各種の認証局によって提供されるサービスで認証できます。

4.9.10. インストール設定ファイルの手動作成

クラスターをインストールするには、インストール設定ファイルを手動で作成する必要があります。

前提条件

  • ローカルマシンには、インストールプログラムに提供する SSH 公開鍵があります。このキーは、デバッグおよび障害復旧のためにクラスターノードへの SSH 認証に使用されます。
  • OpenShift Container Platform インストールプログラムおよびクラスターのプルシークレットを取得しています。

手順

  1. 必要なインストールアセットを保存するためのインストールディレクトリーを作成します。

    Copy to Clipboard Toggle word wrap
    $ mkdir <installation_directory>
    重要

    ディレクトリーを作成する必要があります。ブートストラップ X.509 証明書などの一部のインストールアセットの有効期限は短く設定されているため、インストールディレクトリーを再利用することができません。別のクラスターインストールの個別のファイルを再利用する必要がある場合は、それらをディレクトリーにコピーすることができます。ただし、インストールアセットのファイル名はリリース間で変更される可能性があります。インストールファイルを以前のバージョンの OpenShift Container Platform からコピーする場合は注意してコピーを行ってください。

  2. 提供されるサンプルの install-config.yaml ファイルテンプレートをカスタマイズし、これを <installation_directory> に保存します。

    注記

    この設定ファイルの名前を install-config.yaml と付ける必要があります。

  3. install-config.yaml ファイルをバックアップし、複数のクラスターをインストールするのに使用できるようにします。

    重要

    install-config.yaml ファイルは、インストールプロセスの次の手順で使用されます。この時点でこれをバックアップする必要があります。

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

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

表4.13 最小リソース要件
マシンオペレーティングシステム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. 1 vCPU は、同時マルチスレッド (SMT) またはハイパースレッディングが有効にされていない場合に 1 つの物理コアと同等です。これが有効にされている場合、数式「(コアごとのスレッド × コア数) × ソケット数 = 仮想 CPU」を使用して対応する比率を計算します。
  2. OpenShift Container Platform および Kubernetes はディスクのパフォーマンスに敏感であり、特に 10 ms p99 fsync 期間を必要とするコントロールプレーンノード上の etcd については、高速ストレージが推奨されます。多くのクラウドプラットフォームでは、ストレージサイズと IOPS スケールが一緒にあるため、十分なパフォーマンスを得るためにストレージボリュームの割り当てが必要になる場合があります。
  3. すべての 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 ファイルは参照用にのみ提供されます。これを使用して、手動で作成したインストール設定ファイルにパラメーター値を入力します。

Copy to Clipboard Toggle word wrap
apiVersion: v1
baseDomain: example.com 
1

credentialsMode: Mint 
2

controlPlane: 
3
 
4

  hyperthreading: Enabled 
5

  name: master
  platform:
    aws:
      zones:
      - us-gov-west-1a
      - us-gov-west-1b
      rootVolume:
        iops: 4000
        size: 500
        type: io1 
6

      metadataService:
        authentication: Optional 
7

      type: m6i.xlarge
  replicas: 3
compute: 
8

- hyperthreading: Enabled 
9

  name: worker
  platform:
    aws:
      rootVolume:
        iops: 2000
        size: 500
        type: io1 
10

      metadataService:
        authentication: Optional 
11

      type: c5.4xlarge
      zones:
      - us-gov-west-1c
  replicas: 3
metadata:
  name: test-cluster 
12

networking:
  clusterNetwork:
  - cidr: 10.128.0.0/14
    hostPrefix: 23
  machineNetwork:
  - cidr: 10.0.0.0/16
  networkType: OVNKubernetes 
13

  serviceNetwork:
  - 172.30.0.0/16
platform:
  aws:
    region: us-gov-west-1 
14

    propagateUserTags: true 
15

    userTags:
      adminContact: jdoe
      costCenter: 7536
    subnets: 
16

    - subnet-1
    - subnet-2
    - subnet-3
    amiID: ami-0c5d3e03c0ab9b19a 
17

    serviceEndpoints: 
18

      - name: ec2
        url: https://vpce-id.ec2.us-west-2.vpce.amazonaws.com
    hostedZone: Z3URY6TWQ91KVV 
19

fips: false 
20

sshKey: ssh-ed25519 AAAA... 
21

publish: Internal 
22

pullSecret: '{"auths": ...}' 
23
1 12 14 23
必須。
2
オプション: Cloud Credential Operator (CCO) に指定されたモードの使用を強制するには、このパラメーターを追加します。デフォルトでは、CCO は kube-system namespace のルート認証情報を使用して、認証情報の機能を動的に判断しようとします。CCO モードの詳細は、認証および認可 ガイドの「Cloud Credential Operator について」セクションを参照してください。
3 8