Kubernetes
Blue-Green Deployments on Kubernetes: Zero-Downtime Releases
Blue-green deployment runs two identical environments: blue (current production) and green (new version). Traffic switches from blue to green atomically once the new version passes health checks and validation. If something goes wrong, traffic switches back to blue instantly. This strategy provides the safest deployment model with zero-downtime and immediate rollback.
Need this done for your project?
We implement, you ship. Async, documented, done in days.
Blue-Green Architecture with Kubernetes Services
Create two Deployments: `my-app-blue` and `my-app-green`, each with a label like `version: blue` or `version: green`. A single Kubernetes Service uses a label selector to route traffic to the active version. To deploy a new version, update the green Deployment with the new image, wait for all pods to be ready and pass health checks, then update the Service's selector from `version: blue` to `version: green`. Traffic switches immediately because the Service's endpoints are updated atomically. To rollback, change the selector back to `version: blue`.
Pre-Switch Validation and Smoke Testing
Before switching traffic, validate the green environment thoroughly. Create a separate Service (e.g., `my-app-green-internal`) that routes to the green pods. Run automated smoke tests against this internal service: check health endpoints, verify database connectivity, test critical API paths, and confirm that the response format matches expectations. Use Kubernetes Jobs or CI pipeline steps to run these tests. Only update the production Service selector after all tests pass. This catches issues that unit and integration tests might miss, like environment-specific configuration errors.
Database Schema Compatibility
Blue-green deployments require database schema backward compatibility because both versions run simultaneously during the switch. Use the expand-contract migration pattern: first add new columns or tables without removing old ones (expand), deploy the new application version, then remove unused schema elements in a subsequent migration (contract). This ensures the blue version can still read and write to the database during the transition. For breaking schema changes, introduce an intermediate version that supports both old and new schemas.
Implementing with Argo Rollouts
Argo Rollouts provides a `BlueGreen` strategy as a first-class deployment primitive. Define a Rollout resource with `strategy.blueGreen` specifying an `activeService` (production traffic) and `previewService` (pre-release testing). Set `autoPromotionEnabled: false` to require manual approval before switching traffic. Argo Rollouts integrates with analysis templates that run automated tests and metric checks against the preview before promotion. If the analysis fails, the rollout is aborted automatically. This is the most robust way to implement blue-green on Kubernetes.
Why Anubiz Engineering
100% async — no calls, no meetings
Delivered in days, not weeks
Full documentation included
Production-grade from day one
Security-first approach
Post-delivery support included
Ready to get started?
Skip the research. Tell us what you need, and we'll scope it, implement it, and hand it back — fully documented and production-ready.