[K8S] Karpenter와 Cluster AutoScaler(CA)

쿠버네티스에서 Auto Scaling

• Auto Scaling은 부하와 요구 사항에 따라 컴퓨팅 리소스를 자동으로 조정하여 최적의 성능과 비용 효율성을 제공하는 프로세스입니다.

• EKS에서 Auto Scaling은 ‘Pod Auto Scaling’과 ‘Node Auto Scaling’ 2가지가 있습니다.

  

• Pod의 Auto Scaling

  • Horizontal Pod Autoscaler(HPA) : pod의 수평적인 scaling(scale out/in)을 담당하는 컴포넌트
  • Vertical Pod Autoscaler(VPA) : pod의 수직적인 scaling(scale up/down)을 담당하는 컴포넌트

• Node의 Auto Scaling

  • Cluster AutoScaler(CA) : k8s 클러스터에서 노드를 scaling하는 k8s의 기본 컴포넌트(Scale out/in)
  • Karpenter : k8s cluster autocaling를 위해 AWS에서 만든 오픈소스 프로젝트

Karpenter와 Cluster Autoscaler

• 여기서는 EKS 환경에서 동작하는 CA와 Karpenter를 비교하고 각각의 동작 방식을 이해하고자 합니다.

  

• CA는 AWS 리소스인 Auto Scaling Group(ASG)를 사용하여 클러스터의 크기를 조정하지만, Karpenter는 EC2를 직접 조작하여 클러스터의 크기를 조정합니다.

• CA는 그룹 단위로 노드를 관리하지만 Karpenter는 노드 그룹이라는개념을 사용하지 않으므로 제한 없이 클러스터를 확장하거나 축소할 수 있습니다.

• Karpenter는 EC2 API를 직접 사용하기 때문에 CA에 비해 빠르고, 유연하며 k8s native합니다.

• CA를 사용하면 하나의 EC2에 대해 ASG에서는 인스턴스로, EKS에서는 노드로 관리하기 때문에 관리에 어려움이 있습니다.
  예를 들어, kubectl로 직접 노드를 삭제한다면 ASG는 이를 모르기 때문에 EC2 인스턴스를 삭제하지 않습니다.

• EKS의 노드 그룹은 1개의 Capacity type만 지정이 가능하기 때문에
  CA를 사용하면서 Spot과 On-Demand를 함께 사용하기 위해서는 여러 개의 노드 그룹을 사용해야합니다.

• CA는 여러 개의 노드 그룹이 존재하는 경우 확장할 노드 그룹을 결정해야 합니다.
  CA는 expander 옵션을 통해 여러가지 scaling 전략(random, priority, price 등)를 선택할 수 있습니다.
  (기본 expander는 random이고 AWS는 price expander를 지원하지 않습니다.)

• EKS의 노드 그룹은 ASG에 기반하며 노드 그룹의 인스턴스 사이즈는 1가지로 정하는 것이 권장됩니다.

• CA를 사용하면 노드 그룹의 최대 크기를 미리 정해야 합니다.

• CA는 노드 그룹 내의 모든 노드가 같은 vCPU와 Memory를 가지고 있다고 가정하기 때문에 자원의 낭비가 발생할 수 있습니다.
  예를 들어 0.5vCPU와/256MiB를 사용하는 하나의 파드를 실행하는데 8vCPU/32Gib 사이즈의 노드가 프로비저닝 될 수도 있습니다.

• Karpenter는 CA에 비해 새로운 기술이라 기술적 성숙도가 낮습니다.

• Karpenter는 EC2 Fleet으로 노드를 프로비저닝 합니다.
  EC2 Fleet은 한 번의 API 호출로 여러가지 구매 옵션(Spot, On-Demand, RI)와 여러가지 인스턴스 타입, 여러 가용영역에 걸쳐 EC2를 프로비저닝하는 기능입니다.

• Karpenter는 워크로드의 Capacity를 단순화하여 Spot과 On-Demand 뿐만 아니라 여러가지 인스턴스 타입을 혼합하여 사용할 수 있습니다.

CA의 동작 방식

• Scale Out

  

  1. K8S 클러스터에 파드를 배치할 충분한 용량이 없어 Pending 상태의 파드가 발생하여 CA는 Pending 상태인 파드를 감지합니다.
  2. CA는 파드를 스케줄링하기 위해 실행하기 위한 리소스를 확보하기 위해 ASG의 Desired Count를 늘립니다.
  3. ASG는 Desired Count 변화를 감지하고 새 노드를 프로비저닝합니다.
  4. 새 노드가 Ready 상태가 되면 Pending 상태였던 Pod가 정상적으로 스케줄링됩니다.

• Scale In

  

  1. 파드의 실행이 종료되거나 HPA에 의해 파드가 Scale in 되는 경우
  2. CA는 아래의 모든 조건을 충족하는 노드를 불필요한(unneeded)한 노드로 간주합니다.
     • CA는 주기적으로 각 노드의 CPU 및 MEM의 사용률을 평가합니다.
       해당 노드에서 실행 중인 모든 파드의 CPU request의 합과 MEM requests의 합이 노드의 자원의 임계값(기본적 임계값은 50%)미만인지 확인합니다.
     • 해당 노드에서 실행되는 모든 파드가 다른 노드로 이동 가능한지 확인합니다.
     • 해당 노드에 “scale-down-disabled : true” 주석이 없는지 확인합니다.
  3. 불필요한 노드가 일정 시간(기본 값은 10분) 이상 유지되는 경우 CA는 pod들을 evicting(축출)하고 tainting하여 노드를 비웁니다.
  4. 비워진 노드를 제거합니다.
  5. 노드가 종료되면 CA는 ASG의 Desired Count를 조정합니다.

Karpenter의 동작 방식

• Scale Out

  

  1. K8S 클러스터에 파드를 배치할 충분한 용량이 없어 Pending 상태의 파드가 발생하여 Karpenter는 Pending 상태인 파드를 감지합니다.
  2. Karpenter는 파드를 스케줄링하기 위해 필요한 컴퓨팅 용량을 산정하고 EC2 API를 직접 호출하여 가장 저렴한 노드를 우선적으로 프로비저닝합니다.
  3. 새 노드가 Ready 상태가 되면 Pending 상태였던 Pod가 정상적으로 스케줄링됩니다.

• Scale In

  

  

  1. Karpenter는 리소스 사용률을 최적화하고 동시에 비용을 절감하기 위해 노력합니다. 이를 Workload Consolidation이라고 합니다.
  2. Karpenter는 다음을 식별하여 비용을 적극적으로 줄이기 위해 노력합니다.
     • 노드가 비어있는 경우 노드를 제거(Deletion)
     • 워크로드가 다른 노드에서 실행 가능한 경우 노드를 제거(Deletion)
     • 워크로드의 변경(파드 스케일링 또는 워크로드의 종료 등)으로 더 저렴한 노드로 교체 가능한 경우 노드를 교체(Replace)