HorizontalPodAutoscaler(HPA) — requests 대비 사용률로 replica 수를 조절한다
Kubernetes HorizontalPodAutoscaler 및 NetworkPolicy 공식 문서·운영 가이드 종합 (웹 리서치, 2026) — GKE 공식 문서(horizontalpodautoscaler), Calico/Kubernetes 커뮤니티 NetworkPolicy 가이드 GKE 공식 문서 Horizontal Pod autoscaling
이 모듈을 다 읽으면
- HPA의 CPU 사용률 계산이 k8s-learn-05의 requests를 기준으로 한다는 것을 설명할 수 있다
- stabilizationWindowSeconds가 왜 존재하는지(scale up/down 진동 방지) 설명할 수 있다
k8s-learn-05에서 다룬 requests(스케줄러 배정 기준)를 전제로, HPA가 실제 사용량을 그 requests와 비교해 replica 수를 자동으로 늘리고 줄이는 원리를 정리한다.
CPU 사용률 = 실제 사용량 / requests
HPA는 metrics-server가 각 노드의 kubelet으로부터 수집한 CPU·메모리 사용량 지표를 근거로 스케일링을 결정한다. 중요한 것은 이 '사용률'이 절대적인 CPU 수치가 아니라 k8s-learn-05에서 다룬 requests 대비 백분율이라는 점이다 — 컨테이너가 500m을 requests로 걸어두고 실제로 250m을 쓰고 있다면 사용률은 50%다. 즉 HPA를 쓰려면 requests를 반드시 설정해둬야 하고, requests를 잘못 잡으면(너무 낮게/높게) HPA의 스케일링 판단 자체가 왜곡된다.
핵심 포인트
- CPU 사용률 = 실제 사용량 ÷ k8s-learn-05의 requests(절대 수치가 아닌 requests 대비 백분율)
- HPA가 제대로 동작하려면 requests가 반드시 설정돼 있어야 함 — requests를 잘못 잡으면 스케일링 판단 자체가 왜곡됨
stabilizationWindowSeconds — 진동을 막는 완충 장치
부하가 오르내릴 때마다 즉시 replica 수를 바꾸면, 순간적인 부하 스파이크에도 스케일업했다가 곧바로 다시 스케일다운하는 진동(flapping)이 생길 수 있다. HPA의 behavior 필드에 scaleUp/scaleDown 정책을 지정할 수 있는데, 각각의 stabilizationWindowSeconds는 '최근 이 시간 동안 계산된 추천값들 중 가장 보수적인 값을 택하겠다'는 완충 구간이다 — 예를 들어 scaleUp은 30초, scaleDown은 300초(5분)로 비대칭하게 잡는 것이 흔한 패턴이다. scaleUp은 빠르게 반응하되(짧은 윈도우), scaleDown은 신중하게(긴 윈도우) 하는 게 일반적인 이유는, 너무 빨리 줄였다가 부하가 다시 튀면 그 사이 서비스 품질이 떨어지는 게 더 위험하기 때문이다.
핵심 포인트
- stabilizationWindowSeconds: 최근 지정 시간 동안의 추천값 중 가장 보수적인 값을 택해 진동(flapping) 방지
- scaleUp은 짧게(빠른 반응), scaleDown은 길게(신중한 축소) 비대칭 설정이 흔한 패턴 — 너무 빨리 줄였다가 부하가 다시 튀는 위험 회피