- Today
- Total
코기판
k8s pod autoscaler 개념 (HPA, VPA) 본문
Pod autoscaling에 대해 개념적으로 알아보도록 하겠습니다.
지난 포스팅에서는 k8s CA(cluster autoscaler)에 대해서 알아봤는데요,
이번에는 그 연장선이라고 할 수 있습니다.
처음 CA(Cluster Autoscaler)를 도입할 때,
여러 명의 서비스 개발자가 계속해서 여러 개의 서비스를 배포할 수 있도록
node에 pod이 가득 차면 새로운 worker node를 만들어주기 위해 CA를 도입하였습니다.
그렇다면 개발자들이 pod deploy를 해야만 pod의 갯수가 증가할까요?
pod은 서비스가 많이 deploy될 수록 늘어나기도 하지만,
cpu 나 memory 사용량, 혹은 대량의 request가 들어올 때 스스로 늘어납니다.
(물론 설정이 필요합니다)
그리고 이렇게 스스로 늘어나는 것을 pod autoscaling이라고 합니다.
이 때, pod이 어떤 방향으로 늘어나냐에 따라 HPA(horizontal Pod Autoscaling)인지, VPA(Vertical Pod Autoscaling)인지가 결정됩니다.
아래와 같이 수평적인 방향으로 새로운 pod이 생성되는 것이 HPA(Horizontal Pod Autoscaler) 이고,
다음과 같이 resource를 추가하여 수직의 방향으로 커지는 것이 VPA(Vertical Pod Autoscaler)입니다.
그리고 만약 pod이 늘어나게 했던 요소가 해소되면,
사용하던 리소스를 반납하고 원래대로 돌아오는 것 까지가 pod autoscaling의 역할입니다.
늘어나는 것은 scale out, 줄어드는 것은 scale in이라고 합니다.
(저는 처음에 반대로 엄청 헷갈렸네요 ㅋㅋ)
그런데 pod이 늘어날지, 혹은 줄어들지를 결정하는 것은 pod 혼자서만은 할 수 없습니다.
왜냐하면 모든 pod이 평균적으로 리소스를 사용하고 있는지를 알아야 하는데,
pod 혼자서는 자기의 리소스 사용량만 알기 때문입니다
따라서, 모니터링 역할을 해주는 component가 따로 필요합니다
이 component가 바로 metric server입니다.
Pod autoscaler는 metrics server를 이용해 평균적인 사용량을 가져오고, 늘어날지 혹은 줄어들지에 대한 판단을 합니다.
즉, pod autoscaling을 하기 위해서는 꼭 metrics server의 도움을 받아야 한다는 것이 요지입니다.
만약 metrics server가 안떠있으면, 다음과 같은 상황이 발생합니다
kubectl get hpa NAME REFERENCE TARGETS MINPODS MAXPODS REPLICAS AGE my-hpa Deployment/hpa <unknown>/ 40% 1 6 1 25m |
고로, 이 말은 metrics server가 필요하므로, 다음 포스팅에서는 metrics server에 대한 소개와 구현 방법을 설명하겠다는 말입니다
HPA/VPA 구현은 그 다음으로 진행하도록 할게요 !
references :
https://github.com/kubernetes-incubator/kube-aws/issues/549
http://www.magalix.com/blog/kubernetes-autoscaling-101
(Special thank for Mohamed Ahmed, your post definitely gives me great help to understand k8s stuffs.)
'Infra' 카테고리의 다른 글
grpc client load balancing 구현하기 (grpc 번외편) (0) | 2019.05.28 |
---|---|
protobuf란 무엇인가? (gRPC 시리즈 #2) (1) | 2019.05.12 |
gRPC란 무엇인가? (gRPC 시리즈 #1) (5) | 2019.04.21 |
EKS에 클러스터 오토스케일링(cluster autoscaling) 하기 (4) | 2019.03.29 |
AWS EKS 배포 가능한 최대 pods 갯수 (0) | 2019.03.09 |