项目金丝雀策略在部署中

抱歉，我需要您提供要翻译的具体文本内容（除代码块、URL 和源链接之外）。请把文章的正文粘贴在这里，我会按照要求将其翻译成简体中文并保留原有的格式。

插图

Source: …

本项目演示内容

• Canary deployment – 它的真实含义
• 流量如何在不同版本之间分配
• 为什么会有 Canary（真实生产环境中的原因）

DevOps 工程师必须仔细关注的事项

• 如果 Canary 实施不当，在生产环境中可能会出现的故障

1️⃣ 什么是 Canary？（plain DevOps explanation）

Canary 部署 = 首先向 小比例的用户 发布新版本。

而不是：

• 一次性全部替换（Rolling）
• 运行两个完整的堆栈（Blue/Green）

你：

1. 保持 v1（stable） 运行。
2. 添加 v2（canary），并 使用更少的副本。
3. 让 Kubernetes 自然分流流量。

• 如果出现问题 → 立即删除 canary。
• 如果一切正常 → 将 canary 扩容，v1 缩容。

DevOps 目标： 减少冲击半径。

2️⃣ 当 DevOps 使用 Canary（真实场景）

使用 Canary 的情况 当新功能涉及：

• 支付、身份验证、Kafka 消费者
• 有风险的模式或配置更改
• 需要 真实用户流量，而不仅是测试流量

监控和回滚必须 即时。

不应使用 Canary 的情况：

• 应用是无状态且体积很小
• 没有监控措施
• 没有回滚流程
• 它是一个小型内部工具

3️⃣ 金丝雀演示项目（您将构建的内容）

您将部署：

• 一个 服务
• 通过 副本计数 进行流量分配

4️⃣ 步骤实施（最小化 YAML）

步骤 1 – 稳定版本 (v1)

文件: deploy-v1.yaml

apiVersion: apps/v1
kind: Deployment
metadata:
  name: app-v1
spec:
  replicas: 3
  selector:
    matchLabels:
      app: demo
      version: v1
  template:
    metadata:
      labels:
        app: demo
        version: v1
    spec:
      containers:
      - name: app
        image: hashicorp/http-echo
        args:
          - "-listen=:8080"
          - "-text=VERSION 1"
        ports:
        - containerPort: 8080

应用：

kubectl apply -f deploy-v1.yaml

步骤 2 – 金丝雀版本 (v2)

文件: deploy-v2-canary.yaml

apiVersion: apps/v1
kind: Deployment
metadata:
  name: app-v2-canary
spec:
  replicas: 1   # 🔑 这就是金丝雀
  selector:
    matchLabels:
      app: demo
      version: v2
  template:
    metadata:
      labels:
        app: demo
        version: v2
    spec:
      containers:
      - name: app
        image: hashicorp/http-echo
        args:
          - "-listen=:8080"
          - "-text=VERSION 2 (CANARY)"
        ports:
        - containerPort: 8080

应用：

kubectl apply -f deploy-v2-canary.yaml

步骤 3 – 单一 Service（流量分配在此进行）

文件: service.yaml

apiVersion: v1
kind: Service
metadata:
  name: demo-svc
spec:
  selector:
    app: demo
  ports:
  - port: 80
    targetPort: 8080

应用：

kubectl apply -f service.yaml

5️⃣ 实时流量观察（最重要的部分）

暴露服务：

minikube service demo-svc

对暴露的 URL 进行持续流量请求：

while true; do
  date +"%H:%M:%S"
  curl -s $URL
  echo
  sleep 0.3
done

您将看到的结果

VERSION 1
VERSION 1
VERSION 1
VERSION 2 (CANARY)
VERSION 1
VERSION 1

这就是 Canary 实际运行。

6️⃣ 流量拆分的真实工作原理（DevOps 实际）

Kubernetes 不按百分比拆分——而是按 Pod 数量 拆分。

• v1 = 3 个 pod
• v2 = 1 个 pod

≈ 25 % 的流量 会进入金丝雀版本。

7️⃣ Canary 阶段的 DevOps 责任（关键部分）

🔍 指标

• 错误率（5xx）
• 延迟增加
• Pod 重启
• CPU / 内存峰值

📜 日志

• 应用异常
• Kafka 延迟
• 数据库连接失败

🚦 健康

• 就绪探针失败
• CrashLoopBackOff
• 部分可用性

8️⃣ 模拟故障（重要演示）

立即删除金丝雀：

kubectl delete deployment app-v2-canary

2‑金丝雀

流量立即返回至

VERSION 1
VERSION 1
VERSION 1

• 👉 无需回滚
• 👉 无停机时间
• 👉 这就是金丝雀存在的原因

9️⃣ 将 Canary 提升为正式发布

如果一切正常：

kubectl scale deployment app-v2-canary --replicas=3
kubectl scale deployment app-v1 --replicas=0

结果：

• v2 成为主版本
• v1 已移除
• 用户从未察觉

🔟 常见金丝雀错误（真实生产问题）

• ❌ 没有监控
• ❌ 金丝雀没有 readinessProbe
• ❌ v1 与 v2 使用相同的数据库迁移
• ❌ 金丝雀运行时间超过所需
• ❌ 没有即时删除计划

最终的 DevOps 要点（重要）

Canary 不是 YAML。
Canary 是 风险管理。

你的真实工作：

• 控制曝光
• 及早检测故障
• 快速终止不良发布
• 保护用户和业务