第3章 OpenShift Container Platform コントロールプレーン
3.1. OpenShift Container Platform コントロールプレーンについて
コンテナープレーンはマスターマシンから設定されており、OpenShift Container Platform クラスターを管理します。コントロールプレーンマシンは、コンピュートマシン (ワーカーマシンとしても知られる) のワークロードを管理します。クラスター自体は、Cluster Version Operator、Machine Config Operator、および個々の Operator のアクションによって、マシンへのすべてのアップグレードを管理します。
3.1.1. マシン設定プールを使用したノード設定管理
コントロールプレーンのコンポーネントまたはユーザーワークロードを実行するマシンは、それらが処理するリソースタイプに基づいてグループに分類されます。マシンのこれらのグループはマシン設定プール (MCP) と呼ばれます。それぞれの MCP はノードのセットおよびその対応するマシン設定を管理します。ノードのロールは、これが所属する MCP を判別します。MCP は割り当てられたノードロールラベルに基づいてノードを制御します。MCP のノードには同じ設定があります。つまり、ワークロードの増減に応じてノードのスケールアップおよび破棄が可能です。
デフォルトで、クラスターのインストール時にクラスターによって作成される 2 つの MCP ( master および worker) があります。それぞれのデフォルト MCP には、Machine Config Operator (MCO) によって適用される定義された設定があり、これは MCP を管理し、MCP アップグレードを容易にするために使用されます。追加の MCP またはカスタムプールを作成して、デフォルトのノードタイプの範囲を超えるカスタムユースケースを持つノードを管理できます。
カスタムプールは、ワーカープールから設定を継承するプールです。これらはワーカープールのターゲット設定を使用しますが、カスタムプールのみをターゲットに設定する変更をデプロイする機能を追加します。カスタムプールはワーカープールから設定を継承するため、ワーカープールへの変更もカスタムプールに適用されます。ワーカープールから設定を継承しないカスタムプールは MCO ではサポートされません。
ノードは 1 つの MCP にのみ含めることができます。ノードにいくつかの MCP に対応するラベルがある場合 (worker,infra など)、これはワーカープールではなく infra カスタムプールによって管理されます。カスタムプールは、ノードラベルに基づいて管理するノードの選択を優先します。カスタムプールに属さないノードはワーカープールによって管理されます。
クラスターで管理するすべてのノードロールについてカスタムプールを使用することが推奨されます。たとえば、infra ワークロードを処理するために infra ノードを作成する場合、それらのノードをまとめるためにカスタム infra MCP を作成することが推奨されます。infra ロールラベルをワーカーノードに適用し、これが worker,infra の二重ラベルを持つようにするものの、カスタム infra MCP がない場合、MCO はこれをワーカーノードと見なします。ノードから worker ラベルを削除して、これをカスタムプールで分類せずに infra ラベルを適用する場合、ノードは MCO によって認識されず、クラスターによって管理されません。
infra ワークロードのみを実行する infra ロールのラベルが付いたノードは、サブスクリプションの合計数にカウントされません。infra ノードを管理する MCP は、クラスターでサブスクリプション料金を決定する方法と相互に排他的です。適切な infra ロールを持つノードにテイントを付け、テイントを使用してユーザーのワークロードがそのノードにスケジュールされないようにすることが、infra ワークロードのサブスクリプション料金を防ぐための唯一の要件になります。
MCO はプールの更新を個別に適用します。たとえば、すべてのプールに影響を与える更新がある場合、各プールのノードは相互に並行して更新されます。カスタムプールを追加する場合、そのプールのノードはマスターおよびワーカーノードとの同時更新を試みます。
3.1.2. OpenShift Container Platform のマシンのロール
OpenShift Container Platform はホストに複数の異なるロールを割り当てます。これらのロールは、クラスター内のマシンの機能を定義します。クラスターには、標準のマスターおよびワーカーのロールタイプの定義が含まれます。
また、クラスターにはブートストラップロールの定義も含まれます。ブートストラップマシンが使用されるのはクラスターのインストール時のみであり、この機能については、クラスターインストールのドキュメントで説明されています。
3.1.2.1. クラスターのワーカー
Kubernetes のクラスターでは、Kubernetes のユーザーがリクエストした実際のワークロードは、ワーカーノードで実行され、管理されます。ワーカーノードは、独自の容量と (マスターサービスの一部である) スケジューラーを公開し、どのノードでコンテナーと Pod を起動するかを決定します。重要なサービスは各ワーカーノードで実行されますが、これには、コンテナーエンジンである CRI-O、コンテナーのワークロードの実行と停止の要求を受け入れ、実行するサービスである Kubelet、ワーカー間での Pod の通信を管理するサービスプロキシーが含まれます。
OpenShift Container Platform では、マシンセットがワーカーマシンを制御します。ワーカーのロールを持つマシンは、自動スケーリングを行う特定のマシンプールによって制御されるコンピュートワークロードを実行します。OpenShift Container Platform は複数のマシンタイプをサポートすることができ、ワーカーマシンは コンピュートマシンとして分類されています。本リリースでは、コンピュートマシンの唯一のデフォルトタイプはワーカーマシンであるため、本リリースでは ワーカーマシン と コンピュートマシン は相互に置き換え可能な用語として使用されています。OpenShift Container Platform の今後のバージョンでは、インフラストラクチャーマシンなどの異なる種類のコンピュートマシンがデフォルトで使用される可能性があります。
マシンセットは machine-api namespace 下のマシンリソースのグループです。マシンセットは、特定のクラウドプロバイダーで新規マシンを起動するように設計されている設定です。マシン設定プール (MCP) は Machine Config Operator (MCO) namespace の一部です。MCP は、MCO がそれらの設定を管理し、それらのアップグレードを容易に実行できるようにマシンをまとめるために使用されます。
3.1.2.2. クラスターのマスター
Kubernetes のクラスターでは、マスターノードは Kubernetes クラスターの制御に必要なサービスを実行します。OpenShift Container Platform では、マスターマシンはコントロールプレーンになります。これには、OpenShift Container Platform のクラスターを管理する Kubernetes サービス以外も含まれます。コントロールプレーンのロールを持つすべてのマシンがマスターマシンであるため、 マスター と コントロールプレーン はこれらを説明する際の相互に置き換え可能な用語として使用されています。マスターマシンは、マシンセットにグループ化されるのではなく、一連のスタンドアロンマシン API リソースによって定義されます。 すべてのマスターマシンが削除されてクラスターが切断されないようにするために、追加の制御がマスターマシンに適用されます。
3 つのマスターノードのみが、すべての実稼働デプロイメントで使用される必要があります。
マスター上の Kubernetes カテゴリーに分類されるサービスには、Kubernetes API サーバー、etcd、Kubernetes コントローラーマネージャー、Kubernetes スケジューラーが含まれます。
| コンポーネント | 説明 |
|---|---|
| API サーバー | Kubernetes API サーバーは Pod、サービスおよびレプリケーションコントローラーのデータを検証し、設定します。また、クラスターの共有される状態を確認できる中心的な部分として機能します。 |
| etcd | etcd はマスターの永続的な状態を保存し、他のコンポーネントは etcd で変更の有無を監視して、それぞれを指定された状態に切り替えます。 |
| コントローラーマネージャーサーバー | コントローラーマネージャーサーバーは etcd でレプリケーション、namespace、サービスアカウントコントローラーのオブジェクトへの変更の有無を監視し、API を使用して指定された状態を実行します。このような複数のプロセスは、一度に 1 つのアクティブなリーダーを設定してクラスターを作成します。 |
| Kubernetes スケジューラー | Kubernetes スケジューラーは、割り当て済みのノードなしで新規に作成された Pod の有無を監視し、Pod をホストする最適なノードを選択します。 |
マスターマシン上のこれらサービスの一部は systemd サービスとして実行し、それ以外は 静的な Pod として実行されます。
systemd サービスは、起動直後の特定のシステムで常に起動している必要のあるサービスに適しています。マスターマシンの場合は、リモートログインを可能にする sshd も含まれます。また、以下のようなサービスも含まれます。
- CRI-O コンテナーエンジン (crio): コンテナーを実行し、管理します。OpenShift Container Platform 4.5 は、Docker Container Engine ではなく CRI-O を使用します。
- Kubelet (kubelet): マシン上で、マスターサービスからのコンテナー管理要求を受け入れます。
CRI-O および Kubelet は、他のコンテナーを実行する前に実行されている必要があるため、systemd サービスとしてホスト上で直接実行される必要があります。
installer-* および revision-pruner-* コントロールプレーン Pod は、root ユーザーが所有する /etc/kubernetes ディレクトリーに書き込むため、root パーミッションで実行する必要があります。これらの Pod は以下の namespace に置かれます。
-
openshift-etcd -
openshift-kube-apiserver -
openshift-kube-controller-manager -
openshift-kube-scheduler
3.1.3. OpenShift Container Platform の Operator
OpenShift Container Platform では、Operator はコントロールプレーンでサービスをパッケージ化し、デプロイし、管理するための推奨される方法です。Operator の使用は、ユーザーが実行するアプリケーションにも各種の利点があります。Operator は kubectl や oc コマンドなどの Kubernetes API および CLI ツールと統合します。Operator はアプリケーションの監視、ヘルスチェックの実行、OTA (over-the-air) 更新の管理を実行し、アプリケーションが指定した状態にあることを確認するための手段となります。
CRI-O と Kubelet はすべてのノード上で実行されるため、Operator を使用することにより、ほぼすべての他のクラスター機能をコントロールプレーンで管理できます。Operator は OpenShift Container Platform 4.5 の最も重要なコンポーネントです。Operator を使用してコントロールプレーンに追加されるコンポーネントには、重要なネットワークおよび認証情報サービスが含まれます。
OpenShift Container Platform クラスターの他の Operator を管理する Operator は Cluster Version Operator です。
OpenShift Container Platform 4.5 は複数の異なるクラスの Operator を使用してクラスター操作を実行し、アプリケーションが使用するクラスターでサービスを実行します。
3.1.3.1. OpenShift Container Platform の Platform Operator
OpenShift Container Platform 4.5 では、すべてのクラスター機能は一連の Platform Operator に分類されます。Platform Operator は、クラスター全体でのアプリケーションロギング、Kubernetes コントロールプレーンの管理、またはマシンプロビジョニングシステムなどの、クラスター機能の特定の分野を管理します。
各 Operator は、クラスター機能を判別するための単純な API を提供します。Operator は、コンポーネントのライフサイクルの管理についての詳細を非表示にします。Operator は単一コンポーネントも、数十のコンポーネントも管理できますが、最終目標は常に、共通アクションの自動化によって操作上の負担の軽減することにあります。また、Operator はより粒度の高いエクスペリエンスも提供します。各コンポーネントは、グローバル設定ファイルではなく、Operator が公開する API を変更して設定できます。
3.1.3.2. OLM によって管理される Operator
クラスターの Operator Lifecycle Management (OLM) コンポーネントはアプリケーションで使用できる Operator を管理します。これは OpenShift Container Platform を設定する Operator を管理しません。OLM は、Kubernetes ネイティブアプリケーションを Operator として管理するフレームワークです。これは、Kubernetes マニフェストを管理する代わりに、Kubernetes Operator を管理します。OLM は Red Hat Operator と認定 Operator の 2 つのクラスの Operator を管理します。
一部の Red Hat Operator は、スケジューラーおよび問題検出機能などのクラスター機能を実行します。他の Operator は etcd などのように各自で管理し、アプリケーションで使用できるように提供されます。また OpenShift Container Platform は、コミュニティーが構築し、保守する認定 Operator を提供します。これらの認定 Operator は API 層を従来のアプリケーションに提供し、アプリケーションを Kubernetes コンストラクトで管理できるようにします。
3.1.3.3. OpenShift Container Platform の更新サービスについて
OpenShift Container Platform の更新サービスとは、OpenShift Container Platform と Red Hat Enterprise Linux CoreOS (RHCOS) の両方に OTA(over-the-air) 更新を提供するホスト型サービスです。コンポーネント Operator のグラフ、または 頂点 とそれらを結ぶ 辺 を含む図表が提示されます。グラフの辺は、どのバージョンであれば安全に更新できるかを示します。 頂点は、管理されたクラスターコンポーネントの想定された状態を特定する更新のペイロードです。
クラスター内の Cluster Version Operator (CVO) は、OpenShift Container Platform の更新サービスをチェックして、グラフの現在のコンポーネントバージョンとグラフの情報に基づき、有効な更新および更新パスを確認します。ユーザーが更新をリクエストすると、OpenShift Container Platform CVO はその更新のリリースイメージを使ってクラスターをアップグレードします。リリースアーティファクトは、コンテナーイメージとして Quay でホストされます。
OpenShift Container Platform 更新サービスが互換性のある更新のみを提供できるようにするために、自動化を支援するリリース検証 Pipeline が使用されます。それぞれのリリースアーティファクトについて、他のコンポーネントパッケージだけでなくサポートされているクラウドプラットフォームおよびシステムアーキテクチャーとの互換性の有無が検証されます。Pipeline がリリースの適合性を確認した後に、OpenShift Container Platform 更新サービスは更新が利用可能であることを通知します。
更新サービスが有効な更新をすべて表示するために、更新サービスが表示しないバージョンへの更新を強制することはできません。
連続更新モードでは、2 つのコントローラーが実行されます。1 つのコントローラーはペイロードマニフェストを絶えず更新し、それらをクラスターに適用し、Operator が利用可能か、アップグレード中か、または失敗しているかに応じて Operator の制御されたロールアウトのステータスを出力します。2 つ目のコントローラーは OpenShift Container Platform 更新サービスをポーリングして、更新が利用可能かどうかを判別します。
クラスターを以前のバージョンに戻すこと、つまりロールバックはサポートされていません。サポートされているのは、新規バージョンへのアップグレードのみです。アップグレードできない場合は、Red Hat サポートにお問い合わせください。
アップグレードプロセスで、Machine Config Operator (MCO) は新規設定をクラスターマシンに適用します。これは、マシン設定プールの maxUnavailable フィールドによって指定されるノードの数を分離し、それらを利用不可としてマークします。デフォルトで、この値は 1 に設定されます。次に、新しい設定を適用して、マシンを再起動します。Red Hat Enterprise Linux (RHEL) マシンをワーカーとして使用する場合、まず OpenShift API をそれらのマシンで更新する必要があるため、MCO はそれらのマシンで kubelet を更新しません。新規バージョンの仕様は古い kubelet に適用されるため、RHEL マシンを Ready 状態に戻すことができません。マシンが利用可能になるまで更新を完了することはできません。ただし、利用不可のノードの最大数は、その数のマシンがサービス停止状態のマシンとして分離されても通常のクラスター操作が継続できるようにするために設定されます。
3.1.3.4. Machine Config Operator について
OpenShift Container Platform 4.5 は、オペレーティングシステムとクラスター管理を統合します。クラスターは、クラスターノードでの Red Hat Enterprise Linux CoreOS (RHCOS) への更新を含め、独自の更新を管理するので、OpenShift Container Platform では事前に設定されたライフサイクル管理が実行され、ノードのアップグレードのオーケストレーションが単純化されます。
OpenShift Container Platform は、ノードの管理を単純化するために 3 つのデーモンセットとコントローラーを採用しています。これらのデーモンセットは、Kubernetes 形式のコンストラクトを使用してオペレーティングシステムの更新とホストの設定変更をオーケストレーションします。これには、以下が含まれます。
-
machine-config-controller: コントロールプレーンからマシンのアップグレードを調整します。すべてのクラスターノードを監視し、その設定の更新をオーケストレーションします。 -
machine-config-daemonデーモンセット: クラスターの各ノードで実行され、マシン設定で定義された設定で、MachineConfigController の指示通りにマシンを更新します。 ノードは、変更を検知すると Pod からドレイン (解放) され、更新を適用して再起動します。これらの変更は、指定されたマシン設定を適用し、 kubelet 設定を制御する Ignition 設定ファイルの形式で実行されます。更新自体はコンテナーで行われます。このプロセスは、OpenShift Container Platform と RHCOS の更新を同時に管理する際に不可欠です。 -
machine-config-serverデーモンセット: コントロールプレーンノードがクラスターに参加する際に Ignition 設定ファイルをコントロールプレーンノードに提供します。
このマシン設定は Ignition 設定のサブセットです。machine-config-daemon はマシン設定を読み取り、OSTree の更新を行う必要があるか、または一連の systemd kubelet ファイルの変更、設定の変更、オペレーティングシステムまたは OpenShift Container Platform 設定などへのその他の変更を適用する必要があるかを確認します。
ノード管理操作の実行時に、KubeletConfig カスタムリソース (CR) を作成または変更します。
マシン設定への変更が行われると、Machine Config Operator は変更を有効にするために、対応するすべてのノードを自動的に再起動します。
マシン設定の変更後、変更が適用される前にノードが自動的に起動されないようにするには、対応するマシンプール設定で spec.paused フィールドを true に設定して自動再起動プロセスを一時停止する必要があります。一時停止すると、spec.paused フィールドを false に設定し、ノードが新しい設定で再起動されるまで、マシン設定の変更は適用されません。
追加情報
Machine Config Operator によるマシン設定の変更後にコントロールプレーンマシンが自動的に起動されないようにする方法については、Disabling Machine Config Operator from automatically rebooting を参照してください。
