day-log

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

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

새벽 3시 47분. 핸드폰이 미친 듯이 울렸다.PagerDuty가 동시에 네 건. P99 레이턴시, 5xx 비율, 큐 적체, 그리고 결제 워커 alive 체크 실패까지 줄줄이 빨간색. 잠이 깰 새도 없었다. 노트북을 열고 Grafana부터 켰는데, 노드 수가 떡 하니 23대에서 6대로 떨어져 있었다. 누가 그랬을까. 범인은 나였다. 정확히는, 일주일 전 내가 만진 Karpenter 설정이.무슨 짓을 했길래배경부터. 우리 팀은 EKS에서 Karpenter로 노드를 굴린다. NodePool 두 개 — 일반 워크로드용 default, 그리고 결제/주문 같은 stability-sensitive 워크로드용 payments. 한 달 전쯤 FinOps 압박이 들어왔다. "비용 너무 많이 나온다, 야간에 트래픽 적은 ..

작년 말 GA 된 EKS Auto Mode를 우리 팀도 새 클러스터에 적용했다. 몇 주 굴려보고 운영에서 부딪힌 부분들이 꽤 있어서, 도입을 고민하는 분들에게 도움이 될 만한 실무 가이드를 정리했다. 마케팅 문구가 아닌 "현실에서 뭐가 좋고 뭐가 아픈가" 관점이다.처음 듣는 분을 위해 간단히 설명하면, EKS Auto Mode는 컴퓨트(노드), 네트워킹(VPC CNI/로드밸런서), 스토리지(EBS CSI), Karpenter, Pod Identity Agent 같은 클러스터 구성요소를 AWS가 관리형으로 묶어서 제공하는 모드다. 우리가 직접 Helm chart를 깔고 IRSA를 매핑하던 작업이 거의 사라진다. 대신 자유도는 줄어든다.1. 사전 준비: 우리 클러스터가 적합한가도입 전에 다음 체크리스트를 먼..

Karpenter를 1년 넘게 운영하다 보니 "왜 이 인스턴스 타입을 골랐을까" 하는 순간이 종종 생긴다. m5.2xlarge면 충분해 보이는데 c6i.4xlarge를 띄운다거나, 분명히 비슷한 spec인데 어떤 Pod는 한 노드에 몰리고 어떤 Pod는 새 노드를 띄운다. 처음엔 그냥 "알아서 잘 해주겠지" 하고 넘어갔는데, 최근 Karpenter 1.11에서 Application Recovery Controller(ARC) zonal shift 통합이 들어오면서 zone 단위 회복 시나리오를 검토할 일이 생겼다. 이 김에 스케줄러 내부를 한 번 제대로 들여다봤다.사실 Karpenter의 스케줄링 로직은 pkg/controllers/provisioning/scheduling/scheduler.go 한 파..

지난 3주 동안 사내 LLM 추론 서비스를 KServe + vLLM 조합으로 K8s에 올렸다. 결과만 말하면 "어찌어찌 굴러는 가는데, 처음 일주일은 거의 매일 야근"이었다. 글로 정리해두지 않으면 또 까먹을 것 같아서 적어둔다.배경부터 짧게 풀자면, 우리 팀은 자체 호스팅 LLM 추론을 sagemaker나 bedrock 대신 EKS 위에 올리기로 했다. 비용도 비용이지만, 모델 빈번한 교체 + 사내 RAG 데이터와의 결합 때문에 직접 운영이 불가피했다. NVIDIA L40S 노드 4대로 시작했고, 모델은 처음에 Llama 3.1 8B, 그다음 70B로 키워가는 시나리오였다.1. 첫 번째 벽 — 이미지 풀(Pull)에 12분vLLM 공식 이미지(vllm/vllm-openai:latest)가 거의 9GB ..

처음에 의심한 것들지난주 새벽 2시 반에 알람이 울렸다. P99 레이턴시 알람이었는데, 한두 번이면 그냥 무시하고 자고 다음 날 보겠지만 같은 알람이 5분 간격으로 계속 울렸다. 누워서 폰만 보다가 결국 노트북을 열었다.원인은 Karpenter였다. v1.0으로 올리고 한 달 정도 됐는데, 이 시점에 처음으로 큰 사고가 터졌다. 자려고 누웠다가 새벽 5시까지 깨어 있었던 그 밤 이야기를 정리해두려고 한다.알람이 P99 latency였으니까 당연히 애플리케이션을 먼저 봤다. 그런데 백엔드 트레이스를 까보니 응답 자체는 빠른데, 가끔 한 노드의 모든 파드가 동시에 사라지는 패턴이 보였다. terminated 이벤트가 5분에 한 번씩 떴다.처음엔 spot interruption인 줄 알았다. 우리 서비스 노드..

GitHub-hosted runner 비용이 슬슬 부담스러워서 self-hosted로 갈아탈 때, 요즘은 거의 ARC(Actions Runner Controller) + Karpenter 조합이 정석처럼 굳어가는 분위기다. 우리 팀도 작년 말부터 이 구성으로 전환했고, 그 과정에서 정리해둔 내용을 가이드로 풀어본다.작년 6월에 ARC 0.12가 나오면서 ephemeral runner 설치가 큐잉되고 실패 시 5번까지 재시도하는 식으로 바뀌었다. 노드 스케일 다운 도중에 러너 파드가 휘말려 죽는 케이스에서 체감이 꽤 좋아졌다. 이 글은 0.12 이상 기준이다.왜 Karpenter랑 묶나처음엔 Cluster Autoscaler로도 충분하지 않을까 했었다. 결론부터 말하면, CI 워크로드 특성상 Karpent..

오늘 알게 된 건 아니고, 최근에 팀원이 Karpenter 설정 PR을 올렸길래 리뷰하다가 "어 이게 v1.0부터 바뀌었는데 모르는 분들 꽤 많겠네" 싶어서 짧게 정리해둔다.WhenUnderutilized 라는 이름은 이제 없다Karpenter 1.0 GA 이후로 WhenUnderutilized는 WhenEmptyOrUnderutilized로 이름이 바뀌었다. 옛날 블로그 글이나 사내 위키 보고 그대로 복붙하면 NodePool apply가 깨진다. 지난주에 1.12.0이 나왔는데도 검색하면 아직 옛날 이름이 상위에 뜨더라.그리고 더 중요한 변화 — 1.0부터는 consolidateAfter를 WhenEmptyOrUnderutilized에서도 쓸 수 있다. 이전에는 WhenEmpty에서만 동작해서, "노드..

지난달에 결국 Karpenter로 갈아탔다. 팀에서 반년 넘게 "다음 분기에 해야지" 하며 미뤄왔던 숙제였는데, 예상대로 쉽지 않았다. 이 글은 자랑이 아니라 그냥 기록이다. 비슷한 고민 하는 분들에게 조금이라도 도움이 됐으면 해서 적는다.Karpenter가 v1.0 GA 찍은 지도 벌써 한참 됐고, 최근에는 OCI provider까지 GA 나오면서 더 이상 "AWS 전용 실험 프로젝트" 소리는 못 듣는 상황이다. 그래도 막상 프로덕션에 올려보면 문서에 안 나오는 함정이 꽤 있다.왜 옮겼나솔직히 Cluster Autoscaler(CAS)가 못 쓸 물건은 아니다. 노드 18대 규모에서 몇 년을 잘 돌았다. 문제는 배치 잡 비중이 커지면서부터였다.우리 팀은 데이터 파이프라인 일부가 Kubernetes Job..