Skip to content

Commit 6801b91

Browse files
bburt-rhbburt-rh
authored
Merge pull request #52118 from bburt-rh/RHDEVDOCS-4249-cmo-config-for-topologyspreadconstraints
RHDEVDOCS-4249 - CMO config settings for topology spread constraints
2 parents e230cfa + 740b26d commit 6801b91

5 files changed

+233
-0
lines changed

‎modules/monitoring-configuring-pod-topology-spread-constraints-for-monitoring.adoc

Lines changed: 12 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,12 @@
1+
// Module included in the following assemblies:
2+
//
3+
// * monitoring/configuring-the-monitoring-stack.adoc
4+
5+
:_content-type: CONCEPT
6+
[id="configuring_pod_topology_spread_constraintsfor_monitoring_{context}"]
7+
= Configuring pod topology spread constraints for monitoring
8+
9+
You can use pod topology spread constraints to control how Prometheus, Thanos Ruler, and Alertmanager pods are spread across a network topology when {product-title} pods are deployed in multiple availability zones.
10+
11+
Pod topology spread constraints are suitable for controlling pod scheduling within hierarchical topologies in which nodes are spread across different infrastructure levels, such as regions and zones within those regions.
12+
Additionally, by being able to schedule pods in different zones, you can improve network latency in certain scenarios.

‎modules/monitoring-setting-up-pod-topology-spread-constraints-for-alertmanager.adoc

Lines changed: 69 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,69 @@
1+
// Module included in the following assemblies:
2+
//
3+
// * monitoring/configuring-the-monitoring-stack.adoc
4+
5+
:_content-type: PROCEDURE
6+
[id="setting-up-pod-topology-spread-constraints-for-alertmanager_{context}"]
7+
= Setting up pod topology spread constraints for Alertmanager
8+
9+
For core {product-title} platform monitoring, you can set up pod topology spread constraints for Alertmanager to fine tune how pod replicas are scheduled to nodes across zones.
10+
Doing so helps ensure that Alertmanager pods are highly available and run more efficiently, because workloads are spread across nodes in different data centers or hierarchical infrastructure zones.
11+
12+
You configure pod topology spread constraints for Alertmanager in the `cluster-monitoring-config` config map.
13+
14+
.Prerequisites
15+
16+
* You have installed the OpenShift CLI (`oc`).
17+
* You have access to the cluster as a user with the `cluster-admin` role.
18+
* You have created the `cluster-monitoring-config` `ConfigMap` object.
19+
20+
.Procedure
21+
22+
. Edit the `cluster-monitoring-config` `ConfigMap` object in the `openshift-monitoring` namespace:
23+
+
24+
[source,terminal]
25+
----
26+
$ oc -n openshift-monitoring edit configmap cluster-monitoring-config
27+
----
28+
29+
. Add values for the following settings under `data/config.yaml/alertmanagermain` to configure pod topology spread constraints:
30+
+
31+
[source,yaml]
32+
----
33+
apiVersion: v1
34+
kind: ConfigMap
35+
metadata:
36+
name: cluster-monitoring-config
37+
namespace: openshift-monitoring
38+
data:
39+
config.yaml: |
40+
alertmanagerMain:
41+
topologySpreadConstraints:
42+
- maxSkew: 1 <1>
43+
topologyKey: monitoring <2>
44+
whenUnsatisfiable: DoNotSchedule <3>
45+
labelSelector:
46+
matchLabels: <4>
47+
app.kubernetes.io/name: alertmanager
48+
----
49+
<1> Specify a numeric value for `maxSkew`, which defines the degree to which pods are allowed to be unevenly distributed.
50+
This field is required, and the value must be greater than zero.
51+
The value specified has a different effect depending on what value you specify for `whenUnsatisfiable`.
52+
<2> Specify a key of node labels for `topologyKey`.
53+
This field is required.
54+
Nodes that have a label with this key and identical values are considered to be in the same topology.
55+
The scheduler will try to put a balanced number of pods into each domain.
56+
<3> Specify a value for `whenUnsatisfiable`.
57+
This field is required.
58+
Available options are `DoNotSchedule` and `ScheduleAnyway`.
59+
Specify `DoNotSchedule` if you want the `maxSkew` value to define the maximum difference allowed between the number of matching pods in the target topology and the global minimum.
60+
Specify `ScheduleAnyway` if you want the scheduler to still schedule the pod but to give higher priority to nodes that might reduce the skew.
61+
<4> Specify a value for `matchLabels`. This value is used to identify the set of matching pods to which to apply the constraints.
62+
63+
. Save the file to apply the changes automatically.
64+
+
65+
[WARNING]
66+
====
67+
When you save changes to the `cluster-monitoring-config` config map, the pods and other resources in the `openshift-monitoring` project might be redeployed.
68+
The running monitoring processes in that project might also restart.
69+
====

