6.2. OpenShift Container Platform のマシンのロール
OpenShift Container Platform はホストに複数の異なるロールを割り当てます。これらのロールは、クラスター内のマシンの機能を定義します。クラスターには、標準の master および worker のロールタイプの定義が含まれます。
また、クラスターには bootstrap ロールの定義も含まれます。ブートストラップマシンが使用されるのはクラスターのインストール時のみであり、この機能は、クラスターインストールのドキュメントで説明されています。
6.2.1. コントロールプレーンとノードホストの互換性
OpenShift Container Platform のバージョンは、コントロールプレーンホストとノードホストの間で一致する必要があります。たとえば 4.16 クラスターでは、すべてのコントロールプレーンホストが 4.16、すべてのノードが 4.16 でなければなりません。
クラスターのアップグレード中の一時的な不一致は許容されます。たとえば、以前の OpenShift Container Platform バージョンから 4.16 にアップグレードする場合、一部のノードは他のノードよりも先に 4.16 にアップグレードされます。コントロールプレーンホストとノードホストのスキューが長引くと、古いコンピューティングマシンがバグや不足している機能にさらされる可能性があります。ユーザーは、スキューされたコントロールプレーンホストとノードホストをできるだけ早く解決する必要があります。
kubelet サービスは kube-apiserver よりも新しいものであってはならず、OpenShift Container Platform のバージョンが奇数か偶数かに応じて、最大 2 つのマイナーバージョンになる可能性があります。次の表は、適切なバージョンの互換性を示しています。
| OpenShift Container Platform バージョン | サポートされている kubelet スキュー |
|---|---|
| 奇数の OpenShift Container Platform マイナーバージョン [1] | 1 つ前のバージョンまで |
| 偶数の OpenShift Container Platform のマイナーバージョン [2] | 2 つ前のバージョンまで |
- たとえば、OpenShift Container Platform 4.11､4.13 です。
- たとえば、OpenShift Container Platform 4.10､4.12 です。
6.2.2. クラスターのワーカー
Kubernetes のクラスターでは、ワーカーノードは Kubernetes ユーザーによってリクエストされた実際のワークロードを実行し、管理します。ワーカーノードは容量をアドバタイズし、コントロールプレーンサービスであるスケジューラーは Pod とコンテナーを開始するノードを決定します。以下の重要なサービスは、各ワーカーノードで実行されます。
- コンテナーエンジンである CRI-O。
- コンテナーワークロードの実行と停止の要求を受け入れて停止するサービスである kubelet。
- ワーカー全体で Pod の通信を管理するサービスプロキシー。
- コンテナーを作成して実行する、runC または crun の低レベルコンテナーランタイム。
デフォルトの runC の代わりに crun を有効にする方法は、ContainerRuntimeConfig CR の作成に関するドキュメントを参照してください。
OpenShift Container Platform では、コンピューティングマシンセットは、worker マシンロールが割り当てられたコンピューティングマシンを制御します。worker のロールを持つマシンは、自動スケーリングを行う特定のマシンプールによって制御されるコンピュートワークロードを実行します。OpenShift Container Platform には複数のマシンタイプをサポートする能力があるため、worker ロールを持つマシンは コンピュート マシンとして分類されます。本リリースでは、コンピュートマシンの唯一のデフォルトタイプはワーカーマシンであるため、本リリースでは ワーカーマシン と コンピュートマシン は相互に置き換え可能な用語として使用されています。OpenShift Container Platform の今後のバージョンでは、インフラストラクチャーマシンなどの異なる種類のコンピュートマシンがデフォルトで使用される可能性があります。
コンピューティングマシンセットは、machine-api namespace にあるコンピューティングマシンリソースのグループです。コンピューティングマシンセットは、特定のクラウドプロバイダーで新しいコンピューティングマシンを起動するように設計された設定です。machine config pool (MCP) は Machine Config Operator (MCO) namespace の一部です。MCP は、MCO がそれらの設定を管理し、それらのアップグレードを容易に実行できるようにマシンをまとめるために使用されます。
6.2.3. クラスターコントロールプレーン
Kubernetes のクラスターでは、master ノードは Kubernetes クラスターの制御に必要なサービスを実行します。OpenShift Container Platform では、コントロールプレーンは、master マシンのロールを持つコントロールプレーンマシンで構成されます。これには、OpenShift Container Platform のクラスターを管理する Kubernetes サービス以外も含まれます。
ほとんどの OpenShift Container Platform クラスターでは、コントロールプレーンマシンは一連のスタンドアロンマシン API リソースによって定義されます。サポートされているクラウドプロバイダーと OpenShift Container Platform バージョンの組み合わせの場合、コントロールプレーンはコントロールプレーンマシンセットで管理できます。すべてのコントロールプレーンマシンが削除されてクラスターが切断されないようにするために、追加の制御がコントロールプレーンマシンに適用されます。
3 つのコントロールプレーンノードのみが、すべての実稼働デプロイメントで使用される必要があります。
コントロールプレーン上の Kubernetes カテゴリーに分類されるサービスには、Kubernetes API サーバー、etcd、Kubernetes コントローラーマネージャー、Kubernetes スケジューラーが含まれます。
| コンポーネント | 説明 |
|---|---|
| Kubernetes API サーバー | Kubernetes API サーバーは Pod、サービスおよびレプリケーションコントローラーのデータを検証し、設定します。また、クラスターの共有される状態を確認できる中心的な部分として機能します。 |
| etcd | etcd はコントロールプレーンの永続的な状態を保存し、他のコンポーネントは etcd で変更の有無を監視して、それぞれを指定された状態に切り替えます。 |
| Kubernetes コントローラーマネージャー | Kubernetes コントローラーマネージャーは etcd でレプリケーション、namespace、サービスアカウントコントローラーのオブジェクトなどのオブジェクトへの変更の有無を監視し、API を使用して指定された状態を実行します。このような複数のプロセスは、一度に 1 つのアクティブなリーダーを設定してクラスターを作成します。 |
| Kubernetes スケジューラー | Kubernetes スケジューラーは、割り当て済みのノードなしで新規に作成された Pod の有無を監視し、Pod をホストする最適なノードを選択します。 |
また、コントロールプレーンで実行される OpenShift サービス (OpenShift API サーバー、OpenShift コントローラーマネージャー、OpenShift OAuth API サーバー、および OpenShift OAuth サーバー) もあります。
| コンポーネント | 説明 |
|---|---|
| OpenShift API サーバー | OpenShift API サーバーは、プロジェクト、ルート、テンプレートなどの OpenShift リソースのデータを検証し、設定します。 OpenShift API サーバーは OpenShift API Server Operator によって管理されます。 |
| OpenShift コントロールマネージャー | OpenShift コントローラーマネージャーは etcd でプロジェクト、ルート、テンプレートコントローラーオブジェクトなどの OpenShift オブジェクトへの変更の有無を監視し、API を使用して指定された状態を適用します。 OpenShift コントローラーマネージャーは OpenShift Controller Manager Operator によって管理されます。 |
| OpenShift OAuth API サーバー | OpenShift OAuth API サーバーは、ユーザー、グループ、OAuth トークンなどの OpenShift Container Platform に対して認証を行うようにデータを検証し、設定します。 OpenShift OAuth API サーバーは Cluster Authentication Operator によって管理されます。 |
| OpenShift OAuth サーバー | ユーザーは OpenShift OAuth サーバーからトークンを要求し、API に対して認証します。 OpenShift OAuth サーバーは Cluster Authentication Operator によって管理されます。 |
コントロールプレーンマシン上のこれらサービスの一部は systemd サービスとして実行し、それ以外は静的な Pod として実行されます。
systemd サービスは、起動直後の特定のシステムで常に起動している必要のあるサービスに適しています。コントロールプレーンマシンの場合は、リモートログインを可能にする sshd も含まれます。また、以下のようなサービスも含まれます。
- CRI-O コンテナーエンジン (crio): コンテナーを実行し、管理します。OpenShift Container Platform 4.16 は、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
