파드는 터지고 노드는 남아도는 이 상황, 어디서부터 손대야 할까
트래픽이 몰리면 파드가 죽고, 한산해지면 노드가 놀고 있다. 쿠버네티스를 운영하다 보면 누구나 한 번쯤 겪는 딜레마다. 오토스케일링을 도입하려고 검색하면 HPA, VPA, Cluster Autoscaler, Karpenter까지 선택지가 쏟아진다. 이름은 비슷해 보이는데 역할이 전부 다르다.
이 글을 끝까지 읽으면 네 가지 오토스케일러의 작동 원리와 차이점을 명확히 이해하고, 워크로드 특성에 맞는 조합을 직접 설계할 수 있다. 비용 절감과 안정성, 두 마리 토끼를 잡는 출발점이 바로 여기다.
쿠버네티스 오토스케일링이 복잡해진 진짜 이유
스케일링 대상이 두 계층으로 나뉜다
가장 흔한 혼란의 원인은 단순하다. 파드 레벨 스케일링과 노드 레벨 스케일링이 별개의 메커니즘이라는 점을 간과하기 때문이다. 파드 스케일링은 애플리케이션 복제본 수나 리소스 할당량을 조절한다. 노드 스케일링은 그 파드가 올라갈 서버 자체를 늘리거나 줄인다.
레스토랑으로 비유하면 이렇다. 손님이 밀려올 때 직원(파드)을 더 투입하는 게 HPA다. 각 직원에게 더 넓은 작업 공간(CPU/메모리)을 배정하는 게 VPA다. 테이블(노드) 자체가 부족하면 Cluster Autoscaler나 Karpenter가 홀을 넓혀준다.
네 도구의 포지션 맵
- HPA(Horizontal Pod Autoscaler) — 파드 수를 수평으로 늘리고 줄임. CPU·메모리·커스텀 메트릭 기반
- VPA(Vertical Pod Autoscaler) — 개별 파드의 CPU·메모리 request/limit을 자동 조정
- Cluster Autoscaler — Pending 파드가 생기면 노드 그룹 단위로 노드 추가. 유휴 노드는 제거
- Karpenter — AWS 네이티브 노드 프로비저너. 노드 그룹 없이 파드 요구사항에 맞는 인스턴스를 즉시 선택·생성
쿠버네티스 공식 문서에서는 HPA와 VPA를 워크로드 리소스 관리의 핵심 컴포넌트로 분류한다. 이 두 가지가 파드 안쪽을, 나머지 두 가지가 파드 바깥쪽을 담당한다고 이해하면 전체 그림이 잡힌다.
HPA vs VPA, 파드 스케일링에서 어떤 걸 먼저 적용해야 할까
수평 확장이 기본값인 이유
대부분의 웹 서비스나 API 서버는 HPA가 정답이다. Stateless 워크로드는 복제본을 늘리면 처리량이 선형에 가깝게 증가하고, 축소도 즉각적이다. kubectl autoscale deployment my-app --cpu-percent=60 --min=2 --max=20 한 줄이면 기본 설정이 완료된다.
반면 VPA는 파드를 재시작해야 리소스가 반영되는 구조적 한계가 있다. 그래서 ML 학습 잡이나 단일 인스턴스 데이터베이스처럼 수평 확장이 불가능한 워크로드에 적합하다. 실제 적용 사례를 살펴보면, 배치 처리 파이프라인에서 VPA를 적용해 메모리 request를 자동 튜닝한 뒤 리소스 낭비를 40% 가까이 줄인 팀도 있다.
동시 사용 시 주의점
HPA와 VPA를 같은 디플로이먼트에 동시 적용하면 충돌이 생길 수 있다. HPA가 CPU 메트릭으로 스케일링하는데 VPA가 CPU request를 변경하면 기준 자체가 흔들린다. VPA 공식 저장소에서도 CPU 기반 HPA와의 병행을 권장하지 않는다. 굳이 함께 쓰려면 HPA는 커스텀 메트릭을, VPA는 메모리만 조정하도록 분리하는 전략이 필요하다.
Cluster Autoscaler와 Karpenter, 노드 스케일링의 세대교체
노드 그룹이라는 병목
Cluster Autoscaler는 쿠버네티스 생태계의 오랜 표준이다. 하지만 근본적인 한계가 하나 있다. 사전에 정의된 노드 그룹(ASG) 안에서만 스케일링한다는 점이다. GPU 워크로드용, 범용 워크로드용, 메모리 집약형 워크로드용 노드 그룹을 각각 만들어야 하고, 새로운 인스턴스 타입을 추가하려면 노드 그룹 설정을 수정해야 한다.
많은 팀이 처음에는 노드 그룹 3~4개로 시작하지만, 서비스가 성장하면서 10개, 20개로 불어나는 경우가 흔하다. 관리 복잡도가 기하급수적으로 증가한다.
Karpenter가 바꿔놓은 게임의 규칙
Karpenter는 이 문제를 정면으로 해결한다. 노드 그룹이라는 개념 자체를 없앴다. Pending 파드의 resource request, nodeSelector, toleration 등을 분석해서 가장 적합한 인스턴스 타입을 실시간으로 선택한다. 스팟 인스턴스 활용도 자연스럽게 통합되어 있어서, 스팟과 온디맨드 인스턴스의 비용 차이를 극대화하기에 유리하다.
노드 추가 속도도 차이가 크다. Cluster Autoscaler가 ASG를 거쳐 스케일링 결정까지 보통 2~5분 걸리는 반면, Karpenter는 EC2 Fleet API를 직접 호출해 60초 이내에 노드를 띄우는 경우가 많다. 다만 Karpenter는 AWS 전용이라는 점을 반드시 기억해야 한다. GCP나 Azure 환경이라면 Cluster Autoscaler가 여전히 유일한 선택지다.
잘못된 조합이 오히려 비용을 늘리는 함정
과도한 스케일링 설정의 역효과
오토스케일링을 도입했는데 오히려 비용이 올라갔다는 사례가 의외로 많다. 원인은 대부분 비슷하다. HPA의 minReplicas를 너무 높게 잡거나, Cluster Autoscaler의 scale-down-delay를 지나치게 길게 설정한 경우다. 트래픽이 빠진 뒤에도 노드가 30분 넘게 유지되면 그 자체가 낭비다.
팁: Cluster Autoscaler의
--scale-down-unneeded-time기본값은 10분이다. 워크로드 패턴에 따라 5분까지 줄이되, 잦은 스케일 업/다운 반복(플래핑)이 발생하지 않는지 모니터링해야 한다.
멀티 클라우드·하이브리드 환경에서의 제약
Karpenter의 장점에 끌려 무작정 도입했다가 벤더 종속에 발목 잡히는 경우도 있다. 조직이 멀티 클라우드 전략을 추진 중이라면 Cluster Autoscaler의 클라우드 중립성이 오히려 강점이 된다. 모든 도구에는 트레이드오프가 존재하며, 기술 선택은 현재 인프라 환경과 팀의 운영 역량에 맞춰야 한다.
워크로드 특성별 오토스케일링 조합 추천
세 가지 대표 시나리오
- 웹 API 서버(Stateless) — HPA(CPU 70% 기준) + Karpenter(AWS) 또는 Cluster Autoscaler. 가장 보편적이고 효과가 즉각적인 조합이다
- ML 추론 서비스 — HPA(커스텀 메트릭: 큐 길이, 지연시간) + Karpenter(GPU 인스턴스 자동 선택). GPU 노드는 비싸므로 빠른 스케일 다운이 핵심
- 배치/데이터 파이프라인 — VPA(메모리 자동 튜닝) + Cluster Autoscaler. 수평 확장보다 단일 파드 리소스 최적화가 효율적
설정 시작점 예시
HPA 설정의 실질적인 출발점은 이렇다. targetCPUUtilizationPercentage: 65, minReplicas: 2, maxReplicas: 현재 피크 대비 3배. 여기서 시작해서 실제 메트릭을 관찰하며 2주 단위로 조정하는 방식이 실무에서 가장 안정적이다. 노드 사이징과 스팟 전략까지 함께 최적화하면 TCO를 절반 가까이 줄인 사례도 보고된다.
정리하며
HPA와 VPA는 파드 레벨, Cluster Autoscaler와 Karpenter는 노드 레벨을 담당한다. 대부분의 워크로드는 HPA + 노드 오토스케일러 조합으로 시작하면 된다. Karpenter는 빠르고 유연하지만 AWS 전용이라는 제약을 잊지 말아야 한다.
오늘 당장 할 수 있는 한 가지가 있다. 운영 중인 클러스터에서 kubectl top pods와 kubectl top nodes를 실행해보자. request 대비 실제 사용량의 괴리가 보이면, 그것이 오토스케일링 도입의 출발 신호다. 리소스 낭비 현황을 수치로 파악한 뒤, 이 글의 시나리오별 조합을 참고해 첫 번째 HPA부터 적용해보길 권한다.