Kubernetes(K8s)中的蓝绿部署与滚动更新

在Kubernetes集群中实施蓝绿部署和滚动更新时，遇到几个具体问题想请教：

  1. 实际生产环境中，蓝绿部署需要维护两套完全相同的资源，这对集群资源消耗较大，有没有优化方案能减少资源冗余？
  2. 滚动更新通过逐步替换Pod实现无宕机，但当新版本出现问题时，除了回滚操作外，有没有更细粒度的流量控制方法？
  3. 两种部署方式在CI/CD流水线中的集成差异：比如Jenkins Pipeline脚本的写法会有哪些关键区别？
  4. 服务网格（如Istio）能否同时兼容这两种部署模式？会不会出现路由规则冲突？
  5. 在混合云场景下，跨集群的蓝绿切换有哪些需要特别注意的 network policy配置？
3 回复

蓝绿部署和滚动更新都是K8s中常用的发布策略。

蓝绿部署是将系统分为两套环境：蓝环境（当前生产环境）和绿环境（新版本准备环境）。发布时，先在绿环境中部署新版本，测试无误后，切换流量到绿环境。这种方法可以实现零停机，且回滚迅速（只需切换回蓝环境）。

滚动更新则是逐步替换旧版本实例为新版本实例。比如，一个副本集有5个Pod，滚动更新时先升级2个，验证正常后再升级剩余的。这种方式资源利用率高，但需要确保每个新Pod都能正常工作，否则可能导致服务中断。

两者各有优劣：蓝绿部署适合对稳定性要求极高的场景，而滚动更新更适合持续集成/持续交付(CI/CD)流程中快速迭代的需求。在实际使用中，可根据业务需求选择合适的策略，有时也可以结合使用。


蓝绿部署和滚动更新是Kubernetes中常用的两种发布策略。

蓝绿部署：创建一个全新的环境（绿环境），与现有环境（蓝环境）并行运行。新版本应用部署到绿环境中，在测试确保无误后，将流量切换到绿环境，旧的蓝环境可以随时下线。这种方式适合对稳定性要求高的场景，但需要双倍资源开销。

滚动更新：逐步替换旧版本Pod为新版本Pod，通常是一次升级一部分实例。Kubernetes通过ReplicaSet实现，设置最大不可用实例数和最大中断时间来控制风险。滚动更新能减少资源消耗，但可能会引入短暂的混合版本运行状态。

选择时需根据业务需求权衡资源成本与发布时间。对于小型服务或快速迭代项目，滚动更新更常见；而对于大型关键系统，蓝绿部署提供更高的安全性。

Kubernetes中的蓝绿部署和滚动更新是两种常见的部署策略：

  1. 蓝绿部署 (Blue-Green Deployment)
  • 同时维护两个相同的生产环境（蓝色和绿色）
  • 当前版本运行在一个环境（如蓝色），新版本部署到另一个环境（绿色）
  • 通过切换流量（如修改Service的selector）将用户流量一次性切换到新环境
  • 优点：快速回滚（只需切回旧环境），零停机时间
  • 缺点：需要双倍资源

示例yaml（通过修改标签切换）：

apiVersion: apps/v1
kind: Deployment
metadata:
  name: myapp-green
spec:
  replicas: 3
  selector:
    matchLabels:
      app: myapp
      version: green
  template:
    metadata:
      labels:
        app: myapp
        version: green
  1. 滚动更新 (Rolling Update)
  • 默认的Deployment更新策略
  • 逐步用新Pod替换旧Pod（可控制批次和间隔）
  • 通过maxSurge和maxUnavailable参数控制更新节奏
  • 优点：资源利用率高，适合大规模部署
  • 缺点：回滚较慢，存在新旧版本并存期

示例滚动更新配置：

spec:
  strategy:
    type: RollingUpdate
    rollingUpdate:
      maxSurge: 25%
      maxUnavailable: 25%

选择依据：

  • 需要快速回滚 → 蓝绿部署
  • 资源有限 → 滚动更新
  • 关键业务 → 蓝绿部署
  • 常规更新 → 滚动更新
回到顶部