1、SLO 基础概念：SLO、SLI、SLA 的定义与区别，SLO 在 Kubernetes 中的重要性
1.1 核心术语定义
在可靠性工程体系中，SLO（Service Level Objective，服务等级目标）、SLI（Service Level Indicator，服务等级指标）与SLA（Service Level Agreement，服务等级协议）是三个紧密关联但层次不同的概念。理解它们的定义与区别，是构建 Kubernetes 集群 SLO 体系的第一步。
| 术语 | 英文全称 | 核心定义 | 典型示例（K8s 场景） |
|---|---|---|---|
| SLI | Service Level Indicator | 衡量服务质量的具体量化指标，是可观测的原始数据 | API Server 请求延迟 P99、Pod 就绪率、节点 CPU 利用率 |
| SLO | Service Level Objective | 基于 SLI 设定的目标阈值，是团队承诺达到的可靠性边界 | API Server P99 延迟 ≤ 200ms（月度 99.9% 达标） |
| SLA | Service Level Agreement | 与客户/用户签订的正式合同，包含未达标的惩罚条款 | 对外承诺 99.95% 可用性，否则赔付 10% 月费 |
记忆口诀：SLI 是「测量什么」，SLO 是「目标多少」，SLA 是「承诺什么」。SLO 通常比 SLA 更严格，为 SLA 提供缓冲空间。
1.2 三者的层级关系与区别
下图展示了 SLI → SLO → SLA 的递进关系，以及它们在 Kubernetes 集群可靠性管理中的位置：
1.3 SLO 在 Kubernetes 中的重要性
Kubernetes 集群是一个高度动态、多组件的分布式系统，其复杂性使得可靠性管理面临独特挑战。SLO 在 K8s 环境中扮演着以下关键角色：
- 量化可靠性边界：将「集群是否健康」从主观判断转化为客观指标。例如，定义
kube-apiserver的请求成功率 SLO 为 99.9%，而非模糊的「API 应该可用」。 - 指导容量规划：通过 SLO 的燃烧速率（Burn Rate）预警，提前发现资源瓶颈。例如，当 Pod 调度延迟 SLO 接近阈值时，触发节点自动扩缩容。
- 区分故障优先级：并非所有故障都同等重要。SLO 帮助团队聚焦于影响用户的关键路径。例如，控制面组件（etcd、API Server）的 SLO 优先级高于集群内非关键工作负载。
- 驱动自动化运维：SLO 是 Kubernetes 自动化操作（如 HPA、Cluster Autoscaler、Descheduler）的决策依据。没有 SLO，自动化缺乏明确的目标。
- 建立团队共识：SLO 为开发、运维、业务团队提供统一的可靠性语言，减少「这个故障算不算严重」的争论。
K8s 典型 SLO 示例：
# 控制面组件 SLO
- SLI: kube-apiserver 请求延迟 P99
SLO: ≤ 1s（月度 99.9% 时间达标）
- SLI: etcd 写入延迟 P99
SLO: ≤ 10ms（月度 99.95% 时间达标）
# 工作负载 SLO
- SLI: Pod 就绪率（Ready Pods / Total Pods）
SLO: ≥ 99.5%（滚动窗口 5 分钟）
- SLI: 节点 NotReady 比例
SLO: ≤ 1%（月度平均值）1.4 常见误区与避坑指南
| 误区 | 正确理解 |
|---|---|
| SLO 越高越好 | SLO 过高（如 99.999%）会导致成本爆炸、变更僵化。应基于用户满意度设定「足够好」的目标。 |
| SLO 等于 SLA | SLO 是内部目标，通常比 SLA 严格 10 倍以上，为 SLA 提供缓冲。例如 SLA 99.9%，SLO 设为 99.99%。 |
| 所有组件都需要 SLO | 只对用户可见的关键路径（Critical Path）定义 SLO。非关键组件（如日志收集器）可仅用 SLI 监控。 |
| SLO 设定后不可变 | SLO 应随业务发展、集群规模、用户期望定期调整。建议每季度评审一次。 |
K8s 实践警告：不要试图为集群内每一个 Deployment 都定义 SLO。优先覆盖控制面组件（etcd、API Server、Scheduler）和核心业务工作负载。过多的 SLO 会导致告警疲劳和运维成本失控。