panxiao81/gitea-dynamic-runner
1
0
Fork 0
Code Issues 5 Pull Requests Actions Packages Projects Releases Wiki Activity

PoC：使用 standalone containerd + Kata 作为 microVM provider #20

New Issue
Open
opened 2026-09-17 08:30:31 +00:00 by panxiao81 · 0 comments
panxiao81 commented 2026-09-17 08:30:31 +00:00
Owner
Copy Link
Copy Source

背景

现有 Cloud Hypervisor shell launcher 已完成可行性验证，但继续维护磁盘、TAP、网络、VMM 进程与清理逻辑会使项目演变成自制 hypervisor 管理工具。

Kata Containers 本身是 containerd shim v2：containerd 提供稳定任务 API、OCI 镜像与生命周期管理，Kata shim 负责创建 microVM、guest agent、网络、挂载、状态持久化和 VMM 集成。官方支持不经 Kubernetes，直接使用 ctr/nerdctl 和 io.containerd.kata.v2；runtime-rs 支持 Cloud Hypervisor、Firecracker、QEMU 与内置 Dragonball。

这可能让现有 pve2 LXC 只运行 containerd + Kata，而无需维护第二个 Kubernetes 集群，也无需本项目管理 TAP、qcow2 与 Cloud Hypervisor 进程。

需要验证的拓扑

microvm-executor
      │ containerd API
      ▼
containerd ─► containerd-shim-kata-v2 ─► Cloud Hypervisor/Dragonball ─► runner OCI image

关键验证

  • 在现有 pve2 特权 LXC 中复用已经验证的 /dev/kvm、cgroup 与 AppArmor 配置
  • 安装 containerd 2.x 与 Kata 4.x runtime-rs，不安装 kubelet/k3s
  • 首选测试 Cloud Hypervisor 配置；同时记录 Dragonball 的兼容性与资源占用
  • 通过 containerd API 或 nerdctl 启动一次性 privileged runner OCI container
  • 验证停止、取消、超时、containerd 重启与异常退出后的资源回收
  • 测量冷启动、空闲内存、任务峰值内存和磁盘写放大

Docker/kind 验证

之前 Docker overlay2 在 Kata guest 中失败，是因为默认容器 rootfs//var/lib/docker 位于 virtiofs，virtiofs 不能作为 overlayfs upper。

本 PoC 不应再次用 shell 临时修补。优先验证 Kata EROFS snapshotter 或其他官方 block-backed snapshotter：其 writable upper 以 ext4 block device 挂入 guest，使 pipeline 安装的 Docker daemon 可以使用 overlay2。若仍不能满足要求，再比较显式临时 block volume 与 fuse-overlayfs。

必须验证：

  • workflow 内按需安装并启动 Docker daemon
  • Docker 使用 overlay2，或明确记录所选 storage driver 及原因
  • kind create cluster、基础 Pod 调度与删除成功
  • runner 退出后 Docker 数据随 Kata sandbox 一起销毁

验收标准

  • 无 Kubernetes 组件也能通过 containerd 启动 Kata runner
  • executor 不直接创建 TAP、磁盘、seed image 或 VMM 进程
  • OCI 镜像可承载 Gitea runner，后续也可承载 GitHub runner
  • kind smoke test 通过
  • 单 job 完成、失败、取消和超时后无遗留 shim、VMM、网络或磁盘状态
  • 与当前 Cloud Hypervisor launcher 对比启动时间和内存占用
  • 将结论记录到 provider 选型文档，并决定是否替换 shell PoC

备选与淘汰条件

  • Incus VM：成熟 REST API、ephemeral VM、cloud-init、镜像/网络/存储管理完整；若 Kata 无法可靠运行 kind，它是首选回退方案，但使用 QEMU 全系统 VM且在 LXC 内嵌套部署较重
  • libvirt：成熟但抽象层较低，项目仍需组合镜像、cloud-init、网络和回收策略，不作为首选
  • firecracker-containerd：方向类似但集成与运维成熟度暂不优于 Kata，只有 Kata VMM 路径失败时再评估
  • Ignite/Flintlock：项目已归档或缺乏持续维护，不采用
