Prometheus Operator 详解
Prometheus Operator 详解
本文介绍 Prometheus Operator 的概念、工作原理、部署方式,以及如何通过自定义资源实现监控与告警。
一、什么是 Operator
定义
Operator = 用自己开发的控制器管理自定义的资源
Operator(控制器)---管理---> 自定义资源(CR)在 K8s 中的意义
K8s 原生的控制器(如 Deployment、StatefulSet)只能管理原生资源。Operator 让你可以:
- 定义自己的"资源类型"(CRD)
- 用控制器自动化管理这些资源
二、为什么需要 Prometheus Operator
传统部署方式的问题
手动部署 Prometheus 监控体系:
1. 部署 Prometheus Server(手动)
2. 配置监控目标(改配置文件)
3. 配置 Alertmanager(改配置文件)
4. 配置告警规则(改配置文件)
5. 每次改配置 → 手动重启 Prometheus
6. 监控一套服务 → 重复步骤 2-5Operator 方式的优势
把 Prometheus 监控体系涉及的所有组件及相关配置都变成自定义资源,由控制器实现自动化管理:
- 配置的自动更新
- 配置的自动重载
- 一套 YAML 声明式管理所有组件
三、Prometheus Operator 架构
核心资源关系
┌─────────────────────────────────────────────────────────┐
│ Prometheus Operator 资源关系 │
├─────────────────────────────────────────────────────────┤
│ │
│ Prometheus(自定义资源) │
│ │ │
│ ├─── 关联 ──► ServiceMonitor(监控目标) │
│ │ │ │
│ │ └─── 关联 ──► Service │
│ │ │ │
│ │ └─── 关联 ──► Endpoints(/metrics)│
│ │ │
│ └─── 关联 ──► PrometheusRule(告警规则) │
│ │
│ Alertmanager(自定义资源) │
│ │ │
│ └─── 关联 ──► AlertmanagerConfig(路由配置) │
│ │
└─────────────────────────────────────────────────────────┘资源说明
| 资源类型 | 作用 |
|---|---|
| Prometheus | 定义一个 Prometheus Server 实例 |
| ServiceMonitor | 定义要监控的服务(target) |
| PrometheusRule | 定义告警规则 |
| Alertmanager | 定义 Alertmanager 实例 |
| AlertmanagerConfig | 定义告警路由、接收者配置 |
四、工作原理
控制器 Watch 机制
Operator 控制器会 Watch(监听)自定义资源的变更,发生变化则采取相应行动:
Prometheus 资源 → 创建 Pod
# 声明一个 Prometheus 资源
apiVersion: monitoring.coreos.com/v1
kind: Prometheus
metadata:
name: k8s
namespace: monitoring
spec:
replicas: 2
serviceAccountName: prometheus-k8s控制器行动:自动创建运行 Prometheus Server 的 Pod
ServiceMonitor 资源 → 更新配置
apiVersion: monitoring.coreos.com/v1
kind: ServiceMonitor
metadata:
name: nginx
namespace: monitoring
spec:
selector:
matchLabels:
app: nginx
endpoints:
- port: web
path: /metrics控制器行动:
- ServiceMonitor 被转换成监控 target
- 注入到 Prometheus Server 配置文件
- 自动 reload Prometheus 配置
PrometheusRule 资源 → 更新告警规则
apiVersion: monitoring.coreos.com/v1
kind: PrometheusRule
metadata:
name: nginx-alerts
spec:
groups:
- name: nginx
rules:
- alert: NginxDown
expr: up{job="nginx"} == 0
for: 1m控制器行动:
- PrometheusRule 被转换成告警规则
- 注入到 Prometheus Server 配置
- 自动 reload 配置
Alertmanager 资源 → 创建 Pod + 更新配置
apiVersion: monitoring.coreos.com/v1
kind: Alertmanager
metadata:
name: main
namespace: monitoring
spec:
replicas: 3控制器行动:
- 创建 Alertmanager Pod
- AlertmanagerConfig 转换成路由配置
- 自动 reload Alertmanager
五、部署 kube-prometheus
官方资源
- Prometheus Operator:prometheus-operator
- 完整监控栈:kube-prometheus
注意:如果要部署完整监控技术栈,用 kube-prometheus 项目。
部署步骤
# 1. 克隆项目
git clone https://github.com/prometheus-operator/kube-prometheus.git
cd kube-prometheus
# 2. 创建 monitoring 命名空间和 CRD 资源
kubectl apply --server-side -f manifests/setup
# 3. 等待 CRD 资源处于可用状态
kubectl wait \
--for condition=Established \
--all CustomResourceDefinition \
--namespace=monitoring
# 输出 "condition met" 代表完成
# 4. 部署 Operator 和监控组件
kubectl apply -f manifests/清理
kubectl delete -f manifests/
kubectl delete -f manifests/setup/常见问题
镜像拉取失败
如果镜像来自 registry.k8s.io 拉取失败,替换为国内镜像:
# 1. 修改 prometheusAdapter
vim manifests/prometheusAdapter-deployment.yaml
# 替换为
registry.cn-hangzhou.aliyuncs.com/egon-k8s-test/prometheus-adapter:v0.12.0
# 2. 修改 kubeStateMetrics
vim manifests/kubeStateMetrics-deployment.yaml
# 替换为
registry.cn-shanghai.aliyuncs.com/egon-k8s-test/kube-state-metrics:v2.13.0
# 3. 修改 prometheusOperator
vim manifests/prometheusOperator-deployment.yaml
# 替换为
registry.cn-shanghai.aliyuncs.com/egon-k8s-test/prometheus-operator:v0.76.0
registry.cn-shanghai.aliyuncs.com/egon-k8s-test/kube-rbac-proxy:v0.18.1无法删除命名空间
如果删除 monitoring 命名空间时卡住:
# 编辑命名空间,删除 finalizers
kubectl edit namespace monitoring
# 删除 spec.finalizers 字段六、查看 Prometheus/Alertmanager 配置
配置以 Secret 形式存储,三种查看方式:
方式一:进入 Pod 内查看
kubectl exec -it prometheus-k8s-0 -n monitoring -- /bin/sh
cat /etc/prometheus/config/prometheus.yaml方式二:Web 页面查看
Prometheus 和 Alertmanager 都有 Web UI,直接访问。
方式三:解码 Secret
# 查看 Prometheus 配置
kubectl -n monitoring get secrets prometheus-k8s -o json \
| jq -r '.data."prometheus.yaml.gz"' \
| base64 -d \
| gzip -d
# 查看 Alertmanager 配置
kubectl -n monitoring get secrets alertmanager-main -o json \
| jq -r '.data."alertmanager.yaml"' \
| base64 -d七、自定义监控实战
1. 准备 /metrics 接口
被监控的目标需要提供 /metrics 接口:
# 例如 etcd,需要修改监听地址
etcd --listen-metrics-urls=http://0.0.0.0:23812. 添加监控 Target
方式一:Pod 有 /metrics 接口
直接用 Service 标签选择:
apiVersion: v1
kind: Service
metadata:
name: nginx
labels:
app: nginx
spec:
selector:
app: nginx
ports:
- name: web
port: 80
targetPort: 80
---
apiVersion: monitoring.coreos.com/v1
kind: ServiceMonitor
metadata:
name: nginx
namespace: monitoring
spec:
selector:
matchLabels:
app: nginx
endpoints:
- port: web
path: /metrics方式二:没有 Service 的 Pod
创建 Endpoints 手动关联:
apiVersion: v1
kind: Endpoints
metadata:
name: my-app
subsets:
- addresses:
- ip: 10.244.1.100
ports:
- port: 9090
name: metrics3. 出图(Grafana)
- 部署 Grafana(kube-prometheus 已包含)
- 导入 Dashboard 模板
- 选择对应的 DataSource
4. 配置告警(Alertmanager)
创建告警规则
apiVersion: monitoring.coreos.com/v1
kind: PrometheusRule
metadata:
name: nginx-alerts
namespace: monitoring
spec:
groups:
- name: nginx
rules:
- alert: NginxDown
expr: up{job="nginx"} == 0
for: 1m
labels:
severity: critical
annotations:
summary: "Nginx 服务不可用"
- alert: HighMemoryUsage
expr: (1 - node_memory_MemAvailable_bytes / node_memory_MemTotal_bytes) * 100 > 80
for: 2m
labels:
severity: warning
annotations:
summary: "内存使用率 {{ $value }}%"配置 Alertmanager 路由
apiVersion: monitoring.coreos.com/v1
kind: AlertmanagerConfig
metadata:
name: dingtalk-config
namespace: monitoring
spec:
route:
groupBy: [alertname]
receiver: dingtalk
receivers:
- name: dingtalk
webhookConfigs:
- url: http://dingtalk-service:8060/dingtalk/webhook1/send八、自动发现配置(补充监控项)
8.1 为什么需要额外配置
ServiceMonitor 适合少量、精确的监控配置。但如果监控大量重复性目标(如所有带某个注解的 Service),一个个创建 ServiceMonitor 依然麻烦。
解决方案:通过 additionalScrapeConfigs 注入自动发现配置。
8.2 自动发现配置示例
第一步:创建配置 Secret
# prometheus-additional.yaml
- job_name: 'myendpoints'
kubernetes_sd_configs:
- role: endpoints
relabel_configs:
# 只保留带有 prometheus.io/scrape=true 注解的 Service
- source_labels: [__meta_kubernetes_service_annotation_prometheus_io_scrape]
action: keep
regex: true
# 替换监控路径(从注解读取)
- source_labels: [__meta_kubernetes_service_annotation_prometheus_io_path]
action: replace
target_label: __metrics_path__
regex: (.+)
# 替换目标地址和端口
- source_labels: [__address__, __meta_kubernetes_service_annotation_prometheus_io_port]
action: replace
target_label: __address__
regex: ([^:]+)(?::\d+)?;(\d+)
replacement: $1:$2
# 替换协议(http/https)
- source_labels: [__meta_kubernetes_service_annotation_prometheus_io_scheme]
action: replace
target_label: __scheme__
regex: (https?)
# 把 Service 标签转成 Prometheus 标签
- action: labelmap
regex: __meta_kubernetes_service_label_(.+)
replacement: $1
# 添加 namespace、service、pod 等标签
- source_labels: [__meta_kubernetes_namespace]
action: replace
target_label: kubernetes_namespace
- source_labels: [__meta_kubernetes_service_name]
action: replace
target_label: kubernetes_service
- source_labels: [__meta_kubernetes_pod_name]
action: replace
target_label: kubernetes_pod第二步:创建 Secret
kubectl create secret generic additional-configs \
--from-file=prometheus-additional.yaml \
-n monitoring第三步:修改 Prometheus 资源
# vim manifests/prometheus-prometheus.yaml
apiVersion: monitoring.coreos.com/v1
kind: Prometheus
metadata:
name: k8s
namespace: monitoring
spec:
# ... 其他配置 ...
additionalScrapeConfigs:
name: additional-configs
key: prometheus-additional.yaml第四步:给 ServiceAccount 授权
# 绑定 clusterrole,让 prometheus-k8s 的 sa 有查看 endpoints 的权限
kubectl create clusterrolebinding prometheus-endpoints-reader \
--clusterrole=endpoints-reader \
--serviceaccount=monitoring:prometheus-k8s8.3 使用方式
只需要在 Service 上添加注解即可自动被发现:
apiVersion: v1
kind: Service
metadata:
annotations:
prometheus.io/scrape: "true"
prometheus.io/path: "/metrics"
prometheus.io/port: "9090"
prometheus.io/scheme: "http"
labels:
app: myapp
name: myapp
spec:
selector:
app: myapp
ports:
- port: 808.4 prometheus.io/scrape 注解详解
是什么
prometheus.io/scrape 是一个标记注解,用来告诉 Prometheus:"这个 Service 要被监控"。
annotations:
prometheus.io/scrape: "true" # 打了这个标记的 Service 才会被监控为什么需要
K8s 里有大量 Service,但并不是所有都要监控。用这个标记来筛选。
# K8s 里有 100 个 Service
# 只有 30 个需要监控(打标记)
# 另外 70 个是内部服务,不需要监控怎么工作
自动发现配置里有这一步筛选:
relabel_configs:
# 检查:有没有 prometheus.io/scrape=true 注解
- source_labels: [__meta_kubernetes_service_annotation_prometheus_io_scrape]
action: keep # keep = 保留符合条件的
regex: true # 只保留值为 true 的结果:
- 有 prometheus.io/scrape="true" → 保留 → 被监控
- 没有这个注解 → 丢弃 → 不被监控8.5 relabel_configs 逐行详解
概念
relabel_configs:
# 3 种 action:
- action: keep # 筛选(保留符合条件的目标)
- action: replace # 替换(修改变量的值)
- action: labelmap # 映射(把某个前缀的标签转成新名字)Prometheus 自动携带的内置标签
当 Prometheus 发现一个 Service 时,自动带上这些标签:
| 内置标签 | 含义 |
|---|---|
__address__ | Service 的地址(IP:Port) |
__metrics_path__ | 指标路径(默认 /metrics) |
__scheme__ | 协议(http 或 https) |
__meta_kubernetes_service_annotation_xxx | Service 注解的值 |
__meta_kubernetes_namespace | 命名空间 |
__meta_kubernetes_service_name | Service 名称 |
逐行解析
relabel_configs:
# 第1步:筛选
# 保留带有 prometheus.io/scrape=true 注解的 Service
- source_labels: [__meta_kubernetes_service_annotation_prometheus_io_scrape]
action: keep
regex: true
# 第2步:替换监控路径
# 从注解 prometheus.io/path 读取路径,替换 __metrics_path__
- source_labels: [__meta_kubernetes_service_annotation_prometheus_io_path]
action: replace
target_label: __metrics_path__
regex: (.+) # 捕获注解的值作为新路径
# 第3步:替换地址和端口
# 从注解 prometheus.io/port 读取端口,替换 __address__
- source_labels: [__address__, __meta_kubernetes_service_annotation_prometheus_io_port]
action: replace
target_label: __address__
regex: ([^:]+)(?::\d+)?;(\d+)
replacement: $1:$2
# 第4步:替换协议
# 从注解 prometheus.io/scheme 读取(http 或 https)
- source_labels: [__meta_kubernetes_service_annotation_prometheus_io_scheme]
action: replace
target_label: __scheme__
regex: (https?)
# 第5步:标签映射
# 把 Service 的标签(app、env 等)转成 Prometheus 标签
- action: labelmap
regex: __meta_kubernetes_service_label_(.+)
replacement: $1
# 第6步:添加固定标签
- source_labels: [__meta_kubernetes_namespace]
action: replace
target_label: kubernetes_namespacesource_labels 和 regex 详解
source_labels: [__address__, __meta_kubernetes_service_annotation_prometheus_io_port]意思:从这两个标签取值,中间用分号连接
__address__ = "10.0.0.1:80" # Service 的 IP:端口
__meta_kubernetes_service_annotation_prometheus_io_port = "8080" # 注解里的端口
实际值 = "10.0.0.1:80;8080"regex: ([^:]+)(?::\d+)?;(\d+)
解析 "10.0.0.1:80;8080":
([^:]+) → 第一个捕获组:10.0.0.1(IP,非冒号字符)
(?::\d+)? → 非捕获组::80(可选的端口部分)
; → 分隔符
(\d+) → 第二个捕获组:8080(端口号)
所以:
$1 = 10.0.0.1
$2 = 8080replacement: $1:$2
意思是:用 $1(IP):$2(新端口)替换 __address__
原来:__address__ = "10.0.0.1:80"
替换后:__address__ = "10.0.0.1:8080"完整流程
┌─────────────────────────────────────────────────────────┐
│ Prometheus 发现一个 Service: │
│ __address__ = "10.0.0.1:80" │
│ prometheus.io/scrape = "true" │
│ prometheus.io/port = "8080" │
│ │
│ 第1步:检查 prometheus.io/scrape = true │
│ → 是 → 保留,继续 │
│ │
│ 第2步:替换端口 │
│ 原始 __address__ = "10.0.0.1:80;8080" │
│ 提取:IP=10.0.0.1,端口=8080 │
│ 替换后 __address__ = "10.0.0.1:8080" │
│ │
│ 结果:Prometheus 访问 10.0.0.1:8080/metrics │
└─────────────────────────────────────────────────────────┘8.6 端口不一样怎么处理
关键点
每个 Service 的注解里可以写不同的端口:
# Service A(Go 服务)
annotations:
prometheus.io/scrape: "true"
prometheus.io/port: "8080" # Go 服务用 8080
# Service B(Java 服务)
annotations:
prometheus.io/scrape: "true"
prometheus.io/port: "9090" # Java 服务用 9090
# Service C(Python 服务)
annotations:
prometheus.io/scrape: "true"
prometheus.io/port: "8000" # Python 服务用 8000自动发现配置只需要写一次,从每个 Service 的注解里读取各自的端口。
8.7 ServiceMonitor vs 自动发现
| 对比项 | ServiceMonitor | 自动发现 |
|---|---|---|
| 配置量 | 每个目标一个 YAML | 写一次配置 + 每个 Service 打注解 |
| 端口 | 在 ServiceMonitor 里指定 | 每个 Service 注解里写自己的 |
| 路径 | 在 ServiceMonitor 里指定 | 每个 Service 注解里写自己的 |
| 灵活性 | 高(可以精细控制) | 一般(统一规则) |
| 适合场景 | 少量、特殊需求 | 大量、规律性需求 |
选择建议
┌─────────────────────────────────────────────────────────┐
│ │
│ 大多数情况用自动发现 │
│ → 大量微服务,统一监控要求 │
│ → 每个 Service 打注解就行 │
│ │
│ 特殊需求用 ServiceMonitor │
│ → 需要 HTTPS/TLS 认证 │
│ → 需要不同 scrape interval │
│ → 同一个 Service 有多端口 │
│ → 非标准 /metrics 路径 │
│ │
└─────────────────────────────────────────────────────────┘可以同时用
两者不冲突,可以结合使用:
ServiceMonitor → 监控特殊目标(MySQL、Nginx)
自动发现 → 监控通用微服务(所有带注解的 Service)九、数据持久化
9.1 为什么需要持久化
Prometheus Server 的数据存储在 Pod 内,重启后会丢失。如果需要历史数据查询,需要持久化存储。
9.2 通过 StorageClass 持久化
Prometheus 是 StatefulSet 部署,通过 storage 字段指定持久化:
# 修改 prometheus-prometheus.yaml
apiVersion: monitoring.coreos.com/v1
kind: Prometheus
metadata:
name: k8s
namespace: monitoring
spec:
# ... 其他配置 ...
storage:
volumeClaimTemplate:
spec:
storageClassName: local-path # 使用 local-path 存储
resources:
requests:
storage: 20Gi # 请求 20Gi 空间9.3 验证持久化
# 查看 PVC
kubectl -n monitoring get pvc
# 输出示例
NAME STATUS VOLUME
prometheus-k8s-db-prometheus-k8s-0 Bound pvc-xxx 20Gi RWO local-path
prometheus-k8s-db-prometheus-k8s-1 Bound pvc-yyy 20Gi RWO local-path
# 查看 Pod 挂载
kubectl -n monitoring get pod prometheus-k8s-0 -o yaml | grep -A5 volumeMounts9.4 注意事项
警告:Prometheus 对 NFS 存储支持不好,线上环境不要使用 NFS。
十、黑盒监控
10.1 白盒监控 vs 黑盒监控
| 类型 | 视角 | 关注点 |
|---|---|---|
| 白盒监控 | 内部视角 | 资源用量、进程状态、连接数 |
| 黑盒监控 | 用户视角 | 站点能否访问、响应是否正常 |
白盒监控:看里面 → CPU/内存/磁盘用多少
黑盒监控:看外面 → 用户能不能访问10.2 Blackbox Exporter
Blackbox Exporter 是 Prometheus 官方提供的黑盒监控解决方案,可以模拟用户访问:
- HTTP/HTTPS:探测站点是否可访问
- TCP:检测端口是否开放
- ICMP/Ping:检测主机是否存活
- DNS:检测域名解析是否正常
- SSL 证书:检测证书是否过期
10.3 kube-prometheus 自带 Blackbox Exporter
# Blackbox Exporter 的 Service 已存在
kubectl -n monitoring get svc blackbox-exporter
# 输出
NAME TYPE CLUSTER-IP PORT(S)
blackbox-exporter ClusterIP 10.110.165.80 9115/TCP,19115/TCP10.4 黑盒监控配置
HTTP 监控示例
# 定义 Probe 资源
apiVersion: monitoring.coreos.com/v1
kind: Probe
metadata:
name: http-example
namespace: monitoring
spec:
interval: 30s
scrapeTimeout: 10s
jobName: http-check
targets:
staticConfig:
staticConfigs:
- targets:
- https://www.baidu.com
- https://example.com
module: http_2xx手动添加黑盒监控 Job
如果 Probe 不够灵活,可以直接通过 additionalScrapeConfigs 添加:
# prometheus-additional.yaml 添加
- job_name: 'blackbox-http'
metrics_path: /probe
params:
module: [http_2xx]
static_configs:
- targets:
- https://www.baidu.com
- https://example.com
relabel_configs:
- source_labels: [__address__]
target_label: __param_target
- source_labels: [__param_target]
target_label: instance
- target_label: __address__
replacement: blackbox-exporter.monitoring:1911510.5 黑盒监控告警规则
apiVersion: monitoring.coreos.com/v1
kind: PrometheusRule
metadata:
name: blackbox-alerts
spec:
groups:
- name: blackbox
rules:
# 探测失败告警
- alert: BlackboxProbeFailed
expr: probe_success == 0
for: 1m
labels:
severity: critical
annotations:
summary: "黑盒探测失败 {{ $labels.instance }}"
description: "探测失败,当前值:{{ $value }}"
# 请求慢告警
- alert: BlackboxProbeSlow
expr: avg_over_time(probe_duration_seconds[1m]) > 1
for: 1m
labels:
severity: warning
annotations:
summary: "请求响应慢 {{ $labels.instance }}"
description: "响应时间超过 1 秒,当前值:{{ $value }}s"
# HTTP 状态码异常
- alert: BlackboxHttpStatusError
expr: probe_http_status_code <= 199 OR probe_http_status_code >= 400
for: 1m
labels:
severity: critical
annotations:
summary: "HTTP 状态码异常 {{ $labels.instance }}"
description: "状态码非 200-399,当前:{{ $value }}"
# SSL 证书即将到期(30天)
- alert: SSLCertExpiringSoon
expr: probe_ssl_earliest_cert_expiry - time() < 86400 * 30
for: 1m
labels:
severity: warning
annotations:
summary: "SSL 证书即将到期 {{ $labels.instance }}"
description: "证书将在 30 天后过期"
# SSL 证书过期
- alert: SSLCertExpired
expr: probe_ssl_earliest_cert_expiry - time() <= 0
for: 1m
labels:
severity: critical
annotations:
summary: "SSL 证书已过期 {{ $labels.instance }}"
description: "SSL 证书已过期,请立即处理"10.6 常用黑盒监控场景
| 场景 | 协议 | 监控内容 |
|---|---|---|
| 站点可用性 | HTTP | 状态码、响应时间 |
| API 联通性 | HTTP POST | 接口返回是否正常 |
| 端口探测 | TCP | 端口是否开放 |
| 服务探活 | ICMP | 主机是否存活 |
| DNS 解析 | DNS | 域名解析是否正常 |
| 证书过期 | SSL | 证书剩余有效期 |
十一、kube-prometheus 自带组件
部署 kube-prometheus 后,monitoring 命名空间下会有这些组件:
| 组件 | 类型 | 作用 |
|---|---|---|
| prometheus-operator | Deployment | 控制器,管理所有 CR |
| prometheus-k8s | StatefulSet | Prometheus Server |
| alertmanager-main | StatefulSet | Alertmanager 集群 |
| grafana | Deployment | 可视化面板 |
| kube-state-metrics | Deployment | 采集 K8s 对象状态指标 |
| node-exporter | DaemonSet | 采集主机指标(CPU、内存等) |
| blackbox-exporter | Deployment | 黑盒监控探测 |
| prometheus-adapter | Deployment | 自定义指标 APIService |
常用 exporter 端口
| Exporter | 端口 | 监控什么 |
|---|---|---|
| node-exporter | 9100 | 主机资源 |
| mysqld_exporter | 9104 | MySQL |
| redis_exporter | 9121 | Redis |
| postgres_exporter | 9187 | PostgreSQL |
| blackbox-exporter | 9115/19115 | HTTP/TCP/ICMP |
十二、总结
整体架构图
┌─────────────────────────────────────────────────────────┐
│ kube-prometheus 完整架构 │
├─────────────────────────────────────────────────────────┤
│ │
│ ┌─────────────────────────────────────────────────┐ │
│ │ Prometheus Operator │ │
│ │ (控制器,Watch 所有 CR) │ │
│ └─────────────────────┬───────────────────────────┘ │
│ │ │
│ ┌────────────────────┴───────────────────────────┐ │
│ │ 自定义资源(CR) │ │
│ │ ┌──────────┐ ┌──────────┐ ┌──────────┐ │ │
│ │ │Prometheus│ │Service │ │Prometheus│ │ │
│ │ │ │ │Monitor │ │Rule │ │ │
│ │ └──────────┘ └──────────┘ └──────────┘ │ │
│ │ ┌──────────┐ ┌──────────┐ │ │
│ │ │Alert │ │Alertmanager│ │ │
│ │ │manager │ │Config │ │ │
│ │ └──────────┘ └──────────┘ │ │
│ └─────────────────────────────────────────────────┘ │
│ │ │
│ ┌────────────────────┴───────────────────────────┐ │
│ │ 监控目标(数据来源) │ │
│ │ ┌──────────┐ ┌──────────┐ ┌──────────┐ │ │
│ │ │node- │ │kube- │ │应用 │ │ │
│ │ │exporter │ │state-metrics│ │exporter │ │ │
│ │ └──────────┘ └──────────┘ └──────────┘ │ │
│ └─────────────────────────────────────────────────┘ │
│ │
└─────────────────────────────────────────────────────────┘核心要点
┌─────────────────────────────────────────────────────────┐
│ Prometheus Operator 核心要点 │
├─────────────────────────────────────────────────────────┤
│ │
│ 核心理念: │
│ └─ 把监控体系所有组件都变成 K8s 自定义资源 │
│ │
│ 自定义资源: │
│ ├─ Prometheus → 运行 Prometheus Server │
│ ├─ ServiceMonitor → 定义监控目标 │
│ ├─ PrometheusRule → 定义告警规则 │
│ ├─ Alertmanager → 运行 Alertmanager │
│ └─ AlertmanagerConfig → 定义路由和接收者 │
│ │
│ 控制器行为: │
│ ├─ 检测到变更 → 自动 reload 配置 │
│ └─ 声明式管理 → 修改 YAML 即可 │
│ │
│ 监控方式: │
│ ├─ ServiceMonitor → 精确监控少量目标 │
│ ├─ 自动发现 → 批量监控,打注解就行 │
│ └─ Probe → 黑盒监控 │
│ │
│ 部署: │
│ └─ kube-prometheus = Operator + 完整监控栈 │
│ │
└─────────────────────────────────────────────────────────┘十三、命令速查
# 查看 Prometheus Pod
kubectl get pods -n monitoring | grep prometheus
# 查看 ServiceMonitor
kubectl get servicemonitor -n monitoring
# 查看 PrometheusRule
kubectl get prometheusrule -n monitoring
# 查看 Alertmanager
kubectl get alertmanager -n monitoring
# 查看 Probe(黑盒监控)
kubectl get probe -n monitoring
# 查看 Secret 配置(解码)
kubectl -n monitoring get secrets prometheus-k8s -o json \
| jq -r '.data."prometheus.yaml.gz"' | base64 -d | gzip -d
# 手动 reload Prometheus(触发配置重新加载)
kubectl exec -it prometheus-k8s-0 -n monitoring -c prometheus -- \
curl -X POST http://localhost:9090/-/reload
# 查看 PVC(持久化存储)
kubectl -n monitoring get pvc
# 查看所有监控相关资源
kubectl -n monitoring get all