컴퓨팅 및 오토 스케일링

개발자는 CPU 및 메모리와 같은 애플리케이션의 리소스 요구 사항을 추정하지만 지속적으로 조정하지 않으면 비용이 증가하고 성능과 신뢰성이 저하될 수 있습니다. 애플리케이션의 리소스 요구 사항을 지속적으로 조정하는 것이 처음부터 올바르게 조정하는 것보다 더 중요합니다.

아래에 언급된 모범 사례는 비용을 최소화하고 조직이 투자 수익을 극대화할 수 있도록 하면서 비즈니스 성과를 달성하는 비용 인식 워크로드를 구축하고 운영하는 데 도움이 됩니다. 클러스터 컴퓨팅 비용 최적화의 중요도는 다음과 같습니다.

1. 적절한 크기의 워크로드

2. 미사용 용량 감소

3. 컴퓨팅 용량 유형(예: 스팟) 및 액셀러레이터(예: GPUs) 최적화

워크로드의 적절한 크기 조정

대부분의 EKS 클러스터에서 대부분의 비용은 컨테이너화된 워크로드를 실행하는 데 사용되는 EC2 인스턴스에서 발생합니다. 워크로드 요구 사항을 이해하지 않으면 컴퓨팅 리소스의 크기를 조정할 수 없습니다. 따라서 적절한 요청과 제한을 사용하고 필요에 따라 해당 설정을 조정하는 것이 중요합니다. 또한 인스턴스 크기 및 스토리지 선택과 같은 종속성은 워크로드 성능에 영향을 미쳐 비용 및 신뢰성에 의도하지 않은 다양한 결과를 초래할 수 있습니다.

요청은 실제 사용률과 일치해야 합니다. 컨테이너의 요청이 너무 높으면 총 클러스터 비용에서 큰 요인인 미사용 용량이 있습니다. 애플리케이션 및 사이드카와 같은 포드의 각 컨테이너에는 집계 포드 제한이 최대한 정확하도록 자체 요청 및 제한이 설정되어 있어야 합니다.

컨테이너에 대한 리소스 요청 및 제한을 추정하는 Goldilocks, KRR 및 Kubecost와 같은 도구를 활용합니다. 애플리케이션의 특성, 성능/비용 요구 사항 및 복잡성에 따라 확장하기에 가장 적합한 지표, 애플리케이션 성능이 저하되는 시점(포화점), 그에 따라 요청 및 제한을 조정하는 방법을 평가해야 합니다. 이 주제에 대한 추가 지침은 애플리케이션 오른쪽 크기 조정을 참조하세요.

Horizontal Pod Autoscaler(HPA)를 사용하여 실행해야 하는 애플리케이션의 복제본 수를 제어하고, Vertical Pod Autoscaler(VPA)를 사용하여 복제본당 애플리케이션 요구 사항을 조정하고 제한하며, Karpenter 또는 Cluster Autoscaler와 같은 노드 Autoscaler를 사용하여 클러스터의 총 노드 수를 지속적으로 조정하는 것이 좋습니다. Karpenter 및 Cluster Autoscaler를 사용한 비용 최적화 기법은이 문서의 뒷부분에 설명되어 있습니다.

Vertical Pod Autoscaler는 워크로드가 최적으로 실행되도록 컨테이너에 할당된 요청 및 제한을 조정할 수 있습니다. VPA가 자동으로 변경되고 포드가 다시 시작되지 않도록 감사 모드에서 VPA를 실행해야 합니다. 관찰된 지표를 기반으로 한 변경 사항을 제안합니다. 프로덕션 워크로드에 영향을 미치는 변경 사항이 있는 경우 먼저 비프로덕션 환경에서 변경 사항을 검토하고 테스트해야 합니다. 이러한 변경 사항은 애플리케이션의 신뢰성과 성능에 영향을 미칠 수 있기 때문입니다.

소비 감소

