1. 课程导论：什么是配置漂移、为什么需要审计、PromOperator 在配置漂移中的角色

1.1 什么是配置漂移

配置漂移（Configuration Drift）是指系统或基础设施的实际运行状态与预期基准配置之间逐渐产生的、非预期的偏差。在云原生环境中，这种漂移通常表现为：

• 手动修复：运维人员通过 kubectl edit 或 kubectl patch 临时修改资源，但未同步到 Git 仓库。
• 热修复脚本：应急时直接修改 Deployment 或 DaemonSet，导致与 Helm Chart 或 Kustomize 基线不一致。
• 版本滞后：集群中部分 Prometheus 实例的 Operator 版本、CRD 版本或镜像标签与预期不符。
• 配置残留：旧版 ServiceMonitor 或 PodMonitor 未被清理，导致指标采集重复或冲突。

1.2 为什么需要审计

审计配置漂移并非为了“追责”，而是为了建立可观测、可追溯、可恢复的运维基线。具体原因包括：

1.3 PromOperator 在配置漂移中的角色

Prometheus Operator（简称 PromOperator）通过 CRD（Custom Resource Definition）将 Prometheus 及其周边组件的配置声明式地管理起来。它在配置漂移审计中扮演三个关键角色：

1. 配置的声明式入口：所有 Prometheus 实例、采集规则、告警规则都通过 Prometheus、ServiceMonitor、PodMonitor、PrometheusRule 等 CRD 定义。这些 CRD 是审计的“黄金基准”。
2. 状态的实际执行者：Operator 控制器持续调和（Reconcile）CRD 状态与集群实际状态。当调和循环检测到漂移时，Operator 会尝试自动修复，但并非所有漂移都能被自动覆盖。
3. 漂移的暴露面：Operator 通过 Status 字段、Events 事件以及 Metrics 指标暴露调和结果。这些数据是审计系统判断是否存在漂移的直接证据。

1.4 漂移发生的典型场景

在 PromOperator 日常运维中，以下场景最容易引发配置漂移：

• 场景 A：临时扩缩容 — 运维人员直接修改 Prometheus StatefulSet 的副本数，但未更新 Prometheus CR 的 replicas 字段。Operator 下次调和时会将其重置，导致服务中断。
• 场景 B：热加载规则 — 通过 POST /-/reload 向 Prometheus 实例注入临时告警规则，但未写入 PrometheusRule CR。重启后规则丢失。
• 场景 C：手动打标签 — 为 ServiceMonitor 关联的 Service 手动添加 prometheus.io/scrape: "true" 注解，导致 Operator 生成的采集配置与预期不符。
• 场景 D：版本回退 — 回滚 Operator 版本时，未同步回滚 CRD 版本，导致新 CRD 字段被旧 Operator 忽略，配置静默丢失。

1.5 审计的核心指标

在后续课程中，我们将围绕以下核心指标构建审计能力：