Gitops를 활용한 AWS EKS 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 등으로 연결을 변경합니다.
만약, 해당 클러스터 또는 어플리케이션에 문제가 생길 경우, 기존 EKS Cluster(이하 Blue 클러스터)로 흐르는 트래픽을 중지하고 Blue 클러스터로 트래픽을 롤백합니다.
App of apps 도입
기존에도 ArgoCD를 사용하였는데 ArgoCD가 보고 있는 Chart 파일이 Service Repo에 구성되어 있어 인프라를 수정시 어플리케이션 서비스의 이미지 새로 생성된다는 단점이 있었습니다. 이점을 개선하고자 배포를 위한 "ddocdoc-kubernetes" Repo를 만들고, Manifest 파일에 Image Tag 값이 변경되게 변경하였습니다.
App of Apps 구성에서 사용되는 Chart 파일은 서비스들은 사용 목적에 맞춰 "ddocdoc-oksa" 라는 Repo에 서비스별 Helm Chart를 각각 구성하여 Kubernetes 특정 버전에서 사용이 제약이 없도록 구성하였습니다.
처음 구성에 시간이 많이 소요되지만, 한 번 만들어 놓을 경우 해당 템플릿을 재활용할 수 있습니다. 일부 케이스의 경우는 Helm Template을 사용하지 않고, Kustomize로 구성되어 있습니다. 각 사용목적에 따라 Helm, Kustomzie 등을 이용합니다.
## Kubernetes Github Repo
# 각 서비스 레포에 구성되어 있는 Chart를 한개의 Repo에서 관리
├── apps
├── README.md
├── dd-app-api-gateway-1.25 --- server-dd-template 사용
├── dd-app-consumer-1.25 --- server-consumer-template 사용
├── dd-charmander-1.25
...
# 사용 목적에 맞춰 Helm chart 구성
├── README.md
├── kafka-consumer-template
├── server-batch-template
├── server-dd-template
├── server-hpa-template
├── server-peaktime-template
...
그리고 기존 GitAction(CI) 또한 각 배포환경에 맞는 Barnch에도 "ddocdoc-kubernetes" Repo의 이미지 태그와 동일하게 변경되게 설정합니다. 같은 이미지 태그를 쓰는 이유는 마이그레이션 이전에 hotfix 같은 문제로 업데이트가 되었을 때 Repo에서 바라보고 있는 태그값이 달라지기 때문입니다. 그러므로 기존 1.22 버전의 클러스터가 바라보고 있는 Repo Image Tag와 신규 1.25 버전의 클러스터가 바라보고 있는 Repo Image Tag 값을 같게 설정합니다.
## GitAction CI.yaml
# Blue, Green Cluster가 바라보는 곳으로 Image Tag 변경
jobs:
blue_cluster:
uses: "./.github/workflows/old-deploy.yaml" # Blue Cluster Image Tag push
with:
eksVersion: 1.22
... 생략 ...
gren_cluster:
uses: "./.github/workflows/new-deploy.yaml" # Green Cluster Image Tag push
with:
eksVersion: 1.25
... 생략 ...
Kubernetes API 지원 종료 확인
Kubernetes 1.22에서 1.25로 버전 업데이트를 하면서 API Version이 업데이트 되거나 종료되는 API를 확인해야 합니다. 확인하는 방법으로는 Kubernetes 공식 문서 에서 확인할 수 있고, OpenSource인 kubent 을 사용하여 확인할 수 있습니다.
이번 1.25로 EKS 업데이트 시 변경해야 하는 API는 "CronJob" 과 "PDB" 가 있는 것을 확인할 수 있습니다.
$ kubent -t 1.25.0
5:47PM INF >>> Kube No Trouble `kubent` <<<
5:47PM INF version 0.7.0 (git sha d1bb4e5fd6550b533b2013671aa8419d923ee042)
5:47PM INF Initializing collectors and retrieving data
5:47PM INF Target K8s version is 1.25.0
---------------------------------------------------------------------------------
>>> Deprecated APIs removed in 1.25 <<<
---------------------------------------------------------------------------------
KIND NAMESPACE NAME API_VERSION REPLACE_WITH (SINCE)
PodDisruptionBudget kube-system coredns-pdb policy/v1beta1 policy/v1 (1.21.0)
Cronjob kube-system cronjob-runner batch/v1beta1 batch/v1 (1.21.0)
공식문서 및 Opensource를 활용하여 중복으로 확인하여 놓친부분이 있는지 확인합니다.
"kubent"이외 오픈소스로는 kubepug이 있으며, Krew Plugin 을 활용합니다.
ArgoCD Manifest 주의사항
주의사항으로는 각 Chart 폴더에 설정된 Manifest가 EKS Version에 맞춰 구성되어 있고, Kubernetes API가 다를 경우 배포가 실패될 수 있습니다. EKS 1.25 버전으로 업데이트할 경우, PDB와 CronJob의 API Version이 업데이트 되어서 1.22의 Manifest를 EKS 1.25에 배포할 경우 배포가 되지 않고 실패하게 됩니다.
EKS 업데이트 적용과 그 이후
App of Apps 도입 후기
ArgoCD를 좀 더 활용적으로 사용하고자 개발자와 인프라가 작업해야 하는 부분을 분리하는 과정에 많은 시간이 소모되었습니다. Kubernetes Resource를 수정할 때 이미지가 새로 생성되는 것을 막고자 CI를 분리하였고, 쿠버네티스 버전에 따라 Chart 파일을 관리하는 것으로 바뀌어 인프라 엔지니어의 호출 빈도수가 적게 되었습니다. 기존 이슈 사항이나 배포 시 인프라 엔지니어가 같이 호출되는 경우가 있었는데, ArgoCD의 권한을 분리하여 개발자가 로그를 보거나 특정 hotfix 이슈로 인해 긴급배포를 위해 ArgoCD를 통해 문제 해결을 할 수 있게 변경하였습니다.
그리고 Kubernetes Add-on, 3rd-party Solution 또한 ArgoCD를 통해 손쉽게 배포할 수 있게 구성하여 테스트를 위한 샌드박스 클러스터를 구성하여도 수제 햄버거(?)처럼 필요한 솔루션을 구성할 수 있게 구성하였습니다.
Blue Green 클러스터 교체 후기
1.22 버전의 만료일을 2주 남기고 1.25로 업데이트하는 것을 성공적으로 마무리하였습니다. 샌드박스 클러스터와 Add-on, 3rd-party 솔루션을 100번(?) 이상 설치하고 지우고를 반복하고, 대대적인 인프라 공사로 인한 누락 API 도메인들이 있는지 테스트하고 검증하였습니다. 마이그레이션 당시 Route 53에서 변경이 누락된 API 도메인들이 있어 임시 Proxy를 구성하여 해당 누락된 도메인들을 찾는 시간이 소요 되었지만, 성공적으로 업데이트를 진행하였습니다.
기억에 남는 부분은 테스트 환경에서 가중치 기반으로 변경할 때 TTL 시간이 기본적으로 300초로 설정되어 있는데, 변경 시 해당 TTL 시간을 조정하지 않아서 바로 적용이 되지 않아서 어디가 문제인지를 계속 엉뚱한 곳만 찾고 있었습니다.. 꼭 Blue-Green 클러스터 업데이트 시 TTL 시간을 조정하여 적용해야 합니다!
기존 클러스터를 업데이트 하는 방식이 아닌, Route53 가중치기반의 Blue-Green 클러스터 업데이트를 하면서 마이너 버전을 건너뛴다는 큰 장점을 경험하다 보니 앞으로는 위와 같이 Blue-Green 방식의 업데이트를 사용할 것 같습니다. 1.25 버전 또한 2024년 05월에 지원 종료가 되는 심판의 날이 오지만 Terraform 과 ArgoCD를 통해 충분한 테스트를 진행한다면 해당 업데이트 또한 어려움이 없을 것 같습니다.
똑닥 EKS 업데이트를 Blue-Green 방식으로 진행하였지만, 해당 업데이트보다 더 쉽고 간단한 방법들이 있습니다. 각 운영하는 환경에 맞는 업데이트를 진행하시는 것이 가장 좋은 선택입니다.
감사합니다.