day-log

EKS Pod Identity vs IRSA, 2년 굴려보고 우리 팀이 정리한 것

Pod Identity가 정식으로 나온 지 이제 2년 반쯤 됐다. 그동안 우리 팀에서는 IRSA로 굴러가는 클러스터 4개, Pod Identity로 새로 띄운 클러스터 3개를 운영해봤다. 솔직히 처음에는 "OIDC 트러스트 한 줄 더 박는 게 그렇게 귀찮은 일인가?" 싶었는데, 클러스터가 늘어나면서 생각이 좀 바뀌었다.최근 6월 기준으로 Medium에 다시 비교 글이 올라오길래(이게 또 새로 입사하는 친구들이 가장 많이 찾는 주제다) 우리 팀 내부 결정 기록을 정리해서 공유한다. 결론부터 적으면, 새 워크로드는 Pod Identity, 단 Fargate에 띄울 거면 IRSA. 그리고 둘은 같은 클러스터에서 공존시켜도 별 문제 없다.트러스트 정책의 무게IRSA의 진짜 비용은 IAM role 자체가 아니라 ..

오늘 알게 된 건데, Karpenter NodePool의 weight 가지고 spot 우선 + on-demand fallback 구성한 분들 꽤 많을 거다. 우리 팀도 그렇게 쓰고 있었고. 근데 이게 생각만큼 매끄럽게 fallback이 안 되는 케이스가 있다.며칠 전에 다른 팀 슬랙에서 "spot이 깨졌는데 on-demand로 안 넘어와요" 하는 글을 봤다. 처음엔 NodePool 매칭이 안 맞나 싶었는데, GitHub 이슈를 따라가다 보니 karpenter-provider-aws#8885라는 게 있더라. 올해 1월 말부터 올라온 이슈인데, 아직 진행 중이다.무슨 상황이냐면대충 이런 구성을 떠올리면 된다.# 우선순위 높은 spot 풀apiVersion: karpenter.sh/v1kind: NodePoo..

요즘 사내 슬랙에 "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년 운영하면서 어떤 패밀리가 어디에 잘 ..

우리가 깐 구성지난주 화요일 새벽에 알림이 울렸다. 정확히는 알림이 안 울려서 문제였다. 이미지 변환 워커가 SQS 큐의 메시지를 잘 먹고 있는 줄 알았는데, 다음 날 아침에 보니 "어제 업로드한 썸네일이 안 나와요"라는 CS 티켓이 17건 쌓여 있었다. SQS DLQ에 들어간 것도 아니고 그냥 큐 어디에도 없었다. 처리는 안 됐는데 사라졌다는 게 가장 큰 문제였다.원인은 KEDA였다. 정확히는 KEDA가 잘못한 건 아닌데, scaleToZero를 너무 공격적으로 설정한 우리 팀이 잘못했다. 이 글은 그 이야기다.배경부터 정리하면, 우리 팀은 이미지 변환 파이프라인을 KEDA + SQS로 운영하고 있다. 사용자가 이미지를 업로드하면 S3 트리거가 SQS로 메시지를 보내고, 워커 파드가 그걸 받아서 리사이..

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%..

이번 주에 우리 팀 IAM trust policy 점검하다가 좀 놀란 게 있어서 짧게 적어둔다. 이거 모르는 분 꽤 많을 것 같다.익숙한 그 패턴GitHub Actions에서 AWS 붙일 때 OIDC federation 쓰는 건 이제 거의 표준이다. 그런데 trust policy 보다 보면 이런 게 자주 나온다.{ "Condition": { "StringLike": { "token.actions.githubusercontent.com:sub": "repo:my-org/my-repo:*" } }}좋다, 우리 repo로 한정은 했다. 근데 *이 너무 넓다. PR에서 돌아가는 워크플로우든, 누가 임시로 만든 브랜치에서 돌리는 거든, 환경 보호 없는 워크플로우든 — 전부 이 role을 가..

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개월 동안 잘 굴러간 부분도 있고, 새벽에 멘탈이 나간 부분도 있어서 정리해둔다. 누가 똑같은 선택을 앞두고 있다면 이 글이 조금이라도 시간을 아껴주면 좋겠다.도입 직후 — "이거 너무 ..