k8s HPA 동작 방식 및 이슈들 정리

DevOps & SRE/Docker & kubernetes

k8s HPA 동작 방식 및 이슈들 정리

seungh0 2023. 5. 16. 22:13

HPA (Horizontal Pod AutoScaling) 도입 배경

운영하는 플랫폼이 버스트성으로 들어오는 트래픽들이 많고, 점점 많아질 예정이어서 이러한 버스트성 트래픽을 k8s 환경에서 효율적으로 대응하기 위해서 HPA을 검토하였음.

HPA (Horizontal Pod AutoScaling) 이란?

Workload Resource를 자동으로 업데이트 하며, 워크로드의 크기를 수요에 맞게 자동으로 스케일링하는 것을 목표로 함.
즉 k8s에서 AutoScaling의 역할을 수행.

HPA 동작 방식

k8s는 HPA을 간헐적으로 실행되는 컨트롤 루프 형태로 구현했다.
- 이 말은 지속적으로 모니터링해서 워크로드를 변경하지 않고, 주기(default 15초)별로 체크하는 형태.
- 각 주기마다, Controller Manager는 각 HPA에 정의에 지정된 메트릭 지표에 대해서 리소스를 조회한다.
- scaleTargetRef에 정의된 타겟 리소스를 찾은 후, 파드를 선택해서 메트릭 API로부터 메트릭을 수집하는 형태로 동작.

오토스케일링 기준 메트릭 종류

리소스 메트릭 지원

type: Resource
resource:
  name: cpu
  target:
    type: Utilization
    averageUtilization: 60

ex) HPA 컨트롤러는 스케일링 대상에서 파드의 평균 사용률을 60%로 유지한다.

컨테이너 리소스 메트릭

type: ContainerResource
containerResource:
  name: cpu
  container: application
  target:
    type: Utilization
    averageUtilization: 60

ex) 모든 파드의 application 컨테이너에 있는 CPU의 평균 사용률이 60%가 되도록 대상을 조정

커스텀 메트릭

요청량 등을 커스텀한 메트릭을 기준으로 조정할 수 있음.
https://kubernetes.io/ko/docs/tasks/run-application/horizontal-pod-autoscale-walkthrough/#다양한-메트릭-및-사용자-정의-메트릭을-기초로한-오토스케일링

HPA 알고리즘

HPA 컨트롤러는 desired 메트릭 갑과 current 메트릭 값 사이의 비율로 작동함.

desiredReplicas = currentReplicas * ( currentMetricValue / desiredMetricValue )

ex) 현재 replicas: 10, cpu usages: 3.0인 상황에서 metrics 기준을 2.0인 경우 -> 10 * (3000 / 1000) = 15개
ex) 현재 replicas: 20, cpu usages: 1.0ms인 상황에서 metrics 기준을 2.0인 경우 -> 20 * (1.0 / 2.0) = 10개

Behavior

갑자기 너무 많은 파드가 scale-out 혹은 scale-in 되는 것을 방지하기 위해서 사용

behavior:
    scaleDown:
      stabilizationWindowSeconds: 300
      policies:
        - type: Percent
          value: 100
          periodSeconds: 15
      selectPolicy: Max
    scaleUp:
      stabilizationWindowSeconds: 0
      policies:
        - type: Pods
          value: 4
          periodSeconds: 15
        - type: Percent
          value: 100
          periodSeconds: 15
      selectPolicy: Max

scale-out: 4개 혹은 replicas의 100% 중 큰 수 초과로 15초 동안 scale-up이 되는 것을 방지.
scale-in: replicas의 100% 초과로 15초동안 scale-down이 되는 것을 방지.
stabilizationWindowSeconds
- 스케일링에 사용되는 메트릭이 계속 변동할 때 레플리카 수의 흔들림을 제한하기 위해 사용됨.
- behavior.scaleDown.stabilizationWindowSeconds: 300의 의미는 5분 동안 scale-down이 되기 위한 조건을 유지해야 scale-down을 해준다는 의미

HPA 도입하면서 발생한 이슈들

scale-out 시점에 예상보다 많은 replicas가 생기는 현상

HPA scale-out으로 인해 새로운 파드가 뜨면서, 초기에 CPU 사용률이 높아서, 해당 지표가 HPA에 영향을 줌 -> 예상보다 많은 Replicas로 scale-out 되는 현상이 발생함.

해결 방안

coolDownPeriodSeconds: 90
Pod 생성 초기에 Ready 상태가 된 후 설정한 시간(초)만큼 HPA 계산에서 제외되도록 하는 설정.
- 대략 컨테이너의 애플리케이션이 안정화돼서 뜨는 시간 정도로 주면 괜찮아 보임.
cf) HPA 컨트롤러는 메트릭 기준이 되는 리소스는 READY 상태인 파드들을 기준으로 계산함.

Cold Start 이슈

scale-out 되어 신규로 생성된 파드에 대한 처음 요청들이 느리게 처리되는 현상. (HPA만의 문제는 아니지만, HPA 사용 시 특히 이슈가 될 수 있음)

해결 방안

웜업 추가
- warm-up 과정은 postStart 과정에서 처리하도록 하였음.
- 혹은 readiness 과정에서 처리하고, readiness.initialDelaySeconds을 웜업을 할 수 있는 시간으로 충분히 늘리고 해당 시점에 웜업을 해도 좋을 거 같음.
- → 그렇지만 애플리케이션이 뜨는 시간은 점점 늘어날 텐데, 해당 설정 값을 변경해 나가는 것은 귀찮아서, postStart 시점에 웜업을 수행하였음.

Pod Lifecycle

cf) k8s에서 postStart의 호출 이후, 성공 시 liveness Probe & readiness Probe가 수행됨.

저작자표시