k8s autoscaling 1. hpa (Horizontal Autoscaler)

1. 서론

 

쿠버네티스에서는 Horizontal Pod Autoscaler(HPA), Vertical Pod Autoscaler(vpa), Cluster Autoscaler(CA)

이렇게 크게 3가지 오토스케일링 기능을 사용할 수 있습니다.

한개씩만 해도 내용이 꽤 되기때문에 오늘부터 하나씩 포스팅해보도록 하겠습니다.

 

2.hpa ( horizontal pod auto scaler)

hpa는 이름 그대로 pod를 수평적으로 스케일링 아웃합니다.

 

pod의 cpu/memory 사용량을 (혹은 사용자 정의 메트릭을) 관찰하면서 pod의 평균 cpu 사용량이 일정 수치에 가까워지도록  레플리카 개수를 조정합니다.

 

예를 들어 cpu 사용량을 scaling 기준으로 보기로 했다면 cpu 사용량을 관찰하다가 pod들의 평균적인 리소스가 부족해지면 pod의 개수(replica)를 늘립니다. 또 리소스 사용량이 일정 기준 이하로 낮아지면 다시 개수를 줄입니다. 아주 직관적이죠? cloud에서 일반 인스턴스를 scaling하는 방식과 비슷합니다

 

 replication controller, deployment, replicaset, statefulset 등의 워크로드 리소스를 scale out할 수 있고. 크기를 조정할 수 없는 daemonset등은 hpa로 scaling이 불가능 합니다.

 

2.1. replica 개수 계산 방식

ceil [현재 pod 개수 * (현재 metric / 원하는 metric)]

 

실제로 pod가 scaling 될때 위와 같은 계산식을 이용하여 늘리거나 줄일 pod의 숫자를 결정합니다.

숫자가 1에 가깝다면 현재 상태를 유지하는데요, default로 설정된 임계치는 0.1로 해당 값이 1.1 이상, 혹은 0.9 이하라면 scaling됩니다.

이 값은 -horizontal-pod-autoscaler-tolerance 를 사용해서 수정할 수 있습니다. 만약 이 수치를 올린다면 scaling이 덜 자주 일어나겠죠. 

 

3. 설치하기

3.1 metric server

hpa를 사용하기 위해서는 제일 먼저 metric 서버가 필요합니다.

Metric 서버는 api를 통해서 컨테이너 CPU 및 메모리 사용량과 같은 리소스 사용량 메트릭을 제공하는데요, hpa는 이 api를 호출해서 Metric 서버에서 제공해주는 리소스 사용량을 기준으로 scaling 여부를 판단합니다.

 

Metric api는 kubectl top 커맨드를 통해서 직접 요청할 수도 있습니다.

이런식으로 cpu, memory의 사용량을 간단하게 확인할 수 있습니다.

 

Metric server는 k8s 클러스터에 기본적으로 탑재되있지않기 때문에 따로 설치가 필요한데요

 

Mertic-server github에서 제공하는 config 파일을 이용해 간단하게 설치할 수 있습니다. 필요하다면 파일을 내려받은 뒤 config 파일을 수정하고 배포하면 됩니다.

kubectl apply -f https://github.com/kubernetes-sigs/metrics-server/releases/download/v0.4.1/components.yaml

 

아주 쉽네요! get 커맨드로 파드 잘 뜬 것을 확인할 수 있습니다.

 

3.2 hpa 생성

Hpa pod 파드는 아래처럼 커맨드로 간단하게 생성할 수 있습니다.

kubectl autoscale deployment practice_deployment --cpu-percent=80 --min=2 --max=10

위 hpa는 practice_deployment라는 이름의 deployment의 평균 cpu 사용량을 80퍼센트에 맞추기 위해서 scaling을 합니다. 최소 pod의 개수는 2개, 최대 pod의 개수는 10개로 지정해놓았네요.

Get hpa command를 사용하면  방금 띄운 hpa의 상태를 확인할 수 있습니다.

Target 사용률이 80%, 현재 사용률은 4%인 것을 볼 수 있습니다. Min pod를 2로 설정해놓았기때문에 현재 replica 수도 2네요.

 

기본적인 설정 이외에 다른 항목들을 추가하고싶다면 yml파일을 이용하면 됩니다.

 

hpa-config.yml
---
apiVersion: autoscaling/v2beta2
kind: HorizontalPodAutoscaler
metadata:
  name: hpa-practive
  namespace: default
spec:
  scaleTargetRef:
    apiVersion: apps/v1
    kind: Deployment
    name: hpa-practive
  minReplicas: 1
  maxReplicas: 10
  behavior:
    scaleDown:
      stabilizationWindowSeconds: 300
      policies:
      - type: Percent
        value: 10
        periodSeconds: 300
      - type: Pods
        value: 1
        periodSeconds: 120 
      selectPolicy: Min
  metrics:
    - type: Resource
      resource:
        name: cpu
        target:
          type: Utilization
          averageUtilization: 50 # scale up 기준 값.

---

 

Kubectl apply -f hpa-config.yml

위에서 설정했던 min replica, max replica, averageUtilization 외에 여러가지 설정값이 있는데요 한개씩 설명해보겠습니다.

 

4. configuration

4.1 metric

hpa에서 사용할 수 있는 metric은 resource metric, 사용자 정의 metric, 외부 metric 이렇게 크게 세가지 종류가 있습니다.

