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 が正しくレポートすることを確認するには、KCS 5277891 を参照してください。

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

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

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

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