64 lines
2.7 KiB
Markdown
64 lines
2.7 KiB
Markdown
# 路线图
|
||
|
||
路线图按能够立即产生价值的纵向切片推进，而不是先构建完整通用框架。
|
||
|
||
## 0. 平台基础
|
||
|
||
- 建立 Dev 与 Prod API/control plane。
|
||
- 建立认证、RBAC、OpenBao 凭据和备份恢复。
|
||
- 定义 API、conditions、ownership 和 executor 公共约定。
|
||
- 建立不可变制品与 Dev 到 Prod promotion。
|
||
|
||
## 1. Controller 纵向验证切片
|
||
|
||
- 使用当前最小 `Job` API 验证 watch、状态机、finalizer、取消、TTL、external reference 与
|
||
backend adapter。
|
||
- Kubernetes executor 不能与 management API client 或同集群 namespace 语义绑定。
|
||
- 验证完成后，将可复用机制收敛为内部 `Run`/execution 能力；不把这一切片扩展为 FaaS、
|
||
Cloud Run 或通用 Job Service。
|
||
|
||
## 2. 首批资源产品
|
||
|
||
- `Database`：PostgreSQL database、role、credential 与回收。
|
||
- `LoadBalancer`：Envoy 配置/xDS、健康检查、固定 VIP 与 GoBGP 路由宣告。
|
||
- `Bucket`：SeaweedFS bucket、policy、credential 与删除策略。
|
||
- 按纵向价值选择先后，不为三者预先建立统一 provider 框架。
|
||
|
||
## 3. Human Executor 与延迟自动化
|
||
|
||
- `ManualTask`、`TaskReport` 和版本化 Runbook。
|
||
- Telegram/Email 通知、领取、提醒和升级。
|
||
- 后端验证与上游 reconcile 恢复。
|
||
|
||
## 4. Compute 与节点生命周期
|
||
|
||
- 建立稳定的 `VirtualMachine` 北向 API，并支持现有资源 adopt。
|
||
- 南向按能力组合 Proxmox API、节点受限 Agent/CLI 与 `ManualTask`，不假设 Proxmox API 完整。
|
||
- Node 加入、drain 和 `SafeToRemove`；Node API 由 Ayatori Compute Agent 实现，不依赖 kubelet。
|
||
- StorageClass、StoragePool、Volume 与迁移计划。
|
||
- 先支持人工磁盘迁移，再按实际收益自动化。
|
||
|
||
## 5. 条件性扩展
|
||
|
||
- OpenSandbox/microVM 可以作为内部 Run backend，但不由此产生 FaaS 产品承诺。
|
||
- DNS、证书和 Credential 只有在跨系统协调收益明确时形成独立资源。
|
||
- KaaS 只有出现托管控制面、租户隔离或频繁集群生命周期的真实需求时才立项。
|
||
|
||
### KaaS 候选方案
|
||
|
||
- 采用成熟 hosted-control-plane 后端。
|
||
- 组合控制面、worker、LB、DNS、网络和凭据。
|
||
- 用户集群只暴露 worker node，控制面完全由平台托管。
|
||
- 本节记录候选实现边界，不构成路线图承诺。
|
||
|
||
## 后续 Compute 验收场景
|
||
|
||
Database 等首批资源优先落地。Compute 开始实施后，以 Laptop Rebuild Readiness 验证节点
|
||
生命周期与恢复能力；该场景不作为首批 Database、LoadBalancer 或 Bucket 的交付前置条件：
|
||
|
||
1. 临时节点加入。
|
||
2. laptop 上的 workload 被重建、迁移或形成可执行人工任务。
|
||
3. laptop 达到 `SafeToRemove=True`。
|
||
4. laptop 重装并重新加入。
|
||
5. 临时节点排空并安全退出。
|