Kubernetes 可扩展性保证全解析：SIG Scalability 的 SLI/SLO 体系与实践指南

Kubernetes 可扩展性保证全解析：SIG Scalability 的 SLI/SLO 体系与实践指南

【免费下载链接】communityKubernetes Community Documentation项目地址: https://gitcode.com/GitHub_Trending/com/community

在 Kubernetes 中，"集群能撑住多大规模"并非一句空话，而是由一套可量化、可测试、可追溯的指标体系来定义。本文以 Kubernetes 社区仓库中 sig-scalability/slos/slos.md 为核心，系统讲解 Kubernetes 官方如何定义可扩展性与性能保证（SLI/SLO）、这些保证的适用前提（"你承诺，我承诺"框架）、稳态 SLI/SLO 的完整清单及每一项的度量口径，并结合 阈值定义文档 与各 SLI 明细文档给出可落地的配置与测量方法。读完本文，你将能准确理解 Kubernetes 官方承诺的边界（如 API 调用延迟 99 分位 ≤ 1s、无状态 Pod 启动延迟 ≤ 5s），知道自己的集群在什么条件下才能享有这些保证，并能复现其度量方法。

一、Kubernetes 保证什么：可扩展性与性能的承诺框架

可扩展性和性能特性是 Kubernetes 最重要的属性之一。无论是普通用户、集群运维者还是管理员，都期望集群在这些方面得到某种程度的保证。slos.md 的使命就是把这些保证系统化、文档化，明确"Kubernetes 到底承诺了什么"。

需要强调的是，这一承诺并不是无条件的。官方文档采用了一个非常直白的契约模型：

如果你承诺：

• 正确配置你的集群（correctly configure your cluster）
• "合理地"使用可扩展性特性（use extensibility features "reasonably"）
• 将集群负载保持在推荐限制之内（keep the load in the cluster within recommended limits）

那么我们就承诺：你的集群是可扩展的（your cluster scales），即所有 SLO 均被满足（all the SLOs are satisfied）。

这个"你承诺，我承诺"（you promise, we promise）的框架是理解整套 SLO 体系的钥匙：Kubernetes 不会在任何配置、任何负载下都给出保证，而是在一组明确前提被满足时，才承诺稳态性能指标达标。

二、如何定义可扩展性：SLI 与 SLO 的两层概念

Kubernetes 的可扩展性定义建立在两个业界通用概念之上：

• 服务等级指标（SLI，Service Level Indicator）：定义"测量什么、如何测量"。SLI 是通用的，它只描述度量方式本身。
• 服务等级目标（SLO，Service Level Objective）：在 SLI 之上给出具体的目标值。满足 SLO 往往依赖一些特定前提条件（如集群配置、可扩展性特性使用方式、集群负载）。

SLI 与 SLO 的区别在于：SLI 可以是通用的（无论集群如何搭建都能度量），而 SLO 只在默认安装（default installation）等受控场景下提供。

2.1 SLI/SLO 必须具备的四个属性

官方明确要求所有 SLI/SLO 满足以下性质：

属性	含义
精确且定义良好（precise and well-defined）	保证用户和 Kubernetes 开发团队对"承诺了什么"有完全一致的理解，杜绝歧义
相互一致（consistent with each other）	各 SLI/SLO 之间使用相同的术语、相同的概念，避免口径冲突
面向用户（user-oriented）	首先，SLO 必须是用户真正关心的；其次，表述必须能被不了解系统内部实现的人理解，不能依赖晦涩的内部知识
可测试（testable）	理想情况下 SLI/SLO 应在所有运行中的集群可度量；若某些指标无法度量或度量代价过高（如系统资源开销过大），则退而求其次使用基准测试（benchmark）。这意味着并非每个 SLO 都能转化为 SLA（服务等级协议）

2.2 SLI 与 SLO 的关系

由于 SLI 是通用的、SLO 才提供具体保证，二者是分层的关系：先定义通用的度量口径（SLI），再在特定前提下给出目标值（SLO）。同时，满足 SLO 可能依赖以下具体前提：

• 集群配置（cluster configuration）
• 用户对 Kubernetes 可扩展性特性的使用方式
• 集群上的负载（load on the cluster）

官方同时表示：系统仍在持续扩展 SLI/SLO 的覆盖范围，以更好地反映用户期望；此外未来可能引入**仅供开发者使用（internal，for developers only）**的 SLI，用于理解系统性能特性，但不对用户提供任何保证。

