Kubernetes金丝雀发布实战：从手工到自动化部署

1. 为什么需要金丝雀发布？

在云原生时代，服务更新迭代的速度越来越快，但直接全量发布新版本的风险也随之增加。想象一下你正在运营一个日活百万的电商平台，新版本上线后突然出现商品详情页加载缓慢的问题，这种故障的影响范围和损失将难以估量。这就是为什么我们需要金丝雀发布（Canary Release）——这种部署策略的名字来源于矿工用金丝雀检测矿井毒气的典故。

金丝雀发布的核心思想是：先让一小部分用户流量访问新版本，其余用户继续使用稳定版本。通过监控新版本的各项指标（如错误率、延迟、CPU使用率等），确认没有问题后再逐步扩大新版本的流量比例，最终完成全量发布。这种方式能有效控制故障爆炸半径，把风险控制在可接受范围内。

2. 手工实现金丝雀发布的三种经典方案

2.1 基于Service的流量切分

这是最基础的手工实现方式，通过创建两个Deployment（稳定版和金丝雀版）共享同一个Service来实现。具体操作步骤如下：

yaml复制# 稳定版部署
apiVersion: apps/v1
kind: Deployment
metadata:
  name: stable-app
spec:
  replicas: 10
  selector:
    matchLabels:
      app: my-app
      track: stable
  template:
    metadata:
      labels:
        app: my-app
        track: stable
    spec:
      containers:
      - name: app
        image: my-app:v1.0.0

# 金丝雀版部署（初始副本数为1）
apiVersion: apps/v1
kind: Deployment
metadata:
  name: canary-app
spec:
  replicas: 1  # 初始只部署1个副本
  selector:
    matchLabels:
      app: my-app
      track: canary
  template:
    metadata:
      labels:
        app: my-app
        track: canary
    spec:
      containers:
      - name: app
        image: my-app:v1.1.0  # 新版本

# 共享的Service
apiVersion: v1
kind: Service
metadata:
  name: my-app-service
spec:
  selector:
    app: my-app  # 同时选择stable和canary的Pod
  ports:
    - protocol: TCP
      port: 80
      targetPort: 8080

这种方式的流量分配比例取决于两个Deployment的副本数比例。在上面的例子中，金丝雀流量占比约为1/(10+1)=9%。要调整比例，只需修改canary-app的replicas数量即可。

注意事项：使用这种方式时，确保两个Deployment的Pod模板中除了image版本和track标签外完全一致，否则可能导致流量分配不均匀。

2.2 基于Ingress的权重控制

对于HTTP服务，更精细的控制方式是使用Ingress Controller的流量切分功能。以Nginx Ingress为例：

yaml复制apiVersion: