.png){kind=small}
안녕하세요. 쿠버네티스(EKS)를 운영하다 보면 트래픽이 몰릴 때 파드(Pod)는 늘어났는데, 정작 그 파드를 띄울 노드(EC2)가 늦게 떠서 서비스가 지연되는 경험, 다들 있으실 겁니다.
기존에 우리가 쓰던 **Cluster Autoscaler(CA)**는 구조적인 한계가 있었습니다. 이를 해결하기 위해 AWS가 직접 칼을 갈고 만든 오픈소스 프로젝트가 바로 Karpenter입니다.
오늘은 왜 다들 Karpenter로 넘어가라고 하는지, 기존 방식과 무엇이 다른지 개념 위주로 확실하게 정리해 드립니다.
1. 기존 방식(Cluster Autoscaler)의 한계: "버스 배차 간격의 답답함"
우리가 흔히 쓰던 Cluster Autoscaler(CA)는 사실 쿠버네티스 native한 방식이라기보다, AWS의 **Auto Scaling Group(ASG)**에 의존하는 방식입니다.
동작 방식: 파드가 들어갈 자리가 부족함(Pending) → CA가 감지 → ASG에게 "노드 수(Desired Capacity) 늘려줘" 요청 → ASG가 EC2 생성 → 노드 합류.
문제점:
느리다: 단계를 많이 거치기 때문에 노드가 뜨는 데 시간이 꽤 걸립니다.
유연하지 않다: 미리 정의해 둔 노드 그룹(예: t3.medium 그룹) 안에서만 스케일링이 됩니다. 만약 고성능 CPU가 필요한 파드가 들어와도, 설정된 t3만 계속 띄우는 비효율이 발생합니다.
마치 **"사람이 많아져도 정해진 크기의 버스만, 정해진 배차 간격으로 오는 것"**과 같습니다.
2. Karpenter: "필요한 차를 바로 부르는 택시"
Karpenter는 ASG(Auto Scaling Group)를 거치지 않습니다. 쿠버네티스 클러스터 안에서 직접 EC2 Fleet API를 호출하여 노드를 생성합니다.
핵심 특징 1: Groupless (노드 그룹이 없다)
Karpenter의 가장 큰 혁명입니다. 미리 t3.medium용 그룹, m5.large용 그룹을 만들어 둘 필요가 없습니다.
**Provisioner(NodePool)**라는 설정만 해두면,
대기 중인 파드(Pod)의 리소스 요청량(CPU, Memory)을 분석해서,
AWS에 있는 수백 가지 EC2 인스턴스 타입 중 **"가장 저렴하고 딱 맞는 인스턴스"**를 알아서 골라옵니다.
핵심 특징 2: Just-in-Time (엄청 빠르다)
중간 관리자(ASG)가 없기 때문에, 파드가 Pending 되자마자 거의 즉시 EC2 생성 명령을 날립니다. 기존 CA 대비 노드 프로비저닝 속도가 획기적으로 빠릅니다.
핵심 특징 3: Consolidation (빈틈 채우기 & 비용 절감)
노드에 파드가 듬성듬성 떠 있으면 비용 낭비죠?
Karpenter는 알아서 파드를 이동시켜 빈 노드를 정리하거나, "큰 노드 1개를 작은 노드 2개로 바꾸는 게 더 싸겠다" 싶으면 알아서 교체해 버립니다. (비용 최적화의 끝판왕)
3. 한눈에 비교: CA vs Karpenter
4. 언제 도입해야 할까요?
다음과 같은 고민이 있다면 Karpenter 도입을 강력 추천합니다.
다양한 인스턴스 타입을 써야 할 때: AI/ML 워크로드처럼 GPU도 필요하고 고메모리도 필요한 경우, 노드 그룹을 일일이 만드는 건 지옥입니다. Karpenter는 알아서 다 띄워줍니다.
스팟 인스턴스(Spot Instance)를 적극 활용하고 싶을 때: Karpenter는 스팟 인스턴스가 회수(Interruption)될 때 빠르게 다른 스팟으로 갈아타는 능력이 탁월합니다.
노드 스케일링 속도가 너무 느려서 답답할 때: 이벤트나 타임세일 때 빠른 확장이 필수라면 선택이 아닌 필수입니다.
마치며
"노드 그룹을 관리하던 시대는 끝났습니다."
Karpenter는 단순히 빠른 오토스케일러가 아니라, EKS 운영의 패러다임을 **"인프라 관리"에서 "애플리케이션 요구사항 중심"**으로 바꿔주는 도구입니다.
아직 CA를 쓰고 계신다면, 개발계(Dev) 클러스터부터 천천히 Karpenter로 전환해 보시는 건 어떨까요? 클라우드 비용 청구서가 얇아지는 마법을 보실 수 있을 겁니다.
