k8s1.23 部署Prometheus-Operator集群监控

1. Prometheus-Operator介绍

Prometheus Operator 为 Kubernetes 提供了对 Prometheus 相关监控组件的本地部署和管理方案，该项目的目的是为了简化和自动化基于 Prometheus 的监控栈配置，主要包括以下几个功能：

• kubernetes自定义资源：使用kubernetes CRD 来部署和管理Prometheus，Alertmanager和相关组件
• 简化的部署配置：直接通过kubernetes资源清单配置Prometheus,比如版本，持久化，副本，保留策略等等配置
• Prometheus监控目标配置：基于熟知的kubernetes标签查询自动生成监控目标配置，无需学习prometheus特地的配置

1.1. prometheus-operator组织架构

下图是 Prometheus-Operator 官方提供的架构图，各组件以不同的方式运行在 Kubernetes 集群中，其中 Operator 是最核心的部分，作为一个控制器，它会去创建 Prometheus、ServiceMonitor、AlertManager以及 PrometheusRule 等 CRD 资源对象，然后会一直 Watch 并维持这些资源对象的状态。

下面三个yaml文件 很好的表述了，prometheus 如何关联选择 servicemonitor，servicemonitor 如何关联选择目标service。

为了能让prom监控k8s内的应用，Prometheus-Operator通过配置servicemonitor匹配到由service对象自动填充的Endpoints，并配置prometheus监控这些Endpoints后端的pods，ServiceMonitor.Spec的Endpoints部分就是用于配置Endpoints的哪些端口将被scrape指标。

servicemonitor对象很巧妙，它解耦了“监控的需求”和“需求的实现方”。servicemonitor 只需要用到label-selector 这种简单又通用的方式声明一个 “监控需求”，也就是哪些Endpoints 需要搜集，怎么收集就行了。让用户只关心需求，这是一个非常好的关注点分离。当然servicemonitor 最后还是会被operator转化为原始的复 杂的scrape config,但这个复杂度已经完全被operator屏蔽了。

1.2. prometheus告警对接流程

下图很好的展现了prometheus在配置报警时需要操作哪些资源，及各资源起到的作用

首先通过配置servicemonitor/podmonitor来获取应用的监控指标；

Prometheus.spec.alerting字段会匹配Alertmanager中的配置，匹配到alertmanager实例

然后通过prometheusrule对监控到的指标配置报警规则；

最后配置告警接收器，配置alertmanagerconfig来配置如何处理告警，包括如何接收、路由、抑制和发送警报等；

1.3. 常见CRD

Prometheus：

定义了所需的 Prometheus 部署。

ServiceMonitor：

以声明方式指定应如何监控 Kubernetes 服务组。Operator 根据 API 服务器中对象的当前状态自动生成 Prometheus 抓取配置。

PodMonitor:

以声明方式指定应如何监控 pod 组。Operator 根据 API 服务器中对象的当前状态自动生成 Prometheus 抓取配置。

PrometheusRule:

定义了一组所需的 Prometheus 警报和/或记录规则。Operator 生成一个规则文件，可供 Prometheus 实 例使用。

Alertmanager:

定义了所需的 Alertmanager 部署。

AlertmanagerConfig:

以声明方式指定 Alertmanager 配置的子部分，允许将警报路由到自定义接收器并设置禁止规则。

Probe:

以声明方式指定应如何监视入口组或静态目标。Operator 根据定义自动生成 Prometheus scrape 配置。 配合blackbox exporter使用。

ThanosRuler:

定义了所需的 Thanos Ruler 部署。

2. 克隆Prometheus Operator