관리형 노드 그룹(Managed Node Group)으로 노드 라이프사이클 간소화

관리형 노드 그룹(Managed Node Group)으로 노드 라이프사이클 간소화

Amazon EKS 관리형 노드 그룹이 노드(Amazon EC2 인스턴스)의 프로비저닝과 라이프사이클 관리를 자동화하는 방법을 설명합니다.

출처: 문서

본문

Amazon EKS 관리형 노드 그룹은 Amazon EKS Kubernetes 클러스터의 노드(Amazon EC2 인스턴스) 프로비저닝과 라이프사이클 관리를 자동화합니다.

Amazon EKS 관리형 노드 그룹을 사용하면 Kubernetes 애플리케이션을 실행할 컴퓨팅 용량을 제공하는 Amazon EC2 인스턴스를 별도로 프로비저닝하거나 등록할 필요가 없습니다. 단일 작업으로 클러스터의 노드를 생성, 자동 업데이트 또는 종료할 수 있습니다. 노드 업데이트와 종료는 애플리케이션이 계속 사용 가능하도록 노드를 자동으로 드레인(drain)합니다.

모든 관리형 노드는 Amazon EKS가 대신 관리하는 Amazon EC2 Auto Scaling 그룹의 일부로 프로비저닝됩니다. 인스턴스와 Auto Scaling 그룹을 포함한 모든 리소스는 사용자의 AWS 계정 내에서 실행됩니다. 각 노드 그룹은 사용자가 정의한 여러 가용 영역에 걸쳐 실행됩니다.

관리형 노드 그룹은 노드의 상태를 지속적으로 모니터링하는 노드 자동 복구(node auto repair)를 선택적으로 활용할 수도 있습니다. 감지된 문제에 자동으로 대응하고 가능할 때 노드를 교체합니다. 이는 최소한의 수동 개입으로 클러스터의 전반적인 가용성을 높이는 데 도움이 됩니다. 자세한 내용은 "노드 상태 문제 감지 및 자동 노드 복구 활성화"를 참고하세요.

Amazon EKS 콘솔, eksctl, AWS CLI, AWS API 또는 AWS CloudFormation을 포함한 인프라 코드 도구를 사용해 새 클러스터나 기존 클러스터에 관리형 노드 그룹을 추가할 수 있습니다. 관리형 노드 그룹의 일부로 시작된 노드에는 Kubernetes Cluster Autoscaler가 자동 검색할 수 있도록 태그가 자동으로 지정됩니다. 노드 그룹을 사용해 Kubernetes 라벨을 노드에 적용하고 언제든지 업데이트할 수 있습니다.

Amazon EKS 관리형 노드 그룹 사용에는 추가 비용이 없으며, 프로비저닝한 AWS 리소스에만 비용을 지불합니다. 여기에는 Amazon EC2 인스턴스, Amazon EBS 볼륨, Amazon EKS 클러스터 시간 및 기타 AWS 인프라가 포함됩니다. 최소 요금이나 선불 약정은 없습니다.

새 Amazon EKS 클러스터와 관리형 노드 그룹으로 시작하려면 "Amazon EKS 시작하기 – AWS Management Console 및 AWS CLI"를 참고하세요. 기존 클러스터에 관리형 노드 그룹을 추가하려면 "클러스터용 관리형 노드 그룹 생성"을 참고하세요.

관리형 노드 그룹 개념

Amazon EKS 관리형 노드 그룹은 Amazon EC2 인스턴스를 대신 생성하고 관리합니다.

  • 모든 관리형 노드는 Amazon EKS가 대신 관리하는 Amazon EC2 Auto Scaling 그룹의 일부로 프로비저닝됩니다. 또한 Amazon EC2 인스턴스와 Auto Scaling 그룹을 포함한 모든 리소스가 사용자의 AWS 계정 내에서 실행됩니다.
  • Amazon EKS는 관리형 노드 그룹의 스케일링 구성을 주기적으로 동기화하여 실제 Auto Scaling 그룹 값과 일치시킵니다. Cluster Autoscaler 같은 외부 주체가 Auto Scaling 그룹의 크기를 수정하면 DescribeNodegroup이 결국 이러한 변경을 반영합니다. 스케일링 구성을 명시적으로 수정하지 않고 노드 그룹 업데이트나 업그레이드를 시작하면 워크플로는 노드 그룹에 저장된 스케일링 구성이 아니라 현재 Auto Scaling 그룹 값을 사용합니다. 저장된 스케일링 구성은 UpdateNodegroupConfig 요청에 명시적으로 포함할 때만 우선합니다.
  • 관리형 노드 그룹의 Auto Scaling 그룹은 그룹을 만들 때 지정한 모든 서브넷에 걸쳐 있습니다.
  • Amazon EKS는 관리형 노드 그룹 리소스에 Kubernetes Cluster Autoscaler를 사용하도록 구성되도록 태그를 지정합니다.