三、满足 SLO 的前提条件

3.1 环境（集群配置）要求

为了让 SLO 得以满足，系统必须运行在满足以下标准的集群环境中：

• 运行单个或多个**规模适当（appropriately sized）**的 master 机器
• 事件（Events）存储在与主数据隔离的独立 etcd 实例（或集群）中
• 所有 etcd 实例均运行在 master 机器上
• Kubernetes 版本至少为 X.Y.Z（具体版本号由发布节奏决定）
• 其他必要条件（原文档标注为__TODO: Document other necessary configuration.__，即仍在完善中）

从实践角度看，"事件存入独立 etcd"这一条尤其值得运维者关注：事件对象数量庞大且写入频繁，若与核心对象混用同一 etcd，会显著影响 API 调用延迟等指标。

3.2 可扩展性阈值（Scalability Thresholds）

要让集群具备享受 SLO 的资格，用户集群中的对象数量还必须满足 thresholds 文件 中定义的阈值。该文件位于仓库sig-scalability/configs-and-limits/thresholds.md，是 SLO 能否成立的关键配套文档。

3.2.1 可扩展性包络（Scalability Envelope）概念

阈值文档指出，Kubernetes 支持的各种配置组合构成了一个可扩展性包络（Scalability Envelope）——一个多维空间中"集群可被支持配置"的边界区域：

包络具有以下性质：

1. 它不是立方体：各个维度之间并非相互独立；
2. 它不是凸的（NOT convex）；
3. 沿某一维度推进越远，其他维度上的横截面（cross-section）就越小——即维度之间存在此消彼长的关系；
4. 它是有界的（bounded）；
5. 它可以分解为更小的子包络（decomposable into smaller envelopes）。

3.2.2 阈值的使用注意事项

在套用阈值表之前，必须先理解以下四点：

1. 多数情况下，阈值并非硬性上限（NOT hard limits）——超出限制只会导致性能下降，并不意味着集群立即崩溃；
2. 许多集群级（cluster scope）阈值是针对最大规模集群给出的，对于更小的集群，限制会按比例更低；
3. 阈值可能随 Kubernetes 版本变化（期望只增不减）；下表针对 Kubernetes head 版本给出；
4. 阈值基于OSS 发行版 + sharded etcd的配置假设；自 2025 年 12 月起，官方发布阻塞可扩展性测试运行在kops之上。

3.2.3 与 API Server 和 etcd 存储相关的阈值（内置资源类型）

数量项	阈值（scope=resource type）	阈值（scope=cluster）
对象数量（非 Event）	150,000	TBD
对象数量（Event）	1,000,000	n/a
单对象大小（Size per object）	1.5MB	1.5MB
总大小（Total size）	1.5GB	TBD

3.2.4 按资源类型划分的阈值

数量项	阈值（scope=namespace）	阈值（scope=cluster）
#Nodes（节点数）	n/a	5000
#Namespaces（命名空间数）	n/a	10000
#Pods（Pod 数）	3000	150000
#Pods per node（单节点 Pod 数）	min(110, 10×核数)	min(110, 10×核数)
#Services（Service 数）	5000	10000
#All service endpoints（全部 Service 端点）	TBD	TBD
#Endpoints per service（单 Service 端点数）	250	n/a
#Secrets	TBD	TBD
#ConfigMaps	TBD	TBD
#Deployments	2000	TBD
#DaemonSets	TBD	TBD
#Jobs	TBD	TBD
#StatefulSets	TBD	TBD
#AccessTokens（访问令牌数）	2000	2000
#AccessTokens verifications（令牌校验 QPS）	5000 QPS	5000 QPS

3.2.5 依赖环境/云提供商的阈值（非穷尽列表）

数量项	阈值（scope=namespace）	阈值（scope=cluster）
#Ingresses	TBD	TBD
#PersistentVolumes	n/a	TBD
#PersistentVolumeClaims	TBD	TBD
#PersistentVolumeClaims per node	TBD	TBD

实践提示：#Pods per node = min(110, 10×核数)是一条非常具体的可执行规则，规划节点规格时即可据此推算单节点 Pod 容量上限。而#Endpoints per service = 250直接约束了大型工作负载的 Service 后端数量设计。

3.3 Kubernetes 可扩展性特性（Extensibility）的使用要求

要满足 SLO，用户还必须"明智地"使用可扩展性特性。官方给出的精确表述仍在完善中，但已明确包含以下方向：

