4. Prometheus Operator 架构：核心组件与自动发现原理

在生产环境中，手动管理 Prometheus 配置（如 scrape_configs、rule_files）会随着微服务数量增长而迅速失控。Prometheus Operator 通过 Kubernetes 原生声明式 API 解决了这一痛点，将 Prometheus 的部署、配置、服务发现和告警管理全部抽象为自定义资源（CRD）。本章深入剖析 Operator 的组件架构、ServiceMonitor/PodMonitor 配置细节以及自动发现机制。

4.1 整体架构与核心组件

Prometheus Operator 遵循典型的 Kubernetes Operator 模式：一个控制循环（Controller）持续监听自定义资源的变化，并调和出期望的 Prometheus 实例状态。其核心组件包括：

4.2 ServiceMonitor 配置详解

ServiceMonitor 是 Prometheus Operator 中最常用的抓取配置 CRD。它通过 标签选择器 匹配 Kubernetes Service，然后从 Service 的 spec.ports 中获取抓取端口和路径。

4.2.1 核心字段与示例

apiVersion: monitoring.coreos.com/v1
kind: ServiceMonitor
metadata:
  name: my-app-monitor
  namespace: monitoring
spec:
  # 选择要抓取的 Service（命名空间选择器 + 标签选择器）
  namespaceSelector:
    matchNames:
      - production
  selector:
    matchLabels:
      app: my-app
      release: stable
  # 定义抓取端点
  endpoints:
  - port: http-metrics      # 对应 Service 的端口名称
    interval: 15s
    path: /metrics
    scheme: http
    # 可选：TLS 配置、BasicAuth、Relabel 等
    relabelings:
    - sourceLabels: [__meta_kubernetes_pod_node_name]
      targetLabel: node
      action: replace
  # 目标标签（自动附加到所有抓取到的指标）
  targetLabels:
    - app
    - version

4.2.2 ServiceMonitor 与 Service 的关联流程

1. 用户创建 ServiceMonitor：指定 namespaceSelector 和 selector。
2. Operator 监听事件：发现新的 ServiceMonitor 资源。
3. 查询匹配的 Service：Operator 调用 Kubernetes API，列出指定命名空间下所有标签匹配的 Service。
4. 解析 Endpoints：对于每个匹配的 Service，获取其 spec.ports 中名称与 endpoints.port 匹配的端口，再查询该 Service 背后的 Endpoints 对象，得到所有 Pod IP。
5. 生成 scrape_config：Operator 将上述信息写入 Prometheus 配置的 scrape_configs 段，并触发 Prometheus 热加载。

4.3 PodMonitor 配置详解

PodMonitor 与 ServiceMonitor 类似，但 不经过 Service 层，直接通过 Pod 标签选择器抓取。适用于以下场景：

• Sidecar 模式：主业务容器与指标导出 Sidecar 同 Pod，但未创建 Service。
• 无头服务（Headless Service）：需要直接抓取每个 Pod 实例。
• Batch 任务：短生命周期 Pod，不需要 Service 抽象。

4.3.1 PodMonitor 示例

apiVersion: monitoring.coreos.com/v1
kind: PodMonitor
metadata:
  name: sidecar-monitor
  namespace: monitoring
spec:
  namespaceSelector:
    any: true  # 选择所有命名空间
  selector:
    matchLabels:
      sidecar: metrics-exporter
  podMetricsEndpoints:
  - port: metrics
    interval: 30s
    path: /metrics
    relabelings:
    - sourceLabels: [__meta_kubernetes_pod_container_name]
      targetLabel: container
      action: replace

4.4 自动发现原理与 Relabeling 机制

Prometheus Operator 的自动发现能力建立在 Kubernetes 服务发现（SD）之上，并通过 Relabeling 对发现的目标进行过滤、修改和标记。理解 Relabeling 是排查抓取问题的关键。

4.4.1 自动发现流程

4.4.2 关键元标签与 Relabeling 实战

Prometheus 在自动发现时会为每个目标注入一组 __meta_kubernetes_* 标签。以下是最常用的元标签：

4.4.3 典型 Relabeling 场景

relabelings:
- sourceLabels: [__meta_kubernetes_namespace]
  regex: production
  action: keep
- sourceLabels: [__meta_kubernetes_pod_label_app]
  regex: my-app
  action: keep
- sourceLabels: [__meta_kubernetes_pod_label_version]
  targetLabel: version
  action: replace
- sourceLabels: [__meta_kubernetes_pod_name]
  targetLabel: instance
  action: replace

4.5 ServiceMonitor 与 PodMonitor 对比

4.6 蓝绿发布场景下的自动发现挑战

在蓝绿发布过程中，ServiceMonitor 和 PodMonitor 的自动发现行为会直接影响流量切换的观测连续性：

• ServiceMonitor 切换滞后：当 Service 的 selector 从蓝色 Pod 标签切换到绿色 Pod 标签时，Prometheus 需要等待下一次 relist interval（默认 30s-60s）才能发现新的 Endpoints。这会导致抓取目标短暂为空或出现旧目标。
• PodMonitor 实时性更高：PodMonitor 直接监听 Pod 标签变化，新 Pod 创建后几乎立即被发现（取决于 Operator 的同步周期，通常 10-15s）。
• Relabeling 冲突：如果蓝绿 Pod 带有相同的 app 标签但不同的 version 标签，Relabeling 规则需要正确处理，避免将两个版本的目标合并到同一个 job 中导致指标混乱。