관리형 노드 그룹

• Amazon EKS 관리형 노드 그룹은 사용자를 위해 Amazon EC2 인스턴스를 생성하고 관리합니다.

• 모든 관리형 노드는 Amazon EKS에서 관리하는 Amazon EC2 Auto Scaling 그룹의 일부로 프로비저닝됩니다. 게다가 Amazon EC2 인스턴스 및 Auto Scaling 그룹을 포함한 모든 리소스는 AWS 계정 내에서 실행됩니다.

• 관리형 노드 그룹의 Auto Scaling 그룹은 그룹을 생성할 때 지정하는 모든 서브넷에 걸쳐 있습니다.

• Amazon EKS는 관리형 노드 그룹 리소스를 태깅하여 Kubernetes Cluster Autoscaler를 사용하도록 구성합니다.

  중요

  Amazon EBS 볼륨에 의해 백업되고 Kubernetes AutoScaling를 사용하는 상태 기반 애플리케이션을 여러 가용 영역에서 실행하는 경우 각 단일 가용 영역으로 범위가 지정된 여러 노드 그룹을 구성해야 합니다. 또한 --balance-similar-node-groups 기능을 활성화해야 합니다.

• 관리형 노드를 배포할 때 더 높은 수준의 유연성과 사용자 지정을 위해 사용자 정의 시작 템플릿을 사용할 수 있습니다. 예를 들어 추가kubelet 인수를 지정하고 사용자 지정 AMI를 사용할 수 있습니다. 자세한 내용은 사용자 지정 시작 템플릿이 있는 관리형 노드 단원을 참조하십시오. 관리형 노드 그룹을 처음 생성할 때 사용자 정의 시작 템플릿을 사용하지 않으면 자동 생성된 시작 템플릿이 표시됩니다. 이 자동 생성된 템플릿을 수동으로 수정하지 마세요. 수정하면 오류가 발생합니다.

• Amazon EKS는 관리형 노드 그룹의 CVE 및 보안 패치에 대한 공동 책임 모델을 따릅니다. 관리형 노드가 Amazon EKS 최적화 AMI를 실행하는 경우 버그나 문제가 보고될 때 패치 버전의 AMI를 빌드해야 합니다. 수정 사항을 게시할 수 있습니다. 그러나 이렇게 패치된 AMI 버전은 사용자가 관리형 노드 그룹에 배포해야 합니다. 관리형 노드가 사용자 지정 AMI를 실행하는 경우 버그나 문제가 보고되고 AMI를 배포할 때 패치 버전의 AMI를 빌드해야 합니다. 자세한 내용은 관리형 노드 그룹 업데이트 단원을 참조하십시오.

• Amazon EKS 관리형 노드 그룹은 퍼블릭 서브넷과 프라이빗 서브넷 모두에서 시작할 수 있습니다. 2020년 4월 22일 또는 이후에 퍼블릭 서브넷에서 관리형 노드 그룹을 시작하는 경우 인스턴스가 클러스터에 성공적으로 조인하려면 서브넷에서 MapPublicIpOnLaunch를 true로 설정해야 합니다. 2020년 3월 26일 이후에 eksctl 또는 Amazon EKS 벤딩 AWS CloudFormation 템플릿을 사용하여 퍼블릭 서브넷을 생성한 경우 이 설정이 이미 true로 설정되어 있습니다. 2020년 3월 26일 이전에 퍼블릭 서브넷을 생성한 경우 해당 설정을 수동으로 변경해야 합니다. 자세한 내용을 알아보려면 서브넷의 퍼블릭 IPv4 주소 지정 속성 수정을 참조하세요.

