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 컨트롤 플레인 마이너 버전 업그레이드에 맞춰 노드 그룹 rolling 교체를 걸어놨는데, 새벽 3시쯤 슬랙에 "노드 3대가 30분째 SchedulingDisabled 상태로 안 빠진다"는 알림이 떴다. 새벽에 눈이 번쩍 떠졌다.원인은 결국 우리가 반년 전쯤 붙여둔 PodDisruptionBudget 이었다. 그런데 이게 왜 하필 이번 업그레이드에서 터졌는지, 어디서 계산이 어긋났는지를 정리해두려고 이 글을 쓴다.뭐가 문제였나우리 팀은 결제 관련 워크로드 몇 개에 minAvailable: 2 로 PDB를 걸어뒀다. 처음 붙일 때 replica가 4~5개였고, "최소 2개는 살아있어야 한다"는 서비스 팀 요구를 반영한 값이었다.문제는 그 사이에 트래픽 특성이 바뀌면서 몇몇 ..

Karpenter 1.x가 굴러가는 클러스터를 몇 개 운영해보니, "왜 이 노드가 갑자기 사라졌지?" 하는 질문이 종종 나온다. 특히 consolidation 정책을 WhenEmptyOrUnderutilized로 두면 (1.x 기본값이다) 반쯤 차 있는 노드도 사라진다. 사실 내부적으로는 꽤 정교한 시뮬레이션을 돌리고 있는데, 이걸 모르면 로그만 봐도 무슨 소린지 모르겠다.이 글은 Karpenter가 노드 하나를 지우기로 결정하기까지 내부에서 무슨 일이 벌어지는지, 코드 구조와 로그를 따라가면서 풀어본다. 우리 팀에서 Karpenter를 도입한 지 반년쯤 됐는데, 이 흐름을 이해하고 나니 disruption budget 튜닝이 훨씬 편해졌다.disruption controller가 하는 일Karpente..

지난주에 롤링 업데이트 도중 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..

작년 이맘때만 해도 우리 팀은 Cluster Autoscaler(CAS)만 썼다. 노드 그룹 5개 정도로 쪼개놓고, 크기 별로 알아서 스케일링되게 두는 방식. 나쁘지 않았다. 진짜로. 근데 클러스터가 200노드를 넘어가고, 배치 잡이랑 온라인 워크로드가 같은 클러스터에서 뒤섞이기 시작하면서 이야기가 달라졌다.이 글은 두 오토스케일러를 놓고 실무에서 어떤 게 다르고, 우리는 왜 결국 Karpenter로 갈아탔는지 정리해본 것이다. Karpenter 홍보글은 아니고, CAS가 여전히 낫다고 판단한 지점도 같이 적어둔다.구조가 근본적으로 다르다CAS는 "노드 그룹을 스케일한다". Karpenter는 "필요한 노드를 직접 만든다". 이거 한 줄이 사실상 전부다.CAS는 EKS 노드 그룹이든 GKE 노드 풀이든,..

지난 화요일 새벽 3시쯤이었다. 알람이 울렸다. P99 latency가 400ms를 넘겼다는 알림. 자다 깨서 노트북을 열었을 때 제일 먼저 든 생각은 "또 뭐가 문제냐"였다.우리 EKS 클러스터는 노드 40대 정도 되고, 트래픽이 특별히 튀지도 않았다. Grafana에서 애플리케이션 CPU도 여유롭고, DB 지표도 정상. 근데 왜 느려졌지? 한참 파고 나서야 원인이 나왔다. DNS였다. CoreDNS 파드는 CPU 20%도 안 쓰고 있는데 DNS 응답이 느렸다. 좀 어이가 없었다.처음엔 CoreDNS 스케일업을 의심했다당연히 첫 반응은 "CoreDNS 파드 수 늘려야겠다"였다. 그런데 grafana를 보니 CoreDNS 자체는 문제가 없었다. coredns_dns_request_duration_seco..

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

요즘 팀 슬랙에 EKS 노드 스케일 아웃 후 파드가 Running까지 도달하는 데 걸리는 시간 얘기가 자주 올라온다. GPU 노드에 20GB짜리 추론 이미지를 올려야 하는데, 이미지 pull에만 3분 넘게 걸린다. 트래픽 스파이크가 오고 나서야 노드가 뜨기 시작하면 사실상 늦다.이 문제 해결책으로 몇 년 전부터 계속 언급되는 게 lazy pulling이다. 이미지 전체를 미리 받지 않고, 컨테이너가 실제로 파일을 요청할 때만 해당 range를 원격 registry에서 가져다가 마운트해주는 방식. 개념은 단순한데 내부 동작이 꽤 재밌어서 이번에 SOCI(Seekable OCI) snapshotter 코드를 좀 뜯어봤다. 정리해둔다.OCI 이미지가 어떻게 생겨먹었길래 lazy pulling이 되는가우선 왜 ..