day-log

Karpenter v1.5로 올렸더니 새벽에 깨버린 이야기

지난주 화요일이었다. 새벽 3시 47분에 PagerDuty가 울렸다. P95 레이턴시 알람. 평소 같으면 일시적 스파이크겠거니 했을 텐데, 이번엔 5분 넘게 안 풀렸다.원인은 Karpenter였다. 정확히는, 일주일 전에 우리 팀이 v1.4에서 v1.5로 올린 게 발단이었다. Release note에 "emptiness-first consolidation"이라는 게 있길래 "오, 빈 노드 더 잘 정리해주겠네" 정도로만 읽고 PR을 머지했었다. 그게 화근이었다.무슨 일이 벌어졌나새벽 트래픽이 줄면서 Karpenter가 underutilized 판정을 내린 노드들을 consolidation하기 시작했다. 여기까진 정상이다. 문제는 우리 클러스터에 있던 60대 노드 중 30대 가까이가 비슷한 시점에 동시에 d..

요즘 사내 슬랙에 "Pod Identity로 갈아타야 하지 않냐"는 질문이 부쩍 늘었다. AWS가 작년부터 신규 워크로드에는 Pod Identity를 권장한다고 명시하고 있고, 최근 블로그들도 IRSA를 "레거시" 취급하는 분위기다. 그런데 막상 운영 중인 클러스터를 보면 IRSA가 멀쩡히 잘 돌아가고 있다. 굳이 옮겨야 하나?결론부터 말하면 모든 환경에 다 옮길 필요는 없다. 다만 새로 만드는 워크로드부터는 Pod Identity로 가는 게 맞고, 기존 워크로드는 옮길 만한 이유가 있을 때 옮기면 된다. 우리 팀에서 지난 두 달 동안 약 40개 ServiceAccount 중 절반쯤을 옮기면서 정리한 내용을 공유한다.IRSA, 뭐가 불편했나IRSA가 잘못된 건 아니다. OIDC provider만 등록해두..

지난달에 우리 팀이 운영하던 EKS 클러스터 두 개를 Auto Mode로 갈아탔다. "노드 관리 안 해도 된다", "Karpenter 직접 안 만져도 된다", 이런 얘기 듣고 한 달만에 슬쩍 옮긴 건데, 첫 달 청구서 받고 멘탈이 살짝 나갔다. 결론부터 말하면 망한 건 아니다. 다만 예상하고 옮긴 그림이랑은 꽤 달랐다는 얘기다.어떻게 옮겼나원래 우리 클러스터는 Karpenter 0.37로 NodePool 4개 돌리고 있었다. 일반 워크로드, batch job용 spot, GPU 추론, 그리고 좀 큰 메모리 잡아먹는 streaming consumer용. 인스턴스 타입은 직접 골랐다. m6i.2xlarge, r6i.4xlarge, g5.xlarge 이런 식으로. 한 1년 운영하면서 어떤 패밀리가 어디에 잘 ..

NAT Gateway egress 비용 폭탄 맞고 깨달은 것들지난달 AWS 청구서를 보고 멘탈이 나갔다. NAT Gateway 한 줄에 $4,200. 평소의 3배다. 우리 팀 인프라 전체 비용에서 NAT Gateway가 차지하는 비중이 갑자기 28%까지 치솟았다는 뜻이다.처음엔 누가 큰 데이터셋이라도 외부에 올렸나 싶었다. 근데 트래픽 패턴을 까보니 그게 아니었다. 범인은 ECR이었다. 정확히는, 우리가 6개월 전에 추가한 워커 노드 그룹이 ECR public 이미지를 NAT Gateway 통해서 매번 끌어다 쓰고 있었던 것.처음 본 게 다가 아니었다처음엔 VPC Flow Logs를 켜고 NAT EIP의 destination port를 분석했다. 결과를 보고 좀 당황했는데, 443 트래픽이 전체의 87%..

Karpenter NodeOverlay로 GPU spot 가격 흔들림 잡아보다 (alpha 도입 보류한 이야기)지난주에 GPU 학습 워크로드 비용 그래프를 보다가 멘탈이 좀 나갔다. 분명 spot으로 돌리고 있는데 월 비용이 예상의 1.6배. 클러스터에 들어가서 노드 목록을 찍어보니, Karpenter가 골라준 인스턴스 타입이 죄다 g5.12xlarge, g6e.12xlarge 같은 큰 놈들이었다. 우리가 돌리는 잡 사이즈 보면 g5.2xlarge 두세 대면 충분한데.원인을 찾는 데 한참 걸렸다. 결론부터 말하면 Karpenter의 spot 할당 전략 — price-capacity-optimized — 가 큰 인스턴스를 "더 싸다"고 판단한 결과였다. 단위 vCPU당 가격이 큰 인스턴스가 낮긴 한데, 우..