• 프라이빗 서브넷에 관리형 노드 그룹을 배포할 때 컨테이너 이미지를 가져오기 위해 Amazon ECR에 액세스할 수 있는지 확인해야 합니다. NAT 게이트웨이를 서브넷의 라우팅 테이블에 연결하거나 다음 AWS PrivateLink VPC 엔드포인트를 추가하여 이 작업을 수행할 수 있습니다.

  • Amazon ECR API 엔드포인트 인터페이스 - com.amazonaws.region-code.ecr.api

  • Amazon ECR Docker 레지스트리 API 엔드포인트 인터페이스 – com.amazonaws.region-code.ecr.dkr

  • Amazon S3 게이트웨이 엔드포인트 - com.amazonaws.region-code.s3

  일반적으로 사용되는 다른 서비스와 엔드포인트는 프라이빗 클러스터 요구 사항 섹션을 참조하세요.

• 관리형 노드 그룹을 AWS Outposts이나 AWS Wavelength 또는 AWSLocal Zones에 배포할 수 없습니다.

• 단일 클러스터 내에서 여러 관리형 노드 그룹을 생성할 수 있습니다. 예를 들어, 일부 워크로드에는 표준 Amazon EKS 최적화 Amazon Linux AMI를 사용하는 노드 그룹을 생성하고 GPU 지원이 필요한 워크로드에는 GPU 변형을 사용하는 다른 노드 그룹을 생성할 수 있습니다.

• 관리형 노드 그룹에 Amazon EC2 인스턴스 상태 확인 오류가 발생하면 Amazon EKS는 문제 진단에 도움이 되는 오류 메시지를 반환합니다. 자세한 내용은 관리형 노드 그룹 오류 단원을 참조하십시오.

• Amazon EKS는 관리형 노드 그룹 인스턴스에 Kubernetes 레이블을 추가합니다. 이러한 Amazon EKS 제공 레이블에는 eks.amazonaws.com 접두사가 붙습니다.

• Amazon EKS는 종료 또는 업데이트 중에 Kubernetes API를 사용하여 노드를 자동으로 비웁니다.

• AZRebalance로 노드를 종료하거나 원하는 노드 수를 줄이는 경우 포드 중단 예산은 반영되지 않습니다. 이러한 작업은 노드에서 Pods 제거를 시도합니다. 그러나 15분 넘게 걸리면 노드의 모든 Pods가 종료되었는지 여부에 관계없이 노드가 종료됩니다. 노드가 종료될 때까지 기간을 연장하려면 Auto Scaling 그룹에 수명 주기 후크를 추가하세요. 자세한 내용을 알아보려면 Amazon EC2 Auto Scaling 사용 설명서의 수명 주기 후크 추가를 참조하세요.

• 스팟 중단 알림 또는 용량 재조정 알림을 수신한 후 드레인 프로세스를 올바르게 실행하려면 CapacityRebalance를 true로 설정해야 합니다.

• 관리 노드 그룹을 업데이트하면 Pods에 대해 설정한 Pod 중단 예산을 준수합니다. 자세한 내용은 관리형 노드 업데이트 동작 단원을 참조하십시오.

• Amazon EKS 관리형 노드 그룹을 사용하는 데 따른 추가 비용은 없습니다. 프로비저닝하는 AWS 리소스에 대해서만 비용을 지불합니다.

• 노드에 대해 Amazon EBS 볼륨을 암호화하려는 경우 시작 템플릿을 사용하여 노드를 배포할 수 있습니다. 시작 템플릿을 사용하지 않고 암호화된 Amazon EBS 볼륨이 있는 관리형 노드를 배포하려면 계정에 생성된 모든 새 Amazon EBS 볼륨을 암호화합니다. 자세한 내용은 Amazon EC2 사용 설명서에서 기본적으로 암호화를 참조하세요.

작동 방식

기본적으로, 용량 유형을 지정하지 않은 경우 관리형 노드 그룹이 온디맨드 인스턴스를 사용하여 프로비저닝됩니다. 관리형 노드 그룹은 다음 설정을 적용하여 사용자를 대신하여 Amazon EC2 Auto Scaling 그룹을 구성합니다.

