调和灰度发布与恢复
调和(Reconciliation)应分阶段启用。持久化的 Hub 状态是运维人员的事实来源; 节点上报只是观测,绝不能改写期望目标。
灰度发布阶段
- 仅观测:持久化上报并比较期望与观测,但不分发新的 Attempt。检查代际(generation)不匹配、过期节点与配置版本漂移。
- 单节点:为某个节点启用生命周期调和,使用幂等的启动/停止命令。确认离线期间写入的期望状态保持持久,且重连后会向当前代际收敛。
- 配置:在理解生命周期收敛之后,启用配置应用/回滚。只有当节点上报了目标版本,且每条受影响的 Stream 都满足其期望代际与状态后,配置 Intent 才算到达终态。
- 机群:逐步扩展,同时关注被阻塞的 Intent、重试次数、租约过期与调和延迟。
故障与重启行为
临时性传输/节点故障会保留期望状态并安排退避重试。永久性执行失败会变为 blocked,
需要新的代际,例如修正后的配置或回滚。放置拒绝同样按“失败即关闭(fail closed)”处理:
目标节点未全部宣告 network_shuffle 能力与数据地址的 split 放置会在分发前被拒绝,
不会发出部分 job_start。结果丢失的已分发 Attempt 会变为 ambiguous;Hub 不会盲目重放它。
出现分歧的 Intent 需要更新的完整上报后才会获得新的 Attempt。
Hub 重启时,持久化的 Intent 与 outbox 行会被恢复。排队的工作可以继续。 已过期分发的 Attempt 保持模糊状态,直到新的 Agent 上报确认目标是否已经生效。 这样可以避免重复执行重启或其他一次性动作。
节点标签与选择器目标
节点可携带一组由操作者管理的标签映射(PUT /api/v1/nodes/{id}/labels,整体替换,每节点最多 16 条、每段 1-63 字符)。标签是 Hub 的持久状态:Agent 重注册与 Hub 重启都不会改变标签,每次替换都落审计。控制台在集群总览提供标签编辑,并支持按标签创建 rollout。
创建 rollout(或经审批提交)时,目标选择可以是显式节点列表,或者标签选择器,例如 {"env": "prod", "tier": "edge"}。由解析语义引出两条运维规则:
- 选择器在创建或提交时一次性解析。之后获得该标签的节点不会被自动纳入;要包含它们,创建新的 rollout。审批策略开启时,待审批请求钉住解析后的节点集,晚些批准也无法偷换目标。
- 匹配读取持久化节点记录而非实时注册表:携带该标签的排空中或失联节点仍然被选中,Hub 重启后尚未重注册的节点同样如此——与显式列出其 id 的效果完全一致。批次是否收敛、何时收敛由 rollout 健康门控决定。
解析结果为空集(no_matching_nodes)时直接拒绝请求。
计划内节点排空
排空(drain)节点改变的是可用性,而不是运维意图。Hub 应停止向排空中的节点分发新工作, 同时保留期望的 Stream 状态。节点重新上线后,注册/上报事件会恢复当前代际的调和。 希望 Stream 保持停止状态的运维人员必须显式写入停止的期望状态。
配置审批闸门
设置 control_api.approval_required: true(配合 approval_ttl_ms,默认
24 小时)后,任何配置 rollout 创建之前都需要第二个身份的审批。全部创建
路径都被门控——批量创建、节点级 apply 与回滚——直接创建会被显式的
approval_required 错误拒绝并指向审批流:
- 运维人员提交
POST /config-approvals,钉住配置版本、目标节点与批 大小。提交会校验版本与节点,但不创建任何东西。 - 另一个身份(admin 角色——
ApproveRollouts动作不授予 operator 角色) 批准或拒绝该请求。 - 批准后以审批人为 actor 创建 rollout。批准过程中崩溃(rollout 已建但 请求未标记)通过认领恢复:每个请求至多产生一个 rollout。
回滚仅在目标版本曾应用到受影响节点时豁免:回滚到一个从未应用过的版本 属于新内容借道回滚路径,会被拒绝。
由此带来两条运维要求。单条静态 operator 凭据只解析出一个身份,因此 无法批准自己的提交——在单身份部署上开启该策略会冻结发布(Hub 启动 时检测到会输出告警)。开启闸门前请准备至少两个 operator 身份(结构化 凭据或 OIDC)。被拒绝与过期的请求是终态;重新发布需提交新请求,控制台 可从被拒请求预填。它不会删除失败的版本,也不会改写之前的观测上报。 原操作连同其失败类别与关联 ID 保持可见,新版本则被独立跟踪,直到观测到收敛。