企业官网建设流程全解析

Kubernetes SIG Scalability 2021 年度报告深度解读：5000 节点规模化验证与大型服务测试的演进之路

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

SIG Scalability 是 Kubernetes 社区中负责"定义并驱动 Kubernetes 可扩展性目标"的特别兴趣小组。本篇基于该 SIG 的 2021 年度报告 展开，系统梳理其在 2021 年围绕特性规模化验证、大型服务（1000+ Pod）测试、测试框架与基础设施改进、KEP 推进、社区健康度与子项目治理等方面取得的进展，并结合本仓库内的 SLO、阈值、流程与回归案例等一手资料进行纵深解读。读完本文，你将理解 Kubernetes 官方规模化测试体系如何运转、2021 年该体系发生了哪些关键变化，以及社区如何通过"中型/大型测试组合 + 流程化门禁"守住 5000 节点规模的可扩展性底线。

2021 年工作全景：从特性验证到规模化测试

年度报告开篇回顾了 SIG 在 2021 年的两项核心工作：

• 全年协助验证大量特性的可扩展性与可靠性影响：作为 Kubernetes 的"规模化守门人"，SIG 持续对新特性在大型集群下的性能与可靠性表现进行验证，这与其 charter 中"协调并推动系统级可扩展性与性能改进"的定位一脉相承。
• 启动大型服务（1000+ Pod）的可扩展性测试：这是 2021 年测试范围的重要扩展——从"集群容纳更多 Pod"转向"单个服务在承载 1000 个以上 Pod 时仍保持可扩展与可用"。这一方向与仓库中处于 WIP 状态的网络类 SLI 相呼应，例如 network_programming_latency.md 关注的"从 Service spec 或其 Ready Pod 列表变化，到负载均衡机制（如 iptables）完成编程"的延迟，以及 first_packet_latency.md 关注的客户端建立 TCP 连接到收到首个数据包的时间。当单个服务的后端 Pod 规模达到数千级别时，这些指标正是最容易暴露瓶颈的环节。

除上述两项外，报告还明确列出了未通过 KEP 跟踪、但 SIG 一直在推进的基础设施工作，详见下一节。

测试框架与基础设施的持续演进

报告指出，SIG 在 2021 年对测试框架和基础设施做了三处关键改进：

• 为测试引入模块化支持（modules）：将测试代码组织为可复用的模块，降低维护成本，让新增测试场景更加轻量。
• 开始测量 apiserver 的可用性：将"控制面心脏"的可用性纳入观测体系，为后续把可用性纳入 SLO 覆盖范围积累数据。
• 新增对 cilium 传播延迟、DNS 延迟的测量能力：这两项分别对应集群内负载均衡编程与 DNS 编程的端到端生效时间。从仓库结构看，slos 目录 中恰好维护着 dns_programming_latency.md、dns_latency.md 与 network_programming_latency.md 等 WIP 状态 SLI，2021 年新增的测量能力可以推断正是为这些 SLI 的落地与验证提供数据支撑。

这些测试能力的载体集中在 SIG 的kubernetes-scalability-test-frameworks与kubernetes-scalability-and-performance-tests-and-validation两个子项目中。根据 sig-scalability/README.md，前者负责设计可扩展性/性能测试框架（如 Cluster Loader v2 与 Kubemark 模拟集群体系），后者则确保官方发布所需的规模化测试真实存在、按时执行（官方测试、Testgrid 与 Perfdash 均为其组成部分）。

2021 年 KEP 进展一览

2021 年 SIG Scalability 相关 KEP 的推进情况如下（目标版本为对应特性首次进入该阶段的 Kubernetes 版本）：

其中，1040（P&F）是对 API Server 请求队列化与限流机制的重新设计，与规模化场景下的 API 延迟保障直接相关。本仓库 api_call_latency.md 的 Caveats 一节即注明：官方 API 调用延迟 SLI/SLO 明确排除了P&F 队列等待时间（1.27+）以及 Webhook 引入的延迟（1.23+）——因为这两者由集群管理员配置决定，不在默认安装的保证范围内。这从侧面说明，P&F 这类机制的存在会显著影响用户实际感知到的 API 延迟，因此在定义官方 SLO 时必须将其排除，才能保证"默认安装"下的承诺可测量、可实现。

647（APIServer 追踪）与2464（Kubetest2 CI 迁移）则分别呼应了 SIG 在可观测性与测试基础设施上的投入方向：前者为 API Server 引入分布式追踪能力，后者推动 CI 测试向新一代 kubetest2 框架迁移——这也与报告中"改进测试框架与基础设施"的表述互相印证。

