day-log

EKS Auto Mode 실전 도입 가이드

EKS Auto Mode가 나온 지 1년 반쯤 됐다. 초기엔 "AWS가 Karpenter 위에 껍데기 하나 씌운 거 아냐?"라는 반응이 많았는데, 올해 초부터 zonal shift, EFA 지원, CloudWatch 로깅까지 붙으면서 이제 진지하게 검토해볼 만한 옵션이 됐다.우리 팀도 얼마 전에 스테이징 클러스터 하나를 Auto Mode로 옮겼다. 이 글은 그 과정에서 정리한 내용이다. "왜 쓰는지" 같은 마케팅 얘기는 최대한 빼고, 실제로 뭘 바꿔야 하고 뭘 조심해야 하는지에 집중한다.뭘 대신 관리해주는지부터Auto Mode를 켜면 AWS가 아래를 관리한다.컴퓨트: Managed Node Group 대신 Karpenter가 노드를 띄운다. AMI는 Bottlerocket 고정, 21일마다 강제 재활용네..

지난주에 팀 내부에서 조용히 진행해온 일 하나가 있다. EKS 클러스터 12개에 걸쳐 흩어져 있던 IRSA(IAM Roles for Service Accounts) 설정을 Pod Identity로 이관하는 작업이다. 큰 장애 없이 끝났지만, 중간에 몇 번은 새벽에 알람이 울려서 눈이 번쩍 떠졌다. 그 삽질 기록.시작한 이유는 단순했다. 클러스터를 하나 더 늘리는데, 또 OIDC provider를 만들고, trust policy에 system:serviceaccount:*:* 문자열을 하나하나 박고 있는 내가 좀 한심하게 느껴졌다. 마침 최근에 나온 자료들에서도 신규 워크로드는 Pod Identity 쪽으로 가는 게 대세라고 얘기하고 있었고. 참고로 IRSA가 deprecated 된 건 아니다. 그냥 새로..

지난주에 롤링 업데이트 도중 5분 동안 502가 쭉쭉 떨어졌다. 트래픽 피크 시간대였고, 알림 채널이 몇 초 간격으로 울렸다. 새벽도 아닌 오후 3시였는데, 오히려 그게 더 뼈아팠다. 다들 사무실에 있었으니까.우리 팀은 EKS 위에 AWS Load Balancer Controller로 ALB를 붙여서 쓴다. 노드 24대, 파드 수는 서비스마다 다르지만 문제가 된 서비스는 파드 12개짜리였다. 배포 스크립트도 평범한 Deployment 롤링 업데이트, maxSurge: 25%, maxUnavailable: 0. 이론적으로는 무중단이어야 하는데, 현실은 그렇지 않았다.처음 의심한 건 헬스체크였다로그를 열어보니 502가 뜬 요청들은 전부 upstream connect error 계열이었다. ALB는 살아있다고..

지난 화요일 밤이었다. 정확히는 수요일 새벽 2시 40분. 폰이 진동했고, 나는 다음날 반차를 쓸까 진지하게 고민 중이었다.Karpenter를 도입한 지 4개월쯤 됐다. 처음에는 얌전하게 consolidationPolicy: WhenEmpty로 돌렸는데, 팀 내부에서 "이럴 거면 왜 Karpenter 썼냐"는 얘기가 슬슬 나왔다. 우리 EKS 클러스터는 노드 30대 규모, 대부분 m6i 계열이었고 야간에는 40% 정도 놀고 있었다. AWS 비용 리뷰에서 매번 얻어맞다 보니 결국 이번 분기에 WhenEmptyOrUnderutilized로 넘어가기로 했다. Karpenter 문서에 최근 이게 코스트 민감한 팀의 기본값이라고까지 적혀 있었으니 뭐 걱정할 게 있겠나 싶었다.그날 새벽에 걸린 알람은 Payment..

Karpenter 얘기는 이제 새롭지 않다. AWS re:Invent 때마다 나오고, 트위터에서도 마이그레이션 후기가 쏟아진다. 얼마 전 Salesforce가 1,000개 넘는 EKS 클러스터를 Karpenter로 옮겼다는 소식도 있었고. 그런데 우리 팀은 좀 늦게 결정한 편이다. 작년에 Cluster Autoscaler(이하 CA)에서 Karpenter로 넘겼고, 반년 정도 운영해봤다. 결론부터 말하면 이득은 있었다. 다만 처음 예상했던 이유들과는 조금 달랐다.왜 넘어갔나원래 이유는 명확했다. 노드 스케일링이 느리다. CA는 ASG 기반이라 unschedulable 파드가 생기면 → CA가 감지 → ASG desired capacity 조정 → EC2 프로비저닝 → kubelet join. 이 사이클이..