EKS 클러스터에서 워크로드 권한 부여, 어떻게 바뀌고 있나EKS 클러스터에서 워크로드가 AWS API를 호출할 때 권한을 어떻게 주느냐는 꽤 오래된 주제다. 한참 동안은 IRSA(IAM Roles for Service Accounts)가 사실상의 표준이었는데, 2023년 말에 Pod Identity가 나오고 2024-2025년을 거치면서 AWS도 "신규 워크로드는 Pod Identity 권장"으로 톤이 바뀌었다. 우리 팀도 작년 말부터 클러스터 두 개를 점진적으로 옮겼는데, 그 과정에서 정리한 실무 노트다.IRSA를 완전히 버리는 건 아니다. Fargate는 여전히 IRSA만 지원하고, 어떤 도구들은 아직 Pod Identity 어노테이션 매핑이 어색하다. 그래도 "신규 SA는 Pod Identity,..

작년 말에 우리 팀이 EKS Auto Mode로 갈아탔다. 정확히는 새로 만드는 서비스 클러스터 한 대를 Auto Mode로 띄워서 운영해본 게 6개월 정도 됐다. 기존 클러스터들은 Karpenter + 자체 노드 그룹으로 굴리고 있었고, 솔직히 큰 불만은 없었다. 그런데 신규 팀에서 클러스터를 자꾸 늘리는 상황이 되니까, 모든 클러스터마다 Karpenter 버전 맞추고, CoreDNS HPA 손보고, VPC CNI 업그레이드 줄 세우는 게 점점 부담이었다. "이거 AWS가 다 해주겠다는데 한번 맡겨보자"는 분위기였다.6개월 동안 잘 굴러간 부분도 있고, 새벽에 멘탈이 나간 부분도 있어서 정리해둔다. 누가 똑같은 선택을 앞두고 있다면 이 글이 조금이라도 시간을 아껴주면 좋겠다.도입 직후 — "이거 너무 ..

클러스터 트래픽이 늘 때 우리 팀이 가장 먼저 듣는 얘기는 보통 이거다. "노드 부족한 거 아니에요?" 근데 막상 들여다보면 노드는 멀쩡한데 DNS 쪽에서 병목이 생긴 경우가 절반쯤 된다. 특히 EKS에서 default 설정 그대로 굴리고 있으면 CoreDNS는 2개 파드로 묶여서 같은 AZ에 떨어져 있는 일도 흔하다.이 글은 EKS CoreDNS를 운영하면서 트래픽이 늘기 시작했을 때 가장 먼저 점검해야 하는 3가지를 정리한 가이드다. 정말로 노드를 더 붙이기 전에, DNS 레이어부터 들여다보자는 얘기.1. CoreDNS 파드 분산 — topologySpreadConstraints이게 의외로 묻혀 있는 변화인데, EKS의 CoreDNS add-on이 v1.9.3-eksbuild.11 그리고 v1.10...

매달 AWS 청구서를 열어볼 때 가장 짜증나는 항목이 뭘까. 우리 팀은 단연 NAT Gateway였다. EC2랑 RDS는 어느 정도 예상 가능한데, NAT는 매번 "어, 이게 왜 이렇게 나왔지?" 하면서 Cost Explorer를 파게 된다. 특히 EKS 클러스터를 운영하다 보면 이미지 pull, 로그 전송, S3 접근 같은 트래픽이 죄다 NAT를 거치게 되는데, 이 데이터 처리 비용이 의외로 크다.이번 글은 우리 팀에서 NAT Gateway 데이터 처리 비용을 한 달 만에 60% 가까이 줄인 방법을 정리한 거다. 정공법이지만 의외로 안 챙겨 쓰는 팀이 많아서 가이드로 남긴다.왜 NAT Gateway가 비싼가NAT Gateway 요금 구조부터 짚고 가자. 두 가지 축이 있다.시간당 고정비: $0.045/..

지난주 목요일 새벽 2시 47분. 알림 톡이 울려서 핸드폰을 봤더니 ArgoCD에서 동시에 11개 애플리케이션의 sync가 Degraded로 떨어졌다는 메시지였다. 처음엔 또 누군가가 이미지 태그를 잘못 박았겠지 싶었다. 새벽에 배포 멘션이 와있던 팀이 두 팀이었고, 자동 sync wave가 한꺼번에 돌고 있었으니까.그런데 콘솔을 열어보니 좀 이상했다. Pod 이벤트에 ImagePullBackOff가 줄줄이 떠있는데, 에러 메시지가 익숙하지 않았다.Failed to pull image ".dkr.ecr.ap-northeast-2.amazonaws.com/svc-foo:v1.42.0":rpc error: code = Unknown desc = failed to pull and unpack image:fai..