第1章 OpenShift Container Platform インストールの概要
1.1. OpenShift Container Platform インストールの概要
OpenShift Container Platform インストールプログラムは柔軟性を提供します。インストールプログラムを使用して、インストールプログラムがプロビジョニングし、クラスターで維持するインフラストラクチャーでクラスターをデプロイしたり、ユーザーが独自に準備し、維持するインフラストラクチャーでクラスターをデプロイしたりすることができます。
OpenShift Container Platform クラスターの基本的な 2 つのタイプとして、インストーラーでプロビジョニングされるインフラストラクチャークラスターとユーザーによってプロビジョニングされるインフラストラクチャークラスターがあります。
これらのクラスターのタイプにはどちらにも以下の特徴があります。
- 単一障害点のない可用性の高いインフラストラクチャーがデフォルトで利用可能である。
- 管理者は適用される更新内容および更新タイミングを制御できる。
同一のインストールプログラムを使用してこれらクラスターの両方のタイプをデプロイできます。インストールプログラムで生成される主なアセットは ブートストラップ、マスターおよびワーカーマシンの 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 カーネルを特長としています。これには、Kubernetes ノードエージェントである kubelet や、Kubernetes に対して最適化される CRI-O コンテナーランタイムが含まれます。
OpenShift Container Platform 4.10 クラスターのすべてのコントロールプレーンは、Ignition と呼ばれる最初の起動時に使用される重要なプロビジョニングツールが含まれる RHCOS を使用する必要があります。このツールは、クラスターのマシンの設定を可能にします。オペレーティングシステムの更新は、Operator によってクラスター全体にデプロイメントされるコンテナーイメージに組み込まれる Atomic OSTree リポジトリーとして提供されます。実際のオペレーティングシステムの変更については、rpm-ostree を使用する atomic 操作として各マシンでインプレースで実行されます。これらのテクノロジーを組み合わせて使用することにより、OpenShift Container Platform では、プラットフォーム全体を最新の状態に保つインプレースアップグレードで、その他のアプリケーションをクラスターで管理するかのようにオペレーティングシステムを管理することができます。これらのインプレースアップグレードにより、オペレーションチームの負担を軽減することができます。
すべてのクラスターマシンのオペレーティングシステムとして RHCOS を使用する場合、クラスターはオペレーティングシステムを含むコンポーネントとマシンのあらゆる側面を管理します。このため、マシンを変更できるのは、インストールプログラムと Machine Config Operator だけです。インストールプログラムは Ignition 設定ファイルを使用して各マシンの状態を設定し、Machine Config Operator はインストール後に、新規証明書またはキーの適用などのマシンへの変更を実行します。
1.1.1. インストールプロセス
OpenShift Container Platform クラスターをインストールする場合、インストールプログラムを OpenShift Cluster Manager サイトの適切な インフラストラクチャープロバイダー ページからダウンロードします。このサイトでは以下を管理しています。
- アカウントの REST API
- 必要なコンポーネントを取得するために使用するプルシークレットであるレジストリートークン
- クラスターのアイデンティティーを Red Hat アカウントに関連付けて使用状況のメトリックの収集を容易にするクラスター登録
OpenShift Container Platform 4.10 では、インストールプログラムは、一連のアセットに対して一連のファイル変換を実行する Go バイナリーファイルです。インストールプログラムと対話する方法は、インストールタイプによって異なります。
- インストーラーでプロビジョニングされるインフラストラクチャーのクラスターの場合、インフラストラクチャーのブートストラップおよびプロビジョニングは、ユーザーが独自に行うのではなくインストールプログラムが代行します。インストールプログラムは、クラスターをサポートするために必要なネットワーク、マシン、およびオペレーティングシステムのすべてを作成します。
- クラスターのインフラストラクチャーを独自にプロビジョニングし、管理する場合には、ブートストラップマシン、ネットワーク、負荷分散、ストレージ、および個々のクラスターマシンを含む、すべてのクラスターインフラストラクチャーおよびリソースを指定する必要があります。
インストール時には、お使いのマシンタイプ用の install-config.yaml という名前のインストール設定ファイル、Kubernetes マニフェスト、および Ingition 設定ファイルの 3 つのファイルセットを使用します。
インストール時に、Kubernetes および基礎となる RHCOS オペレーティングシステムを制御する Ignition 設定ファイルを変更することができます。ただし、これらのオブジェクトに対して加える変更の適合性を確認するための検証の方法はなく、これらのオブジェクトを変更するとクラスターが機能しなくなる可能性があります。これらのオブジェクトを変更する場合、クラスターが機能しなくなる可能性があります。このリスクがあるために、変更方法についての文書化された手順に従っているか、Red Hat サポートが変更することを指示した場合を除き、Kubernetes および Ignition 設定ファイルの変更はサポートされていません。
インストール設定ファイルは Kubernetes マニフェストに変換され、その後マニフェストは Ignition 設定にラップされます。インストールプログラムはこれらの Ignition 設定ファイルを使用してクラスターを作成します。
インストール設定ファイルはインストールプログラムの実行時にすべてプルーニングされるため、再び使用する必要のあるすべての設定ファイルをバックアップしてください。
インストール時に設定したパラメーターを変更することはできませんが、インストール後に数多くのクラスター属性を変更することができます。
インストーラーでプロビジョニングされるインフラストラクチャーでのインストールプロセス
デフォルトのインストールタイプは、インストーラーでプロビジョニングされるインフラストラクチャーです。デフォルトで、インストールプログラムはインストールウィザードとして機能し、独自に判別できない値の入力を求めるプロンプトを出し、残りのパラメーターに妥当なデフォルト値を提供します。インストールプロセスは、高度なインフラストラクチャーシナリオに対応するようカスタマイズすることもできます。インストールプログラムは、クラスターの基盤となるインフラストラクチャーをプロビジョニングします。
標準クラスターまたはカスタマイズされたクラスターのいずれかをインストールすることができます。標準クラスターの場合、クラスターをインストールするために必要な最小限の詳細情報を指定します。カスタマイズされたクラスターの場合、コントロールプレーンが使用するマシン数、クラスターがデプロイする仮想マシンのタイプ、または Kubernetes サービスネットワークの CIDR 範囲などのプラットフォームについての詳細を指定することができます。
可能な場合は、この機能を使用してクラスターインフラストラクチャーのプロビジョニングと保守の手間を省くようにしてください。他のすべての環境の場合には、インストールプログラムを使用してクラスターインフラストラクチャーをプロビジョニングするために必要なアセットを生成できます。
インストーラーでプロビジョニングされるインフラストラクチャークラスターの場合、OpenShift Container Platform は、オペレーティングシステム自体を含むクラスターのすべての側面を管理します。各マシンは、それが参加するクラスターでホストされるリソースを参照する設定に基づいて起動します。この設定により、クラスターは更新の適用時に自己管理できます。
ユーザーによってプロビジョニングされるインフラストラクチャーを使用したインストールプロセス
OpenShift Container Platform はユーザーが独自にプロビジョニングするインフラストラクチャーにインストールすることもできます。インストールプログラムを使用してクラスターインフラストラクチャーのプロビジョニングに必要なアセットを生成し、クラスターインフラストラクチャーを作成し、その後にクラスターをプロビジョニングしたインフラストラクチャーにデプロイします。
インストールプログラムがプロビジョニングするインフラストラクチャーを使用しない場合、以下を含むクラスターリソースを管理し、維持する必要があります。
- クラスターを設定するコントロールプレーンおよびコンピュートマシンの基礎となるインフラストラクチャー
- ロードバランサー
- DNS レコードおよび必要なサブネットを含むクラスターネットワーク
- クラスターインフラストラクチャーおよびアプリケーションのストレージ
クラスターでユーザーによってプロビジョニングされるインフラストラクチャーを使用する場合には、RHEL コンピュートマシンをクラスターに追加するオプションを使用できます。
インストールプロセスの詳細
クラスターの各マシンにはプロビジョニング時にクラスターについての情報が必要になるため、OpenShift Container Platform は初期設定時に一時的な bootstrap マシンを使用し、必要な情報を永続的なコントロールマシンに提供します。これは、クラスターの作成方法を記述する 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.2. インストール後のノード状態の確認
以下のインストールヘルスチェックが正常に行われると、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.3. 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 の概要 を参照してください。