• Webhook 必须提供高可用（high availability）和低延迟（low latency）：webhook 挂在 API 请求路径上，其可用性与延迟直接决定 API 调用 SLO 能否达成；
• CRD 与 CR 必须保持在阈值之内：自定义资源对象同样占用 etcd 与 apiserver 资源，需遵守对象数量/大小阈值。

3.4 两个附加前提：集群可用性与 Churn 上限

除了上述条件，官方还引入了两个必须满足的附加前提，否则 SLO 无从谈起：

Prerequisites: 1. Kubernetes cluster is available and serving. （Kubernetes 集群可用且正在提供服务） 2. Cluster churn is <= 20, where churn is defined as: （集群变更率 <= 20，其中 churn 定义为：） churn = #(Pod spec creations/updates/deletions) + #(user originated requests) in a given second （churn = 每秒内 Pod spec 创建/更新/删除次数 + 每秒用户发起请求数）

原文档同时标注了__TODO: Cluster churn should be moved to scalability thresholds.__，即集群变更率指标未来会被迁移到可扩展性阈值文档中统一管理。这条前提的意义在于：即使对象总数不超阈值，如果短时间内变更/请求过于密集，系统同样无法保证稳态指标。

四、Kubernetes SLI/SLO 总览

官方明确指出：当前已有的 SLI/SLO 足以保证"集群不会彻底宕机"，但在系统许多领域仍未达到用户期望，官方正在积极扩展覆盖范围。

4.1 稳态 SLI/SLO（Steady State SLIs/SLOs）

以下表格是整套体系的核心，完整列出了官方（Official）与进行中（WIP）的稳态指标。所有指标的统计口径均为"过去 5 分钟的 99 百分位"（measured as 99th percentile over last 5 minutes），SLO 目标则按"每集群日（per cluster-day）"衡量。

状态	SLI（指标定义）	SLO（目标）	明细文档
Official（官方）	单对象变更型（mutating）API 调用处理延迟，按每个（resource, verb）组合，取过去 5 分钟 99 百分位	默认 Kubernetes 安装下，对每个（resource, verb）组合（排除虚拟资源、聚合资源与自定义资源定义 CRD），每集群日 99 百分位 ≤ 1s	api_call_latency.md
Official（官方）	非流式只读（non-streaming read-only）API 调用处理延迟，按每个（resource, scope）组合，取过去 5 分钟 99 百分位	默认安装下，对每个（resource, scope）组合（排除虚拟/聚合资源与 CRD），每集群日 99 百分位：(a) 若scope=resource则 ≤ 1s；(b) 否则（scope=namespace或scope=cluster）≤ 30s	api_call_latency.md
Official（官方）	可调度无状态（stateless）Pod 启动延迟，排除镜像拉取与 init 容器运行时间，从 Pod 创建时间戳计到所有容器上报 started 且经 watch 观察到，取过去 5 分钟 99 百分位	默认安装下，每集群日 99 百分位 ≤ 5s	pod_startup_latency.md
WIP（进行中）	可调度有状态（stateful）Pod 启动延迟，排除镜像拉取、init 容器、卷供应（延迟绑定模式）与卷卸载/分离（若前一 Pod 需要），取过去 5 分钟 99 百分位	默认安装下，每集群日 99 百分位 ≤ X，X 取决于存储提供商	pod_startup_latency.md
WIP（进行中）	集群内负载均衡机制（如 iptables）编程延迟，从 Service spec 或其ReadyPod 列表变化计到反映到负载均衡机制，跨所有 programmer 聚合，取过去 5 分钟 99 百分位	默认安装下，每集群日 99 百分位 ≤ X	network_programming_latency.md
WIP（进行中）	DNS 实例编程延迟，从 Service spec 或其ReadyPod 列表变化计到反映到该 DNS 实例，跨所有 DNS 实例聚合，取过去 5 分钟 99 百分位	默认安装下，每集群日 99 百分位 ≤ X	dns_programming_latency.md
WIP（进行中）	集群内网络延迟，由单个 prober Pod 每秒 ping "null service" 测得，取过去 5 分钟 99 百分位	节点间 RTT ≤ Y 的默认安装下，每集群日（所有 prober Pod 的 99 百分位的 99 百分位）≤ X	network_latency.md
WIP（进行中）	集群内 DNS 延迟，由单个 prober Pod 每秒对 "null service" 做 DNS 查询测得，取过去 5 分钟 99 百分位	节点间 RTT ≤ Y 的默认安装下，每集群日（所有 prober Pod 的 99 百分位的 99 百分位）≤ X	dns_latency.md
WIP（进行中）	首包延迟（First Packet Latency，毫秒）：客户端向 Service 发起 TCP 连接（发送 SYN 包）到收到来自 Service 后端的第一个包（典型为三次握手中的 SYN-ACK 包），跨所有节点实例聚合，取过去 5 分钟 99 百分位	节点间 RTT ≤ Y 的默认安装下，每集群日（所有节点的 99 百分位的 99 百分位）≤ X	first_packet_latency.md
WIP（进行中）	到 Service 的 TCP 连接成功数据传输速率，以 bps、kbps、Mbps 或 Gbps 计量，跨节点内所有到 Service 的连接聚合，取过去 5 分钟 99 百分位	节点间 RTT ≤ Y 的默认安装下，每集群日（所有节点的 99 百分位的 99 百分位）≤ X	throughput.md

