部署后执行冒烟检查并自动回滚

概述

就绪探针只回答一个问题：这个 Pod 是否应该接收流量。它不能证明应用能够处理用户真正关心的请求路径。环境变量改名、数据库地址错误或迁移缺失，都可能让 Pod 处于完全就绪却完全不可用的状态。部署后检查通过真实入口发起真实请求，并且只有在响应体显示依赖健康时才认定成功，从而弥补这个缺口。

步骤

1. 编写覆盖 API 与数据库依赖的冒烟脚本：

#!/usr/bin/env bash
set -euo pipefail
for i in $(seq 1 10); do
  code=$(curl -s -o /tmp/body -w '%{http_code}' https://app.example.com/api/health)
  if [ "$code" = "200" ] && grep -q '"db":"ok"' /tmp/body; then
    exit 0
  fi
  sleep 6
done
echo "smoke check failed" >&2
exit 1

2. 在滚动完成后立即执行检查：

kubectl rollout status deployment/payments -n prod --timeout=180s
./scripts/smoke.sh

3. 检查失败时自动回滚：

- name: Roll back on failed smoke test
  if: failure()
  run: |
    kubectl rollout undo deployment/payments -n prod
    kubectl rollout status deployment/payments -n prod --timeout=180s

4. 回滚后重新执行冒烟检查确认恢复。

验证

正常情况下，部署后检查应在数十秒内通过；注入一个错误的环境变量后，流水线应在一分钟左右失败并触发回滚。回滚完成后再次执行检查应通过，从而证明问题来自新版本而不是环境。运行摘要中应保留失败响应与回滚动作，便于后续定位。

注意事项

• 冒烟检查只覆盖少量路径，不能替代金丝雀分析或完整回归。
• 自动回滚无法撤销已执行的迁移或已产生的副作用。
• 重试总时长应控制在两分钟以内，避免拖慢每一次失败发布。
• 检查应通过真实入口执行，而不是在集群内直连 Pod。
• 不要在冒烟测试中执行破坏性操作或写入无法清理的生产数据。