중요: Amazon EBS 볼륨으로 백업되는 상태 저장 애플리케이션을 여러 가용 영역에 걸쳐 실행하면서 Kubernetes Cluster Autoscaler를 사용한다면, 각각 단일 가용 영역으로 범위가 지정된 여러 노드 그룹을 구성해야 합니다. 또한 --balance-similar-node-groups 기능을 활성화해야 합니다.

  • 관리형 노드를 배포할 때 더 큰 유연성과 사용자 지정을 위해 사용자 지정 런치 템플릿을 사용할 수 있습니다. 예를 들어 추가 kubelet 인수를 지정하고 사용자 지정 AMI를 사용할 수 있습니다. 자세한 내용은 "런치 템플릿으로 관리형 노드 사용자 지정"을 참고하세요. 관리형 노드 그룹을 처음 만들 때 사용자 지정 런치 템플릿을 사용하지 않으면 자동 생성된 런치 템플릿이 있습니다. 이 자동 생성 템플릿을 수동으로 수정하지 마세요. 오류가 발생할 수 있습니다.
  • Amazon EKS는 관리형 노드 그룹의 CVE 및 보안 패치에 대해 공동 책임 모델을 따릅니다. 관리형 노드가 Amazon EKS 최적화 AMI를 실행할 때 버그나 문제가 보고되면 Amazon EKS가 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에는 배포할 수 없습니다. 관리형 노드 그룹은 AWS Local Zones에서 만들 수 있습니다. 자세한 내용은 "AWS Local Zones로 저지연 EKS 클러스터 시작"을 참고하세요.
  • 단일 클러스터 내에서 여러 관리형 노드 그룹을 만들 수 있습니다. 예를 들어 일부 워크로드에는 표준 Amazon EKS 최적화 Amazon Linux AMI를 사용하는 노드 그룹을, GPU 지원이 필요한 워크로드에는 GPU 변형을 사용하는 다른 노드 그룹을 만들 수 있습니다.
  • 관리형 노드 그룹이 Amazon EC2 인스턴스 상태 확인 실패를 겪으면 Amazon EKS는 문제 진단을 돕기 위해 오류 코드를 반환합니다. 자세한 내용은 "관리형 노드 그룹 오류 코드"를 참고하세요.
  • Amazon EKS는 관리형 노드 그룹 인스턴스에 Kubernetes 라벨을 추가합니다. Amazon EKS가 제공하는 이 라벨은 eks.amazonaws.com 접두사가 붙습니다.
  • Amazon EKS는 종료 또는 업데이트 중에 Kubernetes API를 사용해 노드를 자동으로 드레인합니다.
  • AZRebalance로 노드를 종료하거나 원하는 노드 수를 줄일 때 Pod 중단 예산(Pod disruption budget)은 존중되지 않습니다. 이러한 작업은 노드의 Pod를 축출(evict)하려고 시도합니다. 하지만 15분 이상 걸리면 노드의 모든 Pod가 종료되었는지와 무관하게 노드가 종료됩니다. 노드가 종료될 때까지의 기간을 연장하려면 Auto Scaling 그룹에 라이프사이클 훅을 추가하세요. 자세한 내용은 Amazon EC2 Auto Scaling 사용 설명서의 "라이프사이클 훅 추가"를 참고하세요.
  • Spot 중단 알림이나 용량 리밸런스 알림을 받은 후 드레인 프로세스를 올바르게 실행하려면 CapacityRebalance가 true로 설정되어 있어야 합니다.
  • 관리형 노드 그룹 업데이트는 Pod에 설정한 Pod 중단 예산을 존중합니다. 자세한 내용은 "노드 업데이트의 각 단계 이해"를 참고하세요.
  • Amazon EKS 관리형 노드 그룹 사용에는 추가 비용이 없습니다. 프로비저닝한 AWS 리소스에만 비용을 지불합니다.
  • 노드의 Amazon EBS 볼륨을 암호화하려면 런치 템플릿을 사용해 노드를 배포할 수 있습니다. 런치 템플릿 없이 암호화된 Amazon EBS 볼륨으로 관리형 노드를 배포하려면 계정에서 생성된 모든 새 Amazon EBS 볼륨을 암호화하세요. 자세한 내용은 Amazon EC2 사용 설명서의 "기본 암호화"를 참고하세요.

관리형 노드 그룹 용량 유형

