Argo Rollouts 的 BlueGreen 策略必须显式声明 spec.strategy.blueGreen 才生效，需正确定义 activeService 和 previewService 的 selector 以匹配对应版本 Pod，避免流量错引或切换失败。
Argo Rollouts 的 BlueGreen 策略到底怎么配才生效
不写 spec.strategy.blueGreen，只写 spec.strategy.canary 或干脆不写策略，BlueGreen 就不会启动。Argo Rollouts 不会自动推断你想要蓝绿——它只认明确声明的 blueGreen 块。
常见错误是把 previewService 指向一个已存在的 Service，结果新版本流量进不去，因为该 Service 的 selector 没匹配新 ReplicaSet 的 label；或者漏掉 activeService，导致切换时找不到“当前线上服务”的入口。
-
activeService必须指向一个真实存在的 Service，且其selector要能稳定匹配当前稳定版本的 Pod（通常靠rollouts.argoproj.io/revision或自定义 label 控制） -
previewService也必须存在，但它的 selector 应只匹配新版本 Pod（比如加rollouts.argoproj.io/revision: "2"） - 别在
blueGreen块里写prePromotionAnalysis却忘了配AnalysisTemplate，否则 rollout 会卡在Paused状态，报错analysisrun not found
为什么 promoteBlueGreen 命令没反应
执行 kubectl argo rollouts promote <code>my-rollout 后状态没变，大概率是 rollout 处于非 Paused 或非 Healthy 状态。Argo Rollouts 只允许在明确暂停点（比如 pre-promotion hook）或健康过渡期触发人工发布。
典型场景：你刚创建 rollout，它还在 initial deploy 阶段，此时 promoteBlueGreen 是无效操作；又或者上一轮分析失败、Pod 一直 CrashLoopBackOff，rollout 进入 Degraded，命令也会静默忽略。
立即学习“Python免费学习笔记（深入）”；
让 macOS 自动化像说话一样简单 —— 用代码控制你的 Mac，无需学习 AppleScript 系统要求 macOS 14+ (Sonoma) Python 3.9+ 需要开启：辅助功能 + 屏幕录制权限
- 先运行
kubectl argo rollouts get <code>my-rollout，确认状态列显示Paused且Message里有waiting for manual promotion - 如果看到
Pending或Degraded，得先解决底层问题：检查新版本 Pod 日志、Event、Service endpoints 是否为空 -
promoteBlueGreen不接受--revision参数，它只作用于当前 pending 的 preview 版本，不能跳版发布
BlueGreen 切换时 Service endpoint 切换延迟的原因
不是 Argo Rollouts 慢，是 Kubernetes Service endpoint 更新有天然延迟。当你执行 promote，Argo Rollouts 立即更新 activeService 的 selector label，但 kube-proxy 和节点上的 iptables/ipvs 规则刷新需要几百毫秒到几秒——尤其在大规模集群或高负载节点上更明显。
这会导致短暂的 503 或连接拒绝，特别是客户端带长连接或重试逻辑弱时。如果你用 Istio，还可能叠加 Pilot 同步延迟。
- 避免依赖“瞬间切流”，业务侧要有重试（比如 3 次，间隔 100ms）和超时控制（建议 ≤ 2s）
- 不要把
activeService和previewService设为同一个名字，否则 selector 冲突会让 endpoint 处于不确定状态 - 若用 NodePort 或 LoadBalancer 类型 Service，注意云厂商 LB 的健康检查周期（如 AWS ALB 默认 30s），它可能比 endpoint 更新还慢
Python 客户端调用 BlueGreen rollout 的关键点
官方 argo-rollouts-python SDK 文档少，直接调 API 更稳。核心不是发 POST，而是要构造正确的 patch payload，并确保 RBAC 允许 patch rollout 资源。
最容易踩的坑是：用 replace 覆盖整个 rollout 对象，结果把 status 字段清空，导致 controller 认为对象损坏；或者 patch path 写成 /spec/strategy/canary 却想改 blueGreen。
- 必须用 JSON Patch（
application/json-patch+json），path 是/spec/strategy/blueGreen/activeService这类精确路径 - promote 操作本质是 patch
spec.strategy.blueGreen.previewReplicaCount为null并触发 reconcile，不是调某个函数 - Python 示例片段：
payload = [{"op": "remove", "path": "/spec/strategy/blueGreen/previewReplicaCount"}]<br>requests.patch(f"{api_url}/apis/argoproj.io/v1alpha1/namespaces/default/rollouts/my-rollout", json=payload, headers=headers)
蓝绿真正的复杂点不在 YAML 写法，而在于 active/preview Service 的 label 生命周期管理——一旦 revision label 被复用或 selector 泄露，就可能把旧流量引向新 Pod，这种问题往往凌晨三点才暴露。
