이 페이지 개선에 도움 주기

이 사용자 가이드에 기여하려면 모든 페이지의 오른쪽 창에 있는 GitHub에서 이 페이지 편집 링크를 선택합니다.

EKS 자율 모드의 비용 최적화

EKS 자율 모드는 통합, 빈 패키징, 적절한 크기 조정을 통해 클러스터의 컴퓨팅 비용을 지속적으로 최적화합니다. 그러나 특정 워크로드 구성은 이러한 최적화를 방해할 수 있습니다. 이 주제에서는 비용 최적화의 작동 방식, 이를 차단할 수 있는 요소, 비용 효율성을 유지하도록 클러스터를 구성하는 방법을 설명합니다.

EKS 자율 모드가 비용을 최적화하는 방법

EKS 자율 모드는 다음 메커니즘을 통해 컴퓨팅 비용을 절감합니다.

이러한 최적화는 수동 개입 없이 지속적으로 실행됩니다. 그러나 특정 포드 주석 및 NodePool 구성은 통합 적용을 방지할 수 있습니다.

기본 제공 노드 풀 및 비용 가드레일

기본 제공 general-purpose 및 system 노드 풀은 이미 몇 가지 비용 보호 기본값을 적용합니다.

기본 제공 노드 풀만 사용 중이라면 이미 이러한 가드레일의 이점을 누리고 있는 것입니다. 인스턴스 패밀리 제외 및 인스턴스 크기 제약에 대한 이 주제의 지침은 이러한 제한을 상속하지 않는 사용자 지정 NodePool을 생성할 때 가장 적절합니다.

그러나 기본 제공 노드 풀의 경우에도 다음 섹션은 여전히 적용됩니다.

통합을 차단하는 요소

노드를 중단하면 워크로드의 가용성 요구 사항이 위반된다고 EKS 자율 모드가 판단하면 통합이 차단됩니다. 다음 구성은 통합을 방지합니다.

do-not-disrupt 주석

karpenter.sh/do-not-disrupt 주석은 주석이 달린 포드가 노드에서 실행되는 한 노드를 보존하도록 EKS 자율 모드에 지시합니다. 이로 인해 노드 사용률이 낮은 경우에도 노드가 통합, 교체 또는 종료되지 않습니다.

metadata:
  annotations:
    karpenter.sh/do-not-disrupt: "true"

고려할 대안:

포드 중단 예산(PDB)

maxUnavailable: 0 또는 minAvailable을 현재 복제본 수와 동일하게 설정하는 PDB는 영향을 받는 포드의 모든 통합을 효과적으로 차단합니다. PDB를 검토하여 한 번에 1개 이상의 포드가 중단되도록 허용하는지 확인합니다.

NodePool 제한을 비용 상한으로 사용

NodePool limits는 NodePool이 프로비저닝할 수 있는 총 컴퓨팅 리소스에 하드 상한을 설정합니다. 한도에 도달하면 EKS 자율 모드는 해당 NodePool을 위한 새 노드 시작을 중지합니다. 이는 포드가 보류 중인 경우에도 발생합니다.

특히 무한 규모 조정이 적절하지 않은 비프로덕션, 테스트 또는 버스트 워크로드를 처리하는 NodePool에는 limits를 비용 가드레일로 사용하세요.

apiVersion: karpenter.sh/v1
kind: NodePool
metadata:
  name: ci-runners
spec:
  template:
    spec:
      nodeClassRef:
        group: eks.amazonaws.com
        kind: NodeClass
        name: default
      requirements:
        - key: "eks.amazonaws.com/instance-category"
          operator: In
          values: ["c", "m"]
  limits:
    cpu: "500"
    memory: 1000Gi

이 예제에서 ci-runners NodePool은 프로비저닝하는 모든 노드에서 모두 합쳐 500개의 vCPU 또는 1000GiB의 메모리를 초과할 수 없습니다. 이 제한을 초과하는 포드는 용량이 확보될 때까지 Pending 상태로 유지됩니다.

비용 제어를 위해 인스턴스 패밀리 제외

기본적으로 EKS 자율 모드는 예약 유연성을 극대화하기 위해 광범위한 인스턴스 유형 중에서 선택합니다. 전문 하드웨어가 필요하지 않은 워크로드의 경우 비용이 많이 드는 인스턴스 유형이 시작되지 않도록 인스턴스 패밀리를 제한하세요.

가속 인스턴스 제외

