Progressive Delivery with Argo Rollouts: Canary, Blue-Green and Metric-Driven Promotion
A practical guide to separating deployment from traffic exposure on Kubernetes: why a rolling update is an obedient, blind machine, the anatomy of a canary Rollout with steps long enough to measure something, why setWeight does not split traffic unless you configure trafficRouting and how replica-based approximation degrades with few pods, real routing with the Gateway API plugin (plus two honest warnings about its alpha status and the RBAC the default chart omits), decoupling replicas from weight with setCanaryScale so a single cold pod does not abort a healthy deploy, an AnalysisTemplate that compares canary against stable instead of absolute thresholds that are correct on exactly one Tuesday, the rollouts_pod_template_hash label Prometheus does not have by default and which turns your analysis into one that can never say no, the arithmetic that decides whether a 5% canary can detect the regression you actually fear, blue-green with prePromotionAnalysis, Python smoke tests that assert the served SHA to dodge the selector-propagation race, scaleDownDelaySeconds as your real rollback window, the kubectl argo rollouts undo trap against Argo CD with selfHeal, KEDA targeting the Rollout rather than the Deployment, Prometheus alerts on the controller itself, eight recurring failures, a production checklist, when not to use any of this, FAQ and glossary. With production-ready YAML, Python and Bash.
Verificando acceso...