Kubernetes SIG Node CI 子组 2022 年度纪要解读从多 NUMA 测试缺口到 Testgrid 矩阵治理【免费下载链接】communityKubernetes Community Documentation项目地址: https://gitcode.com/GitHub_Trending/com/communitySIG Node CI 子组ci-testing subproject是 Kubernetes 社区负责维护节点端到端e2e测试健康度、进行失败用例 triage、优化测试矩阵的一线团队。本文基于该子组 2022 年全年周会的归档纪要sig-node/archive/ci-subgroup-notes-2022.md系统梳理这一年围绕 Topology Manager 多 NUMA 测试缺口、容器运行时与镜像生态迁移、Testgrid 测试矩阵命名与清理、eviction 等 flaky 用例治理、kubelet 性能回归监控所展开的核心工作帮助读者理解 Kubernetes 节点测试基础设施是如何被运营起来的以及每个议题背后的技术细节与可复现的排查命令。一、背景SIG Node CI 子组的定位与目标SIG Node CI 子组由 SIG Node 社区的志愿者组成其章程sig-node/sig-node-ci-testing-group-charter.md明确了它的成立动因SIG Node 拥有大量与节点能力相关的代码与二进制产物社区为此积累了数量庞大的 e2e 测试用例而随着每日大量 PR 合入、各发行版 OS 镜像持续更新维护这些测试并同步跟进 bug triage 的挑战越来越大于是形成了专门的 CI 子项目。从章程中可以看到该子组的目标十分具体维护既有 node e2e 测试的健康度及时 triage 并修复失败用例尤其是 release-blocking 用例、移除废弃测试、改进失败诊断工具与文档提升测试代码质量识别并降低 flaky 行为、审查新增 e2e 测试代码提升测试覆盖识别覆盖缺口并推动补齐OS 镜像与依赖支持确保覆盖有代表性的 OS 镜像集合与容器运行时版本集合测试资源利用与成本优化提高 SIG Node 测试的 ROI在不同云上分散测试以更好地利用云额度保证关键 bug 的及时响应定期 triage、识别关键问题并跟进在每个版本发布前审查高优先级 bug。在仓库的 sigs.yaml 中ci-testing 子项目被正式登记其 owners 覆盖了test/e2e/common、test/e2e/node、test/e2e_node等测试代码目录以及 test-infra 中config/jobs/kubernetes/sig-node、config/testgrids/kubernetes/sig-node、jobs/e2e_node等作业与 Testgrid 配置目录邮件列表为 sig-node-ci。SIG Node 主 READMEsig-node/README.md也确认了每周三的 Weekly CI/Triage Meeting2022 年的会议纪要即归档于 sig-node/archive/ 下的ci-subgroup-notes-2022.md。二、核心议题一Topology Manager 与多 NUMA 测试基础设施缺口2022 年 CI 子组最具战略意义的一个议题是Topology Manager 因 CI 基础设施缺乏多 NUMA 机器而无法运行 e2e 测试这被明确视为其 GA 毕业路上的潜在阻塞项。在 12/07 的会议上社区成员指出Topology Manager 的 e2e 测试需要多 NUMA 节点而当时 Kubernetes CI 基础设施中没有这类机器因此相关测试一直无法在官方 CI 上执行。会上提出了 GCP Compute Optimized 系列机型如 C2-standard-60的设想但与会者一致认为在购买昂贵的机器之前应当先与 k8s infra 团队沟通。随后 Sergey 在 12/07 与 12/14 的会议中给出了两个当时在 GCP 上最便宜的、带 NUMA 的机型实测结果n2-standard-32约 $908.47/月n2d-standard-32约 $790.49/月。验证这两类机型是否具备 NUMA 能力的完整命令链为grep NUMAy /boot/config-$(uname -r) lscpu | grep -i numa在 n2-standard-32 与 n2d-standard-32 上的实测输出均为CONFIG_NUMAy CONFIG_X86_64_ACPI_NUMAy CONFIG_ACPI_NUMAy NUMA node(s): 2 NUMA node0 CPU(s): 0-7,16-23 NUMA node1 CPU(s): 8-15,24-31即内核开启了 NUMA 支持CONFIG_NUMA、CONFIG_X86_64_ACPI_NUMA、CONFIG_ACPI_NUMA且系统识别出 2 个 NUMA 节点各跨两个 CPU 段——这是运行 Topology Manager e2e 测试所必需的基础条件。12/14 会议上还讨论了为 multi-numa 相关测试引入新的 label并由 Swati 启动 POC后续通过打标签和优化来清理测试。该议题并非孤立存在在同年 SIG Node 主会议sig-node/archive/meeting-notes-2022.md中Topology Manager 的 GA 毕业同样被反复提及且当时需要多 NUMA 环境的 e2e 测试在 release-1.26 分支中仍处于跳过状态。这从侧面印证了 CI 基础设施尤其是特殊硬件/拓扑能力对特性毕业节奏的真实制约——CI 子组的工作不仅是修测试还包括为特性验证扫清基础设施障碍。三、核心议题二容器运行时与镜像生态的大迁移2022 年是 Kubernetes 节点测试镜像与运行时生态剧烈变动的一年CI 子组的周会几乎贯穿了三条主线3.1 从 gcr.io 到 registry.k8s.io 的 Great Migration03/16 会议提出向 registry.k8s.io 全面迁移并讨论了如何验证默认 sandbox image 变更kubelet 侧默认沙箱镜像定义位于cmd/kubelet/app/options/container_runtime.gopodSandboxImage相关默认值03/23 会议要求同步修改 containerd 配置以适配新 registry对应 test-infra 的多份配置 PR因作者缺席与会者被提醒如果看到与此变更相关的失败请直接回滚04/06 会议推进了 CRI-O 侧切换到 registry.k8s.io 的 PR并讨论了从自定义镜像迁移出去的议题k8s.io 仓库 issue #1527。这是一次波及所有运行时作业的镜像源迁移任何测试作业的镜像拉取配置不一致都会直接导致 CI 失败因此 CI 子组承担了迁移的验证与回滚决策职责。3.2 dockershim 移除后的 presubmit 作业清理随着 dockershim 从 kubelet 中移除大量仍然依赖 dockershim 的 presubmit 作业需要被清理或迁移01/05 会议提出Maybe delete all and only bring back those we need先全部删除只恢复确实需要的作业并明确了 1.24 的两个目标迁移到 kubetest2以及迁移到公共项目池02/23 会议继续清理剩余的 dockershim presubmitgce 相关的清理单独拆成 PR。3.3 kubelet 与运行时 cgroup 驱动的一致性11/16 会议讨论了一个长期存在、且不容易被发现的问题kubelet 与容器运行时之间 cgroup 驱动不匹配。当 kubelet 使用systemd驱动而运行时如 containerd 1.5 时代的部分配置使用cgroupfs两者写入不同 cgroup 层级会导致资源统计错乱但这类问题往往不会立刻暴露为明显失败。会议确定的策略是cgroupv2 将成为主要测试目标用更统一的 cgroup 模型来收敛这类不一致。同年的主会议记录也印证了 cgroupv2 是贯穿全年的工作重点包括 in-place pod resize 的 cgroupv2 支持、用户态 OOM killer 在 cgroupv2 下的标准化等。CI 子组在此承担的是确保 cgroupv1/cgroupv2 双模式下的 e2e 作业如cos-cgroupv2-containerd-node-e2e-serial持续健康运行并把 cgroupv2 作为首要验证对象。四、核心议题三Testgrid 矩阵审查与测试命名规范Testgridhttps://testgrid.k8s.io是 Kubernetes 社区展示 CI 作业健康度的仪表盘SIG Node 的作业按sig-node-*系列 tab 组织。2022 年 CI 子组花了大量精力审查并清理这套矩阵。4.1 测试命名一致性讨论01/12会议集中讨论了测试作业的命名规范核心诉求是不要让人以为我们测试了每个平台Dont make an impression that we test every platform除非必要不要在名字中包含 OS 名称容器运行时是必须体现的信息且至少需要测试两个容器运行时——但如何决定选哪两个Sergey 的建议是运行时可以出现在 sig-node 系列 tab 的命名中但不要出现在 release-blocking 测试的命名里命名方案需要统一对齐涉及维度包括e2e与node_e2e的区别、OS、容器运行时、运行时版本、测试类型features / serial / 无标记、具体特性名如 hugepages、ci-前缀表示构建部署与pull-/pr-前缀presubmit是否需要合并是否需要测试多个 containerd 版本如果不需要这些测试应该在哪里运行区分e2e/node与e2e_nodeElana 建议当不启动完整集群时使用node-only这样的命名。4.2 Testgrid tab 的增删审查01/05、01/12会议形成的审查清单非常具体包含大量该删则删的决策计划移除sig-node-kubelet下不再有价值的conformance-node-rhel与conformance-node-containerized-rhel作业cgroupv2 相关作业cos-cgroupv2-containerd-node-e2e-serial关联 issue #107062 跟踪benchmark 作业node-e2e-benchmark需要找到 owner 并归档 bug历史 issue #36621eviction 作业node-kubelet-containerd-eviction关联 issue #107063CRI-O 的node-kubelet-serial-crio与ci-crio-cgroupv1-node-e2e-eviction分别关联 issue #107343 与既有讨论COS 相关的soak-cos-gce、e2e-cos-flaky需要询问 COS 团队bsdnetNPD 的ci-npd-e2e-node关联 issue #10706702/09 会议进一步决定移除 sig-node-critical tab其中只有 2 个作业不是一个有用的视图01/19 会议还发现 CRI-O alpha tab 实际在跑 conformance、containerd 缺少 Flaky tab 等矩阵结构问题。这种逐 tab 过一遍、每个红色作业都有 issue 或 owner的工作方式正是 CI 子组保证测试矩阵可持续的关键方法论也对应了章程中Identify, document release-blocking tests的可持续性目标。五、核心议题四flaky 治理与 eviction 测试的攻防战eviction驱逐相关测试是 2022 年最顽固的 flaky 来源之一CI 子组对它的排查过程极具代表性。5.1 磁盘驱逐测试30Gi 磁盘太慢填不满在 04/27 会议上针对sig-node-containerd下node-kubelet-containerd-eviction作业的长期失败社区给出了相当细致的根因分析问题已知、修法未知Problem is mostly known, fixing of it is unknown测试之间存在相互干扰并且测试与宿主机的状态互相干扰——建议磁盘压力测试改用其他磁盘关键细节测试试图填满整个磁盘来触发 imagefs 驱逐但 30Gi 的磁盘填充非常慢超时很可能就是由填充速度导致的。对此02/02 会议提出的优化方向是创建一个小的 tmpfs 用于磁盘压力测试这样更容易快速填满并稳定触发驱逐条件。此外04/27 还指出驱逐优先级的问题——当容器存储被写满时哪个 pod 先被驱逐取决于imagefs.available的统计而 05/25 会议上有人提出了一个尖锐的问题为什么 EvictionHard 的imagefs.available默认值与 ImageGC 的ImageGCHighThresholdPercent相同这直接关系到磁盘压力场景下驱逐与镜像 GC 的先后行为。5.2 PID 驱逐cadvisor 返回 0 值07/27 会议记录了一个跨组件的问题containerd 的 PidEviction 测试失败原因是 cadvisor 上报的 PID 统计为 0导致 PID 驱逐优先级随机。这可能也是其他测试失败的潜在原因。由于涉及 cadvisor 代码库会议请求 David 介入排查——这展示了 flaky 问题如何跨越 kubelet、CRI 运行时与监控组件多个代码库。5.3 swap、AppArmor 与其他 flaky 矩阵swap 测试kubelet-gce-e2e-swap-fedora-serial、kubelet-gce-e2e-swap-ubuntu-serial等作业在 04/27 被点名已有对应 PR 在修复同年主会议记录也提到 swap-fedora 作业持续失败AppArmor 测试01/05 会议发现kubelet-gce-e2e-swap-ubuntu及 containerd 相关作业中的 AppArmor 失败需归档 bugissue #107342GPU / device plugin 测试01/26 会议报告e2e-cos-device-plugin-gpu等作业wouldnt start并归档 issue #10780006/01 会议 fromani 带来了重新启用 device plugin 测试的 PR 进展称mostly good newsdensity 测试06/29 会议 paco 提交了修复 pod 创建密度测试的 PR 等待批准NPD soak 测试soak-cos-gce在 NPD 相关 PR 合入后持续失败疑似 CI 未使用最新代码。这些记录共同揭示了一个事实SIG Node 的 flaky 治理是一场持久战其根因往往不是单一测试问题而是磁盘 IO 速度、监控统计口径、运行时版本、主机环境相互作用的综合体。CI 子组的价值就在于把这些分散的信号汇总、归因并分配到具体的 owner。六、核心议题五kubelet 性能回归监控CI 子组同时承担着节点侧性能回归的哨兵职责主要通过 perf-dash 与 100 节点规模测试来监控 kubelet 的资源占用03/16 会议发现 kubelet CPU/内存出现可疑变化随即file a bug to investigate并给出了 perf-dash 上gce-100Nodes-master作业LoadResources指标中 kubelet 的 CPU 与 memory 对比数据要求持续观察02/02 会议观察到 perf dashboard 上运行时内存出现小幅上升计划下周看是否回落形成同一模式03/30 会议确认了一个 kubelet CPU 性能回归并关联到了 Slack 上的修复讨论02/09 会议上gcloud auth login失败导致大量测试无法运行被定性为 critical-urgent——基础设施本身的问题同样在 triage 范围内06/15 会议宣布 Brian 接手性能测试xmcqueen。七、核心议题六测试覆盖与代码质量改进04/27 会议是全年关于测试质量讨论最深入的一次主题是规划可靠性/可维护性改进。核心结论包括增加测试和必要的重构占用的是同一批 reviewer 的带宽必须提高这项工作的优先级kubelet 的 PR 将被thoroughly reviewed for the proper coverage改善测试覆盖是合入新代码的前提当前覆盖不足的两个典型领域failure modes testing失败模式测试和预期行为没有明确规范sometimes expected behavior is not specified clearly提出可以为这类工作静态分配更多时间statically allocate more time。与之呼应的是 02/09 会议Danielle 开始在pkg/kubelet/...各处补充单元测试并公开征集 review。锁竞争lock contention测试也是一条持续的线索01/05 会议回顾了锁文件竞争测试的由来与推进计划02/16 会议决定恢复此前被移除的锁竞争测试作业并持续推进相关 PR。这些都属于章程中Improving test code quality与Improving test coverage两大目标的落地动作。八、年度工作节奏与治理机制从纪要本身还能读出 CI 子组的运营节奏会议基本每周三举行但会随美国节假日11/23 感恩节周与 code freeze07/27取消也会因 Zoom 2FA 问题06/22、主持人不可用11/02等技术原因临时取消每次会议结构清晰Attendees / Agenda议题多为三到五条重点围绕 triage、release-blocking 状态、特定 flaky 作业的根因讨论与发布周期强对齐11/09 会议恰逢 code freeze 前夜逐项核对 v1.26 的 release-blocking PR 与 issue包括可能影响 pod vertical scaling 测试的 issue #113791 等11/16 确认nothing release blocking12/14 会议讨论了 block ephemeral containers for Static Pods 等合入 PR以及向 1.23 分支 backport registry 迁移的 PR人员轮换也是治理的一部分04/20 会议宣布 Elana 在 1.25 周期休假并卸任 CI 子项目 lead提名 Danielle 接任06/15 会议 Sergey 宣布休育儿假至 9 月期间由其他成员轮流主持——这些记录在 sig-node/archive/README.md 中有系统归档。此外01/12 会议还提议使用 Google Sheets 追踪 Testgrid 状态Kubernetes SIG-Node CI Testgrid Tracker并讨论了单 tab 追踪延续性push vs pull 获取状态tab 到测试的映射与长时历史等方案取舍——这是测试矩阵治理从临时讨论走向工具化的探索。九、从 2022 到后续一份可追溯的治理档案这份 2022 年纪要并非孤立的会议流水账而是与仓库中其他文档共同构成一套完整的治理档案sig-node/sig-node-ci-testing-group-charter.md子组的章程与目标定义sig-node/README.mdci-testing 子项目登记、Weekly CI/Triage 会议入口与联系方式sigs.yamlci-testing 子项目的正式定义与 owners 清单sig-node/archive/ci-subgroup-notes-2021.md 与 sig-node/archive/ci-subgroup-notes-2023.md前后相邻年份的连续性记录2021 年已出现 fake NUMA flag 的探索2023 年延续 Topology Manager GA 与多 NUMA 议题的推进。对于想要深入参与 Kubernetes 节点测试基础设施的开发者这份纪要提供了三条可直接上手的路径一是对照 Testgrid 的 sig-node 系列 tab 复现 2022 年的逐 tab 审查方法为每个红色作业找到 owner 与 issue二是参考多 NUMA 验证命令在自有测试环境复现 Topology Manager 的测试前提三是沿着 kubelet 相关测试目录 与 test-infra 作业配置config/jobs/kubernetes/sig-node补齐测试覆盖——这正是该子组一年又一年在做的事。【免费下载链接】communityKubernetes Community Documentation项目地址: https://gitcode.com/GitHub_Trending/com/community创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 Kubernetes SIG Node CI 子组 2022 年度纪要解读：从多 NUMA 测试缺口到 Testgrid 矩阵治理
Kubernetes SIG Node CI 子组 2022 年度纪要解读从多 NUMA 测试缺口到 Testgrid 矩阵治理【免费下载链接】communityKubernetes Community Documentation项目地址: https://gitcode.com/GitHub_Trending/com/communitySIG Node CI 子组ci-testing subproject是 Kubernetes 社区负责维护节点端到端e2e测试健康度、进行失败用例 triage、优化测试矩阵的一线团队。本文基于该子组 2022 年全年周会的归档纪要sig-node/archive/ci-subgroup-notes-2022.md系统梳理这一年围绕 Topology Manager 多 NUMA 测试缺口、容器运行时与镜像生态迁移、Testgrid 测试矩阵命名与清理、eviction 等 flaky 用例治理、kubelet 性能回归监控所展开的核心工作帮助读者理解 Kubernetes 节点测试基础设施是如何被运营起来的以及每个议题背后的技术细节与可复现的排查命令。一、背景SIG Node CI 子组的定位与目标SIG Node CI 子组由 SIG Node 社区的志愿者组成其章程sig-node/sig-node-ci-testing-group-charter.md明确了它的成立动因SIG Node 拥有大量与节点能力相关的代码与二进制产物社区为此积累了数量庞大的 e2e 测试用例而随着每日大量 PR 合入、各发行版 OS 镜像持续更新维护这些测试并同步跟进 bug triage 的挑战越来越大于是形成了专门的 CI 子项目。从章程中可以看到该子组的目标十分具体维护既有 node e2e 测试的健康度及时 triage 并修复失败用例尤其是 release-blocking 用例、移除废弃测试、改进失败诊断工具与文档提升测试代码质量识别并降低 flaky 行为、审查新增 e2e 测试代码提升测试覆盖识别覆盖缺口并推动补齐OS 镜像与依赖支持确保覆盖有代表性的 OS 镜像集合与容器运行时版本集合测试资源利用与成本优化提高 SIG Node 测试的 ROI在不同云上分散测试以更好地利用云额度保证关键 bug 的及时响应定期 triage、识别关键问题并跟进在每个版本发布前审查高优先级 bug。在仓库的 sigs.yaml 中ci-testing 子项目被正式登记其 owners 覆盖了test/e2e/common、test/e2e/node、test/e2e_node等测试代码目录以及 test-infra 中config/jobs/kubernetes/sig-node、config/testgrids/kubernetes/sig-node、jobs/e2e_node等作业与 Testgrid 配置目录邮件列表为 sig-node-ci。SIG Node 主 READMEsig-node/README.md也确认了每周三的 Weekly CI/Triage Meeting2022 年的会议纪要即归档于 sig-node/archive/ 下的ci-subgroup-notes-2022.md。二、核心议题一Topology Manager 与多 NUMA 测试基础设施缺口2022 年 CI 子组最具战略意义的一个议题是Topology Manager 因 CI 基础设施缺乏多 NUMA 机器而无法运行 e2e 测试这被明确视为其 GA 毕业路上的潜在阻塞项。在 12/07 的会议上社区成员指出Topology Manager 的 e2e 测试需要多 NUMA 节点而当时 Kubernetes CI 基础设施中没有这类机器因此相关测试一直无法在官方 CI 上执行。会上提出了 GCP Compute Optimized 系列机型如 C2-standard-60的设想但与会者一致认为在购买昂贵的机器之前应当先与 k8s infra 团队沟通。随后 Sergey 在 12/07 与 12/14 的会议中给出了两个当时在 GCP 上最便宜的、带 NUMA 的机型实测结果n2-standard-32约 $908.47/月n2d-standard-32约 $790.49/月。验证这两类机型是否具备 NUMA 能力的完整命令链为grep NUMAy /boot/config-$(uname -r) lscpu | grep -i numa在 n2-standard-32 与 n2d-standard-32 上的实测输出均为CONFIG_NUMAy CONFIG_X86_64_ACPI_NUMAy CONFIG_ACPI_NUMAy NUMA node(s): 2 NUMA node0 CPU(s): 0-7,16-23 NUMA node1 CPU(s): 8-15,24-31即内核开启了 NUMA 支持CONFIG_NUMA、CONFIG_X86_64_ACPI_NUMA、CONFIG_ACPI_NUMA且系统识别出 2 个 NUMA 节点各跨两个 CPU 段——这是运行 Topology Manager e2e 测试所必需的基础条件。12/14 会议上还讨论了为 multi-numa 相关测试引入新的 label并由 Swati 启动 POC后续通过打标签和优化来清理测试。该议题并非孤立存在在同年 SIG Node 主会议sig-node/archive/meeting-notes-2022.md中Topology Manager 的 GA 毕业同样被反复提及且当时需要多 NUMA 环境的 e2e 测试在 release-1.26 分支中仍处于跳过状态。这从侧面印证了 CI 基础设施尤其是特殊硬件/拓扑能力对特性毕业节奏的真实制约——CI 子组的工作不仅是修测试还包括为特性验证扫清基础设施障碍。三、核心议题二容器运行时与镜像生态的大迁移2022 年是 Kubernetes 节点测试镜像与运行时生态剧烈变动的一年CI 子组的周会几乎贯穿了三条主线3.1 从 gcr.io 到 registry.k8s.io 的 Great Migration03/16 会议提出向 registry.k8s.io 全面迁移并讨论了如何验证默认 sandbox image 变更kubelet 侧默认沙箱镜像定义位于cmd/kubelet/app/options/container_runtime.gopodSandboxImage相关默认值03/23 会议要求同步修改 containerd 配置以适配新 registry对应 test-infra 的多份配置 PR因作者缺席与会者被提醒如果看到与此变更相关的失败请直接回滚04/06 会议推进了 CRI-O 侧切换到 registry.k8s.io 的 PR并讨论了从自定义镜像迁移出去的议题k8s.io 仓库 issue #1527。这是一次波及所有运行时作业的镜像源迁移任何测试作业的镜像拉取配置不一致都会直接导致 CI 失败因此 CI 子组承担了迁移的验证与回滚决策职责。3.2 dockershim 移除后的 presubmit 作业清理随着 dockershim 从 kubelet 中移除大量仍然依赖 dockershim 的 presubmit 作业需要被清理或迁移01/05 会议提出Maybe delete all and only bring back those we need先全部删除只恢复确实需要的作业并明确了 1.24 的两个目标迁移到 kubetest2以及迁移到公共项目池02/23 会议继续清理剩余的 dockershim presubmitgce 相关的清理单独拆成 PR。3.3 kubelet 与运行时 cgroup 驱动的一致性11/16 会议讨论了一个长期存在、且不容易被发现的问题kubelet 与容器运行时之间 cgroup 驱动不匹配。当 kubelet 使用systemd驱动而运行时如 containerd 1.5 时代的部分配置使用cgroupfs两者写入不同 cgroup 层级会导致资源统计错乱但这类问题往往不会立刻暴露为明显失败。会议确定的策略是cgroupv2 将成为主要测试目标用更统一的 cgroup 模型来收敛这类不一致。同年的主会议记录也印证了 cgroupv2 是贯穿全年的工作重点包括 in-place pod resize 的 cgroupv2 支持、用户态 OOM killer 在 cgroupv2 下的标准化等。CI 子组在此承担的是确保 cgroupv1/cgroupv2 双模式下的 e2e 作业如cos-cgroupv2-containerd-node-e2e-serial持续健康运行并把 cgroupv2 作为首要验证对象。四、核心议题三Testgrid 矩阵审查与测试命名规范Testgridhttps://testgrid.k8s.io是 Kubernetes 社区展示 CI 作业健康度的仪表盘SIG Node 的作业按sig-node-*系列 tab 组织。2022 年 CI 子组花了大量精力审查并清理这套矩阵。4.1 测试命名一致性讨论01/12会议集中讨论了测试作业的命名规范核心诉求是不要让人以为我们测试了每个平台Dont make an impression that we test every platform除非必要不要在名字中包含 OS 名称容器运行时是必须体现的信息且至少需要测试两个容器运行时——但如何决定选哪两个Sergey 的建议是运行时可以出现在 sig-node 系列 tab 的命名中但不要出现在 release-blocking 测试的命名里命名方案需要统一对齐涉及维度包括e2e与node_e2e的区别、OS、容器运行时、运行时版本、测试类型features / serial / 无标记、具体特性名如 hugepages、ci-前缀表示构建部署与pull-/pr-前缀presubmit是否需要合并是否需要测试多个 containerd 版本如果不需要这些测试应该在哪里运行区分e2e/node与e2e_nodeElana 建议当不启动完整集群时使用node-only这样的命名。4.2 Testgrid tab 的增删审查01/05、01/12会议形成的审查清单非常具体包含大量该删则删的决策计划移除sig-node-kubelet下不再有价值的conformance-node-rhel与conformance-node-containerized-rhel作业cgroupv2 相关作业cos-cgroupv2-containerd-node-e2e-serial关联 issue #107062 跟踪benchmark 作业node-e2e-benchmark需要找到 owner 并归档 bug历史 issue #36621eviction 作业node-kubelet-containerd-eviction关联 issue #107063CRI-O 的node-kubelet-serial-crio与ci-crio-cgroupv1-node-e2e-eviction分别关联 issue #107343 与既有讨论COS 相关的soak-cos-gce、e2e-cos-flaky需要询问 COS 团队bsdnetNPD 的ci-npd-e2e-node关联 issue #10706702/09 会议进一步决定移除 sig-node-critical tab其中只有 2 个作业不是一个有用的视图01/19 会议还发现 CRI-O alpha tab 实际在跑 conformance、containerd 缺少 Flaky tab 等矩阵结构问题。这种逐 tab 过一遍、每个红色作业都有 issue 或 owner的工作方式正是 CI 子组保证测试矩阵可持续的关键方法论也对应了章程中Identify, document release-blocking tests的可持续性目标。五、核心议题四flaky 治理与 eviction 测试的攻防战eviction驱逐相关测试是 2022 年最顽固的 flaky 来源之一CI 子组对它的排查过程极具代表性。5.1 磁盘驱逐测试30Gi 磁盘太慢填不满在 04/27 会议上针对sig-node-containerd下node-kubelet-containerd-eviction作业的长期失败社区给出了相当细致的根因分析问题已知、修法未知Problem is mostly known, fixing of it is unknown测试之间存在相互干扰并且测试与宿主机的状态互相干扰——建议磁盘压力测试改用其他磁盘关键细节测试试图填满整个磁盘来触发 imagefs 驱逐但 30Gi 的磁盘填充非常慢超时很可能就是由填充速度导致的。对此02/02 会议提出的优化方向是创建一个小的 tmpfs 用于磁盘压力测试这样更容易快速填满并稳定触发驱逐条件。此外04/27 还指出驱逐优先级的问题——当容器存储被写满时哪个 pod 先被驱逐取决于imagefs.available的统计而 05/25 会议上有人提出了一个尖锐的问题为什么 EvictionHard 的imagefs.available默认值与 ImageGC 的ImageGCHighThresholdPercent相同这直接关系到磁盘压力场景下驱逐与镜像 GC 的先后行为。5.2 PID 驱逐cadvisor 返回 0 值07/27 会议记录了一个跨组件的问题containerd 的 PidEviction 测试失败原因是 cadvisor 上报的 PID 统计为 0导致 PID 驱逐优先级随机。这可能也是其他测试失败的潜在原因。由于涉及 cadvisor 代码库会议请求 David 介入排查——这展示了 flaky 问题如何跨越 kubelet、CRI 运行时与监控组件多个代码库。5.3 swap、AppArmor 与其他 flaky 矩阵swap 测试kubelet-gce-e2e-swap-fedora-serial、kubelet-gce-e2e-swap-ubuntu-serial等作业在 04/27 被点名已有对应 PR 在修复同年主会议记录也提到 swap-fedora 作业持续失败AppArmor 测试01/05 会议发现kubelet-gce-e2e-swap-ubuntu及 containerd 相关作业中的 AppArmor 失败需归档 bugissue #107342GPU / device plugin 测试01/26 会议报告e2e-cos-device-plugin-gpu等作业wouldnt start并归档 issue #10780006/01 会议 fromani 带来了重新启用 device plugin 测试的 PR 进展称mostly good newsdensity 测试06/29 会议 paco 提交了修复 pod 创建密度测试的 PR 等待批准NPD soak 测试soak-cos-gce在 NPD 相关 PR 合入后持续失败疑似 CI 未使用最新代码。这些记录共同揭示了一个事实SIG Node 的 flaky 治理是一场持久战其根因往往不是单一测试问题而是磁盘 IO 速度、监控统计口径、运行时版本、主机环境相互作用的综合体。CI 子组的价值就在于把这些分散的信号汇总、归因并分配到具体的 owner。六、核心议题五kubelet 性能回归监控CI 子组同时承担着节点侧性能回归的哨兵职责主要通过 perf-dash 与 100 节点规模测试来监控 kubelet 的资源占用03/16 会议发现 kubelet CPU/内存出现可疑变化随即file a bug to investigate并给出了 perf-dash 上gce-100Nodes-master作业LoadResources指标中 kubelet 的 CPU 与 memory 对比数据要求持续观察02/02 会议观察到 perf dashboard 上运行时内存出现小幅上升计划下周看是否回落形成同一模式03/30 会议确认了一个 kubelet CPU 性能回归并关联到了 Slack 上的修复讨论02/09 会议上gcloud auth login失败导致大量测试无法运行被定性为 critical-urgent——基础设施本身的问题同样在 triage 范围内06/15 会议宣布 Brian 接手性能测试xmcqueen。七、核心议题六测试覆盖与代码质量改进04/27 会议是全年关于测试质量讨论最深入的一次主题是规划可靠性/可维护性改进。核心结论包括增加测试和必要的重构占用的是同一批 reviewer 的带宽必须提高这项工作的优先级kubelet 的 PR 将被thoroughly reviewed for the proper coverage改善测试覆盖是合入新代码的前提当前覆盖不足的两个典型领域failure modes testing失败模式测试和预期行为没有明确规范sometimes expected behavior is not specified clearly提出可以为这类工作静态分配更多时间statically allocate more time。与之呼应的是 02/09 会议Danielle 开始在pkg/kubelet/...各处补充单元测试并公开征集 review。锁竞争lock contention测试也是一条持续的线索01/05 会议回顾了锁文件竞争测试的由来与推进计划02/16 会议决定恢复此前被移除的锁竞争测试作业并持续推进相关 PR。这些都属于章程中Improving test code quality与Improving test coverage两大目标的落地动作。八、年度工作节奏与治理机制从纪要本身还能读出 CI 子组的运营节奏会议基本每周三举行但会随美国节假日11/23 感恩节周与 code freeze07/27取消也会因 Zoom 2FA 问题06/22、主持人不可用11/02等技术原因临时取消每次会议结构清晰Attendees / Agenda议题多为三到五条重点围绕 triage、release-blocking 状态、特定 flaky 作业的根因讨论与发布周期强对齐11/09 会议恰逢 code freeze 前夜逐项核对 v1.26 的 release-blocking PR 与 issue包括可能影响 pod vertical scaling 测试的 issue #113791 等11/16 确认nothing release blocking12/14 会议讨论了 block ephemeral containers for Static Pods 等合入 PR以及向 1.23 分支 backport registry 迁移的 PR人员轮换也是治理的一部分04/20 会议宣布 Elana 在 1.25 周期休假并卸任 CI 子项目 lead提名 Danielle 接任06/15 会议 Sergey 宣布休育儿假至 9 月期间由其他成员轮流主持——这些记录在 sig-node/archive/README.md 中有系统归档。此外01/12 会议还提议使用 Google Sheets 追踪 Testgrid 状态Kubernetes SIG-Node CI Testgrid Tracker并讨论了单 tab 追踪延续性push vs pull 获取状态tab 到测试的映射与长时历史等方案取舍——这是测试矩阵治理从临时讨论走向工具化的探索。九、从 2022 到后续一份可追溯的治理档案这份 2022 年纪要并非孤立的会议流水账而是与仓库中其他文档共同构成一套完整的治理档案sig-node/sig-node-ci-testing-group-charter.md子组的章程与目标定义sig-node/README.mdci-testing 子项目登记、Weekly CI/Triage 会议入口与联系方式sigs.yamlci-testing 子项目的正式定义与 owners 清单sig-node/archive/ci-subgroup-notes-2021.md 与 sig-node/archive/ci-subgroup-notes-2023.md前后相邻年份的连续性记录2021 年已出现 fake NUMA flag 的探索2023 年延续 Topology Manager GA 与多 NUMA 议题的推进。对于想要深入参与 Kubernetes 节点测试基础设施的开发者这份纪要提供了三条可直接上手的路径一是对照 Testgrid 的 sig-node 系列 tab 复现 2022 年的逐 tab 审查方法为每个红色作业找到 owner 与 issue二是参考多 NUMA 验证命令在自有测试环境复现 Topology Manager 的测试前提三是沿着 kubelet 相关测试目录 与 test-infra 作业配置config/jobs/kubernetes/sig-node补齐测试覆盖——这正是该子组一年又一年在做的事。【免费下载链接】communityKubernetes Community Documentation项目地址: https://gitcode.com/GitHub_Trending/com/community创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考