生产环境平滑滚动更新需采用带环境与构建上下文的组合标签（如api-service:2.4.1-prod.127_8f3a1c9），通过声明式更新镜像字段触发K8s或Swarm滚动替换，配合Always拉取策略与可回退的稳定别名（如-prod），确保可追溯、可审计、零停机。
用自定义标签实现生产环境的平滑滚动更新，核心在于让标签既承载版本语义，又可被系统精准识别和触发更新，同时避免人为误操作。关键不是“打个新标签”，而是构建一套可预测、可审计、可回退的标签驱动流程。
标签设计必须包含可识别的变更标识
单纯用 v1.2.3 或 latest 无法支撑滚动更新的自动化判断。生产环境推荐采用带环境+构建上下文的组合标签，例如：
-
api-service:2.4.1-prod.127_8f3a1c9—— 明确指向生产环境、第127次CI构建、对应Git提交 -
api-service:2.4.1-prod—— 作为“稳定生产流”别名，由CI在验证通过后自动重打（覆盖）该标签
其中 -prod 是关键：它让Kubernetes或Swarm能区分开发/预发/生产镜像；而 .127_8f3a1c9 提供唯一性与可追溯性，防止并发构建冲突。
滚动更新时只修改Deployment或Service中的镜像字段
不要删旧镜像、不要手动拉取，而是通过声明式方式触发替换：
- Kubernetes中，直接更新Deployment YAML里的
image: api-service:2.4.1-prod，然后kubectl apply - Docker Swarm中，执行
docker service update --image api-service:2.4.1-prod web-service
此时K8s或Swarm会按策略（如并行数、延迟、健康检查）逐步替换Pod/Task，旧实例持续服务直到新实例就绪。整个过程无需停机，也不依赖本地缓存是否命中。
配合镜像拉取策略确保行为可控
标签本身不决定是否拉取新镜像，真正起作用的是 imagePullPolicy：
- 设为
Always：每次启动都强制从仓库拉取，适合使用动态标签（如-prod）的场景，确保拿到最新推送 - 设为
IfNotPresent：仅当本地无该标签镜像时才拉取，适合已预热镜像的集群，但需确保节点上没有残留旧版同标签镜像
注意：latest 标签默认触发 Always 策略，但不建议在生产中使用 latest——它掩盖了实际版本，破坏可追溯性。
回滚只需改回上一个可靠标签
滚动更新失败时，回滚不是“重启旧容器”，而是把镜像字段切回前一个已验证的标签：
- 例如从
2.4.1-prod切回2.4.0-prod，再次kubectl apply - Swarm中执行
docker service update --image api-service:2.4.0-prod web-service
系统会再次执行滚动替换，旧版本镜像若仍在仓库中即可立即生效。前提是——你没删除过旧标签镜像，且标签命名保留了历史版本粒度（比如不覆盖 v2.4.0，只更新 -prod 别名）。
