一、 背景

在非 operator 配置的普罗中我们监控 k8s 集群都是通过配置 configmap 进行服务发现和指标拉取。切换到 prometheus-operator 难免会有些使用问题。不少用户已经习惯底层配置自动发现的方式。当过渡到 servicemonitor 或者 podmonitor 或多或少不习惯。所以下面就为大家介绍一下 Prometheus-Operator，以及 servicemonitor 的使用方法

二、 Prometheus-Operator 介绍

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

• kubernetes 自定义资源：使用 kubernetes CRD 来部署和管理 Prometheus，Alertmanager 和相关组件

• 简化的部署配置：直接通过 kubernetes 资源清单配置 Prometheus,比如版本，持久化，副本，保留策略等等配置

• Prometheus 监控目标配置：基于熟知的 kubernetes 标签查询自动生成监控目标配置，无需学习 prometheus 特地的配置

2.1 架构

下图是 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 屏蔽了。

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

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

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

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

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

2.2 常见 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 部署。

三、 Prometheus-Operator 安装

Prometheus-Operator 对 K8S 集群的版本有要求，请参照集群版本选择对应 Prometheus-Operator 版本代码库：https://github.com/prometheus-operator/kube-prometheus

本文档所用环境为 1.25k8s 集群对应 0.12.0 版本https://github.com/prometheus-operator/kube-prometheus/archive/refs/heads/release-0.12.zip

3.1 安装

wget https://github.com/prometheus-operator/kube-prometheus/archive/refs/heads/release-0.12.zip    unzip release-0.12.zip     cd kube-prometheus-release-0.12     kubectl apply --server-side -f manifests/setup     kubectl wait \     --for condition=Established \     --all CustomResourceDefinition \    --namespace=monitoring     kubectl apply -f manifests/

#注意：kube-state-metrics 和 prometheus-adapter 的镜像为谷歌官方库的镜像，国内可能存在拉取不到的问题，如果由于镜像拉取不到导致 pod pending，请将其替换成可获取到的镜像地址。

3.2 卸载

注意：此步骤为卸载步骤，如果想继续保留 Prometheus-Operator，请不要执行此步骤kubectl delete --ignore-not-found=true -f manifests/ -f manifests/setup

四、使用 servicemonitor 监控应用暴露的指标

创建 deployment 对象和 service 资源，该服务 8080 端口会暴露自身指标。

apiVersion: apps/v1kind: Deploymentmetadata:  labels:    app: sample-metrics-app  name: sample-metrics-appspec:  replicas: 2  selector:    matchLabels:      app: sample-metrics-app  template:    metadata:      labels:        app: sample-metrics-app    spec:      tolerations:      - key: beta.kubernetes.io/arch        value: arm        effect: NoSchedule      - key: beta.kubernetes.io/arch        value: arm64        effect: NoSchedule      - key: node.alpha.kubernetes.io/unreachable        operator: Exists        effect: NoExecute        tolerationSeconds: 0      - key: node.alpha.kubernetes.io/notReady        operator: Exists        effect: NoExecute        tolerationSeconds: 0      containers:      - image: luxas/autoscale-demo:v0.1.2        name: sample-metrics-app        ports:        - name: web          containerPort: 8080        readinessProbe:          httpGet:            path: /            port: 8080          initialDelaySeconds: 3          periodSeconds: 5        livenessProbe:          httpGet:            path: /            port: 8080          initialDelaySeconds: 3          periodSeconds: 5---apiVersion: v1kind: Servicemetadata:  name: sample-metrics-app  labels:    app: sample-metrics-appspec:  ports:  - name: web    port: 80    targetPort: 8080  selector:    app: sample-metrics-app

创建 servicemonitor 对象采集应用指标

apiVersion: monitoring.coreos.com/v1kind: ServiceMonitormetadata:  name: sample-metrics-app  labels:    service-monitor: sample-metrics-appspec:  selector:    matchLabels:      app: sample-metrics-app  # 匹配标签为app：sample-metrics-app的service  endpoints:  - port: web  #Promethues采集指标的端口为service中portName表示的端口

查看新建的 service，在集群内节点上通过 service IP 访问应用kubectl get service

通过访问 service IP 的 metrics 接口可以查看到应用暴露的指标curl 10.247.227.116/metrics

可以看到，应用暴露的指标是 “http_requests_total” ，且监控采集到的数量是 805

浏览器访问 Prometheus UI 界面查看指标通过 IP 和端口访问 prometheus-server，查看 servermonitor 及指标监控情况

可以看到应用暴露的指标已成功采集，由于指标采集时间间隔的原因，prometheus 采集的指标数为 800，而应用的 metrics 接口暴露出的数量为 805。

文章转载自：华为云开发者联盟

原文链接：https://www.cnblogs.com/huaweiyun/p/17898923.html

体验地址：http://www.jnpfsoft.com/?from=001