비용을 절감하는 가장 좋은 방법은 리소스를 더 적게 프로비저닝하는 것입니다. 이를 위한 한 가지 방법은 현재 요구 사항에 따라 워크로드를 조정하는 것입니다. 워크로드가 요구 사항을 정의하고 동적으로 규모를 조정하도록 하여 비용 최적화 작업을 시작해야 합니다. 이렇게 하려면 애플리케이션에서 지표를 가져오고 PodDisruptionBudgets 및 포드 준비 게이트와 같은 구성을 설정하여 애플리케이션이 동적으로 안전하게 확장 및 축소될 수 있도록 해야 합니다. 제한적인 PodDisruptionBudgets는 Cluster Autoscaler와 Karpenter 모두 PodDisruptionBudgets를 준수하므로 Cluster Autoscaler와 Karpenter가 노드를 스케일 다운하지 못하게 할 수 있다는 점을 고려해야 합니다. PodDisruptionBudget의 'minAvailable' 값은 항상 배포의 포드 수보다 작아야 하며 두 포드 간에 양호한 버퍼를 유지해야 합니다. 예를 들어, 포드 6개를 배포하여 항상 포드를 최소 4개 이상 실행하려면 PodDisruptionBidget의 'minAvailable'을 4로 설정합니다. 이렇게 하면 Cluster Autoscaler와 Karpenter가 노드 스케일 다운 이벤트 중에 사용률이 낮은 노드에서 포드를 안전하게 드레이닝하고 제거할 수 있습니다. Cluster Autoscaler FAQ 문서를 참조하세요.

Horizontal Pod Autoscaler는 애플리케이션의 성능 및 안정성 요구 사항을 충족하는 데 필요한 복제본 수를 조정할 수 있는 유연한 워크로드 Autoscaler입니다. CPU, 메모리 또는 대기열 깊이, 포드에 대한 연결 수 등과 같은 사용자 지정 지표를 기반으로 스케일 업 및 스케일 다운 시기를 정의하는 유연한 모델이 있습니다.

Kubernetes Metrics Server를 사용하면 CPU 및 메모리 사용량과 같은 기본 제공 지표에 대한 응답으로 조정이 가능하지만 Amazon CloudWatch 또는 SQS 대기열 깊이와 같은 다른 지표를 기반으로 조정하려면 KEDA와 같은 이벤트 기반 Autoscaling 프로젝트를 고려해야 합니다. CloudWatch 지표와 함께 KEDA를 사용하는 방법에 대한 이 블로그 게시물을 참조하세요. 어떤 지표를 모니터링하고 조정할지 확실하지 않은 경우 중요한 지표 모니터링에 대한 모범 사례를 확인하세요.

워크로드 소비를 줄이면 클러스터에 초과 용량이 생성되고 적절한 Auto Scaling 구성을 통해 노드를 자동으로 축소하고 총 지출을 줄일 수 있습니다. 컴퓨팅 용량을 수동으로 최적화하지 않는 것이 좋습니다. Kubernetes 스케줄러 및 노드 오토스케일러는이 프로세스를 처리하도록 설계되었습니다.

미사용 용량 감소

애플리케이션에 적합한 크기를 결정하여 초과 요청을 줄이면 프로비저닝된 컴퓨팅 용량을 줄일 수 있습니다. 위의 섹션에서 워크로드의 크기를 올바르게 조정하는 데 시간이 걸린 경우 동적으로이 작업을 수행할 수 있습니다. AWS의 Kubernetes에는 두 개의 프라이머리 노드 오토스케일러가 사용됩니다.

Karpenter 및 Cluster Autoscaler

포드가 생성되거나 제거되고 컴퓨팅 요구 사항이 변경되면 Karpenter와 Kubernetes Cluster Autoscaler 모두 클러스터의 노드 수를 조정합니다. 두 가지 모두의 기본 목표는 동일하지만 Karpenter는 노드 관리 프로비저닝 및 프로비저닝 해제에 대해 다른 접근 방식을 취하여 비용을 절감하고 클러스터 전체 사용을 최적화하는 데 도움이 될 수 있습니다.

클러스터의 크기가 커지고 다양한 워크로드가 증가하면 노드 그룹 및 인스턴스를 사전 구성하기가 더 어려워집니다. 워크로드 요청과 마찬가지로 초기 기준을 설정하고 필요에 따라 지속적으로 조정하는 것이 중요합니다.

Cluster Autoscaler를 사용하는 경우 각 Auto Scaling 그룹(ASG)의 "최소" 및 "최대" 값을 준수하고 "원하는" 값만 조정합니다. Cluster Autoscaler는 "최소" 수를 초과하여 ASG를 스케일 다운할 수 없으므로 기본 ASG에 대해 이러한 값을 설정하는 동안 주의해야 합니다. "원하는" 수를 정상 업무 시간 동안 필요한 노드 수로 설정하고 "최소"를 업무 외 시간에 필요한 노드 수로 설정합니다. Cluster Autoscaler FAQ 문서를 참조하세요.

