凌晨两点我盯着监控大屏上那个跳动的错误率指标脑子里只有一个念头这版本要是能瞬间回退哪怕让我连加三天班都愿意。那次发布事故之后我开始认真研究蓝绿发布并在Kubernetes上完整落地。其实蓝绿发布的原理一点都不复杂一套在跑的老版本蓝一套待命的新版本绿流量在两者之间瞬间切换。真正复杂的是怎么在Kubernetes这个生态里把它做得干净、可靠、可回滚。这篇文章我会把一次完整的蓝绿发布拆开揉碎讲清楚覆盖核心原理、资源设计、操作步骤、回滚机制以及我在实践中踩过的坑——会话保持、长连接池、配置漂移这类问题网上教程基本不会告诉你。适合正在维护Kubernetes集群的运维、SRE以及需要自己管发布流程的后端开发。哪怕你只是刚接触Kubernetes跟着操作一遍也能建立起对发布流程的完整认知。1. 为什么说蓝绿发布是Kubernetes里的“安全气囊”1.1 它解决了什么问题发布永远是线上事故的高发时段。传统的滚动更新Rolling Update虽然是Kubernetes默认策略但它的核心逻辑是“逐步替换旧Pod”新Pod起来一个旧Pod销毁一个。这种方式的问题是新旧Pod会同时接收流量如果新版本有严重Bug用户会在整个滚动过程中陆续受害而且回滚时需要再滚一遍耗时很长。蓝绿发布解决的正是这两个痛点。要点是始终有两套完整的环境旧版本蓝持续承接线上流量新版本绿先在旁边空跑、预热、验证确认没问题之后通过一个“开关”把流量整体切过去。切换是瞬时的回滚也一样——把开关再拨回来。在Kubernetes里这个“开关”就是Service的selector。你不需要改动Deployment的任何Pod只需要修改Service选中哪一组标签流量就整体换了个方向。这个操作快的话几秒钟就能完成而且不涉及任何Pod的销毁和重建。我习惯把这套机制形容成“安全气囊”平常它低调待命看起来像是浪费了双倍资源真出事的时候它能在你最慌张的时刻帮你把伤害降到最低。1.2 什么时候该用它什么时候别硬上蓝绿发布不是万能的我在不同团队见到不少滥用的情况这里先说清楚边界。适合的场景是核心业务、对可用性要求高、不能接受长时间发布窗口的服务。比如支付回调接口、用户登录服务、订单核心链路。这类服务一旦发布出错影响面是几分钟内立刻放大必须能秒级回滚。蓝绿发布天然适合。另外如果你的团队发布频率不高、每次都紧张兮兮蓝绿发布也能显著降低发布心理压力。不太适合的场景也明显第一资源紧张。蓝绿发布需要常驻两套环境等于Pod数量翻倍。如果你集群本来就捉襟见肘或者费用敏感请慎重。第二对数据库有较强状态依赖且没有做兼容的服务。比如新版本改了表结构、加了字段切过去之后万一要回滚老版本连新表结构往往撑不住。这个问题不是蓝绿发布本身能解决的需要配合数据库的双写或兼容层。第三无状态、低风险的内部服务用滚动更新其实更省事没必要杀鸡用牛刀。提示决定要不要上蓝绿发布先问自己一个问题——万一新版本上线后出问题你能否接受“回滚后老版本也无法工作”的连锁反应如果答案是否定的你得先解决数据库兼容性再谈发布策略。2. 动手前的三板斧Service、Deployment与网络选型2.1 Service selector是发布切换的“总开关”Kubernetes里的Service是一层稳定的访问入口后端Pod通过标签label被选中。蓝绿发布的核心操作就是修改这个Service的selector让流量从选中“蓝”的Pod改为选中“绿”的Pod。这里有个关键认知同一个Service下只能有一个selector。你可能见过一些文章说“Service里配置多个selector就能灰度”——那是误解。Service的selector就是一组键值对最终选中的是一组符合全部标签的Pod。如果你同时选中了蓝绿两套Pod流量就会在两者之间负载均衡这不是蓝绿发布这是混流。所以蓝绿发布的资源模型非常清晰两个Deploymentdeployment-blue标签version: bluedeployment-green标签version: green。一个Serviceselector指向当前在线的版本标签比如version: blue。切换动作把Service的selector从version: blue改成version: green。Service本身不会重启Pod也不会重建只改了转发目标。整个过程对调用方透明这是这个设计最妙的地方。2.2 版本标签设计别把宝全押在app标签上标签设计直接影响切换的安全性和便捷性。我见过有些团队偷懒只给Pod打一个标签app: myapp然后两个Deployment都打这个标签。等切换的时候发现Service把两边的Pod都选中了流量直接混流发布当场乱套。正确的做法是至少两个标签维度app: myapp标识应用名用来做全局筛选和排查。version: blue或version: green标识版本身份Service selector用它做精确定位。如果你有金丝雀发布的需求还可以再加一个track: stable或release: canary之类的标签不过那是后话。蓝绿发布开始阶段严格按照app version两个标签就够了。还有一个细节容易被忽略Deployment的名字建议带上版本标识比如myapp-blue和myapp-green。这样在kubectl get pods看到的列表清晰明了不用每次费力猜测哪个Pod属于哪个版本。别小看这个习惯发布出问题的时候每一秒都在抢时间列表越清爽定位越快。2.3 对外流量入口的三种选择Service的selector决定了流量切给谁但外部流量怎么进集群是另一个需要提前想清楚的问题。根据集群的接入方式蓝绿切换的操作位置可能会略有不同。ClusterIP Ingress这是最常见的生产方案。Ingress把域名流量转到ServiceService再转到Pod。蓝绿切换只需要修改Service的selectorIngress完全不用动。这也是我认为最干净的方式——发布动作被收敛在“Service”这一个点上不管前面挂的是Ingress还是API网关都不需要感知。NodePort适合测试环境。改Service的selector依然生效但如果你直接通过节点IP:NodePort访问注意NodePort本身在切换过程中不会变化流量是被平滑转发的。LoadBalancer云负载均衡云平台提供的LB类型。这里有个重要细节如果业务已经通过LB的会话保持把请求绑定到了某个Pod IP那光改Service selector不一定能让存量会话感知到变化这个问题后面第4节会专门讲。提示生产环境我强烈建议走ClusterIP Ingress的方式把“对外暴露”和“发布切换”彻底解耦。这样你甚至可以在不改Ingress、不碰LB配置的前提下用一行命令完成蓝绿切换。3. 核心实战一次完整的蓝绿发布从切流量到回滚3.1 环境准备与初始状态我用一个模拟的Web API服务来演示镜像用Nginx替代业务上可以理解为返回版本号的服务。整个演示只需要一个Kubernetes集群Minikube或Kind都可以跑通。先看初始状态。当前线上运行的是“蓝”版本负责处理所有真实流量。apiVersion: apps/v1 kind: Deployment metadata: name: demo-app-blue labels: app: demo-app version: blue spec: replicas: 3 selector: matchLabels: app: demo-app version: blue template: metadata: labels: app: demo-app version: blue spec: containers: - name: app image: nginx:1.25 ports: - containerPort: 80对应Service的初始状态selector指向version: blue。apiVersion: v1 kind: Service metadata: name: demo-app-svc spec: selector: app: demo-app version: blue ports: - port: 80 targetPort: 80此时检查一下Pod和Endpoints确认流量确实都打在蓝色Pod上kubectl get pods -l versionblue kubectl get endpoints demo-app-svcEndpoints列表里应该能看到三个蓝色Pod的内网IP这是后面判断是否成功切换的直接依据。3.2 新版本以“绿”身份低调上线新版本代码准备完毕后创建 “绿” Deploymente镜像换用新版本标签同样遵循app: demo-appversion: green。apiVersion: apps/v1 kind: Deployment metadata: name: demo-app-green labels: app: demo-app version: green spec: replicas: 3 selector: matchLabels: app: demo-app version: green template: metadata: labels: app: demo-app version: green spec: containers: - name: app image: nginx:1.27 readinessProbe: httpGet: path: /healthz port: 80 initialDelaySeconds: 5 periodSeconds: 5 ports: - containerPort: 80这一步很关键绿版本上线后它不会接收任何线上流量因为Service的selector还只认version: blue。但绿版本Pod的健康状态、启动速度、日志输出都应该被仔细监控。给绿版本配置readinessProbe是一个我在实战中特别强调的点。readinessProbe决定了一个Pod是不是“就绪”也就是是否被Service纳入Endpoints。如果绿版本没有这个探针它可能一启动就被当成可用但实际上业务线程池还没初始化完成。到时候切换过去流量直接打到一个外强中干的服务上体验会非常糟糕。创建绿版本后验证kubectl get pods -l versiongreen kubectl get endpoints demo-app-svc此时Endpoints里应该仍然只有蓝色Pod的IP绿色Pod虽然处于Running状态但没有被Service选中。这一步验证通过说明蓝绿两套环境已经就绪且互不干扰。3.3 流量切换的三种姿势与操作细节等绿版本Pod全部进入Ready状态就可以执行切换了。有三种姿势我逐个说你根据团队习惯选一种。方式一kubectl patch 直接改selector最直接的方式一行命令完成切换kubectl patch service demo-app-svc -p {spec:{selector:{app:demo-app,version:green}}}这条命令把Service的selector从version: blue改成version: green。执行之后Service的Endpoints会逐渐从三个蓝色IP变成三个绿色IP。整个过程通常只需要几秒但极端情况下可能到几十秒取决于集群规模和控制面组件刷新速度。方式二编辑Service YAML并apply如果你倾向于把Service配置纳入GitOps管理可以修改Service的manifest文件然后applykubectl apply -f service.yaml前提是service.yaml里的selector已经改成了version: green。这种方式的好处是配置变更可追溯配合git提交信息你知道每一次切换是谁、在什么时候改了什么。相比patch它更符合生产环境的审计要求但也更慢一点适合发布窗口不那么紧的团队。方式三脚本封装一键切换把切换动作封装成Shell脚本适合需要频繁发布、或者值班同学不想记住长命令的团队。我做的一个简化版切换脚本逻辑switch(){ if [ $1 green ]; then kubectl patch service demo-app-svc -p \ {spec:{selector:{app:demo-app,version:green}}} elif [ $1 blue ]; then kubectl patch service demo-app-svc -p \ {spec:{selector:{app:demo-app,version:blue}}} else echo usage: switch [blue|green] fi }不管用哪种方式切换后第一件事就是检查Endpointskubectl get endpoints demo-app-svc如果看到Endpoint地址都换成了绿色Pod的IP说明流量已经切到位。注意先不要急着销毁蓝版本后面还要依赖它做回滚。3.4 验证、巡检与一键回滚流量切到绿版本后不要立刻宣布发布完成。正确的是先观察一段时间。我习惯在切换后的5分钟、15分钟、30分钟三个时间点做巡检错误率是否维持在切换前的基线水平接口P99延迟有没有明显劣化业务日志中是否有异常堆栈Pod的CPU、内存曲线是否在合理范围如果绿版本表现正常可以进入“稳定观察期”此时蓝版本先保留。观察期可以持续15分钟也可以持续几小时取决于业务形态。确认没问题后再清理蓝版本把资源释放出来。如果绿版本出了问题回滚就是再把开关拨回去kubectl patch service demo-app-svc -p {spec:{selector:{app:demo-app,version:blue}}}整个过程用户几乎无感因为Service的入口IP没有变只是后端Pod换了。这也是蓝绿发布最吸引人的地方回滚不是“修复”而是“切回另一个已经被验证过的环境”。等确认蓝版本已经稳定兜底后再下线绿版本kubectl delete deployment demo-app-green注意除非紧急到没时间思考否则不要在切换后立刻删除旧版本环境。蓝绿发布之所以安全是因为你手里永远握着“当前正在跑且已验证的版本”。一旦删掉蓝版本你就把保险绳解掉了。4. 我踩过的坑会话保持、连接池、配置漂移与排查速查表4.1 会话保持切流量之后用户掉登录第一次在带有用户态的Web应用上做蓝绿发布我遇到一个很尴尬的问题流量切换过去了但大量用户发现自己“被下线”需要重新登录。原因不复杂。蓝绿切换过程中Service后端的Pod整批换了而如果业务在Pod本地保存了Session用户在旧Pod上的登录态自然带不到新Pod。尤其是那些没有做Session共享、依赖Pod内存保存状态的单体应用切换到绿版本后所有Session都丢了。这个问题的本质不是蓝绿发布的问题而是应用状态分布的问题。解决方案有几个方向把Session存在外部存储比如Redis这样Pod无论怎么换Session还在。如果无法快速改造就在Service开启会话保持让同一用户的请求尽量打到同一个Pod。云LB也有对应的会话保持策略可以在LB层配置。发布前提前通知选择流量低峰期切换把掉线的影响降到最低。我后来在团队的发布检查清单里加了一条发布前必须确认Session是否有外部存储依赖。这个检查项看起来不起眼但它救过我们不止一次。4.2 长连接连接池不释放再说一个隐蔽的坑长连接。蓝绿切换后Service的Endpoints变了但已经建立的TCP长连接不会立刻断开。比如有些客户端用连接池保持了一堆到旧Pod的连接Service后端的Pod换了但客户端还是把请求打到旧Pod的IP上。这个问题的表现是明明Service已经指向绿版本了但旧Pod的QPS还在持续下降、迟迟归不了零连接一直悬挂着。排查思路是先看连接状态kubectl exec -it [旧Pod名称] -- netstat -an | grep ESTABLISHED | wc -l如果这个数字不降说明连接池没有主动断开。解决方向有两个。一是规范应用实现优雅停机在Pod被删除前通过preStop钩子调用应用的管理接口让进程主动关闭监听、等待存量请求处理完再退出。二是在Service层不依赖单个Pod IP做长连接把连接收敛到网关或LB层由它们统一管理后端连接。我在实际项目里还遇到过更极端的客户端是某个老旧的Java服务连接池的校验周期很长旧连接能存在半小时。后来我们的办法是在蓝绿切换前先让旧Pod的readinessProbe失效把旧Pod从Service的Endpoints里摘掉然后再慢慢排空连接。这相当于“先摘流量再切开关”比粗暴切换要平滑得多。4.3 配置版本漂移回滚回不去蓝绿发布有个隐形杀手叫“配置漂移”。新版本上线时团队往往同时更新了ConfigMap或环境变量比如调整了日志级别、改了某个开关。因为Service只负责切换Pod的标签选择它不关心Pod用了什么配置所以当蓝版本和新配置混在一起时问题就开始出现了。最典型的翻车现场是这样绿版本带上了新的配置和新的镜像跑得很好。这时你决定回滚到蓝版本。然后你发现蓝版本虽然镜像没变但Deployment的Pod模板已经因为某个发布流程被更新过挂载了新的ConfigMap启动后行为完全不是我想要的老样子。你以为你回滚了其实你滚回了一个“用新配置跑老代码”的混合体。应对策略是给ConfigMap和Secret做版本化命名。比如demo-app-config-v1、demo-app-config-v2Deployment通过明确的版本引用锁定配置。蓝绿两个Deployment各自绑定自己的配置版本不要共用同一个动态更新的ConfigMap对象。这样切换Pod就等于把代码和对应的配置一起切换回滚也一并回滚不会出现“代码回去了、配置没回去”的尴尬。4.4 常见问题排查速查表最后整理一个我在实战中沉淀的排查速查表。发布出问题时按表逐项排查能省下不少时间现象可能原因排查命令解决方案切换后Service没有更新Endpointsselector写错或Pod未Readykubectl get endpoints/kubectl describe svc检查标签键值是否完全匹配治理readinessProbe旧Pod连接迟迟不断长连接连接池未释放kubectl exec -it [旧Pod] -- netstat -an设置preStop优雅停机先摘流量再切lib用户Session丢失Session存于Pod本地检查应用Session存储位置改用Redis外部存储或低峰期发布回滚后服务错误率不降配置版本没跟代码一起回滚对比新旧Pod的环境变量和ConfigMapConfigMap版本化每个版本绑定独立配置绿版本启动就Ready但请求404readinessProbe未配置真实健康接口kubectl describe pod查看探针状态配置基于业务接口的readinessProbeService下出现蓝绿两个版本Podselector标签写得太宽kubectl get pods -l appdemo-app严格使用appversion双标签不要只按应用名选择还有一个很多人忽略的细节排查问题时多使用kubectl describe而不是只get。describe会显示事件的完整历史比如调度失败、探针失败、镜像拉取失败信息量比只看当前状态大得多。尤其在紧急排障时一句事件日志往往就指明了方向。我个人在实际操作中的体会是蓝绿发布不是一套单纯“照着配”的模板它更像是一种思维怎么让“上线”和“回滚”都变成一个低风险的切换动作而不是一次提心吊胆的重建。Kubernetes只是把它实现得比传统裸机时代简单太多。最后再分享一个落地的小建议——先拿一个低风险服务试跑几轮蓝绿发布等团队把整个流程跑顺了再逐步推广到核心链路。别第一次上蓝绿就用在最要命的系统上就像你不会第一次开车就上高速。