argo rollouts 不需在 go 代码中实现，而是通过 kubernetes crd 控制流量；go 服务只需提供稳定健康检查、正确 label 和 metrics，由 yaml 配置驱动蓝绿或金丝雀发布。
Argo Rollouts 在 Go 项目里不直接写代码实现
Argo Rollouts 是 Kubernetes 原生的渐进式交付控制器，它本身不依赖 Go 应用内部逻辑——你不需要在 main.go 里调用某个函数来触发蓝绿或金丝雀。它的控制面完全跑在 K8s 集群中，靠监听 Rollout 自定义资源（CRD）和调整底层 ReplicaSet / Service 来驱动流量切换。
这意味着：Go 服务只需保持标准 HTTP/gRPC 接口、健康检查路径（如 /healthz）可用，其余交给 Argo Rollouts YAML 配置驱动。
- 常见错误现象：
kubectl get rollout显示Progressing卡住，实际是 Go 服务没暴露 readiness probe 或 probe 返回非 200 - 使用场景：适用于已容器化、部署在 Kubernetes 上的 Go 微服务，不是本地开发或单机测试环境
- 性能影响：无运行时开销；但每次发布会创建新
ReplicaSet，需确保集群有足够 CPU/Mem 资源容纳双版本副本
如何配置 Rollout 资源启用蓝绿策略
蓝绿在 Argo Rollouts 中通过 strategy: blueGreen 启用，核心是控制 activeService 和 previewService 两个 Service 的 selector 指向不同 ReplicaSet。
关键点在于：Go 服务的 Deployment 必须被 Rollout 替代，且健康检查必须稳定——否则 prePromotionAnalysis 或自动预热会失败。
立即学习“go语言免费学习笔记（深入）”；
- 参数差异：
autoPromotionEnabled: false表示手动确认（适合生产），true则自动切流（适合 CI 流水线可信度高时） - 容易踩的坑：
previewService的 selector 必须与新版本 Pod label 完全匹配，否则流量切不进去；常因 label 拼写（如app: mygoapivsapp: my-go-api）导致 503 - 示例片段：
strategy: blueGreen: activeService: mygo-active previewService: mygo-preview autoPromotionEnabled: false
金丝雀发布的 Go 服务适配要点
金丝雀依赖 canary 策略下的 steps 和指标反馈，Go 应用本身不参与决策，但必须输出 Argo Rollouts 能采集的信号。
最常用的是 Prometheus 指标（如 http_request_duration_seconds_bucket）或自定义健康检查端点。若用内置 webhook 分析，Go 服务需提供一个返回 JSON 的 /metrics/analysis 接口（格式需符合 Argo Rollouts schema）。
- 使用场景：需要按 5% → 20% → 100% 分阶段放量，同时监控延迟、错误率等真实业务指标
- 兼容性影响：Kubernetes v1.19+、Argo Rollouts v1.3+ 才支持
setCanaryScale动态扩缩，旧版本只能靠固定canaryReplicas - 常见错误现象：
AnalysisRun处于Pending，通常是因为 Prometheus 查询超时，或 Go 服务未暴露/metrics且未配置failureCondition回退逻辑
Go 服务健康检查与就绪探针怎么写才不拖后腿
Argo Rollouts 的所有策略（包括暂停、回滚、自动升级）都强依赖 readinessProbe 和 livenessProbe 的响应结果。Go 服务若 probe 实现粗糙，会导致误判、卡住发布流程。
不要只检查端口通不通，要检查依赖是否 ready（如 DB 连接池、Redis、下游 gRPC 服务）。probe 路径建议独立于主逻辑，避免锁竞争或长耗时阻塞。
- 推荐写法：用
net/http启一个轻量/readyz，内含最小依赖连通性校验（例如db.PingContext()），超时设为1s，失败立即返回 503 - 容易踩的坑：
initialDelaySeconds设太小（如 1s），Go 应用还没初始化完 probe 就开始调，反复失败；应设为5–10s，留出日志初始化、DB 连接池 warmup 时间 - 示例 probe handler：
http.HandleFunc("/readyz", func(w http.ResponseWriter, r *http.Request) { if err := db.PingContext(r.Context()); err != nil { http.Error(w, "db unreachable", http.StatusServiceUnavailable) return } w.WriteHeader(http.StatusOK) })
真正难的不是写 Rollout YAML，而是让 Go 服务的 probe、metric、label、镜像 tag 管理形成闭环——任意一环脱节，金丝雀就会停在 5%，没人知道是配置错了还是服务真挂了。
