Karpenter 도입 체크리스트

Karpenter란?

Just-in-time Nodes for Any Kubernetes Cluster

Karpenter Docs

Karpenter는 적시에 적절한 노드로 Kubernetes 인프라를 단순화합니다.

Karpenter는 클러스터의 애플리케이션을 처리하는 데 적합한 컴퓨팅 리소스만 자동으로 시작합니다. Kubernetes 클러스터를 위한 빠르고 간단한 컴퓨팅 프로비저닝으로 클라우드를 최대한 활용할 수 있도록 설계되었습니다.

애플리케이션 가용성 향상

Karpenter는 애플리케이션 로드, 일정 및 리소스 요구 사항의 변화에 신속하고 자동으로 대응하여 사용 가능한 다양한 컴퓨팅 리소스 용량에 새로운 워크로드를 배치합니다.

컴퓨팅 비용 절감

Karpenter는 활용도가 낮은 노드를 제거하고 값비싼 노드를 저렴한 대안으로 교체하고 워크로드를 보다 효율적인 컴퓨팅 리소스로 통합할 수 있는 기회를 찾아 클러스터 컴퓨팅 비용을 낮춥니다.

운영 오버헤드 최소화

Karpenter는 쉽게 사용자 정의할 수 있는 단일 선언적 리소스에 독자적인 기본값 세트와 함께 제공됩니다 Provisioner.

작동 방식

Karpenter는 예약되지 않은 포드의 총 리소스 요청을 관찰하고 예약 대기 시간과 인프라 비용을 최소화하기 위해 노드를 시작하고 종료하는 결정을 내립니다.

Checklist

• Karpenter Provisioner를 적용하기 이전 ASG에서 관리하던 노드는 어떻게 하는가?

  • Karpenter의 Provisioner로 생성되지 않은 노드는 별도의 관리가 필요하다.
    • ASG의 Desired size를 점진적 조정하여 Karpenter Provisioner 관리체계 노드로 마이그레이션 한다.
    • 워크로드의 유실을 방지하기 위해 Live Service의 구성 pod요소들에 대해 PDB(Pod Disruption Budget)를 설정 후 마이그레이션 하는 것을 권장한다.

• Karpenter는 Group-less node provisioning라는 컨셉을 가지고 있는데, Group node provisioning이 가능한가?

  • Service를 위한 NodeGroup, System NodeGroup등 목적성에 따른 관리를 위한, 적절한 taints and tolerations, affinity and nodeSelector 활용을 위한 선택을 목적으로 Group node provisioning이 유의미 할 수 있다.
    • provisioner의 설정으로 nodeSelector등 노드의 taints 설정이 가능하다.

• NodeGroup의 시작 템플릿이 필요한가?

  • Provisioner는 별도의 설정을 하지 않으면 클러스터의 Kubernetes 현재 버전의 latest ami로 자동 반영되어 Node를 생성한다.

• NodeGroup의 Desired size를 0으로 변경하여도 해당 NodeGroup에서 노드를 생성 할 수 있는가?

  • 가능하다. Provisioner가 노드의 관리를 하기 때문에 Desired size의 영향을 받지 않는다.

• Scale In, Out에 문제는 없는가?

  • Platform 클러스터에 적용 이후 현재까지 아무런 문제 없이 정상적인 ScaleIn, Out이 되고있다.
    • 추가적으로 속도가 CAS에 비해 상대적으로 개선된 것을 볼 수 있다.
      • Scale In Dev Cluster 테스트 기준
        • CAS: 약 48초
        • Karpenter: 약 37초
          • CAS 대비 약 20~25% 수준의 감소 효과

• 소유권(Ownership)과 종료자(Finalizer)를 설정을 할 필요가 있는가?

  • 노드가 ownership과 finalizer가 지정된 채로 생성된다.
    • NTH(Node Termination Handler) 노드 종료 핸들러를 별도로 사용 할 필요가 없다.

• 교체를 위한 renaming 등 모종의 이유로 Provisioner를 삭제하면 어떻게 되는가?

  • provisioner가 관리하던 노드가 일괄 종료된다.
    • provisioner renaming 시에는 ttlSecondsUntilExpired값을 조정하여 새로운 provisioner에 이동되도록 하는 것이 안전하다.

• NodeGroup의 Max size를 지정할 수 있는가?

  • karpenter의 컨셉 상 size에 대한 개념은 없지만 Provisioner에 Limits cpu, memory 설정을 통해 인스턴스 생성을 제한 할 수 있다.
    • 적절하게 특정 NodeGroup에서 사용할 Resources를 산정하여 관리하는 것이 바람직하다 생각된다.

• 싱글 클러스터 업그레이드 방식의 EKS 버전 업그레이드를 진행 했을 때는 노드 버전관리를 어떻게 할 수 있는가?

  • Provisioner의 ttlSecondsUntilExpired 값을 일시적으로 조정하여 업그레이드된 Kubernetes의 버전을 가진 node로 재생성되도록 해야한다.

• Spot Instance는 어떻게 사용 할 수 있는가?

  • karpenter.sh/capacity-type에 spot을 등록하여 사용 가능하다.

    • ex. karpenter.sh/capacity-type: [spot]

  • on-demand와 같이 사용 할 경우 capacity-spread의 배열 수로 설정하여 비율 조정이 가능하다.

    • ex.

    # provisioner spec.requirements
    key: karpenter.sh/capacity-type
    operator: In
    values: [ on-demand ]
    
    key: karpenter.sh/capacity-spread
    operator: In
    values: [ "on-demand-1", "on-demand-2" ]
    
    ---
    
    key: karpenter.sh/capacity-type
    operator: In
    values: [ spot ]
    
    key: karpenter.sh/capacity-spread
    operator: In
    values: [ "spot-1", "spot-2", "spot-3" ]

• CAS에서 Karpenter로 마이그레이션 시 고려사항

  • 적용하고자 하는 Cluster에 Karpenter를 위한 Role 설정
    • karpenter policy 설정 및 Role 등록 과정
    • Cluster의 subnet과 sg에 karpenter managing을 위한 tagging
  • Karpenter Manifest Structure
    • Helm template to Yaml
    • Kustomize
      • https://github.com/yieon-lyon/karpenter-sample
  • Karpenter won’t launch capacity to run itself (log related to the karpenter.sh/provisioner-name DoesNotExist requirement) so it can’t provision for the second Karpenter pod.
    • Karpenter 자기 자신은 실행용량을 체크하지 않는다.
    • Karpenter의 노드확보를 위한 별도의 NodeGroup을 사이즈에 맞도록 설정하여 karpenter deployment를 확보한다.