Kubernetes持续部署：蓝绿部署，金丝雀发布实战​

1. 引言：为什么要关注部署策略？

在当今快节奏的软件开发世界中，仅仅把代码写好已经远远不够了。想象一下，你花了三个月精心打造了一个电商平台的新版本，结果上线后因为一个没发现的bug导致整个网站崩溃，用户无法下单——这简直是每个开发者的噩梦。这就是为什么我们需要关注部署策略。

Kubernetes作为容器编排的事实标准，为我们提供了强大的部署能力。但如何用好这些能力，如何在保证系统稳定性的同时实现快速迭代，这就需要我们掌握蓝绿部署和金丝雀发布这两种核心策略。

2. 蓝绿部署：像切换交通灯一样切换版本

2.1 蓝绿部署的基本原理

蓝绿部署的概念其实很简单，就像它的名字一样直观。想象你有两个完全独立的环境："蓝色"和"绿色"。蓝色运行当前生产版本，绿色则部署新版本。当新版本准备就绪后，你只需要将流量从蓝色切换到绿色，就完成了发布。

# 技术栈：Kubernetes + Nginx Ingress
# 蓝色部署示例 (当前生产版本)
apiVersion: apps/v1
kind: Deployment
metadata:
  name: myapp-blue
  labels:
    app: myapp
    version: blue
spec:
  replicas: 3
  selector:
    matchLabels:
      app: myapp
      version: blue
  template:
    metadata:
      labels:
        app: myapp
        version: blue
    spec:
      containers:
      - name: myapp
        image: myapp:v1.0.0
        ports:
        - containerPort: 8080
---
# 绿色部署示例 (新版本)
apiVersion: apps/v1
kind: Deployment
metadata:
  name: myapp-green
  labels:
    app: myapp
    version: green
spec:
  replicas: 3
  selector:
    matchLabels:
      app: myapp
      version: green
  template:
    metadata:
      labels:
        app: myapp
        version: green
    spec:
      containers:
      - name: myapp
        image: myapp:v1.1.0
        ports:
        - containerPort: 8080
---
# Ingress配置 - 初始指向蓝色版本
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: myapp-ingress
spec:
  rules:
  - host: myapp.example.com
    http:
      paths:
      - path: /
        pathType: Prefix
        backend:
          service:
            name: myapp-blue-service
            port:
              number: 8080

2.2 蓝绿部署的切换过程

当新版本测试通过后，切换流量到绿色版本只需要更新Ingress配置：

# 更新后的Ingress配置 - 指向绿色版本
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: myapp-ingress
spec:
  rules:
  - host: myapp.example.com
    http:
      paths:
      - path: /
        pathType: Prefix
        backend:
          service:
            name: myapp-green-service
            port:
              number: 8080

2.3 蓝绿部署的应用场景

蓝绿部署特别适合以下情况：

需要零停机部署的关键业务系统
版本间有重大变更，需要完全切换的环境
需要快速回滚的场景（回滚就是切回蓝色环境）

2.4 蓝绿部署的优缺点分析

优点：

发布过程几乎瞬间完成
回滚极其简单快速
新旧版本完全隔离，减少风险
便于进行上线前的完整测试

缺点：

需要双倍资源（同时运行两个环境）
数据库兼容性问题需要注意
切换时可能有短暂会话中断
不适合需要渐进式发布的场景

3. 金丝雀发布：像矿工带金丝雀下井一样安全发布

3.1 金丝雀发布的基本原理

金丝雀发布的名字来源于一个古老的煤矿安全实践：矿工们会带一只金丝雀下井，因为金丝雀对有毒气体更敏感。如果金丝雀出问题了，矿工就知道该撤退了。

在软件部署中，我们也是先让一小部分用户流量访问新版本，就像"金丝雀"一样先探路。如果一切正常，再逐步扩大范围，直到完全替换旧版本。

# 技术栈：Kubernetes + Istio
# 部署v1版本 (当前稳定版)
apiVersion: apps/v1
kind: Deployment
metadata:
  name: myapp-v1
  labels:
    app: myapp
    version: v1
spec:
  replicas: 3
  selector:
    matchLabels:
      app: myapp
      version: v1
  template:
    metadata:
      labels:
        app: myapp
        version: v1
    spec:
      containers:
      - name: myapp
        image: myapp:v1.0.0
        ports:
        - containerPort: 8080
---
# 部署v2版本 (新版本)
apiVersion: apps/v1
kind: Deployment
metadata:
  name: myapp-v2
  labels:
    app: myapp
        version: v2
spec:
  replicas: 1  # 初始只部署少量实例
  selector:
    matchLabels:
      app: myapp
      version: v2
  template:
    metadata:
      labels:
        app: myapp
        version: v2
    spec:
      containers:
      - name: myapp
        image: myapp:v1.1.0
        ports:
        - containerPort: 8080
