第4章 モニタリングのための Pod トポロジー分散制約の設定
Pod トポロジー分散制約を使用して、OpenShift Container Platform Pod が複数のアベイラビリティーゾーンにデプロイされている場合に、Prometheus、Thanos Ruler、および Alertmanager Pod がネットワークトポロジー全体にどのように分散されるかを制御できます。
Pod トポロジーの分散制約は、ノードがリージョンやリージョン内のゾーンなど、さまざまなインフラストラクチャーレベルに分散している階層トポロジー内で Pod のスケジューリングを制御するのに適しています。さらに、さまざまなゾーンで Pod をスケジュールできるため、特定のシナリオでネットワーク遅延を改善できます。
4.1. Prometheus の Pod トポロジー分散制約の設定
コア OpenShift Container Platform プラットフォームのモニタリングでは、Prometheus の Pod トポロジー分散制約を設定して、Pod レプリカがゾーン間でノードにスケジュールされる方法を微調整できます。そうすることで、Prometheus Pod の可用性が高くなり、より効率的に実行されるようになります。これは、ワークロードが異なるデータセンターまたは階層インフラストラクチャーゾーンのノードに分散されるためです。
cluster-monitoring-config
config map で、Prometheus の Pod トポロジー分散制約を設定します。
前提条件
-
OpenShift CLI (
oc
) がインストールされている。 -
cluster-admin
クラスターロールを持つユーザーとしてクラスターにアクセスできます。 -
cluster-monitoring-config
ConfigMap
オブジェクトを作成している。
手順
openshift-monitoring
namespace でcluster-monitoring-config
ConfigMap
オブジェクトを編集します。$ oc -n openshift-monitoring edit configmap cluster-monitoring-config
data/config.yaml/prometheusK8s
の下に次の設定の値を追加して、Pod トポロジー分散制約を設定します。apiVersion: v1 kind: ConfigMap metadata: name: cluster-monitoring-config namespace: openshift-monitoring data: config.yaml: | prometheusK8s: topologySpreadConstraints: - maxSkew: 1 1 topologyKey: monitoring 2 whenUnsatisfiable: DoNotSchedule 3 labelSelector: matchLabels: 4 app.kubernetes.io/name: prometheus
- 1
maxSkew
の数値を指定します。これは、どの程度まで Pod が不均等に分散されることを許可するか定義します。このフィールドは必須で、値はゼロより大きい必要があります。指定された値は、whenUnsatisfiable
に指定した値に応じて異なる効果を持ちます。- 2
topologyKey
にノードラベルのキーを指定します。このフィールドは必須です。このキーと同じ値のラベルを持つノードは、同じトポロジーにあると見なされます。スケジューラーは、バランスのとれた数の Pod を各ドメインに配置しようとします。- 3
whenUnsatisfiable
の値を指定します。このフィールドは必須です。利用可能なオプションはDoNotSchedule
とScheduleAnyway
です。maxSkew
値で、ターゲットトポロジー内の一致する Pod の数とグローバル最小値との間で許容される最大差を定義する場合は、DoNotSchedule
を指定します。スケジューラーが引き続き Pod をスケジュールするが、スキューを減らす可能性のあるノードにより高い優先度を与える場合は、ScheduleAnyway
を指定します。- 4
matchLabels
の値を指定します。この値は、制約の適用対象となる一致する Pod のセットを識別するために使用されます。
ファイルを保存して、変更を自動的に適用します。
警告cluster-monitoring-config
config map への変更を保存すると、openshift-monitoring
プロジェクトの Pod およびその他のリソースが再デプロイされる場合があります。そのプロジェクトで実行中のモニタリングプロセスも再起動する場合があります。