쿠버네티스 오토스케일링 계층 — HPA · KEDA · Karpenter

HPA·KEDA·Karpenter 는 모두 쿠버네티스 오토스케일링 구성요소입니다. 셋이면 역할이 겹칠 것 같지만, HPA 와 KEDA 는 파드 개수를 조절하고 Karpenter 는 노드(EC2)를 늘리는 식으로 서로 다른 층에서 동작합니다. 하나가 파드를 늘리면 다음이 노드를 띄우는 식으로 이어집니다.

Pod를 늘리는 층 — HPA와 KEDA

HPA 는 CPU·메모리 사용률을 보고 Pod replicas 를 조절하며, metrics-server 가 있어야 동작합니다.

KEDA 는 그 대신 외부 메트릭을 봅니다. SQS 큐 깊이, Kafka lag, Prometheus 쿼리 같은 걸 기준으로 Pod 를 늘리는 이벤트 드리븐 방식입니다.

갈리는 지점은 “무엇을 보고 늘리느냐” 하나입니다. 큐가 쌓이면 워커를 늘리고 다 처리하면 0 으로 줄이는 배치성 워크로드라면, CPU 사용률로는 “큐가 쌓였다” 를 표현할 수 없으니 KEDA + 큐 조합이 맞습니다.

노드를 늘리는 층 — Karpenter

Pod 를 늘려 봐야 노드에 자리가 없으면 그대로 Pending 이고, 여기서부터가 Karpenter 의 몫입니다.

KEDA 는 “Pod 를 더 만들어라” 까지만 합니다. 그 Pod 가 뜰 자리(노드)는 Karpenter 가 만듭니다. 층이 나뉘어 있어서 서로 안 부딪힙니다. Pod 층은 KEDA/HPA, 노드 층은 Karpenter.

scale-to-zero의 cold start

KEDA 는 Pod 를 0 까지 줄일 수 있습니다(scale-to-zero). 비용은 좋은데, 큐가 비었다가 첫 요청이 올 때 Pod 가 없어서 지연(cold start)이 생깁니다.

완화하는 방법이 몇 가지입니다.

• minReplicaCount: 1 로 최소 하나는 항상 유지
• cooldownPeriod 를 조정해 너무 빨리 0 으로 안 가게
• ScaledJob 으로 Pod 를 Job 형태로 실행 — 요청이 있을 때만 생성

0 까지 줄여 비용을 아끼는 것과 첫 요청 지연은 맞바꾸는 관계입니다. 요청이 얼마나 자주 오는지, 지연을 얼마나 견딜 수 있는지에 따라 값을 정합니다.

참고

• KEDA 문서