Kubernetes SIG Scalability 章程全解SLO 定义、回归阻断与跨 SIG 治理机制【免费下载链接】communityKubernetes Community Documentation项目地址: https://gitcode.com/GitHub_Trending/com/community导读SIG Scalability 是 Kubernetes 社区中负责定义并驱动可扩展性目标的横向技术组织它通过 SLI/SLO 体系把Kubernetes 是否可扩展量化为可测试、可发布的硬性承诺并依靠跨 SIG 特权PR 回滚、合并队列冻结、Beta/GA 门禁保障每一个官方版本都达标。本文以 sig-scalability/charter.md 为主体结合仓库内 SLIs/SLOs 定义、扩展性阈值、合并阻断规则 与正式流程文档系统讲解该 SIG 的职责边界、测试框架、SLO 体系与回归治理机制读完你既能理解Kubernetes 声称可扩展背后的定义与门槛也能掌握社区如何在发布前守住扩展性底线。SIG Scalability 的使命与职责范围根据 charter.md 的定义SIG Scalability 的首要职责是定义并驱动 Kubernetes 的可扩展性目标。具体而言它负责定义、测试并度量与性能和可扩展性相关的服务级别指标Service Level IndicatorsSLI确保每个 Kubernetes 官方版本都能满足基于这些 SLI 构建的服务级别目标Service Level ObjectivesSLO协调并参与不属于其他单个 SIG 章程范围的、系统级的可扩展性与性能改进——通过推动大型架构变更、定位系统瓶颈来实现就 Kubernetes 中任何与可扩展性和性能相关的方面提供咨询。从仓库中的 README.md 可以看到SIG 的工作还延伸到超越 5k 节点这一长期兴趣方向只要不牺牲 Kubernetes 整体架构的可维护性、可理解性SIG 乐意指导并协作相关探索但这并非当前优先级。In Scope代码、二进制与跨 SIG 流程测试框架与测试资产SIG Scalability 拥有并维护的核心测试资产分为两类可扩展性与性能测试框架典型代表Cluster Loader v2clusterloader2位于kubernetes/perf-tests仓库是当前官方发布阻塞可扩展性测试的执行框架Kubemark位于kubernetes/kubernetes仓库的cmd/kubemark等目录通过空心节点hollow-node在少量真实机器上模拟数千节点规模的集群。可扩展性与性能测试测试用例位于kubernetes/perf-tests仓库的clusterloader2/testing目录运行这些测试的 CI 任务位于kubernetes/test-infra仓库的config/jobs/kubernetes/sig-scalability目录。关于测试的规模层次FAQ 文档 补充说明SIG 在100 节点与5000 节点两个量级上测试 Kubernetes所有可扩展性测试都运行在单台大型控制面虚拟机承载全部控制面组件的集群上——用于 5000 节点测试的控制面 VM 为64 核、256GB 内存、200GB SSD 持久盘。此外还用 Kubemark 模拟集群约 80 台机器、每台跑 60 余个 hollow-node 来模拟 5000 节点。目前官方发布验证使用 GCE 上的真实集群。跨 SIG 与对外流程章程将以下流程列为 In Scope定义Kubernetes 可扩展的含义定义或批准各项性能 SLI/SLO确保它们都以用户体验为导向且彼此一致见 SLIs/SLOs 文档发布门禁确保每个官方 Kubernetes 版本都满足Kubernetes scalability定义中的全部可扩展性与性能要求最佳实践输出建立并记录如何以可扩展、高性能的方式设计与实现 Kubernetes 特性的最佳实践教育贡献者并为其设计与实现提供咨询相关产出见 扩展性治理与回归案例研究瓶颈发现定位系统瓶颈协调跨领域架构变更。Out of Scope职责边界章程明确属于其他单个 SIG 章程范围内特性的性能/可扩展性改进不在本 SIG 范围内。这是为了保持职责划分清晰横向、系统级的可扩展性问题归 SIG Scalability而某一特定特性如调度、网络、存储内部的性能优化归对应 SIG。这一边界同时解释了为何 SIG Scalability 需要跨 SIG 特权——它必须协调其他 SIG 的资源来修复其职责范围内的瓶颈。跨 SIG 特权如何守住扩展性底线由于可扩展性/性能是系统的横向属性——Kubernetes 单点改动可能影响整个系统——章程授予 SIG Scalability 一组特殊的跨 SIG 权力1. 回滚已合并的 PR如果某个已合并 PR 被识别为性能/可扩展性 SLO 回归由发布阻塞的可扩展性/性能测试集判定的原因SIG 可以回滚该 PR。该 PR 只有在通过规模化测试证明无问题后才被允许重新合并。2. 冻结相关仓库的合并队列在发生性能回归时SIG 可以阻止所有 PR 合并进入相关仓库直到回归根因被定位并缓解。关于暂停合并队列的交战规则Rules of engagement及引入该机制的必要性详见 block_merges.md其核心规则为在某个发布阻塞测试套件上观察到可扩展性回归定义为由绿转红——若测试本已失败则无权宣布回归冻结受影响分支上相关仓库的所有 PR 合并并声明涉及哪些仓库及原因定位造成回归的 PR可通过阅读代码变更、二分、基于指标/日志调试等只要有合理把握即可认定不必等机制 100% 理解以缩短合并冻结时间缓解回归例如回滚 PR、默认关闭某特性开关、若易修则直接修复解除合并冻结。该文档给出的理由非常务实大规模 e2e 测试耗时太长、天然存在 flaky无法作为每个 PR 的前置条件一旦回归被合并而无人处理很快会叠加第二个回归而同时调试两个叠加回归的难度是指数级的参见 issue 53255 的历史经验此外历史上 scheduler 反亲和影响 kube-dns、kubelet 网络插件增大 pod 启动延迟、apiserver 大响应违反 gRPC MTU 等问题本可以用基准测试更早、更省人力地捕获。3. 重大变更需技术负责人显式批准章程要求重大变更影响面大的改动例如 etcd 升级、Go 版本升级、重大架构变更等只有在满足以下两个条件时才可合并获得 SIG Scalability 技术负责人tech lead的显式批准在最大支持规模的集群上通过性能测试除非批准人认为无此必要。4. 特性晋级门禁Beta / GASIG 可以阻止特性晋级阻止进入 Beta如果该特性开启后会违反已有的性能/可扩展性 SLO阻止进入 GA当该特性可能在规模化场景使用时多数情况下需要扩展可扩展性测试以覆盖它并确保既有 SLO 仍然满足少数情况下需要引入新的 SLI/SLO 并确保其在规模化下达标。5. 要求引入回归捕获基准测试对于可扩展性关键功能SIG 可以要求相应 SIG 引入回归捕获基准测试regression-catching benchmark test。三层防护设计与实现、测试、发布流程中的可扩展性章程的跨 SIG 特权落地于 formal-scalability-processes.md 提出的三层流程按重量从轻到重实现 / 提交前阶段Pre-submit可选 PR 任务由 PR 作者或评审者通过机器人命令手动触发。中规模任务如 Kubemark-500 约消耗 80 vCPUs、GCE-100 约 100 vCPUs几乎人人可触发大规模任务如 Kubemark-5000 约 700 vCPUs、GCE-2000 约 2030 vCPUs资源与风险高触发权限受限且需配额检查。强制合并前任务Pre-merge在提交队列头部、PR 合并前运行要求快速健康如 Kubemark-500 约 50 分钟、GCE-100 约 40 分钟以免拖累合并速率。约60% 的扩展性回归可由这类中规模任务捕获见回归案例研究。测试 / 提交后阶段Post-submit关键可扩展性任务具备阻塞提交队列的能力支持手动解阻形成回归进入发布前的最后一道防线。为减少误报会忽略未真正运行性能 e2e 的失败、与上次运行同因的失败以及已知 flake。设计 / 特性提案阶段Design每个特性跟踪 issue 默认打上needs-scalability-assessment标签。可扩展性评估员scalability-assessor可标记/scalability-approval-not-needed要求评估员与特性无紧密关联保证视角中立或标记/needs-scalability-review转交可扩展性评审员scalability-reviewer深入审查后给出 YES/NO。Alpha 特性在可扩展性上享有一定弹性但晋级 Beta 前必须处理影响系统扩展性的问题。Kubernetes 可扩展的量化定义SLI / SLO 与阈值章程中反复出现的Kubernetes scalability 定义其具体内容在 slos/slos.md 中展开。SLI 只定义测什么、怎么测SLO 才给出具体承诺而是否满足 SLO 还取决于集群配置、扩展性特性使用方式与集群负载——因此该文档提出了你承诺我承诺you promise, we promise框架如果你承诺正确配置集群、以合理方式使用扩展性特性、将集群负载保持在推荐阈值内那么我们就承诺你的集群是可扩展的——所有 SLO 均得到满足。SLI/SLO 必须具备四项属性精确且定义良好、彼此一致、以用户为导向表述不依赖系统内部细节、可测试若测量成本过高基准测试有时也可接受这意味着并非所有 SLO 都能转译为 SLA。前置条件与扩展性阈值满足 SLO 还需以下前置条件集群可用且正常服务集群 churnchurn 每秒 Pod spec 创建/更新/删除数 每秒用户发起的请求数≤ 20。对象的数量必须满足 thresholds.md 定义的阈值。该文档强调两点多数阈值不是硬限制越界通常导致性能退化而非集群立即宕机许多集群级阈值针对最大规模集群给出小集群应成比例下调。核心阈值摘录如下API Server 与 etcd 存储内置资源类型数量单资源类型集群级对象数非 Event150,000TBD对象数Event1,000,000n/a单对象大小1.5MB1.5MB总大小1.5GBTBD按资源类型数量命名空间级集群级#Nodesn/a5000#Namespacesn/a10000#Pods3000150000#Pods per nodemin(110, 10×核数)min(110, 10×核数)#Services500010000#Endpoints per service250n/a#Deployments2000TBD#AccessTokens20002000#AccessTokens 校验5000 QPS5000 QPS阈值还受环境/云厂商影响例如 #Ingresses、#PersistentVolumes 等大多待定TBD。文档同时指出自 2025 年 12 月起官方发布阻塞可扩展性测试运行在kops之上精确配置可参考 test-infra 中的 sig-scalability job 配置与 kops 的 scalability 场景配置。稳态 SLI/SLO 一览目前已有 SLI/SLO 的覆盖面足以保证集群不会完全死掉但尚未满足用户在许多领域的期望SIG 正在积极扩展覆盖。已列为Official的稳态 SLO 包括变更型 API 调用延迟默认安装下每个resource, verb组合排除虚拟/聚合资源与 CRD99 分位per cluster-day≤ 1s非流式只读 API 调用延迟默认安装下每个resource, scope组合scoperesource≤ 1sscopenamespace或scopecluster≤ 30s可调度无状态 Pod 启动延迟排除镜像拉取与 init 容器时间从 Pod 创建时间戳到所有容器经 watch 观测为 started99 分位 ≤ 5s。处于WIP状态的还包括有状态 Pod 启动延迟、负载均衡编程延迟、DNS 编程延迟、集群内网络延迟、集群内 DNS 延迟、首包延迟First Packet Latency与吞吐throughput等详细定义见 slos 目录 下的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。此外还有仅供开发者理解系统性能特征、不对用户承诺的内部 SLI以及 WIP 状态的 watch 延迟、准入延迟、webhook 调用延迟等其他 SLI。规模化目标Goals历史目标文档 goals.md 给出了可扩展性定义的早期量化目标非特定版本承诺最大每集群 200,000 核、每核 10 个 Pod、每节点管理开销 5%最小 0.5 核/1GB RAM、每集群管理开销 1%最小 2 核/4GB RAMHA 时 3%、每节点最多 64 核、每机器最多 500 Pod、每集群最多 5,000 节点、每集群最多 500,000 Pod、端到端 Pod 启动时间 ≤5s99 分位、调度器吞吐 100 Pod/秒、最大集群饱和恢复时间 90 分钟。这些数字与如今阈值文档中的 5000 节点、150,000 Pod 等一脉相承。测试基础设施与控制面配置provider-configs.md 给出了规模化测试的控制面选型建议Google 使用n1-standard-6464 核/240GB承载 5000 节点测试AWS 提议m4.16xlarge64 核/256GBAzure 提议standard-g532 核/448GBPacket 提议 Type 2 裸金属24 核/256GB。附加配置要求包括etcd 最低版本 3.1.8拆分 etcd集群状态与事件使用两个独立 etcd 集群这也是 GKE 生产默认为每个 etcd 集群提供独立且受保护的 IOPS如各 256GB 专用 SSD/EBS io1API server 做负载均衡、其余组件使用标准 leader election容器运行时建议使用 containerd。回归案例研究为什么这些机制是必要的回归案例研究文档 记录了 SIG Scalability 历史捕获的十余个真实回归例如apiserver 内存增加 10-20%添加 admission 指标后 100 节点集群上 apiserver 内存增加 100-200MB#56061Pod 启动延迟超 SLOCNI 库引入重复地址检测DAD导致启动延迟增加超 1 秒违反 5s SLO#55060kube-dns 调度极慢调度器反亲和实现为 O(pods²) 导致大集群创建超时#54164gRPC 升级导致大响应 API 调用失败vendor 库升级后 apiserver↔etcd 响应 MTU 变化只有规模化测试能捕获#51099Go 1.8 升级带来 ~2x 服务创建耗时最终由 golang 团队在补丁版本修复#45216。这些案例的启示约 60%甚至更多的扩展性回归可由中规模快速测试gce-100、kubemark-500捕获其余大部分由大规模慢速测试kubemark-5k、gce-2k捕获——这正对应正式流程文档中presubmit 盾牌 postsubmit 第二道防线的设计。文档也记录了相应 SIG 的职责划分如测试基础设施问题归 sig-testing、大集群搭建问题归 sig-cluster-lifecycle详见 scalability-validation.md。角色与组织治理章程规定SIG Scalability 遵循 committee-steering/governance/sig-governance.md 中的角色与组织管理约定并选择加入该文档的后续更新。子项目创建权限委托给技术负责人Technical Leads对应 sig-governance 中的 Subproject creation - Option 1。从 README.md 可以看到当前治理结构两位 Chair 负责 SIG 日常运营与流程技术负责人负责建立/解散子项目、解决跨子项目技术问题。SIG 当前拥有六个子项目inference-perf、kubernetes-scalability-and-performance-tests-and-validation、kubernetes-scalability-bottlenecks-detection、kubernetes-scalability-definition、kubernetes-scalability-governance、kubernetes-scalability-test-frameworks分别对应定义、治理、瓶颈发现、测试框架、测试与验证、推理性能基准等领域。其中inference-perf是 GenAI 推理性能基准测试工具可用于对推理部署做 apples-to-apples 的横向对比。总结SIG Scalability 的章程本质上定义了 Kubernetes 可扩展性的承诺模型用精确、一致、用户导向、可测试的 SLI/SLO 把可扩展变成可验证的工程事实用扩展性阈值界定承诺的前提条件再用回滚、合并冻结、重大变更审批、Beta/GA 门禁和基准测试要求等跨 SIG 特权强制执行。对开发者而言理解这份章程意味着在提交大规模改动、引入新特性或设计新 API 时应主动对照 SLIs/SLOs 与 阈值文档 评估影响必要时通过可选 PR 可扩展性任务验证并在晋级 Beta/GA 前满足扩展性审查要求——这正是 Kubernetes 在持续高速演进中仍能维持规模化承诺的制度基石。【免费下载链接】communityKubernetes Community Documentation项目地址: https://gitcode.com/GitHub_Trending/com/community创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考