インストールの概要

インストールプログラムを使用して、各タイプのクラスターをデプロイメントできます。インストールプログラムは、ブートストラップ、コントロールプレーン、コンピュートマシンの Ignition 設定ファイルなどのメインアセットを生成します。インフラストラクチャーを適切に設定している場合は、これらの 3 つのマシン設定を使用して OpenShift Container Platform クラスターを起動できます。

OpenShift Container Platform インストールプログラムは、クラスターのインストールを管理するために一連のターゲットおよび依存関係を使用します。インストールプログラムには、達成する必要のある一連のターゲットが設定され、それぞれのターゲットには一連の依存関係が含まれます。各ターゲットはそれぞれの依存関係の条件が満たされ次第、別個に解決されるため、インストールプログラムは複数のターゲットを並行して達成できるように動作し、最終的にクラスターが実行するようにします。プログラムが依存関係を満たしているため、インストールプログラムはコマンドを実行してコンポーネントを再作成する代わりに、既存のコンポーネントを認識して使用します。

図1.1 OpenShift Container Platform インストールのターゲットおよび依存関係

インストール後に、各クラスターマシンは Red Hat Enterprise Linux CoreOS (RHCOS) をオペレーティングマシンとして使用します。RHCOS は Red Hat Enterprise Linux (RHEL) の不変のコンテナーホストのバージョンであり、デフォルトで SELinux が有効になっている RHEL カーネルを特長としています。RHCOS には、Kubernetes ノードエージェントである kubelet や、Kubernetes に対して最適化される CRI-O コンテナーランタイムが含まれます。

OpenShift Container Platform 4.17 クラスターのすべてのコントロールプレーンは、Ignition と呼ばれる最初の起動時に使用される重要なプロビジョニングツールが含まれる RHCOS を使用する必要があります。このツールは、クラスターのマシンの設定を可能にします。オペレーティングシステムの更新は、OSTree をバックエンドとして使用する起動可能なコンテナーイメージとして配信され、Machine Config Operator によりクラスター全体にデプロイされます。実際のオペレーティングシステムの変更は、rpm-ostree を使用することにより、atomic 操作として各マシン上でインプレースで行われます。これらのテクノロジーを組み合わせることで、OpenShift Container Platform は、プラットフォーム全体を最新の状態に保つインプレースアップグレードにより、クラスター上の他のアプリケーションを管理するのと同じようにオペレーティングシステムを管理できるようになります。これらのインプレースアップグレードにより、オペレーションチームの負担を軽減できます。

すべてのクラスターマシンのオペレーティングシステムとして RHCOS を使用する場合、クラスターはオペレーティングシステムを含むコンポーネントとマシンのあらゆる側面を管理します。このため、マシンを変更できるのは、インストールプログラムと Machine Config Operator だけです。インストールプログラムは、Ignition 設定ファイルを使用して各マシンの正確な状態を設定し、インストール後に Machine Config Operator が新しい証明書やキーの適用などのマシンへの追加の変更を完了します。

この用語集では、インストールコンテンツに関する一般的な用語を定義しています。インストールプロセスの理解を深めるために、次の用語リストを確認してください。

Assisted Installer を除き、OpenShift Container Platform クラスターをインストールする場合は、OpenShift Cluster Manager Hybrid Cloud Console の適切な クラスタータイプ ページから、インストールプログラムをダウンロードする必要があります。このコンソールは以下を管理します。

OpenShift Container Platform 4.17 では、インストールプログラムは、一連のアセットに対して一連のファイル変換を実行する Go バイナリーファイルです。インストールプログラムと対話する方法は、インストールタイプによって異なります。次のインストールユースケースを検討してください。

インストールプログラムの場合、プログラムはインストール中に 3 つのファイルセットを使用します。それは、install-config.yaml という名前のインストール設定ファイル、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 はユーザーが独自にプロビジョニングするインフラストラクチャーにインストールすることもできます。インストールプログラムを使用してクラスターインフラストラクチャーのプロビジョニングに必要なアセットを生成し、クラスターインフラストラクチャーを作成し、その後にクラスターをプロビジョニングしたインフラストラクチャーにデプロイします。

インストールプログラムがプロビジョニングしたインフラストラクチャーを使用しない場合は、クラスターリソースをユーザー自身で管理し、維持する必要があります。次のリストは、一部のセルフマネージドリソースの詳細を示しています。

クラスターで user-provisioned infrastructure を使用する場合は、RHEL コンピュートマシンをクラスターに追加するオプションを使用できます。

インストールプロセスの詳細