• 온디맨드 용량을 프로비저닝하기 위한 할당 전략이 prioritized로 설정됩니다. 관리형 노드 그룹은 API에 전달된 인스턴스 유형의 순서를 사용하여 온디맨드 용량을 채울 때 먼저 사용할 인스턴스 유형을 결정합니다. 예를 들어 세 가지 인스턴스 유형을 c5.large,c4.large, c3.large의 순서로 지정할 수 있습니다. 온디맨드 인스턴스가 시작되면 관리형 노드 그룹은 c5.large, c4.large, c3.large 순으로 시작하여 온디맨드 용량을 채웁니다. 자세한 내용은 Amazon EC2 Auto Scaling 사용 설명서의 Amazon EC2 Auto Scaling 그룹을 참조하세요.

• Amazon EKS는 eks.amazonaws.com/capacityType: ON_DEMAND 용량 유형을 지정하는 관리형 노드 그룹의 모든 노드에 다음 Kubernetes 레이블을 추가합니다. 이 레이블을 사용하여 온디맨드 노드에서 상태 저장 또는 내결함성이 없는 애플리케이션을 예약할 수 있습니다.

작동 방식

관리되는 노드 그룹 내에서 스팟 인스턴스를 사용하려면 용량 유형을 spot으로 설정하여 관리형 노드 그룹을 생성합니다. 관리형 노드 그룹은 다음 스팟 모범 사례를 적용하여 사용자를 대신하여 Amazon EC2 Auto Scaling 그룹을 구성합니다.

• 스팟 노드가 최적의 스팟 용량 풀에서 프로비저닝되도록 다음 중 하나로 할당 전략을 설정합니다.

  • price-capacity-optimized(PCO) - Kubernetes 버전 1.28 이상의 클러스터에서 새 노드 그룹을 생성할 때 할당 전략은 price-capacity-optimized로 설정됩니다. 하지만 Amazon EKS 관리형 노드 그룹이 PCO 지원을 시작하기 전에 capacity-optimized로 이미 생성된 노드 그룹의 할당 전략은 변경되지 않습니다.

  • capacity-optimized(CO) - Kubernetes 버전 1.27 이하의 클러스터에서 새 노드 그룹을 생성할 때 할당 전략은 capacity-optimized로 설정됩니다.

  용량 할당에 사용할 수 있는 스팟 용량 풀 수를 늘리려면 여러 인스턴스 유형을 사용하도록 관리형 노드 그룹을 구성합니다.

• Amazon EC2 스팟 용량 리밸런싱이 활성화되어 있으므로 Amazon EKS가 스팟 노드를 정상적으로 비우고 리밸런싱하여 스팟 노드가 중단 위험이 높을 때 애플리케이션 중단을 최소화할 수 있습니다. 자세한 내용은 Amazon EC2 Auto Scaling 사용 설명서의 Amazon EC2 Auto Scaling 용량 재분배를 참조하세요.

  • 스팟 노드가 리밸런싱 권고를 수신하면 Amazon EKS는 자동으로 새로운 대체 스팟 노드를 시작하려고 시도합니다.

  • 교체 스팟 노드가 Ready 상태가 되면 Amazon EKS가 재조정 권장 사항을 받은 스팟 노드를 비우기 시작합니다. Amazon EKS는 최선을 다해 노드를 드레이닝합니다. 따라서 Amazon EKS가 기존 노드를 드레이닝하기 전에 대체 노드가 클러스터에 조인할 때까지 기다린다는 보장이 없습니다.

  • 대체 스팟 노드가 부트스트랩되고 Kubernetes의 Ready 상태에서 Amazon EKS 코드를 실행하고 리밸런싱 권장 사항을 받은 스팟 노드를 비웁니다. 스팟 노드를 코드화하면 서비스 컨트롤러가 이 스팟 노드로 새 요청을 보내지 않습니다. 또한 정상 활성 스팟 노드 목록에서 제거합니다. 스팟 노드를 비우면 실행 중인 Pods가 정상적으로 제거됩니다.

