1. 发布策略这件事为什么值得单独写一篇先说个大多数 K8s 新手都会踩的坑把应用塞进集群能跑起来就觉得发布这件事结束了。结果第一次上线新版本要么服务断了几十秒要么流量直接打到旧 Pod 上要么配置改错一个缩进导致整个 Deployment 回滚失败——这些我都经历过。K8s 里的发布本质上回答三个问题新版本怎么上去、旧版本怎么下来、流量怎么切换。这三个问题处理不好前面容器化做得再漂亮上线那一刻也会翻车。这篇文章是我在实际项目里反复折腾后的笔记覆盖三种最常见的发布策略滚动更新RollingUpdate、蓝绿发布Blue/Green、金丝雀发布Canary配套完整的 YAML 配置和踩坑记录。适合正在学习 K8s 的运维、后端开发以及准备在生产环境做发布方案选型但还没想清楚差异的人。先给一个结论没有哪种策略是万能药。滚动更新省资源但不好控制爆炸半径蓝绿切换干净但费钱金丝雀最稳但对监控和流量治理有要求。后面我会逐个拆原理、贴配置、讲参数最后把三种策略的对比表放出来。2. 滚动更新默认策略背后的原理与配置陷阱2.1 滚动更新的工作方式不是先删光再创建滚动更新是 Deployment 默认的发布策略也是大多数人最早接触的。它的核心逻辑是逐个替换旧版本 Pod保持服务始终可用。听起来简单但逐个这两个字背后有一套完整的控制器逻辑。当你执行kubectl set image deployment/my-app my-appmy-image:v2或者kubectl apply -f deployment-v2.yaml时Deployment 控制器会创建一个新的 ReplicaSet然后按照你设定的maxSurge和maxUnavailable参数控制新旧 ReplicaSet 的 Pod 数量变化。默认情况下maxSurge25%、maxUnavailable25%。什么意思假设你运行 4 个副本发布时系统会先把旧 Pod 干掉 1 个再创建 1 个新 Pod始终保持可用 Pod 数量不低于 3 个。整个过程像排队换人不是一次性推倒重来。但这个默认值有个隐患如果 Pod 启动需要 2 分钟而 Readiness 探针没配好新 Pod 永远进不了 Service 的 Endpoints发布就会卡住。更糟的情况是新版本启动即崩溃Readiness 探针一直失败ReplicaSet 会不断重建 Pod形成 CrashLoopBackOff 循环。2.2 完整 YAML 配置从探针到策略参数下面是一份我在测试环境验证过的 Deployment YAML重点不在业务镜像而在发布相关的配置项。apiVersion: apps/v1 kind: Deployment metadata: name: order-service namespace: production labels: app: order-service spec: replicas: 4 revisionHistoryLimit: 10 strategy: type: RollingUpdate rollingUpdate: maxSurge: 1 # 允许最多超出期望副本数 1 个 maxUnavailable: 0 # 不允许出现不可用 Pod selector: matchLabels: app: order-service template: metadata: labels: app: order-service spec: containers: - name: order-service image: registry.internal/order-service:v2.3.1 ports: - containerPort: 8080 readinessProbe: httpGet: path: /actuator/health/readiness port: 8080 initialDelaySeconds: 10 periodSeconds: 5 timeoutSeconds: 3 failureThreshold: 3 livenessProbe: httpGet: path: /actuator/health/liveness port: 8080 initialDelaySeconds: 30 periodSeconds: 10 timeoutSeconds: 5 failureThreshold: 3 resources: requests: cpu: 500m memory: 512Mi limits: cpu: 1 memory: 1Gi这里maxSurge: 1和maxUnavailable: 0的组合是我最常用的配置。原因很简单先多起一个新 Pod等它 Ready 了再停一个旧 Pod。整个过程中可用 Pod 数量始终大于等于期望值对于追求稳定性的业务来说这是最平滑的滚动方式。如果你的集群资源紧张可以考虑maxSurge: 0、maxUnavailable: 1先停一个旧的再起新的但这样每个 Pod 替换周期内可用容量会短暂下降流量高峰期可能扛不住。2.3 回滚操作别等到出事了才学滚动更新的好处之一是回滚方便。执行kubectl rollout undo deployment/order-service就能回到上一个版本。但有两个细节值得注意revisionHistoryLimit默认是 10意味着最多保留 10 个历史版本超过的会被清理。如果你需要回滚到很久以前的版本这个参数要调大。回滚操作本身也会触发一次滚动更新同样受maxSurge和maxUnavailable约束。我用kubectl rollout status deployment/order-service --timeout120s来等待发布完成超时则认为发布异常。如果要看发布过程有没有出问题kubectl describe deployment里能看到 ReplicaSet 的变更事件。2.4 滚动更新最常见的三个坑第一个坑是没配 Readiness 探针。新 Pod 只要容器启动了就会被加入 Endpoints流量进来直接 502。很多新手刚学 K8s 时只写了 livenessProbe觉得能检测进程活着就行实际上 Readiness 才是决定流量是否流入的关键。第二个坑是镜像 tag 用 latest。每次发布时如果 YAML 里写的还是latestK8s 默认拉取策略是IfNotPresent节点上已有同 tag 镜像就不会重新拉发布等于没发。要么改用具体版本号要么设置imagePullPolicy: Always。第三个坑是发布期间监控缺失。滚动更新过程中新旧 Pod 同时存在如果日志告警只追踪 Pod 名称会看到大量异常日志来自正在销毁的旧 Pod。建议按版本号或 Deployment 维度聚合日志别自己吓自己。3. 蓝绿发布流量切换的那一瞬间到底发生了什么3.1 为什么需要蓝绿把发布变成切换滚动更新的问题在于新旧版本是混在一起的。如果新版本有 bug影响范围可能是部分流量排查时还要区分百分比。而蓝绿发布的核心思路很简单——同时运行两套完整环境蓝色旧版本、绿色新版本发布时把所有流量一次性切到绿色环境。好处很明显如果新版本有问题切回蓝色环境即可几乎是秒级完成。而且蓝绿发布可以在切换前对新版本做充分的验证比如真实流量测试、数据迁移验证等。代价同样明显需要双倍的资源。两个版本同时在线意味着 CPU、内存、网络等资源消耗翻倍。所以蓝绿发布通常用在资源充裕、业务对稳定性要求极高的场景比如核心交易链路。3.2 基于 Service 的蓝绿实现最简单的方式蓝绿发布在 K8s 里最简单的实现方式是基于 Service 的标签选择器切换。先创建蓝色 Deployment 和 Service服务正常对外。绿色 Deployment 创建好之后通过修改 Service 的 selector 指向绿色版本。这里有个细节两个 Deployment 的服务名需要一致否则 Service 的选择器根本没法定向。我用两个 YAML 文件来管理# blue-deployment.yaml apiVersion: apps/v1 kind: Deployment metadata: name: order-service-blue namespace: production labels: app: order-service version: blue spec: replicas: 4 selector: matchLabels: app: order-service version: blue template: metadata: labels: app: order-service version: blue spec: containers: - name: order-service image: registry.internal/order-service:v2.2.0 ports: - containerPort: 8080# green-deployment.yaml apiVersion: apps/v1 metadata: name: order-service-green namespace: production labels: app: order-service version: green spec: replicas: 4 selector: matchLabels: app: order-service version: green template: metadata: labels: app: order-service version: green spec: containers: - name: order-service image: registry.internal/order-service:v2.3.1Service 的配置如下apiVersion: v1 kind: Service metadata: name: order-service namespace: production spec: selector: app: order-service version: blue # 切换时改成 green 即可 ports: - port: 8080 targetPort: 8080切换执行一条命令kubectl patch service order-service -n production -p {spec:{selector:{version:green}}}但这条路有个隐藏问题Service 的 selector 修改是异步生效的K8s 的 Endpoints 控制器需要一点时间更新 Endpoints 列表。流量切换过程中可能有极少数请求仍然打到蓝色 Pod 上。对于普通业务这个窗口期可以接受但对于强一致场景需要更精细的流量治理方案。3.3 结合 Ingress 的蓝绿发布更可控的切换方式如果不想修改底层 Service 的 selector另一种做法是通过 Ingress 路径或 Header 做流量分发。比如同一个域名下的/blue路径路由到蓝色 Service/green路径路由到绿色 Service验证完再把默认路由改到绿色。这种方式的好处是可以拿真实流量做小范围验证而不是一刀切。坏处是业务代码里如果带了上下文路径可能遇到路径冲突。我自己的经验是如果 Ingress 层已经接了网关直接用网关的灰度能力更顺手K8s 侧的 Service 只负责简单的负载均衡。3.4 蓝绿发布的资源隔离与数据兼容问题聊蓝绿发布不能回避两个现实问题资源隔离蓝绿两套环境通常需要不同的 ConfigMap、Secret甚至数据库账号。如果你有大对象存储、缓存等中间件需要确认新版本是否兼容旧数据结构。否则切到绿色版本之后业务可能读写异常。数据兼容如果发版涉及数据库 schema 变更蓝绿发布需要保证旧版本依然兼容新数据格式。因为流量切到绿色之后蓝色环境还活着虽然没流量如果写操作已经产生了新格式数据回滚到蓝色环境会出问题。我在一次订单服务的发版中就遇到过新版本往数据库里写入了一个新字段回滚后发现旧代码解析不了该字段导致部分接口报错。从那以后凡是涉及数据库变更的版本我都要求开发提前评估兼容性而不是只关注代码逻辑。4. 金丝雀发布把风险控制到 1%需要哪些配置配合4.1 金丝雀的本质真实流量下的渐进式验证金丝雀发布的思路来自煤矿里的金丝雀——先放一只鸟进去如果它死了说明有毒气人就不用进去了。在 K8s 里就是先让一小部分流量比如 1% 或 5%打到新版本上验证没问题再逐步扩大流量比例。和蓝绿发布一次性全切相比金丝雀的优势在于影响面始终可控。如果新版本有问题最多影响 1% 的用户而且可以随时把流量全部切回旧版本。但金丝雀发布对基础设施的要求也最高需要支持按权重或按请求特征进行流量分发。K8s 原生的 Service 只支持轮询转发不支持按百分比路由。所以金丝雀发布通常需要借助额外工具。4.2 原生 K8s 的简易金丝雀手动缩容扩容不上任何额外组件的情况下最土但也有效的金丝雀做法是手动控制新旧版本的副本数比例。比如总容量 10 个副本先起 1 个新版本 Pod、保留 9 个旧版本 Pod让 10% 的流量打到新版本上验证没问题后再逐步调整比例。具体操作就是修改两个 Deployment 的replicas数每调整一次执行一次kubectl apply。但这种方式有几个明显问题如果流量峰值变化手动扩缩容反应不够快不同 Pod 的数量比例不等于实际流量比例因为连接数不一定均匀操作繁琐容易出错简单场景下能用线上环境不建议。我见过有团队用脚本封装这套手动流程配合 Prometheus 监控做自动化扩缩容但复杂度和维护成本并不低。4.3 Istio 场景下的金丝雀VirtualService DestinationRule如果集群已经接了 Service Mesh比如 Istio金丝雀发布的体验会好很多。这里给出我常用的配置# destinationrule.yaml apiVersion: networking.istio.io/v1beta1 kind: DestinationRule metadata: name: order-service-dr namespace: production spec: host: order-service subsets: - name: v1 labels: version: v1 - name: v2 labels: version: v2# virtualservice.yaml apiVersion: networking.istio.io/v1beta1 kind: VirtualService metadata: name: order-service-vs namespace: production spec: hosts: - order-service http: - route: - destination: host: order-service subset: v1 weight: 95 - destination: host: order-service subset: v2 weight: 5此时所有进入order-service的流量按照 95:5 的比例分布到 v1 和 v2。验证没问题后把 weight 改成 50:50、10:90、最终 0:100完成全量切换。如果只想让特定用户先体验新版本可以加headers匹配- match: - headers: end-user: exact: tester001 route: - destination: host: order-service subset: v2 weight: 1004.4 金丝雀发布必须搭配的四大监控指标金丝雀发布的价值取决于你能不能快速地判断新版本是否健康。如果监控指标不完善金丝雀发布等于盲目赌博。我每次做金丝雀发布至少盯住以下四类指标指标类型常见指标判断标准业务指标QPS、成功率、订单量新版本与旧版本差距在 5% 以内性能指标P95/P99 延迟新版本延迟不低于旧版本 10%系统指标CPU、内存、GC 耗时没有持续上涨趋势错误指标5xx 数量、异常堆栈无新增异常类型如果在金丝雀阶段发现错误率上升第一时间把VirtualService里新版本的weight改为 0然后慢慢查问题。这个回滚动作只要一条命令几秒钟生效。4.5 金丝雀和自动化发布平台的配合最后的提醒金丝雀发布最好不要靠手动改 weight。一旦版本多、集群多、环境多手动操作大概率会出错。推荐用 Argo Rollouts 或者 Flagger 这类工具把发布流程编排成 Pipeline。它们可以结合 Prometheus 指标自动判断金丝雀是否健康健康则继续扩容不健康则自动回滚。Argo Rollouts 的配置核心是Rollout资源一个最小的金丝雀配置如下apiVersion: argoproj.io/v1alpha1 kind: Rollout metadata: name: order-service-rollout namespace: production spec: replicas: 10 strategy: canary: steps: - setWeight: 10 - pause: { duration: 5m } - setWeight: 50 - pause: { duration: 10m } - setWeight: 100 selector: matchLabels: app: order-service template: metadata: labels: app: order-service spec: containers: - name: order-service image: registry.internal/order-service:v2.3.1这套配置表达的意思是先让 10% 流量过去保持 5 分钟观察没问题再放 50%保持 10 分钟最后全量。中间任何一步监控报警Argo Rollouts 会自动回滚不需要人工干预。我在多个生产集群里都这么用稳定性显著提升。5. 三种发布策略如何选我给了一个可以直接抄的决策表看到这里你可能已经能感觉到三种策略的差异了。但在实际项目中很多人还是会纠结到底该用哪种。这里我把自己做选型的思路整理成表格方便对比维度滚动更新蓝绿发布金丝雀发布资源成本低不需要额外副本高双倍环境同时运行中需要额外副本但可按比例控制发布速度中受滚动窗口影响快切换即完成慢需要多阶段观察回滚速度中需要再次滚动快切换 Service 指针即可快调整 weight 即可风险控制弱新旧混跑难定位中切换瞬间可能有极小窗口强影响面按比例可控部署复杂度低K8s 原生能力中需要维护两套 Deployment高需要额外网关或 Mesh适用场景资源紧张、变更频率高、快速迭代核心链路、发版频率低、必须秒回滚用户量大的线上环境、风险敏感型业务我的个人建议是测试环境用滚动更新。省事、省资源反正测试环境挂了可以马上重建。生产环境如果还没有 Service Mesh优先用滚动更新 严格的 Readiness 探针。这是 K8s 默认能力不需要额外组件只要把探针和监控做扎实大多数场景足够稳。生产环境如果有重要发版涉及数据库变更、核心接口变更且团队能hold住双倍资源配置就做蓝绿发布。切换前在绿色环境做一轮完整的接口回归测试切换后持续观察 30 分钟再回收蓝色环境。如果用户量大、业务对稳定性极度敏感而且集群基础设施完善Istio 或 Argo Rollouts就上金丝雀发布。这是长期成本最低、风险最可控的方案。还有一个很多文章不会提的细节——三种策略可以组合使用。比如先金丝雀验证 10% 流量没问题后直接切蓝绿完成最终切换或者滚动更新作为兜底方案当金丝雀工具挂掉时能手动完成回滚。6. YAML 配置里的常见错误我踩过的都给你列出来6.1 缩进错误K8s YAML 的玄学YAML 的缩进错误是新手最头疼的问题。K8s 对缩进极其敏感多一个空格、少一个空格直接报错。我踩过最隐蔽的一个坑是spec和template的层级搞混结果应用 Deployment 的时候replicas字段直接被忽略Pod 数量一直不对。这里分享一个排查技巧写好的 YAML 先执行kubectl apply --dry-runclient -f xxx.yaml做语法校验再执行kubectl apply --dry-runserver -f xxx.yaml做服务端校验。两步都通过之后再真正执行kubectl apply。另外强烈建议在本地编辑器里装上 YAML 插件比如 VS Code 的 YAML 扩展配合 Kubernetes 的 schema 自动补全可以避免大部分拼写和层级错误。6.2 字段拼写错误K8s 不会帮你纠正YAML 语法校验通过不代表字段拼写正确。比如readinessProbe拼成readinessprobK8s 会把这个字段当作未知字段忽略掉——不对实际上 K8s 的 API 校验对这种拼写错误是会直接拒绝的。真正隐蔽的是大小写错误initialDelaySeconds拼成InitialDelaySeconds或者initialdelayseconds这种也能通过部分校验但行为不符合预期。我的习惯是任何 YAML 写完之后先kubectl explain deployment.spec.template.spec.containers.readinessProbe查一下字段定义确保每个字段的拼写和层级都正确。6.3 镜像拉取策略一个 deep 到让人想哭的问题前面提到过latesttag 的问题这里再展开说。即使你用了具体版本号imagePullPolicy的行为也会影响发布如果是未指定 tag 以外的合法版本号比如v2.3.1默认策略是IfNotPresent。节点上已经有这个镜像就本地用不重新拉取。如果你改动了镜像内容但 tag 没变比如覆盖推送节点上不会拉新镜像。这种改了镜像但没发出去的问题排查起来非常隐蔽。我的建议是发布相关 YAML 的imagePullPolicy显式设置为Always虽然会多花一点点拉取时间但能避免大量查不出来原因的旧版本运行问题。6.4 资源 requests 和 limits不配必踩的坑还有很多人不配resources或者随便填一填。如果不配requests调度器会认为 Pod 不占资源节点可能超卖严重如果不配limitsPod 可能吃掉节点所有内存。我之前有个 Java 服务默认堆内存 1GBlimits 只给了 512Mi结果 Pod 频繁 OOMKilled。后来把堆配置调小limits 给到合适的值才稳定。配置resources的过程实际上是在逼你了解业务进程的资源画像这一步省不了。6.5 探针配置的几个黄金参数参考最后给一套我常用的探针配置模板可以直接抄readinessProbe: httpGet: path: /actuator/health/readiness port: 8080 initialDelaySeconds: 15 # 容器启动后等待 15 秒才开始探测 periodSeconds: 10 # 每 10 秒探测一次 timeoutSeconds: 3 # 探测请求超时时间 failureThreshold: 3 # 连续 3 次失败判定为不健康 successThreshold: 1 # 1 次成功判定为健康initialDelaySeconds的值取决于应用启动时间。启动慢的应用如果设置太短探针会频繁失败导致 Pod 一直重启如果设置太长发布效率就低。先看日志确认从进程启动到端口可以接受请求的时间再决定这个值不要拍脑袋填。7. 发布之后的验证别急着下班先看完这些7.1 发布成功不等于发布正确很多人看到kubectl rollout status返回成功就觉得万事大吉。但 rollout 成功只代表Pod 层面符合预期不代表业务真的正常。我见过最典型的案例新版本启动成功、Readiness 探针也通过了但是因为配置中心里的某个开关没打开导致新版本接口逻辑错误所有请求返回异常数据。这时候 rollout 是成功的但业务是失败的。所以发布完成后我至少会做三件事检查 Pod 日志看有没有 ERROR 级别的异常输出用测试脚本打几个关键接口验证核心链路正常观察监控面板看 QPS、错误率、延迟曲线是否有异常波动7.2 回滚的触发条件滚动更新的回滚条件比较直观只要 P95 延迟比发布前高出 20% 以上或者错误率连续 5 分钟超过 1%我就执行回滚。这个阈值可以按业务调整但一定要提前约定好不要等出了问题再开会讨论。蓝绿发布的回滚条件更简单切换后 30 分钟内出现任何线上问题直接切回蓝色环境。因为绿色环境已经经过验证大概率不会有大问题如果出现问题多半是数据兼容或灰度环境特有的函数开关等此时先恢复蓝色环境才是最稳的做法。金丝雀发布的回滚条件更灵活每一步暂停期间如果监控指标达标就继续放量如果不达标自动把 weight 调整回 0。这个过程建议完全交给 Argo Rollouts 或 Flagger 来做人工介入反而慢。7.3 发布记录你需要的不是 Memory而是文档最后想提醒一个非技术但同样重要的问题给每一次发布写记录。包括版本号、镜像 tag、主要变更、回滚原因、发布耗时、发布过程中出现的异常。K8s 的rollout history只能看到版本记录看不到变更内容所以团队内部最好有一套发布记录模板。我自己的习惯是每次发完版在 Wiki 或团队协作空间里留下一段文字这次发了什么、为什么发、采用的什么策略、有没有出现意外、下次要注意什么。几个月后再翻这些记录能少踩好多重复的坑。8. 我在实战中的几条补充经验第一滚动更新别只看配置还要看调度器。如果节点资源碎片化严重maxSurge可能长时间无法创建新 Pod。遇到这种情况我通常直接把maxSurge设为25%或1整数和百分比语义不同先用小数百分比容易触发舍入问题。第二蓝绿发布的 Service 切换别忽略 DNS 缓存。虽然在 K8s 集群内部Service 的 Endpoints 变化是即时的但客户端比如某些 Java 服务可能缓存 DNS 解析结果。如果客户端依赖每个域名解析到固定的 ClusterIP切换后可能还有一批连接打到旧的 ClusterIP 上。解决方案是确保客户端连接的 Service 是稳定的 ClusterIP而不是直接解析到 Pod IP。第三金丝雀发布的流量比例不等于副本比例。很多人以为 10% 流量就得配 10% 的副本数实际上副本比例只是影响流量的一个因素最终流量比例由负载均衡算法和连接分布决定。我建议在 Istio 的场景里直接依赖 VirtualService 的 weight 控制不要用副本数来估算流量比例否则很可能出现新版本实际承载了 20% 流量的情况。第四发布策略要和配置管理联动。无论哪种发布策略如果 ConfigMap 或 Secret 发生了变更K8s 不会自动重启 Pod。如果你的应用没有监听配置变更并热加载发布时要记得把配置版本和镜像版本绑定否则可能出现新旧配置混跑的情况。第五多环境发布策略不必完全一致。测试环境、预发环境、生产环境的要求不同策略可以不同。比如测试环境用滚动更新预发环境用金丝雀全量切换生产环境用蓝绿。不要觉得统一配置更规范实际上按场景差异化配置才是进阶做法。我自己的项目里目前的生产发布流程是先用 Argo Rollouts 做金丝雀自动发布配置 10% - 暂停 5 分钟 - 50% - 暂停 10 分钟 - 100%。整个过程由监控指标驱动不需要人工盯得太紧。如果遇到紧急修复hotfix我会降级为滚动更新以速度优先。这套组合拳跑了大半年稳定性提升非常明显。希望你也能找到适合自己团队的发布套路。