脚注 [1]：为了可视化目的，"每集群日"将采用滑动窗口（sliding window）；但就 SLO 本身而言，它实质上表示"每天中好分钟数（fraction of good minutes per day）的占比"保持在阈值之内。

4.2 其他 SLI（Other SLIs）

以下指标同样被定义，但尚未给出 SLO 目标，主要用于内部性能理解与问题定位：

状态	SLI（指标定义）	明细文档
WIP	Watch 延迟：对每种资源，从对象存入数据库到准备好发送给所有 watcher 的时间，取过去 5 分钟 99 百分位	watch_latency.md
WIP	Admission 延迟：每种 admission 插件类型的延迟，取过去 5 分钟 99 百分位	api_extensions_latency.md
WIP	Webhook 调用延迟：每种 webhook 类型的调用延迟，取过去 5 分钟 99 百分位	api_extensions_latency.md

五、API 调用延迟 SLO 详解（Official）

API 调用延迟是整套体系中最核心的官方承诺，其明细见 api_call_latency.md。

5.1 精确度量口径（Definition）

处理时间（processing time）的定义是：从 apiserver 收到请求的时刻，到响应的最后一个字节发送给用户的时刻，排除webhook 以及 API 优先级与公平性（priority & fairness）队列等待时间所带来的延迟。

变更型 API 调用（mutating API calls）指：POST、PUT、DELETE 和 PATCH。

非流式只读 API 调用（non-streaming read-only API calls）指：未设置watch=true的 GET 请求（在 Kubernetes 内部实际会翻译为 GET 和 LIST 两类调用）。

请求作用域（scope）分三种：

• resource：请求针对单个对象；
• namespace：请求针对单个命名空间内的对象；
• cluster：请求跨多个命名空间（spawns objects from multiple namespaces）。

关于 30s 阈值的历史背景（脚注 5）：历史上scope=namespace的 LIST 阈值曾被设为 5 秒。该阈值是在 Kubernetes 尚不支持如今规模、单个命名空间内也没有成千上万（甚至更多）同类型对象的年代选定的。考虑到用户能够接受列出数万个对象耗时超过 5 秒，官方根据使用模式的变化将限制调整到了 30 秒。

5.2 用户故事（User Stories）

• 作为 vanilla Kubernetes 用户，我希望得到"API 调用多久能返回响应"的保证；
• 作为 Kubernetes 集群管理员，如果我知道 apiserver 外部依赖（如自定义 admission 插件、优先级与公平性配置、webhook）的特征，我希望能够向集群用户提供 API 调用延迟的保证。

5.3 设计考量与边界（Other Notes）

• 无法给出无条件的通用保证：集群管理员被允许注册自定义 admission 插件、webhook 以及优先级与公平性配置，这些都不受 Kubernetes 控制，且显然会影响 API 调用延迟；
• 因此，SLI 被定义为通用的（无论集群如何搭建均可度量），但 SLO仅对默认安装（default installations，即 apiserver 行为受控的场景）提供。这不会给用户造成"无论集群如何搭建和安装什么都能获得保证"的错觉；
• API 调用几乎贯穿 Kubernetes 所有非平凡工作流，因此该指标是其他更复杂 SLI/SLO 的基础构件（building block）；
• 只读 API 调用延迟的 SLO 阈值有较大缓冲空间：实际上请求延迟应与工作量（即给定作用域内某种类型对象的数量）成正比，再加上一定的常量开销。为了更好追踪性能，未来可能引入纯内部 SLI——"每对象延迟（latency per object）"，但这不在近期计划内；
• 再次强调：SLO 仅在 thresholds 文件 中定义的阈值被满足时才受保证。这一点对该 SLO 尤为重要，因为它限制了 LIST 调用返回的对象数量。

