5.2. OpenShift Container Platform のマシンのロール
OpenShift Container Platform はホストに複数の異なるロールを割り当てます。これらのロールは、クラスター内のマシンの機能を定義します。クラスターには、標準のマスターおよびワーカーのロールタイプの定義が含まれます。
また、クラスターにはブートストラップロールの定義も含まれます。ブートストラップマシンが使用されるのはクラスターのインストール時のみであり、この機能については、クラスターインストールのドキュメントで説明されています。
5.2.1. コントロールプレーンとノードホストの互換性
OpenShift Container Platform のバージョンは、コントロールプレーンホストとノードホストの間で一致する必要があります。たとえば、4.9 クラスターでは、すべてのコントロールプレーンホストが 4.9 であり、すべてのノードが 4.9 である必要があります。
クラスターのアップグレード中の一時的な不一致は許容されます。たとえば、OpenShift Container Platform 4.8 から 4.9 にアップグレードする場合は、一部のノードが先に 4.9 にアップグレードされます。コントロールプレーンホストとノードホストのスキューが長引くと、古いコンピューティングマシンがバグや不足している機能にさらされる可能性があります。ユーザーは、スキューされたコントロールプレーンホストとノードホストをできるだけ早く解決する必要があります。
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.5、4.7、4.9 です。
- たとえば、OpenShift Container Platform 4.6、4.8、4.10 です。
5.2.2. クラスターのワーカー
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 がそれらの設定を管理し、それらのアップグレードを容易に実行できるようにマシンをまとめるために使用されます。
5.2.3. クラスターのマスター
Kubernetes のクラスターでは、コントロールプレーンノードは Kubernetes クラスターの制御に必要なサービスを実行します。OpenShift Container Platform では、コントロールプレーンマシンはコントロールプレーンです。これには、OpenShift Container Platform のクラスターを管理する Kubernetes サービス以外も含まれます。コントロールプレーンのロールを持つすべてのマシンがコントロールプレーンマシンであるため、 マスター と コントロールプレーン はこれらを説明する際の相互に置き換え可能な用語として使用されています。コントロールプレーンマシンは、マシンセットにグループ化されるのではなく、一連のスタンドアロンマシン API リソースによって定義されます。 すべてのコントロールプレーンマシンが削除されてクラスターが切断されないようにするために、追加の制御がコントロールプレーンマシンに適用されます。
3 つのコントロールプレーンノードのみが、すべての実稼働デプロイメントで使用される必要があります。
マスター上の Kubernetes カテゴリーに分類されるサービスには、Kubernetes API サーバー、etcd、Kubernetes コントローラーマネージャー、Kubernetes スケジューラーが含まれます。
コンポーネント | 説明 |
---|---|
Kubernetes API サーバー | Kubernetes API サーバーは Pod、サービスおよびレプリケーションコントローラーのデータを検証し、設定します。また、クラスターの共有される状態を確認できる中心的な部分として機能します。 |
etcd | etcd はマスターの永続的な状態を保存し、他のコンポーネントは etcd で変更の有無を監視して、それぞれを指定された状態に切り替えます。 |
Kubernetes controller manager | Kubernetes コントローラーマネージャーは etcd でレプリケーション、namespace、サービスアカウントコントローラーのオブジェクトなどのオブジェクトへの変更の有無を監視し、API を使用して指定された状態を実行します。このような複数のプロセスは、一度に 1 つのアクティブなリーダーを設定してクラスターを作成します。 |
Kubernetes スケジューラー | Kubernetes スケジューラーは、割り当て済みのノードなしで新規に作成された Pod の有無を監視し、Pod をホストする最適なノードを選択します。 |
また、コントロールプレーンで実行される OpenShift サービス (OpenShift API サーバー、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.9 は、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