Kubernetes托管服务的等级协议通常以月度正常运行时间百分比呈现，例如99.95%。不少团队把这个数字当成一个遥不可及或必然达成的稳定状态，其实它背后是一套严格的故障时间计算、排除条款和赔偿机制。理解SLA不能只记住百分比，还要知道它针对的是哪一部分组件、按什么周期统计、哪些停机不纳入计算。
核心指标：月度可用性百分比与停机时间的关系
Kubernetes托管服务的SLA通常用“月度正常运行时间百分比”来表述，计算公式为：可用性百分比等于总分钟数减去不可用分钟数，再除以总分钟数，最后乘以100%。这里有一个容易被忽视的点：分母是自然月的总分钟数，而不是全年。因此同样99.95%的可用性，在30天月份里意味着不可用时间不超过21.6分钟，31天月份则对应约22.3分钟。
如果把99.95%直接换算成全年停机时间，结果约为4.38小时，但SLA通常不会按年度滚动统计。每个月的故障时间单独计算，某个月超过阈值只影响该月的赔偿资格，不会因为全年平均下来达标就免除责任。对于业务连续性评估来说，这种月度切分意味着即使前11个月都完全正常，最后一个月控制平面频繁抖动，仍然可能触发SLA违约。
不同百分比之间的差距也远比表面看起来大。99.5%的月度不可用时间约为216分钟，99.9%约为43.8分钟，99.95%约为21.9分钟。每提升一个9，故障预算会成倍下降。同一家托管服务提供区域集群和可用区集群时，区域集群通常承诺更高的可用性，因为它将控制平面副本分布在多个可用区，能够容忍单个可用区故障。
# 计算不同可用性百分比对应的月度停机时间
monthly_minutes = 30 * 24 * 60
for sla in [99.5, 99.9, 99.95, 99.99]:
downtime = monthly_minutes * (1 - sla / 100)
print(f"可用性 {sla}% 对应每月不可用约 {downtime:.1f} 分钟")
从代码输出可以直观看到，99.95%到99.99%之间只差0.04个百分点，但允许的月度不可用时间却从约21.6分钟压缩到约4.3分钟。因此评估托管服务SLA时，不能只看百分比数字本身，还要结合自己的业务对控制平面中断的容忍度，以及故障后恢复的平均时间。
控制平面与数据平面的责任边界
Kubernetes托管服务最重要的责任划分是控制平面与数据平面分离。控制平面通常包括API Server、etcd、scheduler和controller-manager，这些组件由云厂商负责运行并纳入SLA。数据平面则指用户工作节点、Pod、容器运行时、CNI网络插件和负载均衡器等，多数情况下由用户自行维护，不在控制平面SLA承诺范围内。
例如当API Server无法响应请求、etcd不可写入、kubectl命令超时时，通常属于控制平面不可用。但如果工作节点内存不足导致Pod被驱逐、节点池中所有虚拟机故障、或者用户部署的应用本身崩溃，这些都不计入托管服务SLA。有些云厂商也提供计算实例或负载均衡器的单独SLA，但这些需要和Kubernetes控制平面SLA分开查看。
这种边界意味着一个99.95%的控制平面SLA并不能保证整个集群99.95%可用。假设控制平面故障时间符合承诺，但工作节点经常因为资源争抢或配置错误而不可调度，那么用户实际感受到的集群可用性可能远低于99.95%。因此在容量规划和监控告警中，需要把控制平面可用性与数据平面可用性分别衡量，并针对数据平面建立自己的SLO。
排除条款：哪些情况不计入SLA
SLA文件中往往有冗长的排除条款，这些条款决定了即使发生长时间中断，云厂商也可能不承担责任。常见排除项包括计划内维护、客户配置错误、第三方软件故障、超出产品配额、安全事件导致的主动隔离、以及不可抗力因素。计划内维护通常会提前通知，但如果用户没有在维护窗口前调整工作负载，由此产生的故障不计入SLA。
客户配置错误是非常高频的排除理由。例如用户把节点池的网络策略配置成拒绝API Server访问、误删关键命名空间、在集群上运行消耗大量etcd资源的自定义控制器，都可能导致控制平面响应变慢或不可用。云厂商通常只负责托管组件的软件版本升级和基础设施修复，不负责审查用户提交的YAML配置是否合理。
第三方组件问题也经常被排除。比如用户使用第三方Ingress Controller或服务网格，这些组件运行在数据平面，故障不会触发控制平面SLA赔偿。同样，如果用户依赖的镜像仓库不可用、外部DNS服务异常、或者本地kubeconfig文件过期，都不属于托管服务故障。理解这些排除条款有助于在故障复盘时快速判断是否满足SLA索赔条件，避免在不符合条件的场景中浪费沟通成本。
主流托管服务SLA条款差异与赔偿机制
不同云厂商对Kubernetes托管服务的SLA设计存在明显差异。有些厂商将区域集群和可用区集群分别承诺不同可用性，区域集群通常要求至少三个可用区部署控制平面，可用区集群则可能只承诺99.5%。有些厂商对免费层或预览功能不提供SLA，用户需要升级到标准版或生产级集群才能获得赔偿资格。
赔偿机制基本采用服务信用额度形式，即按照故障时长比例返还当月费用的一定百分比。例如月度可用性低于99.95%但高于99.0%时，赔偿10%服务费；低于99.0%但高于95.0%时，赔偿25%；低于95.0%时赔偿50%或更多。服务信用通常只能抵扣后续账单，不能直接提现，并且有一个上限比例，一般不超过当月费用的100%。
申请赔偿通常需要用户主动提交工单，并提供故障起止时间、影响范围、请求ID等证据。云厂商会核对监控数据后确认责任归属。从实践角度看，SLA赔偿更多是一种服务承诺约束，对业务损失几乎没有补偿作用。真正的价值在于通过SLA条款反向了解云厂商对控制平面的可靠性设计，例如是否使用多副本etcd、是否跨可用区部署API Server、故障转移时间有无明确指标。
利用SLA指导集群高可用架构设计
既然托管服务只承诺控制平面，用户就需要在数据平面补齐高可用能力。首要策略是让工作节点分布在多个可用区，并为关键业务配置Pod拓扑分布约束。这样即使某个可用区的节点全部不可用，Pod也能在其他可用区继续运行。下面示例展示了一个要求Pod跨可用区均匀分布的Deployment片段。
apiVersion: apps/v1
kind: Deployment
metadata:
name: web-app
spec:
replicas: 6
selector:
matchLabels:
app: web
template:
metadata:
labels:
app: web
spec:
topologySpreadConstraints:
- maxSkew: 1
topologyKey: topology.kubernetes.io/zone
whenUnsatisfiable: DoNotSchedule
labelSelector:
matchLabels:
app: web
containers:
- name: web
image: nginx:1.25
resources:
requests:
cpu: 100m
memory: 128Mi
该配置通过topologySpreadConstraints声明了跨可用区的最大偏差为1，也就是每个可用区的副本数量差异不超过1个。如果只有两个可用区，6个副本会尽量按3比3分布；如果三个可用区，则按2比2比2分布。这样可以避免所有副本被调度到同一个可用区，提升数据平面可用性。
此外还需要对控制平面本身建立监控。虽然云厂商有内部监控，但用户无法直接接入，因此需要从外部视角探测API Server的可用性。可以定期执行kubectl get nodes或通过Prometheus Blackbox Exporter探测API Server健康端点，记录失败时长。这样在发生SLA争议时，用户手里就有独立于云厂商的故障时间数据，便于对比和索赔。
最后要定期演练故障转移。如果控制平面整体不可用，工作负载仍会继续运行，但无法执行新的调度、扩缩容和配置变更。此时需要评估业务是否能够容忍这种“只读”或“不可管理”状态。对于有严格管理面可用性要求的系统，可以考虑建设多集群架构，将不同集群分布在不同区域甚至不同云厂商，通过全局流量管理实现更高级别的容灾。
等级协议不是可靠性保证书，而是一份经过精确措辞的责任边界说明。读懂Kubernetes托管服务SLA的关键在于区分控制平面与数据平面、掌握月度可用性计算方法、逐条核对排除条款，并把这些约束转化为实际的架构设计动作。只有把纸面百分比落地为多可用区部署、外部监控和故障演练，SLA才能真正发挥指导作用。
Kubernetes托管服务服务等级协议可用性修改时间：2026-08-23 13:55:29