# ADR-0002：采用 k0s 与可选工作负载运行时

- 状态：Accepted
- 日期：2026-09-17

## 背景

Ayatori 需要 Kubernetes API machinery 提供 CRD、watch、RBAC、admission 和 controller
运行模型，但它并不天然要求在同一环境中调度容器 workload。最小控制面应能够仅作为
基础设施 API 使用。

k0s 的 controller 角色默认不运行 kubelet 或容器运行时，因此控制节点不可被用户调度。
这符合将 Kubernetes API 作为独立控制面运行时的需求。

然而 Ayatori 的完整 GitOps 模式需要运行 Flux controllers；Ayatori controllers、
Crossplane 组件以及 Kubernetes Pod executor 也适合以 Pod 交付。因此正常运行形态仍然
需要工作负载调度能力。

## 决策

Ayatori 采用 k0s 作为 Kubernetes API/control-plane 发行版，并将工作负载运行时视为
可选部署组件，而不是 API 控制面的固有组成。

控制节点始终保持 controller-only：

- 不运行 kubelet；
- 不运行容器 runtime；
- 不注册为 Node；
- 不承载 Flux、Ayatori controller 或用户 Job。

通过向集群加入独立 worker 启用工作负载调度。加入或移除 worker 不改变 API、CRD、
数据库和控制节点身份。

定义两种受支持的运行 profile。

### API-only

```text
k0s controller-only
├── kube-apiserver
├── control-plane components
└── external controllers/processes
```

该 profile 不存在可调度 Node，不运行 Flux。它用于最小控制面、bootstrap、恢复、API
开发和不需要 in-cluster controller 的特殊部署。

### Managed runtime

```text
k0s controller-only
        │
        ├── management worker pool
        │   ├── Flux
        │   ├── Ayatori controllers
        │   └── platform operators
        │
        └── execution worker pool（可选）
            └── Job Pod executor workloads
```

该 profile 是 Dev 与 Prod 的正常运行形态。它在 API-only 基础上加入至少一个 worker，
从而启用完整 GitOps 和 in-cluster controllers。

management worker 使用专用 label、taint、toleration 和 resource reservation，默认不接受
普通应用 workload。Job Pod executor 优先使用独立 execution worker pool；资源受限的
Dev 环境可以暂时合并两类 worker，但必须保留调度约束。

## Bootstrap 边界

Flux 无法负责创建承载自身的第一个可调度 worker，因此以下部分位于 GitOps 闭环之外：

- k0s controller 初始安装；
- 控制面数据库和 PKI 恢复；
- 第一个 management worker 的加入；
- Flux 首次 bootstrap。

这些步骤必须由可重复执行的 bootstrap 流程管理，例如固定版本的 Ansible、安装脚本或
人工 Runbook。Flux 成功运行后，in-cluster controller、策略和后续 worker 配置进入
GitOps 管理。

平台必须保留从 API-only 恢复到 managed runtime 的流程，避免 Flux 故障形成无法恢复的
自举循环。

## 工作负载范围

引入 worker 不改变 Ayatori 的定位。该集群是专用 management environment，而不是通用
应用集群。允许的 workload 默认限于：

- Flux 与平台 controller/operator；
- admission webhook 和必要的控制面辅助组件；
- Job Service 选择 Pod executor 后创建的受管任务；
- 平台恢复和诊断所需的短期 workload。

普通长期应用仍运行在其所属 workload cluster、VM 或其他后端。

## 结果

- 保留纯 API 控制面的简洁性与恢复价值。
- 能够使用 Flux 完成平台组件的 GitOps 管理。
- 能够直接复用 Kubernetes 生态中的 operator，而无需改写为 systemd 服务。
- 控制节点不会因为加入 workload runtime 而成为可调度节点。
- Dev 与 Prod 需要额外规划少量 management worker 容量。
- bootstrap 层不能完全由 Flux 自我管理，必须独立记录并验证恢复流程。

## 参考

- [k0s Architecture](https://docs.k0sproject.io/stable/architecture/)
- [k0s Configuration Options](https://docs.k0sproject.io/stable/configuration/)
- [Flux installation](https://fluxcd.io/flux/installation/)