## 背景 现有 Cloud Hypervisor shell launcher 已完成可行性验证，但继续维护磁盘、TAP、网络、VMM 进程与清理逻辑会使项目演变成自制 hypervisor 管理工具。 Kata Containers 本身是 containerd shim v2：containerd 提供稳定任务 API、OCI 镜像与生命周期管理，Kata shim 负责创建 microVM、guest agent、网络、挂载、状态持久化和 VMM 集成。官方支持不经 Kubernetes，直接使用 `ctr`/`nerdctl` 和 `io.containerd.kata.v2`；runtime-rs 支持 Cloud Hypervisor、Firecracker、QEMU 与内置 Dragonball。 这可能让现有 pve2 LXC 只运行 containerd + Kata，而无需维护第二个 Kubernetes 集群，也无需本项目管理 TAP、qcow2 与 Cloud Hypervisor 进程。 ## 需要验证的拓扑 ```text microvm-executor │ containerd API ▼ containerd ─► containerd-shim-kata-v2 ─► Cloud Hypervisor/Dragonball ─► runner OCI image ``` ## 关键验证 - 在现有 pve2 特权 LXC 中复用已经验证的 `/dev/kvm`、cgroup 与 AppArmor 配置 - 安装 containerd 2.x 与 Kata 4.x runtime-rs，不安装 kubelet/k3s - 首选测试 Cloud Hypervisor 配置；同时记录 Dragonball 的兼容性与资源占用 - 通过 containerd API 或 `nerdctl` 启动一次性 privileged runner OCI container - 验证停止、取消、超时、containerd 重启与异常退出后的资源回收 - 测量冷启动、空闲内存、任务峰值内存和磁盘写放大 ## Docker/kind 验证 之前 Docker `overlay2` 在 Kata guest 中失败，是因为默认容器 rootfs/`/var/lib/docker` 位于 virtiofs，virtiofs 不能作为 overlayfs upper。 本 PoC 不应再次用 shell 临时修补。优先验证 Kata EROFS snapshotter 或其他官方 block-backed snapshotter：其 writable upper 以 ext4 block device 挂入 guest，使 pipeline 安装的 Docker daemon 可以使用 overlay2。若仍不能满足要求，再比较显式临时 block volume 与 fuse-overlayfs。 必须验证： - [ ] workflow 内按需安装并启动 Docker daemon - [ ] Docker 使用 `overlay2`，或明确记录所选 storage driver 及原因 - [ ] `kind create cluster`、基础 Pod 调度与删除成功 - [ ] runner 退出后 Docker 数据随 Kata sandbox 一起销毁 ## 验收标准 - [ ] 无 Kubernetes 组件也能通过 containerd 启动 Kata runner - [ ] executor 不直接创建 TAP、磁盘、seed image 或 VMM 进程 - [ ] OCI 镜像可承载 Gitea runner，后续也可承载 GitHub runner - [ ] kind smoke test 通过 - [ ] 单 job 完成、失败、取消和超时后无遗留 shim、VMM、网络或磁盘状态 - [ ] 与当前 Cloud Hypervisor launcher 对比启动时间和内存占用 - [ ] 将结论记录到 provider 选型文档，并决定是否替换 shell PoC ## 备选与淘汰条件 - Incus VM：成熟 REST API、ephemeral VM、cloud-init、镜像/网络/存储管理完整；若 Kata 无法可靠运行 kind，它是首选回退方案，但使用 QEMU 全系统 VM且在 LXC 内嵌套部署较重 - libvirt：成熟但抽象层较低，项目仍需组合镜像、cloud-init、网络和回收策略，不作为首选 - firecracker-containerd：方向类似但集成与运维成熟度暂不优于 Kata，只有 Kata VMM 路径失败时再评估 - Ignite/Flintlock：项目已归档或缺乏持续维护，不采用
Sign in to join this conversation.
No Branch/Tag Specified
Branches Tags
Labels
No items
No labels
Milestone
No items
No Milestone
Projects
Clear projects
No projects
Assignees
Clear assignees
panxiao81 (Xiao Pan)
No Assignees
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: panxiao81/gitea-dynamic-runner#20