[EKS] Blue-Green Migration

개요

클러스터 업그레이드를 위해 Blue/Green 배포 전략을 실습합니다.
Terraform으로 인프라를 구성하고, ArgoCD로 워크로드를 GitOps 방식으로 배포, ALB와 Route53을 통해 무중단 트래픽 전환 실습

Kubernetes 클러스터의 버전 업그레이드는 운영 중에도 꾸준히 요구되지만, 잘못된 업그레이드는 전체 장애로 이어질 수 있습니다. 이때 Blue/Green 전략을 통해 무중단 배포, 빠른 롤백, 점진적인 마이그레이션이 가능해집니다.

 

방식	설명	장점	단점
In-place	기존 클러스터를 직접 업그레이드	리소스 효율적, 관리 단순	다운타임 가능성, 롤백 어려움
Blue/Green	새 클러스터 생성 후 트래픽 전환	무중단, 롤백 용이	비용 증가, IaC 필요
Canary	일부 노드/앱에만 점진 배포	안정성, 테스트 가능	세밀한 제어 필요

실습 시나리오

아래와 같이 AS-IS 인 Blue cluster 에서 클러스터 버전이 업그레이드된 Green Cluster를 배포하고,

DNS 가중치로 점차 트래픽을 넘겨 A-A 형태의 마이그레이션을 진행합니다.

 

실습 구성 요약

이 실습은 AWS 공식 EKS 블루프린트 기반으로 진행되며, Terraform으로 다음을 구성합니다:

- 공통 인프라 (environment/) : VPC, Route53, ACM, Secret Manager
- Blue 클러스터 (eks-blue/) : ArgoCD 및 애플리케이션 (예: burnham)
- Green 클러스터 (eks-green/) : 업그레이드된 버전의 동일 애플리케이션
- Route53의 가중치 기반 라우팅을 통해 트래픽 제어

 

실습 진행

코드 다운로드

git clone https://github.com/aws-ia/terraform-aws-eks-blueprints.git
cd patterns/blue-green-upgrade/

cp terraform.tfvars.example terraform.tfvars
ln -s ../terraform.tfvars environment/terraform.tfvars
ln -s ../terraform.tfvars eks-blue/terraform.tfvars
ln -s ../terraform.tfvars eks-green/terraform.tfvars

 

 

시크릿 매니저 생성

- 여기에 등록될 키는 github ssh에도 등록되어 있어야 합니다.

aws secretsmanager create-secret \         
  --name github-blueprint \
  --secret-string "$(cat ~/.ssh/id_ed25519)"

 

환경 변수 수정

aws_region          = "ap-northeast-2"
environment_name     = "eks-blueprint"
hosted_zone_name    = "ssungz.net" # your Existing Hosted Zone
eks_admin_role_name = "Admin" # Additional role admin in the cluster (usually the role I use in the AWS console)

#gitops_addons_org      = "git@github.com:aws-samples"
#gitops_addons_repo     = "eks-blueprints-add-ons"
#gitops_addons_path     = "argocd/bootstrap/control-plane/addons"
#gitops_addons_basepath = "argocd/"

# EKS Blueprint Workloads ArgoCD App of App repository
gitops_workloads_org      = "git@github.com:aws-samples"
gitops_workloads_repo     = "eks-blueprints-workloads"
gitops_workloads_revision = "main"
gitops_workloads_path     = "envs/dev"

aws_secret_manager_git_private_ssh_key_name = "github-blueprint"

 

Environment 클라우드 리소스 배포

# 테라폼 배포 수행
cd environment
terraform init
terraform apply -auto-approve

 

배포 확인

 

Blue Cluster 배포

cd eks-blue
terraform init
terraform apply -auto-approve

 

- main.tf를 보면 route53 가중치가 100으로 설정되어 있는 것을 확인할 수 있습니다.

 

Green Cluster 배포

cd eks-green
terraform init
terraform apply -auto-approve

 

- 반대로 main.tf에 가중치가 0으로 설정되어 있는 것을 확인할 수 있습니다.

 

어플리케이션 배포 확인

 

- 어플리케이션은 app of apps 방식으로 2개 레포에 연결되어 있다.

k get pod -n team-burnham
k get deployment -n team-burnham -l app=burnham

 

 

서비스 접속 시 접근 클러스터 확인

URL=$(echo -n "https://" ; kubectl get ing -n team-burnham burnham-ingress -o json | jq ".spec.rules[0].host" -r)
curl -s $URL | grep CLUSTER_NAME | awk -F "<span>|</span>" '{print $4}'

## 반복 접근
while true; do
  curl -s "$URL" | grep CLUSTER_NAME | awk -F "<span>|</span>" '{print $4}'
  sleep 2
done

 

- 블루 클러스터만 배포된 상태의 가중치는 아래와 같습니다.

 

가중치 변경 실습

현재 : Blue-100, Green-0

변경 : Blue-100, Green-100

 

 

- green-cluster main.tf 수정

 

- 접근 확인 

curl -s "$URL" | grep CLUSTER_NAME | awk -F "<span>|</span>" '{print $4}'

## 접근 횟수 확인
for i in {1..50}; do curl -s "$URL" | grep CLUSTER_NAME | awk -F "<span>|</span>" '{print $4}'; sleep 0.2; done | sort | uniq -c

 

현재 : Blue-100, Green-100

변경 : Blue-0, Green-100

 

 

- 접근 확인 

 

이렇게 가중치 별로 Blue > Green 업그레이드를 진행했습니다.

A-A 구조로 사용해도 좋고, 실제 마이그레이션 할 경우에도 좋은 방법인것 같습니다.

또 꼭 AWS에서만 사용할 수 있는 것이 아니기 때문에 다양한 방법으로 사용하면 운영에 도움이 많이 될 듯 합니다.