‎modules/monitoring-setting-up-pod-topology-spread-constraints-for-prometheus.adoc

Lines changed: 69 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,69 @@
1+
// Module included in the following assemblies:
2+
//
3+
// * monitoring/configuring-the-monitoring-stack.adoc
4+
5+
:_content-type: PROCEDURE
6+
[id="setting-up-pod-topology-spread-constraints-for-prometheus_{context}"]
7+
= Setting up pod topology spread constraints for Prometheus
8+
9+
For core {product-title} platform monitoring, you can set up pod topology spread constraints for Prometheus to fine tune how pod replicas are scheduled to nodes across zones.
10+
Doing so helps ensure that Prometheus pods are highly available and run more efficiently, because workloads are spread across nodes in different data centers or hierarchical infrastructure zones.
11+
12+
You configure pod topology spread constraints for Prometheus in the `cluster-monitoring-config` config map.
13+
14+
.Prerequisites
15+
16+
* You have installed the OpenShift CLI (`oc`).
17+
* You have access to the cluster as a user with the `cluster-admin` role.
18+
* You have created the `cluster-monitoring-config` `ConfigMap` object.
19+
20+
.Procedure
21+
22+
. Edit the `cluster-monitoring-config` `ConfigMap` object in the `openshift-monitoring` namespace:
23+
+
24+
[source,terminal]
25+
----
26+
$ oc -n openshift-monitoring edit configmap cluster-monitoring-config
27+
----
28+
29+
. Add values for the following settings under `data/config.yaml/prometheusK8s` to configure pod topology spread constraints:
30+
+
31+
[source,yaml]
32+
----
33+
apiVersion: v1
34+
kind: ConfigMap
35+
metadata:
36+
name: cluster-monitoring-config
37+
namespace: openshift-monitoring
38+
data:
39+
config.yaml: |
40+
prometheusK8s:
41+
topologySpreadConstraints:
42+
- maxSkew: 1 <1>
43+
topologyKey: monitoring <2>
44+
whenUnsatisfiable: DoNotSchedule <3>
45+
labelSelector:
46+
matchLabels: <4>
47+
app.kubernetes.io/name: prometheus
48+
----
49+
<1> Specify a numeric value for `maxSkew`, which defines the degree to which pods are allowed to be unevenly distributed.
50+
This field is required, and the value must be greater than zero.
51+
The value specified has a different effect depending on what value you specify for `whenUnsatisfiable`.
52+
<2> Specify a key of node labels for `topologyKey`.
53+
This field is required.
54+
Nodes that have a label with this key and identical values are considered to be in the same topology.
55+
The scheduler will try to put a balanced number of pods into each domain.
56+
<3> Specify a value for `whenUnsatisfiable`.
57+
This field is required.
58+
Available options are `DoNotSchedule` and `ScheduleAnyway`.
59+
Specify `DoNotSchedule` if you want the `maxSkew` value to define the maximum difference allowed between the number of matching pods in the target topology and the global minimum.
60+
Specify `ScheduleAnyway` if you want the scheduler to still schedule the pod but to give higher priority to nodes that might reduce the skew.
61+
<4> Specify a value for `matchLabels`. This value is used to identify the set of matching pods to which to apply the constraints.
62+
63+
. Save the file to apply the changes automatically.
64+
+
65+
[WARNING]
66+
====
67+
When you save changes to the `cluster-monitoring-config` config map, the pods and other resources in the `openshift-monitoring` project might be redeployed.
68+
The running monitoring processes in that project might also restart.
69+
====

‎modules/monitoring-setting-up-pod-topology-spread-constraints-for-thanos-ruler.adoc

