评估 CI 与 AI Agent 的 microVM 及隔离运行时 backend #47

New Issue

2026-09-10T15:47:25Z

panxiao81 commented

2026-09-10 15:47:25 +00:00

背景

Gitea Actions、AI 代码 Review、自动化 merge、依赖更新、OCR 和其他模型任务会执行短命、可重试且可能不可信的 workload。传统 PVE VM 隔离清晰但启动和密度不理想；普通容器启动快，却很难为不可信仓库代码提供足够边界。未来统一计算控制面不应只绑定 PVE，也应能把任务投递到 microVM、Kata Containers 或受限容器 backend。

目标

为短命 CI/Agent workload 选择一个可运营的轻量隔离 backend，并定义与 PVE VM、普通 Kubernetes Pod 共存的 capability 模型。第一阶段重点是启动速度、隔离、生命周期和运维复杂度，不追求一次覆盖所有运行时。

候选方向

Firecracker 或 Cloud Hypervisor 等 microVM
Kata Containers：通过 Kubernetes CRI/RuntimeClass 提供 VM 隔离
gVisor：适合部分无硬件设备需求的低风险 workload，但不是 GPU/CUDA 甜点位置
普通 Kubernetes Pod：仅用于可信代码或作为长驻 inference client/service
PVE/QEMU VM：用于强隔离、完整 OS、Windows、PCI/GPU passthrough 等场景

评估维度

冷启动时间、并发密度与 idle overhead
KVM、cgroup v2、网络、存储 snapshot/rootfs 和镜像分发要求
guest kernel 与宿主攻击面、逃逸边界和多租户适用性
Kubernetes 集成复杂度，以及是否需要独立集群
job cancellation、超时、强制销毁、孤儿回收和节点重启恢复
日志、metrics、exec/debug 和可观测性
OCI 镜像兼容、缓存命中与构建流水线
GPU、vsock、virtiofs、网络策略与 secrets 注入能力
上游活跃度、版本升级成本和硬件兼容性

初步工作负载分层

可信控制器和长驻模型 API：普通 Kubernetes Pod
不可信 CI build/test：优先评估 Kata 或独立 microVM
AI Agent 执行工具和仓库代码：强隔离 sandbox；模型服务与代码执行环境分离
GPU inference：GPU worker 上的长驻服务或整卡独占 Job，第一阶段不依赖 gVisor/microVM GPU passthrough
完整 OS、Windows、特殊 PCI：PVE VM

与统一控制面的接口

backend 应通过 capability 被选择，而不是暴露底层产品：

requirements:
  isolation: microvm
  architecture: amd64
  gpu: none
  networkPolicy: restricted
  ttl: 30m

需要统一返回 instance/job ID、状态、lease、日志定位和销毁结果；IAM 层签发 workload-scoped 短期凭据，运行环境不保存平台长期 secret。

第一阶段交付

选取两个候选做最小 PoC，优先 Kata Containers 与一个直接 microVM runtime
在目标硬件上测量冷启动、内存开销、并发和销毁可靠性
运行真实 Gitea Actions job，并验证取消和节点重启后的垃圾回收
验证网络隔离、只读代码输入、artifact 输出与短期身份注入
给出采用、暂缓和明确不适用的 workload 分类

非目标

第一阶段不实现 GPU 共享、MIG/vGPU 或 GPU microVM passthrough
不为统一接口强行替换 Kubernetes、PVE 或各 runtime 的原生控制面
不先建设完整多集群平台；backend registry 与 capability 调度足够时保持简单。

## 背景 Gitea Actions、AI 代码 Review、自动化 merge、依赖更新、OCR 和其他模型任务会执行短命、可重试且可能不可信的 workload。传统 PVE VM 隔离清晰但启动和密度不理想；普通容器启动快，却很难为不可信仓库代码提供足够边界。未来统一计算控制面不应只绑定 PVE，也应能把任务投递到 microVM、Kata Containers 或受限容器 backend。 ## 目标为短命 CI/Agent workload 选择一个可运营的轻量隔离 backend，并定义与 PVE VM、普通 Kubernetes Pod 共存的 capability 模型。第一阶段重点是启动速度、隔离、生命周期和运维复杂度，不追求一次覆盖所有运行时。 ## 候选方向 - Firecracker 或 Cloud Hypervisor 等 microVM - Kata Containers：通过 Kubernetes CRI/RuntimeClass 提供 VM 隔离 - gVisor：适合部分无硬件设备需求的低风险 workload，但不是 GPU/CUDA 甜点位置 - 普通 Kubernetes Pod：仅用于可信代码或作为长驻 inference client/service - PVE/QEMU VM：用于强隔离、完整 OS、Windows、PCI/GPU passthrough 等场景 ## 评估维度 - 冷启动时间、并发密度与 idle overhead - KVM、cgroup v2、网络、存储 snapshot/rootfs 和镜像分发要求 - guest kernel 与宿主攻击面、逃逸边界和多租户适用性 - Kubernetes 集成复杂度，以及是否需要独立集群 - job cancellation、超时、强制销毁、孤儿回收和节点重启恢复 - 日志、metrics、exec/debug 和可观测性 - OCI 镜像兼容、缓存命中与构建流水线 - GPU、vsock、virtiofs、网络策略与 secrets 注入能力 - 上游活跃度、版本升级成本和硬件兼容性 ## 初步工作负载分层 - 可信控制器和长驻模型 API：普通 Kubernetes Pod - 不可信 CI build/test：优先评估 Kata 或独立 microVM - AI Agent 执行工具和仓库代码：强隔离 sandbox；模型服务与代码执行环境分离 - GPU inference：GPU worker 上的长驻服务或整卡独占 Job，第一阶段不依赖 gVisor/microVM GPU passthrough - 完整 OS、Windows、特殊 PCI：PVE VM ## 与统一控制面的接口 backend 应通过 capability 被选择，而不是暴露底层产品： ```yaml requirements: isolation: microvm architecture: amd64 gpu: none networkPolicy: restricted ttl: 30m ``` 需要统一返回 instance/job ID、状态、lease、日志定位和销毁结果；IAM 层签发 workload-scoped 短期凭据，运行环境不保存平台长期 secret。 ## 第一阶段交付 - 选取两个候选做最小 PoC，优先 Kata Containers 与一个直接 microVM runtime - 在目标硬件上测量冷启动、内存开销、并发和销毁可靠性 - 运行真实 Gitea Actions job，并验证取消和节点重启后的垃圾回收 - 验证网络隔离、只读代码输入、artifact 输出与短期身份注入 - 给出采用、暂缓和明确不适用的 workload 分类 ## 非目标 - 第一阶段不实现 GPU 共享、MIG/vGPU 或 GPU microVM passthrough - 不为统一接口强行替换 Kubernetes、PVE 或各 runtime 的原生控制面 - 不先建设完整多集群平台；backend registry 与 capability 调度足够时保持简单。

panxiao81 referenced this issue

2026-09-17 10:27:54 +00:00

建设由 Ansible 与 Flux 管理的正式 OpenSandbox 集群 #83

Sign in to join this conversation.

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: panxiao81/homelab-infra#47