기계 번역으로 제공되는 번역입니다. 제공된 번역과 원본 영어의 내용이 상충하는 경우에는 영어 버전이 우선합니다.
컴퓨팅 및 오토 스케일링
개발자는 CPU 및 메모리와 같은 애플리케이션의 리소스 요구 사항을 추정하지만 지속적으로 조정하지 않으면 비용이 증가하고 성능과 신뢰성이 저하될 수 있습니다. 애플리케이션의 리소스 요구 사항을 지속적으로 조정하는 것이 처음부터 올바르게 조정하는 것보다 중요합니다.
아래에 언급된 모범 사례는 비용을 최소화하고 조직이 투자 수익을 극대화할 수 있도록 하면서 비즈니스 성과를 달성하는 비용 인식 워크로드를 구축하고 운영하는 데 도움이 됩니다. 클러스터 컴퓨팅 비용 최적화의 중요도는 다음과 같습니다.
-
적절한 크기의 워크로드
-
미사용 용량 감소
-
컴퓨팅 용량 유형(예: 스팟) 및 액셀러레이터(예: GPUs) 최적화
워크로드 크기 조정
대부분의 EKS 클러스터에서 대부분의 비용은 컨테이너화된 워크로드를 실행하는 데 사용되는 EC2 인스턴스에서 발생합니다. 워크로드 요구 사항을 이해하지 않으면 컴퓨팅 리소스의 크기를 조정할 수 없습니다. 따라서 적절한 요청 및 제한을 사용하고 필요에 따라 해당 설정을 조정해야 합니다. 또한 인스턴스 크기 및 스토리지 선택과 같은 종속성은 워크로드 성능에 영향을 미쳐 비용 및 신뢰성에 의도하지 않은 다양한 결과를 초래할 수 있습니다.
요청은 실제 사용률과 일치해야 합니다. 컨테이너의 요청이 너무 높으면 총 클러스터 비용에서 큰 요인인 미사용 용량이 있습니다. 애플리케이션 및 사이드카와 같은 포드의 각 컨테이너에는 집계 포드 제한이 최대한 정확하도록 자체 요청 및 제한이 설정되어 있어야 합니다.
컨테이너에 대한 리소스 요청 및 제한을 추정하는 Goldilocks
Horizontal Pod Autoscaler(HPA)를 사용하여 실행해야 하는 애플리케이션의 복제본 수를 제어하고, Vertical Pod Autoscaler(VPA)를 사용하여 복제본당 애플리케이션 요구 사항을 조정하고 제한하며, Karpenter
Vertical Pod Autoscaler는 워크로드가 최적으로 실행되도록 컨테이너에 할당된 요청 및 제한을 조정할 수 있습니다. VPA가 자동으로 변경되지 않고 포드를 다시 시작하지 않도록 감사 모드에서 VPA를 실행해야 합니다. 관찰된 지표를 기반으로 변경 사항을 제안합니다. 프로덕션 워크로드에 영향을 미치는 변경 사항이 있는 경우 먼저 비프로덕션 환경에서 변경 사항을 검토하고 테스트해야 합니다. 이러한 변경 사항은 애플리케이션의 신뢰성과 성능에 영향을 미칠 수 있기 때문입니다.
소비 감소
비용을 절감하는 가장 좋은 방법은 리소스를 더 적게 프로비저닝하는 것입니다. 이를 위한 한 가지 방법은 현재 요구 사항에 따라 워크로드를 조정하는 것입니다. 워크로드가 요구 사항을 정의하고 동적으로 확장되도록 하여 비용 최적화 작업을 시작해야 합니다. 이렇게 하려면 애플리케이션에서 지표를 가져오고 PodDisruptionBudgets
Horizontal Pod Autoscaler는 애플리케이션의 성능 및 안정성 요구 사항을 충족하는 데 필요한 복제본 수를 조정할 수 있는 유연한 워크로드 Autoscaler입니다. CPU, 메모리 또는 대기열 깊이, 포드에 대한 연결 수 등과 같은 사용자 지정 지표와 같은 다양한 지표를 기반으로 스케일 업 및 스케일 다운 시기를 정의하는 유연한 모델이 있습니다.
Kubernetes 지표 서버는 CPU 및 메모리 사용량과 같은 기본 제공 지표에 대한 응답으로 규모 조정을 활성화하지만 Amazon CloudWatch 또는 SQS 대기열 깊이와 같은 다른 지표를 기반으로 규모 조정하려는 경우 KEDA
워크로드 소비를 줄이면 클러스터에 초과 용량이 생성되고 적절한 오토 스케일링 구성을 통해 노드를 자동으로 스케일 다운하고 총 지출을 줄일 수 있습니다. 컴퓨팅 용량을 수동으로 최적화하지 않는 것이 좋습니다. 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 Priority 확장 프로그램
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% 미만으로 떨어진 후에만 단일 노드를 축소하려고 시도합니다.
디스케줄러를 사용하면 포드가 예약되거나 노드가 클러스터에 추가된 후 클러스터 용량과 사용률을 확인할 수 있습니다. 클러스터의 총 용량을 지정된 임계값 이상으로 유지하려고 시도합니다. 또한 노드 테인트 또는 클러스터에 조인하는 새 노드를 기반으로 포드를 제거하여 포드가 최적의 컴퓨팅 환경에서 실행되고 있는지 확인할 수 있습니다. 디스케줄러는 제거된 포드의 교체를 예약하지 않지만 이에 대한 기본 스케줄러를 사용합니다.
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 드레이닝되는 동안 포드가 노드에 추가되면 나머지 포드는 여전히 제거되지만 해당 포드는 제거될 때까지 종료를 차단합니다. 어느 경우든 노드에 추가 작업이 예약되지 않도록 노드가 연결됩니다. 다음은 주석을 설정하는 방법을 보여주는 예제입니다.
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의 예입니다.
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
Cluster Autoscaler 및 Karpenter를 사용하여 노드에 태그 지정
AWS 리소스 태그는 리소스를 구성하고 AWS 비용을 세부적으로 추적하는 데 사용됩니다. 비용 추적을 위해 Kubernetes 레이블과 직접 연관되지 않습니다. Kubernetes 리소스 레이블 지정으로 시작하고 Kubecost
작업자 노드에는 AWS Cost Explorer에 결제 정보를 표시하는 태그가 있어야 합니다. Cluster Autoscaler를 사용하면 시작 템플릿을 사용하여 관리형 노드 그룹 내의 작업자 노드에 태그를 지정합니다. 자체 관리형 노드 그룹의 경우 EC2 Auto Scaling 그룹을 사용하여 인스턴스에 태그를 지정합니다. Karpenter에서 프로비저닝한 인스턴스의 경우 노드 템플릿에서 spec.tags
다중 테넌트 클러스터
다른 팀에서 공유하는 클러스터에서 작업하는 경우 동일한 노드에서 실행되는 다른 워크로드를 볼 수 없을 수 있습니다. 리소스 요청은 CPU 공유와 같은 일부 "시끄러운 이웃" 문제를 격리하는 데 도움이 될 수 있지만 디스크 I/O 소진과 같은 모든 리소스 경계를 격리하지는 못할 수 있습니다. 워크로드별 모든 소모성 리소스가 격리되거나 제한될 수 있는 것은 아닙니다. 다른 워크로드보다 더 높은 속도로 공유 리소스를 사용하는 워크로드는 노드 테인트 및 허용 오차를
노드 수준에서 워크로드를 격리하면 비용이 더 많이 들 수 있지만 예약 인스턴스
공유 클러스터에는 IP 소진, Kubernetes 서비스 제한 또는 API 조정 요청과 같은 클러스터 수준 리소스 제약이 있을 수도 있습니다. 확장성 모범 사례 가이드를 검토하여 클러스터가 이러한 제한을 피하도록 해야 합니다.
네임스페이스 또는 Karpenter 프로비저너 수준에서 리소스를 격리할 수 있습니다. Resource Quotas
Karpenter 프로비저너는 클러스터의 일부 소모성 리소스(예: CPU, GPU)에 대한 제한을 설정할
예약된 Autoscaling
주말과 업무 시간에 클러스터를 스케일 다운해야 할 수 있습니다. 이는 사용하지 않을 때 0으로 스케일 다운하려는 테스트 및 비프로덕션 클러스터와 특히 관련이 있습니다. 클러스터 턴다운
컴퓨팅 용량 유형 최적화
클러스터의 총 컴퓨팅 용량을 최적화하고 빈 패킹을 활용한 후에는 클러스터에서 프로비저닝한 컴퓨팅 유형과 이러한 리소스에 대한 비용을 지불하는 방법을 살펴봐야 합니다. AWS에는 다음과 같은 용량 유형으로 분류할 컴퓨팅 비용을 줄일 수 있는 컴퓨팅 절감형 플랜
-
스팟
-
절감형 플랜
-
온디맨드
-
Fargate
각 용량 유형에는 관리 오버헤드, 가용성 및 장기 약정에 대한 장단점이 서로 다르므로 환경에 적합한 것을 결정해야 합니다. 어떤 환경도 단일 용량 유형에 의존해서는 안 되며 단일 클러스터에서 여러 실행 유형을 혼합하여 특정 워크로드 요구 사항과 비용을 최적화할 수 있습니다.
스팟
스팟
스팟 컴퓨팅은 스팟 용량을 사용할 수 없을 가능성을 줄이기 위해 다양한 인스턴스 유형을 사용해야 합니다. 노드를 안전하게 종료하려면 인스턴스 중단을 처리해야 합니다. Karpenter 또는 관리형 노드 그룹의 일부로 프로비저닝된 노드는 인스턴스 중단 알림을 자동으로 지원합니다. 자체 관리형 노드를 사용하는 경우 노드 종료 핸들러
단일 클러스터에서 스팟 인스턴스와 온디맨드 인스턴스의 균형을 맞출 수 있습니다. Karpenter를 사용하면 가중 프로비저너
다음은 Karpenter를 사용하여 온디맨드 인스턴스보다 먼저 스팟 인스턴스의 우선순위를 지정하는 예제입니다. 프로비저너를 생성할 때 스팟, 온디맨드 또는 둘 다(아래 참조)를 지정할 수 있습니다. 둘 다 지정하고 포드가 스팟을 사용해야 하는지 온디맨드를 사용해야 하는지 명시적으로 지정하지 않으면 Karpenter는 price-capacity-optimization 할당 전략
apiVersion: karpenter.sh/v1
kind: Provisioner
metadata:
name: spot-prioritized
spec:
requirements:
- key: "karpenter.sh/capacity-type"
operator: In
values: ["spot", "on-demand"]
Savings Plans, 예약 인스턴스 및 AWS EDP
컴퓨팅 절감형 플랜을 사용하여 컴퓨팅
컴퓨팅 절감형 플랜은 사용하려는 인스턴스 유형, 패밀리 또는 리전에 대한 약정 없이 EC2 비용을 최대 66% 절감할 수 있습니다. 절감액은 인스턴스를 사용할 때 인스턴스에 자동으로 적용됩니다.
EC2 Instance Savings Plans C 패밀리의 인스턴스와 같은 특정 리전 및 EC2 패밀리에서 사용량을 약정하여 컴퓨팅 비용을 최대 72% 절감합니다. 사용량을 리전 내의 모든 AZ로 전환하고, c5 또는 c6와 같은 인스턴스 패밀리의 모든 세대를 사용하고, 패밀리 내의 모든 크기의 인스턴스를 사용할 수 있습니다. 할인은 절감형 플랜 기준과 일치하는 계정의 모든 인스턴스에 자동으로 적용됩니다.
예약 인스턴스
고객은 AWS와의 엔터프라이즈 계약에 등록할 수도 있습니다. 엔터프라이즈 계약은 고객의 요구에 가장 적합한 계약을 맞춤 설정할 수 있는 옵션을 제공합니다. 고객은 AWS EDP(엔터프라이즈 할인 프로그램)에 따라 요금 할인을 받을 수 있습니다. 엔터프라이즈 계약에 대한 자세한 내용은 AWS 영업 담당자에게 문의하십시오.
온디맨드
온디맨드 EC2 인스턴스는 절감형 플랜에 비해 스팟과 장기 약정이 없는 경우 중단 없는 가용성의 이점을 누릴 수 있습니다. 클러스터에서 비용을 절감하려면 온디맨드 EC2 인스턴스의 사용량을 줄여야 합니다.
워크로드 요구 사항을 최적화한 후에는 클러스터의 최소 및 최대 용량을 계산할 수 있어야 합니다. 이 숫자는 시간이 지남에 따라 변경될 수 있지만 감소하는 경우는 거의 없습니다. 최소 미만의 모든 항목에 Savings Plan을 사용하고 애플리케이션 가용성에 영향을 주지 않는 용량을 확보하는 것이 좋습니다. 지속적으로 사용되지 않거나 가용성에 필요한 다른 모든 것은 온디맨드 방식으로 사용할 수 있습니다.
이 단원에서 언급했듯이 사용량을 줄이는 가장 좋은 방법은 리소스를 적게 사용하고 프로비저닝한 리소스를 최대한 활용하는 것입니다. Cluster Autoscaler를 사용하면 scale-down-utilization-threshold 설정으로 사용률이 낮은 노드를 제거할 수 있습니다. Karpenter에서는 통합을 활성화하는 것이 좋습니다.
워크로드에 사용할 수 있는 EC2 인스턴스 유형을 수동으로 식별하려면 각 리전에서 사용할 수 있는 인스턴스와 EKS와 호환되는 인스턴스를 표시할 수 있는 ec2-instance-selector
ec2-instance-selector --memory 4 --vcpus 2 --cpu-architecture x86_64 \ -r us-east-1 --service eks c5.large c5a.large c5ad.large c5d.large c6a.large c6i.large t2.medium t3.medium t3a.medium
비프로덕션 환경의 경우 야간 및 주말과 같은 미사용 시간에 클러스터를 자동으로 축소할 수 있습니다. kubecost 프로젝트 클러스터 가동 중지
Fargate 컴퓨팅
Fargate 컴퓨팅은 EKS 클러스터를 위한 완전 관리형 컴퓨팅 옵션입니다. Kubernetes 클러스터에서 노드당 하나의 포드를 예약하여 포드 격리를 제공합니다. 이를 통해 컴퓨팅 노드의 크기를 워크로드의 CPU 및 RAM 요구 사항에 맞게 조정하여 클러스터의 워크로드 사용량을 엄격하게 제어할 수 있습니다.
Fargate는 0.5GB 메모리가 있는 .25 vCPU만큼 작은 워크로드와 120GB 메모리가 있는 16 vCPU만큼 큰 워크로드를 확장할 수 있습니다. 사용 가능한 포드 크기 변형 수에는 제한이 있으며 워크로드가 Fargate 구성에 가장 적합한 방법을 이해해야 합니다. 예를 들어 워크로드에 메모리가 0.5GB인 vCPU 1개가 필요한 경우 가장 작은 Fargate 포드는 메모리가 2GB인 vCPU 1개입니다.
Fargate는 EC2 인스턴스 또는 운영 체제 관리가 없는 등 많은 이점이 있지만 배포된 모든 포드가 클러스터에서 별도의 노드로 격리되어 있기 때문에 기존 EC2 인스턴스보다 더 많은 컴퓨팅 용량이 필요할 수 있습니다. 이렇게 하려면 일반적으로 노드에 배포하는 Kubelet, 로깅 에이전트 및 DaemonSets와 같은 사물에 대해 더 많은 중복이 필요합니다. DaemonSets는 Fargate에서 지원되지 않으므로 포드 "`sidecars"로 변환하고 애플리케이션과 함께 실행해야 합니다.
워크로드 경계가 워크로드 간에 버스트하거나 공유할 수 없는 노드이므로 Fargate는 빈 패킹 또는 CPU 오버프로비저닝의 이점을 누릴 수 없습니다. Fargate는 비용이 드는 EC2 인스턴스 관리 시간을 절약하지만 CPU 및 메모리 비용은 다른 EC2 용량 유형보다 더 높을 수 있습니다. Fargate 포드는 컴퓨팅 절감형 플랜을 활용하여 온디맨드 비용을 절감할 수 있습니다.
컴퓨팅 사용량 최적화
컴퓨팅 인프라 비용을 절감하는 또 다른 방법은 워크로드에 보다 효율적인 컴퓨팅을 사용하는 것입니다. 이는 x86보다 최대 20% 저렴하고 60% 더 에너지 효율적인 Graviton 프로세서
EKS는 혼합 아키텍처(예: amd64 및 arm64)를 사용하여 클러스터를 실행할 수 있으며 컨테이너가 여러 아키텍처에 맞게 컴파일된 경우 프로비저너에서 두 아키텍처를 모두 허용하여 Karpenter를 사용하는 Graviton 프로세서를 활용할 수 있습니다. 그러나 일관된 성능을 유지하려면 각 워크로드를 단일 컴퓨팅 아키텍처에 유지하고 사용 가능한 추가 용량이 없는 경우에만 다른 아키텍처를 사용하는 것이 좋습니다.
프로비저너는 여러 아키텍처로 구성할 수 있으며 워크로드 사양에서 특정 아키텍처를 요청할 수도 있습니다.
apiVersion: karpenter.sh/v1 kind: Provisioner metadata: name: default spec: requirements: - key: "kubernetes.io/arch" operator: In values: ["arm64", "amd64"]
Cluster Autoscaler를 사용하면 Graviton 인스턴스에 대한 노드 그룹을 생성하고 워크로드에서 노드 허용치를 설정
GPUs 및 FPGAs는 워크로드의 성능을 크게 높일 수 있지만 액셀러레이터를 사용하도록 워크로드를 최적화해야 합니다. 기계 학습 및 인공 지능을 위한 많은 워크로드 유형은 컴퓨팅에 GPUs 사용할 수 있으며, 인스턴스를 클러스터에 추가하고 리소스 요청을 사용하여 워크로드에 탑재할 수 있습니다.
spec: template: spec: - containers: ... resources: limits: nvidia.com/gpu: "1"
일부 GPU 하드웨어는 여러 워크로드에서 공유할 수 있으므로 단일 GPU를 프로비저닝하고 사용할 수 있습니다. 워크로드 GPU 공유를 구성하는 방법을 알아보려면 가상 GPU 디바이스 플러그인
