Red Hat Summit第3章 インストールおよび更新
3.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) をプロビジョニングに使用します。接続環境または非接続環境でクラスターをデプロイできます。
- 完全な制御: お客様が準備および保守するインフラストラクチャーにクラスターをデプロイメントできます。これにより、最大限のカスタマイズ性が提供されます。接続環境または非接続環境でクラスターをデプロイできます。
それぞれの方法でデプロイしたクラスターは、以下の特性を持ちます。
- 単一障害点のない高可用性インフラストラクチャーがデフォルトで利用可能です。
- 管理者は適用される更新の内容とタイミングを制御できます。
3.1.1. インストールプログラムについて
インストールプログラムを使用して、各タイプのクラスターをデプロイメントできます。インストールプログラムは、ブートストラップ、コントロールプレーン、コンピュートマシンの Ignition 設定ファイルなどのメインアセットを生成します。インフラストラクチャーを適切に設定している場合は、これらの 3 つのマシン設定を使用して OpenShift Container Platform クラスターを起動できます。
OpenShift Container Platform インストールプログラムは、クラスターのインストールを管理するために一連のターゲットおよび依存関係を使用します。インストールプログラムには、達成する必要のある一連のターゲットが設定され、それぞれのターゲットには一連の依存関係が含まれます。各ターゲットはそれぞれの依存関係の条件が満たされ次第、別個に解決されるため、インストールプログラムは複数のターゲットを並行して達成できるように動作し、最終的にクラスターが実行するようにします。プログラムが依存関係を満たしているため、インストールプログラムはコマンドを実行してコンポーネントを再作成する代わりに、既存のコンポーネントを認識して使用します。
図3.1 OpenShift Container Platform インストールのターゲットおよび依存関係
3.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.18 クラスターのすべてのコントロールプレーンは、Ignition と呼ばれる最初の起動時に使用される重要なプロビジョニングツールが含まれる RHCOS を使用する必要があります。このツールにより、クラスターのマシンの設定が可能になります。オペレーティングシステムの更新は、OSTree をバックエンドとして使用する起動可能なコンテナーイメージとして配信され、Machine Config Operator によりクラスター全体にデプロイされます。実際のオペレーティングシステムの変更は、rpm-ostree を使用することにより、atomic 操作として各マシン上でインプレースで行われます。これらのテクノロジーを組み合わせることで、OpenShift Container Platform は、プラットフォーム全体を最新の状態に保つインプレースアップグレードにより、クラスター上の他のアプリケーションを管理するのと同じようにオペレーティングシステムを管理できるようになります。これらのインプレースアップグレードにより、オペレーションチームの負担を軽減できます。
すべてのクラスターマシンのオペレーティングシステムとして RHCOS を使用する場合、クラスターはオペレーティングシステムを含むコンポーネントとマシンのあらゆる側面を管理します。このため、マシンを変更できるのは、インストールプログラムと Machine Config Operator だけです。インストールプログラムは Ignition 設定ファイルを使用して各マシンの状態を設定し、Machine Config Operator はインストール後に、新規証明書またはキーの適用などのマシンへの変更を実行します。
3.1.3. OpenShift Container Platform クラスターでサポートされるプラットフォーム
次の表は、OpenShift Container Platform クラスターのインストールに使用できるさまざまな方法のサポート対象のプラットフォームを示しています。
| Platform | installer-provisioned infrastructure [1] | user-provisioned infrastructure [2] | Agent-based Installer | Assisted Installer |
|---|---|---|---|---|
| Amazon Web Services (AWS) | X | X | ||
| ベアメタル | X | X | X | X |
| 外部 | X | X | ||
| Google Cloud Platform (GCP) | X | X | ||
| IBM Cloud® Classic | X | |||
| IBM Cloud® Virtual Private Cloud (VPC) | X | |||
| IBM Power® | X | X | X | |
| IBM Z® または IBM® LinuxONE | X | X | X | |
| Microsoft Azure | X | X | ||
| Microsoft Azure Stack Hub | X | X | ||
| None | X | X | ||
| Nutanix | X | X | ||
| Oracle Cloud Infrastructure (OCI) | X | X | ||
| Red Hat OpenStack Platform (RHOSP) [3] | X | X | ||
| VMware vSphere | X | X | X | X |
installer-provisioned infrastructure の場合: インストールプロセスを実行するコンピューターを含むすべてのマシンが、プラットフォームコンテナーのイメージをプルし、Red Hat にテレメトリーデータを提供するために、インターネットに直接アクセスできる必要があります。
重要インストール後は、以下の変更はサポートされません。
- クラウドプロバイダープラットフォームの混在。
- クラウドプロバイダーコンポーネントの混在。たとえば、クラスターをインストールしたプラットフォーム上の別のプラットフォームから永続ストレージフレームワークを使用します。
user-provisioned infrastructure の場合: user-provisioned infrastructure でインストールを実行すると、プラットフォームでサポートされているケースに応じて、完全なインターネットアクセスを備えたマシンを実行したり、クラスターをプロキシーの背後に配置したり、非接続インストールを実行したりできます。
非接続インストールでは、クラスターのインストールに必要なイメージをダウンロードして、ミラーレジストリーに配置し、そのデータを使用してクラスターをインストールできます。プラットフォームコンテナーのイメージをプルするには、インターネットへのアクセスが必要です。ただし、vSphere またはベアメタルインフラストラクチャー上での非接続インストールの場合、クラスターのマシンが直接インターネットにアクセスする必要はありません。
- Red Hat OpenStack Platform (RHOSP) の場合: OpenShift Container Platform の最新リリースでは、最新の RHOSP ロングライフリリースと中間リリースの両方がサポートされています。RHOSP リリースの互換性の詳細は、OpenShift Container Platform on RHOSP support matrix を参照してください。
OpenShift Container Platform 4.x Tested Integrations のページには、各種プラットフォームの統合テストの詳細が記載されています。
3.1.4. インストールプロセス
Assisted Installer を除き、OpenShift Container Platform クラスターをインストールする場合は、OpenShift Cluster Manager Hybrid Cloud Console の適切な クラスタータイプ ページから、インストールプログラムをダウンロードする必要があります。このコンソールは以下を管理します。
- アカウントの REST API。
- 必要なコンポーネントを取得するために使用するプルシークレットであるレジストリートークン。
- クラスターのアイデンティティーを Red Hat アカウントに関連付けて使用状況のメトリクスの収集を容易にするクラスター登録。
OpenShift Container Platform 4.18 では、インストールプログラムは、一連のアセットに対して一連のファイル変換を実行する 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 設定ファイルを使用して起動します。ブートストラップマシンは、コントロールプレーンを設定するコントロールプレーンマシンを作成します。その後、コントロールプレーンマシンはコンピュートマシン (ワーカーマシンとしても知られる) を作成します。以下の図はこのプロセスを示しています。
図3.2 ブートストラップ、コントロールプレーンおよびコンピュートマシンの作成
クラスターのデプロイを計画する際には、パフォーマンスとスケーラビリティーの推奨プラクティスをよく理解しておく必要があります。特に、etcd ストレージの入出力 (I/O) レイテンシーの要件と、推奨されるコントロールプレーンノードのサイジングの要件を確認してください。詳細は、「推奨される etcd プラクティス」および「コントロールプレーンノードのサイジング」を参照してください。
クラスターマシンを初期化した後、ブートストラップマシンは破棄されます。すべてのクラスターがこのブートストラッププロセスを使用してクラスターを初期化しますが、ユーザーがクラスターのインフラストラクチャーをプロビジョニングする場合は、多くの手順を手動で実行する必要があります。
-
インストールプログラムが生成する 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 クラスターが実行します。次に、クラスターはサポートされる環境でのコンピュートマシンの作成など、日常の操作に必要な残りのコンポーネントをダウンロードし、設定します。
インストールのスコープ
OpenShift Container Platform インストールプログラムのスコープは意図的に狭められています。単純さを確保し、確実にインストールを実行できるように設計されているためです。インストールが完了した後に数多くの設定タスクを実行できます。
関連情報
- OpenShift Container Platform 設定リソースの詳細は、利用可能なクラスターのカスタマイズ を参照してください。