クラスターがプロビジョニングされると、クラスター内の各マシンにはクラスターに関する情報が必要になります。OpenShift Container Platform は初期設定時に一時的なブートストラップマシンを使用して、必要な情報を永続的なコントロールプレーンに提供します。一時的なブートストラップマシンは、クラスターの作成方法を記述する Ignition 設定ファイルを使用して起動します。ブートストラップマシンは、コントロールプレーンを設定するコントロールプレーンマシンを作成します。その後、コントロールプレーンマシンはコンピュートマシン (ワーカーマシンとしても知られる) を作成します。以下の図はこのプロセスを示しています。

図1.2 ブートストラップ、コントロールプレーンおよびコンピュートマシンの作成

クラスターマシンを初期化した後、ブートストラップマシンは破棄されます。すべてのクラスターがこのブートストラッププロセスを使用してクラスターを初期化しますが、ユーザーがクラスターのインフラストラクチャーをプロビジョニングする場合は、多くの手順を手動で実行する必要があります。

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

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

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

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

インストールのスコープ

OpenShift Container Platform インストールプログラムのスコープは意図的に狭められています。単純さを確保し、確実にインストールを実行できるように設計されているためです。インストールが完了した後に数多くの設定タスクを実行できます。

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 の概要 を参照してください。

OpenShift Container Platform を独自にインストールし、管理する必要がある場合、以下のプラットフォームにインストールすることができます。

OpenShift Container Platform 4 クラスターは、オンプレミスハードウェアとクラウドホストサービスの両方にデプロイできますが、クラスターのすべてのマシンは同じデータセンターまたはクラウドホストサービスにある必要があります。

OpenShift Container Platform を使用する必要があるが、クラスターを独自に管理する必要がない場合は、複数のマネージドサービスの選択肢から選ぶことができます。Red Hat によって完全に管理されるクラスターが必要な場合は、OpenShift Dedicated を使用できます。OpenShift を Azure、AWS、IBM Cloud®、または Google Cloud Platform でマネージドサービスとして使用することもできます。マネージドサービスの詳細は、OpenShift の製品 ページを参照してください。クラウド仮想マシンを仮想ベアメタルとして OpenShift Container Platform クラスターをインストールする場合、対応するクラウドベースのストレージはサポートされません。

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 に移行するにあたり、任意のタイプの実稼働用のクラスターのインストールプロセスを使用して新規クラスターを作成できます。

オペレーティングシステムは OpenShift Container Platform に不可欠な要素であり、OpenShift Container Platform のインストールプログラムはすべてのインフラストラクチャーの起動を簡単に実行できます。これらは、installer provisioned infrastructure のインストールと呼ばれています。この種のインストールでは、ユーザーは既存のインフラストラクチャーをクラスターに提供できますが、インストールプログラムがクラスターを最初に必要とするすべてのマシンをデプロイします。

installer-provisioned infrastructure クラスターは、クラスターまたはその基盤となるマシンに対するカスタマイズを指定せずに、AWS、Azure、Azure Stack Hub、GCP、Nutanix にデプロイできます。

クラスターマシンのインスタンスタイプなど、installer-provisioned infrastructure クラスターの基本設定を行う必要がある場合は、AWS、Azure、GCP、Nutanix のインストールをカスタマイズできます。

installer-provisioned infrastructure のインストールの場合、AWS の既存の VPC、Azure の vNet、または GCP の VPC を使用できます。ネットワークインフラストラクチャーの一部を再利用して、AWS、Azure、または GCP のクラスターが環境内の既存の IP アドレスの割り当てと共存し、既存の MTU および VXLAN 設定と統合するようにできます。これらのクラウドに既存のアカウントおよび認証情報がある場合は、それらを再利用できますが、OpenShift Container Platform クラスターをインストールするために必要なパーミッションを持つようアカウントを変更する必要がある場合があります。

installer-provisioned infrastructure 方式を使用すると、vSphere および ベアメタル のハードウェアに適切なマシンインスタンスを作成できます。さらに、vSphere では、インストール時に追加のネットワークパラメーターをカスタマイズすることもできます。

VMware vSphere やベアメタルプラットフォームなどの一部の installer-provisioned infrastructure インストールでは、Ingress 仮想 IP (VIP) に到達する外部トラフィックがデフォルトの IngressController レプリカ間で分散されません。ベースライン IngressController ルーターのパフォーマンスを超えることが予想される vSphere およびベアメタル installer-provisioned infrastructure インストールでは、外部ロードバランサーを設定する必要があります。外部ロードバランサーを設定すると、複数の IngressController レプリカのパフォーマンスが実現します。ベースライン IngressController パフォーマンスの詳細は、ベースライン Ingress Controller (ルーター) パフォーマンス を参照してください。外部ロードバランサーの設定の詳細は、ユーザー管理ロードバランサーの設定 を参照してください。

