3.4. ノードセレクターを使用したモニタリングコンポーネントの移動
ラベル付きノードで nodeSelector
制約を使用すると、任意のモニタリングスタックコンポーネントを特定ノードに移動できます。これにより、クラスター全体のモニタリングコンポーネントの配置と分散を制御できます。
モニタリングコンポーネントの配置と分散を制御することで、システムリソースの使用を最適化し、パフォーマンスを高め、特定の要件やポリシーに基づいてワークロードを分離できます。
3.4.1. ノードセレクターと他の制約の連携
ノードセレクターの制約を使用してモニタリングコンポーネントを移動する場合、クラスターに Pod のスケジューリングを制御するための他の制約があることに注意してください。
- Pod の配置を制御するために、トポロジー分散制約が設定されている可能性があります。
- Prometheus、Thanos Querier、Alertmanager、およびその他のモニタリングコンポーネントでは、コンポーネントの複数の Pod が必ず異なるノードに分散されて高可用性が常に確保されるように、ハードな非アフィニティールールが設定されています。
ノード上で Pod をスケジュールする場合、Pod スケジューラーは既存の制約をすべて満たすように Pod の配置を決定します。つまり、Pod スケジューラーがどの Pod をどのノードに配置するかを決定する際に、すべての制約が組み合わされます。
そのため、ノードセレクター制約を設定しても既存の制約をすべて満たすことができない場合、Pod スケジューラーはすべての制約をマッチさせることができず、ノードへの Pod 配置をスケジュールしません。
モニタリングコンポーネントの耐障害性と高可用性を維持するには、コンポーネントを移動するノードセレクター制約を設定する際に、十分な数のノードが利用可能で、すべての制約がマッチすることを確認してください。
3.4.2. モニタリングコンポーネントの異なるノードへの移動
ユーザー定義プロジェクトのワークロードをモニターする任意のコンポーネントを特定のワーカーノードに移動できます。コンポーネントをコントロールプレーンまたはインフラストラクチャーノードに移動することは許可されていません。
前提条件
-
dedicated-admin
ロールを持つユーザーとしてクラスターにアクセスできる。 -
user-workload-monitoring-config
ConfigMap
オブジェクトが存在します。このオブジェクトは、クラスターの作成時にデフォルトで作成されます。 -
OpenShift CLI (
oc
) がインストールされている。
手順
まだの場合は、モニタリングコンポーネントを実行するノードにラベルを追加します。
$ oc label nodes <node-name> <node-label>
ConfigMap
オブジェクトを編集します。openshift-user-workload-monitoring
プロジェクトでuser-workload-monitoring-config
ConfigMap
オブジェクトを編集します。$ oc -n openshift-user-workload-monitoring edit configmap user-workload-monitoring-config
data/config.yaml
でコンポーネントのnodeSelector
制約のノードラベルを指定します。apiVersion: v1 kind: ConfigMap metadata: name: user-workload-monitoring-config namespace: openshift-user-workload-monitoring data: config.yaml: | <component>: 1 nodeSelector: <node-label-1> 2 <node-label-2> 3 <...>
注記nodeSelector
の制約を設定した後もモニタリングコンポーネントがPending
状態のままになっている場合は、Pod イベントで taint および toleration に関連するエラーの有無を確認します。
- 変更を適用するためにファイルを保存します。新しい設定で指定されたコンポーネントは自動的に新しいノードに移動され、新しい設定の影響を受ける Pod は再デプロイされます。
関連情報
-
nodeSelector
制約の詳細は、Kubernetes ドキュメント を参照してください。