이 포스팅에는 전체적인 개요만 말할 것이다! 자세한 실습 내용은 각 링크를 참조해 주십쇼!

EKS Autoscaling에는 HPA(Horizontal Pod Autoscaler), VPA(Vertical Pod Autoscaler), CA(Cluster Autoscaler), KEDA(Kubernetes based Event Driven Autoscaler), CPA(Cluster Proportional Autoscaler), Karpenter(K8S Native AutoScaler)가 있다

아래 그림으로 간략하게 HPA, VPA, CA, Karpenter를 비교할 수 있다.

사진 출처: CON324_Optimizing-Amazon-EKS-for-performance-and-cost-on-AWS.pdf

Untitled

  1. HPA: 타겟의 메트릭이 일정 수치를 넘으면 POD의 Replicas를 늘릴 수 있다.
  2. VPA: 타겟의 메트릭이 일정 수치를 넘으면 POD의 Resource(CPU, Memory)를 높일 수 있다.

Untitled 1

  1. CA: Node의 정해진 사양에 따라 POD가 더 이상 스케줄링될 수 없어서 Pending 상태에 이르면, Autoscaler가 동작하여 Node의 개수를 증가시킨다.

Untitled

  1. Karpenter: CA와 마찬가지로 POD의 스케줄링 상태를 모니터링하다가 Node의 스케일링이 이루어 진다. 하지만 CA와 다르게, POD가 Node에 적절하게 스케줄링되어 낭비되는 리소스가 없게 Node의 Rightsizing을 도와준다.

KEDA는 예전 HPA는 Resource(CPU, Memory) 메트릭을 기반으로 하였는데, 그 점을 보안하여 특정 이벤트를 기반으로 POD의 Replicas를 조절할 수 있다.

CPA는 Node의 스케일링 여부를 고려하여, 성능 처리가 필요한 POD(ex. coredns)의 Replicas를 조절할 수 있다.

실습은 HPA, VPA, CA, KEDA, CPA, Karpenter 여섯 가지로 진행할 예정이고 각각 포스팅을 올릴 것이다.

실습 환경은 전부 가시다님이 제공해 주셨다. (항상 감사합니다!)

이 환경에서는 EKS Node Viewer를 설치했다. 이는 각 Node마다 할당 가능한 용량과 스케줄링된 POD(컨테이너)의 Resource 중 request 값을 표시한다. 실제 POD(컨테이너) 리소스 사용량은 아니다.

https://github.com/awslabs/eks-node-viewer

/pkg/model/pod.go 파일을 보면 컨테이너의 request 합을 반환하며, init containers는 미포함이라고 되어 있다. spec.containers.resources.requests 설정 부분이다.

Untitled 3

참고로 HPA도 동작할 때 POD(컨테이너)의 request로 스케일링이 결정된다.

request를 지정하지 않으면 동작하지 않는다.

마지막까지 모든 실습을 진행하며 Karpenter가 정말 대단하게 잘 만들어진 관리 도구인지 알게 되었다!

Untitled

Categories:

Updated:

Leave a comment