2.2. 对监控的维护和支持

若要配置 OpenShift Container Platform Monitoring,支持的方式是使用本文中介绍的选项。请勿使用其他配置,因为不受支持。各个 Prometheus 发行版本的配置范例可能会有所变化,只有掌握了所有可能的配置,才能稳妥应对这样的配置变化。如果使用并非本节所描述的配置,您的更改可能会丢失,因为 cluster-monitoring-operator 会调节差异。根据设计,Operator 默认将一切重置到定义的状态。

2.2.1. 对监控的支持注意事项

明确不支持以下修改:

  • openshift-*kube-* 项目中创建额外的 ServiceMonitorPodMonitorPrometheusRule 对象。
  • 修改 openshift-monitoringopenshift-user-workload-monitoring 项目中部署的任何资源或对象。OpenShift Container Platform 监控堆栈所创建的资源并不是为了供任何其他资源使用,因为不能保证向后兼容性。

    注意

    Alertmanager 配置作为 secret 资源部署在 openshift-monitoring 项目中。要为 Alertmanager 配置额外的路由,您需要对该 secret 进行解码、修改,然后再进行编码。该程序是对前述声明的一个受支持例外。

  • 修改堆栈的资源。OpenShift Container Platform 监控堆栈确保其资源始终处于期望的状态。如果修改了资源,堆栈会重置它们。
  • 将用户定义的工作负载部署到 openshift-*kube-* 项目。这些项目是为红帽提供的组件保留的,不应该用于用户定义的工作负载。
  • 修改监控堆栈 Grafana 实例。
  • 在 OpenShift Container Platform 上安装自定义 Prometheus 实例。
  • 使用 Prometheus Operator 中的 Probe 自定义资源定义(CRD)启用基于症状的监控。

2.2.2. 监控 Operator 的支持策略

监控 Operator 确保 OpenShift Container Platform 监控资源按设计和测试的方式正常工作。如果某个 Operator 的 Cluster Version Operator (CVO) 控制被覆盖,该 Operator 不会响应配置更改,协调集群对象的预期状态或接收更新。

虽然在调试过程中覆盖 Operator 的 CVO 可能有所帮助,但该操作不受支持,集群管理员需要完全掌控各个组件的配置和升级。

覆盖 Cluster Version Operator

可将 spec.overrides 参数添加到 CVO 的配置中,以便管理员提供对组件的 CVO 行为覆盖的列表。将一个组件的 spec.overrides[].unmanaged 参数设置为 true 会阻止集群升级并在设置 CVO 覆盖后提醒管理员:

Disabling ownership via cluster version overrides prevents upgrades. Please remove overrides before continuing.
警告

设置 CVO 覆盖会使整个集群处于不受支持的状态,并导致监控堆栈无法被协调到其预期状态。这会影响 Operator 内置的可靠性功能,并妨碍接收更新。在删除所有覆盖后,必须可以重现报告的问题方可获得支持。