Kubernetes CRI 运行时测试策略从 Node E2E 必测套件到 TestGrid 结果发布与 pre-submit 准入【免费下载链接】communityKubernetes Community Documentation项目地址: https://gitcode.com/GitHub_Trending/com/community本文是 Kubernetes 社区仓库中由 SIG-Node 维护的 Container Runtime Interface (CRI) 测试策略 的深度解读与实践指南。文章围绕 CRI 运行时维护者必须测什么、怎么测、结果发到哪里、如何晋升为 PR 门禁这条主线展开并结合仓库内 Node E2E 测试框架、CRI 背景文档与 SIG-Node 组织信息进行源码级佐证。读完本文你将掌握 CRI 运行时接入 Kubernetes 测试生态的完整流程、TestGrid 结果发布规范以及本地运行 Node E2E 测试的具体命令与方法。CRI 测试策略的定位与目标CRIContainer Runtime Interface是 kubelet 与容器运行时之间的标准接口由 protobuf API 与配套库组成其背景与演进在 container-runtime-interface.md 中有完整说明在 CRI 出现之前运行时如 docker、rkt必须通过实现 kubelet 内部的高层接口来完成集成入门门槛高且无法扩展CRI 的出现正是为了让容器运行时变成可插拔组件。而本策略文档要解决的是插拔之后的质量问题——当社区涌现出 cri-o、cri-containerd、frakti 等众多运行时实现时如何让社区能够统一、持续地追踪每个运行时的一致性conformance、稳定性stability与特性支持情况。为此SIG-Node 制定了这份测试政策要求 CRI 运行时维护者将测试结果发布到一个联邦化的仪表盘federated dashboard也就是 TestGrid 的sig-node标签页从而为 Kubernetes 社区提供低门槛的运行时质量可视化入口。该策略归属于 SIG-Node其使命、领导层、联络方式与 subproject 划分可参见 sigs.yaml 中sig-node条目文档自身亦声明Owner: SIG-Node。文档聚焦 Node/集群级别的端到端E2E测试原因在于大量 Kubernetes 特性需要运行时、操作系统甚至云厂商的深度集成更高层的集成测试能给社区提供更好的垂直技术栈兼容性信号。与此同时运行时开发者在日常开发中仍被强烈建议运行低层级的CRI validation 测试套件即 cri-tools 提供的 validation 测试。本仓库中对应的说明文档 cri-validation.md 已标记为 DEPRECATED其内容已迁移至 cri-tools 仓库的 validation 文档读者可按需查阅。必测与推荐测试运行时接入的测试基线必测Node 一致性套件与 Node 特性套件运行时维护者**必须required**提交以下两套测试结果Node conformance test suite节点一致性测试套件Node feature test suite节点特性测试套件这两套测试统称为 Node E2E 测试其对象是预装了 CRI 运行时的 OS 镜像。策略对 OS 发行版、打包方式与部署机制不做任何限制——运行时维护者可以自由选择但需要证明该运行时 该 OS 镜像的组合符合 Kubernetes 节点的一致性要求。两者的分工如下conformance 套件一组平台无关不依赖特定 OS、运行时、云厂商的测试用于验证 OS 镜像的一致性是接入的硬性门槛feature 套件允许运行时展示其在特定 OS 发行版上支持哪些特性是差异化能力的展示窗口。关于 Node E2E 测试框架与如何验证兼容 OS 镜像的教程详见仓库内的 e2e-node-tests.md。强烈推荐Kubernetes 集群级一致性测试套件在必测之外运行时维护者被强烈推荐运行并提交Kubernetes conformance test suite集群级一致性测试套件。这套集群级 E2E 测试能覆盖 CRI 与 Node 级测试无法覆盖的领域最典型的就是网络Networking——因为网络需要运行时、云厂商以及其他集群组件之间的深度集成纯节点级测试无法验证。由于涉及面广策略建议运行时维护者向其他相关 SIG如 SIG-GCP、SIG-AWS寻求指导或赞助co-sponsorship。测试选型背后的工程逻辑从 test-suite.md 可以看出这套设计的工程基础Node E2E 测试与常规集群 E2E 测试的最大区别在于基础设施规模——常规 E2E 需要完整集群而 Node E2E 只需 kubelet、apiserver 与 etcd 三件套即可运行因此可以做到轻量、高频、可本地化非常适合作为运行时接入的日常质量信号。这也解释了为何策略把 Node E2E 作为必测、而把集群级测试作为推荐项前者成本可控、信号直接后者覆盖更广但需要更多资源与跨 SIG 协作。测试结果发布流程从提案到 TestGrid第一步提交提案要将测试结果发布到联邦化仪表盘运行时维护者需在 Kubernetes community 仓库中提交一份提案内容要求简要说明你的运行时runtime提供至少两名维护者maintainers将提案指派给SIG-Node 的 leads。这份提案相当于准入申请SIG-Node 通过评审来确定该运行时是否被纳入联邦化测试展示。第二步结果在 TestGrid 中的组织方式测试结果发布在sig-node标签页下目录结构为sig-node - sig-node-cri-{Kubernetes-version} - [page containing the required jobs]即在sig-node主标签页下按 Kubernetes 版本建立sig-node-cri-版本号分组分组内是包含必测 job 的页面。每个版本的页面都对应着该运行时在该 Kubernetes 版本下的必测任务。第三步版本保留策略任何时刻TestGrid 上只保留最近三个 Kubernetes 版本与 master 分支的测试结果。这一策略与 Kubernetes 的发布节奏和策略保持一致——超过三版的旧版本结果会被自动淘汰避免仪表盘被历史数据淹没也让维护者始终聚焦在当前支持范围内的回归信号上。测试任务维护要求发布到仪表盘不是终点而是持续运维的起点。策略对测试任务test job的维护提出明确要求运行频率测试至少需要**每夜nightly**运行一次健康责任运行时维护者对测试的持续健康负责。如果测试被认为未被积极维护not actively maintainedSIG-Node 可以自行决定将测试从测试网格test grid中移除。这意味着发布测试结果相当于与 SIG-Node 达成了一种持续承诺高频运行 及时维护否则会被清出仪表盘。这与 e2e-node-tests.md 中描述的项目自身 CI 实践一致——Node E2E 在 Kubernetes 项目中同时作为 pre-submit 与 post-submit 测试运行结果由 Prow 发布到 PR 状态栏测试的稳定性直接关系到开发迭代速度。晋升 pre-submit从结果展示到 PR 门禁晋升条件与注意事项如果测试处于良好状态持续通过超过 2 周运行时维护者可以请求将测试纳入 pre-submit PR 测试。策略特别提醒两点pre-submit 测试需要显著更高的测试容量testing capacitypre-submit 测试的标准更高因为它们直接影响开发速度development velocity——一个不稳定的门禁会让所有贡献者的 PR 体验恶化。降级机制反过来如果测试出现 flaky 或失败且维护者未能及时响应修复SIG leads 可以将运行时从 pre-submit 测试中移除直到问题解决。这是一套完整的晋升-降级闭环测试健康则升级为门禁测试失修则降回普通展示。当前准入范围限制截至目前SIG-Node 只接受将 Node conformance 测试晋升为 pre-submit。原因在于 Kubernetes conformance 测试涉及更广的范围跨组件、跨 SIG可能需要其他 SIG 的共同赞助co-sponsorship因此集群级测试暂时不在此准入范围内。这一限制在测试策略中属于当前状态而非永久规定会随社区协作机制的成熟而演进。FAQ边界问题与运行指引策略文档用五个 FAQ 划清了职责边界这些答案对运行时维护者规划测试策略至关重要1. 运行时维护者能否发布其他 E2E 测试结果可以。额外的 Node E2E 测试结果将展示在sig-node-{runtime-name}页面且适用相同的测试维护策略。额外的集群级 E2E 测试SIG-Node 可能同意托管但维护者被强烈建议寻找更合适的 SIG 来赞助或托管——因为集群级测试的信号归属通常与特定云厂商/组件 SIG 更相关。2. 这些运行时专属测试 job 能否被视为发布阻断release blocking不能由 SIG-Node 单方面决定。这超出了 SIG-Node 的权限范围需要多个 SIG如 Release SIG、相关云厂商 SIG 等达成共识。也就是说运行时的质量测试结果默认是展示性而非门禁性的除非跨 SIG 协商后另有安排。3. 如何运行前述测试在单一文档中维护所有运行说明甚至链接的成本过高、易过期因此策略明确建议联系相关 SIG 获取协助。本仓库内的 e2e-node-tests.md 提供了可自行落地的详细运行方法下文展开。4. 如何修改 test-grid 以发布测试结果联系 SIG-Node 获取详细操作指引。TestGrid 的 job 配置由 kubernetes/test-infra 仓库管理参见 sigs.yaml 中 SIG-Node 的 ci-testing subproject 对 test-infra 配置目录的归属说明配置变更需经过 SIG-Node 的评审与协调。5. 该策略如何适用于 Windows 容器Windows 容器仍处于早期开发阶段特性变化迅速因此建议将其视为一个特性feature只运行经过筛选的白名单whitelisted测试。这体现了策略的务实态度对快速演进的技术栈先做最小验证集再逐步扩大覆盖。实战落地如何本地运行必测的 Node E2E 测试虽然策略文档将如何运行的细节指向 SIG 协助仓库内的 e2e-node-tests.md 给出了完整可操作的运行指南这里梳理其核心链路供运行时维护者直接套用注意仅支持 LinuxMac 与 Windows 不支持且 Node E2E 环境中没有 scheduler测试需要手动调度 Pod。本地运行推荐用于快速迭代本地运行远快于远程前置条件为etcd位于PATH或作为/tmp/etcd二进制存在本地运行启用了 CRI 插件的containerdcgroupfs或systemdcgroup 驱动均可但 kubelet 与 containerd 必须使用同一驱动可用的 CNI 配置/etc/cni/net.d/与 CNI 插件二进制/opt/cni/bin/测试场景下 bridge loopback 配置即可。从 Kubernetes 源码根目录执行make test-e2e-node若宿主机开启了 swap典型开发者工作站的默认情况kubelet 默认拒绝启动需通过TEST_ARGS传入--fail-swap-onfalsemake test-e2e-node TEST_ARGS--kubelet-flags--fail-swap-onfalse该命令会运行 ginkgo 二进制并针对test/e2e_node子目录执行内部依次完成请求 sudo 权限 → 构建 Kubernetes 源码 →可选预拉取测试镜像make test-e2e-node PREPULL_IMAGEStrue→ 启动本地 etcd → 启动本地 kube-apiserver → 启动本地 kubelet → 运行测试并输出到 STDOUT → 停止 kubelet、apiserver 与 etcd。查看全部可调参数可运行make test-e2e-node PRINT_HELPytest-suite.md 从源码视角补充了这条链路的底层实现make test-e2e-node实际调用hack/make-rules/test-e2e-node.sh本地 runner 的入口是test/e2e_node/runner/local/run_local.go它首先构建cmd/kubelet、test/e2e_node/e2e_node.test、vendor/github.com/onsi/ginkgo/ginkgo等目标再由 ginkgo 以-nodes8的默认并行度引导测试套件测试内部通过SynchronizedBeforeSuite依次完成系统校验、镜像预拉取、启动 etcd/apiserver/namespace controller 等服务并等待节点就绪。整个Makefile 目标 → ginkgo 启动的流程如下图所示远程运行贴近项目 CI 环境远程模式在 GCE 虚拟机上运行测试环境与 Kubernetes 项目自身的 pre/post-submit 测试高度一致make test-e2e-node REMOTEtrue该命令会构建源码、基于默认测试镜像创建 GCE 实例、将 ginkgo/kubelet/kube-apiserver/e2e_node.test 等二进制打包上传、远程运行测试并把日志通过scp回传到本地带时间戳的目录默认/tmp/_artifacts/YYMMDDTHHMMSS可用ARTIFACTS环境变量覆盖。常用变体包括自定义镜像IMAGES...、指定已有实例HOSTS...、自定义网络子网NETWORK/SUBNET、每次重建实例以暴露启动类 flakeDELETE_INSTANCEStrue、测试后保留进程用于调试CLEANUPfalse等。用 FOCUS / SKIP 精确圈定测试范围FOCUS 与 SKIP 参数接受正则表达式是精准运行必测套件的关键工具# 只跑匹配正则的测试 make test-e2e-node REMOTEtrue FOCUSregex-to-match # 跳过匹配正则的测试 make test-e2e-node REMOTEtrue SKIPregex-to-match项目中ci-kubernetes-node-kubelet这类 job 的典型配置是--focus\[NodeConformance\] --skip\[Flaky\]|\[Serial\]对应命令为make test-e2e-node REMOTEtrue FOCUS\[NodeConformance\] SKIP\[Flaky\]|\[Serial\]其余实用技巧包括运行单个测试将 ginkgo 的It描述串传给--focus、按特性标签运行如--focus\[Feature:HostAccess\]、持续运行直到失败以排查 flakeRUN_UNTIL_FAILUREtrue、调整并行度PARALLELISM4或PARALLELISM1顺序执行。测试结束后可在 TestGridtestgrid.k8s.io的sig-node-containerd等标签页查看结果网格中每一行对应一个 E2E 测试或 job 阶段如创建 VM、下载文件绿色表示通过、红色表示失败——这正是策略文档所说联邦化仪表盘的落地形态。与仓库其他文档的关联脉络这份测试策略并非孤立文档它与 SIG-Node 目录下的多份文档共同构成完整的CRI 运行时质量体系container-runtime-interface.mdCRI 的动机、架构与演进历史v1alpha1 → Beta → GA解释为什么运行时需要以 CRI 为标准接入e2e-node-tests.mdNode E2E 测试的完整运行手册即必测套件的执行层test-suite.mdNode E2E 测试套件的源码级剖析runner 入口、ginkgo 引导、服务启动链路即必测套件的实现层cri-validation.md低层级 CRI validation 测试的说明已弃用迁移至 cri-toolssigs.yamlSIG-Node 的使命、领导层、联系渠道及 ci-testing、cri-api、cri-client 等 subproject 的归属关系。运行时维护者若想完整履行本策略建议按通读 CRI 背景 → 按 e2e-node-tests 手册本地跑通 Node conformance/feature 套件 → 向 SIG-Node 提交发布提案 → 维持 nightly 运行与健康维护 → 条件成熟后申请 pre-submit 晋升的路径推进。整个体系的最终目标始终如一让 Kubernetes 社区能以最低成本、持续地评估每个 CRI 运行时的一致性、稳定性与特性支持从而支撑起健康、可插拔的运行时生态。【免费下载链接】communityKubernetes Community Documentation项目地址: https://gitcode.com/GitHub_Trending/com/community创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考