lander.log

K8s HPA policies

3 min read

K8s HPA policies

정의 (Definition)

policies는 Horizontal Pod Autoscaler(HPA)가 레플리카를 조정할 때,주기당(scale window) 최대 증감량 을 제한하는 규칙 집합이며 behavior.scaleUp/scaleDown에 적용됩니다.

문제가 되는 배경 (Problem Context)

메트릭 스파이크나 일시적 노이즈에 HPA가 즉시 크게 반응하면, 파드 생성/삭제가 과도해지고 노드 오토스케일러까지 급격히 흔들릴 수 있습니다. “확장은 빠르게, 축소는 천천히” 같은 운영 의도를 코드로 고정하려면 속도 제한이 필요합니다.

핵심 메커니즘 (How it Works)

policies는 다음 형태로 정의합니다.

policies:
  - type: Percent   # 또는 Pods
    value: 50       # 퍼센트 또는 파드 수
    periodSeconds: 60
selectPolicy: Max   # (선택) Max/Min/Disabled
  • type: Percent(현재 레플리카의 비율) 또는 Pods(절대 개수)
  • value: type에 따른 상한값
  • periodSeconds: 상한이 적용되는 시간 창
  • selectPolicy: 여러 정책이 있을 때 최종 적용 방식

예:

  • scale up(Percent): 60초 동안 현재의 100%까지 증가 가능(10 → 20)
  • scale down(Pods): 60초 동안 최대 2개만 감소 가능

불변 조건과 보장 범위 (Invariants & Guarantees)

  • 보장: HPA가 레플리카를 변경할 때, policies가 정의한 “주기당 상한”을 넘는 변화는 발생하지 않습니다.
  • 비보장: 제한을 걸어도 메트릭이 장기간 높게 유지되면 결국 레플리카는 상한(maxReplicas)까지 도달할 수 있습니다.

비유 (Analogy)

policies는 급가속/급감속을 막는 가속 페달 리미터 입니다. 목적지는 같아도 변화율을 제한합니다.

실무적 함의 (Operational Implications)

  • scale down 은 캐시/상태/워밍업 비용이 큰 워크로드일수록 더 보수적으로 제한하는 편이 안정적입니다.
  • scale up 은 노드 확장 속도(노드 프로비저닝 지연)와 함께 설계해야 Pending 폭증을 줄일 수 있습니다.

주의사항 / 오해 (Pitfalls & Misconceptions)

  • policies만으로 플래핑이 완전히 없어지지 않습니다. (완충은 K8s HPA stabilizationWindowSeconds가 담당)
  • 제한을 과도하게 걸면 부하 상승 시 SLO를 위반할 수 있습니다(확장이 “느려지는” 것이기 때문).

References

Recent Posts