We want to move beyond simple "All-at-once" deployments and start using Canary releases and Blue-Green deployments within our GitOps framework. Between 'Flagger' and 'Argo Rollouts', which one integrates better with a Service Mesh like Linkerd or Istio? I want our GitOps controller to automatically trigger a rollback if our Prometheus metrics show an increase in error rates during the canary phase. What does the configuration look like in a typical Git repository for this?
3 answers
Argo Rollouts is a specialized controller that replaces the standard Kubernetes 'Deployment' object with a 'Rollout' object. It is exceptionally well-integrated with the ArgoCD UI, showing you a real-time visualization of your canary traffic split. Flagger, conversely, works by watching standard Deployments and is often preferred if you are using Flux CD. For Service Mesh integration, both support Istio and Linkerd extensively. In your Git repo, you define an 'AnalysisTemplate' (in Argo) or a 'Canary' resource (in Flagger) that points to your Prometheus queries. If the 'success-rate' metric falls below your threshold, the controller automatically scales back the canary and points 100% of traffic to the stable version.
When defining your Prometheus metrics for the canary analysis, how do you account for "cold start" latency spikes that might trigger a false-positive rollback?
Progressive Delivery is the "Holy Grail" of GitOps. It turns your deployment process into a self-correcting system that doesn't need a human to watch the dashboards at 2 AM.
Totally, Michelle. Implementing Argo Rollouts reduced our production incidents by 60% because the system catches the bugs before they hit the majority of our users.
George, that is a common issue. In our Argo Rollouts configuration, we include a prePromotionAnalysis with a delay period. This gives the new pods about 60 seconds to warm up and for the JVM to JIT-compile before we start measuring latency. We also use a "step-based" approach, where we only increase traffic by 5% every 2 minutes. By using a 'rolling window' average in our PromQL queries instead of instantaneous values, we smooth out those initial spikes and ensure our GitOps-driven rollbacks are only triggered by genuine regressions.