Kubernetes SIG Scalability 2024 年度技术报告规模验证、测试框架演进与 watch-cache/CBOR 等核心 KEP 解读【免费下载链接】communityKubernetes Community Documentation项目地址: https://gitcode.com/GitHub_Trending/com/communitySIG ScalabilityKubernetes 可扩展性特别兴趣小组负责为整个 Kubernetes 定义并驱动可扩展性目标同时协调系统级的性能与扩展性改进。本文以该 SIG 在sig-scalability/annual-report-2024.md中的年度报告为骨架结合本仓库中的 charter.md、slos.md、thresholds.md 与 block_merges.md 等治理与定义文档系统解读 SIG 在 2024 年Kubernetes v1.30v1.32的核心工作规模回归防护、可扩展性测试框架增强以及 Consistent Reads from Cache、Streaming List、CBOR Serializer、Resilient watchcache initialization 四项重点 KEP。读完本文你将完整掌握 SIG Scalability 的职责边界、SLO 保障机制、2024 年技术成果清单以及社区协作与治理流程的全貌。SIG Scalability 的定位与年度报告概览SIG Scalability 的本职工作是定义并驱动 Kubernetes 的可扩展性目标。根据 charter.md它的核心职责包括定义、测试并度量与性能和可扩展性相关的服务等级指标SLI并确保每个 Kubernetes 官方版本都满足基于这些 SLI 构建的服务等级目标SLO同时通过推动大规模架构变更、发现瓶颈为不属于其他 SIG charter 的系统级扩展性与性能改进提供咨询。2024 年年度报告给出的四个高亮成果构成了该年工作的主线全年为大量特性验证可扩展性/性能影响与可靠性并防止回归regression增强可扩展性测试框架更好的可观测性instrumentation与更低的 flakiness测试不稳定率在整个 Kubernetes 项目中新增测试覆盖推动并影响了一批 KEP 与修复主要集中在 Kubernetes 核心组件API Server、API Machinery、etcd 与 kube-controller-manager。其中防止回归正是 SIG 的看家本领——下文会看到SIG 为此在 charter 中拿到了可回滚已合并 PR、可暂停合并队列的特殊跨 SIG 权限并配套了完整的治理文档。规模验证与回归防护SIG 的守门人机制Release-blocking 测试与验证流程报告强调SIG 全年持续为大量特性做规模/性能影响与可靠性验证。这一工作并非临时起意而是沉淀在 scalability-validation.md 中的正式流程对Kubernetes 支持 X 节点集群的声明需要通过两类大规模 e2e 测试验证——正确性测试correctness与性能测试performance且官方 release 必须把 5k 节点测试列为 release-blocking 任务。该文档还给出了历史排期模式工作日每天在 5k 节点 GCE 集群上分别运行正确性与性能测试周末在 GKE 上运行 5k 与 2k 测试以平衡回归发现及时性与大规模测试的高成本单次运行 1224 小时、消耗数万核时。2024 年的执行细节可能随 job 健康度与发布需求调整但每日一次大集群回归信号的原则延续至今。回归发生后的处置暂停合并队列如果回归仍然发生SIG 拥有 charter 赋予的强力手段。按照 block_merges.md 中的 Rules of engagement处置顺序为在 release-blocking 测试套件上观察到可扩展性回归必须是由绿转红的转变原本就失败的测试不算声明受影响仓库与原因暂停受影响分支上所有 PR 的合并定位导致回归的 PR代码走查、bisect、基于指标/日志的调试只要合理确信即可判定不必等 100% 理解机制以缩短合并阻塞时间缓解回归回滚 PR、关闭特性开关优先默认关闭测试中关闭是最后手段、或快速修复解除合并阻塞。这份文档还解释了为什么需要如此激进的手段关键规模 e2e 测试耗时过长、无法作为每个 PR 的合并前置条件端到端测试本身有 flakiness 需要重试一旦第一个回归合入第二个回归大概率会叠加在它之上而同时调试两个叠加回归的难度是指数级上升的文档引用了历史 issue 53255 的经验。三道防线pre-submit / post-submit / design reviewSIG 把可扩展性保障按开发阶段拆成三道防线见 formal-scalability-processes.md实现/预提交阶段提供可手动触发的可选 PR 规模测试 job如 Kubemark-500、GCE-100 等中规模 jobKubemark-2000/5000、GCE-500/2000 等大规模 job 触发权限受限以及合并队列头部的强制 pre-merge job测试/后提交阶段关键规模 job 具备阻塞 submit-queue 的能力失败后人工解除并过滤掉非性能类失败与已知 flake避免误伤设计/特性提案阶段每个特性默认打上needs-scalability-assessment标签由 scalability-assessor 初筛、scalability-reviewer 终审确保新特性在设计阶段就被评估可扩展性影响。可扩展性测试框架与覆盖增强2024 年报告的另一条主线是测试框架本身的演进更强的 instrumentation 与更低的 flakiness以及覆盖整个 Kubernetes 项目的新增测试。这些工作归属kubernetes-scalability-test-frameworks与kubernetes-scalability-and-performance-tests-and-validation两个子项目测试框架参见 README.md 的 subprojects 说明Cluster Loader v2声明式地定义并加载大规模集群负载、Kubemark以轻量伪节点模拟大规模集群的测试工具两者对应不同的成本/精度取舍测试与验证官方测试集、Testgrid结果看板与 Perfdash性能数据看板共同构成持续验证闭环目标是让每个官方 Kubernetes 版本都满足可扩展性定义中的全部要求成为可重复、可审计的过程。测试框架的价值在于把大规模回归的发现成本前置例如历史上 scheduler anti-affinity 影响 kube-dns、kubelet 网络插件抬高 pod 启动延迟、apiserver 大响应违反 gRPC MTU 等问题都是在昂贵的大规模 e2e 中才被捕获的——如果有 benchmark 类测试本可以更早、更省人力地发现见 block_merges.md 的 Rationale 部分。2024 核心 KEP 深度解读v1.30 / v1.31 / v1.32年度报告列出了四项重点 KEP大多与 SIG API Machinery、SIG etcd 共同持有。这四项都围绕一个共同主题在不牺牲一致性的前提下降低 etcd 与 API Server 在大规模下的压力。KEP-2340Consistent Reads from Cachev1.31 Beta该 KEP 的目标是让 API Server 的 watch cache 在保持一致性读语义的前提下承担更多读请求。传统上某些读请求为了保证读到最新数据必须直接打到 etcdConsistent Reads from Cache 通过可靠地跟踪资源的最近已提交版本使得从缓存返回的数据也能满足一致性要求从而显著降低 etcd 的读负载。其在 2024 年 v1.31 进入 Beta是 API Server 读取路径性能优化的关键一步。KEP-3157Streaming Listv1.32 BetaStreaming Listwatch list允许把 LIST 请求以流式方式从 watch cache 返回数据。相比传统 LIST 需要一次性在 etcd 端完成快照再整体返回流式 LIST 可以边推进资源版本边输出对象避免了大资源列表对 etcd 内存与 API Server 响应体的一次性冲击对拥有数万对象的大 namespace 场景尤为重要。v1.32 进入 Beta为后续 LIST 路径的整体重构铺路。KEP-4222CBOR Serializerv1.32 Alpha该 KEP 引入 CBORConcise Binary Object Representation作为 API Server 的二进制序列化格式。相比 JSONCBOR 是带 schema 的二进制编码在编码/解码开销、传输体积与内存占用上具备优势是缓解大规模集群下 API 流量带宽与 CPU 成本的重要方向。v1.32 以 Alpha 形态合入属于协议层减负的长期投入。KEP-4568Resilient watchcache initializationv1.31 Beta该 KEP 让 watch cache 的初始化过程更具韧性。此前 watch cache 初始化依赖从 etcd 全量 LIST 增量 watch 的衔接在 etcd 繁忙或网络抖动时容易出现初始化失败或长时间阻塞进而影响 API Server 启动与大流量下的稳定性。增强后初始化路径在失败时可重试、可降级减少了对 etcd 的瞬时压力与级联故障。说明以上 KEP 的阶段性状态Alpha/Beta 与对应版本均来自年度报告原文其机制描述为对公开增强提案的概念性归纳细节请以各 KEP 提案文档为准。可扩展性定义SLI/SLO 体系与你承诺我们承诺报告反复强调要引导各 SIG 主动识别并文档化自己负责的 API 与工作流的 SLI/SLO/limits这是因为 SIG Scalability 的可扩展性保障建立在一套严谨的 SLI/SLO 体系之上。核心定义见 slos.md。定义原则与you promise, we promise框架SLI/SLO 必须满足四个属性精确且定义清晰、彼此一致、以用户为中心、可测试。在此基础上SIG 采用你承诺我们承诺框架如果你承诺正确配置集群、合理地使用可扩展性特性、将集群负载保持在推荐 limits 之内那么我们承诺你的集群是可扩展的即所有 SLO 均被满足。满足 SLO 需要若干前提环境配置符合要求事件与集群状态分存于独立 etcd 实例、版本不低于某基线等、集群对象数量满足 thresholds.md 中的阈值、以及扩展特性webhook、CRD被明智地使用。另有两条硬性前置条件集群可用且正常服务集群 churn每秒 Pod spec 创建/更新/删除数 用户发起请求数不超过 20。稳态 SLI/SLO 关键指标状态SLI99 百分位5 分钟窗口SLO默认安装每 cluster-dayOfficial单对象 mutating API 调用处理延迟按 resource/verb 对每 (resource, verb) 对 ≤ 1sOfficial非流式只读 API 调用处理延迟按 resource/scope 对resource 作用域 ≤ 1snamespace/cluster 作用域 ≤ 30sOfficial可调度无状态 Pod 启动延迟不含拉镜像与 init 容器从创建到全部容器经 watch 观察到 started≤ 5sWIP有状态 Pod 启动延迟≤ X取决于存储提供商WIP负载均衡机制如 iptables编程延迟≤ XWIPDNS 实例编程延迟≤ XWIP集群内网络/DNS 延迟、首包延迟、吞吐量≤ X受节点间 RTT 约束关键细节详见 api_call_latency.md 与 pod_startup_latency.mdAPI 调用延迟只度量 apiserver 自身的处理时间排除 webhook1.23与 API priority fairness 队列等待时间1.27——这些是集群管理员可控的外部因素只读请求的 SLO 排除 watch 流式请求内部即 GET 与 LIST历史上 namespace 作用域 LIST 阈值为 5s后因单 namespace 可容纳数万对象的使用模式变化调整为 30sPod 启动延迟只统计可立即调度、无需抢占的 Pod有状态/无状态按挂载卷来源区分已启动定义为所有容器都经 watch 报告为 started而非 readiness因为 readiness 与应用强相关。阈值表与 Scalability EnvelopeSLO 成立的前提之一是集群负载不超限具体数量阈值见 thresholds.md。该文档用一个关键概念解释阈值间的耦合关系——Scalability Envelope可扩展性包络面包络面的属性它不是立方体维度之间相互依赖、不是凸的、沿某一维度推进越远时其余维度的横截面越小、有界、可分解为更小的包络面。这意味着阈值不是独立恒定的而是相互牵制的。当前主要阈值摘录builtin 资源、sharded etcd 下的 OSS 默认安装数量维度namespace 作用域cluster 作用域#Nodes—5000#Namespaces—10000#Pods3000150000#Pods per nodemin(110, 10×核数)min(110, 10×核数)#Services500010000#Endpoints per service250—#Deployments2000—#AccessTokens20002000对象数量非 Event/ 单对象大小 / 总量—150000 / 1.5MB / 1.5GB需要特别说明的 caveats多数阈值不是硬限制超限表现为性能劣化而非集群立即宕机cluster 作用域阈值针对最大规模集群给出较小集群应按比例下调官方 release-blocking 规模测试的基准环境从 2025 年 12 月起运行于 kops 之上。控制平面的具体选型参考见 provider-configs.md如 Google n1-standard-64、AWS m4.16xlarge 等机型以及拆分 etcd、独立 IOPS 等要求。子项目与工作组现状年度报告确认了五个继续运行的子项目与 README.md 中的定义对应kubernetes-scalability-and-performance-tests-and-validation确保验证规模与性能所需的测试齐备提供易用框架、与各 SIG 协作并按日历执行、确保每个官方 release 满足可扩展性定义kubernetes-scalability-bottlenecks-detection发现、记录规模瓶颈并推动跨 SIG 架构变更消除它们相关案例见 k8s-services-scalability-issues.mdkubernetes-scalability-definition定义Kubernetes 可扩展的含义即制定/批准各 SLI/SLO并度量、发布 limits 与规模化部署建议kubernetes-scalability-governance沉淀可扩展性设计与实现的最佳实践回归案例研究见 scalability-regressions-case-studies.mdkubernetes-scalability-test-frameworks打造让所有贡献者都能轻松进行规模/性能测试的框架Cluster Loader v2、Kubemark。报告未列出 2024 年新增的工作组Working Groups条目。此外2024 年报告反映了 SIG 与 CNCF 生态的持续联动例如在 EU KubeCon巴黎上做了 SIG Scalability Intro Deep-Dive 分享介绍 SIG 定位与 2024 年工作。社区协作方向与治理自检面向各 SIG 的求援点报告明确呼吁各 SIG 在以下方面与 SIG Scalability 协作倍增force-multiply各自负责组件/特性的可扩展性测试覆盖与回归排查主动识别并文档化自己负责的 API 与工作流的 SLI/SLO/limits——就像对待 uptime/availability 一样为各自系统设定可扩展性基准让可扩展性成为 Kubernetes 及相关 CNCF 项目的一等公民SIG Scalability 承诺全程提供指导与咨询。报告还指出 2024 年来自多家公司的贡献保持健康相关贡献统计可在 CNCF devstats 的 SIG Scalability 视图查看。Operational 治理自检作为年度例行工作2024 年报告对以下运营项做了逐项核验全部勾选通过复核并更新 README.md 的准确性复核并更新 CONTRIBUTING.md复核并更新 contributors/devel 等其他贡献文档复核并更新 sigs.yaml 中的子项目列表及关联 OWNERS 文件确认 sigs.yaml 中的 SIG 领导人chairs、tech leads、subproject leads准确且在任确保 2024 年会议纪要与录像已从 README.md 链接并更新。结语从年度报告看可扩展性的制度基建把 2024 年年度报告与本仓库中的治理文档对照阅读可以清晰看到 SIG Scalability 的运作模式用精确的 SLI/SLO 定义何为可扩展slos.md、thresholds.md用三层防线与合并阻塞机制守住回归不得进入block_merges.md、formal-scalability-processes.md再用测试框架与每日大集群验证把每个版本都满足 SLO变成可执行的纪律。2024 年围绕 watch cacheConsistent Reads、Streaming List、Resilient initialization与序列化CBOR的四项 KEP正是这套机制催生出的核心组件减负动作其成果将在后续版本的 API Server 与 etcd 路径上持续兑现。对于希望深度参与的贡献者从 slos.md 理解 SLO 语义、从 thresholds.md 掌握规模边界、再对照 scalability-regressions-case-studies.md 学习历史案例是最快的入门路径。【免费下载链接】communityKubernetes Community Documentation项目地址: https://gitcode.com/GitHub_Trending/com/community创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考
Kubernetes SIG Scalability 2024 年度技术报告：规模验证、测试框架演进与 watch-cache/CBOR 等核心 KEP 解读
Kubernetes SIG Scalability 2024 年度技术报告规模验证、测试框架演进与 watch-cache/CBOR 等核心 KEP 解读【免费下载链接】communityKubernetes Community Documentation项目地址: https://gitcode.com/GitHub_Trending/com/communitySIG ScalabilityKubernetes 可扩展性特别兴趣小组负责为整个 Kubernetes 定义并驱动可扩展性目标同时协调系统级的性能与扩展性改进。本文以该 SIG 在sig-scalability/annual-report-2024.md中的年度报告为骨架结合本仓库中的 charter.md、slos.md、thresholds.md 与 block_merges.md 等治理与定义文档系统解读 SIG 在 2024 年Kubernetes v1.30v1.32的核心工作规模回归防护、可扩展性测试框架增强以及 Consistent Reads from Cache、Streaming List、CBOR Serializer、Resilient watchcache initialization 四项重点 KEP。读完本文你将完整掌握 SIG Scalability 的职责边界、SLO 保障机制、2024 年技术成果清单以及社区协作与治理流程的全貌。SIG Scalability 的定位与年度报告概览SIG Scalability 的本职工作是定义并驱动 Kubernetes 的可扩展性目标。根据 charter.md它的核心职责包括定义、测试并度量与性能和可扩展性相关的服务等级指标SLI并确保每个 Kubernetes 官方版本都满足基于这些 SLI 构建的服务等级目标SLO同时通过推动大规模架构变更、发现瓶颈为不属于其他 SIG charter 的系统级扩展性与性能改进提供咨询。2024 年年度报告给出的四个高亮成果构成了该年工作的主线全年为大量特性验证可扩展性/性能影响与可靠性并防止回归regression增强可扩展性测试框架更好的可观测性instrumentation与更低的 flakiness测试不稳定率在整个 Kubernetes 项目中新增测试覆盖推动并影响了一批 KEP 与修复主要集中在 Kubernetes 核心组件API Server、API Machinery、etcd 与 kube-controller-manager。其中防止回归正是 SIG 的看家本领——下文会看到SIG 为此在 charter 中拿到了可回滚已合并 PR、可暂停合并队列的特殊跨 SIG 权限并配套了完整的治理文档。规模验证与回归防护SIG 的守门人机制Release-blocking 测试与验证流程报告强调SIG 全年持续为大量特性做规模/性能影响与可靠性验证。这一工作并非临时起意而是沉淀在 scalability-validation.md 中的正式流程对Kubernetes 支持 X 节点集群的声明需要通过两类大规模 e2e 测试验证——正确性测试correctness与性能测试performance且官方 release 必须把 5k 节点测试列为 release-blocking 任务。该文档还给出了历史排期模式工作日每天在 5k 节点 GCE 集群上分别运行正确性与性能测试周末在 GKE 上运行 5k 与 2k 测试以平衡回归发现及时性与大规模测试的高成本单次运行 1224 小时、消耗数万核时。2024 年的执行细节可能随 job 健康度与发布需求调整但每日一次大集群回归信号的原则延续至今。回归发生后的处置暂停合并队列如果回归仍然发生SIG 拥有 charter 赋予的强力手段。按照 block_merges.md 中的 Rules of engagement处置顺序为在 release-blocking 测试套件上观察到可扩展性回归必须是由绿转红的转变原本就失败的测试不算声明受影响仓库与原因暂停受影响分支上所有 PR 的合并定位导致回归的 PR代码走查、bisect、基于指标/日志的调试只要合理确信即可判定不必等 100% 理解机制以缩短合并阻塞时间缓解回归回滚 PR、关闭特性开关优先默认关闭测试中关闭是最后手段、或快速修复解除合并阻塞。这份文档还解释了为什么需要如此激进的手段关键规模 e2e 测试耗时过长、无法作为每个 PR 的合并前置条件端到端测试本身有 flakiness 需要重试一旦第一个回归合入第二个回归大概率会叠加在它之上而同时调试两个叠加回归的难度是指数级上升的文档引用了历史 issue 53255 的经验。三道防线pre-submit / post-submit / design reviewSIG 把可扩展性保障按开发阶段拆成三道防线见 formal-scalability-processes.md实现/预提交阶段提供可手动触发的可选 PR 规模测试 job如 Kubemark-500、GCE-100 等中规模 jobKubemark-2000/5000、GCE-500/2000 等大规模 job 触发权限受限以及合并队列头部的强制 pre-merge job测试/后提交阶段关键规模 job 具备阻塞 submit-queue 的能力失败后人工解除并过滤掉非性能类失败与已知 flake避免误伤设计/特性提案阶段每个特性默认打上needs-scalability-assessment标签由 scalability-assessor 初筛、scalability-reviewer 终审确保新特性在设计阶段就被评估可扩展性影响。可扩展性测试框架与覆盖增强2024 年报告的另一条主线是测试框架本身的演进更强的 instrumentation 与更低的 flakiness以及覆盖整个 Kubernetes 项目的新增测试。这些工作归属kubernetes-scalability-test-frameworks与kubernetes-scalability-and-performance-tests-and-validation两个子项目测试框架参见 README.md 的 subprojects 说明Cluster Loader v2声明式地定义并加载大规模集群负载、Kubemark以轻量伪节点模拟大规模集群的测试工具两者对应不同的成本/精度取舍测试与验证官方测试集、Testgrid结果看板与 Perfdash性能数据看板共同构成持续验证闭环目标是让每个官方 Kubernetes 版本都满足可扩展性定义中的全部要求成为可重复、可审计的过程。测试框架的价值在于把大规模回归的发现成本前置例如历史上 scheduler anti-affinity 影响 kube-dns、kubelet 网络插件抬高 pod 启动延迟、apiserver 大响应违反 gRPC MTU 等问题都是在昂贵的大规模 e2e 中才被捕获的——如果有 benchmark 类测试本可以更早、更省人力地发现见 block_merges.md 的 Rationale 部分。2024 核心 KEP 深度解读v1.30 / v1.31 / v1.32年度报告列出了四项重点 KEP大多与 SIG API Machinery、SIG etcd 共同持有。这四项都围绕一个共同主题在不牺牲一致性的前提下降低 etcd 与 API Server 在大规模下的压力。KEP-2340Consistent Reads from Cachev1.31 Beta该 KEP 的目标是让 API Server 的 watch cache 在保持一致性读语义的前提下承担更多读请求。传统上某些读请求为了保证读到最新数据必须直接打到 etcdConsistent Reads from Cache 通过可靠地跟踪资源的最近已提交版本使得从缓存返回的数据也能满足一致性要求从而显著降低 etcd 的读负载。其在 2024 年 v1.31 进入 Beta是 API Server 读取路径性能优化的关键一步。KEP-3157Streaming Listv1.32 BetaStreaming Listwatch list允许把 LIST 请求以流式方式从 watch cache 返回数据。相比传统 LIST 需要一次性在 etcd 端完成快照再整体返回流式 LIST 可以边推进资源版本边输出对象避免了大资源列表对 etcd 内存与 API Server 响应体的一次性冲击对拥有数万对象的大 namespace 场景尤为重要。v1.32 进入 Beta为后续 LIST 路径的整体重构铺路。KEP-4222CBOR Serializerv1.32 Alpha该 KEP 引入 CBORConcise Binary Object Representation作为 API Server 的二进制序列化格式。相比 JSONCBOR 是带 schema 的二进制编码在编码/解码开销、传输体积与内存占用上具备优势是缓解大规模集群下 API 流量带宽与 CPU 成本的重要方向。v1.32 以 Alpha 形态合入属于协议层减负的长期投入。KEP-4568Resilient watchcache initializationv1.31 Beta该 KEP 让 watch cache 的初始化过程更具韧性。此前 watch cache 初始化依赖从 etcd 全量 LIST 增量 watch 的衔接在 etcd 繁忙或网络抖动时容易出现初始化失败或长时间阻塞进而影响 API Server 启动与大流量下的稳定性。增强后初始化路径在失败时可重试、可降级减少了对 etcd 的瞬时压力与级联故障。说明以上 KEP 的阶段性状态Alpha/Beta 与对应版本均来自年度报告原文其机制描述为对公开增强提案的概念性归纳细节请以各 KEP 提案文档为准。可扩展性定义SLI/SLO 体系与你承诺我们承诺报告反复强调要引导各 SIG 主动识别并文档化自己负责的 API 与工作流的 SLI/SLO/limits这是因为 SIG Scalability 的可扩展性保障建立在一套严谨的 SLI/SLO 体系之上。核心定义见 slos.md。定义原则与you promise, we promise框架SLI/SLO 必须满足四个属性精确且定义清晰、彼此一致、以用户为中心、可测试。在此基础上SIG 采用你承诺我们承诺框架如果你承诺正确配置集群、合理地使用可扩展性特性、将集群负载保持在推荐 limits 之内那么我们承诺你的集群是可扩展的即所有 SLO 均被满足。满足 SLO 需要若干前提环境配置符合要求事件与集群状态分存于独立 etcd 实例、版本不低于某基线等、集群对象数量满足 thresholds.md 中的阈值、以及扩展特性webhook、CRD被明智地使用。另有两条硬性前置条件集群可用且正常服务集群 churn每秒 Pod spec 创建/更新/删除数 用户发起请求数不超过 20。稳态 SLI/SLO 关键指标状态SLI99 百分位5 分钟窗口SLO默认安装每 cluster-dayOfficial单对象 mutating API 调用处理延迟按 resource/verb 对每 (resource, verb) 对 ≤ 1sOfficial非流式只读 API 调用处理延迟按 resource/scope 对resource 作用域 ≤ 1snamespace/cluster 作用域 ≤ 30sOfficial可调度无状态 Pod 启动延迟不含拉镜像与 init 容器从创建到全部容器经 watch 观察到 started≤ 5sWIP有状态 Pod 启动延迟≤ X取决于存储提供商WIP负载均衡机制如 iptables编程延迟≤ XWIPDNS 实例编程延迟≤ XWIP集群内网络/DNS 延迟、首包延迟、吞吐量≤ X受节点间 RTT 约束关键细节详见 api_call_latency.md 与 pod_startup_latency.mdAPI 调用延迟只度量 apiserver 自身的处理时间排除 webhook1.23与 API priority fairness 队列等待时间1.27——这些是集群管理员可控的外部因素只读请求的 SLO 排除 watch 流式请求内部即 GET 与 LIST历史上 namespace 作用域 LIST 阈值为 5s后因单 namespace 可容纳数万对象的使用模式变化调整为 30sPod 启动延迟只统计可立即调度、无需抢占的 Pod有状态/无状态按挂载卷来源区分已启动定义为所有容器都经 watch 报告为 started而非 readiness因为 readiness 与应用强相关。阈值表与 Scalability EnvelopeSLO 成立的前提之一是集群负载不超限具体数量阈值见 thresholds.md。该文档用一个关键概念解释阈值间的耦合关系——Scalability Envelope可扩展性包络面包络面的属性它不是立方体维度之间相互依赖、不是凸的、沿某一维度推进越远时其余维度的横截面越小、有界、可分解为更小的包络面。这意味着阈值不是独立恒定的而是相互牵制的。当前主要阈值摘录builtin 资源、sharded etcd 下的 OSS 默认安装数量维度namespace 作用域cluster 作用域#Nodes—5000#Namespaces—10000#Pods3000150000#Pods per nodemin(110, 10×核数)min(110, 10×核数)#Services500010000#Endpoints per service250—#Deployments2000—#AccessTokens20002000对象数量非 Event/ 单对象大小 / 总量—150000 / 1.5MB / 1.5GB需要特别说明的 caveats多数阈值不是硬限制超限表现为性能劣化而非集群立即宕机cluster 作用域阈值针对最大规模集群给出较小集群应按比例下调官方 release-blocking 规模测试的基准环境从 2025 年 12 月起运行于 kops 之上。控制平面的具体选型参考见 provider-configs.md如 Google n1-standard-64、AWS m4.16xlarge 等机型以及拆分 etcd、独立 IOPS 等要求。子项目与工作组现状年度报告确认了五个继续运行的子项目与 README.md 中的定义对应kubernetes-scalability-and-performance-tests-and-validation确保验证规模与性能所需的测试齐备提供易用框架、与各 SIG 协作并按日历执行、确保每个官方 release 满足可扩展性定义kubernetes-scalability-bottlenecks-detection发现、记录规模瓶颈并推动跨 SIG 架构变更消除它们相关案例见 k8s-services-scalability-issues.mdkubernetes-scalability-definition定义Kubernetes 可扩展的含义即制定/批准各 SLI/SLO并度量、发布 limits 与规模化部署建议kubernetes-scalability-governance沉淀可扩展性设计与实现的最佳实践回归案例研究见 scalability-regressions-case-studies.mdkubernetes-scalability-test-frameworks打造让所有贡献者都能轻松进行规模/性能测试的框架Cluster Loader v2、Kubemark。报告未列出 2024 年新增的工作组Working Groups条目。此外2024 年报告反映了 SIG 与 CNCF 生态的持续联动例如在 EU KubeCon巴黎上做了 SIG Scalability Intro Deep-Dive 分享介绍 SIG 定位与 2024 年工作。社区协作方向与治理自检面向各 SIG 的求援点报告明确呼吁各 SIG 在以下方面与 SIG Scalability 协作倍增force-multiply各自负责组件/特性的可扩展性测试覆盖与回归排查主动识别并文档化自己负责的 API 与工作流的 SLI/SLO/limits——就像对待 uptime/availability 一样为各自系统设定可扩展性基准让可扩展性成为 Kubernetes 及相关 CNCF 项目的一等公民SIG Scalability 承诺全程提供指导与咨询。报告还指出 2024 年来自多家公司的贡献保持健康相关贡献统计可在 CNCF devstats 的 SIG Scalability 视图查看。Operational 治理自检作为年度例行工作2024 年报告对以下运营项做了逐项核验全部勾选通过复核并更新 README.md 的准确性复核并更新 CONTRIBUTING.md复核并更新 contributors/devel 等其他贡献文档复核并更新 sigs.yaml 中的子项目列表及关联 OWNERS 文件确认 sigs.yaml 中的 SIG 领导人chairs、tech leads、subproject leads准确且在任确保 2024 年会议纪要与录像已从 README.md 链接并更新。结语从年度报告看可扩展性的制度基建把 2024 年年度报告与本仓库中的治理文档对照阅读可以清晰看到 SIG Scalability 的运作模式用精确的 SLI/SLO 定义何为可扩展slos.md、thresholds.md用三层防线与合并阻塞机制守住回归不得进入block_merges.md、formal-scalability-processes.md再用测试框架与每日大集群验证把每个版本都满足 SLO变成可执行的纪律。2024 年围绕 watch cacheConsistent Reads、Streaming List、Resilient initialization与序列化CBOR的四项 KEP正是这套机制催生出的核心组件减负动作其成果将在后续版本的 API Server 与 etcd 路径上持续兑现。对于希望深度参与的贡献者从 slos.md 理解 SLO 语义、从 thresholds.md 掌握规模边界、再对照 scalability-regressions-case-studies.md 学习历史案例是最快的入门路径。【免费下载链接】communityKubernetes Community Documentation项目地址: https://gitcode.com/GitHub_Trending/com/community创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考