Lines changed: 70 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,70 @@
1+
// Module included in the following assemblies:
2+
//
3+
// * monitoring/configuring-the-monitoring-stack.adoc
4+
5+
:_content-type: PROCEDURE
6+
[id="setting-up-pod-topology-spread-constraints-for-thanos-ruler_{context}"]
7+
= Setting up pod topology spread constraints for Thanos Ruler
8+
9+
For user-defined monitoring, you can set up pod topology spread constraints for Thanos Ruler to fine tune how pod replicas are scheduled to nodes across zones.
10+
Doing so helps ensure that Thanos Ruler pods are highly available and run more efficiently, because workloads are spread across nodes in different data centers or hierarchical infrastructure zones.
11+
12+
You configure pod topology spread constraints for Thanos Ruler in the `user-workload-monitoring-config` config map.
13+
14+
.Prerequisites
15+
16+
* You have installed the OpenShift CLI (`oc`).
17+
* A cluster administrator has enabled monitoring for user-defined projects.
18+
* You have access to the cluster as a user with the `cluster-admin` role, or as a user with the `user-workload-monitoring-config-edit` role in the `openshift-user-workload-monitoring` project.
19+
* You have created the `user-workload-monitoring-config` `ConfigMap` object.
20+
21+
.Procedure
22+
23+
. Edit the `user-workload-monitoring-config` config map in the `openshift-user-workload-monitoring` namespace:
24+
+
25+
[source,terminal]
26+
----
27+
$ oc -n openshift-user-workload-monitoring edit configmap user-workload-monitoring-config
28+
----
29+
30+
. Add values for the following settings under `data/config.yaml/thanosRuler` to configure pod topology spread constraints:
31+
+
32+
[source,yaml]
33+
----
34+
apiVersion: v1
35+
kind: ConfigMap
36+
metadata:
37+
name: user-workload-monitoring-config
38+
namespace: openshift-user-workload-monitoring
39+
data:
40+
config.yaml: |
41+
thanosRuler:
42+
topologySpreadConstraints:
43+
- maxSkew: 1 <1>
44+
topologyKey: monitoring <2>
45+
whenUnsatisfiable: ScheduleAnyway <3>
46+
labelSelector:
47+
matchLabels: <4>
48+
app.kubernetes.io/name: thanos-ruler
49+
----
50+
<1> Specify a numeric value for `maxSkew`, which defines the degree to which pods are allowed to be unevenly distributed.
51+
This field is required, and the value must be greater than zero.
52+
The value specified has a different effect depending on what value you specify for `whenUnsatisfiable`.
53+
<2> Specify a key of node labels for `topologyKey`.
54+
This field is required.
55+
Nodes that have a label with this key and identical values are considered to be in the same topology.
56+
The scheduler will try to put a balanced number of pods into each domain.
57+
<3> Specify a value for `whenUnsatisfiable`.
58+
This field is required.
59+
Available options are `DoNotSchedule` and `ScheduleAnyway`.
60+
Specify `DoNotSchedule` if you want the `maxSkew` value to define the maximum difference allowed between the number of matching pods in the target topology and the global minimum.
61+
Specify `ScheduleAnyway` if you want the scheduler to still schedule the pod but to give higher priority to nodes that might reduce the skew.
62+
<4> Specify a value for `matchLabels`. This value is used to identify the set of matching pods to which to apply the constraints.
63+
64+
. Save the file to apply the changes automatically.
65+
+
66+
[WARNING]
67+
====
68+
When you save changes to the `user-workload-monitoring-config` config map, the pods and other resources in the `openshift-user-workload-monitoring` project might be redeployed.
69+
The running monitoring processes in that project might also restart.
70+
====

‎monitoring/configuring-the-monitoring-stack.adoc

Lines changed: 13 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -139,6 +139,19 @@ include::modules/monitoring-attaching-additional-labels-to-your-time-series-and-
139139
* See xref:../monitoring/configuring-the-monitoring-stack.adoc#preparing-to-configure-the-monitoring-stack[Preparing to configure the monitoring stack] for steps to create monitoring config maps.
140140
* xref:../monitoring/enabling-monitoring-for-user-defined-projects.adoc#enabling-monitoring-for-user-defined-projects[Enabling monitoring for user-defined projects]
141141

142+
// Configuring topology spread constraints for monitoring components
143+
include::modules/monitoring-configuring-pod-topology-spread-constraints-for-monitoring.adoc[leveloffset=1]
144+
145+
[role="_additional-resources"]
146+
.Additional resources
147+
148+
* xref:../nodes/scheduling/nodes-scheduler-pod-topology-spread-constraints.adoc#nodes-scheduler-pod-topology-spread-constraints-about[Controlling pod placement by using pod topology spread constraints]
149+
* link:https://kubernetes.io/docs/concepts/scheduling-eviction/topology-spread-constraints/[Kubernetes Pod Topology Spread Constraints documentation]
150+
151+
include::modules/monitoring-setting-up-pod-topology-spread-constraints-for-prometheus.adoc[leveloffset=2]
152+
include::modules/monitoring-setting-up-pod-topology-spread-constraints-for-alertmanager.adoc[leveloffset=2]
153+
include::modules/monitoring-setting-up-pod-topology-spread-constraints-for-thanos-ruler.adoc[leveloffset=2]
154+
142155
// Setting log levels for monitoring components
143156
include::modules/monitoring-setting-log-levels-for-monitoring-components.adoc[leveloffset=+1]
144157

0 commit comments

Comments
 (0)