안녕하세요, 비브로스 DevOps 박진홍입니다.
23년도에 EKS 업데이트 방식을 소개한 적이 있는데, 어김없이 찾아온 EKS 1.29버전의 지원 종료로 인해 업데이트를 진행해야 했습니다.
기존 CDK를 통해 EKS를 배포하고 In-place 업데이트하던 방식에서 EKSCTL을 통한 Blue-Green/Record 변경 방식으로 운영하다가 약 2년이 지나 해당 업데이트의 문제점을 파악하고 새로운 업데이트 방식을 검토하고 도입하기로 한 여정을 소개하고자 합니다.
이번 글에서는 EKS 업데이트시 고려했던 부분 과 도입 과정 을 중점적으로 다루고, 똑닥 인프라의 고도화 과정 을 일부 추가하여 작성하였습니다.
안녕하세요, 비브로스 백엔팀에서 인프라를 맡고 있는 박진홍입니다.
23년 상반기 EKS Blue-Green 업데이트에 이어 Karpenter 도입기를 소개해드리고자 합니다.
기존 AWS Cluster AutoScaler를 사용하였지만, 스파크성 트래픽시 노드 스케일링 속도에 문제가 있었고 비용 최적화를 위해 Karpenter 도입에 대해 고민하였습니다.
시작하기전 Kubernetes 엔지니어들의 많은 고심이겠지만.. 인프라의 변경사항은 "낭만이 아니라 헬이다!!!" 라는 말과 같이 유사한 영상이 있어 공유드립니다!
웃으면서 봐주시면 감사하겠습니다. 😂
안녕하세요, 비브로스 백엔드팀에서 인프라를 맡고 있는 박진홍입니다.
비브로스에서는 Amazon Cloud의 EKS Service를 사용하고 있고, 당시 최상인 1.22 버전의 EKS를 사용환경에 적용하였습니다. 똑닥 서비스들의 배포되고 안정적인 운영을 이어가던 도중 심판의 날이 다가오게 되었습니다.
EKS 최신 버전을 당시 구성하여도 약 3개월 1번씩 EKS 버전이 새로 나오게 되며, 약 1년 뒤에는 새로운 버전으로 업데이트를 진행해야 합니다.
저희는 기존 사용 중인 클러스터를 업데이트 하는 방식(In-place 롤링 업데이트)가 아닌, Gitops를 활용한 Blue-Green 방식으로 클러스터 업데이트를 진행한 방법에 대해 소개하려고 합니다.