Blue-Green Deployment Project on Kubernetes

Project Overview

This project demonstrates a Blue-Green Deployment strategy for a web application using Kubernetes and ArgoCD. The infrastructure is provisioned with Terraform modules, and the deployment is managed manually or via GitOps.

The project also integrates Prometheus monitoring to track application and cluster metrics.

Table of Contents

1. Architecture
2. Infrastructure Components
3. Terraform Modules
4. Kubernetes Deployment
5. Blue-Green Deployment Strategy
6. Monitoring
7. Usage
8. Future Enhancements

Architecture

The project is deployed on AWS EKS across multiple availability zones (multi-AZ) for high availability.

Key Components:

• VPC – Private network with subnets in multiple availability zones.
• Security Groups – Controls inbound/outbound traffic for EKS nodes and ALB.
• EKS Cluster – Kubernetes cluster managed by AWS.
• ECR – Container registry for storing application Docker images.
• OIDC & IRSA – IAM Roles for Service Accounts for secure AWS access.
• Route53 – DNS management for application domain.
• ALB (Application Load Balancer) – Handles traffic routing to blue or green deployments.
• External DNS – Automatically creates Route53 records pointing to ALB.
• Prometheus – Monitors cluster and application metrics.

Infrastructure Components

The infrastructure is provisioned using Terraform modules. Key components and their purpose:

1. VPC & Multi-AZ Subnets – Provides a secure network across multiple availability zones for high availability.

2. Security Groups – Controls inbound/outbound traffic for EKS nodes and ALB.

3. EKS Cluster – Managed Kubernetes cluster to run application workloads.

4. Worker Nodes – EC2 instances in EKS that run application pods across AZs.

5. ECR Repository – Stores Docker images for the application.

6. IAM Roles & Service Accounts (IRSA) – Provides AWS permissions for: . ALB Controller to manage load balancers. . External DNS to create Route53 records.

7. Route53 Hosted Zones – Domain management for your application (e.g., example.com).

8. AWS Load Balancer Controller via Helm – Automatically provisions ALB, listeners, and target groups for Ingress.

9. External DNS via Helm – Monitors Ingress resources and creates/upates Route53 DNS records automatically.

Kubernetes Deployment

• • Workflow Explanation:

• Service Accounts – IRSA for AWS permissions . aws-load-balancer-controller → Provides permission for ALB to manage load balancers. . external-dns → Allows automatic creation of DNS records in Route53.

• Helm Charts – Install controllers . ALB Controller → Automatically provisions ALB and target groups for Ingress. . External DNS → Monitors Ingress resources and creates/upates Route53 records.

• Ingress Resources – Route traffic . Annotations → Configure ALB listener ports, target type, and DNS hostname. . Directs user traffic to the appropriate service in the cluster.

• Services & Deployments – Blue-Green mode . Blue Deployment → Current live version serving users. . Green Deployment → New version deployed for testing before switching traffic. . ALB routes traffic to blue or green, enabling zero downtime deployments.

Blue-Green Deployment Strategy

• Workflow Explanation:

1. Blue Deployment – The current version of the application serving live traffic to users.

2. Green Deployment – A new version of the application deployed in parallel, not serving live traffic yet.

3. Testing – Green version is tested internally to make sure everything works correctly.

4. Traffic Switching – Once green is verified, the ALB (Application Load Balancer) is updated to route all incoming traffic from blue to green. This makes green live without downtime.

5. Rollback – If any issues are detected after switching, ALB can quickly redirect traffic back to the blue deployment.

Advantages:

• Zero Downtime – Users are never disconnected during the switch.

• Safe Testing – New version is tested before it receives live traffic.

• Easy Rollback – Traffic can be reverted immediately if something goes wrong.

Monitoring

• Prometheus → Track metrics & alerts

Usage

• Access via http://myapp.example.com
• Must be inside Route53 zone

Future Enhancements

• Automated rollback

• Multi-environment support

• TLS via cert-manager

• Optional Canary deployment

• CI/CD Pipeline

Request Flow

Here’s how a user request travels through your system:

1. User Request – The user accesses the application via http://myapp.example.com.

2. DNS Resolution (Route53) – The domain resolves to the Application Load Balancer (ALB) IP address. External DNS ensures the DNS record always points to the correct ALB.

3. ALB Routing – The ALB receives the request and routes it based on Ingress rules: . Traffic can go to the Blue deployment (current live version) . Or to the Green deployment (new version being tested)

4. Kubernetes Ingress – Ingress forwards the request to the appropriate Kubernetes Service (myapp-active).

5. Kubernetes Service – The service load-balances the request to one of the healthy Pods running the application in the selected deployment (blue or green).

6. Pod Processing – The Pod processes the request and generates a response.

7. Response to User – The response travels back through the service, Ingress, and ALB to the user’s browser.

• Summary Diagram:

[ User → Route53 DNS → ALB → Ingress → Service → Pod → Response ]

• Key Points: . ALB allows switching traffic between blue and green deployments without downtime. . External DNS automatically keeps the domain pointed to the ALB. . Pods can scale horizontally, and the service ensures even distribution of requests.