관리형 노드 그룹을 만들 때 On-Demand 또는 Spot 용량 유형 중 하나를 선택할 수 있습니다. Amazon EKS는 On-Demand 인스턴스만 또는 Amazon EC2 Spot 인스턴스만 포함하는 Amazon EC2 Auto Scaling 그룹으로 관리형 노드 그룹을 배포합니다. 단일 Kubernetes 클러스터 내에서 내결함성 애플리케이션용 Pod를 Spot 관리형 노드 그룹에, 내결함성이 낮은 애플리케이션을 On-Demand 노드 그룹에 스케줄할 수 있습니다. 기본적으로 관리형 노드 그룹은 On-Demand Amazon EC2 인스턴스를 배포합니다.

On-Demand – On-Demand 인스턴스를 사용하면 장기 약정 없이 컴퓨팅 용량에 대해 초 단위로 비용을 지불합니다.

기본적으로 Capacity Type을 지정하지 않으면 관리형 노드 그룹은 On-Demand 인스턴스로 프로비저닝됩니다. 관리형 노드 그룹은 다음 설정을 적용해 사용자 대신 Amazon EC2 Auto Scaling 그룹을 구성합니다.

  • On-Demand 용량을 프로비저닝하는 할당 전략은 prioritized로 설정됩니다. 관리형 노드 그룹은 API로 전달된 인스턴스 유형의 순서를 사용해 On-Demand 용량을 충족할 때 어떤 인스턴스 유형을 먼저 사용할지 결정합니다. 예를 들어 c5.large, c4.large, c3.large 순서로 세 가지 인스턴스 유형을 지정할 수 있습니다. On-Demand 인스턴스가 시작될 때 관리형 노드 그룹은 c5.large부터, 그다음 c4.large, 그다음 c3.large로 On-Demand 용량을 충족합니다. 자세한 내용은 Amazon EC2 Auto Scaling 사용 설명서의 "Amazon EC2 Auto Scaling 그룹"을 참고하세요.
  • Amazon EKS는 관리형 노드 그룹의 모든 노드에 용량 유형을 지정하는 다음 Kubernetes 라벨을 추가합니다: eks.amazonaws.com/capacityType: ON_DEMAND. 이 라벨을 사용해 상태 저장 또는 내결함성이 낮은 애플리케이션을 On-Demand 노드에 스케줄할 수 있습니다.

Spot – Amazon EC2 Spot 인스턴스는 On-Demand 가격에서 큰 할인을 제공하는 예비 Amazon EC2 용량입니다. EC2가 용량을 되찾아야 할 때 Amazon EC2 Spot 인스턴스는 2분 중단 알림으로 중단될 수 있습니다. 자세한 내용은 Amazon EC2 사용 설명서의 "Spot 인스턴스"를 참고하세요. Amazon EKS 클러스터에서 실행되는 컴퓨팅 노드의 비용을 최적화하도록 Amazon EC2 Spot 인스턴스로 관리형 노드 그룹을 구성할 수 있습니다.

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

  • Spot 노드가 최적의 Spot 용량 풀에 프로비저닝되도록 할당 전략이 다음 중 하나로 설정됩니다.
    • price-capacity-optimized(PCO) – Kubernetes 버전 1.28 이상의 클러스터에서 새 노드 그룹을 만들 때 할당 전략이 price-capacity-optimized로 설정됩니다. 그러나 Amazon EKS 관리형 노드 그룹이 PCO를 지원하기 시작하기 전에 capacity-optimized로 이미 생성된 노드 그룹의 할당 전략은 변경되지 않습니다.
    • capacity-optimized(CO) – Kubernetes 버전 1.27 이하의 클러스터에서 새 노드 그룹을 만들 때 할당 전략이 capacity-optimized로 설정됩니다.
  • 용량을 할당할 수 있는 Spot 용량 풀 수를 늘리려면 관리형 노드 그룹이 여러 인스턴스 유형을 사용하도록 구성하세요.
  • Amazon EC2 Spot Capacity Rebalancing이 활성화되어 Spot 노드가 중단 위험이 높을 때 Amazon EKS가 애플리케이션 중단을 최소화하도록 Spot 노드를 정상적으로 드레인하고 리밸런스할 수 있습니다. 자세한 내용은 Amazon EC2 Auto Scaling 사용 설명서의 "Amazon EC2 Auto Scaling Capacity Rebalancing"을 참고하세요.
  • Spot 노드가 리밸런스 권장 사항을 받으면 Amazon EKS는 자동으로 새 교체 Spot 노드를 시작하려고 시도합니다.
  • 교체 Spot 노드가 Ready 상태가 되기 전에 Spot 2분 중단 알림이 도착하면 Amazon EKS는 리밸런스 권장 사항을 받은 Spot 노드 드레인을 시작합니다. Amazon EKS는 최선의 노력(best-effort) 방식으로 노드를 드레인합니다. 따라서 교체 노드가 클러스터에 가입할 때까지 Amazon EKS가 기존 노드 드레인을 기다릴 것이라는 보장은 없습니다.
  • 교체 Spot 노드가 부트스트랩되어 Kubernetes에서 Ready 상태가 되면 Amazon EKS는 리밸런스 권장 사항을 받은 Spot 노드를 cordon하고 드레인합니다. Spot 노드를 cordon하면 서비스 컨트롤러가 이 Spot 노드에 새 요청을 보내지 않도록 합니다. 또한 정상 활성 Spot 노드 목록에서 제거합니다. Spot 노드를 드레인하면 실행 중인 Pod가 정상적으로 축출되도록 보장합니다.
  • Amazon EKS는 관리형 노드 그룹의 모든 노드에 용량 유형을 지정하는 다음 Kubernetes 라벨을 추가합니다: eks.amazonaws.com/capacityType: SPOT. 이 라벨을 사용해 내결함성 애플리케이션을 Spot 노드에 스케줄할 수 있습니다.

