docs: refine managed runtime topology

2026-09-17 16:28:34 +00:00
parent beda443f2c
commit 546d9dbf1d
2 changed files with 41 additions and 35 deletions
@@ -1,7 +1,13 @@
 # 环境与发布

-Ayatori 从第一天维护 Dev 与 Prod 两套控制面，因为首个稳定产品能力会立即承载真实服务，
-同时后续能力仍需要破坏性集成测试。
+Ayatori 首先建立 Dev。首个产品能力完成开发并达到可发布状态前，Prod 不实际存在；此时
+没有生产制品需要承载，提前维护第二套环境没有收益。
+
+Dev 使用 managed runtime profile，以单台启用了 worker 的 k0s control node 同时承载
+API、Flux、Ayatori controllers 和平台 operators。Job 等非控制 workload 应使用外部
+执行后端或后续加入的 execution worker，不与平台控制组件争抢资源。
+
+首个功能通过 Dev 集成测试后，创建独立 Prod，并从该制品开始执行正式 promotion 流程：

 ```text
 source commit
@@ -17,8 +23,12 @@ Prod deployment of the same artifact

 不维护长期漂移的环境分支。Git 中分别声明 Dev 与 Prod 当前采用的不可变制品版本或 digest。

-Dev 应连接真实后端，但使用独立身份、地址空间和资源范围。Dev 凭据在后端权限层面不应
-具备修改 Prod 资源的能力。
+Prod 建立后，Dev 与 Prod 使用独立 API、数据库、身份和凭据。Dev 应连接真实后端，但
+使用独立地址空间和资源范围；Dev 凭据在后端权限层面不应具备修改 Prod 资源的能力。
+
+Prod 默认同样使用 managed runtime profile，并将 Flux 与 Ayatori controller 调度到启用
+worker 的 control node。是否采用多个 control node、是否加入独立 execution worker，由
+首个生产功能的可用性和容量需求决定，而不是 Dev 阶段预先建设。

 当前手工管理的基础设施视为 legacy 数据面，由 Prod 逐项 import/adopt 或替换；它不是
 第三套 Ayatori 控制面。