1. 蓝绿发布到底解决了什么问题搞运维和开发的兄弟应该都有过这种经历一个版本上线把全站用户给搭进去了。我印象很深的一次某电商项目改了订单状态的流转逻辑测试环境怎么验都没问题结果一上线线上订单全部卡在“支付成功待发货”的状态。当时还不是蓝绿发布用的滚动更新新版本的Pod一批一批地替换旧Pod等我们反应过来有问题的时候新代码已经扩散到一半的节点上了回滚都要等滚动完了才能继续操作。那半小时里用户每下一单就失败一单客服电话直接被打爆。事后复盘大家聊到一个问题如果当时有一整套老版本环境可以随时切回去结果会不会不一样答案其实是肯定的。这就是蓝绿发布最朴素的出发点——手里留一套能随时顶上来的老环境。蓝绿发布这个词最早是从什么场景火起来的我不确定但在Kubernetes这套体系里它已经成了很多团队上线必配的一套流程。网上讲蓝绿发布的文章不少但大部分只给你贴两个Deployment的YAML然后说“改一下Service的selector就切流量了”。听起来确实简单但真正在生产和预发环境里跑过一轮之后你会发现里面有大量坑连接池怎么平滑迁移、旧环境什么时候才能撤、验证流量怎么打、回滚的时候日志会不会乱掉、数据库兼容性怎么处理。这篇文章我不打算给你讲纯理论我按自己实操过的路径把蓝绿发布从原理到落地再到避坑完整拆一遍内容包括最关键的切换机制、资源编排、应用配置、流量验证和应急回滚。适合谁来读如果你是刚接触Kubernetes的初级运维看了能直接对着文中的配置在集群里搭出一套能用的蓝绿发布流程如果你已经在用滚动更新或者正在被灰度发布的复杂度搞得头疼这篇文章能帮你理清楚蓝绿这条路线为什么在某些场景下更合适。老实说蓝绿不是银弹但它确实是“快速回滚”这个目标下实现成本最低的一种方案。1.1 蓝绿发布的原理一个入口、两套环境蓝绿发布的核心逻辑用一句话讲就是同一时间存在两套完全独立的应用环境分别叫蓝色环境当前生产版本和绿色环境即将上线的新版本两套环境共享同一个服务入口通过入口的调度规则把真实流量全部切到蓝色或者绿色。这套逻辑放到Kubernetes里基础设施层面的表达非常干净——两套Deployment分别跑蓝色版本和绿色版本它们各自有独立的Pod和Label外面套一个Service利用Service的selector字段指向不同标签就能实现流量在蓝绿之间的切换。很多人第一次接触这个概念的时候会有一个疑惑为什么不用Ingress去切Ingress切的是域名路由可以很精细地做到按路径、按请求头分流但它更倾向于灰度发布和A/B测试。蓝绿发布要的是“整体切换、一步到位”切换的粒度应该是服务级而不是路由级。所以在Kubernetes里最契合蓝绿发布思路的流量控制点就是Service。Service这一层对Ingress来说是不透明的一个抽象它内部的selector无论指向哪一批PodIngress都不需要做任何变更域名和路由规则始终保持原来的样子。这种“后端悄悄换、前端毫无感知”的特性正是蓝绿发布最舒服的地方。再细分一点流量入口其实分两层。最外层是Ingress负责域名、TLS证书、路径转发规则这一层在整个发布期间基本不动内层是Service它通过selector选择后端Pod。蓝绿切换的本质动作就是修改Service的selector让它的流量从指向蓝色Deployment的Label变成指向绿色Deployment的Label。整个过程不涉及Pod重建连接断开后立即建立新的连接就能访问新版本。还有个很容易被忽略的点Service只做转发不做会话保持。如果应用有登录态或者会话数据切换后用户请求落在新版本Pod上Session如果存在本地内存里就直接丢了。这个问题不是蓝绿发布带来的是任何发布方式都绕不开的但蓝绿发布一瞬间切换的特性会让这个问题集中爆发。所以做蓝绿发布之前先想清楚应用状态是不是无状态的、会话是不是已经外置到Redis或者别的存储里了。如果这些没准备好蓝绿发布带来的不是平滑是灾难。1.2 为什么我最终选了蓝绿而不是滚动或灰度先说说滚动更新。Kubernetes默认的发布方式就是RollingUpdate新老Pod同时存在逐个替换。滚动更新的优点是资源占用少不需要额外准备一整套环境缺点是发布过程中新老版本会同时对外提供服务如果新旧版本之间不兼容比如数据库字段变更、API接口语义变化滚动期间就会出现一部分请求走新逻辑、一部分请求走老逻辑的割裂状态。更让人头疼的是回滚一旦发现问题你得等滚动更新把新版本全部替换完或者手动介入暂停然后反向再滚一轮。这个过程耗时很长期间服务一直处于异常状态。灰度发布则更加精细。它按流量比例分流比如先切5%的流量到新版本验证没问题再逐步扩大到10%、30%、50%、100%。灰度发布适合那种需要长时间观察、逐步放量的场景尤其适合用户量很大、一旦出事影响面就非常广的业务。但灰度发布的基础设施要求也高要么用Ingress的Annotation做流量权重要么引入Service Mesh比如服务网格要么在网关层做复杂的规则配置。自己做灰度发布规则写起来不复杂但监控、追踪、日志都需要按版本维度去拆对中小团队来说成本不低。蓝绿发布夹在中间。它比滚动更新“安全”因为线上始终有一套完整的、经过验证的版本在兜底它比灰度发布“简单”因为不需要按比例切流量、不需要维护复杂的规则所有的流量就是“整切”或者“不切”两个状态。蓝绿唯一的缺点是需要占用双倍的资源在流量高峰期间相当于你养了两套生产环境。但对大多数业务体量来说这个资源成本相比故障造成的损失完全值得。我的建议是交易链路、账务系统这类“绝对不能出大问题”的服务优先考虑蓝绿对外的新功能尝试、可容忍小范围异常的服务再考虑灰度。2. 动手前环境准备和资源规划怎么搞2.1 集群规模与组件选型先把环境说清楚。我这次实操用的集群是三台2核4G的工作节点Kubernetes版本1.24容器运行时是containerdIngress控制器用的是Ingress-Nginx版本1.8左右。这套配置没什么特别的门槛基本是中小团队的标配。如果你用的是托管的Kubernetes服务核心操作都是一样的只是Ingress的创建入口不一样。镜像仓库我用的私有Registry应用镜像打好tag之后直接push上去。这里有一个细节值得注意mirror tag区分度要高不要一直用latest因为蓝绿切换的时候你要从Service的selector上明确看出来现在指向的是哪个版本的Pod如果镜像tag都是latest光了看Pod的列表你根本分不清哪个是蓝哪个是绿。版本号强制规范一下比如v1.8.0和v1.9.0这种语义化版本号配置和Git提交记录也对得上排查问题的时候省很多事。还有一点蓝绿发布虽然是应用层的东西但它和集群的调度策略是联动的。如果你的节点只有一个两套环境会跑在同一台机器上发布期间两个版本的Pod同时存在CPU、内存都会有明显波动压力测试不充分的情况下可能出现想切流量但新版本还没Ready的情况。生产环境最好保证至少三个工作节点并且两套Deployment的Pod反亲和性策略避免调度到同一个节点上。下面是一段Pod反亲和性的配置示例affinity: podAntiAffinity: preferredDuringSchedulingIgnoredDuringExecution: - weight: 100 podAffinityTerm: labelSelector: matchLabels: app: my-app topologyKey: kubernetes.io/hostname这个配置的意思是尽量让同属一个应用的新旧版本Pod不落在同一台宿主机上。好处是如果新版本部署后出现了内存泄漏之类的问题不至于把集群里所有节点一次性拖垮。2.2 命名空间和资源隔离怎么设计蓝绿发布如果只在一个命名空间里搞省事但风险控制上不如单独建一个发布专用命名空间来得干净。我习惯的做法是给这个应用单独建一个命名空间比如叫app-production里面放这个应用所有相关的Deployment、Service、ConfigMap和Ingress。这样做的好处是你执行kubectl get all的时候看到的就是这个应用的全貌某个环境出了问题也不会误操作到别的应用。命名空间内部再按发布单元划分就更清晰了。比如这个订单服务它依赖数据库、Redis、消息队列那数据库和Redis这些中间件可以用独立的命名空间管理应用部署在这个命名空间里只关注自身的Deployment和Service。蓝绿发布真正要切换的只是应用这层中间件是不参与切换的如果中间件也参与蓝绿切换那就是另一个复杂度的故事了一般不建议在初期就这么设计。整体的拓扑关系是这样的一套命名空间跑两个Deployment蓝色和绿色各自带一组Pod然后一个共享的Service。这个Service的名字和应用名保持一致方便Ingress绑定。切换动作就是改Service的selectorIngress、域名、证书全都不用动。希望你把这个结构记清楚后面的实操字符串都是围绕这个拓扑展开的。3. 蓝绿发布的完整实操流程3.1 第一步部署蓝色环境当前生产版本模拟一个场景订单服务当前线上版本是v1.8.0跑在一个名叫my-app-blue的Deployment里。蓝色环境的标签配置我会非常刻意地设计因为它决定了之后切换和排查的准确性。先看YAMLapiVersion: apps/v1 kind: Deployment metadata: name: my-app-blue namespace: app-production spec: replicas: 3 selector: matchLabels: app: my-app track: blue template: metadata: labels: app: my-app track: blue version: v1.8.0 spec: containers: - name: app-container image: registry.internal/order-service:v1.8.0 ports: - containerPort: 8080 env: - name: APP_VERSION value: v1.8.0 - name: DB_DSN valueFrom: secretKeyRef: name: db-secret key: dsn readinessProbe: httpGet: path: /health port: 8080 initialDelaySeconds: 5 periodSeconds: 5 livenessProbe: httpGet: path: /health port: 8080 initialDelaySeconds: 10 periodSeconds: 10两个标签很关键track: blue和version: v1.8.0。track是发布环境的角色标识version是版本标识。在排查问题的时候我们通过track就能快速判断当前的流量指向在查看日志和监控的时候version能让你一眼看到当前Pod跑的是哪一版代码。这两个标签在后续的Service selector里都会用到。readinessProbe就绪探针不是可有可无的它是蓝绿切换节奏的纪律器。注意我配置的是/health接口这个接口最好不只是简单的“程序在运行”而应该包含关键依赖的健康状态比如数据库连接池是否可用、Redis是否连接成功。如果数据库挂了但探针依然返回200那Kubernetes会认为Pod是健康的流量切过去之后用户就直接面对错误页面。这个接口的意义在蓝绿发布里格外重要因为你是整体切换没有小流量验证的机会。应用本身的安全基线也别落下比如Pod里跑的用户不要用root加resources的requests和limits不然流量高峰的时候宿主机资源被撑爆了谁都不好受。这是我在生产环境踩过的坑新版本上线后内存占用比预估的多了不少要不是提前配置了limits整个节点都能被拖死。3.2 第二步部署绿色环境新版本现在把v1.9.0版本部署成绿色环境。YAML结构和蓝色基本一致差异只有三处Deployment的名字变成my-app-greentrack标签变成green镜像tag变成v1.9.0。别小看这三处差异Deployment名字如果搞成和蓝色一样Kubernetes会把旧的直接替换掉绿环境就起不来了。apiVersion: apps/v1 kind: Deployment metadata: name: my-app-green namespace: app-production spec: replicas: 3 selector: matchLabels: app: my-app track: green template: metadata: labels: app: my-app track: green version: v1.9.0 spec: containers: - name: app-container image: registry.internal/order-service:v1.9.0 ports: - containerPort: 8080 env: - name: APP_VERSION value: v1.9.0 - name: DB_DSN valueFrom: secretKeyRef: name: db-secret key: dsn readinessProbe: httpGet: path: /health port: 8080 initialDelaySeconds: 5 periodSeconds: 5 livenessProbe: httpGet: path: /health port: 8080 initialDelaySeconds: 10 periodSeconds: 10为什么是新环境先部署、用户无感知地跑起来而不是直接改流量这是因为部署本身是有风险的镜像可能拉取失败、配置可能不匹配、新版本可能启动就崩溃。如果直接改Service的selector等于把用户直接丢进一个还没有经过任何验证的环境里。正确的节奏是绿环境先独立启动Pod进入Running且Ready状态确认新版本能正常对外提供服务之后才进行流量切换。这个“先部署、后切换”的节奏是蓝绿发布的纪律核心。部署完之后别忘了看一眼Pod的运行状态。kubectl get pods -n app-production -l trackgreen如果看到Pod一直Pending或者CrashLoopBackOff先别急着切流量。可以进入到Pod里看启动日志或者直接kubectl logs 看有没有报错。这阶段排查问题的成本是最低的不需要回滚不需要恢复现场改完配置重新部署就行。3.3 第三步创建共享Service和Ingress两套Deployment都就绪之后创建一个共享的Service。这个Service的名字叫my-app-svcselector先指向蓝色环境因为当前生产流量还在蓝色那边。apiVersion: v1 kind: Service metadata: name: my-app-svc namespace: app-production spec: selector: app: my-app track: blue ports: - port: 80 targetPort: 8080先指向蓝色让业务先保持在线状态的稳定。接着创建IngressapiVersion: networking.k8s.io/v1 kind: Ingress metadata: name: my-app-ingress namespace: app-production spec: ingressClassName: nginx rules: - host: order.example.com http: paths: - path: / pathType: Prefix backend: service: name: my-app-svc port: number: 80Ingress配置里的backend是my-app-svc这个一直不用变。域名、TLS、路径规则都绑定在Service这一层上而Service的selector才是切换流量的开关。这里有个容易踩的坑如果创建Ingress的时候把Service名字误写成了my-app-blue那后续不管你怎么改Service的selector流量都不会切到绿色环境因为Ingress压根是直连蓝色Service。正确的做法是让Ingress永远指向那个共享的Service。这个阶段先验证一下访问order.example.com流量应该正常落在蓝色环境的Pod上。可以在蓝色环境某个Pod的日志里确认访问记录是存在的这能帮你确认整条链路通了。3.4 第四步一键切换流量万事俱备切流量。这个动作本质上就是修改Service的selector让track从blue变成green。执行命令kubectl patch svc my-app-svc -n app-production -p {spec:{selector:{app:my-app,track:green}}}或者用update方式kubectl edit svc my-app-svc -n app-production把selector里的track改成green保存退出即可。我一般推荐用patch命令因为可重复、可脚本化而edit方式要人工去改容易误操作。执行完之后看一眼Service关联的Endpointskubectl get endpoints my-app-svc -n app-production正常情况下ENDINGS列显示的Pod IP会从蓝环境3个Pod的IP变成绿环境3个Pod的IP。如果显示的还是蓝色环境的IP说明selector改错了或者绿色环境的Pod没有通过就绪探针。这一步检查一定要做它能第一时间发现问题。再看一下Pod的状态和日志kubectl get pods -n app-production -o wide kubectl logs -n app-production -l trackgreen --tail50如果绿色环境的Pod日志里出现了正常的访问记录说明流量已经成功切过来了。此时在用户侧访问order.example.com看到的就是新版本的页面和功能。注意这个切换是瞬间完成的Service的转发规则会立即更新到数据链路。但已存在的长连接不会立刻断掉已经建立好的TCP连接会继续走完生命周期。这个细节后面在问题排查部分我会详细展开这里你只要知道蓝绿切换不等于无缝切换就行了。3.5 第五步验证与稳定期管理流量切过去之后不是切换动作做完就完事了还有一段验证观察期。观察期的长短取决于你的业务性质。订单服务这种核心交易链路我一般至少观察15到30分钟期间要盯几个指标而不是单纯看页面能不能打开接口错误率是否在正常基线范围P99延迟是否有明显增加应用日志里有没有大量异常堆栈基础设施监控里看一眼CPU、内存、磁盘IO、网络带宽的变化趋势数据库慢查询是否增多依赖的下游服务有没有出现超时报错我习惯把所有这些集中到一个观察面板上。如果团队已经有了监控系统直接贴上应用的维度就行如果没有临时用命令行盯日志也要盯。发布期间人不离开终端这是最朴素但也最有效的办法。在观察期内如果应用出现任何不符合预期的情况直接执行回滚。回滚操作和切换一样简单把selector改回bluekubectl patch svc my-app-svc -n app-production -p {spec:{selector:{app:my-app,track:blue}}}这个操作能在几秒钟之内让流量全部回到原来的蓝色环境。蓝绿发布最大的价值就是这个回滚不是重新发布一版代码而是“切回去”成本极低。观察期确认没问题之后再把蓝色环境的副本数缩容到0或者直接删除蓝色Deployment释放资源。这一步一般放在第二天业务低峰期做因为万一切换后一个晚上出现了延迟性问题蓝色环境还在还能兜底。3.6 第六步回滚的完整路线回滚分几种情况处理方式不一样。第一种情况切换后几分钟内发现了明显问题比如接口大面积报错、用户反馈页面打不开。这种就果断切回去不用思考。执行的命令就是把selector的track改成blue然后观察蓝色环境的日志和延迟确认业务恢复了。此时绿色环境不要删除因为报错信息还要从绿色环境的日志里捞出来分析如果删了连现场都没了。第二种情况切换后过了几个小时甚至一天才发现问题比如某个批处理任务到了晚上才跑跑挂了。这时候流量已经全部打在绿色环境上你需要评估是修复新版本的问题然后再切回来还是直接回滚到蓝色环境。如果回滚需要把Service切回蓝色同时绿色环境暂时保留。等定位问题、修复完成后重新把绿色环境更新成修复后的版本再切。这种场景下蓝色环境实际上成了长期存在的“保护网”。第三种情况新版本和数据库之间有兼容性问题。比如新版本代码需要读取数据库里新增的某个字段但回滚到旧版本之后旧版本代码不认这个字段导致回滚后依然报错。这种问题在蓝绿发布里很经典它说明一个原则数据库变更和应用变更是不同步的。如果数据库结构的变更是一次性的、不可逆的那蓝绿发布的回滚能力就打折了。这个问题没有银弹只能尽量让数据库变更与应用代码向下兼容或者把数据库变更放在应用发布更早的时间点去执行给回滚留下容错空间。这也是很多团队在蓝绿发布流程规范里会专门写明的一条纪律数据库变更必须与应用发布解耦且变更要支持双向兼容。4. 我踩过的坑常见问题与排查实录4.1 切换瞬间大量报错长连接全断了第一次在业务高峰期做蓝绿切换的时候切完流量我这边监控面板直接飘红大量请求超时、连接重置、用户端不断重试。排查下来发现问题不在Service切换本身而在于应用没有处理好“优雅退出”。先说原理。滚动更新时新老Pod交替老Pod收到SIGTERM信号后会有一段graceful shutdown窗口默认是30秒让程序把存量请求处理完再退出期间新Pod已经Ready了流量会慢慢往新Pod上引导。但蓝绿切换时蓝色环境的Pod并没有收到任何终止信号它们是“被抛弃”的——Service的selector变了新的连接不再转发到蓝色Pod但已经建立的HTTP长连接、gRPC连接、数据库连接池连接还挂在蓝色Pod上。如果客户端是长连接型应用且没有重连机制这些连接会一直挂到超时用户侧表现就是请求一直转圈。解决这个问题有两个层面。第一应用自身要设置合理的HTTP keep-alive超时时间不要让连接无限期挂在一个Pod上第二网关层要有连接失效后的重试机制比如Nginx超时后重新发起请求到新的后端。如果是对外提供API的服务客户端SDK最好设置连接池探活和自动重建机制。这个方法得提前和运维、客户端开发的同事都对好否则切换的时候很容易翻车。另外一个隐含问题是假如蓝色环境的Pod上还挂着正在处理的数据库事务切流量后事务还没提交完这批请求会完成但下一次查询可能已经转到绿色环境而绿色环境和蓝色环境共享同一个数据库理论上数据是一致的但如果事务中途失败会产生死锁或数据不一致。这种问题排查起来非常痛苦建议逻辑复杂的服务增加一个“排空窗口”切换前先等待存量请求耗尽比如通过Ingress层面先停止转发、等30秒再切Service这一步能做但需要业务方配合评估。4.2 新旧版本Pod同时收到流量这个坑我遇到过两次排查过程比较曲折。现象是切换完成后蓝色和绿色环境的Pod日志里都有请求流量成了“一半一半”或者“随机分布”。第一次排查怀疑是Service的selector没有完全覆盖导致两个环境都被选中了。翻看Service的YAMLselector是app: my-app和track: green按理说只应该选中绿色Pod。后来发现蓝色Deployment的template里track标签虽然是blue但Pod上还有一个手工加的标签track: blue而且这个标签和Service里某个历史配置匹配上了。Kubernetes的Service选择器匹配逻辑是“所有标签都必须匹配”但历史遗留的Service定义有可能出现过没写track的情况导致蓝色Pod的app标签匹配就进了Endpoints。解决办法是严格梳理所有资源的标签一致性旧的、无用的标签一律删掉Service定义和Deployment模板里的标签保持完全一致。第二次是因为多Service共存。当时我的Ingress同时绑定了两个Service一个指向蓝色、一个指向绿色想实现灰度验证的效果但忘记在切换时把蓝色Service的权重改成0了。结果Ingress层面按轮询把流量分发到两个Service蓝绿两边都收到了请求。这个错误本质上是对蓝绿发布模式理解不透彻——蓝绿发布不是让你同时开两个入口而是只有一个入口、一个Service靠selector切。如果确实需要临时验证新版本功能更安全的做法是在绿色环境Deployment旁边临时起一个仅供测试的Service访问路径上加一个二级域名或者Header路由和正式流量完全隔离。验证完了再销毁这个临时Service。4.3 Pod已经Ready但流量还是不走它这个坑很有代表性。绿色环境Deployment部署完成kubectl get pods看到所有Pod状态都是Runningreadiness探针也过了selectors也没写错但切换之后流量还是全部打到了蓝色环境的Pod上绿色一个请求都没有。最终定位到问题出在Service的Endpoints上。Kubernetes在更新Service的selector后Endpoints的刷新不是“改一下就行”那种瞬间生效而是有一小段异步同步周期正常情况下是秒级。但如果绿色环境Pod数量多、Endpoint Controller处理不过来或者网络插件CNI没有及时同步节点上的转发规则就会出现几秒钟甚至几十秒的“切换前状态”。这个可以通过强制更新Endpoints来看kubectl get endpoints my-app-svc -n app-production kubectl describe endpoints my-app-svc -n app-production如果Endpoints已经更新成绿色IP但流量依然不走绿色那问题就出在kube-proxy和CNI的规则同步上。最简单的办法是重启一下相关节点的kube-proxy或者等它自动重新同步一般30秒内会恢复。遇到这种问题别慌蓝绿切换不是瞬时无感的给它一个合理的“排空窗口期”就好窗口期内可能有一小部分请求仍落到旧环境这属于正常现象最好是选择业务低峰期做切换。还有一个比较隐蔽的情况如果集群启用了会话亲和sessionAffinity切换后客户端IP会被哈希到固定的后端IP上一旦哈希到已不存在的旧Pod IP上请求就断了。蓝绿发布要默认关闭sessionAffinity除非你的应用已经做了外部会话存储否则不要开。4.4 ConfigMap与Secret跟着版本漂移应用跑起来了但配置还是旧的这个问题对蓝绿发布来说是致命伤。很多应用通过ConfigMap注入配置如果你只有一个ConfigMap名字叫my-app-config蓝绿两个Deployment都引用了同一个ConfigMap对象。这种情况下如果修改了ConfigMap的内容且更新了新版本代码来适配新配置但蓝色环境仍在跑旧代码它读取到新配置就会直接挂掉。Kubernetes的ConfigMap更新后Pod里挂载的文件不会立即生效默认有同步延迟kubelet默认每分钟同步一次而且有的应用只会在启动时读取一次配置。所以在蓝绿发布的场景里配置和代码应该同步版本化每个版本有自己独立的ConfigMap在Deployment的envFrom里引用版本对应的ConfigMap。比如v1.8.0引用my-app-config-v1-8-0v1.9.0引用my-app-config-v1-9-0。这样切换的时候代码和配置天然是一套的。另外一个容易被忽略的是Secret。数据库账号密码、第三方API密钥这些敏感信息如果只存在一个Secret蓝绿环境共同引用切换本身没问题但一旦新版本需要换一套密钥旧版本还在用新密钥可能直接导致旧的可用环境变成不可用回滚的兜底也就失效了。个人建议Secret也按环境隔离一个环境一套别混杂。4.5 双环境长期运行资源成本怎么控蓝绿发布的资源双倍问题是很多团队最终放弃它的主要原因尤其是没有预算买更多机器的中小企业。我的做法是给蓝绿两套环境设置不同的资源规格。蓝色环境因为是稳定兜底保持正常副本数和资源请求绿色环境部署的时候可以先把副本数压低到最小比如2个验证阶段通过后在切换流量之前再扩容到和蓝色环境相同的副本数。这样部署阶段资源占用小切换之后才真正承担全部流量。再者观察期结束、确认新版本稳定后蓝色环境可以直接缩容到1个副本甚至0个副本。如果业务有周期性的低峰期那么低峰期缩容蓝环境高峰期前重新拉起。这些操作可以通过Kubernetes的HPA水平自动扩缩容或者CronJob写脚本实现。不过不建议把这个自动化搞得太复杂蓝绿发布的核心价值是“可快速回滚”如果蓝环境长期缩容到0回滚就需要重新拉Pod、等Ready最快的效果也会大打折扣。一般建议至少保留1个副本随时待命。还有一个省钱思路非关键服务的蓝绿发布可以复用同一批节点的空闲资源只要节点的Requests总和没有超过节点容量就不会产生额外费用。Kubernetes调度器按Requests来分配资源你的BlueGreen同时跑在一台4核的虚拟机上只要总Requests低于4核就都能跑。当然Pod实际使用的CPU可能超过Requests所以生产环境还是要有监控兜底别超卖得太狠。5. 把蓝绿发布自动化形成可复用的发布管线5.1 一键发布脚本设计手动操作做一两次可以但每次发布都要敲一堆kubectl命令存在两个问题一是容易出错二是没法留痕。所以我把整个流程封装成了一个发布脚本核心逻辑就是几个阶段函数。脚本的大致结构是这样的#!/bin/bash set -euo pipefail NAMESPACEapp-production APP_NAMEmy-app NEW_VERSION${1:-v1.9.0} OLD_VERSION${2:-v1.8.0} pre_deploy() { echo 部署新版本绿色环境 kubectl apply -f green-deployment-${NEW_VERSION}.yaml kubectl rollout status deployment/my-app-green -n ${NAMESPACE} --timeout180s } switch_traffic() { echo 切换流量到绿色环境 kubectl patch svc ${APP_NAME}-svc -n ${NAMESPACE} \ -p {\spec\:{\selector\:{\app\:\${APP_NAME}\,\track\:\green\}}} echo 等待 Endpoints 更新 sleep 5 kubectl get endpoints ${APP_NAME}-svc -n ${NAMESPACE} } rollback() { echo 回滚到蓝色环境 kubectl patch svc ${APP_NAME}-svc -n ${NAMESPACE} \ -p {\spec\:{\selector\:{\app\:\${APP_NAME}\,\track\:\blue\}}} } case ${1:-} in pre) pre_deploy ;; switch) switch_traffic ;; rollback) rollback ;; *) echo 用法: $0 {pre|switch|rollback} ;; esac这套脚本的指导思想是“一个动作、一条命令、一秒钟切回”。pre阶段只部署新环境不影响线上流量switch阶段才真正把用户流量切到新环境rollback阶段一键回到旧环境。每个阶段都有明确的输出日志里会记录发布操作的时间戳和执行的patch命令发布完还能把输出归档成文件作为审计凭据。脚本里有一个细节值得注意switch之后sleep 5秒让Endpoint Controller有时间更新Pod列表。这个等待时间不是随便定的它取决于你的集群规模小集群几秒即可大集群可能得10秒以上。等Endpoints确认更新完毕再继续后续操作。如果你在切换后立刻做压力测试可能测到的是还没切换完成的中间状态容易误判。5.2 与CI/CD流水线集成发布脚本只是最底层的手动操作真正顺畅的用法是接进CI/CD流水线。以常见的GitLab CI或者GitHub Actions为例阶段划分大概是构建阶段代码合并到主干后自动构建镜像打上版本号tag并推送到镜像仓库预发布阶段调用pre_deploy部署绿色环境但此时流量还在蓝色验证阶段跑自动化冒烟测试执行关键业务链路的用例登录、下单、支付、查询还可以用爬虫打一个小流量到绿色环境的临时Service上切换阶段人工确认或自动执行switch_traffic稳定观察阶段持续15-30分钟后监控指标没有异常再往下走清理阶段缩容蓝色环境每一步的准入条件一定要卡死。比如切换到绿色环境之前自动化测试必须全部通过冒烟测试覆盖率不能低于某个阈值不然任何人都能跳过验证直接发布。这套流程跑顺之后发布这个动作就从“高危操作”变成了“例行操作”开发测试同学都能执行运维只需要在处理异常情况的时候介入。5.3 蓝绿发布的进阶玩法与灰度结合讲到这里有人会问蓝绿和灰度只能二选一吗其实可以结合。比如电商大促前核心交易链路适合蓝绿发布确保整体稳定但预言一个新功能的时候更适合灰度发布看用户反馈再放量。可以在同一套基础设施里给核心服务配置蓝绿发布给非核心服务配置Ingress的canary规则做灰度这样既保证了核心链路的稳定性又保留了产品验证的灵活性。还有一种组合是“金丝雀蓝绿”做法是绿色环境部署好但先不切全量在Ingress层加一条临时规则把内部测试人员的IP段或者某个Header比如X-Canary: true转发到绿色环境其他流量继续走蓝色。这种方式本质上是用灰度发布的方式验证蓝绿环境验证通过后再整切。很多团队愿意用这个方式因为它既保留了蓝绿的大规模回滚能力又解决了蓝绿完全按全量发布缺少“最后一公里”验证的问题。实现方式很简单在Ingress上多加一条path规则优先级高于现有规则指定特定Header的请求转发到绿色环境对应的一个临时Service。这条规则用完之后删除即可。这套玩法基础设施成本不增加多少但运维操作的复杂度确实上来了所以建议团队磨合稳定了再上。6. 写在最后我的几点体会蓝绿发布做久了你会发现它本质上不是技术问题而是管理和决策问题。技术层面的切换和回滚都很快难的是你团队有没有底气在发现问题的那一刻果断按回滚键。很多人切换完成后看着监控曲线不对劲第一反应是再等等看会不会恢复——这个“等等看”的窗口期往往就是故障扩大化的根源。我的做法是事先写清楚切换后哪些指标属于“立即回滚红线”比如错误率超过1%、P99延迟翻倍、数据库慢查询明显上升只要触发红线不做任何犹豫直接回滚。这样整个团队有章法可循发布负责人不需要临场做情绪化决策。另外蓝绿发布并不适合所有服务。如果公司初创期服务才刚刚上线两周用户量极少直接改代码重启就行蓝绿这套流程反而是负担。它的价值在服务发展稳定、上线风险成本大于资源成本之后才凸显出来。这个判断标准建议作为决策的起点而不是别人用你也用。最后分享一个小技巧发布过程中把操作命令的输出去重定向到文件里保存甚至可以每天发一次定时任务把当前Service的selector状态输出成报告存档。这样一旦出问题回溯是谁在什么时间点改了哪些配置清清楚楚扯皮的时候也有了事实依据。希望这篇实战经验能帮到那些正准备引入蓝绿发布或者已经在蓝绿发布里折腾得焦头烂额的同行。
