kubernetes蓝绿发布核心是通过service selector或ingress切换流量入口实现瞬时切换：先部署新旧两个deployment并用不同version标签区分，再更新service selector指向新版本，或通过ingress重定向流量，全程零宕机且支持秒级回滚。
Kubernetes 实现蓝绿发布，核心是让新旧两个版本的应用并行运行，再通过控制流量入口（通常是 Service 或 Ingress）完成瞬时切换，全程不中断服务。
用 Service selector 切换版本（最轻量）
这是原生、无额外组件的实现方式，适合基础场景：
- 部署两个 Deployment，比如
app-v1和app-v2，它们的 Pod 都带公共 label（如app: myapp），但用不同版本 label 区分（如version: v1/version: v2） - 创建一个 Service，其
selector初始只匹配v1（例如app: myapp, version: v1） - 验证
v2就绪后，直接更新 Service 的 selector，把version: v1改为version: v2 - Kubernetes 会立即重路由所有流量到
v2的 Pod，旧v1仍保留在集群中，可随时切回
用 Ingress + Canary 注解做蓝绿（更可控）
当需要借助七层网关控制入口，且希望保留回滚能力或做前置验证时：
- 为
v1和v2分别创建独立的 Service - 配置两个 Ingress：主 Ingress 指向
v1；另一个带nginx.ingress.kubernetes.io/canary: "true"的 Ingress 指向v2 - 通过
canary-by-header或canary-by-cookie让内部人员或测试环境先访问v2，确认无误 - 最后将主 Ingress 的 backend 切换为
v2的 Service，或直接删除旧 Ingress、重命名新 Ingress 为生产名
关键注意事项
蓝绿不是“部署完就切”，而是一套需协同验证的动作：
- 两个版本的 Pod 必须使用兼容的 API 协议和数据格式，避免切换后调用失败
- Service 切换是秒级生效，但需确保新版本 Pod 已全部
Ready（检查kubectl get pods -l version=v2） - 切换前后建议触发一次健康检查请求，比如
curl -I http://$EXTERNAL_IP/healthz - 配套的 ConfigMap/Secret 若有变更，需提前同步到
v2环境，避免切流后配置缺失
为什么推荐先用 Service 方式
它不依赖 Ingress 控制器、不引入 Istio 等复杂组件，仅靠 Kubernetes 原生对象就能完成完整蓝绿流程。对中小规模业务或 CI/CD 流水线中的自动化发布来说，够用、稳定、易排查。等流量策略变复杂（比如按用户 ID 分流、多维度灰度），再平滑升级到 Ingress 或 Service Mesh 方案。
