현재 팀구성은 Devops 조직이긴 하지만 팀원들 대부분이 개발업무에 더 집중되어 있습니다.
그러다보니 아무래도 매년 주기적으로 다가오는 AWS 업그레이드가 부담스러울수 밖에 없네요.
단점이 있긴 하지만 그동안 in place(롤링 업그레이드) 방식으로 수월하게 해결해 왔습니다.
그런데, 얼마전 Amazon Linux2(AL2) EOS로 인해 2026년 6월까지 Amazon Linux2023 (AL2023) 전환해야 되고
EKS 업그레이드를 진행할 경우 무조건 블루그린 방식으로 진행해야 된다는 공지를 받았습니다.
물론 블루그린 방식이 많은 장점이 있는 정석이긴 하지만,
운영중인 상용 EKS 환경과 정확히 일치하는 클러스터를 동일하게 만드는게 쉽지는 않습니다.
일일이 원점부터 시작해서 모든 프로젝트에 맞게 인프라 설정을 하나하나 해야 될거 같은데.
손쉽게 설정정보를 백업한다든지 해서 새로운 EKS를 만드는 간편하고 좋은 방법이 있을까요?
일단 eksctl로만 이용중입니다만
지금이라도 테라폼 같은 Iac를 사용하는게 맞을까요?
조언 부탁드려요
DevOps 팀임에도 불구하고 대부분 개발에 투입되는 상황이고 Terraform 을 사용해보신 적이 없다면 아무래도 인적 리소스가 많이 부족하신 상황일 것 같습니다. Terraform을 쓰면 클라우드의 종류에 구애받지 않고 지원이 되어서 좋긴 한데, HCL도 배워야 하고 러닝커브가 좀 있는 상태에서 누군가가 그걸 배워서 진행해야겠죠. (HCL이 문법 자체가 어려운 것은 아닙니다만, 그래도 도입 초기에는 시간이 필요할 것 같습니다.)
팀원들이 개발을 많이 하셨다면 JSON/yaml에는 이미 익숙하실텐데 AWS만 고려하고 계신다면 CloudFormation 도입은 어떨까 싶네요.
EKS 업그레이드를 진행할 경우 무조건 블루/그린 전략으로 업데이트를 수행해야 한다라는 조건은 “관리형 노드 그룹에서 사용자 지정 AMI 혹은 launch template 사용하지 않는 경우” 에 해당 합니다. 즉, AWS에서 제공하는 최적화된 EKS용 AMI를 그대로 사용하는 경우에만 해당 하는 것 같습니다. 관리형 노드 그룹에서 “사용자 지정 AMI를 사용하는 경우” 현재와 같이 in-place 업데이트 전략을 그대로 사용할 수 있다고 가이드 하고 있습니다.
이런 경우, 가장 심플한 방안으로는 EKS 업데이트하고자 하는 목표 버전에 대한 EKS용 최적화 AMI → 사용자 정의 AMI를 생성합니다. 기존에 IaC 기반으로 인프라를 정의 및 관리를 하고 있지 않다면, AWS 콘솔에서 수동으로 진행하셔도 무방합니다. (추후 Packer, Terraform 사용을 고려 해보시면 좋을 것 같네요.)
위에 사용자 정의 AMI 생성이 완료되었다면, EKS 업데이트 방식으로 In-place 업데이트 전략으로 진행에 대해 설명 드리겠습니다. (EKS 클러스터 업데이트 순서대로 진행)
EKS 컨트롤 플레인 업데이트 수행
EKS 클러스터내에 addons 버전 업데이트 수행
EKS 데이터 플레인 영역인 EKS 노드 그룹 업데이트 수행
→ 커스텀 AMI를 지정해서 EKS 관리형 노드 그룹을 신규로 생성 (eksctl or 수동 or terraform)
→ 기존 EKS 노드 그룹에 배치 된 Kubernetes Pod 자원들을 신규 노드 그룹으로 Drain 시킵니다. (기존 EKS 노드 그룹은 Pod가 스케줄링 되지 않도록 cordon or taint 처리 필요)
→ Kubernetes 자원들이 모두 신규 노드 그룹에 배치 되고 Pod 상태 확인
기존 EKS 노드 그룹 제거 (마찬가지로 eksctl or 수동 or terraform)
참고로, EKS 컨트롤 플레인과 EKS 노드간 버전 차이(skew)는 n-3 까지 가능합니다. 만약에 버전 차이가 해당 조건에 해당 된다면 EKS 컨트롤 플레인 버전만 서둘러 업데이트한 후에 추후에 EKS 노드 업데이트 작업을 진행하셔도 됩니다.
알려주신 대로 현재 시스템이 관리형 노드 그룹에서 사용자 지정 AMI를 사용하는 경우에 해당해서
in-place 방식으로 하면 될거 같습니다.
사실 그동안 in-place 방식으로 별다른 문제 없이 잘 업데이트 해오고 있긴 하지만
시간이 갈수록 EKS에 namespace가 많이 생기고 비대해지다 보니.
혹시라도 업데이트 중 fail 나서 롤백도 안되는 상황이 올까 걱정도 되긴 합니다.
EKS 클러스터 업데이트의 핵심은 데이터 플레인 영역(노드) 입니다.
EKS 컨트롤 플레인은 AWS 자체적으로 다중화/스케일링 구성이 되어 있어서, 문제가 생기더라도 큰 문제는 없지만 데이터 플레인 영역은 고객이 직접 핸들링 해야 하는 부분이고 실행중인 워크로드를 안전하게 옮겨 가는게 핵심 입니다.
EKS 노드 그룹 업데이트 문제는 개발/스테이징 환경에서 충분히 테스트 해보고 발생되는 이슈를 모두 해소한 후에 프로덕션 환경 EKS 업데이트 진행하면 될 것 같습니다. 기존 EKS 노드 그룹을 그대로 유지한채로 신규 EKS 노드 그룹으로 kubernetes 자원들을 옮기고 나서 서비스에 문제가 생겨서 롤백해야 하는 상황이라면 다시 drian하여 기존 노드로 옮기면 될 것 같습니다. (kubectl 명령어 도구로 수동으로 작업 보다는 bash 스크립트를 만들어서, 작업하시면 좀더 수월하게 진행 할 수 있을 것 같습니다.)
