2026/9/10 9:56:50
FEATURED · 精选文章 
K3s 测试体系演进从 Drone 与 GitHub Actions 双平台走向统一 CI 架构【免费下载链接】k3sLightweight Kubernetes项目地址: https://gitcode.com/GitHub_Trending/k3/k3s本文基于 K3s 仓库中的架构决策记录 testing-2024.md系统梳理 K3s 测试体系的分类、历史痛点、统一迁移方案及当前仓库中的实际落地情况。读者将了解 K3s 各测试类型的定位与运行方式掌握 GitHub Actions 统一 CI 的作业划分、目录组织与本地复现命令从而能够快速理解 K3s 的测试全貌并参与测试贡献。决策背景一份 2024 年的架构决策记录docs/adrs/testing-2024.md是 K3s 项目的一份已接受Accepted状态的架构决策记录ADR日期为 2024-02-23。它的核心议题是如何重组 K3s 分散在 GitHub Actions 与 Drone CI 两套平台上的测试基础设施降低维护成本并提升反馈速度。在 K3s 中ADR 文档位于 docs/adrs 目录用于记录影响项目长期走向的技术决策及其理由testing-2024.md记录的正是 2024 年测试架构调整的完整决策链条背景Context→ 决策Decision→ 后果Consequences。本篇文章以此文档为主体骨架结合仓库中实际的 CI 工作流文件与测试代码还原这套测试体系的现状。决策前的测试版图两套平台、六类测试决策记录首先勾勒了 2024 年初 K3s 测试的全景。当时测试分布在GitHub Actions与Drone CI两套平台上共六类平台测试类型说明GitHub Actions单元测试Unit Tests针对单个组件与函数采用白盒white box方式GitHub Actions集成测试Integration Tests跨多个包验证功能采用黑盒black box方式GitHub Actions冒烟测试Smoke Tests验证基本功能可用细分为 Cgroup验证 cgroupv2 支持、Snapshotter验证 btrfs 与 overlayfs 快照支持、安装测试在多种操作系统上验证 K3s 安装Drone CIDocker 测试Docker Tests在容器中运行集群验证基本功能细分为 Basic Tests 与 Sonobuoy Conformance Tests在多种数据库后端上验证 K8s 一致性Drone CI端到端测试E2E Tests覆盖多节点配置与集群管理不接入 CI性能测试Performance Tests使用 Terraform 测试大规模集群部署属遗留测试从未在 CI 中运行这套划分在当前仓库中依然能找到对应痕迹冒烟测试中的安装测试对应 tests/install 目录下的 Vagrantfile 集合性能测试对应 tests/perf 目录内含 Terraform 配置E2E 测试对应 tests/e2e 下按场景组织的子目录。四大痛点为什么要迁移决策记录明确列出了旧架构的四个问题这些是推动迁移的直接动因基础设施复杂且碎片化测试没有全部收拢到tests目录下组织混乱维护开销大。GitHub Actions 资源受限开源项目可用的 runner 资源不足不适合运行大型测试。硬件虚拟化支持不稳GitHub Actions 仅在 macOS runner 上支持硬件虚拟化且该支持经常不可用。Drone CI 无法处理单个测试失败Drone 的语义是任一测试失败即整个构建失败无法按测试粒度独立判定导致排查与合并体验差。值得注意的是第 2、3 点很快被新进展New Developments化解——2024 年 1 月底GitHub Actions 面向开源项目的 runner 资源翻倍4 核 CPU、16GB 内存且标准免费Linux runner 开始支持嵌套虚拟化Nested Virtualization。嵌套虚拟化的到来意味着可以在 GitHub 托管的 Linux runner 上用 Vagrant/libvirt 拉起真正的虚拟机做安装测试与 E2E 测试这正是决策得以成立的技术前提。核心决策统一到 GitHub Actions按规模分层基于上述背景K3s 决定向单一测试平台 GitHub Actions 迁移并依据测试的规模与复杂度重新分配运行位置单元测试、集成测试继续留在 GitHub Actions。它们规模小、执行快适合轻量 runner。安装测试、Docker Basic 测试、E2E 测试得益于 runner 资源提升与嵌套虚拟化支持迁移到 GitHub Actions 标准 Linux runner 上运行。Docker Conformance 测试与大型 E2E 测试2 个及以上节点仍留在 Drone CI因为这些场景资源消耗大。配套的结构性调整还包括统一目录将所有测试相关文件收拢到tests目录提升组织清晰度。移除 Cgroup 冒烟测试由于多数操作系统默认支持 CgroupV2该测试已失去意义。Snapshotter 冒烟测试升级为完整 E2E 测试。删除遗留的性能测试规模测试scale testing改由 QA 按需处理不再占用仓库维护资源。决策落地当前仓库中的 GitHub Actions 测试工作流单元测试与覆盖率unitcoverage.yaml决策后的单元测试依然运行在 GitHub Actions 的ubuntu-24.04与windows-2022runner 上并同时承担代码覆盖率采集go test -coverpkg ./pkg/... -coverprofile coverage.out ./pkg/... -run Unit go tool cover -func coverage.out工作流将覆盖率结果上传至 Codecovflag 为unittests并额外通过Dockerfile.test构建test-mods镜像来验证 K8s 相关模块。从 tests/TESTING.md 可知K3s 单元测试遵循Table Driven Test风格命名约定为Test_UnitFUNCTION_TO_TEST可通过go test ./pkg/... -run Unit在本地复现。集成测试integration.yaml集成测试矩阵覆盖startup、etcdsnapshot、kubeflags、cacertrotation、longhorn、secretsencryption、certrotation、etcdrestore、localstorage、flannelnone、custometcdargs共 11 个场景在 Ubuntu runner 上以max-parallel: 5并发执行sudo -E env PATH$PATH go test -timeout45m ./... -run Integration -ginkgo.v -test.v工作流同样为 Windowswindows-2022准备了集成测试作业覆盖agnhost工作负载的启动验证。本地运行方式与更多细节见 tests/integration/README.md集成测试采用Ginkgo/Gomega的 BDD 风格测试文件命名TEST_NAME_int_test.go必须以 root 运行也可通过编译期 flag 在已有单节点集群上执行go test -ldflags -X github.com/k3s-io/k3s/tests/integration.existingServerTrue ./tests/integration/... -run Integration -ginkgo.v -test.v安装测试install.yaml这是决策中从冒烟测试迁移到 GitHub Actions 的代表性成果。工作流使用 Vagrant libvirt 在centos-9、alma-10、rocky-9、fedora、opensuse-leap、ubuntu-2404六个操作系统上执行安装验证——这直接受益于标准 Linux runner 的嵌套虚拟化支持。测试过程包括拉取已构建的 k3s 二进制、vagrant up启动虚拟机、scp 上传二进制、执行vagrant provision完成安装并销毁虚拟机。本地复现方式参见 tests/TESTING.md 的 Install Tests 一节cd tests/install/rocky-8 vagrant up vagrant provision --provision-withk3s-wait-for-node vagrant provision --provision-withk3s-wait-for-coredns # ... 依次执行各 wait/status provisioner测试可用环境变量包括TEST_VM_CPUS默认 2、TEST_VM_MEMORY默认 2048MB、TEST_VM_BOOT_TIMEOUT默认 600 秒。Docker 测试与大型 E2Ee2e.yamle2e.yaml是决策落地最完整的体现它同时承载了 Docker 测试、常规 E2E 与资源密集型作业E2E 作业矩阵覆盖startup、s3、embeddedmirror、privateregistry、wasm、externalip、rootless、multus、btrfs九个场景通过go test -timeout45m ./etest_test.go -test.v -ginkgo.v -ci -local在ubuntu-24.04上结合 Vagrant/libvirt 运行。Docker 作业docker-go矩阵覆盖autoimport、basics、bootstraptoken、cacerts、dualstack、etcd、t4、hardened、lazypull、nixsnapshotter、skew、secretsencryption、snapshotrestore、svcpoliciesandfirewall、token、upgrade共 16 个场景并在 amd64/arm64 双架构上运行。大型作业docker-largescale测试使用cncf-ubuntu-32-128-x86大规格 runner仅限k3s-io主仓库触发运行./scale.test -test.timeout40m -test.v -ginkgo.v -ci -k3sImage$K3S_IMAGE——这与决策中资源密集型场景仍保留在专用基础设施上的思路一脉相承。各 E2E 场景的实际测试入口可见于 tests/e2e 下对应目录的*_test.go文件如 startup/startup_test.go、s3/s3_test.go、multus/multus_test.go每个场景一个Test函数配合各自的Vagrantfile定义虚拟机规格。测试代码的组织规范决策中收拢测试到 tests 目录的目标在当前仓库中已完全实现。tests目录结构如下tests/ ├── TESTING.md # 测试标准总览何时写、如何写、如何跑 ├── unit.go # 单元测试辅助 ├── client.go # 测试客户端 ├── docker/ # Docker 测试容器内集群 ├── e2e/ # E2E 测试多节点Vagrant ├── integration/ # 集成测试Ginkgo/Gomega ├── install/ # 安装测试多 OS Vagrantfile ├── perf/ # 性能测试Terraform遗留 ├── mock/ # 测试 mock 辅助 └── fixtures/ # 测试固定数据tests/TESTING.md 还补充了各测试类型的编写规范单元测试须与被测文件同包、命名为FILE_UNDER_TEST_test.go可使用 contrib/gotests_templates 提供的 gotests 模板自动生成E2E 与集成测试分别由各自的 README 指导。提交新测试时PR 标题需包含NAME_OF_TEST (Created/Updated)字样。后果与评估决策带来的收益决策记录在 Consequences 一节给出了预期的四项收益对照当前仓库可以逐项验证测试基础设施更有组织、更易维护所有测试文件已集中到tests目录CI 工作流统一收敛到 .github/workflows 下的 YAML 文件。更快的 PR 反馈GitHub Actions 与 PR 深度集成pull_request触发贡献者在提交后即可获得按作业粒度的状态反馈不再受 Drone一损俱损的整构建失败影响。降低维护开销Cgroup 冒烟测试移除、Snapshotter 冒烟测试转为 E2E、遗留性能测试删除均已在当前目录结构中体现tests/e2e 存在而tests/cgroup已不存在。可作为相关项目的测试流程样板文档明确将新测试流程可被相关项目借鉴列为预期后果这与 Rancher 生态的 distros-test-framework 等实践相互印证见 tests/TESTING.md 的 Distros Test Framework 一节。从源码结构看决策中继续保留在 Drone CI的 Docker Conformance 测试与大型 E2E 测试在当前仓库中已无.drone.yml文件残留相关工作负载改由 e2e.yaml 中的专用大规格 runner 作业docker-large、cncf-ubuntu-32-128-x86承接可以推断该迁移在仓库演进过程中已按计划落地完成。小结docs/adrs/testing-2024.md记录了 K3s 测试架构一次从分散走向统一的关键决策以 GitHub Actions 为单一平台按测试规模分层调度同时通过目录收拢与旧测试清理降低维护成本。当前仓库中的 .github/workflows、tests 目录结构以及 tests/TESTING.md 测试规范共同构成了这份 ADR 的完整落地证据。对于想要为 K3s 贡献测试或理解其 CI 体系的开发者本文梳理的工作流对应关系与本地运行命令可以作为直接的切入点。【免费下载链接】k3sLightweight Kubernetes项目地址: https://gitcode.com/GitHub_Trending/k3/k3s创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考
K3s 测试体系演进：从 Drone 与 GitHub Actions 双平台走向统一 CI 架构
K3s 测试体系演进从 Drone 与 GitHub Actions 双平台走向统一 CI 架构【免费下载链接】k3sLightweight Kubernetes项目地址: https://gitcode.com/GitHub_Trending/k3/k3s本文基于 K3s 仓库中的架构决策记录 testing-2024.md系统梳理 K3s 测试体系的分类、历史痛点、统一迁移方案及当前仓库中的实际落地情况。读者将了解 K3s 各测试类型的定位与运行方式掌握 GitHub Actions 统一 CI 的作业划分、目录组织与本地复现命令从而能够快速理解 K3s 的测试全貌并参与测试贡献。决策背景一份 2024 年的架构决策记录docs/adrs/testing-2024.md是 K3s 项目的一份已接受Accepted状态的架构决策记录ADR日期为 2024-02-23。它的核心议题是如何重组 K3s 分散在 GitHub Actions 与 Drone CI 两套平台上的测试基础设施降低维护成本并提升反馈速度。在 K3s 中ADR 文档位于 docs/adrs 目录用于记录影响项目长期走向的技术决策及其理由testing-2024.md记录的正是 2024 年测试架构调整的完整决策链条背景Context→ 决策Decision→ 后果Consequences。本篇文章以此文档为主体骨架结合仓库中实际的 CI 工作流文件与测试代码还原这套测试体系的现状。决策前的测试版图两套平台、六类测试决策记录首先勾勒了 2024 年初 K3s 测试的全景。当时测试分布在GitHub Actions与Drone CI两套平台上共六类平台测试类型说明GitHub Actions单元测试Unit Tests针对单个组件与函数采用白盒white box方式GitHub Actions集成测试Integration Tests跨多个包验证功能采用黑盒black box方式GitHub Actions冒烟测试Smoke Tests验证基本功能可用细分为 Cgroup验证 cgroupv2 支持、Snapshotter验证 btrfs 与 overlayfs 快照支持、安装测试在多种操作系统上验证 K3s 安装Drone CIDocker 测试Docker Tests在容器中运行集群验证基本功能细分为 Basic Tests 与 Sonobuoy Conformance Tests在多种数据库后端上验证 K8s 一致性Drone CI端到端测试E2E Tests覆盖多节点配置与集群管理不接入 CI性能测试Performance Tests使用 Terraform 测试大规模集群部署属遗留测试从未在 CI 中运行这套划分在当前仓库中依然能找到对应痕迹冒烟测试中的安装测试对应 tests/install 目录下的 Vagrantfile 集合性能测试对应 tests/perf 目录内含 Terraform 配置E2E 测试对应 tests/e2e 下按场景组织的子目录。四大痛点为什么要迁移决策记录明确列出了旧架构的四个问题这些是推动迁移的直接动因基础设施复杂且碎片化测试没有全部收拢到tests目录下组织混乱维护开销大。GitHub Actions 资源受限开源项目可用的 runner 资源不足不适合运行大型测试。硬件虚拟化支持不稳GitHub Actions 仅在 macOS runner 上支持硬件虚拟化且该支持经常不可用。Drone CI 无法处理单个测试失败Drone 的语义是任一测试失败即整个构建失败无法按测试粒度独立判定导致排查与合并体验差。值得注意的是第 2、3 点很快被新进展New Developments化解——2024 年 1 月底GitHub Actions 面向开源项目的 runner 资源翻倍4 核 CPU、16GB 内存且标准免费Linux runner 开始支持嵌套虚拟化Nested Virtualization。嵌套虚拟化的到来意味着可以在 GitHub 托管的 Linux runner 上用 Vagrant/libvirt 拉起真正的虚拟机做安装测试与 E2E 测试这正是决策得以成立的技术前提。核心决策统一到 GitHub Actions按规模分层基于上述背景K3s 决定向单一测试平台 GitHub Actions 迁移并依据测试的规模与复杂度重新分配运行位置单元测试、集成测试继续留在 GitHub Actions。它们规模小、执行快适合轻量 runner。安装测试、Docker Basic 测试、E2E 测试得益于 runner 资源提升与嵌套虚拟化支持迁移到 GitHub Actions 标准 Linux runner 上运行。Docker Conformance 测试与大型 E2E 测试2 个及以上节点仍留在 Drone CI因为这些场景资源消耗大。配套的结构性调整还包括统一目录将所有测试相关文件收拢到tests目录提升组织清晰度。移除 Cgroup 冒烟测试由于多数操作系统默认支持 CgroupV2该测试已失去意义。Snapshotter 冒烟测试升级为完整 E2E 测试。删除遗留的性能测试规模测试scale testing改由 QA 按需处理不再占用仓库维护资源。决策落地当前仓库中的 GitHub Actions 测试工作流单元测试与覆盖率unitcoverage.yaml决策后的单元测试依然运行在 GitHub Actions 的ubuntu-24.04与windows-2022runner 上并同时承担代码覆盖率采集go test -coverpkg ./pkg/... -coverprofile coverage.out ./pkg/... -run Unit go tool cover -func coverage.out工作流将覆盖率结果上传至 Codecovflag 为unittests并额外通过Dockerfile.test构建test-mods镜像来验证 K8s 相关模块。从 tests/TESTING.md 可知K3s 单元测试遵循Table Driven Test风格命名约定为Test_UnitFUNCTION_TO_TEST可通过go test ./pkg/... -run Unit在本地复现。集成测试integration.yaml集成测试矩阵覆盖startup、etcdsnapshot、kubeflags、cacertrotation、longhorn、secretsencryption、certrotation、etcdrestore、localstorage、flannelnone、custometcdargs共 11 个场景在 Ubuntu runner 上以max-parallel: 5并发执行sudo -E env PATH$PATH go test -timeout45m ./... -run Integration -ginkgo.v -test.v工作流同样为 Windowswindows-2022准备了集成测试作业覆盖agnhost工作负载的启动验证。本地运行方式与更多细节见 tests/integration/README.md集成测试采用Ginkgo/Gomega的 BDD 风格测试文件命名TEST_NAME_int_test.go必须以 root 运行也可通过编译期 flag 在已有单节点集群上执行go test -ldflags -X github.com/k3s-io/k3s/tests/integration.existingServerTrue ./tests/integration/... -run Integration -ginkgo.v -test.v安装测试install.yaml这是决策中从冒烟测试迁移到 GitHub Actions 的代表性成果。工作流使用 Vagrant libvirt 在centos-9、alma-10、rocky-9、fedora、opensuse-leap、ubuntu-2404六个操作系统上执行安装验证——这直接受益于标准 Linux runner 的嵌套虚拟化支持。测试过程包括拉取已构建的 k3s 二进制、vagrant up启动虚拟机、scp 上传二进制、执行vagrant provision完成安装并销毁虚拟机。本地复现方式参见 tests/TESTING.md 的 Install Tests 一节cd tests/install/rocky-8 vagrant up vagrant provision --provision-withk3s-wait-for-node vagrant provision --provision-withk3s-wait-for-coredns # ... 依次执行各 wait/status provisioner测试可用环境变量包括TEST_VM_CPUS默认 2、TEST_VM_MEMORY默认 2048MB、TEST_VM_BOOT_TIMEOUT默认 600 秒。Docker 测试与大型 E2Ee2e.yamle2e.yaml是决策落地最完整的体现它同时承载了 Docker 测试、常规 E2E 与资源密集型作业E2E 作业矩阵覆盖startup、s3、embeddedmirror、privateregistry、wasm、externalip、rootless、multus、btrfs九个场景通过go test -timeout45m ./etest_test.go -test.v -ginkgo.v -ci -local在ubuntu-24.04上结合 Vagrant/libvirt 运行。Docker 作业docker-go矩阵覆盖autoimport、basics、bootstraptoken、cacerts、dualstack、etcd、t4、hardened、lazypull、nixsnapshotter、skew、secretsencryption、snapshotrestore、svcpoliciesandfirewall、token、upgrade共 16 个场景并在 amd64/arm64 双架构上运行。大型作业docker-largescale测试使用cncf-ubuntu-32-128-x86大规格 runner仅限k3s-io主仓库触发运行./scale.test -test.timeout40m -test.v -ginkgo.v -ci -k3sImage$K3S_IMAGE——这与决策中资源密集型场景仍保留在专用基础设施上的思路一脉相承。各 E2E 场景的实际测试入口可见于 tests/e2e 下对应目录的*_test.go文件如 startup/startup_test.go、s3/s3_test.go、multus/multus_test.go每个场景一个Test函数配合各自的Vagrantfile定义虚拟机规格。测试代码的组织规范决策中收拢测试到 tests 目录的目标在当前仓库中已完全实现。tests目录结构如下tests/ ├── TESTING.md # 测试标准总览何时写、如何写、如何跑 ├── unit.go # 单元测试辅助 ├── client.go # 测试客户端 ├── docker/ # Docker 测试容器内集群 ├── e2e/ # E2E 测试多节点Vagrant ├── integration/ # 集成测试Ginkgo/Gomega ├── install/ # 安装测试多 OS Vagrantfile ├── perf/ # 性能测试Terraform遗留 ├── mock/ # 测试 mock 辅助 └── fixtures/ # 测试固定数据tests/TESTING.md 还补充了各测试类型的编写规范单元测试须与被测文件同包、命名为FILE_UNDER_TEST_test.go可使用 contrib/gotests_templates 提供的 gotests 模板自动生成E2E 与集成测试分别由各自的 README 指导。提交新测试时PR 标题需包含NAME_OF_TEST (Created/Updated)字样。后果与评估决策带来的收益决策记录在 Consequences 一节给出了预期的四项收益对照当前仓库可以逐项验证测试基础设施更有组织、更易维护所有测试文件已集中到tests目录CI 工作流统一收敛到 .github/workflows 下的 YAML 文件。更快的 PR 反馈GitHub Actions 与 PR 深度集成pull_request触发贡献者在提交后即可获得按作业粒度的状态反馈不再受 Drone一损俱损的整构建失败影响。降低维护开销Cgroup 冒烟测试移除、Snapshotter 冒烟测试转为 E2E、遗留性能测试删除均已在当前目录结构中体现tests/e2e 存在而tests/cgroup已不存在。可作为相关项目的测试流程样板文档明确将新测试流程可被相关项目借鉴列为预期后果这与 Rancher 生态的 distros-test-framework 等实践相互印证见 tests/TESTING.md 的 Distros Test Framework 一节。从源码结构看决策中继续保留在 Drone CI的 Docker Conformance 测试与大型 E2E 测试在当前仓库中已无.drone.yml文件残留相关工作负载改由 e2e.yaml 中的专用大规格 runner 作业docker-large、cncf-ubuntu-32-128-x86承接可以推断该迁移在仓库演进过程中已按计划落地完成。小结docs/adrs/testing-2024.md记录了 K3s 测试架构一次从分散走向统一的关键决策以 GitHub Actions 为单一平台按测试规模分层调度同时通过目录收拢与旧测试清理降低维护成本。当前仓库中的 .github/workflows、tests 目录结构以及 tests/TESTING.md 测试规范共同构成了这份 ADR 的完整落地证据。对于想要为 K3s 贡献测试或理解其 CI 体系的开发者本文梳理的工作流对应关系与本地运行命令可以作为直接的切入点。【免费下载链接】k3sLightweight Kubernetes项目地址: https://gitcode.com/GitHub_Trending/k3/k3s创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 
