3.3.5. ユーザー定義プロジェクトをモニターするコンポーネントへの容認の割り当て
ユーザー定義プロジェクトをモニターするコンポーネントに許容値を割り当てて、汚染されたワーカーノードにプロジェクトを移動できるようにすることができます。コントロールプレーンまたはインフラストラクチャーノードでのスケジューリングは許可されていません。
前提条件
-
dedicated-admin
ロールを持つユーザーとしてクラスターにアクセスできる。 -
user-workload-monitoring-config
ConfigMap
オブジェクトをopenshift-user-workload-monitoring
namespace に作成している。 -
OpenShift CLI (
oc
) がインストールされている。
手順
ConfigMap
オブジェクトを編集します。openshift-user-workload-monitoring
プロジェクトでuser-workload-monitoring-config
ConfigMap
オブジェクトを編集します。$ oc -n openshift-user-workload-monitoring edit configmap user-workload-monitoring-config
コンポーネントの
tolerations
を指定します。apiVersion: v1 kind: ConfigMap metadata: name: user-workload-monitoring-config namespace: openshift-user-workload-monitoring data: config.yaml: | <component>: tolerations: <toleration_specification>
<component>
および<toleration_specification>
を随時置き換えます。たとえば、
oc adm taint nodes node1 key1=value1:NoSchedule
は、キーがkey1
で、値がvalue1
のnode1
にテイントを追加します。これにより、モニタリングコンポーネントがnode1
に Pod をデプロイするのを防ぎます。ただし、そのテイントに対して許容値が設定されている場合を除きます。以下の例では、サンプルのテイントを容認するようにthanosRuler
コンポーネントを設定します。apiVersion: v1 kind: ConfigMap metadata: name: user-workload-monitoring-config namespace: openshift-user-workload-monitoring data: config.yaml: | thanosRuler: tolerations: - key: "key1" operator: "Equal" value: "value1" effect: "NoSchedule"
変更を適用するためにファイルを保存します。新しいコンポーネントの配置設定が自動的に適用されます。
警告変更がモニタリング設定マップに保存されると、関連するプロジェクトの Pod およびその他のリソースが再デプロイされる可能性があります。該当するプロジェクトの実行中のモニタリングプロセスも再起動する可能性があります。
関連情報
- テイントおよび許容値については、OpenShift Container Platform ドキュメント を参照してください。
- テイントおよび許容値については、Kubernetes ドキュメント を参照してください。