项目健康度与人才需求

报告用 6 个问题评估了 SIG 的项目健康度：

• 最需要帮助的领域：所有子项目都欢迎更多人手，但可扩展性测试框架与可扩展性/性能测试与验证是社区新人最容易成长的两个方向；其余方向（如瓶颈探测、可扩展性定义）需要先对 Kubernetes 有"既深且广"的理解，才可能做出合理贡献。
• 社区健康指标：SIG 最关心主仓库perf-tests的指标，通过 devstats 度量，持续跟踪 reviewer 数量、打开的 issue 数与合并的 PR 数。
• 新人引导：CONTRIBUTING.md 明确指向good first issue与help-wanted标签的维护清单，并建议新人优先从测试框架与性能测试入手；在正式投入前，还建议先阅读 Clusterloader2 与可扩展性阈值。
• 审查者要求：SIG 对 reviewer/approver 没有超出通用贡献者指南的特殊要求，但核心领域客观上需要深入的 Kubernetes 知识。
• 多公司参与：2021 年报告确认贡献者来自多家公司/组织。
• 终端用户参与：终端用户通常带着规模化相关问题前来咨询，主动贡献的意愿不强——这解释了为何 SIG 更需要开发者的深度参与。

社区规模与成员数据

报告披露的 2021 年成员规模数据如下：

可见 SIG Scalability 是一个"小核心、大外围"的社区：正式审查力量集中在个位数成员，但 Slack 频道拥有超过 2000 名关注者。这也解释了为何报告反复强调"增加测试框架与测试验证方向的人手"——这是扩大核心圈最现实的路径。

子项目与工作组

2021 年 SIG 的子项目没有新增、也没有退役，以下 5 个子项目全部延续（每个子项目的详细职责与 OWNERS 列表见 sig-scalability/README.md 的 Subprojects 一节）：

1. kubernetes-scalability-and-performance-tests-and-validation：确保官方发布所需的规模化与性能测试齐全、按时执行，并据此判定每个发布是否满足可扩展性要求（相关流程见 processes 目录）。
2. kubernetes-scalability-bottlenecks-detection：发现、记录可扩展性瓶颈并推动架构改进，典型案例分析见 k8s-services-scalability-issues.md。
3. kubernetes-scalability-definition：定义"Kubernetes 可扩展"的含义，维护并批准各项 SLI/SLO 与阈值。
4. kubernetes-scalability-governance：沉淀可扩展性设计最佳实践，回归案例研究 即由该子项目维护。
5. kubernetes-scalability-test-frameworks：设计让所有贡献者都能轻松开展规模化测试的框架（Cluster Loader v2、Kubemark）。

工作组方面，2021 年延续的唯一工作组是WG Reliability（其 2021 年报告未收录于本仓库，可参见归档目录下的 README 了解其定位）。可扩展性与可靠性天然耦合——年度报告中"验证特性的可扩展性与可靠性影响"的表述，正是两个群体协作的缩影。

深层机制：支撑年度规模化验证的 SLI/SLO 体系

要理解 2021 年"验证特性影响、测量 apiserver 可用性、测 DNS 延迟"这些工作背后的逻辑，需要了解 SIG 的可扩展性定义框架。根据 slos.md，Kubernetes 的可扩展性建立在SLI（服务等级指标）与SLO（服务等级目标）两个概念之上，并要求它们具备四个性质：精确且定义清晰、彼此一致、面向用户、可测试。

其核心承诺模型是"你承诺，我承诺"（You promise, we promise）：

如果你承诺：正确配置集群、合理使用扩展性特性、将集群负载控制在推荐阈值内——那么我们就承诺：你的集群是可扩展的，即所有 SLO 均被满足。

围绕这一框架，仓库维护着一张稳态 SLI/SLO 表（见 slos.md），部分关键条目如下：

同时，SLO 的成立还有两个前提：集群可用且提供服务；集群churn（每秒 Pod spec 创建/更新/删除次数与用户请求数之和）≤ 20。这些指标细节可在 api_call_latency.md 与 pod_startup_latency.md 中进一步查看（例如"处理延迟"指 apiserver 收到请求到发出最后一个响应字节的时间，并排除 Webhook 与 P&F 排队等待；Pod 启动延迟定义为"所有容器均报告 started 且通过 watch 观测到"的时刻）。

阈值与"可扩展性包络"

