📚 课程目录第4章 SLO与K8s联动架构

4. SLO与K8s联动架构：Prometheus → Alertmanager → Webhook → Operator/Job 闭环

SLO自愈的核心在于将SLO的燃烧速率与Kubernetes集群的自动化修复能力实时联动。本章构建的架构是一个典型的“监控-告警-触发-修复”闭环，确保SLO一旦偏离阈值，系统能在分钟级内自动执行预定义的恢复剧本。

4.1 整体架构总览

下图展示了从指标采集到自愈动作执行的完整数据流。所有组件均运行在Kubernetes集群内，形成松耦合的事件驱动管道。

4.2 核心组件职责

闭环中的每个组件承担明确的职责，并通过标准接口解耦。下表列出了各组件的核心功能与关键配置项。

组件	核心职责	关键配置 / 接口
Prometheus	采集SLI指标，计算燃烧速率，触发告警规则	Recording rules（burnrate）、Alerting rules（SLO violation）
Alertmanager	接收告警，执行路由、分组、抑制、静默	Route（severity: critical）、Receivers（webhook）
Webhook Receiver	解析告警JSON，转换为Kubernetes事件或CRD	HTTP endpoint、告警标签映射、事件类型判断
SLO Operator	监听自定义资源（SLOAction），执行持续修复逻辑	CRD（SLOAction）、Reconcile loop、幂等性控制
Kubernetes Job	执行一次性修复任务（如重启Pod、清理缓存）	Job template、环境变量、重试策略

4.3 数据流与事件驱动模型

整个闭环采用异步事件驱动架构，每个阶段通过HTTP或Kubernetes API进行通信。以下是标准的数据流步骤：

指标采集与告警触发：Prometheus 定期拉取 SLI 指标（如请求延迟、错误率），通过预定义的 burnrate 规则计算燃烧速率。当燃烧速率超过阈值（例如 2x 燃烧速率持续 1 小时），触发告警发送至 Alertmanager。
告警路由与分组：Alertmanager 根据告警标签（如 severity=critical、slo=api-availability）将告警路由到对应的 Webhook Receiver。分组机制防止告警风暴，合并相同 SLO 的连续告警。
事件转换与分发：Webhook Receiver 接收告警 JSON，解析出 SLO 名称、燃烧速率、时间窗口等关键字段。根据预配置的映射规则，决定将事件发送给 SLO Operator（创建/更新 SLOAction CR）还是直接创建 Kubernetes Job。
修复执行：SLO Operator 监听到 SLOAction CR 变化后，执行对应的自愈剧本（如滚动更新、扩容副本、回滚版本）。Kubernetes Job 则运行一次性脚本，完成后自动退出。
反馈闭环：修复动作完成后，Prometheus 继续采集指标。如果 SLO 燃烧速率恢复正常，告警自动解除；如果未恢复，Alertmanager 根据告警重复周期再次触发修复，形成持续自愈循环。

  关键设计原则： 所有修复动作必须幂等。Operator 和 Job 在执行前应检查当前状态，避免重复修复导致资源抖动。建议在 Webhook Receiver 层增加去重逻辑，基于告警指纹（fingerprint）过滤重复事件。

4.4 告警到修复的映射策略

并非所有SLO告警都需要立即执行修复。根据燃烧速率和持续时间，系统采用分级响应策略。下表展示了典型的映射规则。

燃烧速率	持续时间	严重级别	修复动作	执行方式
1x - 2x	> 2小时	Warning	扩容副本 + 日志分析	Kubernetes Job（一次性）
2x - 5x	> 30分钟	Critical	滚动重启 + 回滚至上一版本	SLO Operator（持续修复）
> 5x	> 5分钟	Pager	立即隔离 + 流量切换 + 人工介入	SLO Operator + 通知

实践建议： 在 Webhook Receiver 中维护一张映射表（可通过 ConfigMap 动态更新），避免硬编码修复逻辑。同时为每个修复动作设置最大执行次数和冷却时间，防止修复风暴。

4.5 组件间接口定义

为了保证各组件独立演进，接口必须标准化。以下是核心接口的简要定义。

Prometheus → Alertmanager：标准 Alertmanager API，告警格式为 JSON，包含 labels、annotations、startsAt、endsAt。
Alertmanager → Webhook：HTTP POST，Payload 为 Alertmanager webhook JSON，包含告警列表、状态（firing/resolved）、分组标签。
Webhook → Operator：通过 Kubernetes API 创建/更新 SLOAction 自定义资源。CR 定义包含 sloName、burnRate、actionType、parameters。
Webhook → Job：通过 Kubernetes API 创建 Job 对象，Job 模板中注入环境变量（如 SLO_NAME、BURN_RATE）。

# Webhook Receiver 接收的告警示例（简化）
{
  "receiver": "slo-webhook",
  "status": "firing",
  "alerts": [
    {
      "status": "firing",
      "labels": {
        "alertname": "SLOBurnRateCritical",
        "severity": "critical",
        "slo": "api-availability"
      },
      "annotations": {
        "burn_rate": "3.5",
        "window": "1h"
      },
      "startsAt": "2025-01-15T10:00:00Z"
    }
  ]
}

注意： Webhook Receiver 必须处理 resolved 状态的告警。当告警解除时，应通知 Operator 停止修复或标记修复完成，避免 Operator 在指标已恢复后继续执行不必要的操作。

4.6 架构优势与适用场景

该架构已在多个生产集群中验证，主要优势包括：

松耦合：每个组件可独立升级、扩缩容，故障隔离性好。
可观测性：每个环节都有日志和指标输出，便于排查修复失败原因。
策略灵活：通过修改 Webhook 映射表或 Operator 的 CRD，可快速调整修复策略，无需重启整个管道。
安全可控：修复动作通过 Kubernetes RBAC 控制，Operator 和 Job 使用最小权限 ServiceAccount。

适用场景包括：SLO 驱动的自动扩缩容、故障 Pod 自动重启、版本回滚、缓存预热、以及基于燃烧速率的渐进式修复。