4.2. 为用户工作负载监控配置性能和可扩展性
您可以配置监控堆栈来优化集群的性能和扩展。以下文档提供了有关如何分发监控组件的信息,并控制监控堆栈对 CPU 和内存资源的影响。
4.2.1. 控制监控组件的放置和分发
您可以将监控堆栈组件移到特定的节点上:
-
使用带有标记节点的
nodeSelector
约束,将任何监控堆栈组件移到特定的节点上。 - 分配容限以启用将组件移到污点节点。
通过这样做,您可以控制集群中监控组件的放置和分发。
通过控制监控组件的放置和分发,您可以根据特定要求或策略优化系统资源使用、提高性能和单独的工作负载。
其他资源
4.2.1.1. 将监控组件移到其他节点
您可以将监控用户定义的项目的工作负载的任何组件移到特定的 worker 节点。
不允许组件移到控制平面或基础架构节点。
先决条件
-
您可以使用具有
cluster-admin
集群角色或具有openshift-user-workload-monitoring
项目中的user-workload-monitoring-config-edit
角色的用户访问集群。 - 集群管理员为用户定义的项目启用了监控。
-
已安装 OpenShift CLI(
oc
)。
流程
如果您还没有这样做,请在要运行监控组件的节点中添加标签:
$ oc label nodes <node_name> <node_label> 1
- 1
- 将 <
;node_name
> 替换为您要添加标签的节点的名称。将<node_label
> 替换为所需标签的名称。
在
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 事件中与污点和容限相关的错误。- 保存文件以使改变生效。新配置中指定的组件会自动移到新节点上,受新配置影响的 pod 会被重新部署。
其他资源
- 为用户定义的项目启用监控
- 了解如何更新节点上的标签
- 使用节点选择器将 pod 放置到特定节点
- nodeSelector (Kubernetes 文档)
4.2.1.2. 为监控组件分配容忍(tolerations)
您可以为监控用户定义的项目的组件分配容限,以便将其移到污点的 worker 节点。在控制平面或基础架构节点上不允许调度。
先决条件
-
您可以使用具有
cluster-admin
集群角色的用户访问集群,也可以使用在openshift-user-workload-monitoring
项目中具有user-workload-monitoring-config-edit
角色的用户访问集群。 - 集群管理员为用户定义的项目启用了监控。
-
已安装 OpenShift CLI(
oc
)。
流程
编辑
openshift-user-workload-monitoring
项目中的user-workload-monitoring-config
配置映射:$ 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 会自动重新部署。
其他资源
- 为用户定义的项目启用监控
- 使用节点污点控制 pod 放置
- 污点和容限( Kubernetes 文档)
4.2.2. 管理监控组件的 CPU 和内存资源
您可以通过为这些组件的资源限值和请求指定值来确保运行监控组件的容器具有足够的 CPU 和内存资源。
您可以为监控 openshift-user-workload-monitoring
命名空间中的用户定义的项目的监控组件配置这些限制和请求。
4.2.2.1. 指定限制和请求
要配置 CPU 和内存资源,请在 openshift-user-workload-monitoring
命名空间中的 user-workload-monitoring-config
ConfigMap
对象中指定资源限值和请求值。
先决条件
-
您可以使用具有
cluster-admin
集群角色的用户访问集群,也可以使用在openshift-user-workload-monitoring
项目中具有user-workload-monitoring-config-edit
角色的用户访问集群。 -
已安装 OpenShift CLI(
oc
)。
流程
编辑
openshift-user-workload-monitoring
项目中的user-workload-monitoring-config
配置映射:$ oc -n openshift-user-workload-monitoring edit configmap user-workload-monitoring-config
添加值来为您要配置的每个组件定义资源限值和请求。
重要确保为限制设置的值始终高于为请求设置的值。否则,会出现错误,容器将不会运行。
设置资源限值和请求示例
apiVersion: v1 kind: ConfigMap metadata: name: user-workload-monitoring-config namespace: openshift-user-workload-monitoring data: config.yaml: | alertmanager: resources: limits: cpu: 500m memory: 1Gi requests: cpu: 200m memory: 500Mi prometheus: resources: limits: cpu: 500m memory: 3Gi requests: cpu: 200m memory: 500Mi thanosRuler: resources: limits: cpu: 500m memory: 1Gi requests: cpu: 200m memory: 500Mi
- 保存文件以使改变生效。受新配置影响的 Pod 会自动重新部署。
其他资源
- 关于为监控组件指定限制和请求
- Kubernetes 请求和限值文档 (Kubernetes 文档)
4.2.3. 控制用户定义的项目中未绑定指标属性的影响
集群管理员可以使用以下方法控制用户定义的项目中未绑定指标属性的影响:
- 限制用户定义的项目中每个目标提取可接受的示例数量
- 限制提取标签数量、标签名称长度以及标签值长度
- 创建在达到提取示例阈值或无法提取目标时触发的警报
限制提取示例可帮助防止在标签中添加多个未绑定属性导致的问题。开发人员还可以通过限制其为指标定义的未绑定属性数量来防止底层原因。使用绑定到一组有限可能值的属性可减少潜在的键-值对组合数量。
4.2.3.1. 为用户定义的项目设置提取示例和标签限制
您可以限制用户定义的项目中每个目标提取可接受的示例数量。您还可以限制提取标签数量、标签名称长度以及标签值长度。
如果您设置了 sample 或 label limits,则在达到限制后,不会为该目标提取获得进一步的示例数据。
先决条件
-
您可以使用具有
cluster-admin
集群角色的用户访问集群,也可以使用在openshift-user-workload-monitoring
项目中具有user-workload-monitoring-config-edit
角色的用户访问集群。 - 集群管理员为用户定义的项目启用了监控。
-
已安装 OpenShift CLI(
oc
)。
流程
在
openshift-user-workload-monitoring
项目中编辑user-workload-monitoring-config
ConfigMap
对象:$ oc -n openshift-user-workload-monitoring edit configmap user-workload-monitoring-config
在
data/config.yaml
中添加enforcedSampleLimit
配置,以限制用户定义的项目中每个目标提取可接受的示例数量:apiVersion: v1 kind: ConfigMap metadata: name: user-workload-monitoring-config namespace: openshift-user-workload-monitoring data: config.yaml: | prometheus: enforcedSampleLimit: 50000 1
- 1
- 如果指定此参数,则需要一个值。这个
enforceSampleLimit
示例将用户定义的项目中每个目标提取的示例数量限制为 50,000。
将
enforcedLabelLimit
,enforcedLabelNameLengthLimit
, 和enforcedLabelValueLengthLimit
配置添加到data/config.yaml
,以限制刮除的标签数量、标签名称长度以及用户定义的项目中的标签值长度:apiVersion: v1 kind: ConfigMap metadata: name: user-workload-monitoring-config namespace: openshift-user-workload-monitoring data: config.yaml: | prometheus: enforcedLabelLimit: 500 1 enforcedLabelNameLengthLimit: 50 2 enforcedLabelValueLengthLimit: 600 3
- 保存文件以使改变生效。限制会自动应用。
4.2.3.2. 创建提取示例警报
您可以创建在以下情况下通知您的警报:
-
在指定的
for
持续时间内无法提取对象或对象不可用 -
在指定的
for
持续时间内达到或超过提取示例阈值
先决条件
-
您可以使用具有
cluster-admin
集群角色的用户访问集群,也可以使用在openshift-user-workload-monitoring
项目中具有user-workload-monitoring-config-edit
角色的用户访问集群。 - 集群管理员为用户定义的项目启用了监控。
-
您已经使用
enforcedSampleLimit
限制了用户定义的项目中每个目标提取可接受的示例数量。 -
已安装 OpenShift CLI(
oc
)。
流程
创建一个包含警报的 YAML 文件,用于在目标停机以及即将达到强制的示例限制时通知您。本例中的文件名为
monitoring-stack-alerts.yaml
:apiVersion: monitoring.coreos.com/v1 kind: PrometheusRule metadata: labels: prometheus: k8s role: alert-rules name: monitoring-stack-alerts 1 namespace: ns1 2 spec: groups: - name: general.rules rules: - alert: TargetDown 3 annotations: message: '{{ printf "%.4g" $value }}% of the {{ $labels.job }}/{{ $labels.service }} targets in {{ $labels.namespace }} namespace are down.' 4 expr: 100 * (count(up == 0) BY (job, namespace, service) / count(up) BY (job, namespace, service)) > 10 for: 10m 5 labels: severity: warning 6 - alert: ApproachingEnforcedSamplesLimit 7 annotations: message: '{{ $labels.container }} container of the {{ $labels.pod }} pod in the {{ $labels.namespace }} namespace consumes {{ $value | humanizePercentage }} of the samples limit budget.' 8 expr: (scrape_samples_post_metric_relabeling / (scrape_sample_limit > 0)) > 0.9 9 for: 10m 10 labels: severity: warning 11
- 1
- 定义警报规则的名称。
- 2
- 指定要部署警报规则的用户定义的项目。
- 3
- 如果在
for
持续时间内无法提取目标或者目标不可用,则TargetDown
警报将触发。 - 4
TargetDown
警报触发时输出的消息。- 5
- 在这个持续时间内必须满足
TargetDown
警报的条件才会触发该警报。 - 6
- 定义
TargetDown
警报的严重性。 - 7
- 当在指定的
for
持续时间内超过定义的提取示例阈值时,ApproachingEnforcedSamplesLimit
警报将触发。 - 8
- 当
ApproachingEnforcedSamplesLimit
警报触发时输出的消息。 - 9
ApproachingEnforcedSamplesLimit
警报的阈值。在本例中,当最接近的样本数量超过配置的限制的 90% 时,会触发警报。- 10
- 在这个持续时间内必须满足
ApproachingEnforcedSamplesLimit
警报的条件才会触发该警报。 - 11
- 定义
ApproachingEnforcedSamplesLimit
警报的严重性。
将配置应用到用户定义的项目中:
$ oc apply -f monitoring-stack-alerts.yaml
另外,您可以检查目标是否达到配置的限制:
在 web 控制台的 Administrator 视角中,进入 Observe
Targets 并选择您要检查的 Down
状态的端点。如果端点因为超过示例限制失败,则会显示 Scrape failed: sample limit exceeded 信息。
4.2.4. 配置 pod 拓扑分布限制
您可以为用户定义的监控配置 pod 拓扑分布限制,以控制 pod 副本如何在区调度到节点。这样可确保 pod 具有高可用性并更有效地运行,因为工作负载分散在不同的数据中心或分层基础架构区域中。
您可以使用 user-workload-monitoring-config
配置映射为监控 pod 配置 pod 拓扑分布限制。
先决条件
-
您可以使用具有
cluster-admin
集群角色或具有openshift-user-workload-monitoring
项目中的user-workload-monitoring-config-edit
角色的用户访问集群。 - 集群管理员为用户定义的项目启用了监控。
-
已安装 OpenShift CLI(
oc
)。
流程
编辑
openshift-user-workload-monitoring
项目中的user-workload-monitoring-config
配置映射:$ oc -n openshift-user-workload-monitoring edit configmap user-workload-monitoring-config
在
data/config.yaml
字段中添加以下设置来配置 pod 拓扑分布限制:apiVersion: v1 kind: ConfigMap metadata: name: user-workload-monitoring-config namespace: openshift-user-workload-monitoring data: config.yaml: | <component>: 1 topologySpreadConstraints: - maxSkew: <n> 2 topologyKey: <key> 3 whenUnsatisfiable: <value> 4 labelSelector: 5 <match_option>
- 1
- 指定您要为其设置 pod 拓扑分布限制的组件名称。
- 2
- 为
maxSkew
指定数字值,它定义了允许不均匀分布 pod 的程度。 - 3
- 为
topologyKey
指定节点标签键。带有具有此键和相同值标签的节点被视为在同一拓扑中。调度程序会尝试将大量 pod 放置到每个域中。 - 4
- 为
whenUnsatisfiable
指定一个值。可用选项包括DoNotSchedule
和ScheduleAnyway
。如果您希望maxSkew
值定义目标拓扑和全局最小值中匹配 pod 数量之间允许的最大值,则指定DoNotSchedule
。如果您希望调度程序仍然调度 pod,但为可能降低 skew 的节点赋予更高的优先级,请指定ScheduleAnyway
。 - 5
- 指定
labelSelector
来查找匹配的 pod。与此标签选择器匹配的 Pod 被计算,以确定其对应拓扑域中的 pod 数量。
Thanos Ruler 的配置示例
apiVersion: v1 kind: ConfigMap metadata: name: user-workload-monitoring-config namespace: openshift-user-workload-monitoring data: config.yaml: | thanosRuler: topologySpreadConstraints: - maxSkew: 1 topologyKey: monitoring whenUnsatisfiable: ScheduleAnyway labelSelector: matchLabels: app.kubernetes.io/name: thanos-ruler
- 保存文件以使改变生效。受新配置影响的 Pod 会自动重新部署。
其他资源
- 关于用于监控的 pod 拓扑分布限制
- 使用 pod 拓扑分布限制控制 pod 放置
- Pod Topology Spread Constraints (Kubernetes 文档)