[K8S] HPA - 쿠버네티스 Horizontal Pod AutoScaler

k8s 운영에 대한 고민

안녕하세요 ㅎㅎ

우리는 이전 글에서 쿠버네티스 환경에서 어떻게 애플리케이션을 배포하는지 간단하게 알아보았습니다.

2020.07.20 - [Developer/Kubernetes] - [k8s/쿠버네티스] - Deployment로 애플리케이션 배포

[k8s/쿠버네티스] - Deployment로 애플리케이션 배포

 

하지만 애플리케이션을 서비스하고 운영하다보면, 되게 많은 일들이 일어나게 됩니다.

그 중의 하나인,

컨테이너가 사용할 수 있는 컴퓨팅 또는 메모리 자원이 고갈되고 더 이상 서비스 트래픽을 받을 수 없는 현상이 일어나게 되는데요.

 

이때 어떻게 하면 컴퓨팅 자원 환경에 따라서 유연하게 대처할 수 있는지에 대하여 알아볼려고 합니다

 

Metric 정보

우선 쿠버네티스에서는 어떻게 서버 리소스 자원에 대한 Metric 정보를 수집할까요.?

https://github.com/kubernetes-sigs/metrics-server

GitHub - kubernetes-sigs/metrics-server: Scalable and efficient source of container resource metrics for Kubernetes built-in aut

바로 Metric Server 가 시간별로 pod, node 에 대한 리소스 자원들에 대한 metric 정보들을 수집하게 됩니다!

위의 Github 링크가 바로 metric 을 수집하는 Component 에 대한 저장소 링크입니다.

k8s metric server

전체적인 아키텍쳐는 위와 같은데요.

Metric Server 가 k8s Aggregator 에게 metric 정보를 노티하는 방식으로 metric 정보가 관리되게 되는 구조입니다.

 

만약 Metric 정보를 얻고 싶다면 별도의 tool 을 이용해서 aggregator 에 있는 metric 정보들을 가져가게 되는 것이죠

 

해당 Metric Server 는 기본적인 k8s component 에 포함되어 있지 않기에 별도의 적용이 필요합니다

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

정상적으로 설치가 되었다면 kubectl top 명령어도 사용할 수 있게 됩니다.

해당 명령도 마찬가지로 Metric 정보를 수집한 것을 바탕으로 보여주게 되니까요 ㅎㅎ

그러면 우리는 k8s 에서 pod / node 에 대한 metric 정보를 수집하는 방법과 

해당 정보를 볼 수 있는 방법에 대해 알아보았습니다.

 

그렇다면 k8s 에서 metric 정보를 기반으로 auto scaling 을 지원해주는 component 에 대해 알아볼까요?

바로 2가지 종류가 있습니다

종류	설명
HPA(Horizontal Pod Autoscaler)	Scale Out 에 대한 기능 제공. Pod 가 배포되는 개수를 높여준다.
VPA(Vertical Pod Autoscaler)	Scale Up 에 대한 기능 제공. Pod 의 리소스 할당량을 높여준다.

2가지 유형에 대한 

Vertical Pod Autoscaler

VPA

VPA 의 핵심은 바로 pod 가 운용되는 리소스 단위를 변경하는 것에 있습니다.

recommendation:
	containerRecommendations:
	- containerName: nginx
  	lowerBound:
    	cpu: 40m
    	memory: 3100k
  	target:
    	cpu: 60m
    	memory: 3500k
  	upperBound:
    	cpu: 831m
    	memory: 8000k

위에서  보는 것처럼 리소스에 대한 자원량을 명시하는 것을 볼 수 있는데요.

 

VPA 는 치명적인 단점이 하나 있습니다.

바로 Container 에 대한 리소스 제한을 변경시키기 위한 유일한 방법은 바로 Restart 밖에 존재하지 않는다는 것이죠.

이는 서비스 중인 Container(pod) 에 대해서 운영 중지가 일어날 수도 있다는 점입니다.

 

Pod 는 기본적으로 Node 의 자원을 사용하기 때문에, Scale Up 해서 리소스 자원량을 늘리기보다는

Scale Out 을 통해 Container 더 늘리는 방향을 선호하기도 하게 되는 것이죠

 

Scale Out 은 서비스 중인 Container 에 영향을 주는 것이 아닌 새로운 Pod 에만 영향이 가기 때문이죠.

Horizontal Pod Autoscaler

그래서 Scale out 을 위한 HPA 가 인기가 있는 것입니다.

HPA

HPA 는 Pod 개수를 늘리거나 줄이는 것에 중점을 두고 있기 때문이죠.

apiVersion: autoscaling/v1
kind: HorizontalPodAutoscaler
metadata:
  name: php-apache
spec:
  scaleTargetRef:
    apiVersion: apps/v1
    kind: Deployment
    name: php-apache
  minReplicas: 1
  maxReplicas: 10
  targetCPUUtilizationPercentage: 50 // cpu 평균 사용량을 50프로(1코어 기준) 을 유지한다.

 

 

최소 조건을 만족하는 replica(pod 개수) 를 지정하고,

cpu 부하가 50 프로 이상일 때 최대 replica 를 10개로 유지하겠다는 옵션입니다.

 

테스트 해보기

( 로컬에서 테스트 후 작성 예정입니다 )

 

정리

정리하면 총 3가지 포인트로 정리할 수 있어요

• k8s 에서 Metric 에 대한 수집은 Metric 서버가, Metric Data 는 Aggregator 가 실시한다
• VPA 는 Scale up 하는 오토스케일러 이다
• HPA 는 Scale out 하는 오토스케일러 이다

k8s 운영하면서 auto scaling 은 기능은 주로 비즈니스의 이벤트 행사시에 많이 사용하게 됩니다 ㅎㅎ

물론, Auto scaler 를 정상적으로 사용하기 위해서는 사전에 Node 에 대한 충분한 자원량이 

우선적으로 확보되야 가능하니 꼭 Node 에 대한 자원량을 체크하시기 바랍니다 :)

참고 문서

Resource Metric Pipeline

Horizontal Pod Autoscaler

쿠버네티스#26 - 오토스케일러