2. 系统架构总览：整体架构图、核心组件与数据流

本章从全局视角剖析 Prom告警驱动证书轮换调度器 的系统架构。整个系统围绕“告警感知 → 调度决策 → 资源预留 → 证书轮换”的闭环设计，将 Prometheus 生态的告警能力与 Kubernetes 调度器的资源管理能力深度整合。下面依次介绍整体架构图、四个核心组件及其职责，以及贯穿系统的关键数据流。

2.1 整体架构图

下图展示了系统的核心拓扑结构。Prometheus 负责采集证书过期指标并触发告警；Alertmanager 对告警进行路由、抑制与分组后，将告警通知发送至调度器；调度器根据告警内容计算资源预留策略，并操作资源池完成预留；最终由证书轮换执行器（或外部工具）在预留的资源上完成证书更新。

2.2 核心组件

系统由四个核心组件构成，每个组件承担明确的职责，并通过标准接口进行通信。下表总结了各组件的功能定位与关键特性：

2.3 核心组件详解

2.3.1 Prometheus — 证书过期感知层

Prometheus 通过以下方式采集证书过期信息：

• Blackbox Exporter：探测 TLS 端点证书有效期。
• cert_exporter：直接读取本地证书文件过期时间。
• Kubelet 指标：Kubernetes 节点证书状态。

告警规则示例：

groups:
- name: certificate_alerts
  rules:
  - alert: CertificateExpiringSoon
    expr: (cert_expiry_days < 30) and (cert_expiry_days > 0)
    for: 5m
    labels:
      severity: warning
    annotations:
      summary: "证书 {{ $labels.common_name }} 将在 {{ $value }} 天后过期"

2.3.2 Alertmanager — 告警治理层

Alertmanager 负责对 Prometheus 发送的告警进行治理：

• 分组：将同一证书的多次告警合并为一条通知。
• 抑制：当证书已进入轮换流程时，抑制后续重复告警。
• 路由：根据告警标签（如 severity、cluster）将告警发送到对应的调度器 Webhook。

Webhook 配置片段：

receivers:
- name: 'cert-scheduler'
  webhook_configs:
  - url: 'http://cert-scheduler:8080/webhook'
    send_resolved: true

2.3.3 证书轮换调度器 — 决策与编排层

调度器是整个系统的决策核心，主要工作流程：

1. 接收告警：解析 Alertmanager 发送的 Webhook JSON 负载。
2. 评估资源需求：根据证书类型、服务规模、历史数据计算所需资源量。
3. 预留资源：向资源池发起预留请求，确保轮换时有充足资源。
4. 触发轮换：资源就绪后，向证书轮换执行器下发轮换指令。

2.3.4 资源池 — 资源抽象与管理层

资源池将底层基础设施资源抽象为可预留的单元，支持：

• CPU 与内存预留：为证书轮换过程中的临时 Pod 或容器预留计算资源。
• 网络端口预留：避免端口冲突，特别是 TLS 端口重新绑定场景。
• 存储卷预留：确保证书文件写入时有足够的存储空间。

2.4 数据流

系统数据流分为两条主线：告警驱动流 和 资源预留流。下面用第二个 SVG 图展示数据在组件间的传递细节。

2.5 数据流关键阶段说明

结合上述时序图，数据流可归纳为七个关键阶段：

2.6 架构设计原则

• 松耦合：各组件通过标准接口（HTTP/gRPC）通信，可独立升级或替换。
• 可观测性：Prometheus 不仅作为告警源，也负责采集调度器、资源池的运行指标。
• 幂等性：调度器处理重复告警时，资源预留请求具有幂等性，不会重复预留。
• 资源隔离：资源池为每个轮换任务分配独立资源，避免相互影响。