大規模なクラウドインフラストラクチャーを再利用する必要がある場合、user-provisioned infrastructure のインストールを実行できます。これらのインストールでは、インストールプロセス時にクラスターに必要なマシンを手動でデプロイします。AWS、Azure、および Azure Stack Hub で user-provisioned infrastructure を実行する場合、提供されるテンプレートを使用して必要なすべてのコンポーネントを起動できます。共有 VPC on GCP を再利用することもできます。それ以外の場合は、プロバイダーに依存しない インストール方法を使用して、クラスターを他のクラウドにデプロイすることができます。

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

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

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

非接続のクラスターまたはネットワークが制限されたクラスターなど、インターネットへのアクセスが限定されたクラスターをインストールする必要がある場合、インストールパッケージをミラーリング し、そこからクラスターをインストールできます。user-provisioned infrastructure によるインストールの詳細な手順を実行して、AWS、GCP、IBM Z® または IBM® LinuxONE、RHEL KVM が搭載された IBM Z® または IBM® LinuxONE、IBM Power®、vSphere、または ベアメタル のネットワークが制限された環境にインストールしてください。ネットワークが制限された環境へのクラスターのインストールは、installer-provisioned infrastructure を使用して、AWS、GCP、IBM Cloud®、Nutanix、RHOSP、および vSphere 用の詳細な手順に従って実行することもできます。

クラスターを AWS GovCloud リージョン、AWS China リージョン、または Azure government リージョン にデプロイする必要がある場合は、installer-provisioned infrastructure のインストール時にこれらのカスタムリージョンを設定できます。

インストール中に FIPS 140-2/140-3 検証 のために NIST に提出された RHEL 暗号化ライブラリーを使用するようにクラスターマシンを設定することもできます。

目的

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 を使用したインストールの実行中に限り、ベアメタル機能を無効にすることを推奨します。

目的

Build 機能により、Build API が有効になります。Build API は、Build オブジェクトと BuildConfig オブジェクトのライフサイクルを管理します。

目的

Cloud Controller Manager Operator は、CloudControllerManager の機能を提供します。

クラスターのインストール設定 (install-config.yaml) ファイルの値を確認することで、クラスターが CloudControllerManager 機能の無効化をサポートしているかどうかを判断できます。

install-config.yaml ファイルで、platform パラメーターを見つけます。

Cloud Controller Manager Operator は、OpenShift Container Platform 上にデプロイされた Cloud Controller Manager を管理および更新します。Operator は Kubebuilder フレームワークおよび controller-runtime ライブラリーに基づいています。これは Cluster Version Operator (CVO) を使用してインストールされます。

これには、以下のコンポーネントが含まれます。

デフォルトで、Operator は metrics サービス経由で Prometheus メトリックを公開します。

目的

Cloud Credential Operator は、CloudCredential の機能を提供します。

Cloud Credential Operator (CCO) は、クラウドプロバイダーの認証情報を Kubernetes カスタムリソース定義 (CRD) として管理します。CCO は CredentialsRequest カスタムリソース (CR) で同期し、OpenShift Container Platform コンポーネントが、クラスターの実行に必要な特定のパーミッションと共にクラウドプロバイダーの認証情報を要求できるようにします。

install-config.yaml ファイルで credentialsMode パラメーターに異なる値を設定すると、CCO は複数の異なるモードで動作するように設定できます。モードが指定されていない場合や、credentialsMode パラメーターが空の文字列 ("") に設定されている場合は、CCO はデフォルトモードで動作します。

目的

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

プロジェクト

cluster-image-registry-operator

目的

Cluster Storage Operator は、Storage 機能を提供します。

Cluster Storage Operator は OpenShift Container Platform のクラスター全体のストレージのデフォルト値を設定します。これにより、OpenShift Container Platform クラスターのデフォルトの storageclass の存在を確認できます。また、クラスターがさまざまなストレージバックエンドを使用できるようにする Container Storage Interface (CSI) ドライバーもインストールします。

注記

目的

Console Operator は、コンソール 機能を提供します。

Console Operator は OpenShift Container Platform Web コンソールをクラスターにインストールし、維持します。Console Operator はデフォルトでインストールされ、コンソールを自動的に維持します。

目的

Cluster CSI Snapshot Controller Operator は、CSISnapshot 機能を提供します。

Cluster CSI Snapshot Controller Operator は、CSI Snapshot Controller をインストールし、維持します。CSI Snapshot Controller は VolumeSnapshot CRD オブジェクトを監視し、ボリュームスナップショットの作成および削除のライフサイクルを管理します。

目的

DeploymentConfig 機能は、DeploymentConfig API を有効にして管理します。

目的

Ingress Operator は、Ingress 機能を提供します。Ingress 機能はデフォルトで有効になっています。

Ingress Operator は OpenShift Container Platform ルーターを設定し、管理します。