• Amazon EKS는 eks.amazonaws.com/capacityType: SPOT 용량 유형을 지정하는 관리형 노드 그룹의 모든 노드에 다음 Kubernetes 레이블을 추가합니다. 이 레이블을 사용하여 스팟 노드에서 내결함성 애플리케이션을 예약할 수 있습니다.

용량 유형 선택 시 고려 사항

온디맨드 또는 스팟 용량을 사용하여 노드 그룹을 배포할지 여부를 결정할 때 다음 조건을 고려해야 합니다.

• 스팟 인스턴스는 유연한 무상태 내결함성 애플리케이션에 적합합니다. 여기에는 배치 및 기계 학습 교육 워크로드, Apache Spark와 같은 빅 데이터 ETL, 대기열 처리 애플리케이션 및 무상태 API 엔드포인트가 포함됩니다. 스팟은 시간이 지남에 따라 변경될 수 있는 예비 Amazon EC2 용량이므로 중단 방지 워크로드에 스팟 용량을 사용하는 것이 좋습니다. 보다 구체적으로 말하면 스팟 용량은 필요한 용량을 사용할 수 없는 기간을 허용할 수 있는 워크로드에 적합합니다.

• 내결함성이 없는 애플리케이션의 경우 온디맨드를 사용하는 것이 좋습니다. 모니터링 및 운영 도구와 같은 클러스터 관리 도구, StatefulSets가 필요한 배포, 상태 유지 애플리케이션(예: 데이터베이스)이 여기에 포함됩니다.

• 스팟 인스턴스를 사용하는 동안 애플리케이션의 가용성을 극대화하려면 여러 인스턴스 유형을 사용하도록 스팟 관리 노드 그룹을 구성하는 것이 좋습니다. 여러 인스턴스 유형을 사용할 때는 다음 규칙을 적용하는 것이 좋습니다.

  • 관리형 노드 그룹 내에서 Cluster Autoscaler를 사용하는 경우 vCPU 및 메모리 리소스의 양이 같은 유연한 인스턴스 유형 집합을 사용하는 것이 좋습니다. 이는 클러스터의 노드가 예상대로 확장되도록 하기 위한 것입니다. 예를 들어 4개의 vCPU와 8개의 GiB 메모리가 필요한 경우 c3.xlarge, c4.xlarge, c5.xlarge, c5d.xlarge, c5a.xlarge, c5n.xlarge 또는 기타 유사한 인스턴스 유형을 사용합니다.

  • 애플리케이션 가용성을 높이려면 여러 스팟 관리형 노드 그룹을 배포하는 것이 좋습니다. 이를 위해 각 그룹은 동일한 vCPU 및 메모리 리소스를 가진 유연한 인스턴스 유형 집합을 사용해야 합니다. 예를 들어 4개의 vCPU와 8개의 GiB 메모리가 필요한 경우 c3.xlarge, c4.xlarge, c5.xlarge, c5d.xlarge, c5a.xlarge, c5n.xlarge 또는 기타 유사한 인스턴스 유형을 사용하여 관리형 노드 그룹을 하나 생성하고 m3.xlarge, m4.xlarge, m5.xlarge, m5d.xlarge, m5a.xlarge, m5n.xlarge 또는 기타 유사한 인스턴스 유형을 사용하여 두 번째 관리형 노드 그룹을 생성하는 것이 좋습니다.

  • 사용자 정의 시작 템플릿을 사용하는 스팟 용량 유형으로 노드 그룹을 배포하는 경우 API를 사용하여 여러 인스턴스 유형을 전달합니다. 시작 템플릿을 통해 단일 인스턴스 유형을 전달하지 마세요. 시작 템플릿을 사용하여 노드 그룹을 배포하는 방법에 대한 자세한 내용은 사용자 지정 시작 템플릿이 있는 관리형 노드 부분을 참조하세요.