← 返回文章列表

Prometheus Operator 详解

22 分钟阅读
字号

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-5

Operator 方式的优势

把 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

控制器行动

  1. ServiceMonitor 被转换成监控 target
  2. 注入到 Prometheus Server 配置文件
  3. 自动 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

控制器行动

  1. PrometheusRule 被转换成告警规则
  2. 注入到 Prometheus Server 配置
  3. 自动 reload 配置

Alertmanager 资源 → 创建 Pod + 更新配置

apiVersion: monitoring.coreos.com/v1
kind: Alertmanager
metadata:
  name: main
  namespace: monitoring
spec:
  replicas: 3

控制器行动

  1. 创建 Alertmanager Pod
  2. AlertmanagerConfig 转换成路由配置
  3. 自动 reload Alertmanager

五、部署 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:2381

2. 添加监控 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: metrics

3. 出图(Grafana)

  1. 部署 Grafana(kube-prometheus 已包含)
  2. 导入 Dashboard 模板
  3. 选择对应的 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-k8s

8.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: 80

8.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_xxxService 注解的值
__meta_kubernetes_namespace命名空间
__meta_kubernetes_service_nameService 名称

逐行解析

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_namespace

source_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 = 8080
replacement: $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 volumeMounts

9.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/TCP

10.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:19115

10.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-operatorDeployment控制器,管理所有 CR
prometheus-k8sStatefulSetPrometheus Server
alertmanager-mainStatefulSetAlertmanager 集群
grafanaDeployment可视化面板
kube-state-metricsDeployment采集 K8s 对象状态指标
node-exporterDaemonSet采集主机指标(CPU、内存等)
blackbox-exporterDeployment黑盒监控探测
prometheus-adapterDeployment自定义指标 APIService

常用 exporter 端口

Exporter端口监控什么
node-exporter9100主机资源
mysqld_exporter9104MySQL
redis_exporter9121Redis
postgres_exporter9187PostgreSQL
blackbox-exporter9115/19115HTTP/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
分享

// RELATED_POSTS

0%