Amazon EKS에서 EC2 스팟 인스턴스를 사용하는 모범 사례는 무엇인가요?

3분 분량
0

내 Amazon Elastic Kubernetes Service(Amazon EKS)에서 Amazon Elastic Compute Cloud(Amazon EC2) 스팟 인스턴스를 사용하고 싶습니다. 어떤 모범 사례를 따라야 합니까?

간략한 설명

다음은 Amazon EKS에서 Amazon EC2 스팟 인스턴스를 사용하는 몇 가지 모범 사례입니다.

  • 장기 실행 작업이나 상태 유지 애플리케이션에는 스팟 인스턴스를 사용하지 않습니다.
  • 스팟 인스턴스에서 관리형 노드 그룹을 사용합니다.
  • 노드 그룹에 여러 인스턴스 유형을 추가합니다.
  • 자체 관리형 노드 그룹에 AWS Node Termination Handler(NTH)를 사용합니다.

해결 방법

장기 실행 작업이나 상태 유지 애플리케이션에는 스팟 인스턴스 사용 금지

스팟 인스턴스의 짧은 수명으로 인해 오래 실행되는 작업이 원치 않게 종료될 수 있습니다. 또한 상태 유지 애플리케이션은 종료가 용인되지 않기 때문에 스팟 인스턴스는 상태 유지 애플리케이션에 영향을 줄 수 있습니다. 대신 장기 실행 작업에 온디맨드 인스턴스를 사용하세요.

스팟 인스턴스에서 관리형 노드 그룹을 사용

관리형 노드 그룹의 용량 유형을 스팟으로 설정할 수 있습니다. 그런 다음 관리형 노드 그룹은 EC2 Auto Scaling 용량 재분배를 사용하도록 Auto Scaling 그룹을 구성합니다. EC2 Auto Scaling 용량 재분배가 활성화되고 스팟 노드가 재분배 권장 사항을 수신하면 Amazon EKS가 스팟 노드 교체를 시도합니다.

새 스팟 노드가 준비되면 Amazon EKS가 이전 스팟 노드를 분리하고 드레이닝합니다. 이렇게 하면 Amazon Elastic Block Store(Amazon EBS) 볼륨 손상 또는 데이터베이스 연결 중단의 위험을 줄일 수 있습니다.

노드 그룹에 여러 인스턴스 유형 추가

모든 스팟 인스턴스 풀은 특정 가용 영역의 특정 인스턴스 유형에 대한 미사용 EC2 인스턴스 용량으로 구성됩니다. 노드 그룹이 새 노드를 프로비저닝하려고 할 때 노드 그룹은 해당 구성에 정의된 인스턴스 유형 중 하나를 사용합니다. 인스턴스 유형의 가용 영역에 스팟 용량이 없는 경우 노드 그룹이 확장되지 않고 성능이 저하됩니다.

이 문제를 방지하려면 노드 그룹에서 유사한 인스턴스 유형의 수를 늘립니다.

예를 들어 m5.large(2 vCPU/8GiB RAM) 인스턴스 유형이 있습니다. vCPU 및 RAM 값이 동일한 인스턴스(예: m5a.large, m5n.large, m4.large)를 추가합니다.

자체 관리형 노드 그룹에 AWS NTH 사용

GitHub 웹 사이트에서 제공하는 AWS Node Termination Handler(NTH)는 배포 또는 DaemonSet로서 Amazon EKS 클러스터에 배포됩니다. NTH는 자체 관리형 노드 그룹에 부족한 기능을 추가합니다. 핸들러가 Amazon EC2 유지 관리 이벤트, 스팟 중단 알림, Auto Scaling 그룹 축소 이벤트 및 가용 영역 재분배를 감지하고 적절히 대응할 수 있도록 지원합니다. Queue Processor(대기열 프로세서) 옵션을 사용하여 모든 NTH 기능을 자체 관리형 노드 그룹에 추가할 수 있습니다.

Karpenter를 사용한 스팟 인스턴스 관리

Karpenter는 스케줄링할 수 없는 포드에 대응하여 새 노드를 자동으로 프로비저닝하는 오픈 소스 클러스터 오토스케일러입니다. 또한 Karpenter는 노드를 스케일 인하고 통합하여 낭비와 비용을 줄이는 기능을 제공합니다. 이 기능은 용량 최적화된 우선순위 할당 전략 사용하여 EC2 인스턴스를 프로비저닝합니다.

Karpenter는 Amazon EKS 클러스터의 AWS 리전 및 가용 영역에서 사용할 수 있는 모든 EC2 인스턴스 유형을 사용하여 스팟 인스턴스를 최적화합니다. Karpenter를 EC2 Instance Selector 툴과 함께 사용하여 특정 컴퓨팅 요구 사항에 맞는 인스턴스 유형 목록을 생성할 수 있습니다. 다양한 인스턴스 유형 세트를 사용하면 용량 부족 오류의 위험을 줄일 수 있습니다. 또한 여러 가용 영역에 인스턴스를 분산하여 서로 다른 스팟 풀을 사용하는 것이 가장 좋습니다.

Karpenter 모범 사례 및 제한 사항에 대한 자세한 정보는 GitHub에서 Karpenter 모범 사례를 참조하세요.

중요: 현재 Karpenter는 스팟 중단 종료 알림(ITN)용 2분 경고를 처리할 수 없습니다. 이 문제를 해결하려면 NTH를 설치하여 스팟 노드가 중단되었을 때 정상적으로 차단하고 드레이닝할 수 있습니다.


AWS 공식
AWS 공식업데이트됨 일 년 전
댓글 없음

관련 콘텐츠