resource metric은 위에서 봤던 metric server에서 제공하는 pod의 resource에 대한 metric이고 가장 주로 사용합니다,

 

  metrics:
    - type: Resource
      resource:
        name: cpu
        target:
          type: Utilization
          averageUtilization: 50 # scale up 기준 값.

 먼저 resource는 cpu, memory 중에 선택을 할 수있습니다.

 

사실 안정화된 버전인 autoscaling/v1에서는 cpu만 설정이 가능합니다. 베타버전인 autoscaling/v2beta2 에서는 cpu와 memory, 나아가 설명할 사용자정의 metric까지 지원합니다. 저는 autoscaling/v2beta2 을 사용했는데 크게 문제되는 점은 (아직) 발견하지 못했습니다.그렇지만 만일을 대비해 안정성이 중요한 시스템이라면 cpu만 메트릭으로 쓰는 것이 좋겠죠.

 

위 설정값에서는 type이 Utilization, averageUtilzation이 50인데요, 이 말은 cpu(혹은 memory)의 평균 사용량을 50퍼센트로 유지하겠다는 뜻입니다. type을 value로, averageUtilization을 averageValue로 수정하면 퍼센테이지가 아니라 절대적인 value로 metric을 비교할 수 있습니다.

 

위에서 resource metric이 pod의 resource라고 했지만 pod가 아니라 container의 resource를 metric으로 사용하는 것도 가능합니다.

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

위처럼 설정하면 한 pod에 2개 이상의 container가 존재할때 원하는 container를 기준으로 scaling이 가능합니다.

 

사용자 정의 metric은 metric server가 제공하는 api가 아닌 외부의 metric solution 공급 업체에서 제공하는 metric 입니다.

현재 Prometheus,  Microsoft Azure , Datadog Cluster 등에서 metric을 제공 받을 수 있다고 합니다.여기에서 자세한 정보를 볼 수 있습니다.

 

외부 metric은 k8s 오브젝트와 관련이 없는 metric입니다. 사용자 정의 metric을 제공하는 외부 metric solution에서 제공하는 경우가 있다고 합니다. 하지만 보안상의 이유로 외부 metric보다는 사용자정의 metric을 사용하는 것이 바람직하다고 하네요.

 

* 주의할 점

- 만일 metric을 여러개 사용했다면 k8s는 여러 metric에서 계산된 replica 개수 중에 가장 큰 것을 사용합니다.

- 모종의 이유로 pod에서 metric이 수집되지않는 경우도 생길텐데요 이때는 해당 pod때문에 pod들의 평균이 크게 바뀌지않도록 보수적으로 평균을 계산한다고 합니다.

 

4.2 behavior

 

behavior는 실제로 pod가 scale in, 혹은 scale out되는 방법 것입니다.

예시에는 scaleDown만 있는데요, 같은 방식으로 scaleUp도 가능합니다.

  behavior:
    scaleDown:
      stabilizationWindowSeconds: 300
      policies:
      - type: Percent
        value: 10
        periodSeconds: 30
      - type: Pods
        value: 1
        periodSeconds: 120 
      selectPolicy: Min

 

* stabilizationWindowSeconds 

 

k8s 한글 문서에서는 stabilizationWindowSeconds를 안정화 윈도우로 부르더라구요.. 어색하지만 저도 편의를 위해 안정화 윈도우라고 부르겠습니다. 안정화윈도우는 메트릭이 계속해서 변할때 relica의 개수가 너무 자주 변경되지않도록( flapping 현상) 제한하기 위해서 사용합니다. 

위처럼 안정화 윈도우가 300으로 지정된 경우에는 지난 5분동안의 상태를 모두 계산해서 그 중 제일 높은 값을 사용해 scaling합니다.

stabilizationWindowSeconds이 0이라면 scaling이 필요하다는 계산을 하자마자 바로 scaling을 시작합니다.

 

* policy

 

policy에서 구체적인 전략을 설정해줄 수 있습니다.

위의 예시에서 scaleDown의 type이 Percent, value가 10인 policy가 있는데요. 이말은 한번에 pod 개수의 10%씩 줄인다는 말입니다. 그리고 period second가 30인 것은 30초에 한번씩 scale down을 하라는 뜻입니다.

예를들어 현재 replica가 총 20개이고 4개의 replica를 줄이기로 계산을 했다면 30초에 한번씩 replica의 10%를 terminate 시킵니다.

 

그 아래 예시에서는 type이 pod, value가 1, period second가 120입니다. 이 policy는 120초에 한번에 pod 1개씩을 줄인다는 뜻이겠죠.

 

* selectPolicy

 

그렇게 이렇게 policy가 2개 이상 있을때는 그중 어떤 policy를 선택해야할까요?

위 예시에서는 selectPolicy의 value가 min으로 되어있습니다. 두 policy로 각각 계산한 scaling할 replica의 개수 중에 가장 더 작은 값을 선택하겠다는 뜻입니다.

 

selectPolicy는 min, max, disabled 중에 선택할 수 있고 default값은 max입니다. disabled를 사용하면 해당 방향으로의 scaling이 전혀 이루어지지않기때문에 조심해서 사용을 해야합니다.

 

 

 

 

 

참고 : kubernetes.io/ko/docs/tasks/run-application/horizontal-pod-autoscale/

Horizontal Pod Autoscaler

kubernetes.io/docs/tasks/run-application/horizontal-pod-autoscale-walkthrough/