OpenShift 4 のインフラストラクチャーノード

Issue

インフラストラクチャーノードを使用すると、お客様は以下の 2 つの主要目的で、インフラストラクチャーワークロードを分離することができます。

1. サブスクリプションカウントに対する請求コストの負担を防ぐ目的。
2. メンテナンスと管理を分離させる目的。

このソリューションは、OpenShift 4 でのインフラストラクチャーノードの作成に関する 公式ドキュメント を補完するものです。 さらに、このプロセス全体を説明している OpenShift Commons の優れた動画があります。OpenShift Commons: Everything about Infra nodes

インフラストラクチャーノードは、デフォルトルーター、統合コンテナーイメージレジストリー、クラスターメトリクスおよびモニタリング用のコンポーネントなど、インフラストラクチャーコンポーネントのみをホストします。これらのインフラストラクチャーマシンは、環境の実行に必要なサブスクリプションの合計数にカウントされません。

最初の問題を解決するために必要なのは、特定のノード、ノードのセット、またはマシンおよび MachineSet にノードラベルを追加することだけです。 Red Hat サブスクリプションの仮想 CPU カウントでは、node-role.kubernetes.io/infra: "" というラベルの付いたノードによって報告された仮想 CPU が省略され、Red Hat がこれらのリソースの料金を請求することはありません。 この記事の設定変更を適用した後、仮想 CPU のレポートが正しいことを確認するために、How to confirm infra nodes not included in subscription cost in OpenShift Cluster Manager? を参照してください。

2 つ目の問題を解決するには、インフラストラクチャーワークロードをインフラストラクチャーノードに特化してスケジュールし、他のワークロードがインフラストラクチャーノードでスケジュールされないようにする必要があります。 これを達成するためのストラテジーが 2 つありますが、これについては後で説明します。

インフラストラクチャーのワークロードが、コントロールプレーンで実行されているワークロードと異なる理由について説明します。 OpenShift クラスターには、3 つのコントロールプレーンノードに加え、2 つのワーカーノードが含まれます。クラスターの操作性に不可欠なコントロールプレーンコンポーネントはマスター上で分離されていますが、ワーカーノード (クラスターユーザーがアプリケーションをデプロイするのと同じノード) でデフォルトで実行されるインフラストラクチャーワークロードが依然としていくつかあります。

注記: インフラストラクチャーノードで実行できるワークロードを確認するには、OpenShift sizing and subscription guide for enterprise Kubernetes の「Red Hat OpenShift control plane and infrastructure nodes」セクションを参照してください。

これらのインフラストラクチャーコンポーネントをホストするノードに関して、ノードの変更を計画する場合は、簡単に対処するべきではなく、一般に、通常のアプリケーションワークロードに特化して実行しているノードとは別に対処する必要があります。