プロジェクト

openshift-ingress-operator

CRD

設定オブジェクト

注記

Ingress Operator はルーターを openshift-ingress プロジェクトに設定し、ルーターのデプロイメントを作成します。

$ oc get deployment -n openshift-ingress

Ingress Operator は、network/cluster ステータスの clusterNetwork[].cidr を使用して、管理 Ingress Controller (ルーター) が動作するモード (IPv4、IPv6、またはデュアルスタック) を判別します。たとえば、clusterNetwork に v6 cidr のみが含まれる場合、Ingress Controller は IPv6 専用モードで動作します。

以下の例では、Ingress Operator によって管理される Ingress Controller は、1 つのクラスターネットワークのみが存在し、ネットワークが IPv4 cidr であるために IPv4 専用モードで実行されます。

$ oc get network/cluster -o jsonpath='{.status.clusterNetwork[*]}'

map[cidr:10.128.0.0/14 hostPrefix:23]

目的

Insights Operator は、Insights 機能を提供します。

Insights Operator は OpenShift Container Platform 設定データを収集し、これを Red Hat に送信します。このデータは、クラスターで発生する可能性のある問題について、今後を見据えた上で、事前に対応できる内容に関して推奨事項を生み出します。これらの今後の対応案は、console.redhat.comの Insights Advisor を介してクラスター管理者に伝達されます。

注記

Insights Operator は、OpenShift Container Platform Telemetry を補完します。

目的

machine-api-operator、cluster-autoscaler-operator、および cluster-control-plane-machine-set-operator Operator は、MachineAPI 機能の機能を提供します。この機能は、user-provisioned infrastructure を使用してクラスターをインストールする場合にのみ無効にできます。

Machine API 機能は、クラスター内のすべてのマシンの設定と管理を担当します。インストール中に Machine API 機能を無効にした場合は、すべてのマシン関連タスクを手動で管理する必要があります。

目的

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 を設定することで個々のカタログを有効または無効にすることができます。

目的

Node Tuning Operator は、NodeTuning の機能を提供します。

Node Tuning Operator は、TuneD デーモンを調整することでノードレベルのチューニングを管理し、Performance Profile コントローラーを使用して低レイテンシーのパフォーマンスを実現するのに役立ちます。ほとんどの高パフォーマンスアプリケーションでは、一定レベルのカーネルのチューニングが必要です。Node Tuning Operator は、ノードレベルの sysctl の統一された管理インターフェイスをユーザーに提供し、ユーザーが指定するカスタムチューニングを追加できるよう柔軟性を提供します。

NodeTuning 機能を無効にすると、一部のデフォルトチューニング設定がコントロールプレーンノードに適用されなくなります。これにより、900 を超えるノードまたは 900 のルートを持つ大規模なクラスターのスケーラビリティとパフォーマンスが制限される可能性があります。

目的

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 テンプレートとして分類されます。

サンプル機能を無効にすると、ユーザーはそれが提供するイメージストリーム、サンプル、およびテンプレートにアクセスできなくなります。デプロイメントによっては、このコンポーネントが不要な場合は無効にすることができます。

目的

Operator Lifecycle Manager (OLM) を使用することにより、ユーザーは Kubernetes ネイティブアプリケーション (Operator) および OpenShift Container Platform クラスター全体で実行される関連サービスにインストール、更新、およびそのライフサイクルの管理を実行できます。これは、Operator を効果的かつ自動化された拡張可能な方法で管理するために設計されたオープンソースツールキットの Operator Framework の一部です。

Operator が次の API のいずれかを必要とする場合は、OperatorLifecycleManager 機能を有効にする必要があります。

etcd に保存されるシークレットが FIPS 検証済みまたは進行中のモジュール (Modules in Process) の暗号を使用できるようにするには、ノードを FIPS モードで起動します。クラスターを FIPS モードでインストールした後に、FIPS 承認の aes cbc 暗号アルゴリズムを使用して etcd データを暗号化 できます。

ローカルストレージの場合は、RHEL が提供するディスク暗号化または RHEL が提供するディスク暗号化を使用する Container Native Storage を使用します。RHEL が提供するディスク暗号を使用するボリュームにすべてのデータを保存し、クラスター用に FIPS モードを有効にすることで、移動しないデータと移動するデータまたはネットワークデータは FIPS の検証済みまたは進行中のモジュール (Modules in Process) の暗号化によって保護されます。ノードのカスタマイズ で説明されているように、各ノードのルートファイルシステムを暗号化するようにクラスターを設定できます。

コンテナーに対して FIPS 検証済みまたは進行中のモジュール (Modules in Process) 暗号モジュールを使用しているホストで実行されていることを認識させるには、CRI-O を使用してランタイムを管理します。