배포는 빨라졌는데, 왜 그래프가 자꾸 뻘겋게 되나배포 시간이 오래 걸리는 게 싫어서 ALB target group의 deregistration_delay를 30초까지 내렸다가, 몇 주 동안 배포 때마다 5xx가 조용히 튀는 걸 뒤늦게 알아챈 이야기다. 뭐 그렇게 대단한 사건은 아닌데, 원인이 좀 얄궂어서 기록으로 남긴다.우리 팀은 ECS on EC2로 앱을 굴린다. 배포는 하루에 5~7번, 카나리 없이 rolling update. 처음에는 deregistration_delay=300 (기본값 5분)이었는데, 배포가 뭘 하나만 바꿔도 10분씩 걸리는 게 아까워서 30초로 내렸다. task 자체는 gracefully shutdown 잘 하니까 30초면 넉넉하다고 판단했다.며칠 뒤부터 CloudWatch 대시..

EKS 쓰다 보면 언젠가 한 번은 부딪히는 질문. 파드가 AWS 리소스에 접근할 때 IAM을 어떻게 붙일 것인가. 예전에는 답이 하나였다. IRSA. 근데 몇 년 전 Pod Identity가 나오고, 올해 초 우리 팀은 결국 이걸로 옮겼다. 왜 옮겼는지, 뭐가 좋고 뭐가 애매한지 정리해본다.IRSA는 그동안 잘 써왔는데솔직히 IRSA에 큰 불만은 없었다. OIDC provider 만들어놓고, ServiceAccount에 어노테이션 붙이고, IAM 역할의 trust policy에 그 SA를 넣어주면 끝. 몇 년째 잘 굴러왔다.문제는 클러스터가 늘어나면서 시작됐다. 우리 팀은 dev/staging/prod로 클러스터가 세 개, 여기에 데이터 팀이 요청한 별도 클러스터 하나가 더 붙어서 총 네 개다. 각 클러..

지난 주에 스테이지에서 결국 롤백했다. 프로덕션 붙이기 전에 걸러진 게 다행이라면 다행인데, 나흘을 매달렸으니 후련한 기분은 아니다.발단은 흔한 이유였다. 라이더팀 서비스가 시간대별로 커넥션이 폭주하면서 too many connections 로그를 하루에 몇 십건씩 뱉기 시작했다. Aurora PostgreSQL 15, max_connections 200에 라이더 API 파드가 오토스케일링으로 4개에서 20개까지 오가는 상황. HikariCP maximumPoolSize를 낮춰봐도 임계가 애매하게 겹칠 때는 여전히 튕겼다. AWS 문서에서 "RDS Proxy는 이럴 때 붙이면 된다"라고 아주 자신있게 쓰여있길래, 시니어분과 얘기해서 도입 PoC를 시작했다.붙인 순간, 왜인지 느려졌다붙이고 나서 첫 번째 ..

옮기기 전에 체크할 것EKS Pod Identity가 GA된 게 2023년 말이니까 벌써 2년 반쯤 됐다. 처음 나왔을 때는 "굳이 IRSA에서 갈아탈 이유가 있나" 싶었는데, 클러스터 수가 10개를 넘어가면서 OIDC provider를 매번 등록하고 trust policy의 sub 클레임을 클러스터마다 갈아끼우는 게 슬슬 짜증나기 시작했다. 올해 들어 우리 팀도 본격적으로 옮기기 시작했고, 이제 절반쯤 마이그레이션한 상태다.이 글은 "왜 옮겨야 하나"보다는 "어떻게 옮기나"에 집중한다. 결론부터 말하면 한 번에 다 갈아엎을 필요는 없다. 같은 클러스터, 같은 네임스페이스에서 IRSA와 Pod Identity가 공존한다.먼저 마이그레이션을 시작하기 전에 확인해야 할 게 몇 가지 있다.EKS 클러스터 버전..