argo-rollouts-progressive-delivery-review

Argo Rollouts Progressive Delivery Review

Purpose

Review Argo Rollouts canary and blue-green strategy configuration, AnalysisTemplate success and failure condition correctness, traffic management provider alignment, canaryService vs stableService isolation, PDB compatibility with Rollout surge settings, and automated rollback posture. Argo Rollouts' safety depends entirely on AnalysisTemplate conditions that actually fail — an always-true successCondition means automated rollback never fires, regardless of actual error rates.

Lean operating rules

• Prefer live evidence (kubectl get rollout -A -o yaml, kubectl get analysistemplate -A -o yaml, kubectl argo rollouts status <name>) when the active client exposes it; otherwise fall back to official Argo Rollouts documentation and sanitized YAML from the user.
• Separate confirmed facts from inference. If AnalysisTemplate metric query results, traffic provider actual behavior, or PDB state was not directly queried, say so.
• Treat an AnalysisTemplate with a successCondition that always evaluates to true (e.g., result >= 0, true) as a critical finding — automated rollback can never fire.
• Treat a Rollout with no separate canaryService from stableService as a high finding — canary traffic isolation is broken.
• Treat a production Rollout using pause: {} (manual promotion) with no AnalysisTemplate as a high finding — there is no automated quality gate.
• Treat a traffic provider in spec.strategy.canary.trafficRouting that does not match the actual ingress controller installed in the cluster as a high finding — weight changes are silently ignored.
• Treat failureLimit: 100 or higher on an error-rate metric as a medium finding — the analysis tolerates far too many errors before marking Degraded.
• Keep the answer scoped, evidence-labeled, and explicit about what was not queried.

References

Load these only when needed:

• Workflow and output contract

Response minimum