5.4 注意事项（Caveats）

• 编码无关性：SLO 必须独立于用户请求所使用的编码而成立，这要求测试时注意客户端类型的混合。但官方假设所有core组件都使用protocol buffers与 apiserver 通信；
• 缓存数据：对于 GET 请求，用户可以选择接收可能过期的数据（从缓存提供服务），SLO 也必须独立于该选择成立，这使得测试中请求的选择需要格外谨慎；
• 排除项：SLI 与 SLO 排除了不受 Kubernetes 控制的因素，具体为 webhook（1.23+）与 API 优先级及公平性队列等待时间（1.27+）引入的延迟。

5.5 待办（TODOs）

未来可能将non-namespaced（非命名空间级）资源作为独立的分桶处理；不过若其数量与namespaced资源相当，则可能没有意义。测试场景（Test scenario）在文档中标注为__TODO。

六、Pod 启动延迟 SLO 详解（Official + WIP）

Pod 启动延迟的完整口径见 pod_startup_latency.md。这是第二个官方（Official）SLO：无状态 Pod 启动延迟每集群日 99 百分位 ≤ 5s。

6.1 关键定义

• 可调度 Pod（schedulable pod）：无需其他任何组件介入即可立即调度、且不会引发任何抢占（preemption）的 Pod；
• 无状态 Pod（stateless pod）：不挂载除 secrets、config maps、downward API 和 empty dir 之外来源卷的 Pod；
• 有状态 Pod（stateful pod）：至少挂载一个来自其他来源的卷的 Pod。

6.2 什么被纳入、什么被排除

只有可调度 Pod 才计入该 SLI：

• 如果集群没有空间放置 Pod，Kubernetes 无能为力（这是 Cluster Autoscaler 的任务，应为其建立独立的 SLI/SLO）；
• 如果放置 Pod 需要抢占其他 Pod，这可能严重依赖应用本身（例如其优雅终止周期），官方不希望这部分计入该 SLI。

显式区分无状态与有状态 Pod：

• 启动有状态 Pod 需要挂载卷，这耗时不可忽略且不完全取决于 Kubernetes。不过卷挂载虽依赖存储提供商，却不是应用特有的，因此仍纳入 SLI（尽管具体 SLO 阈值可能取决于存储提供商）；
• 显式排除卷供应时间（delayed volume binding 模式）：卷供应可视为有状态工作负载生命周期中的一次引导（bootstrapping）操作，只在最开始发生一次，而非每次创建 Pod 都发生；
• 显式排除卷卸载与分离时间（若卷此前挂载到另一个 Pod）：这与排除需要抢占的 Pod 是对称的——都属于"清理前任"性质的操作。

显式排除镜像拉取时间：镜像拉取高度依赖镜像的位置、镜像仓库性能特征（如吞吐量）、镜像大小等，这些都不受 Kubernetes 控制且会显著影响 SLI，故直接排除。

显式排除 init 容器运行时间：同样高度依赖应用本身（与 Kubernetes 无关）。

6.3 "何时算启动完成"的语义

"Pod 何时应被视为已启动"的答案并不直观。官方选择的语义是**"所有容器都被上报为 started，且经 watch 观察到"**，理由如下：

1. 要求所有容器都启动（而非仅第一个）：确保诸如 Pod 内容器启动线性化之类的潜在回归能被该 SLI 捕获；
2. 不要求所有容器都在运行：若某个容器在最后一个容器启动前已经结束，也是可以的，只需所有容器都被启动过（至少一次）；
3. 不依赖就绪检查（readiness checks）：就绪检查高度依赖应用——如果应用初始化需要几分钟才开始响应就绪检查，这不应当计入 Kubernetes 的性能；
4. watch 上报至关重要：即使应用已启动，Kubernetes 中许多控制循环也要先观察到该状态才会触发。如果 kubelet 因故无法上报状态，系统其他部分将无从得知；
5. 由于 watch 在 Kubernetes 中处于核心地位（许多控制循环由特定 watch 事件触发），观察 Pod 状态本身也是 SLI 的一部分——这正是下一个控制循环可能被触发的时刻。

6.4 待办与测试注意

