如何设计具备自动活跃生产环境检测的Spinnaker蓝绿部署流水线？

核心逻辑：活跃环境的判定方式 #

Spinnaker本身不会自动维护蓝绿环境的活跃状态，而是通过Kubernetes资源的标签与路由规则来判定：

• 给蓝/绿环境的Deployment分别打上env: blue和env: green的标签
• 生产Service通过spec.selector中的env标签指向当前活跃的Deployment——Service指向的环境即为活跃环境
• 流水线通过读取Service的selector或Deployment的标签状态，动态确定非活跃环境作为部署目标

流水线分步设计（满足所有需求） #

1. 前置阶段：检测当前活跃环境 #

添加Run Script阶段，执行Kubectl命令获取并输出非活跃环境变量：

# 获取当前生产Service指向的活跃环境
ACTIVE_ENV=$(kubectl get service <你的服务名> -n <命名空间> -o jsonpath='{.spec.selector.env}')
# 计算非活跃环境
INACTIVE_ENV=$(if [ "$ACTIVE_ENV" = "blue" ]; then echo "green"; else echo "blue"; fi)
# 将变量输出为Artifact供后续阶段引用
echo "ACTIVE_ENV=$ACTIVE_ENV" > /workdir/env.properties
echo "INACTIVE_ENV=$INACTIVE_ENV" >> /workdir/env.properties

• 启用阶段的Artifact输出，将env.properties作为输出 artifact，后续阶段可通过${ACTIVE_ENV}、${INACTIVE_ENV}引用变量
• 替代方案：用Spinnaker原生的Find Manifest阶段查询Service的selector，无需写脚本，更符合Spinnaker生态

2. 部署新版本至非活跃环境 #

添加Deploy (Manifest)阶段，配置如下：

• 选择目标Kubernetes账户与命名空间
• 部署新版本的Deployment，强制添加标签：env: ${INACTIVE_ENV}，同时追加版本标签（如version: ${BUILD_NUMBER}）用于区分
• 确保Deployment的Pod基础标签（如app: <你的应用名>）与Service的固定selector匹配，仅通过env标签区分蓝绿环境
• 注意：不要修改现有活跃环境的Deployment，完全部署独立的新实例

3. 自动切换流量至新环境 #

1. 先添加Wait for Manifest Condition阶段，等待非活跃环境的Deployment达到available状态（availableReplicas等于replicas）
2. 再添加Patch Manifest阶段，修改生产Service的selector，将流量切换至新环境：

spec:
  selector:
    app: <你的应用名>
    env: ${INACTIVE_ENV}

• 可选：添加Run Script阶段执行应用健康检查（如调用/health接口），确保新环境正常后再完成流量切换

4. 流量切换后清理旧环境 #

添加Delete Manifest阶段，配置如下：

• 选择标签匹配env: ${ACTIVE_ENV}且app: <你的应用名>的Deployment
• 可选：添加Confirm阶段，让运维人员手动确认后再删除旧环境，降低误操作风险

避坑提示 #

• 不要使用滚动发布部署类型：滚动发布是在同一个Deployment内更新Pod，无法实现蓝绿环境的完全隔离，必须用独立的两个Deployment做蓝绿切换
• 优先通过Kubernetes资源状态判定活跃环境：不要依赖Spinnaker内部参数存储，避免集群与Spinnaker状态不一致
• 有状态应用需额外处理：部署新环境前需同步旧环境的数据库/存储数据，确保蓝绿环境数据一致性

内容的提问来源于stack exchange，提问作者LLL