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 的可扩展性定义建立在两个业界通用概念之上服务等级指标SLIService Level Indicator定义测量什么、如何测量。SLI 是通用的它只描述度量方式本身。服务等级目标SLOService 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 的覆盖范围以更好地反映用户期望此外未来可能引入**仅供开发者使用internalfor 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——一个多维空间中集群可被支持配置的边界区域包络具有以下性质它不是立方体各个维度之间并非相互独立它不是凸的NOT convex沿某一维度推进越远其他维度上的横截面cross-section就越小——即维度之间存在此消彼长的关系它是有界的bounded它可以分解为更小的子包络decomposable into smaller envelopes。3.2.2 阈值的使用注意事项在套用阈值表之前必须先理解以下四点多数情况下阈值并非硬性上限NOT hard limits——超出限制只会导致性能下降并不意味着集群立即崩溃许多集群级cluster scope阈值是针对最大规模集群给出的对于更小的集群限制会按比例更低阈值可能随 Kubernetes 版本变化期望只增不减下表针对 Kubernetes head 版本给出阈值基于OSS 发行版 sharded etcd的配置假设自 2025 年 12 月起官方发布阻塞可扩展性测试运行在kops之上。3.2.3 与 API Server 和 etcd 存储相关的阈值内置资源类型数量项阈值scoperesource type阈值scopecluster对象数量非 Event150,000TBD对象数量Event1,000,000n/a单对象大小Size per object1.5MB1.5MB总大小Total size1.5GBTBD3.2.4 按资源类型划分的阈值数量项阈值scopenamespace阈值scopecluster#Nodes节点数n/a5000#Namespaces命名空间数n/a10000#PodsPod 数3000150000#Pods per node单节点 Pod 数min(110, 10×核数)min(110, 10×核数)#ServicesService 数500010000#All service endpoints全部 Service 端点TBDTBD#Endpoints per service单 Service 端点数250n/a#SecretsTBDTBD#ConfigMapsTBDTBD#Deployments2000TBD#DaemonSetsTBDTBD#JobsTBDTBD#StatefulSetsTBDTBD#AccessTokens访问令牌数20002000#AccessTokens verifications令牌校验 QPS5000 QPS5000 QPS3.2.5 依赖环境/云提供商的阈值非穷尽列表数量项阈值scopenamespace阈值scopecluster#IngressesTBDTBD#PersistentVolumesn/aTBD#PersistentVolumeClaimsTBDTBD#PersistentVolumeClaims per nodeTBDTBD实践提示#Pods per node min(110, 10×核数)是一条非常具体的可执行规则规划节点规格时即可据此推算单节点 Pod 容量上限。而#Endpoints per service 250直接约束了大型工作负载的 Service 后端数量设计。3.3 Kubernetes 可扩展性特性Extensibility的使用要求要满足 SLO用户还必须明智地使用可扩展性特性。官方给出的精确表述仍在完善中但已明确包含以下方向Webhook 必须提供高可用high availability和低延迟low latencywebhook 挂在 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/SLOSteady State SLIs/SLOs以下表格是整套体系的核心完整列出了官方Official与进行中WIP的稳态指标。所有指标的统计口径均为过去 5 分钟的 99 百分位measured as 99th percentile over last 5 minutesSLO 目标则按每集群日per cluster-day衡量。状态SLI指标定义SLO目标明细文档Official官方单对象变更型mutatingAPI 调用处理延迟按每个resource, verb组合取过去 5 分钟 99 百分位默认 Kubernetes 安装下对每个resource, verb组合排除虚拟资源、聚合资源与自定义资源定义 CRD每集群日 99 百分位 ≤ 1sapi_call_latency.mdOfficial官方非流式只读non-streaming read-onlyAPI 调用处理延迟按每个resource, scope组合取过去 5 分钟 99 百分位默认安装下对每个resource, scope组合排除虚拟/聚合资源与 CRD每集群日 99 百分位(a) 若scoperesource则 ≤ 1s(b) 否则scopenamespace或scopecluster≤ 30sapi_call_latency.mdOfficial官方可调度无状态statelessPod 启动延迟排除镜像拉取与 init 容器运行时间从 Pod 创建时间戳计到所有容器上报 started 且经 watch 观察到取过去 5 分钟 99 百分位默认安装下每集群日 99 百分位 ≤ 5spod_startup_latency.mdWIP进行中可调度有状态statefulPod 启动延迟排除镜像拉取、init 容器、卷供应延迟绑定模式与卷卸载/分离若前一 Pod 需要取过去 5 分钟 99 百分位默认安装下每集群日 99 百分位 ≤ XX 取决于存储提供商pod_startup_latency.mdWIP进行中集群内负载均衡机制如 iptables编程延迟从 Service spec 或其ReadyPod 列表变化计到反映到负载均衡机制跨所有 programmer 聚合取过去 5 分钟 99 百分位默认安装下每集群日 99 百分位 ≤ Xnetwork_programming_latency.mdWIP进行中DNS 实例编程延迟从 Service spec 或其ReadyPod 列表变化计到反映到该 DNS 实例跨所有 DNS 实例聚合取过去 5 分钟 99 百分位默认安装下每集群日 99 百分位 ≤ Xdns_programming_latency.mdWIP进行中集群内网络延迟由单个 prober Pod 每秒 ping null service 测得取过去 5 分钟 99 百分位节点间 RTT ≤ Y 的默认安装下每集群日所有 prober Pod 的 99 百分位的 99 百分位≤ Xnetwork_latency.mdWIP进行中集群内 DNS 延迟由单个 prober Pod 每秒对 null service 做 DNS 查询测得取过去 5 分钟 99 百分位节点间 RTT ≤ Y 的默认安装下每集群日所有 prober Pod 的 99 百分位的 99 百分位≤ Xdns_latency.mdWIP进行中首包延迟First Packet Latency毫秒客户端向 Service 发起 TCP 连接发送 SYN 包到收到来自 Service 后端的第一个包典型为三次握手中的 SYN-ACK 包跨所有节点实例聚合取过去 5 分钟 99 百分位节点间 RTT ≤ Y 的默认安装下每集群日所有节点的 99 百分位的 99 百分位≤ Xfirst_packet_latency.mdWIP进行中到 Service 的 TCP 连接成功数据传输速率以 bps、kbps、Mbps 或 Gbps 计量跨节点内所有到 Service 的连接聚合取过去 5 分钟 99 百分位节点间 RTT ≤ Y 的默认安装下每集群日所有节点的 99 百分位的 99 百分位≤ Xthroughput.md脚注 [1]为了可视化目的每集群日将采用滑动窗口sliding window但就 SLO 本身而言它实质上表示每天中好分钟数fraction of good minutes per day的占比保持在阈值之内。4.2 其他 SLIOther SLIs以下指标同样被定义但尚未给出 SLO 目标主要用于内部性能理解与问题定位状态SLI指标定义明细文档WIPWatch 延迟对每种资源从对象存入数据库到准备好发送给所有 watcher 的时间取过去 5 分钟 99 百分位watch_latency.mdWIPAdmission 延迟每种 admission 插件类型的延迟取过去 5 分钟 99 百分位api_extensions_latency.mdWIPWebhook 调用延迟每种 webhook 类型的调用延迟取过去 5 分钟 99 百分位api_extensions_latency.md五、API 调用延迟 SLO 详解OfficialAPI 调用延迟是整套体系中最核心的官方承诺其明细见 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指未设置watchtrue的 GET 请求在 Kubernetes 内部实际会翻译为 GET 和 LIST 两类调用。请求作用域scope分三种resource请求针对单个对象namespace请求针对单个命名空间内的对象cluster请求跨多个命名空间spawns objects from multiple namespaces。关于 30s 阈值的历史背景脚注 5历史上scopenamespace的 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 控制的因素具体为 webhook1.23与 API 优先级及公平性队列等待时间1.27引入的延迟。5.5 待办TODOs未来可能将non-namespaced非命名空间级资源作为独立的分桶处理不过若其数量与namespaced资源相当则可能没有意义。测试场景Test scenario在文档中标注为__TODO。六、Pod 启动延迟 SLO 详解Official WIPPod 启动延迟的完整口径见 pod_startup_latency.md。这是第二个官方OfficialSLO无状态 Pod 启动延迟每集群日 99 百分位 ≤ 5s。6.1 关键定义可调度 Podschedulable pod无需其他任何组件介入即可立即调度、且不会引发任何抢占preemption的 Pod无状态 Podstateless pod不挂载除 secrets、config maps、downward API 和 empty dir 之外来源卷的 Pod有状态 Podstateful pod至少挂载一个来自其他来源的卷的 Pod。6.2 什么被纳入、什么被排除只有可调度 Pod 才计入该 SLI如果集群没有空间放置 PodKubernetes 无能为力这是 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 观察到**理由如下要求所有容器都启动而非仅第一个确保诸如 Pod 内容器启动线性化之类的潜在回归能被该 SLI 捕获不要求所有容器都在运行若某个容器在最后一个容器启动前已经结束也是可以的只需所有容器都被启动过至少一次不依赖就绪检查readiness checks就绪检查高度依赖应用——如果应用初始化需要几分钟才开始响应就绪检查这不应当计入 Kubernetes 的性能watch 上报至关重要即使应用已启动Kubernetes 中许多控制循环也要先观察到该状态才会触发。如果 kubelet 因故无法上报状态系统其他部分将无从得知由于 watch 在 Kubernetes 中处于核心地位许多控制循环由特定 watch 事件触发观察 Pod 状态本身也是 SLI 的一部分——这正是下一个控制循环可能被触发的时刻。6.4 待办与测试注意重新审视是否要将watch pod 状态部分包含进 SLI考虑为 Pod 删除延迟创建 SLI对有状态 Pod必须先从节点分离 RWO 卷才能挂载到另一节点慢删除可能阻塞启动测试中容易排除需要抢占或卷卸载的 Pod环境完全可控但生产环境如何正确排除仍需解决测试注意当集群节点跨多个可用区时预置卷应在各可用区间均衡分配避免因单可用区资源不足导致 Pod 不可调度。七、网络与 DNS 编程延迟 SLIWIP这两项指标度量的是变更何时真正生效明细见 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 聚合方式的深意CaveatsSLI 跨所有 programmer/DNS 实例聚合所有样本进入一个大池子百分位从整个池子计算。这正符合终端用户视角即便一小部分 programmer 完全无响应其他都很快也是可接受的——在规模变大时这种现象必然出现。若改为在 SLI 层面聚合从 99% 的 programmer 可见为判断每次变化何时在 99% 的 programmer 中生效就必须按变更粒度追踪指标这在计算上极不现实。7.4 测量方法如何实现该 SLI网络编程延迟的测量方法并不直观官方给出了完整的实现蓝图DNS 编程延迟的测量方法与之完全相同可参考 network_programming_latency.md#how-to-measure-the-sli假设集群内负载均衡编程基于 Kubernetes 的Endpoints对象为Endpoints对象引入一个专用 annotation名称待定Endpoints controller 在更新某个Endpoints对象时将该 annotation 的值设置为触发此次更新的变更时间戳对 Pod 在Ready/NotReady之间的状态转换时间戳就是 Pod 条件condition的一部分Service 更新待定理想方案是在对象 metadata 中新增LastUpdateTimestamp字段紧邻已有的CreationTimestamp。数据在存储层已存在传播并不困难集群内负载均衡 programmer 在编程完成后导出一个 Prometheus 指标操作延迟定义为完成时间戳 − 新引入 annotation 记录的时间戳。该测量方法存在三个已知注意事项单个Endpoints对象可能批量合并多次 Pod 状态转换此时选择最早的那个不暴露所有时间戳避免对象理论上无界增长。这会使指标不精确但批处理周期相对整个端到端流程较小单个 Pod 可能在批处理周期内多次转换状态为此将在 Endpoints controller 中增加缓存缓存每个 Pod 首次观察到的转换时间戳controller 将 Pod 纳入Endpoints更新时清空缓存与上面选择最早更新一致。初期可能直接忽略这一事实组件可能掉出 watch 窗口历史而错过部分 watch 事件当单个对象在期间多次变化时会成为问题否则 informer 会在重新 list 时送达 handler。该情况只发生在组件处理事件过慢此时已反映在指标中或 kube-apiserver 重启之后。官方决定忽略该问题以避免不必要的复杂度。八、集群内网络与 DNS 延迟 SLIWIP8.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 跟踪查询/etc/resolv.conf中的 nameserver IP查询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 注意事项CaveatsSLI 针对 prober Pod 表述用户在 SLO 层面才做聚合这提供了非常相似的保证且便于测量节点间 RTT 差异若节点处于不同拓扑如不同的 GCP zoneRTT 可能显著不同。由于 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 的推进。九、首包延迟与吞吐量 SLIWIP这两项指标聚焦数据面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 时满足性能要求并理解何时满足、何时不满足。设计动机聚合吞吐量有助于判断集群网络与应用能否承载所需的数据传输速率并识别限制吞吐量的瓶颈。测量方法需要同时采集连接持续时长与期间传输的数据量同样可通过客户端侧应用代码/基准工具或网络设备侧报文检测分析实现。十、其他 SLIWatch 延迟与扩展点延迟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 的可扩展性保证体系可以总结为一条清晰的逻辑链满足环境前提规模适当的 master、事件独立 etcd、版本达标等满足对象数量阈值thresholds.md 中按资源类型给出的数量/大小限制合理使用可扩展性特性webhook 高可用低延迟、CRD 数量受限控制集群 churn ≤ 20/s在上述前提下稳态 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创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考