2. Prometheus 接入策略即代码基础：IaC 概念、Prometheus Operator、CRD 资源模型
在构建租户配额回滚护栏之前，必须理解“策略即代码”的底层基础设施。本章聚焦三个核心支柱：基础设施即代码（IaC）的通用原则、Prometheus Operator 在 Kubernetes 中的角色，以及 CRD（Custom Resource Definition） 资源模型如何将监控配置转化为可声明、可版本控制的代码。
2.1 基础设施即代码（IaC）核心概念
IaC 是一种通过机器可读的定义文件（而非手动流程）来管理和配置基础设施的实践。其核心价值在于：
- 版本控制：所有配置变更都记录在 Git 等 VCS 中，支持审计、回滚与协作。
- 幂等性：重复应用同一份配置，始终得到相同的基础设施状态。
- 自动化：消除手动操作，减少人为错误，加速交付周期。
- 一致性：开发、测试、生产环境使用相同的配置模板，避免环境漂移。
下表对比了传统手动管理与 IaC 管理 Prometheus 配置的差异：
| 维度 | 传统手动管理 | IaC 管理（Operator + CRD） |
|---|---|---|
| 配置存储 | SSH 登录后修改配置文件 | YAML 文件存储在 Git 仓库 |
| 变更记录 | 依赖人工记忆或变更单 | Git 提交历史，自动关联 PR |
| 回滚操作 | 手动恢复备份文件 | git revert + 重新 apply |
| 环境一致性 | 容易产生配置漂移 | 声明式模板保证一致 |
| 扩展性 | 大规模集群管理困难 | Operator 自动处理扩缩容 |
2.2 Prometheus Operator 架构与职责
Prometheus Operator 是一个 Kubernetes Operator，它利用 Kubernetes 的控制器模式，将 Prometheus 及其相关组件的部署、配置、生命周期管理自动化。它不再要求 SRE 直接操作 Prometheus 配置文件，而是通过操作 Kubernetes CRD 资源来声明期望状态。
下图展示了 Prometheus Operator 在 Kubernetes 集群中的核心架构与数据流：
Operator 的核心工作流程如下：
- 声明：SRE 通过
kubectl apply提交 CRD 资源 YAML（如 ServiceMonitor）。 - 监听：Operator 内部的控制器监听 API Server 上 CRD 资源的变化。
- 调和：Operator 根据 CRD 资源的期望状态，自动生成或更新 Prometheus 配置文件，并触发 Prometheus 实例的热加载。
- 反馈：Prometheus 实例状态被写回资源 Status 字段，形成闭环。
2.3 CRD 资源模型详解
CRD（Custom Resource Definition）是 Kubernetes 扩展 API 的机制。Prometheus Operator 定义了一组 CRD，将原本复杂的 Prometheus 配置抽象为 Kubernetes 原生资源。以下是三个最核心的 CRD：
| CRD 名称 | 用途 | 对应传统配置 | 典型作用域 |
|---|---|---|---|
| ServiceMonitor | 定义如何监控一组 Kubernetes Service | scrape_configs 中的 kubernetes_sd_configs |
Namespace / 集群 |
| PodMonitor | 定义如何监控一组 Pod（无需 Service） | scrape_configs 中的 kubernetes_sd_configs |
Namespace / 集群 |
| PrometheusRule | 定义告警规则和记录规则 | rules/*.yml 文件 |
Namespace / 集群 |
ServiceMonitor 和 PrometheusRule 就是该租户的“监控策略”。将这些 YAML 文件纳入 Git 仓库，并通过 CI/CD 管道进行审批和部署，就构成了“策略即代码”的基础。
以下是一个典型的 ServiceMonitor 示例，它声明了如何抓取名为 tenant-a-app 的 Service 的指标：
apiVersion: monitoring.coreos.com/v1
kind: ServiceMonitor
metadata:
name: tenant-a-monitor
namespace: tenant-a-ns
labels:
tenant: tenant-a
team: platform
spec:
selector:
matchLabels:
app: tenant-a-app
endpoints:
- port: metrics
interval: 30s
path: /metrics
namespaceSelector:
matchNames:
- tenant-a-ns这个 YAML 文件可以直接提交到 Git 仓库。当需要为租户 A 调整抓取间隔或添加新的端点时，只需修改此文件并重新 apply，Operator 会自动完成配置更新。
2.4 从 CRD 到 Prometheus 配置的转换逻辑
理解 Operator 如何将 CRD 转换为底层配置，对于调试和配额校准至关重要。下图展示了 ServiceMonitor 到 prometheus.yml 的映射关系：
labels 和 selector 必须严格匹配。如果 ServiceMonitor 的 selector.matchLabels 与目标 Service 的 metadata.labels 不一致，Operator 将无法发现目标，导致抓取配置缺失。这在多租户环境中尤其容易引发“配额未生效”的假象。
2.5 本章小结
- IaC 是策略即代码的哲学基础，强调声明式、版本化、自动化。
- Prometheus Operator 是 Kubernetes 上的 IaC 实现者，它将手动配置转化为控制器逻辑。
- CRD 资源模型（ServiceMonitor、PodMonitor、PrometheusRule）是 SRE 直接操作的“策略单元”，每个 YAML 文件代表一个可版本控制的配置片段。
- 理解 CRD 到
prometheus.yml的映射关系，是后续进行租户配额校准和回滚护栏设计的前提。