蓝绿部署最早来自物理机时代的发布策略，但在容器化和Kubernetes环境中才真正变得轻量。它的核心逻辑很简单：保留当前线上版本作为绿环境，再创建一套完全相同的蓝环境运行新版本。两个环境同时存在，只有一套接收生产流量。新版本在蓝环境中完成启动、健康检查和预热后，通过一次路由切换把用户请求指向蓝环境。如果出现异常，可以立即切回绿环境，避免长时间停机或者错误版本影响用户。对容器化应用而言，Pod的快速创建销毁和Service的动态选择器让这种切换变得非常直接。
一、蓝绿部署的核心机制与传统发布差异
传统滚动更新会直接替换旧Pod，过程中新旧版本同时处理请求。如果新版本存在协议不兼容、资源泄漏或业务逻辑错误，问题会立刻扩散到线上用户。蓝绿部署则把变更过程隔离出来：绿环境持续稳定服务，蓝环境部署新版本并接受自动化验证，验证通过后才切换流量。这样即使新版本有缺陷，也不会在发布过程中污染旧环境。
资源成本是蓝绿部署最明显的代价。切换前需要有足够的CPU、内存和网络资源同时运行两套完整环境。对于大规模微服务集群，这种翻倍需求可能带来不小的账单压力。因此蓝绿部署通常用于核心交易链路、对外API网关等对可用性要求极高的场景，而不是所有内部服务都盲目套用。
适用边界也很重要。如果应用无状态、数据库变更向前兼容、接口只增不改，蓝绿部署几乎是最优选择。但如果新旧版本需要同时写不同结构的数据库表，或者两个版本无法共享消息队列和缓存，蓝绿切换会变得非常复杂，这时可能需要引入金丝雀发布或特性开关来逐步放量。
二、在Kubernetes中构建蓝绿环境的三种方式
最直接的实现是创建两套Deployment，它们使用相同的业务标签，但版本标签不同。例如两套Deployment都带有app=web，其中一个version=green，另一个version=blue。Service只需要通过选择器指向其中一个版本，就能决定流量落在哪套环境。
apiVersion: apps/v1
kind: Deployment
metadata:
name: app-blue
spec:
replicas: 3
selector:
matchLabels:
app: web
version: blue
template:
metadata:
labels:
app: web
version: blue
spec:
containers:
- name: web
image: registry.ipipp.com/app:2.0.0
ports:
- containerPort: 8080
对应的Service可以选择绿环境作为当前生产后端：
apiVersion: v1
kind: Service
metadata:
name: app-svc
spec:
selector:
app: web
version: green
ports:
- protocol: TCP
port: 80
targetPort: 8080
当蓝环境部署完成并通过健康检查后，只需要修改Service的选择器，把version从green改成blue，流量就会切换到新环境。这个操作可以用kubectl命令完成：
kubectl patch service app-svc -p '{"spec":{"selector":{"version":"blue"}}}'
第二种方式是使用Ingress按Host或路径进行切换。例如old.web.ipipp.com指向绿环境，new.web.ipipp.com指向蓝环境。测试完成后修改Ingress规则，让主域名指向蓝环境。不过这种方式切换粒度更粗，而且DNS缓存可能会影响生效时间。第三种方式是基于Istio等Service Mesh实现权重路由，把蓝绿切换升级为更细粒度的流量分配，甚至可以做灰度切流和自动回滚。
三、数据库迁移和会话保持的落地策略
数据库是蓝绿部署最大的约束。两套应用共用同一个数据库时，必须保证新版本的Schema变更对旧版本兼容。推荐的策略是向前兼容迁移：先增加新列或新表，不改动旧结构；切换完成后，等旧版本完全下线，再删除废弃字段。禁止在蓝绿切换前执行删除列、修改列类型或重命名字段，否则旧环境会直接报错。
会话保持问题同样不能忽略。如果应用使用基于Cookie的本地Session，切换后用户的会话在蓝环境中并不存在，会导致突然登出或购物车清空。解决办法包括将Session集中存储到Redis，或者改用JWT这类无状态令牌。对于短时间无法改造的系统，可以在Ingress或负载均衡层配置一定时长的粘滞会话，让已登录用户继续留在旧环境，直到新会话自然建立。
缓存预热也需要提前规划。蓝环境刚接收流量时，如果Redis或本地缓存是空的，大量请求会直接打到数据库，可能造成瞬间压力。可以在切换前通过脚本或消息回放给蓝环境预热热点数据，也可以在切换后设置一段低流量观察期，待命中率恢复后再全量放量。
四、自动化流水线与监控回滚
蓝绿部署能否可靠执行，取决于流水线自动化程度。一条典型的蓝绿发布流水线包含这些步骤：构建并推送镜像、部署蓝Deployment、等待Pod就绪、执行冒烟测试、修改Service选择器切换流量、持续观察指标、异常时自动切回、成功后缩容绿环境。等待Pod就绪可以使用kubectl wait命令：
kubectl rollout status deployment/app-blue kubectl wait --for=condition=available --timeout=120s deployment/app-blue
切流之后的监控不能只看启动成功。需要重点观察错误率、P99延迟、CPU和内存使用率，以及应用日志中的异常堆栈。前五分钟是最危险的窗口，建议在流水线中设置自动回滚策略：如果错误率超过阈值，立即把Service选择器切回version=green，并触发告警。
回滚时不要重新构建旧版本，因为绿环境一直保留着。直接执行一次反向切换即可。绿环境应该至少保留一个完整的业务周期，通常建议24小时以上。这样既能覆盖交易高峰，也能给问题排查留出时间。等到新版本运行稳定后，再缩容或删除绿Deployment，释放集群资源。
蓝绿部署不是万能方案，但它把发布从高风险操作变成可控的流量切换。对容器化应用来说，配合Kubernetes原生对象和Service Mesh能力，再加一套明确的数据库兼容策略，完全可以把故障恢复时间压缩到秒级。核心业务的发布体验，会因此发生质的改变。
蓝绿部署容器化应用Kubernetes修改时间：2026-09-17 15:23:45