SLO 并非无条件承诺，集群负载必须满足 thresholds.md 中定义的阈值。该文档用一个关键概念总结了多维阈值的复杂性——可扩展性包络（Scalability Envelope）：

包络的关键性质：它不是立方体（维度间并不独立）、不是凸的、沿某一维度前进时其余维度的"截面"会变小、有界、且可分解为更小的包络。这提醒我们，Kubernetes 的规模上限是多个维度（节点数、对象数、单对象大小等）联合约束的结果，而非单个数字。

阈值文档给出了若干量化边界（部分节选，完整表格见原文）：

几个重要 caveat：阈值大多不是硬限制，越过只会导致性能下降而不会立即宕机；集群级阈值针对最大规模集群给出，小集群应等比例降低；阈值随版本演进（只增不减是期望方向）。此外，环境/云厂商相关的阈值（Ingress、PV、PVC 等）尚有多项待定（TBD）。对应的控制面硬件基线（如 Google n1-standard-64、AWS m4.16xlarge，以及 split etcd、独立 IOPS 卷等要求）记录在 provider-configs.md 中。

规模化验证如何落地：自动化、发布门禁与职责分工

2021 年 SIG 的工作之所以能全年覆盖"众多特性的规模化验证"，得益于一套多年沉淀的正式流程。仓库中的两份核心流程文档给出了完整设计：

• scalability-validation.md（发布规模化验证）：提出四个目标——以合理频率自动化大规模集群测试、具体定义发布所用的测试配置、把规模化验证设为发布前置条件、明确各团队对规模测试的职责。文档给出了历史上每天运行的正确性/性能测试日程（如工作日 GCE 5k 节点正确性与性能测试、周末 GKE 5k/2k 测试），并提供了"规模化验证报告"模板（记录云厂商、节点数、节点/主节点规格、非默认配置、任务名与 run# 等），供发布时沉淀配置与结论。
• formal-scalability-processes.md（正式流程）：按"实施/合入前 → 测试/合入后 → 设计/特性提案"三个阶段，由轻到重地建立防线。合入前：提供可选 PR 任务（中型如 Kubemark-500 约 80 vCPU、GCE-100 约 100 vCPU；大型如 Kubemark-5000 约 700 vCPU、GCE-2000 约 2030 vCPU）与强制预合并任务；合入后：让关键规模化任务具备阻塞提交队列的能力；设计阶段：通过needs-scalability-assessment标签 + scalability-assessor/reviewer 角色对特性设计做可扩展性评审。

这两份文档共同回答了"2021 年如何全年验证众多特性"：中型测试高频拦截、大型测试兜底验证、设计评审前置把关。

关于这套机制的实际成效，回归案例研究 给出了数据支撑：约60%的可扩展性回归仅靠中型（且快速）测试（gce-100、kubemark-500）即可捕获，其余大部分由大型测试（kubemark-5k、gce-2k）兜住。案例表记录了多个只在大规模下才会暴露的问题——例如某次 CNI 库更新引入重复地址检测（DAD）步骤，导致 Pod 启动延迟超过 5s SLO；gRPC 库升级改变 apiserver 与 etcd 间默认响应 MTU 后只有规模化测试才能暴露。这也印证了年度报告开头那句"全年协助验证特性的可扩展性与可靠性影响"的分量。

2021 年运维盘点与对外沟通

报告末尾的运维清单确认，SIG 在 2021 年完成了全部治理任务：审查并更新了 README.md 与 CONTRIBUTING.md、核对了 sigs.yaml 中的子项目与 OWNERS、确认了 sig-governance.md 规定的领导人信息准确且在任、更新了会议记录链接，并在 2021 年 Kubecon NA 上向社区做了更新汇报。这些看似"行政"的工作，正是保证规模化测试体系长期可维护、可审计的基石。

总结

SIG Scalability 的 2021 年是"守成与拓界并存"的一年：一方面延续全年性的特性规模化验证，用"SLI/SLO + 阈值 + 三层流程"守住了 Kubernetes 5000 节点规模的可扩展性承诺；另一方面把测试视野从"集群容量"拓展到"单个大型服务（1000+ Pod）"，并在 apiserver 可用性、cilium 传播延迟、DNS 延迟等新维度上补齐测量能力，为 WIP 状态的新 SLI 落地铺路。如果你希望参与 Kubernetes 规模化工作，仓库内的 CONTRIBUTING.md（good first issue 清单）、SLO 文档、阈值文档 与 流程文档 是最好的起点。

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