Docker镜像Tag实现灰度发布的核心是通过规范命名（如v1.2.1-gray）标识版本阶段，结合Kubernetes多Deployment与Service Mesh/Ingress按标签和权重分流，并在CI/CD中自动化构建、部署、验证与回滚。
使用 Docker 镜像的 Tag 功能做灰度发布，核心是通过不同 Tag 区分版本（如 v1.0.0、v1.0.1-rc、gray-v1.0.1），再结合编排工具或服务发现机制，将部分流量导向带特定 Tag 的容器实例。它不依赖复杂平台，但需要严谨的命名规范和部署协同。
用 Tag 明确标识灰度版本
Tag 不是随意起名，要体现用途和阶段。推荐格式：{环境}-{功能}-{版本号} 或 {版本号}-{stage}，例如：
-
v1.2.0：正式稳定版，全量上线 -
v1.2.1-rc：预发布候选，供内部验证 -
v1.2.1-gray：灰度版本，仅 5% 流量接入 -
v1.2.1-canary：金丝雀版本，固定几台节点运行
避免使用 latest 做灰度——它不可追溯、易覆盖、违反可重现原则。
配合 Kubernetes 实现流量分流
Kubernetes 本身不直接解析镜像 Tag 做路由，需借助 Service + 多 Deployment + 标签选择器 组合实现：
- 为灰度版本单独创建 Deployment，镜像指定为
myapp:v1.2.1-gray，并打上标签version: gray - 稳定版本 Deployment 使用
myapp:v1.2.0，标签为version: stable - Service 的
selector暂不直接匹配 version，改用统一 label（如app: myapp），再通过 Service Mesh（如 Istio）或 Ingress 控制器（如 Nginx Ingress with canary annotations） 按权重/请求头/用户 ID 分流
例如 Istio VirtualService 可这样配置灰度规则：
- headers:
cookie:
exact: "user-type=beta"
route:
- destination:
host: myapp
subset: gray
在 CI/CD 流程中自动化 Tag 管控
灰度不是手动改 YAML 文件，而是嵌入流水线：
- Git 分支策略：
main对应稳定 Tag，release/v1.2.x或feature/gray-login触发灰度镜像构建，自动打v1.2.1-grayTag 并推送到镜像仓库 - 部署阶段判断：根据触发分支或 PR 标签，决定部署到灰度 namespace 还是 production namespace，并更新对应 Deployment 的
image字段 - 加一道人工确认门禁：灰度发布后，自动触发健康检查（HTTP 探针 + 自定义指标），达标才允许执行“全量升级”动作（即把 stable Deployment 的 image 改为新版本）
监控与回滚必须绑定 Tag
每个 Tag 版本上线后，监控看板要能按 image.tag 维度聚合指标（QPS、延迟、错误率、JVM 内存）。一旦异常：
- 立即停止灰度扩缩容
- 用 kubectl 快速回滚：
kubectl set image deploy/myapp-app myapp=myapp:v1.2.0 - 保留灰度镜像不删除（哪怕已下线），便于复现问题；建议镜像仓库开启保留策略，至少存最近 3 个灰度 Tag
Tag 是灰度的“版本指纹”，不是装饰。用好它，能让发布从“赌一把”变成“看得见、控得住、退得快”。