---
# Istio VirtualService配置 - 初始90%流量到v1，10%到v2
apiVersion: networking.istio.io/v1alpha3
kind: VirtualService
metadata:
  name: myapp
spec:
  hosts:
  - myapp.example.com
  http:
  - route:
    - destination:
        host: myapp
        subset: v1
      weight: 90
    - destination:
        host: myapp
        subset: v2
      weight: 10

3.2 金丝雀发布的渐进过程

当确认10%流量运行稳定后，可以逐步调整流量比例：

# 调整后的VirtualService - 50%流量到v1，50%到v2
apiVersion: networking.istio.io/v1alpha3
kind: VirtualService
metadata:
  name: myapp
spec:
  hosts:
  - myapp.example.com
  http:
  - route:
    - destination:
        host: myapp
        subset: v1
      weight: 50
    - destination:
        host: myapp
        subset: v2
      weight: 50

最终可以完全切换到v2：

# 完全切换到v2
apiVersion: networking.istio.io/v1alpha3
kind: VirtualService
metadata:
  name: myapp
spec:
  hosts:
  - myapp.example.com
  http:
  - route:
    - destination:
        host: myapp
        subset: v2
      weight: 100

3.3 金丝雀发布的高级用法

金丝雀发布不仅可以基于流量比例，还可以基于更复杂的规则：

# 基于用户属性的金丝雀发布
apiVersion: networking.istio.io/v1alpha3
kind: VirtualService
metadata:
  name: myapp
spec:
  hosts:
  - myapp.example.com
  http:
  - match:
    - headers:
        cookie:
          regex: ".*(internal|testuser).*"  # 内部或测试用户
    route:
    - destination:
        host: myapp
        subset: v2
  - route:
    - destination:
        host: myapp
        subset: v1

3.4 金丝雀发布的应用场景

金丝雀发布特别适合以下情况：

需要观察新版本在实际生产环境中的表现
系统对稳定性要求高，不能承受全量故障
需要基于用户属性进行差异化发布
需要收集生产环境中的性能数据

3.5 金丝雀发布的优缺点分析

优点：

风险小，影响范围可控
可以实时监控新版本表现
不需要双倍资源
支持基于各种条件的精细化控制

缺点：

发布过程较长
需要完善的监控系统
流量分配策略可能复杂
会话一致性需要特别处理

4. 蓝绿部署与金丝雀发布的对比与选择

4.1 何时选择蓝绿部署

当你有足够的资源同时运行两个环境
当你需要极快的回滚能力
当你的发布间隔较长，版本差异较大
当你的系统可以容忍瞬间切换

4.2 何时选择金丝雀发布

当你需要逐步观察新版本表现
当你的资源有限，无法同时运行两个完整环境
当你需要基于用户属性进行差异化发布
当你的发布频率很高，需要渐进式更新

4.3 混合使用策略

实际上，很多团队会结合使用这两种策略。例如：

先在隔离环境中进行蓝绿部署和全面测试
然后对内部用户进行金丝雀发布
最后对公众用户进行金丝雀发布

5. 实战中的注意事项

5.1 数据库兼容性

无论蓝绿还是金丝雀，数据库变更都是最大的挑战之一。解决方案包括：

向后兼容的数据库变更
使用功能开关
双写模式

5.2 会话一致性

对于有状态应用，确保用户会话不会在版本间跳转：

使用粘性会话
外部化会话状态
确保会话数据兼容

5.3 监控与告警

完善的监控是安全部署的保障：

部署前建立基线指标
设置合理的告警阈值
监控关键业务指标而不仅是技术指标

5.4 自动化与流程

将部署流程自动化：

自动化测试
自动化部署
自动化回滚
部署检查清单

6. 总结与最佳实践

经过对蓝绿部署和金丝雀发布的深入探讨，我们可以得出以下最佳实践：

根据业务需求选择策略：没有放之四海而皆准的解决方案，要根据你的具体业务需求和技术约束选择合适的策略或组合。
基础设施即代码：像本文示例一样，将你的部署配置代码化、版本化，确保每次部署都是可重复的过程。
渐进式交付：结合功能开关、A/B测试等技术，实现真正的渐进式交付，而不仅仅是渐进式部署。
全面监控：建立覆盖技术指标和业务指标的全面监控体系，这是安全部署的眼睛。
文化先行：部署策略的成功实施离不开团队文化的支持，建立协作、透明、勇于承担责任的文化。
持续改进：每次部署后都要进行回顾，持续改进你的部署流程和策略。

记住，部署策略的终极目标不是技术本身，而是为了更快、更安全地向用户交付价值。无论选择哪种策略，都要确保它服务于这个根本目标。

敲码拾光专注于编程技术，涵盖编程语言、代码实战案例、软件开发技巧、IT前沿技术、编程开发工具，是您提升技术能力的优质网络平台。

Kubernetes持续部署：蓝绿部署，金丝雀发布实战