Cluster Autoscaler 우선 순위 확장기

Kubernetes Cluster Autoscaler는 애플리케이션이 확장 및 축소될 때 노드 그룹이라고 하는 노드 그룹을 확장 및 축소하여 작동합니다. 워크로드를 동적으로 조정하지 않는 경우 Cluster Autoscaler는 비용을 절감하는 데 도움이 되지 않습니다. Cluster Autoscaler를 사용하려면 클러스터 관리자가 노드 그룹을 미리 생성해야 워크로드를 사용할 수 있습니다. 노드 그룹은 "profile"이 동일한 인스턴스, 즉 대략 동일한 양의 CPU와 메모리를 사용하도록 구성해야 합니다.

여러 노드 그룹을 가질 수 있으며, 우선 순위 조정 수준을 설정하도록 Cluster Autoscaler를 구성할 수 있으며, 각 노드 그룹에는 다양한 크기의 노드가 포함될 수 있습니다. 노드 그룹은 다양한 용량 유형을 가질 수 있으며 우선 순위 확장기를 사용하여 더 저렴한 그룹을 먼저 확장할 수 있습니다.

다음은 온디맨드 인스턴스를 사용하기 전에 ConfigMap`를 사용하여 예약 용량의 우선 순위를 지정하는 클러스터 구성 코드 조각의 예입니다. 동일한 기법을 사용하여 다른 유형보다 Graviton 또는 스팟 인스턴스의 우선 순위를 지정할 수 있습니다.

apiVersion: eksctl.io/v1alpha5
kind: ClusterConfig
metadata:
  name: my-cluster
managedNodeGroups:
  - name: managed-ondemand
    minSize: 1
    maxSize: 7
    instanceType: m5.xlarge
  - name: managed-reserved
    minSize: 2
    maxSize: 10
    instanceType: c5.2xlarge

apiVersion: v1
kind: ConfigMap
metadata:
  name: cluster-autoscaler-priority-expander
  namespace: kube-system
data:
  priorities: |-
    10:
      - .*ondemand.*
    50:
      - .*reserved.*

노드 그룹을 사용하면 기본 컴퓨팅 리소스가 기본적으로 예상되는 작업을 수행하는 데 도움이 될 수 있습니다. 예를 들어 AZs 간에 노드를 분산하지만 모든 워크로드가 동일한 요구 사항 또는 기대치를 가지고 있지는 않으며 애플리케이션이 요구 사항을 명시적으로 선언하도록 하는 것이 좋습니다. Cluster Autoscaler에 대한 자세한 내용은 모범 사례 섹션을 참조하세요.

디스케줄러

Cluster Autoscaler는 예약해야 하는 새 포드 또는 노드 사용률이 낮은 노드를 기반으로 클러스터에서 노드 용량을 추가하고 제거할 수 있습니다. 노드로 예약된 후에는 포드 배치를 전체적으로 볼 수 없습니다. Cluster Autoscaler를 사용하는 경우 클러스터의 용량이 낭비되지 않도록 Kubernetes 스케줄러도 확인해야 합니다.

클러스터에 노드가 10개 있고 각 노드가 60% 활용된 경우 클러스터에서 프로비저닝된 용량의 40%를 사용하지 않는 것입니다. Cluster Autoscaler를 사용하면 노드당 사용률 임계값을 60%로 설정할 수 있지만 사용률이 60% 미만으로 떨어지면 단일 노드만 축소하려고 시도합니다.

디스케줄러를 사용하면 포드가 예약되거나 노드가 클러스터에 추가된 후 클러스터 용량과 사용률을 확인할 수 있습니다. 클러스터의 총 용량을 지정된 임계값 이상으로 유지하려고 시도합니다. 또한 노드 테인트 또는 클러스터에 조인하는 새 노드를 기반으로 포드를 제거하여 포드가 최적의 컴퓨팅 환경에서 실행되고 있는지 확인할 수 있습니다. descheduler는 제거된 포드의 교체를 예약하지 않지만 이에 대한 기본 스케줄러를 사용합니다.

Karpenter 통합

Karpenter는 노드 관리에 "그룹 없는" 접근 방식을 취합니다. 이 접근 방식은 다양한 워크로드 유형에 대해 더 유연하며 클러스터 관리자의 사전 구성이 덜 필요합니다. 그룹을 사전 정의하고 워크로드에 따라 각 그룹을 조정하는 대신 Karpenter는 프로비저닝 도구와 노드 템플릿을 사용하여 생성할 수 있는 EC2 인스턴스 유형과 인스턴스 생성 시 인스턴스에 대한 설정을 광범위하게 정의합니다.

빈 패킹은 더 적은 수의 최적의 크기의 인스턴스에 더 많은 워크로드를 패킹하여 인스턴스의 리소스를 더 많이 활용하는 방법입니다. 이렇게 하면 워크로드가 사용하는 리소스만 프로비저닝하여 컴퓨팅 비용을 줄이는 데 도움이 되지만 단점이 있습니다. 특히 대규모 조정 이벤트 시 용량을 클러스터에 추가해야 하므로 새 워크로드를 시작하는 데 더 오래 걸릴 수 있습니다. 빈 패킹을 설정할 때 비용 최적화, 성능 및 가용성 간의 균형을 고려합니다.

Karpenter는 지속적으로 모니터링하고 binpack하여 인스턴스 리소스 사용률을 개선하고 컴퓨팅 비용을 절감할 수 있습니다. Karpenter는 워크로드에 대해 보다 비용 효율적인 작업자 노드를 선택할 수도 있습니다. 이는 프로비저너에서 "통합" 플래그를 true로 설정하여 달성할 수 있습니다(아래 샘플 코드 조각). 아래 예제는 통합을 활성화하는 프로비저너 예제를 보여줍니다. 이 안내서를 작성할 때 Karpenter는 실행 중인 스팟 인스턴스를 더 저렴한 스팟 인스턴스로 대체하지 않습니다. Karpenter 통합에 대한 자세한 내용은 이 블로그를 참조하세요.

apiVersion: karpenter.sh/v1
kind: Provisioner
metadata:
  name: enable-binpacking
spec:
  consolidation:
    enabled: true

체크포인트가 없는 장기 실행 배치 작업과 같이 중단이 불가능할 수 있는 워크로드의 경우, 포드에 do-not-evict 주석을 추가하는 것이 좋습니다. 포드를 제거에서 옵트아웃하면 Karpenter에이 포드가 포함된 노드를 자발적으로 제거해서는 안 된다고 알립니다. 그러나 노드가 do-not-evict 드레이닝되는 동안 포드가 노드에 추가되면 나머지 포드는 계속 제거되지만 해당 포드는 제거될 때까지 종료를 차단합니다. 어느 경우든 노드에 추가 작업이 예약되지 않도록 노드가 연결됩니다. 다음은 주석을 설정하는 방법을 보여주는 예제입니다.

8"" linenumbering="unnumbered">apiVersion: v1 kind: Pod metadata: name: label-demo labels: environment: production annotations: + "karpenter.sh/do-not-evict": "true" spec: containers: * name: nginx image: nginx ports: ** containerPort: 80

Cluster Autoscaler 파라미터를 조정하여 사용률이 낮은 노드 제거

노드 사용률은 요청된 리소스의 합계를 용량으로 나눈 값으로 정의됩니다. 기본적으로 scale-down-utilization-threshold는 50%로 설정됩니다. 이 파라미터는 및와 함께 사용할 수 scale-down-unneeded-time있습니다.이 파라미터는 노드를 스케일 다운할 수 있을 때까지 노드가 필요하지 않은 기간을 결정합니다. 기본값은 10분입니다. 축소된 노드에서 계속 실행 중인 포드는 kube-scheduler에 의해 다른 노드에서 예약됩니다. 이러한 설정을 조정하면 활용도가 낮은 노드를 제거하는 데 도움이 될 수 있지만 클러스터가 조기에 축소되지 않도록 먼저 이러한 값을 테스트하는 것이 중요합니다.

제거 비용이 많이 드는 포드가 Cluster Autoscaler에서 인식하는 레이블로 보호되도록 하여 스케일 다운이 발생하지 않도록 할 수 있습니다. 이렇게 하려면 제거 비용이 많이 드는 포드에 주석이 있는지 확인합니다cluster-autoscaler.kubernetes.io/safe-to-evict=false. 다음은 주석을 설정하는 yaml의 예입니다.

8"" linenumbering="unnumbered">apiVersion: v1 kind: Pod metadata: name: label-demo labels: environment: production annotations: + "cluster-autoscaler.kubernetes.io/safe-to-evict": "false" spec: containers: * name: nginx image: nginx ports: ** containerPort: 80