通过 parallelism 和 delay 可精准控制滚动更新的并发数与批次间隔，需配合 start-first 顺序和有效 healthcheck 才能实现零停机；parallelism=1 最稳妥，delay=15s 适合初始化慢的服务。
通过 deploy.update_config 中的 parallelism 和 delay 两个参数，就能精准控制滚动更新的并发数量与时间节奏。关键在于让新容器有足够时间就绪，再逐步替换旧实例，避免服务抖动或中断。
parallelism：控制每次更新几个容器
该参数决定同一轮更新中最多启动多少个新容器。值越小，更新越保守，对系统压力越小；值越大，更新越快，但资源占用和风险也相应上升。
- 设为 1：最稳妥，每次只更新一个副本，适合核心服务或资源受限环境
- 设为 2 或 3：适用于副本数较多（如 6+）、资源较充裕的场景，可缩短整体更新耗时
- 设为 0 或不设置：默认行为是尽可能并行（取决于 replicas 数量），容易造成瞬时资源争抢
delay：设定批次之间的等待时间
它定义了前一批新容器启动并完成健康检查后，到下一批开始更新之间的间隔。这个空档用于验证稳定性、观察监控指标、预留人工干预窗口。
- 5–10 秒：适用于轻量 HTTP 服务，健康检查响应快、依赖少
- 15–30 秒：推荐用于数据库连接初始化较慢、或需加载大缓存的服务
- 过短（如
- 过长（如 >60 秒）：拉长整体更新周期，降低发布效率，但利于人工盯盘
必须配合 order 和 healthcheck 才生效
仅设 parallelism 和 delay 不足以保证平滑——它们依赖于更新顺序策略和就绪判断依据：
-
order: start-first：先拉起新容器，等它通过healthcheck后再停旧容器，这是实现“零停机”的前提 -
healthcheck必须真实反映服务就绪状态（例如检查端口连通 + 关键接口返回 200），否则 delay 和 parallelism 就失去意义 - 若用
order: stop-first，即使设了 parallelism=1，也会先停旧容器再启新容器，必然出现短暂中断
一个生产级配置示例
以下片段确保每轮只更新 1 个副本，等待其完全就绪（健康检查连续通过 3 次）后再继续，两次更新间隔 15 秒，失败自动回滚：
deploy:replicas: 4
update_config:
parallelism: 1
delay: 15s
order: start-first
failure_action: rollback
healthcheck:
test: ["CMD", "curl", "-f", "http://localhost:8080/health"]
interval: 5s
timeout: 3s
retries: 3
