Cloud Operator 是 ZJUSCT Cloud 的虚拟机控制器：在 Kubernetes 中管理持久 CloudVM，创建 launcher Pod 并复用默认 scheduler。VM 的系统盘使用独立 PVC，当前实验接入现有 Ceph RBD。
当前为 v0.1 后端验收版。已在 m600 隔离环境跑通 Ubuntu 24.04、SSH、持久盘、启停和离线备份恢复；门户、正式租户管理及服务发布仍在设计中。
- 协作仓库：ZJUSCT/cloud-operator
- 现有代码来源：Sushidesu486/cloud-operator
- 运行组件：ZJUSCT/cloud-launcher
- 端到端验收与实验操作 · CPU 密度实验 · launcher 协议
门户 / Cloud API（计划中：身份、授权、配额）
↓
CloudVM → cloud-operator Deployment → launcher Pod 定义
↓
Kubernetes 默认 scheduler
↓
launcher → Firecracker / KVM → guest
↕
Ceph CSI / RBD PVC
- Operator： 调谐 CloudVM 和 launcher Pod、检查根盘归属、记录 VM 生命周期状态。
- Kubernetes： 默认 scheduler 根据 Pod 资源请求和节点约束调度；CSI 提供持久块设备。
- Launcher： 按版本化配置在 Pod 内运行一台 Firecracker VM，处理 TAP、停止和退出结果；源码独立维护。
- 门户/API（计划）： 登录、用户与资源归属、配额和产品接口。可以与本仓库协作开发，作为独立服务运行。
Operator 与 launcher 没有跨仓库 Go 模块依赖；接口以协议文档为准，不兼容变更需要版本化并同步两端。
| 能力 | 状态 |
|---|---|
| 实例生命周期 | CloudVM CRD、显式启动/停止、Pod 状态及 SSH 就绪已在实验环境验证 |
| 系统与磁盘 | Ubuntu 24.04、固定 ZJU Mirror 镜像、独立 Ceph RBD 系统盘；停止后保留数据 |
| 访问与网络 | 实验环境通过 m600 跳板、Service 和 launcher SSH relay 登录；有 Pod NAT、DNS 和隔离策略 |
| 备份恢复 | 支持停机后备份到 m600 本地、恢复到新 PVC 并启动；异机备份和正式策略待完善 |
| 门户与用户入口 | 尚未接入；共享 SSH 网关、Git OAuth 绑定与网站域名方案正在讨论 |
| 密度实验 | 10 / 20 台各 1 vCPU、512 MiB 的 VM 共享一个逻辑 CPU，详见下文与实验报告 |
端到端验收使用 1 vCPU / 1 GiB / 8 GiB 的 Ubuntu VM。实验版 launcher Pod 使用 privileged 和只读 hostPath，正式部署需要继续收敛权限。
| 字段 | 用途 |
|---|---|
owner |
稳定用户标识，创建后不可变 |
rootVolumeClaim |
同命名空间的独立 raw block PVC，创建后不可变 |
vcpus / memoryMiB |
guest 规格；当前允许 1–4 vCPU、128–4096 MiB |
powerState |
Running 或 Stopped |
bootID |
递增的显式启动请求；相同 bootID 的重试保持幂等 |
状态包含 Pending、Running、Stopping、Stopped、Failed、Blocked、Unknown，以及原因、Pod、节点等信息。启用实验网络时，Running 等待 guest SSH banner 就绪。guest 正常退出后保持停止；重新启动需要新的 bootID。当前 guest 内 reboot 也结束本次运行，平台 restart 使用停止后重新启动。
PVC 的 owner 和 claim 标记由可信控制面维护。删除 CloudVM 保留根盘及其预约；释放卷之前要确认旧 writer 已停止。已观测 Pod 丢失或旧 Pod 仍在终止时，控制器先报告状态；跨节点接管需要补齐 fencing。普通用户通过未来的平台 API 操作资源，由 API 负责授权。
需要 Go 1.25 或更新版本。两个仓库建议放在同级目录：
git clone git@github.com:ZJUSCT/cloud-operator.git
git clone git@github.com:ZJUSCT/cloud-launcher.git
make -C cloud-launcher test build
make -C cloud-operator test build在 Operator 仓库内执行：
make test
make build
make generate # 修改 API 后重新生成 DeepCopy 和 CRD当前 go.mod 和内部 import 使用 github.com/Sushidesu486/cloud-operator；组织仓库迁移及 module 路径调整由仓库所有者处理。Go 本地测试验证控制逻辑与协议；真实调度、KVM 和 Ceph 行为需在隔离 Linux 集群验证。
先阅读 Ubuntu 验收说明。当前保留的验收环境支持以下只读查询及 SSH 体验：
python3 hack/acceptance.py status
python3 hack/acceptance.py ssh alice
python3 hack/acceptance.py ssh bob启动、停止、创建、备份、恢复等操作见验收说明，运行前先了解这些命令对现有实例与 PVC 的影响。早期 BusyBox 生命周期实验在 hack/lab.py；其 cleanup 会删除对应实验 namespace、PVC 和 CRD，适用于明确可回收的环境。实验资源不由生产 Argo 管理。
共享 CPU 密度实验以一个逻辑 CPU 作为整组 VM 的预算：轻量 HTTP 总计 100 RPS 下，10 台 P95 为 8.6 ms、20 台为 11 ms。实验中的 Pod 资源和 CPU affinity 是单独设置；当前 Operator 仍按 vCPU 设置 Pod CPU request / limit，需先改造资源配置才能用于日常超售。实验条件与结果
api/v1alpha1/ CloudVM 类型与生成的 DeepCopy
config/crd/ CRD
config/samples/ CloudVM 示例
cmd/cloud-operator/ 控制器入口
internal/controller/ 调谐、Pod 创建与状态逻辑
images/ 镜像目录、根盘构建与卷传输
hack/ 实验、验收和密度测试脚本
docs/ launcher 协议、验收与压测报告
evidence/ 已记录的实验结果
- 调度与资源： 拆分 guest vCPU 与 Pod CPU request / limit，明确内存开销和资源配额，在隔离节点验证默认调度与共享 CPU。
- 生命周期和恢复： 完善退出结果、guest reboot、Operator / 节点重启后的状态恢复；跨节点自动接管前处理 fencing 与卷单写。
- 存储与镜像： 完善版本化模板、克隆、磁盘归属、备份保留及异机恢复；逐个验证并开放 OS 镜像。
- 门户与产品 API： 设计 Git OAuth / 静态用户、实例归属、配额和操作审计；用户通过 API 访问自己的资源。
- 网络接入： 与网络负责人讨论统一 SSH 网关、个人校园网络认证、平台与自定义网站域名；确认接口后对接 Service 和路由。
- 部署与运维： 收敛 launcher 权限及运行资产交付，补齐长期运行监控、宿主资源预算和恢复演练。
本仓库的开发约束见 AGENTS.md。修改协议时同时更新 launcher；涉及生产环境的配置按团队 GitOps 流程交付。