インストールの概要
OpenShift Container Platform のインストールに関する概要コンテンツ
概要
第1章 OpenShift Container Platform インストールの概要
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. インストールプログラムについて
インストールプログラムを使用して、各タイプのクラスターをデプロイメントできます。インストールプログラムは、ブートストラップ、コントロールプレーン、コンピュートマシンの Ignition 設定ファイルなどのメインアセットを生成します。インフラストラクチャーを適切に設定している場合は、これらの 3 つのマシン設定を使用して OpenShift Container Platform クラスターを起動できます。
OpenShift Container Platform インストールプログラムは、クラスターのインストールを管理するために一連のターゲットおよび依存関係を使用します。インストールプログラムには、達成する必要のある一連のターゲットが設定され、それぞれのターゲットには一連の依存関係が含まれます。各ターゲットはそれぞれの依存関係の条件が満たされ次第、別個に解決されるため、インストールプログラムは複数のターゲットを並行して達成できるように動作し、最終的にクラスターが実行するようにします。プログラムが依存関係を満たしているため、インストールプログラムはコマンドを実行してコンポーネントを再作成する代わりに、既存のコンポーネントを認識して使用します。
図1.1 OpenShift Container Platform インストールのターゲットおよび依存関係
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.12 クラスターのすべてのコントロールプレーンは、Ignition と呼ばれる最初の起動時に使用される重要なプロビジョニングツールが含まれる RHCOS を使用する必要があります。このツールは、クラスターのマシンの設定を可能にします。オペレーティングシステムの更新は、OSTree をバックエンドとして使用する起動可能なコンテナーイメージとして配信され、Machine Config Operator によりクラスター全体にデプロイされます。実際のオペレーティングシステムの変更は、rpm-ostree を使用することにより、atomic 操作として各マシン上でインプレースで行われます。これらのテクノロジーを組み合わせることで、OpenShift Container Platform は、プラットフォーム全体を最新の状態に保つインプレースアップグレードにより、クラスター上の他のアプリケーションを管理するのと同じようにオペレーティングシステムを管理できるようになります。これらのインプレースアップグレードにより、オペレーションチームの負担を軽減できます。
すべてのクラスターマシンのオペレーティングシステムとして RHCOS を使用する場合、クラスターはオペレーティングシステムを含むコンポーネントとマシンのあらゆる側面を管理します。このため、マシンを変更できるのは、インストールプログラムと Machine Config Operator だけです。インストールプログラムは、Ignition 設定ファイルを使用して各マシンの正確な状態を設定し、インストール後に Machine Config Operator が新しい証明書やキーの適用などのマシンへの追加の変更を完了します。
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.4. インストールプロセス
Assisted Installer を除き、OpenShift Container Platform クラスターをインストールする場合は、OpenShift Cluster Manager Hybrid Cloud Console の適切な クラスタータイプ ページから、インストールプログラムをダウンロードする必要があります。このコンソールは以下を管理します。
- アカウントの REST API。
- 必要なコンポーネントを取得するために使用するプルシークレットであるレジストリートークン。
- クラスターのアイデンティティーを Red Hat アカウントに関連付けて使用状況のメトリクスの収集を容易にするクラスター登録。
OpenShift Container Platform 4.12 では、インストールプログラムは、一連のアセットに対して一連のファイル変換を実行する Go バイナリーファイルです。インストールプログラムと対話する方法は、インストールタイプによって異なります。次のインストールユースケースを検討してください。
- Assisted Installer を使用してクラスターをデプロイするには、Assisted Installer を使用してクラスター設定を行う必要があります。ダウンロードして設定するインストールプログラムはありません。クラスター設定が完了したら、検出 ISO をダウンロードし、そのイメージを使用してクラスターマシンを起動します。Assisted Installer を使用して、完全に統合された Nutanix、vSphere、およびベアメタル、ならびに統合されていないその他のプラットフォームにクラスターをインストールできます。ベアメタルにインストールする場合は、ネットワーク、負荷分散、ストレージ、個々のクラスターマシンなど、すべてのクラスターインフラストラクチャーとリソースを提供する必要があります。
- Agent-based Installer を使用してクラスターをデプロイするには、最初に Agent-based Installer をダウンロードします。次に、クラスターを設定して、検出イメージを生成します。検出イメージを使用してクラスターマシンを起動します。これにより、インストールプログラムと通信してプロビジョニングを処理するエージェントがインストールされます。インストールプログラムとを操作したりプロビジョナーマシンを自分で設定したりする必要はありません。ネットワーク、負荷分散、ストレージ、個々のクラスターマシンなど、すべてのクラスターインフラストラクチャーとリソースを提供する必要があります。このアプローチは、非接続環境に最適です。
- installer-provisioned infrastructure のクラスターの場合、インフラストラクチャーのブートストラップおよびプロビジョニングは、ユーザーが独自に行うのではなくインストールプログラムが代行します。インストールプログラムは、ベアメタルにインストールする場合を除き、クラスターをサポートするために必要なすべてのネットワーク、マシン、およびオペレーティングシステムを作成します。ベアメタルにインストールする場合は、ブートストラップマシン、ネットワーク、負荷分散、ストレージ、個々のクラスターマシンなど、すべてのクラスターインフラストラクチャーとリソースを提供する必要があります。
- クラスターのインフラストラクチャーを独自にプロビジョニングし、管理する場合には、ブートストラップマシン、ネットワーク、負荷分散、ストレージ、および個々のクラスターマシンを含む、すべてのクラスターインフラストラクチャーおよびリソースを指定する必要があります。
インストールプログラムの場合、プログラムはインストール中に 3 つのファイルセットを使用します。それは、install-config.yaml という名前のインストール設定ファイル、Kubernetes マニフェスト、およびマシンタイプの Ignition 設定ファイルです。
インストール時に、Kubernetes および基礎となる RHCOS オペレーティングシステムを制御する Ignition 設定ファイルを変更できます。ただし、これらのオブジェクトに対して加える変更の適合性を確認するための検証の方法はなく、これらのオブジェクトを変更するとクラスターが機能しなくなる可能性があります。これらのオブジェクトを変更すると、クラスターが機能しなくなる可能性があります。このリスクがあるために、変更方法を文書化した手順に従っているか、Red Hat サポートが変更することを指示した場合を除き、Kubernetes および Ignition 設定ファイルの変更はサポートされていません。
インストール設定ファイルは Kubernetes マニフェストに変換され、その後マニフェストは Ignition 設定にラップされます。インストールプログラムはこれらの Ignition 設定ファイルを使用してクラスターを作成します。
インストール設定ファイルはインストールプログラムの実行時にすべてプルーニングされるため、再び使用する必要のあるすべての設定ファイルをバックアップしてください。
インストール時に設定したパラメーターを変更することはできませんが、インストール後に数多くのクラスター属性を変更できます。
Assisted Installer を使用したインストールプロセス
Assisted Installer を使用したインストールでは、Web ベースのユーザーインターフェイスまたは RESTful API を使用して対話的にクラスター設定を作成します。Assisted Installer ユーザーインターフェイスは、ユーザーインターフェイスまたは API で変更しない限り、必要な値の入力を求め、残りのパラメーターに適切なデフォルト値を提供します。Assisted Installer は検出イメージを生成します。このイメージをダウンロードして、クラスターマシンの起動に使用します。イメージによって RHCOS とエージェントがインストールされ、エージェントがプロビジョニングを処理します。OpenShift Container Platform を、Assisted Installer を使用して完全な統合により、Nutanix、vSphere、およびベアメタルにインストールできます。統合せずに、Assisted Installer を使用して OpenShift Container Platform を別のプラットフォームにインストールすることもできます。
OpenShift Container Platform は、オペレーティングシステム自体を含む、クラスターのすべての側面を管理します。各マシンは、それが参加するクラスターでホストされるリソースを参照する設定に基づいて起動します。この設定により、クラスターは更新の適用時に自己管理できます。
可能であれば、Agent-based Installer をダウンロードして設定する必要がないように、Assisted Installer 機能を使用してください。
エージェントベースのインフラストラクチャーを使用したインストールプロセス
Agent-based installation は Assisted Installer を使用する場合とよく似ていますが、最初に Agent-based Installer をダウンロードしてインストールする必要があります。エージェントベースのインストールは、Assisted Installer の利便性を活用したいにもかかわらず、非接続環境でクラスターをインストールする必要がある場合に役立ちます。
可能であれば、エージェントベースのインストール機能を使用してください。その場合は、ブートストラップ仮想マシンを使用してプロビジョナーマシンを作成し、クラスターインフラストラクチャーをプロビジョニングして維持する必要がなくなります。
installer-provisioned infrastructure でのインストールプロセス
デフォルトのインストールタイプは、installer-provisioned infrastructure です。デフォルトで、インストールプログラムはインストールウィザードとして機能し、独自に判別できない値の入力を求めるプロンプトを出し、残りのパラメーターに妥当なデフォルト値を提供します。インストールプロセスは、高度なインフラストラクチャーシナリオに対応するようカスタマイズすることもできます。インストールプログラムは、クラスターの基盤となるインフラストラクチャーをプロビジョニングします。
標準クラスターまたはカスタマイズされたクラスターのいずれかをインストールできます。標準クラスターの場合は、クラスターをインストールするために必要な最小限の詳細情報を指定します。カスタマイズされたクラスターの場合は、コントロールプレーンが使用するマシン数、クラスターがデプロイする仮想マシンのタイプ、または Kubernetes サービスネットワークの CIDR 範囲などのプラットフォームの詳細を指定できます。
可能な場合は、この機能を使用してクラスターインフラストラクチャーのプロビジョニングと保守の手間を省くようにしてください。他のすべての環境では、インストールプログラムを使用してクラスターインフラストラクチャーをプロビジョニングするために必要なアセットを生成できます。
installer-provisioned infrastructure クラスターの場合、OpenShift Container Platform は、オペレーティングシステム自体を含むクラスターのすべての側面を管理します。各マシンは、それが参加するクラスターでホストされるリソースを参照する設定に基づいて起動します。この設定により、クラスターは更新の適用時に自己管理できます。
user-provisioned infrastructure を使用したインストールプロセス
OpenShift Container Platform はユーザーが独自にプロビジョニングするインフラストラクチャーにインストールすることもできます。インストールプログラムを使用してクラスターインフラストラクチャーのプロビジョニングに必要なアセットを生成し、クラスターインフラストラクチャーを作成し、その後にクラスターをプロビジョニングしたインフラストラクチャーにデプロイします。
インストールプログラムがプロビジョニングしたインフラストラクチャーを使用しない場合は、クラスターリソースをユーザー自身で管理し、維持する必要があります。次のリストは、一部のセルフマネージドリソースの詳細を示しています。
- クラスターを設定するコントロールプレーンおよびコンピュートマシンの基礎となるインフラストラクチャー
- ロードバランサー
- DNS レコードおよび必要なサブネットを含むクラスターネットワーク
- クラスターインフラストラクチャーおよびアプリケーションのストレージ
クラスターで user-provisioned infrastructure を使用する場合は、RHEL コンピュートマシンをクラスターに追加するオプションを使用できます。
インストールプロセスの詳細
クラスターがプロビジョニングされると、クラスター内の各マシンにはクラスターに関する情報が必要になります。OpenShift Container Platform は初期設定時に一時的なブートストラップマシンを使用して、必要な情報を永続的なコントロールプレーンに提供します。一時的なブートストラップマシンは、クラスターの作成方法を記述する Ignition 設定ファイルを使用して起動します。ブートストラップマシンは、コントロールプレーンを設定するコントロールプレーンマシンを作成します。その後、コントロールプレーンマシンはコンピュートマシン (ワーカーマシンとしても知られる) を作成します。以下の図はこのプロセスを示しています。
図1.2 ブートストラップ、コントロールプレーンおよびコンピュートマシンの作成
クラスターマシンを初期化した後、ブートストラップマシンは破棄されます。すべてのクラスターがこのブートストラッププロセスを使用してクラスターを初期化しますが、ユーザーがクラスターのインフラストラクチャーをプロビジョニングする場合は、多くの手順を手動で実行する必要があります。
-
インストールプログラムが生成する Ignition 設定ファイルには、24 時間が経過すると期限切れになり、その後に更新される証明書が含まれます。証明書を更新する前にクラスターが停止し、24 時間経過した後にクラスターを再起動すると、クラスターは期限切れの証明書を自動的に復元します。例外として、kubelet 証明書を回復するために保留状態の
node-bootstrapper証明書署名要求 (CSR) を手動で承認する必要があります。詳細は、コントロールプレーン証明書の期限切れの状態からのリカバリー に関するドキュメントを参照してください。 - 24 時間証明書はクラスターのインストール後 16 時間から 22 時間でローテーションするため、Ignition 設定ファイルは、生成後 12 時間以内に使用することを検討してください。12 時間以内に Ignition 設定ファイルを使用することにより、インストール中に証明書の更新が実行された場合のインストールの失敗を回避できます。
クラスターのブートストラップには、以下のステップが関係します。
- ブートストラップマシンが起動し、コントロールプレーンマシンの起動に必要なリモートリソースのホスティングを開始します。インフラストラクチャーをプロビジョニングする場合、この手順では人的介入が必要になります。
- ブートストラップマシンは、単一ノードの etcd クラスターと一時的な Kubernetes コントロールプレーンを起動します。
- コントロールプレーンマシンは、ブートストラップマシンからリモートリソースをフェッチし、起動を終了します。インフラストラクチャーをプロビジョニングする場合、この手順では人的介入が必要になります。
- 一時的なコントロールプレーンは、実稼働コントロールプレーンマシンに対して実稼働コントロールプレーンをスケジュールします。
- Cluster Version Operator (CVO) はオンラインになり、etcd Operator をインストールします。etcd Operator はすべてのコントロールプレーンノードで etcd をスケールアップします。
- 一時的なコントロールプレーンはシャットダウンし、コントロールを実稼働コントロールプレーンに渡します。
- ブートストラップマシンは OpenShift Container Platform コンポーネントを実稼働コントロールプレーンに挿入します。
- インストールプログラムはブートストラップマシンをシャットダウンします。インフラストラクチャーをプロビジョニングする場合、この手順では人的介入が必要になります。
- コントロールプレーンはコンピュートノードを設定します。
- コントロールプレーンは一連の Operator の形式で追加のサービスをインストールします。
このブートストラッププロセスの結果として、OpenShift Container Platform クラスターが実行します。次に、クラスターはサポートされる環境でのコンピュートマシンの作成など、日常の操作に必要な残りのコンポーネントをダウンロードし、設定します。
1.1.5. インストール後のノード状態の確認
以下のインストールヘルスチェックが正常に行われると、OpenShift Container Platform のインストールが完了します。
- プロビジョナーは、OpenShift Container Platform Web コンソールにアクセスできます。
- すべてのコントロールプレーンノードが準備状態にある。
- すべてのクラスター Operator が利用可能です。
インストールが完了すると、ワーカーノードを実行する特定のクラスター Operator が継続的にすべてのワーカーノードのプロビジョニングを試みます。すべてのワーカーノードが READY と報告されるまで、多少時間がかかります。ベアメタルへのインストールの場合、ワーカーノードのトラブルシューティングを行う前に、少なくとも 60 分間待機してください。他のすべてのプラットフォームへのインストールの場合は、ワーカーノードのトラブルシューティングを行う前に、少なくとも 40 分間待機してください。ワーカーノードを実行するクラスター Operator の DEGRADED 状態は、ノードの状態ではなく、Operator 自体のリソースに依存します。
インストールが完了したら、引き続きクラスター内におけるノードの状態を監視できます。
前提条件
- インストールプログラムはターミナルで正常に解決されます。
手順
すべてのワーカーノードのステータスを表示します。
$ oc get nodes
出力例
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
すべてのワーカーマシンノードのフェーズを表示します。
$ oc get machines -A
出力例
NAMESPACE NAME PHASE TYPE REGION ZONE AGE openshift-machine-api example-zbbt6-master-0 Running 95m openshift-machine-api example-zbbt6-master-1 Running 95m openshift-machine-api example-zbbt6-master-2 Running 95m openshift-machine-api example-zbbt6-worker-0-25bhp Running 49m openshift-machine-api example-zbbt6-worker-0-8b4c2 Running 49m openshift-machine-api example-zbbt6-worker-0-jkbqt Running 49m openshift-machine-api example-zbbt6-worker-0-qrl5b Running 49m
関連情報
インストールのスコープ
OpenShift Container Platform インストールプログラムのスコープは意図的に狭められています。単純さを確保し、確実にインストールを実行できるように設計されているためです。インストールが完了した後に数多くの設定タスクを実行できます。
関連情報
- OpenShift Container Platform 設定リソースの詳細は、利用可能なクラスターのカスタマイズ を参照してください。
1.1.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.2. OpenShift Container Platform クラスターでサポートされるプラットフォーム
OpenShift Container Platform バージョン 4.12 では、インストーラーでプロビジョニングされるインフラストラクチャーを使用するクラスターの場合、以下のプラットフォームにインストールできます。
- Alibaba Cloud
- Amazon Web Services (AWS)
- ベアメタル
- Google Cloud Platform (GCP)
- IBM Cloud® VPC
- 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 Cloud (VMC) on AWS
- VMware vSphere
これらのクラスターの場合は、インストールプロセスを実行するコンピューターを含むすべてのマシンが、プラットフォームコンテナーのイメージをプルし、Telemetry データを Red Hat に提供できるようインターネットに直接アクセスできる必要があります。
インストール後は、以下の変更はサポートされません。
- クラウドプロバイダープラットフォームの混在。
- クラウドプロバイダーコンポーネントの混在。たとえば、クラスターをインストールしたプラットフォーム上の別のプラットフォームから永続ストレージフレームワークを使用します。
OpenShift Container Platform 4.12 では、ユーザーによってプロビジョニングされるインフラストラクチャーを使用するクラスターの場合、以下のプラットフォームにインストールできます。
- 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 のページには、各種プラットフォームの統合テストの詳細が記載されています。
関連情報
- それぞれのサポートされているプラットフォームで利用できるインストールのタイプの詳細は、各種プラットフォームのサポートされているインストール方法 を参照してください。
- インストール方法の選択と必要なリソースの準備については、クラスターインストール方法の選択およびそのユーザー向けの準備 を参照してください。
第2章 クラスターインストール方法の選択およびそのユーザー向けの準備
OpenShift Container Platform をインストールする前に、実行するインストールプロセスを決定し、ユーザー用にクラスターを準備する際に必要なすべてのリソースがあることを確認します。
2.1. クラスターのインストールタイプの選択
OpenShift Container Platform クラスターをインストールする前に、実行する最適なインストール手順を選択する必要があります。以下の質問に回答して、最も良いオプションを選択します。
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
- Google Cloud Platform (GCP)
- Red Hat OpenStack Platform (RHOSP)
- Red Hat Virtualization (RHV)
- IBM Cloud VPC
- IBM Z または IBM® LinuxONE
- IBM Z または IBM® LinuxONE for Red Hat Enterprise Linux (RHEL) KVM
- IBM Power
- Nutanix
- VMware vSphere
- VMware Cloud (VMC) on AWS
- ベアメタルまたはその他のプラットフォームに依存しないインフラストラクチャー
OpenShift Container Platform 4 クラスターは、オンプレミスハードウェアとクラウドホストサービスの両方にデプロイできますが、クラスターのすべてのマシンは同じデータセンターまたはクラウドホストサービスにある必要があります。
OpenShift Container Platform を使用する必要があるが、クラスターを独自に管理することを望まない場合は、複数のマネージドサービスオプションを使用できます。Red Hat によって完全に管理されるクラスターが必要な場合は、OpenShift Dedicated または OpenShift Online を使用することができます。OpenShift を Azure、AWS、IBM Cloud、または Google Cloud VPC でマネージドサービスとして使用することもできます。マネージドサービスの詳細は、OpenShift の製品 ページを参照してください。クラウド仮想マシンを仮想ベアメタルとして OpenShift Container Platform クラスターをインストールする場合、対応するクラウドベースのストレージはサポートされません。
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 に移行するにあたり、任意のタイプの実稼働用のクラスターのインストールプロセスを使用して新規クラスターを作成できます。
2.1.3. クラスターで既存のコンポーネントを使用する必要がありますか ?
オペレーティングシステムは OpenShift Container Platform に不可欠な要素であり、OpenShift Container Platform のインストールプログラムはすべてのインフラストラクチャーの起動を簡単に実行できます。これらは、installer provisioned infrastructure のインストールと呼ばれています。この種のインストールでは、ユーザーは既存のインフラストラクチャーをクラスターに提供できますが、インストールプログラムがクラスターを最初に必要とするすべてのマシンをデプロイします。
クラスターまたはその基盤となるマシンの Alibaba Cloud、AWS、Azure、Azure Stack Hub、GCP、Nutanix、または VMC on AWS へのカスタマイズを指定することなく、インストーラーでプロビジョニングされたインフラストラクチャークラスターをデプロイできます。これらのインストール方法は、実稼働対応の OpenShift Container Platform クラスターをデプロイする最も高速な方法です。
インストーラーでプロビジョニングされたインフラストラクチャークラスターの基本設定 (クラスターマシンのインスタンスタイプなど) を実行する必要がある場合は、Alibaba Cloud、AWS、Azure、GCP、Nutanix、または VMC on AWS のインストールをカスタマイズできます。
installer-provisioned infrastructure のインストールの場合、AWS の既存の VPC、Azure の vNet、または GCP の VPC を使用できます。ネットワークインフラストラクチャーの一部を再利用して、AWS、Azure、GCP、または VMC on AWS のクラスターが環境内の既存の IP アドレスの割り当てと共存し、既存の MTU および VXLAN 設定と統合できるようにします。これらのクラウドに既存のアカウントおよび認証情報がある場合は、それらを再利用できますが、OpenShift Container Platform クラスターをインストールするために必要なパーミッションを持つようアカウントを変更する必要がある場合があります。
インストーラーでプロビジョニングされるインフラストラクチャー方法を使用して、RHOSP、Kuryr を使用した RHOSP、RHV、vSphere、および ベアメタル のハードウェアに適切なマシンインスタンスを作成できます。さらに、vSphere、VMC on AWS では、インストール時に追加のネットワークパラメーターをカスタマイズすることもできます。
大規模なクラウドインフラストラクチャーを再利用する必要がある場合、ユーザーによってプロビジョニングされるインフラストラクチャー のインストールを実行できます。これらのインストールでは、インストールプロセス時にクラスターに必要なマシンを手動でデプロイします。AWS、Azure、Azure Stack Hub、GCP、または VMC on AWS でユーザーによってプロビジョニングされるインフラストラクチャーを実行する場合、提供されるテンプレートを使用して必要なすべてのコンポーネントを起動できます。共有 VPC on GCP を再利用することもできます。それ以外の場合は、プロバイダーに依存しない インストール方法を使用して、クラスターを他のクラウドにデプロイすることができます。
ユーザーによってプロビジョニングされるインフラストラクチャーは、既存のハードウェアで実行することもできます。RHOSP、RHV、IBM Z または IBM® LinuxONE、RHEL KVM を使用した IBM Z または IBM® LinuxONE、IBM Power、または vSphere を使用する場合は、特定のインストール手順を使用してクラスターをデプロイします。サポートされる他のハードウェアを使用する場合は、ベアメタルのインストール 手順に従います。RHOSP、vSphere、VMC on AWS、および ベアメタル などの一部のプラットフラォームの場合は、インストール時に追加のネットワークパメーターをカスタマイズすることもできます。
2.1.4. クラスターに追加のセキュリティーが必要ですか ?
user-provisioned installation 方法を使用する場合、クラスターのプロキシーを設定できます。この手順は各インストール手順に含まれています。
パブリッククラウドのクラスターがエンドポイントを外部に公開するのを防ぐ必要がある場合、AWS、Azure、または GCP の installer-provisioned infrastructure を使用してプライベートクラスターをデプロイすることができます。
非接続のクラスターまたはネットワークが制限されたクラスターなど、インターネットへのアクセスが限定されたクラスターをインストールする必要がある場合、インストールパッケージをミラーリング し、そこからクラスターをインストールできます。AWS、GCP、IBM Z または IBM® LinuxONE、RHEL KVM を使用した IBM Z または IBM® LinuxONE、IBM Power、vSphere、VMC on AWS、または ベアメタル のネットワークが制限された環境へのユーザーによってプロビジョニングされるインフラストラクチャーのインストールの詳細な手順を実行します。AWS、GCP、Nutanix、VMC on AWS、RHOSP、RHV、および vSphere の詳細な手順に従って、インストーラーによってプロビジョニングされたインフラストラクチャーを使用して、ネットワークが制限された環境にクラスターをインストールすることもできます。
クラスターを AWS GovCloud リージョン、AWS China リージョン、または Azure government リージョン にデプロイする必要がある場合は、installer-provisioned infrastructure のインストール時にこれらのカスタムリージョンを設定できます。
また、インストール時に FIPS 検証済み/進行中のモジュール (Modules in Process) 暗号化ライブラリー を使用するようにクラスターマシンを設定することもできます。
FIPS 検証済み/進行中のモジュール (Modules in Process) 暗号ライブラリーの使用は、x86_64 アーキテクチャーの OpenShift Container Platform デプロイメントでのみサポートされています。
2.2. インストール後のユーザー向けのクラスターの準備
一部の設定は、クラスターのインストールに必須ではありませんが、ユーザーがクラスターにアクセスする前に設定することが推奨されます。クラスターを設定する Operator を カスタマイズ することでクラスター自体をカスタマイズし、クラスターをアイデンティティープロバイダーなどの他の必要なシステムに統合できます。
実稼働クラスターの場合、以下の統合を設定する必要があります。
2.3. ワークロードに関するクラスターの準備
ワークロードのニーズによっては、アプリケーションのデプロイを開始する前に、追加の手順が必要になる場合があります。たとえば、アプリケーションの ビルドストラテジー をサポートできるようなインフラストラクチャーを準備した後に、低レイテンシー のワークロードに対応できるようにしたり、機密のワークロードを保護 できるようにしたりする必要がある場合があります。アプリケーションワークロードの モニタリング を設定することもできます。Windows ワークロード を実行する予定がある場合は、インストールプロセス中に OVN-Kubernetes を使用してハイブリッドネットワーク を有効にする必要があります。クラスターのインストール後はハイブリッドネットワークを有効にできません。
2.4. 各種プラットフォームのサポートされているインストール方法
各種のプラットフォームで各種のインストールを実行できます。
以下の表にあるように、すべてのプラットフォームですべてのインストールオプションがサポートされている訳ではありません。チェックマークは、オプションがサポートされていることを示し、関連するセクションにリンクしています。
| Alibaba | AWS (64 ビット x86) | AWS (64 ビット ARM) | Azure (64 ビット x86) | Azure (64 ビット ARM) | Azure Stack Hub | GCP | Nutanix | RHOSP | RHV | ベアメタル(64 ビット x86) | ベアメタル (64 ビット ARM) | vSphere | VMC | IBM Cloud VPC | IBM Z | IBM Power | |
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| デフォルト | |||||||||||||||||
| カスタム | |||||||||||||||||
| ネットワークのカスタマイズ | |||||||||||||||||
| ネットワークが制限されたインストール | |||||||||||||||||
| プライベートクラスター | |||||||||||||||||
| 既存の仮想プライベートネットワーク | |||||||||||||||||
| government リージョン | |||||||||||||||||
| 秘密の地域 | |||||||||||||||||
| China リージョン |
| Alibaba | AWS (64 ビット x86) | AWS (64 ビット ARM) | Azure | Azure Stack Hub | GCP | Nutanix | RHOSP | RHV | ベアメタル(64 ビット x86) | ベアメタル (64 ビット ARM) | vSphere | VMC | IBM Cloud VPC | IBM Z | RHEL KVM を使用した IBM Z | IBM Power | プラットフォームの指定なし | |
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| カスタム | ||||||||||||||||||
| ネットワークのカスタマイズ | ||||||||||||||||||
| ネットワークが制限されたインストール | ||||||||||||||||||
| クラスタープロジェクト外でホストされる共有 VPC |
第3章 クラスター機能
クラスター管理者は、クラスター機能を使用して、インストール前にオプションコンポーネントを有効または無効にできます。クラスター管理者は、インストール後いつでもクラスター機能を有効にすることができます。
クラスター管理者は、クラスター機能を有効にした後、それを無効にすることはできません。
3.1. クラスター機能の選択
「クラスターをカスタマイズして AWS にインストール」または「クラスターをカスタマイズして GCP にインストール」など、クラスターをカスタマイズしてインストールするいずれかの方法を使用することで、クラスター機能を選択できます。
カスタマイズを伴うインストールでは、クラスターの設定パラメーターを含む install-config.yaml ファイルを作成します。
特定のクラスター機能を有効または無効にしてクラスターをカスタマイズする場合は、install-config.yaml ファイルを手動で保守する必要があります。新しい OpenShift Container Platform の更新では、既存のコンポーネントの新しい機能ハンドルが宣言されたり、新しいコンポーネントがまとめて導入されたりする可能性があります。install-config.yaml ファイルをカスタマイズするユーザーは、OpenShift Container Platform の更新に合わせて install-config.yaml ファイルを定期的に更新することも検討してください。
次の設定パラメーターを使用して、クラスター機能を選択できます。
capabilities: baselineCapabilitySet: v4.11 1 additionalEnabledCapabilities: 2 - CSISnapshot - Console - Storage
- 1
- インストールする機能のベースラインセットを定義します。有効な値は
None、vCurrent、v4.xです。Noneを選択すると、すべてのオプション機能が無効になります。デフォルト値はvCurrentで、すべてのオプション機能が有効になります。注記v4.xは、現在のクラスターバージョン以前の任意の値を参照します。たとえば、OpenShift Container Platform 4.12 クラスターでの有効値はv4.11とv4.12です。 - 2
- 明示的に有効にする機能のリストを定義します。これらは、
baselineCapabilitySetで指定された機能に加えて有効になります。注記この例では、デフォルトで
v4.11に設定されています。additionalEnabledCapabilitiesフィールドでは、デフォルトのv4.11機能セット以外を有効にできます。
次の表では、baselineCapabilitySet の値を説明します。
| 値 | 説明 |
|---|---|
|
| 新しいリリースで導入される新しいデフォルト機能を自動的に追加する場合、このオプションを指定します。 |
|
|
OpenShift Container Platform 4.11 のデフォルト機能を有効にする場合、このオプションを指定します。 |
|
|
OpenShift Container Platform 4.12 のデフォルト機能を有効にする場合、このオプションを指定します。 |
|
|
他のセットが大きすぎる場合や、機能が必要ない場合、 |
3.2. OpenShift Container Platform 4.12 のオプションのクラスター機能
現在、クラスター Operator はこれらのオプション機能を提供します。以下は、各オプションによって提供される機能と、無効にした場合に失われる機能をまとめたものです。
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 リソースがない場合にのみ、この機能を無効にしてください。
3.2.2. クラスターストレージ機能
目的
Cluster Storage Operator は、Storage 機能を提供します。
Cluster Storage Operator は OpenShift Container Platform のクラスター全体のストレージのデフォルト値を設定します。これにより、OpenShift Container Platform クラスターのデフォルトの storageclass の存在を確認できます。また、クラスターがさまざまなストレージバックエンドを使用できるようにする Container Storage Interface (CSI) ドライバーもインストールします。
クラスターストレージ機能が無効になっている場合、クラスターにデフォルトの storageclass または CSI ドライバーはありません。クラスターストレージ機能が無効になっている場合、管理者権限を持つユーザーは、デフォルトの storageclass を作成して CSI ドライバーを手動でインストールできます。
注記
- Operator が作成するストレージクラスは、そのアノテーションを編集することで非デフォルトにすることができますが、Operator が実行されているかぎり、このストレージクラスを削除することはできません。
3.2.3. コンソール機能
目的
Console Operator は、コンソール 機能を提供します。
Console Operator は OpenShift Container Platform Web コンソールをクラスターにインストールし、維持します。Console Operator はデフォルトでインストールされ、コンソールを自動的に維持します。
関連情報
3.2.4. CSI スナップショットコントローラー機能
目的
Cluster CSI Snapshot Controller Operator は、CSISnapshot 機能を提供します。
Cluster CSI Snapshot Controller Operator は、CSI Snapshot Controller をインストールし、維持します。CSI Snapshot Controller は VolumeSnapshot CRD オブジェクトを監視し、ボリュームスナップショットの作成および削除のライフサイクルを管理します。
関連情報
3.2.5. Insights 機能
目的
Insights Operator は、Insights 機能を提供します。
Insights Operator は OpenShift Container Platform 設定データを収集し、これを Red Hat に送信します。このデータは、クラスターで発生する可能性のある問題について、今後を見据えた上で、事前に対応できる内容に関して推奨事項を生み出します。これらの今後の対応案は、console.redhat.comの Insights Advisor を介してクラスター管理者に伝達されます。
注記
Insights Operator は、OpenShift Container Platform Telemetry を補完します。
3.2.6. マーケットプレイス機能
目的
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 を設定することで個々のカタログを有効または無効にすることができます。
3.2.7. 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 テンプレートとして分類されます。
サンプル機能を無効にすると、ユーザーはそれが提供するイメージストリーム、サンプル、およびテンプレートにアクセスできなくなります。デプロイメントによっては、このコンポーネントが不要な場合は無効にすることができます。
3.3. 関連情報
第4章 FIPS 暗号のサポート
x86_64、ppc64le、および s390x アーキテクチャーで FIPS 検証済み/Modules In Process 暗号化ライブラリーを使用する OpenShift Container Platform クラスターをインストールできます。
クラスターで 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 検証済みまたは進行中のモジュール (Modules in Process) 暗号パッケージのみが有効になります。
FIPS はクラスターが使用するオペレーティングシステムの初回の起動前に有効にされている必要があり、クラスターをデプロイしてから FIPS を有効にすることはできません。
4.1. OpenShift Container Platform での FIPS 検証
OpenShift Container Platform は、それが使用するオペレーティングシステムのコンポーネント用に RHEL および RHCOS 内の特定の FIPS 検証済みまたは進行中のモジュール (Modules in Process) モジュールを使用します。RHEL8 core crypto components を参照してください。たとえば、ユーザーが SSH を使用して OpenShift Container Platform クラスターおよびコンテナーに接続する場合、その接続は適切に暗号化されます。
OpenShift Container Platform コンポーネントは Go で作成され、Red Hat の golang コンパイラーを使用してビルドされます。クラスターの FIPS モードを有効にすると、暗号署名を必要とするすべての OpenShift Container Platform コンポーネントは RHEL および RHCOS 暗号ライブラリーを呼び出します。
| 属性 | 制限事項 |
|---|---|
| RHEL 8 および RHCOS オペレーティングシステムでの FIPS サポート。 | FIPS 実装は、ハッシュ関数を計算し、そのハッシュに基づくキーを検証する単一の機能を提供しません。この制限については、今後の OpenShift Container Platform リリースで継続的に評価され、改善されます。 |
| CRI-O ランタイムの FIPS サポート。 | |
| OpenShift Container Platform サービスの FIPS サポート。 | |
| RHEL 8 および RHCOS バイナリーおよびイメージから取得される FIPS 検証済みまたは進行中のモジュール (Modules in Process) 暗号化モジュールおよびアルゴリズム。 | |
| FIPS と互換性のある golang コンパイラーの使用。 | TLS FIPS サポートは完全に実装されていませんが、今後の OpenShift Container Platform リリースで予定されています。 |
| 複数のアーキテクチャー間の FIPS サポート。 |
FIPS は現在、 |
4.2. クラスターが使用するコンポーネントでの FIPS サポート
OpenShift Container Platform クラスター自体は FIPS 検証済みまたは進行中のモジュール (Modules in Process) モジュールを使用しますが、OpenShift Container Platform クラスターをサポートするシステムが暗号化の FIPS 検証済みまたは進行中のモジュール (Modules in Process) モジュールを使用していることを確認してください。
4.2.1. etcd
etcd に保存されるシークレットが FIPS 検証済みまたは進行中のモジュール (Modules in Process) の暗号を使用できるようにするには、ノードを FIPS モードで起動します。クラスターを FIPS モードでインストールした後に、FIPS 承認の aes cbc 暗号アルゴリズムを使用して etcd データを暗号化 できます。
4.2.2. ストレージ
ローカルストレージの場合は、RHEL が提供するディスク暗号化または RHEL が提供するディスク暗号化を使用する Container Native Storage を使用します。RHEL が提供するディスク暗号を使用するボリュームにすべてのデータを保存し、クラスター用に FIPS モードを有効にすることで、移動しないデータと移動するデータまたはネットワークデータは FIPS の検証済みまたは進行中のモジュール (Modules in Process) の暗号化によって保護されます。ノードのカスタマイズ で説明されているように、各ノードのルートファイルシステムを暗号化するようにクラスターを設定できます。
4.2.3. ランタイム
コンテナーに対して FIPS 検証済みまたは進行中のモジュール (Modules in Process) 暗号モジュールを使用しているホストで実行されていることを認識させるには、CRI-O を使用してランタイムを管理します。
4.3. FIPS モードでのクラスターのインストール
FIPS モードでクラスターをインストールするには、必要なインフラストラクチャーにカスタマイズされたクラスターをインストールする方法の説明に従ってください。クラスターをデプロイする前に、fips: true を install-config.yaml ファイルに設定していることを確認します。
Azure File ストレージを使用している場合、FIPS モードを有効にすることはできません。
AES CBC 暗号化を etcd データストアに適用するには、クラスターをインストールした後に etcd データの暗号化 プロセスを実行してください。
RHEL ノードをクラスターに追加する場合は、初回の起動前に FIPS モードをマシン上で有効にしていることを確認してください。Adding RHEL compute machines to an OpenShift Container Platform cluster および RHEL 8 ドキュメントの Enabling FIPS Mode を参照してください。
Legal Notice
Copyright © 2024 Red Hat, Inc.
OpenShift documentation is licensed under the Apache License 2.0 (https://www.apache.org/licenses/LICENSE-2.0).
Modified versions must remove all Red Hat trademarks.
Portions adapted from https://github.com/kubernetes-incubator/service-catalog/ with modifications by Red Hat.
Red Hat, Red Hat Enterprise Linux, the Red Hat logo, the Shadowman logo, JBoss, OpenShift, Fedora, the Infinity logo, and RHCE are trademarks of Red Hat, Inc., registered in the United States and other countries.
Linux® is the registered trademark of Linus Torvalds in the United States and other countries.
Java® is a registered trademark of Oracle and/or its affiliates.
XFS® is a trademark of Silicon Graphics International Corp. or its subsidiaries in the United States and/or other countries.
MySQL® is a registered trademark of MySQL AB in the United States, the European Union and other countries.
Node.js® is an official trademark of Joyent. Red Hat Software Collections is not formally related to or endorsed by the official Joyent Node.js open source or commercial project.
The OpenStack® Word Mark and OpenStack logo are either registered trademarks/service marks or trademarks/service marks of the OpenStack Foundation, in the United States and other countries and are used with the OpenStack Foundation’s permission. We are not affiliated with, endorsed or sponsored by the OpenStack Foundation, or the OpenStack community.
All other trademarks are the property of their respective owners.
