Blue-Green Deployments on Kubernetes
A GitOps-driven Kubernetes delivery architecture using Argo Rollouts for blue-green and canary releases with metric-gated promotion and instant rollback. It buys release safety and zero downtime at the cost of temporary double capacity.
Overview
This architecture makes deployments safe and reversible on Kubernetes by running two production environments, blue (current) and green (new), and switching traffic between them. Use it when downtime is unacceptable and you want the ability to roll back instantly if a release misbehaves. The same controller supports canary releases, where you shift a small percentage of traffic to the new version first.
Delivery is GitOps-driven: the desired version lives in Git, and a controller reconciles it into the cluster.
Components
- Kubernetes: Runs both blue and green versions of each service.
- Argo Rollouts: Progressive delivery controller that manages blue-green and canary strategies and traffic shifting.
- Argo CD: Reconciles application manifests from Git into the cluster.
- Ingress controller: Routes external traffic and supports weighted splitting between versions.
- Prometheus: Supplies metrics that gate automated promotion.
- Helm: Packages and versions application manifests.
Data Flow
A new image is built and signed in CI, and the version is committed to the Git manifest. Argo CD applies it, and Argo Rollouts deploys the green version alongside blue without sending it live traffic. Smoke tests run against green. The controller then shifts traffic, either all at once for blue-green or incrementally for canary, while watching Prometheus metrics. If error rate or latency breaches a threshold, the rollout aborts and traffic stays on blue. Once green is healthy and fully live, blue is scaled down and kept briefly for fast rollback.
Scaling and Resilience
During a release, both versions run, so the cluster needs headroom for roughly double the capacity of the service under deployment. Automated analysis tied to the four golden signals stops bad rollouts before they reach all users. Rollback is near-instant because the previous version is still warm. Pod disruption budgets and multi-zone scheduling keep the live version available throughout. Horizontal Pod Autoscaling applies to whichever version serves traffic.
Security
GitOps gives every change an auditable, reviewable trail; the cluster pulls from Git rather than accepting pushes, reducing exposure. Images are signed and verified before admission. RBAC limits who can approve promotions, and rollout policies prevent direct manual edits that bypass review. Secrets are managed externally and never committed to the manifests.
Trade-offs and Alternatives
Blue-green gives instant rollback and zero downtime but temporarily doubles resource use and requires care with database schema changes, which must be backward compatible across both versions; the expand-and-contract pattern handles this. Canary reduces the cost of a bad release further but takes longer and needs reliable metrics. Plain rolling updates are simpler and use less capacity but offer slower, messier rollback. Choose blue-green or canary when release safety and zero downtime justify the extra capacity and tooling.