📚 课程目录第2章 PromOperator架构回顾

2. PromOperator 架构回顾：CRD 核心对象与 Operator 工作流程

在深入配置漂移审计之前，必须重新梳理 Prometheus Operator（PromOperator）的核心架构。Operator 的本质是一个“有状态的控制器”，它通过监听 Kubernetes 内置资源与自定义资源（CRD）的变化，自动维持 Prometheus 监控栈的期望状态。理解 CRD 对象与 Operator 工作流程，是定位配置漂移根源的基石。

2.1 三大核心 CRD 对象

PromOperator 定义了多个 CRD，其中与配置漂移审计最密切的是以下三个：

CRD 名称	API 版本（常见）	核心职责	配置漂移风险点
Prometheus	monitoring.coreos.com/v1	定义 Prometheus 实例的全局配置，包括副本数、存储、保留策略、RBAC、以及全局的 `additionalScrapeConfigs` 和 `ruleSelector`。	全局配置变更（如 `scrapeInterval`、`evaluationInterval`）会直接影响所有采集和告警行为。
ServiceMonitor	monitoring.coreos.com/v1	定义如何从一组 Service 中抓取指标。通过 Label Selector 匹配目标 Service，并指定抓取路径、端口、协议及 TLS 配置。	Selector 变更、抓取路径修改、标签重命名（relabeling）规则调整，会导致采集目标丢失或数据错乱。
PrometheusRule	monitoring.coreos.com/v1	定义告警规则（Alerting Rules）和预计算规则（Recording Rules）。Operator 会将这些规则自动注入到 Prometheus 实例中。	规则表达式、标签、注解的修改会直接改变告警触发逻辑，是审计的重点对象。

审计视角提示： 配置漂移通常不是“全量替换”，而是“增量修改”。例如，运维人员可能仅修改了 ServiceMonitor 中的一个 relabel 动作，却导致下游 Grafana 面板数据源失效。因此，对 CRD 的 spec 字段进行版本化审计至关重要。

2.2 Operator 工作流程：从 CRD 到 Prometheus 配置

Operator 的核心逻辑是一个“事件驱动 + 循环调和”的控制器。理解这个流程，就能明白为什么 CRD 的每一次变更都会触发 Prometheus 配置的重新生成与热加载。

下图展示了 Operator 从监听 CRD 到最终更新 Prometheus 配置的完整链路：

2.3 调和循环详解

Operator 的调和循环（Reconcile Loop）是配置漂移发生的“执行现场”。以下是标准调和步骤：

事件监听： Operator 通过 Informer 监听 Prometheus、ServiceMonitor、PrometheusRule 等 CRD 的 Add、Update、Delete 事件。
队列入队： 事件被封装成 Reconcile Request 放入工作队列。Operator 支持并发处理多个请求。
读取当前状态： 从 API Server 读取关联的 CRD 对象最新版本，以及当前 Prometheus StatefulSet 的配置。
生成期望配置： 根据 CRD 的 spec 字段，生成 Prometheus 配置文件（prometheus.yaml）和规则文件。
对比与更新： 将生成的期望配置与当前运行配置进行对比。如果存在差异，则通过 ConfigMap 更新配置，并触发 Prometheus 热加载（POST /-/reload）。
更新状态： 更新 CRD 的 status 字段，反映当前调和结果（如 Available、Reconciling、Failed）。

配置漂移关键洞察： 步骤 5 中的“对比与更新”是 Operator 的正常行为。但问题在于，如果多个 Operator 实例或外部工具同时修改同一个 CRD，或者 CRD 被直接编辑（kubectl edit）而未经过 CI/CD 管道，就会产生非预期的配置漂移。审计系统需要记录的是“谁、在什么时间、修改了哪个 CRD 的哪个字段”。

2.4 CRD 对象关系与配置继承

理解 CRD 之间的引用关系，有助于审计时追溯配置变更的影响范围。

serviceMonitorSelector 和 ruleSelector 匹配 ServiceMonitor 和 PrometheusRule。

  审计实践要点：
  ServiceMonitor 变更： 修改 spec.selector 可能导致 Prometheus 丢失或新增采集目标。审计时应关注 spec.endpoints[].port、spec.endpoints[].path 及 spec.endpoints[].relabelings。
PrometheusRule 变更： 修改 spec.groups[].rules[].expr 或 spec.groups[].rules[].labels 会直接改变告警行为。审计系统应能展示规则表达式的 Diff。
Prometheus 实例变更： 修改 spec.ruleSelector 或 spec.serviceMonitorSelector 的 Label Selector，会导致匹配到的 ServiceMonitor 或 PrometheusRule 集合发生变化，属于“范围漂移”。

2.5 配置漂移在 Operator 工作流中的表现形式

基于上述架构，配置漂移在 Operator 工作流中通常表现为以下三种形式：

漂移类型	触发场景	Operator 响应	审计检测方法
CRD Spec 漂移	直接使用 `kubectl edit` 修改 CRD，或 CI/CD 管道推送了非预期的配置。	Operator 检测到 CRD 版本变化，触发调和，重新生成配置并热加载。	对比 CRD 的 `spec` 字段历史版本（如使用 `kubectl apply --server-side` 的 managed fields）。
Selector 漂移	修改了 ServiceMonitor 或 PrometheusRule 的 Label Selector，导致匹配范围变化。	Operator 重新计算匹配的 CRD 列表，更新 Prometheus 的 `scrape_configs` 或 `rule_files`。	审计 Selector 表达式的变更，并记录匹配对象数量的变化。
全局配置漂移	修改 Prometheus CRD 的全局参数，如 `scrapeInterval`、`evaluationInterval`、`externalLabels`。	Operator 更新 Prometheus 主配置文件，影响所有采集和评估周期。	审计 Prometheus CRD 的 `spec` 根级别字段，并与基线配置进行 Diff。