云原生容器运行时【免费下载链接】kata-containersKata Containers is an open source project and community working to build a standard implementation of lightweight Virtual Machines (VMs) that feel and perform like containers, but provide the workload isolation and security advantages of VMs. https://katacontainers.io/项目地址https://gitcode.com/gh_mirrors/ka/kata-containers点击查看免费下载Kata Containers 的持续集成CI体系基于 GitHub Actions 构建动作定义位于.github/workflows目录并通过调用tests目录下的辅助脚本来实际执行每个测试用例。本文以 ci/README.md 为骨架结合仓库中的工作流文件、Gatekeeper 脚本与测试脚本完整剖析 Kata Containers 的两级 CI 运行模型PR 自动预检 维护者审批的完整测试矩阵、四类运行器规格、Required 任务晋级机制以及如何在本地用kcli复现 CI 环境进行 nerdctl 与 Kubernetes 测试调试的完整实战流程。[!WARNING] 项目官方文档明确提示本项目的 CI 尚有多处待改进之处且仍在持续演进本文描述的是其当前状态可能因后续变更出现过时信息。读者在实际使用中如发现异常欢迎反馈。CI 总体架构GitHub Actions 辅助脚本Kata Containers 的 CI 完全依托 GitHub Actions 执行动作workflow文件集中存放在.github/workflows目录目前包含约 60 个工作流文件覆盖 PR 检查、静态检查、每日构建nightly、发布release、安全扫描codeql、govulncheck、osv-scanner等场景。关键设计是工作流只负责编排真正的测试动作由仓库tests目录下的脚本完成。以 nerdctl 测试为例工作流 basic-ci-amd64.yaml 中的步骤依次调用 tests/integration/nerdctl/gha-run.sh 的install-dependencies、install-kata、run、collect-artifacts四个子命令。这种薄工作流 厚脚本的架构让测试逻辑可以脱离 GitHub 平台独立运行——这也是本地调试得以实现的基础。两类工作流自动预检与审批测试PR 打开即自动运行的任务每当 PR 被创建一批零成本GitHub 免费托管的 runner预检任务会自动启动用于评估 PR 是否达到可评审的基本门槛。从 commit-message-check.yaml 可以看到社区对提交本身的硬性要求包括提交信息格式subject 行不超过 75 个字符、body 行不超过 150 个字符、subject 必须以子系统前缀开头如runtime: fix xxxDevelopers Certificate of OriginDCO每个提交必须包含Signed-off-by标记由tim-actions/dco动作校验静态检查static checks由 static-checks.yaml 驱动包含make static-checks、make check/make test构建检查、go mod tidy一致性校验、protobuf codegen 校验、内核配置版本校验、agent policy 覆盖率检查、broken symlink 检查等众多任务。文档特别强调社区期望贡献者在提交 PR 前至少能本地构建通过自己的代码这是非常合理的要求。需要维护者批准才能运行的任务另一部分测试被社区称为真正的 CI它们运行在付费 runner当前使用 Azure 基础设施上因此必须由项目维护者批准。当前触发方式是给 PR 添加ok-to-test标签社区计划迁移到在 PR review 评论中发送/test命令ok-to-test标签的约束可以从 required-tests.yaml 中test集合的required-labels字段得到印证。批准后依次执行构建所有组件免费 runner 或按架构使用 bare-metal将全部组件打包为 tarball即kata-static.tar.zst仓库根 Makefile 中的kata-tarball目标负责产出用 tarball 生成 kata-deploy 部署载荷供 Kubernetes 集群安装使用执行测试分为两大族依赖 tarball 的测试免费 runner测试运行位置Metricsbare-metaldocker免费 runnernerdctl免费 runnerkata-monitor免费 runnercri-containerd免费 runnernydus免费 runnervfio免费 runner依赖 kata-deploy 载荷的测试kata-deploy免费 runner在 k0s、k3s、rke2、Azure Kubernetes ServiceAKS等不同 Kubernetes 发行版上验证部署生命周期KubernetesAzure 小/中规格实例以及 TEE bare-metal 机器覆盖不同运行时引擎CRI-O 与 containerd、containerd 的不同快照器OverlayFS 与 devmapper以及全部受支持虚拟机监控器——Cloud Hypervisor、Dragonball、Firecracker、QEMU。从 ci.yaml 这个总编排工作流可以看到当前真实的全景仅 cri-containerd 测试就在 amd64 上构成 5 种 VMM × 2 种 containerd 版本共 10 个矩阵组合ci.yaml另有 s390x、ppc64le 上的专项组合Kubernetes 测试则按 AKS、免费 runner、CRI-O、NVIDIA GPU、CoCoConfidential Containers含 SEV-SNP TEE 测试、z/VMZVSI、ppc64le 等维度拆分为独立工作流。文档提醒这些 Azure 实例测试每小时都在消耗真实资金社区请求维护者谨慎使用、避免将其当作免费调试沙箱。四类 Runner 规格CI 中使用的 runner 分为四类规格差异直接影响测试能否本地复现类型规格说明免费 runnerGitHub 官方托管小型、带虚拟化能力用于预检与轻量测试Azure small 实例2 CPU、8GB RAM、带虚拟化能力名称带-smaller后缀如garm-ubuntu-2304-smallerAzure normal 实例4 CPU、16GB RAM、带虚拟化能力通常是 garm 托管、无-smaller后缀Bare-metal runner社区贡献者提供架构/规格不一构建类 runner 无需虚拟化能力执行测试的 runner 必须支持虚拟化且 CPU/RAM 至少对齐 Azure normal 规格新增测试从独立测试到更大测试的一部分文档建议新增测试前先通读 GitHub Actions 官方文档。在 Kata Containers 中测试分为两类独立standalone测试如提交信息检查直接在单个工作流中完成本文不展开更大测试的一部分part of something bigger指那些被并入既有大工作流的测试是社区重点关注的复杂场景。[!NOTE] 文档中的 TODO 注明目前文档以tests称呼实际上的 GitHub jobs/workflows。理想情况下除个别例外新测试的加入不应需要新增工作流社区计划改进工作流以支持这一目标。社区强烈希望新测试自带运行说明 一次通过的实测记录可参考 PR #8115。添加更大测试的一部分只需两步新增 yaml 文件并在更大的 yaml 中调用它参考 Kata Monitor 测试示例新增测试所需辅助脚本参考 Kata Monitor 脚本示例。Required 与 Non-required 任务机制CI 中任务分为两类Required必需必须全部通过 PR 才能正常合并覆盖希望确保不回归的核心功能Non-required非必需用于不稳定测试或实验性、未完全支持的功能理想情况下也希望通过但即使失败也不阻塞合并因为失败不一定意味着 PR 引入回归。晋级为 Required 的流程初始标记标准新任务或近期未标记为 required 的任务需连续 10 天测试通过且期间无相关 PR 失败记录同时需要一名或多名被提名的维护者负责其稳定性维护者可登记在 CI Dashboard 关联的maintainers.yml中。保持 GitHub UI 与 Gatekeeper 同步的流程若有新维护者先创建 PR 更新maintainers.yml创建 PR 更新 required-tests.yaml加入新任务并附上满足上述要求的证据通知所有维护者与 kata-containers/architecture-committee 评审有 PR #11015 作为先例维护者与架构委员会AC评审可在 AC 会议上讨论PR 合并后通知项目 admin 更新 GitHub UI。文档中附注说明这些只是通用准则Kata 架构委员会拥有最终裁量权可随时推翻。Required 任务维护者的职责由于社区贡献者遍布全球required 任务因基础设施或测试问题被阻塞会对协作产生较大影响。因此要求发现问题后维护者须在一个工作日内确认问题、完成初步调查然后要么修复要么在调查/修复期间将任务标记为 non-required。重新标记为 Required一旦任务从 required 列表移除需要连续两次成功的 nightly 测试后才能重新标记为 required。Gatekeeper 的实现机制CI Dashboardkata-containers.github.io是收集任务稳定性证据的重要资源其报告的 nightly 测试结果当前覆盖最近十天是晋级判断的参考依据。与之配套的 gatekeeper.yaml 工作流在pull_request_target事件上运行通过 skips.py 计算当前 PR 需要的任务名/正则列表再由 jobs.py 轮询各工作流运行状态等待 required 任务全部完成或失败并上报状态。可见 required-tests.yaml 中paths字段按改动文件路径映射所需测试集合例如改动docs/或任何.md文件只需通过static集合而test/static集合各自声明了任务名与正则并绑定ok-to-test标签门禁。运行测试在 CI 中运行维护者直接给 PR 添加ok-to-test标签即可自动启动测试未来将切换为 review 评论中的/test命令非维护者在 Slack 留言或等待维护者评审由维护者代为触发。测试失败且疑似测试自身不稳定flaky时的操作路径定位失败的测试点击 details右上角点击 Re-run jobs选择 Re-run failed jobs点击绿色 Re-run jobs 按钮。同时请为该 flaky 测试创建 issue 反馈。在本地运行由于本地通常没有 Azure 订阅无法完全复现 CI 环境但可以搭建足够接近的环境来调试现有测试、或为新测试提供概念验证。基本步骤创建与目标 runner 配置匹配的 VM生成测试所需 artifact或用 CI 失败运行的产物按 action 中的步骤执行测试。下面分别演示非 Kubernetes 与 Kubernetes 测试的调试流程以 PR #8070 为例该 PR 当时同时存在 nerdctl 与 Kubernetes 测试失败。调试非 Kubernetes 测试以 nerdctl 为例以失败的nerdctl测试为例。它运行在garm-ubuntu-2304-smaller虚拟机上其中ubuntu-2304是操作系统smaller表示 2 CPU / 8GB RAM 规格。据此用kcli创建本地 VM$ sudo kcli create vm -i ubuntu2304 -P disks[60] -P numcpus2 -P memory8192 -P cpumodelhost-passthrough debug-nerdctl-pr8070运行测试需要kata-tarball产物kata-static.tar.zst两种获取方式自行构建在仓库根目录执行make kata-tarball对应 Makefile 中的目标从失败 PR 下载点击 Job 页左上角 Summary滚动到 artifacts 区域下载。注意 GitHub 不提供 VM 内直链需在本机下载后用scp拷贝进 VM且这些产物仅在全部 job 结束后保留 15 天。将 tarball 放入 VM 后登录并克隆开发分支$ kcli ssh debug-nerdctl-pr8070 $ git clone --branch feat_add-fc-runtime-rs https://github.com/nubificus/kata-containers添加 upstream 远程、配置 git 并 rebase 到上游 main$ git remote add upstream https://github.com/kata-containers/kata-containers $ git remote update $ git config --global user.email youexample.com $ git config --global user.name Your Name $ git rebase upstream/main将 tarball 拷入kata-artifacts目录$ mkdir kata-artifacts $ cp ../kata-static.tar.zst kata-artifacts/[!NOTE] 若从 GitHub 下载的是 zip 压缩包需先解压才能看到kata-static.tar.zst。最后按测试对应的 yaml 步骤执行。以run-nerdctl-tests-on-garm.yaml为例对应仓库中 basic-ci-amd64.yaml 的 nerdctl 段落注意其中设置了KATA_HYPERVISOR等环境变量核心步骤为安装依赖 → 安装 kata → 运行测试$ export KATA_HYPERVISORdragonball $ bash ./tests/integration/nerdctl/gha-run.sh install-dependencies $ bash ./tests/integration/nerdctl/gha-run.sh install-kata $ bash tests/integration/nerdctl/gha-run.sh rungha-run.sh 内部机制tests/integration/nerdctl/gha-run.sh 揭示了测试脚本与工作流协作的细节install-dependencies安装 wget、pip通过 pip 安装lastversion获取 nerdctl 最新版本号下载nerdctl-full-*tarball 解压到/usr/local/启动 containerd 并生成默认配置当 hypervisor 不支持共享文件系统时kata_hypervisor_runs_without_shared_fs还会额外安装 erofs-utils 并配置 erofs 快照器run依次执行先用 runc 跑一次 nerdctl 冒烟测试作为对照创建 ipvlanipvlan10以宿主eth0为 parent与 macvlanmacvlan20网络以及foo/bar两个 bridge 网络然后分别以io.containerd.kata-${KATA_HYPERVISOR}.v2运行时运行 nerdctl 容器——覆盖默认网络、多 bridge 网络、ipvlan、macvlan 共 4 种网络场景最后清理网络collect-artifacts用journalctl --since${start_time}收集日志到/tmp/artifacts供 CI 上传归档工作流中Archive artifacts步骤以retention-days: 1保留。由此你应能在本地复现 CI 中的完全一致的问题之后即可自行构建代码、使用自己的二进制进行调试。调试 Kubernetes 测试Kubernetes 测试的调试步骤与上述类似但所需的不是kata-static.tar.zst而是供 kata-deploy 使用的部署载荷。自行生成先构建自己的kata-static.tar.zst再借助打包脚本生成并上传 kata-deploy 镜像该镜像必须能被测试 VM 访问复用 CI 失败产物更简单查看失败 job → 点击 Deploy Kata → 展开 Final kata-deploy.yaml that is used in the test 段落即可看到本地集群部署 kata-deploy 所需的准确内容。[!NOTE] 文档中此节标注 TODO计划由维护者基于其run a local CI的 PR 补充完整。新增 Runner只有项目 admin 可以添加/移除 GitHub runner普通成员如有需求应在 Kata Containers Slack 中 ac 寻求帮助。admin 操作路径进入 kata-containers/kata-containers 仓库右上角点击 Settings左侧 Code and automation 下点击 Actions点击 Runners添加右上角绿色按钮 New self-hosted runner移除每个 runner 的 ... 菜单中点击 Remove runner。已知限制由于当前 GitHub Actions 的结构无法在 PR 中测试一个不受pull_request事件触发的 GitHub action 的添加——即新增工作流若不由 PR 事件触发其行为无法在合并前被 CI 验证。关键文件速查用途路径CI 总编排工作流.github/workflows/ci.yamlPR 提交信息检查.github/workflows/commit-message-check.yaml静态检查.github/workflows/static-checks.yamlGatekeeper 门禁工作流.github/workflows/gatekeeper.yamlRequired 任务清单tools/testing/gatekeeper/required-tests.yamlGatekeeper 计算逻辑tools/testing/gatekeeper/skips.py、tools/testing/gatekeeper/jobs.pynerdctl 测试脚本tests/integration/nerdctl/gha-run.sh基础 amd64 测试工作流含 nerdctl/docker/agent-apis.github/workflows/basic-ci-amd64.yamlkata-tarball 构建目标Makefile赞分享云原生容器运行时【免费下载链接】kata-containersKata Containers is an open source project and community working to build a standard implementation of lightweight Virtual Machines (VMs) that feel and perform like containers, but provide the workload isolation and security advantages of VMs. https://katacontainers.io/项目地址https://gitcode.com/gh_mirrors/ka/kata-containers点击查看免费下载相关推荐Ultralytics YOLO 持续集成CI体系深度解析从 GitHub Actions 工作流到代码质量守护Ultralytics YOLO 持续集成CI体系深度解析从 GitHub Actions 工作流到代码质量守护 持续集成CI是现代软件工程中自动集成人工智能深度学习计算机视觉预训练理解 DeepChem 的 CI 体系GitHub Actions 工作流、测试矩阵与依赖管理深度解析理解 DeepChem 的 CI 体系GitHub Actions 工作流、测试矩阵与依赖管理深度解析 DeepChem 是一个面向药物发现、量子化学、材料科人工智能深度学习机器学习生物信息学科学计算MySQLTuner-perl 的 GitHub Actions CI/CD 体系九大自动化工作流深度解析MySQLTuner perl 的 GitHub Actions CI/CD 体系九大自动化工作流深度解析 MySQLTuner perl 仓库在 .gith数据库运维上一篇Mousetrap.js代码模板快速创建新快捷键功能的代码生成器下一篇深入理解gh_mirrors/ca/card的依赖管理Bower与NPM包配置创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考