• 重新审视是否要将"watch pod 状态"部分包含进 SLI；
• 考虑为 Pod 删除延迟创建 SLI（对有状态 Pod，必须先从节点分离 RWO 卷才能挂载到另一节点，慢删除可能阻塞启动）；
• 测试中容易排除需要抢占或卷卸载的 Pod（环境完全可控），但生产环境如何正确排除仍需解决；
• 测试注意：当集群节点跨多个可用区时，预置卷应在各可用区间均衡分配，避免因单可用区资源不足导致 Pod 不可调度。

七、网络与 DNS 编程延迟 SLI（WIP）

这两项指标度量的是"变更何时真正生效"，明细见 network_programming_latency.md 与 dns_programming_latency.md。

7.1 指标定义与用户故事

• 网络编程延迟：从 Service spec 或其ReadyPod 列表变化，到该变化反映到集群内负载均衡机制（如 iptables）的时间，跨所有 programmer 聚合。
• DNS 编程延迟：同样的起点，到变化反映到该 DNS 实例的时间，跨所有 DNS 实例聚合。

对应的用户故事：

• 新后端（backends）多久能成为集群内负载均衡的目标；
• 已删除（或不健康）的后端多久能从负载均衡中移除；
• Service spec 的变化（包括创建）多久能反映到负载均衡；
• 集群内 DNS 多久能开始/停止将 Service 名解析到新启动/已移除的后端；
• 无头服务（headless service）主机名多久能解析到新后端。

7.2 设计取舍（Other Notes）

• 有意聚焦集群内（in-cluster）负载均衡：外部负载均衡明显是云提供商特定的，难以设定 SLO；未来可以按几乎相同的方式为外部负载均衡制定 SLI，以保持一致；
• 曾考虑"从 Pod 创建到生效"的端到端 SLI，但因应用特定性而被否决——引入 SLO 将不可能；
• DNS SLI 聚焦集群内 DNS，外部 DNS 解析取决于云提供商或集群运行环境；
• DNS 发布的 SLI 应保持与记录数量无关：例如在拥有数千个 Pod 的无头服务中，第一个 Pod 与最后一个 Pod 被分配 IP 到 DNS 在 A/AAAA 记录中提供该 IP 的时间差应统计上一致。

7.3 聚合方式的深意（Caveats）

SLI 跨所有 programmer/DNS 实例聚合（所有样本进入一个大池子，百分位从整个池子计算）。这正符合终端用户视角：即便一小部分 programmer 完全无响应（其他都很快），也是可接受的——在规模变大时这种现象必然出现。若改为在 SLI 层面聚合（"从 99% 的 programmer 可见"），为判断每次变化何时在 99% 的 programmer 中生效，就必须按变更粒度追踪指标，这在计算上极不现实。

7.4 测量方法：如何实现该 SLI

网络编程延迟的测量方法并不直观，官方给出了完整的实现蓝图（DNS 编程延迟的测量方法与之完全相同，可参考 network_programming_latency.md#how-to-measure-the-sli）：

1. 假设集群内负载均衡编程基于 Kubernetes 的Endpoints对象；
2. 为Endpoints对象引入一个专用 annotation（名称待定）；
3. Endpoints controller 在更新某个Endpoints对象时，将该 annotation 的值设置为触发此次更新的变更时间戳：
   • 对 Pod 在Ready/NotReady之间的状态转换，时间戳就是 Pod 条件（condition）的一部分；
   • Service 更新待定（理想方案是在对象 metadata 中新增LastUpdateTimestamp字段，紧邻已有的CreationTimestamp。数据在存储层已存在，传播并不困难）；
4. 集群内负载均衡 programmer 在编程完成后导出一个 Prometheus 指标，操作延迟定义为"完成时间戳 − 新引入 annotation 记录的时间戳"。

该测量方法存在三个已知注意事项：

1. 单个Endpoints对象可能批量合并多次 Pod 状态转换：此时选择最早的那个（不暴露所有时间戳，避免对象理论上无界增长）。这会使指标不精确，但批处理周期相对整个端到端流程较小；
2. 单个 Pod 可能在批处理周期内多次转换状态：为此将在 Endpoints controller 中增加缓存，缓存每个 Pod 首次观察到的转换时间戳，controller 将 Pod 纳入Endpoints更新时清空缓存（与上面"选择最早更新"一致）。初期可能直接忽略这一事实；
3. 组件可能掉出 watch 窗口历史而错过部分 watch 事件：当单个对象在期间多次变化时会成为问题（否则 informer 会在重新 list 时送达 handler）。该情况只发生在组件处理事件过慢（此时已反映在指标中）或 kube-apiserver 重启之后。官方决定忽略该问题，以避免不必要的复杂度。