중요: EC2는 Spot 인스턴스를 종료하기 2분 전에 Spot 중단 알림을 발행합니다. 그러나 Spot 노드의 Pod는 정상 종료를 위한 전체 2분 창을 받지 못할 수 있습니다. EC2가 알림을 발행하면 Amazon EKS가 Pod 축출을 시작하기 전에 지연이 있습니다. 축출은 Kubernetes API 서버를 보호하기 위해 순차적으로 발생하므로, 동시에 여러 Spot 회수가 일어나는 동안 일부 Pod는 지연된 축출 알림을 받을 수 있습니다. Pod는 특히 Pod 밀도가 높은 노드, 동시 회수 중이거나 긴 종료 유예 기간을 사용할 때 종료 신호를 받지 않고 강제 종료될 수 있습니다. Spot 워크로드의 경우 애플리케이션이 중단 허용형이 되도록 설계하고, 30초 이하의 종료 유예 기간을 사용하고, 오래 실행되는 preStop 훅을 피하고, Pod 축출 지표를 모니터링해 클러스터의 실제 유예 기간을 이해할 것을 권장합니다. 보장된 정상 종료가 필요한 워크로드에는 On-Demand 용량을 사용할 것을 권장합니다.

On-Demand 또는 Spot 용량으로 노드 그룹을 배포할지 결정할 때 다음 조건을 고려해야 합니다.

  • Spot 인스턴스는 상태 비저장(stateless)이고 내결함성이 있으며 유연한 애플리케이션에 적합합니다. 여기에는 배치 및 머신 러닝 학습 워크로드, Apache Spark와 같은 빅데이터 ETL, 큐 처리 애플리케이션, 상태 비저장 API 엔드포인트가 포함됩니다. Spot은 시간이 지남에 따라 변할 수 있는 예비 Amazon EC2 용량이므로, 중단 허용형 워크로드에 Spot 용량을 사용할 것을 권장합니다. 더 구체적으로, Spot 용량은 필요한 용량을 사용할 수 없는 기간을 견딜 수 있는 워크로드에 적합합니다.
  • 내결함성이 낮은 애플리케이션에는 On-Demand를 사용할 것을 권장합니다. 여기에는 모니터링 및 운영 도구 같은 클러스터 관리 도구, StatefulSets를 요구하는 배포, 데이터베이스 같은 상태 저장 애플리케이션이 포함됩니다.

Spot 인스턴스를 사용하면서 애플리케이션 가용성을 극대화하려면 Spot 관리형 노드 그룹이 여러 인스턴스 유형을 사용하도록 구성할 것을 권장합니다. 여러 인스턴스 유형을 사용할 때 다음 규칙을 적용할 것을 권장합니다.

  • 관리형 노드 그룹 내에서 Cluster Autoscaler를 사용한다면 동일한 vCPU 및 메모리 리소스를 가진 유연한 인스턴스 유형 집합을 사용할 것을 권장합니다. 이는 클러스터의 노드가 예상대로 확장되도록 보장하기 위한 것입니다. 예를 들어 4 vCPU와 8 GiB 메모리가 필요하다면 c3.xlarge, c4.xlarge, c5.xlarge, c5d.xlarge, c5a.xlarge, c5n.xlarge 또는 유사한 인스턴스 유형을 사용하세요.
  • 애플리케이션 가용성을 높이려면 여러 Spot 관리형 노드 그룹을 배포할 것을 권장합니다. 이를 위해 각 그룹은 동일한 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 또는 유사한 인스턴스 유형으로 생성할 것을 권장합니다.
  • 사용자 지정 런치 템플릿을 사용하는 Spot 용량 유형으로 노드 그룹을 배포할 때 API를 사용해 여러 인스턴스 유형을 전달하세요. 런치 템플릿을 통해 단일 인스턴스 유형을 전달하지 마세요. 런치 템플릿을 사용한 노드 그룹 배포에 대한 자세한 내용은 "런치 템플릿으로 관리형 노드 사용자 지정"을 참고하세요.

더 알아보기 (Learn more)