lander.log

K8s HPA behavior

4 min read

K8s HPA behavior

정의 (Definition)

behavior는 Horizontal Pod Autoscaler(HPA)가 scale up/down을 “얼마나 빨리, 얼마나 크게” 수행할지 를 제어하는 정책 집합이며, 목표 레플리카 계산 로직 자체를 바꾸는 필드는 아닙니다.

문제가 되는 배경 (Problem Context)

HPA는 메트릭 변동에 따라 레플리카를 조정합니다. 이때 변동성이 큰 메트릭/지표 노이즈가 있으면 파드 수가 짧은 시간에 늘었다 줄었다 하는 플래핑(flapping) 이 발생해, API 서버/스케줄러/노드 오토스케일러까지 연쇄적으로 흔들릴 수 있습니다.

핵심 메커니즘 (How it Works)

behavior는 scaleUp과 scaleDown으로 분리되며, 각 방향에 대해:

  • 안정화 창: stabilizationWindowSeconds로 과거 추천치(recommendation)를 고려해 급격한 왕복을 완화합니다. (세부: K8s HPA stabilizationWindowSeconds)
  • 증감 속도 제한: policies로 “주기당 최대 증가/감소”를 제한합니다. (세부: K8s HPA policies)

예시는 다음과 같습니다.

behavior:
  scaleUp:
    stabilizationWindowSeconds: 0
    policies:
      - type: Percent
        value: 100
        periodSeconds: 60
  scaleDown:
    stabilizationWindowSeconds: 300
    policies:
      - type: Percent
        value: 50
        periodSeconds: 60

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

  • 보장: behavior는 HPA가 레플리카를 바꾸는 “속도/완충”만 제어합니다.
  • 비보장: HPA가 정한 레플리카로 실제로 스케줄링이 가능한지(노드 용량/쿼터/어피니티 등)는 보장하지 않습니다.
  • 경계: behavior는 minReplicas/maxReplicas의 상·하한을 대체하지 않습니다.

비유 (Analogy)

behavior는 크루즈 컨트롤에서 가속/감속을 “바로 밟는 것”이 아니라 가속 페달의 최대 응답 속도와 브레이크 강도 를 제한하는 장치에 가깝습니다.

실무적 함의 (Operational Implications)

  • 스케일 다운은 보수적으로: 캐시/워밍업이 필요한 워크로드는 scaleDown.stabilizationWindowSeconds를 길게 두는 편이 서비스 지연을 줄입니다.
  • 노드 오토스케일러와 정합: HPA가 급격히 늘리면 노드 오토스케일러가 따라오지 못해 Pending이 늘 수 있으므로 scaleUp.policies로 상승률을 제한하는 설계가 필요합니다.

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

  • “behavior를 넣으면 안정적이다”: 메트릭 자체가 불안정하면 완화는 되지만, 원인(메트릭 설계/수집 지연/집계 방식)이 해결되지는 않습니다.
  • scaleUp 안정화 창 남용: 트래픽 급증에 즉시 대응해야 하는 경우 scaleUp.stabilizationWindowSeconds를 과도하게 키우면 SLO 위반으로 이어질 수 있습니다.

References

Recent Posts