EKS 1.22 지원 종료를 앞두고 In-place 롤링 업데이트 대신 Gitops 기반 Blue-Green 방식으로 클러스터를 교체한 과정입니다. 전략을 바꾼 이유와 준비 과정, 적용 이후에 남은 과제를 정리했습니다. ||
안녕하세요, 비브로스 백엔드팀에서 인프라를 맡고 있는 박진홍입니다.
비브로스에서는 Amazon Cloud의 EKS Service를 사용하고 있고, 당시 최상인 1.22 버전의 EKS를 사용환경에 적용하였습니다. 똑닥 서비스들의 배포되고 안정적인 운영을 이어가던 도중 심판의 날이 다가오게 되었습니다.
EKS 최신 버전을 당시 구성하여도 약 3개월 1번씩 EKS 버전이 새로 나오게 되며, 약 1년 뒤에는 새로운 버전으로 업데이트를 진행해야 합니다.
저희는 기존 사용 중인 클러스터를 업데이트 하는 방식(In-place 롤링 업데이트)가 아닌, Gitops를 활용한 Blue-Green 방식으로 클러스터 업데이트를 진행한 방법에 대해 소개하려고 합니다.
EKS 심판의 날
Amazon EKS Service를 사용하는 회사의 가장 큰 고민 사항은 버전 업데이트이지 않을까 싶습니다. Amazon EKS의 가장 큰 장점은 마스터노드(Control Plane)을 AWS에서 관리하지만, 반대로 특정 버전에 대한 지원이 종료될 경우 마스터 노드를 자동으로 업데이트하게 됩니다. 같이 사용 중이던 워커노드(Data Plane)의 버전과 Add-on 등의 버전을 맞춰주지 않을 경우 장애가 발생할 수 있습니다.
똑닥 서비스는 Amazon EKS Service에 구성되어 있으며 마지막 업데이트는 당시 최상 버전인 1.22 버전을 사용하고 있었습니다. 1.22의 지원 종료가 되는 심판의 날이 다가오게 되어, 똑닥 인프라에서 EKS 업데이트를 준비하게 되었습니다.
기존 사용중이던 Kubernetes 1.22 버전은 2023년 06월 04일에 지원이 종료됩니다.
당시 EKS 전환을 2023년 03월에 준비하여 당시 최신버전인 1.25 버전으로 업데이트를 준비하였습니다. AWS 공식 문서(AWS Docs)를 참고하여 사용 중인 EKS 버전과 최신 버전의 지원종료 일자를 확인합니다.
한 가지 아쉬운 부분은 다른 릴리즈 업데이트와 다르게 약 2달 만에 2개의 버전이 새로 출시되어 아쉬움이 남습니다.
EKS 업데이트 전략 변경 계기
전반적으로 하기와 같은 3가지 이슈 사항이 있지만, 가장 큰 이유는 운영 중인 서비스가 있고 클러스터를 업데이트하였을 때 해당 버전에 문제가 발생하였을 때 이전 버전으로 롤백을 할 수 없다는 큰 제약사항이 있습니다.
Add-on, 3rd-party 지원 유무
기존 클러스터에서 업데이트를 진행시 Kubernetes 별로 변경되는 사항들에 대해 버전별로 확인 필요합니다.
(ex, EKS Add-on, Istio, HPA, Cronjob ...)
클러스터 업데이트 문제시 버전 롤백 제약 사항
운영 중인 환경에서 클러스터를 업데이트를 진행하다가 문제가 발생할 경우, 이전 버전의 클러스터로 롤백을 할 수 없고, 목표로 하는 1.25 버전까지는 총 3번의 클러스터 업데이트를 진행해야 하는 위험 요소가 존재합니다.
인프라 구조 변경으로 인한 시간 제약
기존 운영 중이던 인프라 환경의 네트워크, 보안그룹 구조를 개선하고, ArgoCD를 통해 멀티클러스터를 관리하게 변경 작업을 같이 진행함에 Kubernetes 버전에 각각 맞춰 준비하기에는 소요 시간이 많이 소모됩니다.
EKS 업데이트 전략 준비 과정
Route53 가중치 기반의 클러스터 교체
새로운 Amazon EKS를 생성(이하 Green 클러스터)하고, ArgoCD를 통해 기존 서비스 중인 어플리케이션과 Add-on, 3rd-party 솔루션을 각 클러스터 목적에 맞춰 구성합니다. 클러스터가 구축된 이후 API 버전과 서비스 로직을 검증한 뒤 Green Cluster에 AWS Route53 서비스를 통하여 가중치 기반으로 CF/ELB 등으로 연결을 변경합니다.
만약, 해당 클러스터 또는 어플리케이션에 문제가 생길 경우, 기