HPA와 Metrics Server

HPA

일반적으로 Deployment나 Statefulset 같은 워크로드를 사용하면 레플리카 수를 지정하여 가용성 있게 운영할 수 있게 해 준다. 그러나 레플리카 수를 과도하게 지정하여 리소스 낭비를 하는 경우가 발생하고 반대로 서비스에 과부하가 걸려 지정한 레플리카 수로 처리하기 벅찬 경우가 발생한다.

 

그래서 쿠버네티스에서는 워크로드 내에서 발생하는 메트릭 값을 기준으로 레플리카 수를 동적으로 조정하는 기능인 HPA를 제공하고 있다.

 

HPA는 K8s에서 워크로드에 대한 부하가 발생하면 워크로드에 해당하는 파드의 개수를 수요에 맞게 늘려준다.

 

특징

• HPA는 간헐적으로 컨트롤 루프 형태로 구현. → 기본적으로 15초마다 지정된 워크로드의 리소스를 확인한다.
  • 주기적으로 scaleTargetRef에 정의된 타켓 리소스를 찾고 .spec.selector를 통해 파드를 선택
• HPA가 정상적으로 동작하기 위해서는 리소스 사용량을 확인해야하지만 이는 기본 K8s API에서 처리할 수 없음 따라서 Metrics Server를 통해 Aggregation Layer를 추가하여 메트릭 API까지 확장된 K8s API를 사용해야 한다.

 

흐름

1. Metrics Server를 사전에 구축한다.
2. 사용자는 CLI, 매니페스트를 통해 HPA를 생성한다.
3. HPA는 주기적으로 컨트롤 루프를 통해 리소스 상태 확인을 위한 요청을 K8s API에게 요청한다.
4. 요청을 받은 K8s API는 Metrics Server에게 요약 API(모든 메트릭 정보를 요청하면 과부하가 발생하기 때문에 요약 정보만을 받는다.)를 요청한다.
5. 요약 API는 각 노드의 kubelet을 통해 리소스 상태를 조회한다.
6. kubelet에 포함된 cAdvisor 데몬이 컨테이너 런타임에 대한 리소스 상태를 수집하고 있고 해당 정보를 반환한다.
7. 응답을 받은 HPA는 리소스 상태를 기반으로 스케일링을 할지, 말지 결정한다.

 

스케일링하는 기준

$$원하는레플리카수 = 현재레플리카수 \times (현재메트릭값 \div 원하는메트릭값) $$

→ 여기서 메트릭 값은 백분위로 이뤄진 상대 값일 수 있고 절대적인 원시 값일 수 있다.

 

Metrics Server

위에서도 언급했듯이 K8s 내에서 Metrics API는 기본적으로 제공하고 있지 않다.

 

따라서 K8s API를 확장시킬 수 있게 해주는 Aggregation Layer를 통해 K8s API를 확장시켜야 한다. Aggregation Layer를 통해 Metrcis API를 사용할 수 있게 해주는 것이 Metrcis Server이다.

Aggregation Layer

→ 기본 K8s API를 확장시킬 수 있게 해 준다. 이를 위해서 APIService 오브젝트와 Extension API Server(컨트롤러와 쌍을 이루는 e.g. deployment )를 별도로 구축해야 한다.

 

확장된 API가 구축이 완료되면 해당 API에 관한 요청이 오면 Extension API Server로 전달받게 된다.

대표적으로 Metrics Server가 HPA를 위해 다음과 같은 구조를 가지게 된다.

 

따라서 APIService와 Extension API Server를 기반으로 Metrics Server가 구축되고 최종적으로 아래와 같은 아키텍처를 가지게 된다.

 

1. APIService를 통해 특정 API를 등록한다.

2. 이후 해당 API로 요청이 들어오면 Metrics Server가 Storage에서 메트릭을 찾게 되는데

3. 메트릭은 Scraper를 통해 특정 간격 동안 지정한 대상으로부터 수집한 메트릭이다.

 

HPA 사용하기

HPA는 간단하게 kubectl로 사용할 수 있고 매니페스트를 통해서 다양한 기능과 함께 HPA를 사용할 수 있다.

kubectl로 사용하기

kubectl autoscale (-f FILENAME | TYPE NAME | TYPE/NAME) [--min=MINPODS] --max=MAXPODS [--cpu-percent=CPU] [options]

kubectl autoscale deployment foo --min=2 --max=10 (기본 autoscale 정책이 적용됨.)
kubectl autoscale rc foo --max=5 --cpu-percent=80

매니페스트로 사용하기

apiVersion: autoscaling/v2
kind: HorizontalPodAutoscaler
metadata:
  name: php-apache
spec:
  scaleTargetRef:
    apiVersion: apps/v1
    kind: Deployment
    name: php-apache
  minReplicas: 1
  maxReplicas: 10
  metrics:
  - type: Resource
    resource:
      name: cpu
      target:
        type: Utilization
        averageUtilization: 50

 

Flapping 현상 막기

HPA는 동적인 메트릭 기반으로 동작하기 때문에 레플리카의 수가 매번 달라지게 되는 현상이 발생하는데 이를 flapping이라고 부른다.

이를 막기 위해서 1.23부터 정식으로 추가된 behavior 섹션에 스케일 정책을 추가함으로써 막을 수 있다.

 

behavior:
  scaleDown:
    policies:
    - type: Pods # 60초 동안 최대 4개의 레플리카가 줄어들 수 있다.
      value: 4
      periodSeconds: 60
    - type: Percent # 60초 동안 현재 레플리카 수의 10%까지 줄어들 수 있다. (40개 이상 사용 권장)
      value: 10
      periodSeconds: 60 

정책 추가 외에도 stabilizationWindowSeconds를 사용할 수 있다.

behavior:
  scaleDown:
    stabilizationWindowSeconds: 300 # 5분동안 계산된 계산된 값 중 최대 값을 기준으로 스케일 다운을 한다.

 

참고

Horizontal Pod Autoscaling

리소스 메트릭 파이프라인

167. [Kubernetes] 쿠버네티스 모니터링 : Prometheus Adapter와 Opencensus를 이용한 Custom Metrics 수집 및 HPA 적용

쿠버네티스 모니터링 아키텍처(kubernetes monitoring architecture)