八、集群内网络与 DNS 延迟 SLI（WIP）

8.1 指标定义

• 网络延迟：由单个 prober Pod 每秒 ping "null service" 测得的集群内网络延迟；
• DNS 延迟：由单个 prober Pod 每秒对 "null service" 做 DNS 查询测得的集群内 DNS 延迟。

两者均取过去 5 分钟 99 百分位；SLO 前提是"默认安装 + 节点间 RTT ≤ Y"，目标为"每集群日（所有 prober Pod 的 99 百分位的 99 百分位）≤ X"。详见 network_latency.md 与 dns_latency.md。

8.2 DNS 双查询口径

DNS 延迟 SLI 实际包含两次 DNS 查询，并作为两个独立 SLI 跟踪：

1. 查询/etc/resolv.conf中的 nameserver IP；
2. 查询kube-system/kube-dns的 Service IP。

引入两个 SLI 的目的是测量节点本地缓存（node-local caching）带来的影响。

8.3 设计考量

• 无法在一般场景下给出保证（集群管理员可任意配置集群），因此 SLI 保持通用，SLO 仅针对默认安装且附加"节点间 RTT ≤ Y"的要求；
• 网络延迟是应用性能（尤其在微服务世界）最关键的方面之一，必须提供保证；
• 选择 prober Pod 方案的原因：
  • 它代表用户导向的端到端流程（涉及集群内网络编程机制的延迟，如 iptables）；官方曾考虑把 DNS 解析也纳入，但决定不混合二者（长期应再考虑合并）；
  • 在所有可运行 prober 的集群中都易于测量（例如测量某节点上所有 Pod 的请求延迟需要额外的插桩，如为每个 Pod 挂 sidecar，开销在许多场景不可接受）；
  • 与应用无关。

8.4 注意事项（Caveats）

• SLI 针对 prober Pod 表述（用户在 SLO 层面才做聚合），这提供了非常相似的保证且便于测量；
• 节点间 RTT 差异：若节点处于不同拓扑（如不同的 GCP zone），RTT 可能显著不同。由于 Kubernetes 尚未原生支持拓扑感知服务路由（topology-aware service routing），官方明确承认：跨拓扑时 ping 不同端点结果可能差异显著；
• prober 上报逻辑简单、资源开销可忽略，但没有现成组件可挂载该功能（如 kube-proxy 运行在主机网络），因此将创建一组专用 prober Pod，数量与集群规模成正比；
• 集群中并无现成的 "null service"，管理员需要自行部署一个才能在实际集群中度量该 SLI；测试中则会在 prober Pod 之上创建一个 Service。

8.5 待办

DNS 延迟只是关键指标之一，另一类是"丢弃率（drop rate）"或"超时率（timeout rate）"；后者更难测量/采样，官方计划单独处理，避免阻塞本 SLI 的推进。

九、首包延迟与吞吐量 SLI（WIP）

这两项指标聚焦数据面（data plane）的真实网络体验，明细见 first_packet_latency.md 与 throughput.md。

9.1 首包延迟（Time To First Packet）

定义：从客户端向 Service 发起 TCP 连接（发送 SYN 包）到客户端收到来自 Service 后端的第一个包（典型为三次握手中的 SYN-ACK 包）的延迟（毫秒），跨所有节点实例聚合，取过去 5 分钟 99 百分位。

设计动机：首包延迟比完整的连接建立时间更贴近用户感知——它反映初始感知延迟。即使完整握手稍慢，只要首包延迟快，应用就会给人"很快"的感觉。

测量方法：需要精确的时间戳记录客户端发送 SYN 与收到首包的时刻，可通过两种途径：

• 客户端侧：在应用代码或基准测试应用中测量；
• 网络设备侧：在数据路径上的节点进行报文检测与分析。

注意事项：地理距离、路由与网络拥塞等网络延迟因素会影响结果；即使服务器响应迅速，网络上其他流量也可能延迟 SYN-ACK；客户端侧处理与网络条件也会引入小幅延迟。

9.2 吞吐量（Throughput）

定义：到 Service 的 TCP 连接成功数据传输速率，以 bps、kbps、Mbps 或 Gbps 计量，跨节点内所有到 Service 的连接聚合，取过去 5 分钟 99 百分位。

用户故事：用户希望确认应用在连接 Service 时满足性能要求，并理解何时满足、何时不满足。

