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)。

流程

  1. 如果您还没有这样做,请在要运行监控组件的节点中添加标签:

    $ oc label nodes <node_name> <node_label> 1
    1
    将 &lt ;node_name > 替换为您要添加标签的节点的名称。将 <node_label > 替换为所需标签的名称。
  2. openshift-user-workload-monitoring 项目中编辑 user-workload-monitoring-config ConfigMap 对象:

    $ oc -n openshift-user-workload-monitoring edit configmap user-workload-monitoring-config
  3. 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
        # ...
    1
    <component> 替换为适当的监控堆栈组件名称。
    2
    <node_label_ 1> 替换为添加到节点的标签。
    3
    可选:指定附加标签。如果您指定了额外的标签,则组件的 pod 仅调度到包含所有指定标签的节点上。
    注意

    如果在配置 nodeSelector 约束后监控组件仍然处于 Pending 状态,请检查 Pod 事件中与污点和容限相关的错误。

  4. 保存文件以使改变生效。新配置中指定的组件会自动移到新节点上,受新配置影响的 pod 会被重新部署。

4.2.1.2. 为监控组件分配容忍(tolerations)

您可以为监控用户定义的项目的组件分配容限,以便将其移到污点的 worker 节点。在控制平面或基础架构节点上不允许调度。

先决条件

  • 您可以使用具有 cluster-admin 集群角色的用户访问集群,也可以使用在 openshift-user-workload-monitoring 项目中具有 user-workload-monitoring-config-edit 角色的用户访问集群。
  • 集群管理员为用户定义的项目启用了监控。
  • 已安装 OpenShift CLI(oc)。

流程

  1. 编辑 openshift-user-workload-monitoring 项目中的 user-workload-monitoring-config 配置映射:

    $ oc -n openshift-user-workload-monitoring edit configmap user-workload-monitoring-config
  2. 为组件指定 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"
  3. 保存文件以使改变生效。受新配置影响的 Pod 会自动重新部署。

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)。

流程

  1. 编辑 openshift-user-workload-monitoring 项目中的 user-workload-monitoring-config 配置映射:

    $ oc -n openshift-user-workload-monitoring edit configmap user-workload-monitoring-config
  2. 添加值来为您要配置的每个组件定义资源限值和请求。

    重要

    确保为限制设置的值始终高于为请求设置的值。否则,会出现错误,容器将不会运行。

    设置资源限值和请求示例

    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

  3. 保存文件以使改变生效。受新配置影响的 Pod 会自动重新部署。

4.2.3. 控制用户定义的项目中未绑定指标属性的影响

集群管理员可以使用以下方法控制用户定义的项目中未绑定指标属性的影响:

  • 限制用户定义的项目中每个目标提取可接受的示例数量
  • 限制提取标签数量、标签名称长度以及标签值长度
  • 创建在达到提取示例阈值或无法提取目标时触发的警报
注意

限制提取示例可帮助防止在标签中添加多个未绑定属性导致的问题。开发人员还可以通过限制其为指标定义的未绑定属性数量来防止底层原因。使用绑定到一组有限可能值的属性可减少潜在的键-值对组合数量。

4.2.3.1. 为用户定义的项目设置提取示例和标签限制

您可以限制用户定义的项目中每个目标提取可接受的示例数量。您还可以限制提取标签数量、标签名称长度以及标签值长度。

警告

如果您设置了 sample 或 label limits,则在达到限制后,不会为该目标提取获得进一步的示例数据。

先决条件

  • 您可以使用具有 cluster-admin 集群角色的用户访问集群,也可以使用在 openshift-user-workload-monitoring 项目中具有 user-workload-monitoring-config-edit 角色的用户访问集群。
  • 集群管理员为用户定义的项目启用了监控。
  • 已安装 OpenShift CLI(oc)。

流程

  1. openshift-user-workload-monitoring 项目中编辑 user-workload-monitoring-config ConfigMap 对象:

    $ oc -n openshift-user-workload-monitoring edit configmap user-workload-monitoring-config
  2. 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。
  3. 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
    1
    指定每次刮除的最大标签数。默认值为 0,代表没有指定限制。
    2
    指定标签名称字符的最大长度。默认值为 0,代表没有指定限制。
    3
    指定标签值字符的最大长度。默认值为 0,代表没有指定限制。
  4. 保存文件以使改变生效。限制会自动应用。

4.2.3.2. 创建提取示例警报

您可以创建在以下情况下通知您的警报:

  • 在指定的 for 持续时间内无法提取对象或对象不可用
  • 在指定的 for 持续时间内达到或超过提取示例阈值

先决条件

  • 您可以使用具有 cluster-admin 集群角色的用户访问集群,也可以使用在 openshift-user-workload-monitoring 项目中具有 user-workload-monitoring-config-edit 角色的用户访问集群。
  • 集群管理员为用户定义的项目启用了监控。
  • 您已经使用 enforcedSampleLimit 限制了用户定义的项目中每个目标提取可接受的示例数量。
  • 已安装 OpenShift CLI(oc)。

流程

  1. 创建一个包含警报的 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 警报的严重性。
  2. 将配置应用到用户定义的项目中:

    $ oc apply -f monitoring-stack-alerts.yaml
  3. 另外,您可以检查目标是否达到配置的限制:

    1. 在 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)。

流程

  1. 编辑 openshift-user-workload-monitoring 项目中的 user-workload-monitoring-config 配置映射:

    $ oc -n openshift-user-workload-monitoring edit configmap user-workload-monitoring-config
  2. 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 指定一个值。可用选项包括 DoNotScheduleScheduleAnyway。如果您希望 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

  3. 保存文件以使改变生效。受新配置影响的 Pod 会自动重新部署。
Red Hat logoGithubRedditYoutubeTwitter

学习

尝试、购买和销售

社区

关于红帽文档

通过我们的产品和服务,以及可以信赖的内容,帮助红帽用户创新并实现他们的目标。

让开源更具包容性

红帽致力于替换我们的代码、文档和 Web 属性中存在问题的语言。欲了解更多详情,请参阅红帽博客.

關於紅帽

我们提供强化的解决方案,使企业能够更轻松地跨平台和环境(从核心数据中心到网络边缘)工作。

© 2024 Red Hat, Inc.