워크로드가 GPU 또는 액셀러레이터 리소스를 요청하지 않는 경우 NodePool에서 가속 인스턴스 패밀리를 제외하세요. 이렇게 하면 용량 제약 중에 가속 인스턴스가 선택되는 시나리오를 방지할 수 있습니다.

spec:
  template:
    spec:
      requirements:
        - key: "eks.amazonaws.com/instance-category"
          operator: In
          values: ["c", "m", "r"]

컴퓨팅 최적화, 범용, 메모리 최적화 범주만 지정하면 가속(P, G, Inf, Trn) 및 기타 전문 인스턴스 패밀리를 선택에서 제외할 수 있습니다.

인스턴스 선택과 용량 제약의 상호 작용 방식

EKS 자율 모드는 정상적 인스턴스 선택 중에 가속 인스턴스 유형과 특수 인스턴스 유형을 우선순위에서 배제합니다. 하지만 시작 실패가 지속적으로 발생하면 EKS 자율 모드는 워크로드 가용성을 우선시하여 사용 가능한 나머지 인스턴스 유형에서 시작합니다. 예를 들어 선호하는 모든 인스턴스 유형의 EC2 서비스 할당량이 일시적으로 소진되면 이 현상이 발생합니다.

이 폴백 동작을 방지하려면 NodePool 요구 사항을 워크로드에 필요한 인스턴스 범주로만 명시적으로 제한하세요. 선호하는 유형을 사용할 수 없고 NodePool 구성에서 다른 유형을 허용하지 않는 경우 포드는 비용이 많이 드는 인스턴스에 예약되지 않고 Pending 상태로 유지됩니다.

인스턴스 크기 제약

인스턴스 패밀리 제한 외에도 NodePool 내에서 최대 인스턴스 크기를 제한할 수 있습니다. 인스턴스 크기를 제약하면 통합할 수 없는 단일 노드로 인한 비용 노출이 제한됩니다. 예를 들어 do-not-disrupt 주석으로 차단된 노드는 워크로드가 작아도 축소할 수 없습니다.

eks.amazonaws.com/instance-cpu 레이블을 사용하여 NodePool 요구 사항에서 최대 인스턴스 크기를 제한하세요.

requirements:
  - key: "eks.amazonaws.com/instance-cpu"
    operator: Lte
    values: ["32"]

이 구성은 EKS 자율 모드가 이 NodePool에서 vCPU 32개보다 큰 인스턴스를 시작하는 것을 방지합니다.

기존 클러스터에서 최적화 기회를 식별하려면 가장 큰 실행 중 인스턴스를 검토합니다. 큰 노드가 통합에서 지속적으로 차단된다면 해당 유휴 용량의 노드당 비용이 비례적으로 더 높은 것입니다.

버스트 워크로드에 권장되는 패턴

CI/CD 파이프라인, 배치 작업, 임시 러너는 비용 효율성을 유지하기 위해 특정 구성이 필요한 burst-and-idle 패턴을 생성합니다.

버스트 워크로드에 권장되는 기본값

예: CI 러너 NodePool

apiVersion: karpenter.sh/v1
kind: NodePool
metadata:
  name: ci-runners
spec:
  template:
    spec:
      nodeClassRef:
        group: eks.amazonaws.com
        kind: NodeClass
        name: default
      requirements:
        - key: "eks.amazonaws.com/instance-category"
          operator: In
          values: ["c", "m"]
        - key: "eks.amazonaws.com/instance-cpu"
          operator: Lte
          values: ["32"]
        - key: "karpenter.sh/capacity-type"
          operator: In
          values: ["spot", "on-demand"]
  limits:
    cpu: "500"
    memory: 1000Gi
  disruption:
    consolidationPolicy: WhenEmptyOrUnderutilized
    consolidateAfter: 30s

이 구성은 다음과 같습니다.

노드 수명 주기 및 비용

EKS 자율 모드는 노드가 원하는 사양에서 드리프트하거나(예: 새 Auto Mode AMI 릴리스 후) 노드 수명 만료가 다가올 때 정상적인 중단을 통해 노드를 교체합니다. 정상적 교체 중:

노드가 크거나 많은 클러스터의 경우 이 중복으로 인해 주기적으로 비용이 증가할 수 있습니다. 영향을 최소화하려면:

노드 수명 주기에 대한 자세한 내용은 Amazon EKS 자율 모드 관리형 인스턴스에 대해 알아보기를 참조하세요.