设计动机：聚合吞吐量有助于判断集群网络与应用能否承载所需的数据传输速率，并识别限制吞吐量的瓶颈。

测量方法：需要同时采集连接持续时长与期间传输的数据量，同样可通过客户端侧（应用代码/基准工具）或网络设备侧（报文检测分析）实现。

十、其他 SLI：Watch 延迟与扩展点延迟

10.1 Watch 延迟（Watch Latency）

定义：对每种资源，从对象存入数据库到它准备好发送给所有 watcher 的时间，取过去 5 分钟 99 百分位。详见 watch_latency.md。

价值：Kubernetes 中几乎所有控制循环都是基于 watch 的，因此 watch 慢意味着整个系统都慢。作为管理员，若 Kubernetes 表现缓慢，该 SLI 可帮助判断根因是 api-machinery 本身（watch 慢），还是路径更下游的问题（网络带宽不足、控制器 CPU 饥饿等）。

注意事项：该度量方式隐式假设多 master 集群中无时钟偏差（clock skew）。长期来看官方希望为 watch 延迟提供保证（如每集群日 SLI 的 99 百分位 ≤ X ms），但尚未实现。

10.2 Admission 与 Webhook 延迟（API 扩展点延迟）

定义：

• Admission 延迟：每种 admission 插件类型的延迟，取过去 5 分钟 99 百分位；
• Webhook 调用延迟：每种 webhook 类型的调用延迟，取过去 5 分钟 99 百分位。

详见 api_extensions_latency.md。其价值在于：当 API 调用缓慢时，管理员可以判断是否为扩展点（admission 插件、webhook）所致，以及具体是哪一类插件/哪个 webhook 在拖慢请求——这与 API 调用延迟 SLO 中"排除 webhook 与优先级公平性等待时间"的度量口径形成互补，一个度量系统自身、一个度量扩展点。

十一、从 SLO 到 SLA 的边界与测试验证

综合全文，Kubernetes 的可扩展性保证体系可以总结为一条清晰的逻辑链：

1. 满足环境前提（规模适当的 master、事件独立 etcd、版本达标等）；
2. 满足对象数量阈值（thresholds.md 中按资源类型给出的数量/大小限制）；
3. 合理使用可扩展性特性（webhook 高可用低延迟、CRD 数量受限）；
4. 控制集群 churn ≤ 20/s；
5. 在上述前提下，稳态 SLO 才成立：API 变更/只读调用延迟（1s/1s·30s）、无状态 Pod 启动延迟（5s）为官方承诺；网络/DNS 编程延迟、集群内网络/DNS 延迟、首包延迟、吞吐量、有状态 Pod 启动延迟等为 WIP 指标，阈值 X/Y 待定。

SLO 与 SLA 的边界：如原文档所强调，并非每个 SLO 都能翻译为 SLA（服务等级协议）。SLO 只针对默认安装场景给出，且以"可测量"为前提——有些指标在真实集群中度量代价过高，此时基准测试（benchmark）是可接受的替代。此外，SIG Scalability 正在持续扩展 SLI/SLO 覆盖范围，并可能引入仅供开发者使用的内部 SLI（用于理解系统性能特性，但不向用户提供保证）。

测试验证现状：多数明细文档的测试场景仍标注为__TODO（如 api_call_latency.md 的__TODO: Describe test scenario.__），这反映了 SLO 体系仍在演进中。测试中的已知注意事项包括：客户端类型混合（核心组件假设使用 protobuf）、GET 缓存数据的可选择性、多可用区下预置卷的均衡分布等。

十二、小结

Kubernetes 的"可扩展性保证"不是营销话术，而是一套有明确定义、明确前提、明确度量口径的工程契约：以 slos.md 定义 SLI/SLO 框架与"你承诺，我承诺"模型，以 thresholds.md 划定负载边界，以十份明细文档（api_call_latency.md、pod_startup_latency.md、network_programming_latency.md、dns_programming_latency.md、network_latency.md、dns_latency.md、first_packet_latency.md、throughput.md、watch_latency.md、api_extensions_latency.md）逐一给出可复现的度量口径。

对集群运维者而言，这份文档即是一份自检清单：核对 master 与 etcd 部署方式、对照阈值表核查对象规模、评估 webhook 的可用性与延迟、监控 churn——满足这些前提，你的集群才真正站在官方 SLO 的"承诺范围"之内。

【免费下载链接】communityKubernetes Community Documentation项目地址: https://gitcode.com/GitHub_Trending/com/community