第1章 ホストされたコントロールプレーンの概要
OpenShift Container Platform クラスターは、スタンドアロンまたはホストされたコントロールプレーンという 2 つの異なるコントロールプレーン設定を使用してデプロイできます。スタンドアロン設定では、専用の仮想マシンまたは物理マシンを使用してコントロールプレーンをホストします。OpenShift Container Platform のホステッドコントロールプレーンを使用すると、コントロールプレーンごとに専用の仮想または物理マシンを必要とせずに、ホスティングクラスター上にコントロールプレーンを Pod として作成できます。
1.1. ホストされたコントロールプレーンの概要 (テクノロジープレビュー)
Red Hat OpenShift Container Platform のホストされたコントロールプレーンを、管理コストの削減、クラスターのデプロイ時間の最適化、管理とワークロードの問題の分離に使用することで、アプリケーションに集中できます。
ホストされたコントロールプレーンをテクノロジープレビュー機能として有効にするには、Amazon Web Services (AWS) 上の Kubernetes Operator バージョン 2.0 以降のマルチクラスターエンジン、エージェントプロバイダーを使用したベアメタル、または OpenShift Virtualization を使用します。
ホストされたコントロールプレーンは、テクノロジープレビュー機能としてのみ利用できます。テクノロジープレビュー機能は、Red Hat 製品サポートのサービスレベルアグリーメント (SLA) の対象外であり、機能的に完全ではない場合があります。Red Hat は実稼働環境でこれらを使用することを推奨していません。テクノロジープレビュー機能では、最新の製品機能をいち早く提供します。これにより、お客様は開発段階で機能をテストし、フィードバックを提供できます。
Red Hat のテクノロジープレビュー機能のサポート範囲に関する詳細は、テクノロジープレビュー機能のサポート範囲 を参照してください。
1.1.1. ホストされたコントロールプレーンのアーキテクチャー
OpenShift Container Platform は、多くの場合、クラスターがコントロールプレーンとデータプレーンで設定される結合モデルまたはスタンドアロンモデルでデプロイされます。コントロールプレーンには、API エンドポイント、ストレージエンドポイント、ワークロードスケジューラー、および状態を保証するアクチュエーターが含まれます。データプレーンには、ワークロードとアプリケーションが実行されるコンピューティング、ストレージ、ネットワークが含まれます。
スタンドアロンコントロールプレーンは、クォーラムを確保できる最小限の数で、物理または仮想のノードの専用グループによってホストされます。ネットワークスタックは共有されます。クラスターへの管理者アクセスにより、クラスターのコントロールプレーン、マシン管理 API、およびクラスターの状態に影響を与える他のコンポーネントを可視化できます。
スタンドアロンモデルは正常に機能しますが、状況によっては、コントロールプレーンとデータプレーンが分離されたアーキテクチャーが必要になります。そのような場合には、データプレーンは、専用の物理ホスティング環境がある別のネットワークドメインに配置されています。コントロールプレーンは、Kubernetes にネイティブなデプロイやステートフルセットなど、高レベルのプリミティブを使用してホストされます。コントロールプレーンは、他のワークロードと同様に扱われます。
1.1.2. ホストされたコントロールプレーンの利点
OpenShift Container Platform のホストされたコントロールプレーンを使用すると、真のハイブリッドクラウドアプローチへの道が開かれ、その他にもいくつかの利点を享受できます。
- コントロールプレーンが分離され、専用のホスティングサービスクラスターでホストされるため、管理とワークロードの間のセキュリティー境界が強化されます。その結果、クラスターのクレデンシャルが他のユーザーに漏洩する可能性が低くなります。インフラストラクチャーのシークレットアカウント管理も分離されているため、クラスターインフラストラクチャーの管理者が誤ってコントロールプレーンインフラストラクチャーを削除することはありません。
- ホストされたコントロールプレーンを使用すると、より少ないノードで多くのコントロールプレーンを実行できます。その結果、クラスターはより安価になります。
- コントロールプレーンは OpenShift Container Platform で起動される Pod で設定されるため、コントロールプレーンはすぐに起動します。同じ原則が、モニタリング、ロギング、自動スケーリングなどのコントロールプレーンとワークロードに適用されます。
- インフラストラクチャーの観点からは、レジストリー、HAProxy、クラスター監視、ストレージノードなどのインフラストラクチャーをテナントのクラウドプロバイダーのアカウントにプッシュして、テナントでの使用を分離できます。
- 運用上の観点からは、マルチクラスター管理はさらに集約され、クラスターの状態と一貫性に影響を与える外部要因が少なくなります。Site Reliability Engineer は、一箇所で問題をデバッグして、クラスターのデータプレインを移動するため、解決までの時間 (TTR) が短縮され、生産性が向上します。