**이 페이지 개선에 도움 주기** 이 사용자 가이드에 기여하려면 모든 페이지의 오른쪽 창에 있는 **GitHub에서 이 페이지 편집** 링크를 선택합니다. # 관리형 노드 그룹을 사용한 노드 수명 주기 간소화 Amazon EKS 관리형 노드 그룹은 Amazon EKS Kubernetes 클러스터의 노드(Amazon EC2 인스턴스) 프로비저닝 및 수명 주기 관리를 자동화합니다. Amazon EKS 관리형 노드 그룹을 사용하면 Kubernetes 애플리케이션을 실행하기 위해 컴퓨팅 용량을 제공하는 Amazon EC2 인스턴스를 별도로 프로비저닝하거나 등록할 필요가 없습니다. 한 번의 조작으로 클러스터에 대한 노드를 자동으로 생성, 업데이트 또는 종료할 수 있습니다. 노드 업데이트 및 종료는 자동으로 노드를 드레이닝하여 애플리케이션을 계속 사용할 수 있도록 합니다. 모든 관리형 노드는 Amazon EKS에서 관리하는 Amazon EC2 Auto Scaling 그룹의 일부로 프로비저닝됩니다. 인스턴스 및 Auto Scaling 그룹을 포함한 모든 리소스는 AWS 계정 내에서 실행됩니다. 각 노드 그룹은 정의한 여러 가용 영역에서 실행됩니다. 관리형 노드 그룹은 노드 자동 복구를 선택적으로 활용하여 노드 상태를 지속적으로 모니터링할 수도 있습니다. 감지된 문제에 자동으로 대응하고 가능한 경우 노드를 교체합니다. 이렇게 하면 수동 개입을 최소화하면서 클러스터의 전반적인 가용성을 높일 수 있습니다. 자세한 내용은 [노드 상태 문제 감지 및 노드 자동 복구 활성화](node-health.md) 섹션을 참조하세요. Amazon EKS 콘솔, `eksctl`, AWS CLI, AWS API 또는 AWS CloudFormation을 포함한 코드형 인프라를 사용하여 관리형 노드 그룹을 신규 또는 기존 클러스터에 추가할 수 있습니다. 관리형 노드 그룹의 일부로 시작된 노드는 Kubernetes [Cluster Autoscaler](https://github.com/kubernetes/autoscaler/blob/master/cluster-autoscaler/cloudprovider/aws/README.md)에서 자동 검색할 수 있도록 자동으로 태그가 지정됩니다. 노드 그룹을 사용하여 Kubernetes 레이블을 노드에 적용하고 언제든지 업데이트할 수 있습니다. Amazon EKS 관리형 노드 그룹을 사용하기 위한 추가 비용은 없으며 프로비저닝한 AWS 리소스에 대해서만 비용을 지불합니다. 여기에는 Amazon EC2 인스턴스, Amazon EBS 볼륨, Amazon EKS 클러스터 시간 및 기타 AWS 인프라가 포함됩니다. 최소 요금 및 선수금은 없습니다. 새 Amazon EKS 클러스터 및 관리형 노드 그룹을 시작하려면 [Amazon EKS 시작하기 - AWS Management Console 및 AWS CLI](getting-started-console.md) 부분을 참조하세요. 기존 클러스터에 관리형 노드 그룹을 추가하려면 [클러스터에 대한 관리형 노드 그룹 생성](create-managed-node-group.md)을 참조하세요. ## 관리형 노드 그룹 개념 + Amazon EKS 관리형 노드 그룹은 사용자를 위해 Amazon EC2 인스턴스를 생성하고 관리합니다. + 모든 관리형 노드는 Amazon EKS에서 관리하는 Amazon EC2 Auto Scaling 그룹의 일부로 프로비저닝됩니다. 게다가 Amazon EC2 인스턴스 및 Auto Scaling 그룹을 포함한 모든 리소스는 AWS 계정 내에서 실행됩니다. + 관리형 노드 그룹의 Auto Scaling 그룹은 그룹을 생성할 때 지정하는 모든 서브넷에 걸쳐 있습니다. + Amazon EKS는 관리형 노드 그룹 리소스에 태그를 지정하여 Kubernetes [Cluster Autoscaler](https://github.com/kubernetes/autoscaler/blob/master/cluster-autoscaler/cloudprovider/aws/README.md)를 사용하도록 구성합니다. **중요** Amazon EBS 볼륨에 의해 백업되고 Kubernetes [Cluster Autoscaler](https://github.com/kubernetes/autoscaler/blob/master/cluster-autoscaler/cloudprovider/aws/README.md)를 사용하는 상태 기반 애플리케이션을 여러 가용 영역에서 실행하는 경우 각 단일 가용 영역으로 범위가 지정된 여러 노드 그룹을 구성해야 합니다. 또한 `--balance-similar-node-groups` 기능을 활성화해야 합니다. + 관리형 노드를 배포할 때 더 높은 수준의 유연성과 사용자 지정을 위해 사용자 정의 시작 템플릿을 사용할 수 있습니다. 예를 들어, 추가`kubelet` 인수를 지정하고 사용자 지정 AMI를 사용할 수 있습니다. 자세한 내용은 [시작 템플릿을 사용한 관리형 노드 사용자 지정](launch-templates.md) 섹션을 참조하세요. 관리형 노드 그룹을 처음 생성할 때 사용자 정의 시작 템플릿을 사용하지 않으면 자동 생성된 시작 템플릿이 표시됩니다. 이 자동 생성된 템플릿을 수동으로 수정하지 마세요. 수정하면 오류가 발생합니다. + Amazon EKS는 관리형 노드 그룹의 CVE 및 보안 패치에 대한 공동 책임 모델을 따릅니다. 관리형 노드가 Amazon EKS 최적화 AMI를 실행하는 경우 버그나 문제가 보고될 때 패치 버전의 AMI를 빌드해야 합니다. 수정 사항을 게시할 수 있습니다. 그러나 이렇게 패치된 AMI 버전은 사용자가 관리형 노드 그룹에 배포해야 합니다. 관리형 노드가 사용자 지정 AMI를 실행하는 경우 버그나 문제가 보고되고 AMI를 배포할 때 패치 버전의 AMI를 빌드해야 합니다. 자세한 내용은 [클러스터에 대한 관리형 노드 그룹 업데이트](update-managed-node-group.md) 섹션을 참조하세요. + Amazon EKS 관리형 노드 그룹은 퍼블릭 서브넷과 프라이빗 서브넷 모두에서 시작할 수 있습니다. 2020년 4월 22일 또는 이후에 퍼블릭 서브넷에서 관리형 노드 그룹을 시작하는 경우 인스턴스가 클러스터에 성공적으로 조인하려면 서브넷에서 `MapPublicIpOnLaunch`를 true로 설정해야 합니다. 2020년 3월 26일 이후에 `eksctl` 또는 [Amazon EKS 벤딩 AWS CloudFormation 템플릿](creating-a-vpc.md)을 사용하여 퍼블릭 서브넷을 생성한 경우 이 설정이 이미 true로 설정되어 있습니다. 2020년 3월 26일 이전에 퍼블릭 서브넷을 생성한 경우 해당 설정을 수동으로 변경해야 합니다. 자세한 내용은 [서브넷의 퍼블릭 IPv4 주소 지정 속성 수정](https://docs.aws.amazon.com/vpc/latest/userguide/vpc-ip-addressing.html#subnet-public-ip) 섹션을 참조하세요. + 프라이빗 서브넷에 관리형 노드 그룹을 배포할 때 컨테이너 이미지를 가져오기 위해 Amazon ECR에 액세스할 수 있는지 확인해야 합니다. NAT 게이트웨이를 서브넷의 라우팅 테이블에 연결하거나 다음 [AWS 프라이빗 링크 VPC 엔드포인트](https://docs.aws.amazon.com/AmazonECR/latest/userguide/vpc-endpoints.html#ecr-setting-up-vpc-create)를 추가하여 이 작업을 수행할 수 있습니다. + 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` 일반적으로 사용되는 다른 서비스와 엔드포인트는 [인터넷 액세스가 제한된 프라이빗 클러스터 배포](private-clusters.md) 섹션을 참조하세요. + 관리형 노드 그룹은 [AWS Outposts](eks-outposts.md)나 [AWS Wavelength](https://docs.aws.amazon.com/wavelength/)에 배치할 수 없습니다. 관리형 노드 그룹은 [AWS 로컬 영역](https://aws.amazon.com/about-aws/global-infrastructure/localzones/)에서 생성할 수 있습니다. 자세한 내용은 [AWS 로컬 영역을 통해 지연 시간이 짧은 EKS 클러스터 시작](local-zones.md) 섹션을 참조하세요. + 단일 클러스터 내에서 여러 관리형 노드 그룹을 생성할 수 있습니다. 예를 들어, 일부 워크로드에는 표준 Amazon EKS 최적화 Amazon Linux AMI를 사용하는 노드 그룹을 생성하고 GPU 지원이 필요한 워크로드에는 GPU 변형을 사용하는 다른 노드 그룹을 생성할 수 있습니다. + 관리형 노드 그룹에 [Amazon EC2 인스턴스 상태 확인](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/monitoring-system-instance-status-check.html) 오류가 발생하면 Amazon EKS는 문제 진단에 도움이 되는 오류 메시지를 반환합니다. 자세한 내용은 [관리형 노드 그룹 오류](troubleshooting.md#troubleshoot-managed-node-groups) 섹션을 참조하세요. + Amazon EKS는 관리형 노드 그룹 인스턴스에 Kubernetes 레이블을 추가합니다. 이러한 Amazon EKS 제공 레이블에는 `eks.amazonaws.com` 접두사가 붙습니다. + Amazon EKS는 종료 또는 업데이트 중에 Kubernetes API를 사용하여 노드를 자동으로 비웁니다. + `AZRebalance`로 노드를 종료하거나 원하는 노드 수를 줄이는 경우 포드 중단 예산은 반영되지 않습니다. 이러한 작업은 노드에서 포드 제거를 시도합니다. 그러나 15분 넘게 걸리면 노드의 모든 포드가 종료되었는지 여부에 관계없이 노드가 종료됩니다. 노드가 종료될 때까지 기간을 연장하려면 Auto Scaling 그룹에 수명 주기 후크를 추가하세요. 자세한 내용을 알아보려면 *Amazon EC2 Auto Scaling 사용 설명서*의 [수명 주기 후크 추가](https://docs.aws.amazon.com/autoscaling/ec2/userguide/adding-lifecycle-hooks.html)를 참조하세요. + 스팟 중단 알림 또는 용량 재조정 알림을 수신한 후 드레인 프로세스를 올바르게 실행하려면 `CapacityRebalance`를 `true`로 설정해야 합니다. + 관리형 노드 그룹을 업데이트하면 포드에 대해 설정한 포드 중단 예산을 준수합니다. 자세한 내용은 [노드 업데이트의 각 단계 이해](managed-node-update-behavior.md) 섹션을 참조하세요. + Amazon EKS 관리형 노드 그룹을 사용하는 데 따른 추가 비용은 없습니다. 프로비저닝하는 AWS 리소스에 대해서만 비용을 지불합니다. + 노드에 대해 Amazon EBS 볼륨을 암호화하려는 경우 시작 템플릿을 사용하여 노드를 배포할 수 있습니다. 시작 템플릿을 사용하지 않고 암호화된 Amazon EBS 볼륨이 있는 관리형 노드를 배포하려면 계정에 생성된 모든 새 Amazon EBS 볼륨을 암호화합니다. 자세한 내용은 *Amazon EC2 사용 설명서*에서 [기본적으로 암호화](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/EBSEncryption.html#encryption-by-default)를 참조하세요. ## 관리형 노드 그룹 용량 관리형 노드 그룹을 생성할 때 온디맨드 또는 스팟 용량 유형을 선택할 수 있습니다. Amazon EKS는 온디맨드 또는 Amazon EC2 스팟 인스턴스만 포함하는 Amazon EC2 Auto Scaling 그룹과 함께 관리형 노드 그룹을 배포합니다. 내결함성 애플리케이션이 스팟 관리형 노드 그룹에 대해 포드를 예약하고, 단일 Kubernetes 클러스터 내의 온디맨드 노드 그룹에 내결함성 애플리케이션을 예약할 수 있습니다. 기본적으로 관리형 노드 그룹은 온디맨드 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 그룹](https://docs.aws.amazon.com/autoscaling/ec2/userguide/asg-purchase-options.html#asg-allocation-strategies)을 참조하세요. + Amazon EKS는 용량 유형을 지정하는 관리형 노드 그룹의 모든 노드에 다음 Kubernetes 레이블을 추가합니다. `eks.amazonaws.com/capacityType: ON_DEMAND`. 이 레이블을 사용하여 온디맨드 노드에서 상태 저장 또는 내결함성이 없는 애플리케이션을 예약할 수 있습니다. ### 스팟 Amazon EC2 스팟 인스턴스는 온디맨드 가격에서 큰 폭의 할인을 제공하는 여분의 Amazon EC2 용량입니다. EC2에서 용량을 복구하려면 2분 중단 알림으로 Amazon EC2 스팟 인스턴스를 중단시킬 수 있습니다. 자세한 내용은 *Amazon EC2 사용 설명서*의 [스팟 인스턴스](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/using-spot-instances.html)를 참조하세요. Amazon EC2 스팟 인스턴스로 관리형 노드 그룹을 구성하여 Amazon EKS 클러스터에서 실행되는 컴퓨팅 노드의 비용을 최적화할 수 있습니다. 관리되는 노드 그룹 내에서 스팟 인스턴스를 사용하려면 용량 유형을 `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 용량 재분배](https://docs.aws.amazon.com/autoscaling/ec2/userguide/capacity-rebalance.html)를 참조하세요. + 스팟 노드가 리밸런싱 권고를 수신하면 Amazon EKS는 자동으로 새로운 대체 스팟 노드를 시작하려고 시도합니다. + 교체 스팟 노드가 `Ready` 상태가 되면 Amazon EKS가 재조정 권장 사항을 받은 스팟 노드를 비우기 시작합니다. Amazon EKS는 최선을 다해 노드를 드레이닝합니다. 따라서 Amazon EKS가 기존 노드를 드레이닝하기 전에 대체 노드가 클러스터에 조인할 때까지 기다린다는 보장이 없습니다. + 대체 스팟 노드가 부트스트랩되고 `Ready` 상태에서 Amazon EKS 코드를 실행하고 리밸런싱 권장 사항을 받은 스팟 노드를 비웁니다. 스팟 노드를 코드화하면 서비스 컨트롤러가 이 스팟 노드로 새 요청을 보내지 않습니다. 또한 정상 활성 스팟 노드 목록에서 제거합니다. 스팟 노드를 비우면 실행 중인 포드가 정상적으로 제거됩니다. + Amazon EKS는 용량 유형을 지정하는 관리형 노드 그룹의 모든 노드에 다음 Kubernetes 레이블을 추가합니다. `eks.amazonaws.com/capacityType: SPOT`. 이 레이블을 사용하여 스팟 노드에서 내결함성 애플리케이션을 예약할 수 있습니다. **중요** EC2는 스팟 인스턴스를 종료하기 2분 전에 [스팟 중단 알림](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/spot-instance-termination-notices.html)을 발행합니다. 그러나 스팟 노드의 포드는 정상적인 종료를 위한 전체 2분의 기간을 받지 못할 수도 있습니다. EC2가 알림을 발행하면 Amazon EKS가 포드 제거를 시작하기 전에 지연이 발생합니다. 제거는 Kubernetes API 서버를 보호하기 위해 순차적으로 수행되므로 여러 동시 스팟 회수 중에 일부 포드가 제거 지연 알림을 수신할 수 있습니다. 포드는 특히 포드 밀도가 높은 노드에서 동시 회수 중에 또는 긴 종료 유예 기간을 사용할 때 종료 신호를 수신하지 않고 강제로 종료될 수 있습니다. 스팟 워크로드의 경우 중단 방지로 애플리케이션을 설계하고 30초 이하의 종료 유예 기간을 사용하며 장시간 실행되는 preStop 후크를 피하고 포드 제거 지표를 모니터링하여 클러스터의 실제 유예 기간을 이해하는 것이 좋습니다. 정상적인 종료를 보장해야 하는 워크로드의 경우 대신 온디맨드 용량을 사용하는 것이 좋습니다. 온디맨드 또는 스팟 용량을 사용하여 노드 그룹을 배포할지 여부를 결정할 때 다음 조건을 고려해야 합니다. + 스팟 인스턴스는 유연한 무상태 내결함성 애플리케이션에 적합합니다. 여기에는 배치 및 기계 학습 교육 워크로드, Apache Spark와 같은 빅 데이터 ETL, 대기열 처리 애플리케이션 및 무상태 API 엔드포인트가 포함됩니다. 스팟은 시간이 지남에 따라 변경될 수 있는 예비 Amazon EC2 용량이므로 중단 방지 워크로드에 스팟 용량을 사용하는 것이 좋습니다. 보다 구체적으로 말하면 스팟 용량은 필요한 용량을 사용할 수 없는 기간을 허용할 수 있는 워크로드에 적합합니다. + 내결함성이 없는 애플리케이션의 경우 온디맨드를 사용하는 것이 좋습니다. 모니터링 및 운영 도구와 같은 클러스터 관리 도구, `StatefulSets`가 필요한 배포, 상태 유지 애플리케이션(예: 데이터베이스)이 여기에 포함됩니다. + 스팟 인스턴스를 사용하는 동안 애플리케이션의 가용성을 극대화하려면 여러 인스턴스 유형을 사용하도록 스팟 관리 노드 그룹을 구성하는 것이 좋습니다. 여러 인스턴스 유형을 사용할 때는 다음 규칙을 적용하는 것이 좋습니다. + 관리형 노드 그룹 내에서 [Cluster Autoscaler](https://github.com/kubernetes/autoscaler/blob/master/cluster-autoscaler/cloudprovider/aws/README.md)를 사용하는 경우 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를 사용하여 여러 인스턴스 유형을 전달합니다. 시작 템플릿을 통해 단일 인스턴스 유형을 전달하지 마세요. 시작 템플릿을 사용하여 노드 그룹을 배포하는 방법에 대한 자세한 내용은 [시작 템플릿을 사용한 관리형 노드 사용자 지정](launch-templates.md) 부분을 참조하세요. # 클러스터에 대한 관리형 노드 그룹 생성 이 주제는 Amazon EKS 클러스터에 등록하는 노드의 Amazon EKS 관리형 노드 그룹을 시작하는 데 도움이 됩니다. 노드가 클러스터에 조인한 이후 Kubernetes 애플리케이션을 배포할 수 있습니다. Amazon EKS 관리형 노드 그룹을 처음 시작하는 경우, [Amazon EKS 시작하기](getting-started.md)의 가이드 중 하나를 따르는 것이 좋습니다. 이 가이드에서는 노드가 있는 Amazon EKS 클러스터를 생성하기 위한 시연을 제공합니다. **중요** Amazon EKS 노드는 표준 Amazon EC2 인스턴스입니다. 일반 Amazon EC2 가격을 기준으로 요금이 청구됩니다. 자세한 내용은 [Amazon EC2 요금](https://aws.amazon.com/ec2/pricing/)을 참조하세요. AWS Outposts 또는 AWS Wavelength가 활성화된 AWS 리전에서는 관리형 노드를 만들 수 없습니다. 대신 자체 관리형 노드만 생성할 수 있습니다. 자세한 내용은 [자체 관리형 Amazon Linux 노드 생성](launch-workers.md), [자체 관리형 Microsoft Windows 노드 생성](launch-windows-workers.md), [자체 관리형 Bottlerocket 노드 생성](launch-node-bottlerocket.md) 섹션을 참조하세요. Outpost에서 자체 관리형 Amazon Linux 노드 그룹을 생성할 수도 있습니다. 자세한 내용은 [AWS Outposts에 Amazon Linux 노드 생성](eks-outposts-self-managed-nodes.md) 섹션을 참조하세요. Amazon EKS 최적화 Linux 또는 Bottlerocket에 포함된 `bootstrap.sh` 파일에 [AMI ID를 지정](launch-templates.md#launch-template-custom-ami)하지 않는 경우 관리형 노드 그룹은 최대 값 수 `maxPods`를 적용합니다. vCPU가 30개 이하인 인스턴스의 경우 최대 수는 `110` 입니다. vCPU가 30개 이상인 인스턴스의 경우 최대 개수가 `250` 로 바뀝니다. 이 적용은 `maxPodsExpression`을 포함하여 다른 `maxPods` 구성을 재정의합니다. `maxPods`가 결정되는 방법과 이를 사용자 지정하는 방법에 대한 자세한 내용은 [maxPods 결정 방법](choosing-instance-type.md#max-pods-precedence) 섹션을 참조하세요. + 기존 Amazon EKS 클러스터. 배포하려면 [Amazon EKS 클러스터 생성](create-cluster.md) 섹션을 참조하세요. + 노드가 사용할 기존 IAM 역할. 파일을 만들려면 [Amazon EKS 노드 IAM 역할](create-node-role.md) 섹션을 참조하세요. 이 역할에 VPC CNI에 대한 정책 중 하나도 없는 경우 VPC CNI 포드에 대해 다음과 같은 별도의 역할이 필요합니다. + (선택 사항이지만 권장됨) 필요한 IAM 정책이 연결된 자체 IAM 역할로 구성된 Kubernetes용 Amazon VPC CNI 플러그인 추가 기능. 자세한 내용은 [IRSA를 사용하도록 Amazon VPC CNI 플러그인 구성](cni-iam-role.md) 섹션을 참조하세요. + [최적의 Amazon EC2 노드 인스턴스 유형 선택](choosing-instance-type.md) 에 나열된 고려 사항에 익숙합니다. 선택하는 인스턴스 유형에 따라 클러스터 및 VPC에 대한 추가 전제 조건이 있을 수 있습니다. + Windows 관리형 노드 그룹을 추가하려면 먼저 클러스터에 대한 Windows 지원을 활성화해야 합니다. 자세한 내용은 [EKS 클러스터에 Windows 노드 배포](windows-support.md) 섹션을 참조하세요. 다음 중 하나를 사용하여 관리형 노드 그룹을 생성할 수 있습니다. + [`eksctl`](#eksctl_create_managed_nodegroup) + [AWS Management Console](#console_create_managed_nodegroup) ## `eksctl` **eksctl로 관리형 노드 그룹 만들기** 이 절차에는 `eksctl` 버전 `0.215.0` 이상이 필요합니다. 버전은 다음 명령을 통해 확인할 수 있습니다. ``` eksctl version ``` `eksctl` 설치 또는 업데이트에 대한 지침은 `eksctl` 설명서의 [Installation](https://eksctl.io/installation)를 참조하세요. 1. (선택 사항) **AmazonEKS\$1CNI\$1Policy** 관리형 IAM 정책이 [Amazon EKS 노드 IAM 역할](create-node-role.md)에 연결되어 있는 경우 대신 Kubernetes `aws-node` 서비스 계정에 연결한 IAM 역할에 할당하는 것이 좋습니다. 자세한 내용은 [IRSA를 사용하도록 Amazon VPC CNI 플러그인 구성](cni-iam-role.md) 섹션을 참조하세요. 1. 사용자 정의 시작 템플릿을 사용하거나 사용하지 않고 관리형 노드 그룹을 생성합니다. 시작 템플릿을 수동으로 지정하면 노드 그룹을 더욱 수월하게 사용자 지정할 수 있습니다. 예를 들어, Amazon EKS 최적화 AMI의 `boostrap.sh` 스크립트에 사용자 지정 AMI를 배포하거나 인수를 제공할 수 있습니다. 사용 가능한 모든 옵션 및 기본값의 전체 목록을 보려면 다음 명령을 입력합니다. ``` eksctl create nodegroup --help ``` 다음 명령에서 *my-cluster*를 클러스터 이름으로 바꾸고 *my-mng*를 노드 그룹 이름으로 바꿉니다. 노드 그룹 이름은 63자를 초과할 수 없습니다. 문자나 숫자로 시작하되, 나머지 문자의 경우 하이픈과 밑줄을 포함할 수 있습니다. **중요** 관리형 노드 그룹을 처음 생성할 때 사용자 정의 시작 템플릿을 사용하지 않는 경우 나중에 노드 그룹에 대해 시작 템플릿을 사용하지 마세요. 사용자 정의 시작 템플릿을 지정하지 않은 경우 시스템에서 시작 템플릿을 자동으로 생성하므로 수동으로 수정하지 않는 것이 좋습니다. 이 자동 생성된 시작 템플릿을 수동으로 수정하면 오류가 발생할 수 있습니다. **시작 템플릿 제외** `eksctl`은 계정에 기본 Amazon EC2 시작 템플릿을 생성하고 사용자가 지정한 옵션에 따라 생성되는 시작 템플릿을 사용하여 노드 그룹을 배포합니다. `--node-type`의 값을 지정하려면 [최적의 Amazon EC2 노드 인스턴스 유형 선택](choosing-instance-type.md) 부분을 참조하세요. 허용된 키워드로 *ami-family*를 바꿉니다. 자세한 내용은 `eksctl` 설명서의 [노드 AMI 패밀리 설정](https://eksctl.io/usage/custom-ami-support/#setting-the-node-ami-family)을 참조하세요. *my-key*를 Amazon EC2 키 페어 또는 퍼블릭 키 이름으로 바꿉니다. 이 키는 노드를 시작한 후 SSH로 연결하는 데 사용됩니다. **참고** Windows의 경우 이 명령에서 SSH를 활성화하지 않습니다. 대신 Amazon EC2 키 페어를 인스턴스와 연결하고 인스턴스에 RDP할 수 있습니다. Amazon EC2 키 페어가 아직 없는 경우 AWS Management Console에서 새로 생성할 수 있습니다. Linux에 대한 자세한 내용은 *Amazon EC2 사용 설명서*의 [Amazon EC2 키 페어 및 Linux 인스턴스](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ec2-key-pairs.html)를 참조하세요. Windows에 대한 자세한 내용은 *Amazon EC2 사용 설명서*의 [Amazon EC2 키 페어 및 Windows 인스턴스](https://docs.aws.amazon.com/AWSEC2/latest/WindowsGuide/ec2-key-pairs.html)를 참조하세요. 다음과 같은 조건에 해당하면 IMDS에 대한 포드 액세스를 차단하는 것이 좋습니다. + 포드에 필요한 최소 권한만 있도록 모든 Kubernetes 서비스 계정에 IAM 역할을 할당할 계획입니다. + 클러스터의 어떤 포드도 현재 AWS 리전 검색 등의 다른 이유로 Amazon EC2 인스턴스 메타데이터 서비스(IMDS)에 액세스할 필요가 없습니다. 자세한 내용은 [작업자 노드에 할당된 인스턴스 프로파일에 대한 액세스 제한](https://aws.github.io/aws-eks-best-practices/security/docs/iam/#restrict-access-to-the-instance-profile-assigned-to-the-worker-node) 섹션을 참조하세요. 포드가 IMDS에 액세스하지 못하게 차단하고 싶다면 `--disable-pod-imds` 옵션을 다음 명령에 추가합니다. ``` eksctl create nodegroup \ --cluster my-cluster \ --region region-code \ --name my-mng \ --node-ami-family ami-family \ --node-type m5.large \ --nodes 3 \ --nodes-min 2 \ --nodes-max 4 \ --ssh-access \ --ssh-public-key my-key ``` 인스턴스는 필요에 따라 포드에 훨씬 더 많은 수의 IP 주소를 할당하고, 인스턴스와 다른 CIDR 블록의 포드에 IP 주소를 할당하며, 인터넷 액세스 없이 클러스터에 배포할 수 있습니다. 자세한 내용은 [접두사를 사용하여 Amazon EKS 노드에 추가 IP 주소 할당](cni-increase-ip-addresses.md), [사용자 지정 네트워킹을 통해 대체 서브넷에 포드 배포](cni-custom-network.md) 및 [인터넷 액세스가 제한된 프라이빗 클러스터 배포](private-clusters.md)에서 이전 명령에 추가할 추가 옵션을 참조하세요. 관리형 노드 그룹은 인스턴스 유형에 따라 노드 그룹의 각 노드에서 실행될 수 있는 최대 포드 수에 대해 단일 값을 계산하고 적용합니다. 다른 인스턴스 유형으로 노드 그룹을 생성하는 경우 모든 인스턴스 유형에 대해 계산된 가장 작은 값이 노드 그룹의 모든 인스턴스 유형에서 실행될 수 있는 최대 포드 수로 적용됩니다. 관리형 노드 그룹은 에 참조된 스크립트를 사용하여 값을 계산합니다. **시작 템플릿 사용** 시작 템플릿은 이미 존재해야 하며 [시작 템플릿 구성 기본 사항](launch-templates.md#launch-template-basics)에 지정된 요구 사항을 충족해야 합니다. 다음과 같은 조건에 해당하면 IMDS에 대한 포드 액세스를 차단하는 것이 좋습니다. + 포드에 필요한 최소 권한만 있도록 모든 Kubernetes 서비스 계정에 IAM 역할을 할당할 계획입니다. + 클러스터의 어떤 포드도 현재 AWS 리전 검색 등의 다른 이유로 Amazon EC2 인스턴스 메타데이터 서비스(IMDS)에 액세스할 필요가 없습니다. 자세한 내용은 [작업자 노드에 할당된 인스턴스 프로파일에 대한 액세스 제한](https://aws.github.io/aws-eks-best-practices/security/docs/iam/#restrict-access-to-the-instance-profile-assigned-to-the-worker-node) 섹션을 참조하세요. IMDS에 대한 포드 액세스를 차단하려면 시작 템플릿에서 필요한 설정을 지정합니다. 1. 다음 콘텐츠를 디바이스에 복사합니다. 예제 값을 바꾼 다음 수정된 명령을 실행하여 `eks-nodegroup.yaml` 파일을 생성하세요. 시작 템플릿 없이 배포할 때 지정하는 몇 가지 설정이 시작 템플릿으로 이동됩니다. `version`을 지정하지 않으면 템플릿의 기본 버전이 사용됩니다. ``` cat >eks-nodegroup.yaml < **AWS Management Console을 사용하여 관리형 노드 그룹을 생성하려면** 1. 클러스터 상태가 `ACTIVE`가 되기를 기다립니다. 이미 `ACTIVE` 상태가 아닌 클러스터에 대한 관리형 노드 그룹을 생성할 수 없습니다. 1. [Amazon EKS 콘솔](https://console.aws.amazon.com/eks/home#/clusters)을 엽니다. 1. 관리형 노드 그룹을 만들려는 클러스터의 이름을 선택합니다. 1. **컴퓨팅**을 선택합니다. 1. **노드 그룹 추가**를 선택합니다. 1. **노드 그룹 구성** 페이지에서 적절히 파라미터를 입력하고 **다음**을 선택합니다. + **이름** - 관리형 노드 그룹의 고유한 이름을 입력합니다. 노드 그룹 이름은 63자를 초과할 수 없습니다. 문자나 숫자로 시작하되, 나머지 문자의 경우 하이픈과 밑줄을 포함할 수 있습니다. + **노드 IAM 역할** - 노드 그룹에 사용할 노드 인스턴스 역할을 선택합니다. 자세한 내용은 [Amazon EKS 노드 IAM 역할](create-node-role.md) 섹션을 참조하세요. **중요** 클러스터를 생성하는 데 사용된 것과 동일한 역할을 사용할 수 없습니다. 자체 관리형 노드 그룹에서 현재 사용하지 않는 역할을 사용하는 것이 좋습니다. 그렇지 않으면 새로운 자체 관리형 노드 그룹과 함께 사용할 계획입니다. 자세한 내용은 [클러스터에서 관리형 노드 그룹 삭제](delete-managed-node-group.md) 섹션을 참조하세요. + **시작 템플릿 사용** - (선택사항) 기존 시작 템플릿을 사용할지 여부를 선택합니다. **시작 템플릿 이름**을 선택합니다. 그런 다음 **시작 템플릿 버전**을 선택합니다. 버전을 선택하지 않으면 Amazon EKS가 템플릿의 기본 버전을 사용합니다. 시작 템플릿을 사용하면 사용자 지정 AMI 배포를 허용하고, 포드에 훨씬 더 많은 수의 IP 주소를 할당하고, 인스턴스와 다른 CIDR 블록의 포드에 IP 주소를 할당하고, 아웃바운드 인터넷 액세스 없이 클러스터에 노드를 배포하는 등 더욱 다양한 노드 그룹 사용자 지정이 허용됩니다. 자세한 내용은 [접두사를 사용하여 Amazon EKS 노드에 추가 IP 주소 할당](cni-increase-ip-addresses.md), [사용자 지정 네트워킹을 통해 대체 서브넷에 포드 배포](cni-custom-network.md), [인터넷 액세스가 제한된 프라이빗 클러스터 배포](private-clusters.md) 섹션을 참조하세요. 시작 템플릿은 [시작 템플릿을 사용하여 관리형 노드 사용자 지정](launch-templates.md)의 요구 사항을 충족해야 합니다. 자체 시작 템플릿을 사용하지 않는 경우 Amazon EKS API는 계정에 기본 Amazon EC2 시작 템플릿을 생성하고 기본 시작 템플릿을 사용하여 노드 그룹을 배포합니다. [서비스 계정에 대한 IAM 역할](iam-roles-for-service-accounts.md)을 구현하고 AWS 서비스에 대한 액세스 권한이 필요한 모든 포드에 직접 필요한 권한을 할당하며 클러스터의 포드가 현재 AWS 리전 검색 등 다른 이유로 IMDS에 액세스할 필요가 없는 경우 시작 템플릿에서 호스트 네트워킹을 사용하지 않는 포드에 대해 IMDS에 대한 액세스를 사용 중지할 수도 있습니다. 자세한 내용은 [작업자 노드에 할당된 인스턴스 프로파일에 대한 액세스 제한](https://aws.github.io/aws-eks-best-practices/security/docs/iam/#restrict-access-to-the-instance-profile-assigned-to-the-worker-node) 섹션을 참조하세요. + **Kubernetes 레이블** - (선택 사항) 관리형 노드 그룹의 노드에 Kubernetes 레이블을 적용하도록 선택할 수 있습니다. + **Kubernetes 테인트** - (선택 사항) 관리형 노드 그룹의 노드에 Kubernetes 테인트를 적용하도록 선택할 수 있습니다. **효과** 메뉴에서 사용할 수 있는 옵션은 ` NoSchedule `, ` NoExecute ` 및 ` PreferNoSchedule `입니다. 자세한 내용은 [레시피: 특정 노드에서 포드가 예약되지 않도록 방지](node-taints-managed-node-groups.md) 섹션을 참조하세요. + **태그** - (선택사항) Amazon EKS 관리형 노드 그룹에 태그를 지정하도록 선택할 수 있습니다. 이러한 태그는 노드 그룹의 다른 리소스(예: Auto Scaling 그룹이나 인스턴스)에는 전파되지 않습니다. 자세한 내용은 [태그를 사용하여 Amazon EKS 리소스 구성](eks-using-tags.md) 섹션을 참조하세요. 1. **컴퓨팅 및 크기 조정 구성 설정** 페이지에서 파라미터를 입력하고 **다음**을 선택합니다. + **AMI 유형** – AMI 유형을 선택합니다. Arm 인스턴스를 배포하는 경우 배포하기 전에 [Amazon EKS 최적화 Arm Amazon Linux AMI](eks-optimized-ami.md#arm-ami)의 고려 사항을 검토해야 합니다. 이전 페이지에서 시작 템플릿을 지정하고 시작 템플릿에 AMI를 지정한 경우 값을 선택할 수 없습니다. 템플릿의 값이 표시됩니다. 템플릿에 지정된 AMI에서 [AMI 지정하기](launch-templates.md#launch-template-custom-ami)의 요구 사항을 충족해야 합니다. + **용량 유형** - 용량 유형을 선택합니다. 용량 유형을 선택하는 방법에 대한 자세한 내용은 [관리형 노드 그룹 용량](managed-node-groups.md#managed-node-group-capacity-types) 부분을 참조하세요. 동일한 노드 그룹 내에 서로 다른 용량 유형을 혼합할 수 없습니다. 두 용량 유형을 모두 사용하려면 각각 고유한 용량 및 인스턴스 유형을 가진 별도의 노드 그룹을 생성합니다. GPU 가속 워커 노드 프로비저닝 및 조정에 대한 자세한 내용은 [관리형 노드 그룹의 GPU 예약](https://docs.aws.amazon.com/eks/latest/userguide/capacity-blocks-mng.html) 섹션을 참조하세요. + **인스턴스 유형** - 기본적으로 하나 이상의 인스턴스 유형이 지정됩니다. 기본 인스턴스 유형을 제거하려면 인스턴스 유형의 오른쪽에 있는 `X`를 선택합니다. 관리형 노드 그룹에 사용할 인스턴스 유형을 선택합니다. 자세한 내용은 [최적의 Amazon EC2 노드 인스턴스 유형 선택](choosing-instance-type.md) 섹션을 참조하세요. 콘솔에는 일반적으로 사용되는 인스턴스 유형 세트가 표시됩니다. 표시되지 않은 인스턴스 유형을 사용하여 관리형 노드 그룹을 생성해야 하는 경우 `eksctl`, AWS CLI, AWS CloudFormation 또는 SDK를 사용하여 노드 그룹을 생성합니다. 이전 페이지에서 시작 템플릿을 지정한 경우 인스턴스 유형이 시작 템플릿에 지정되어야 하므로 값을 선택할 수 없습니다. 시작 템플릿의 값이 표시됩니다. **용량 유형**에서 **스팟**을 선택한 경우, 가용성을 높이기 위해 여러 인스턴스 유형을 지정하는 것이 좋습니다. + **디스크 크기** - 노드 루트 볼륨에 사용할 디스크 크기(GiB)를 입력합니다. 이전 페이지에서 시작 템플릿을 지정한 경우 시작 템플릿에 값을 지정해야 하므로 값을 선택할 수 없습니다. + **원하는 크기** - 시작할 때 관리형 노드 그룹에서 유지해야 하는 현재 노드 수를 지정합니다. **참고** Amazon EKS는 노드 그룹을 자동으로 확장 또는 축소하지 않습니다. 그러나 Kubernetes Cluster Autoscaler가 이 작업을 수행하도록 구성할 수 있습니다. 자세한 내용은 [AWS의 Cluster Autoscaler](https://github.com/kubernetes/autoscaler/blob/master/cluster-autoscaler/cloudprovider/aws/README.md)를 참조하세요. + **최소 크기**-관리형 노드 그룹이 확장될 수 있는 최소 노드 수를 지정합니다. + **최대 크기** - 관리형 노드 그룹이 확장될 수 있는 최대 노드 수를 지정합니다. + **노드 그룹 업데이트 구성** - (선택사항) 병렬로 업데이트할 노드의 수 또는 백분율을 선택할 수 있습니다. 이러한 노드는 업데이트 중에 사용할 수 없습니다. **최대 사용 불가**(Maximum unavailable)에서 다음 옵션 중 하나를 선택하고 **값**을 지정합니다. + **숫자** - 노드 그룹에서 병렬로 업데이트할 수 있는 노드 수를 선택하고 지정합니다. + **비율** - 노드 그룹에서 병렬로 업데이트할 수 있는 노드의 비율을 선택하고 지정합니다. 이 기능은 노드 그룹에 많은 수의 노드가 있는 경우에 유용합니다. + **노드 자동 복구 구성**-(선택 사항) **노드 자동 복구 활성화** 확인란을 활성화하면 감지된 문제가 발생할 때 Amazon EKS가 노드를 자동으로 교체합니다. 자세한 내용은 [노드 상태 문제 감지 및 노드 자동 복구 활성화](node-health.md) 섹션을 참조하세요. 1. **네트워킹 지정** 페이지에서 파라미터를 입력하고 **다음**을 선택합니다. + **서브넷** - 관리형 노드를 시작할 서브넷을 선택합니다. **중요** Amazon EBS 볼륨에 의해 백업되고 Kubernetes [Cluster Autoscaler](https://github.com/kubernetes/autoscaler/blob/master/cluster-autoscaler/cloudprovider/aws/README.md)를 사용하는 상태 기반 애플리케이션을 여러 가용 영역에서 실행하는 경우 각 단일 가용 영역으로 범위가 지정된 여러 노드 그룹을 구성해야 합니다. 또한 `--balance-similar-node-groups` 기능을 활성화해야 합니다. **중요** 퍼블릭 서브넷을 선택한 경우 클러스터에 퍼블릭 API 서버 엔드포인트만 활성화되어 있으면, 인스턴스의 서브넷에 `MapPublicIPOnLaunch`가 `true`로 설정되어 있어야 클러스터에 성공적으로 조인할 수 있습니다. 2020년 3월 26일 이후에 `eksctl` 또는 [Amazon EKS 벤딩 AWS CloudFormation 템플릿](creating-a-vpc.md)을 사용하여 퍼블릭 서브넷을 생성한 경우 이 설정이 이미 `true`로 설정되어 있습니다. 2020년 3월 26일 이전에 `eksctl` 또는 AWS CloudFormation 템플릿으로 서브넷을 생성한 경우 해당 설정을 수동으로 변경해야 합니다. 자세한 내용은 [서브넷의 퍼블릭 IPv4 주소 지정 속성 수정](https://docs.aws.amazon.com/vpc/latest/userguide/vpc-ip-addressing.html#subnet-public-ip) 섹션을 참조하세요. 시작 템플릿을 사용하고 여러 네트워크 인터페이스를 지정하는 경우 `MapPublicIpOnLaunch`가 `true`로 설정되어 있더라도 Amazon EC2가 퍼블릭 `IPv4` 주소를 자동으로 할당하지 않습니다. 이 시나리오에서 노드가 클러스터에 조인하려면 클러스터의 프라이빗 API 서버 엔드포인트를 활성화하거나 NAT 게이트웨이와 같은 대체 방법을 통해 제공되는 아웃바운드 인터넷 액세스를 사용하여 프라이빗 서브넷에서 노드를 시작해야 합니다. 자세한 내용은 *Amazon EC2 사용 설명서*의 [인스턴스 IP 주소 지정](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/using-instance-addressing.html)을 참조하세요. + **노드에 대한 SSH 액세스 구성**(선택사항). SSH를 활성화하면 문제가 있는 경우 인스턴스에 연결하여 진단 정보를 수집할 수 있습니다. 노드 그룹을 생성할 때 원격 액세스를 사용 설정하는 것이 좋습니다. 노드 그룹을 생성한 후에는 원격 액세스를 사용 설정할 수 없습니다. 시작 템플릿을 사용하도록 선택한 경우 이 옵션은 표시되지 않습니다. 노드에 대한 원격 액세스를 활성화하려면 시작 템플릿에 키 페어를 지정하고 시작 템플릿에서 지정한 보안 그룹의 노드에 적절한 포트가 열려 있는지 확인합니다. 자세한 내용은 [사용자 지정 보안 그룹 사용](launch-templates.md#launch-template-security-groups) 섹션을 참조하세요. **참고** Windows의 경우 이 명령에서 SSH를 활성화하지 않습니다. 대신 Amazon EC2 키 페어를 인스턴스와 연결하고 인스턴스에 RDP할 수 있습니다. + **SSH 키 페어**에서 사용할 Amazon EC2 SSH 키를 선택합니다. Linux에 대한 자세한 내용은 *Amazon EC2 사용 설명서*의 [Amazon EC2 키 페어 및 Linux 인스턴스](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ec2-key-pairs.html)를 참조하세요. Windows에 대한 자세한 내용은 *Amazon EC2 사용 설명서*의 [Amazon EC2 키 페어 및 Windows 인스턴스](https://docs.aws.amazon.com/AWSEC2/latest/WindowsGuide/ec2-key-pairs.html)를 참조하세요. 시작 템플릿을 사용하도록 선택한 경우 시작 템플릿을 선택할 수 없습니다. Bottlerocket AMI를 사용하여 노드 그룹에 Amazon EC2 SSH 키가 제공되면 관리 컨테이너도 사용됩니다. 자세한 내용은 GitHub의 [Admin container](https://github.com/bottlerocket-os/bottlerocket#admin-container)를 참조하세요. + 특정 인스턴스에 대한 액세스를 제한하려면 **다음에서 SSH 원격 액세스 허용(Allow SSH remote access from)**에서 해당 인스턴스에 연결된 보안 그룹을 선택합니다. 특정 보안 그룹을 선택하지 않는 경우, 인터넷의 어느 곳에서나(`0.0.0.0/0`) SSH 액세스가 허용됩니다. 1. **검토 및 생성** 페이지에서 관리형 노드 그룹 구성을 검토하고 **생성**을 선택합니다. 노드가 클러스터에 조인하지 못한 경우 문제 해결 장의 [노드가 클러스터 조인에 실패](troubleshooting.md#worker-node-fail) 섹션을 참조하세요. 1. 노드의 상태를 확인하고 `Ready` 상태가 될 때까지 대기합니다. ``` kubectl get nodes --watch ``` 1. (GPU 노드만 해당) GPU 인스턴스 유형과 Amazon EKS 최적화 가속 AMI를 선택한 경우 클러스터에 [Kubernetes용 NVIDIA 디바이스 플러그인](https://github.com/NVIDIA/k8s-device-plugin)을 DaemonSet으로 적용해야 합니다. 다음 명령을 실행하기 전에 *vX.X.X*를 원하는 [NVIDIA/k8s-device-plugin](https://github.com/NVIDIA/k8s-device-plugin/releases) 버전으로 바꿉니다. ``` kubectl apply -f https://raw.githubusercontent.com/NVIDIA/k8s-device-plugin/vX.X.X/deployments/static/nvidia-device-plugin.yml ``` ## Kubernetes 추가 기능 설치 정상 작동하는 Amazon EKS 클러스터와 노드가 있으므로, Kubernetes 추가 기능을 설치하고 클러스터에 애플리케이션을 배포하기 시작할 준비가 되었습니다. 다음은 클러스터의 기능을 확장하는 데 도움이 되는 설명서 주제입니다. + 클러스터를 생성한 [IAM 위탁자](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles.html#iam-term-principal)는 `kubectl` 또는 AWS Management Console을 사용하여 Kubernetes API 서버를 직접적으로 직접 호출할 수 있는 유일한 위탁자입니다. 다른 IAM 보안 주체가 클러스터에 액세스할 수 있게 하려면 해당 보안 주체를 추가해야 합니다. 자세한 내용은 [IAM 사용자 및 역할에 Kubernetes API에 대한 액세스 권한 부여](grant-k8s-access.md) 및 [필수 권한](view-kubernetes-resources.md#view-kubernetes-resources-permissions)(을)를 참조하세요. + 다음과 같은 조건에 해당하면 IMDS에 대한 포드 액세스를 차단하는 것이 좋습니다. + 포드에 필요한 최소 권한만 있도록 모든 Kubernetes 서비스 계정에 IAM 역할을 할당할 계획입니다. + 클러스터의 어떤 포드도 현재 AWS 리전 검색 등의 다른 이유로 Amazon EC2 인스턴스 메타데이터 서비스(IMDS)에 액세스할 필요가 없습니다. 자세한 내용은 [작업자 노드에 할당된 인스턴스 프로필에 대한 액세스 제한](https://aws.github.io/aws-eks-best-practices/security/docs/iam/#restrict-access-to-the-instance-profile-assigned-to-the-worker-node) 부분을 참조하세요. + 노드 그룹의 노드 수를 자동으로 조정하도록 Kubernetes [Cluster Autoscaler](https://github.com/kubernetes/autoscaler/blob/master/cluster-autoscaler/cloudprovider/aws/README.md)를 구성합니다. + 클러스터에 [샘플 애플리케이션](sample-deployment.md)을 배포합니다. + 클러스터를 관리하기 위한 중요한 도구를 사용하여 [클러스터 리소스를 구성하고 모니터링](eks-managing.md)합니다. # 클러스터에 대한 관리형 노드 그룹 업데이트 관리형 노드 그룹 업데이트를 시작하면 Amazon EKS가 [노드 업데이트의 각 단계 이해](managed-node-update-behavior.md)에 나열된 단계를 완료하여 자동으로 노드를 업데이트합니다. Amazon EKS 최적화 AMI를 사용하는 경우 Amazon EKS는 최신 AMI 릴리스 버전의 일부로 최신 보안 패치 및 운영 체제 업데이트를 노드에 자동으로 적용합니다. Amazon EKS 관리형 노드 그룹의 버전 또는 구성을 업데이트하는 것이 유용한 몇 가지 시나리오가 있습니다. + Amazon EKS 클러스터의 Kubernetes 버전을 업데이트했으며 동일한 Kubernetes 버전을 사용하도록 노드를 업데이트하려고 합니다. + 관리형 노드 그룹에 새 AMI 릴리스 버전을 사용할 수 있습니다. AMI 버전에 대한 자세한 내용은 다음 섹션을 참조하세요. + [Amazon Linux AMI 버전 정보 검색](eks-linux-ami-versions.md) + [최적화된 Bottlerocket AMI를 사용한 노드 생성](eks-optimized-ami-bottlerocket.md) + [Windows AMI 버전 정보 검색](eks-ami-versions-windows.md) + 관리형 노드 그룹에 있는 인스턴스의 최소, 최대 또는 원하는 수를 조정하려고 합니다. + 관리형 노드 그룹의 인스턴스에서 Kubernetes 레이블을 추가하거나 제거하려고 합니다. + 관리형 노드 그룹에서 AWS 태그를 추가하거나 제거하려고 합니다. + 업데이트된 사용자 지정 AMI와 같은 구성 변경 사항이 있는 시작 템플릿의 새 버전을 배포해야 합니다. + Amazon VPC CNI 추가 기능의 버전 `1.9.0` 이상을 배포하고, 접두사 위임에 대해 추가 기능을 사용하도록 설정했으며, 노드 그룹의 새로운 AWS Nitro System 인스턴스가 크게 증가된 포드 수를 지원하도록 했습니다. 자세한 내용은 [접두사를 사용하여 Amazon EKS 노드에 추가 IP 주소 할당](cni-increase-ip-addresses.md) 섹션을 참조하세요. + Windows 노드에 대해 IP 접두사 위임을 활성화했으며 노드 그룹의 새 AWS Nitro System 인스턴스가 크게 늘어난 수의 포드를 지원하도록 하려고 합니다. 자세한 내용은 [접두사를 사용하여 Amazon EKS 노드에 추가 IP 주소 할당](cni-increase-ip-addresses.md) 섹션을 참조하세요. 관리형 노드 그룹의 Kubernetes 버전에 대한 최신 AMI 릴리스 버전이 있는 경우 노드 그룹의 버전을 업데이트하여 최신 AMI 버전을 사용할 수 있습니다. 마찬가지로 클러스터에서 노드 그룹보다 최신 버전의 Kubernetes 버전을 실행 중인 경우 최신 AMI 릴리스 버전을 사용하여 클러스터의 Kubernetes 버전과 일치하도록 노드 그룹을 업데이트할 수 있습니다. 크기 조정 작업 또는 업데이트로 인해 관리형 노드 그룹의 노드가 종료되면 해당 노드의 포드가 먼저 드레이닝됩니다. 자세한 내용은 [노드 업데이트의 각 단계 이해](managed-node-update-behavior.md) 섹션을 참조하세요. ## 노드 그룹 버전 업데이트 다음 중 하나를 사용하여 노드 그룹 버전을 업데이트할 수 있습니다. + [`eksctl`](#eksctl_update_managed_nodegroup) + [AWS Management Console](#console_update_managed_nodegroup) 업데이트하는 버전은 컨트롤 플레인 버전보다 이후일 수 없습니다. ## `eksctl` **`eksctl`를 사용하여 관리형 노드 그룹 업데이트** 다음 명령을 사용하여 노드에 현재 배포된 동일한 Kubernetes 버전의 최신 AMI 릴리스로 관리형 노드 그룹을 업데이트합니다. 모든 *예제 값*을 자신의 값으로 바꾸세요. ``` eksctl upgrade nodegroup \ --name=node-group-name \ --cluster=my-cluster \ --region=region-code ``` **참고** 시작 템플릿과 함께 배포된 노드 그룹을 새 시작 템플릿 버전으로 업그레이드하는 경우 이전 명령에 `--launch-template-version version-number `을 추가합니다. 시작 템플릿은 [시작 템플릿 을 사용하여 관리형 노드 사용자 지정](launch-templates.md)에 설명된 요구 사항을 충족해야 합니다. 시작 템플릿에 사용자 지정 AMI 가 포함되어 있는 경우 해당 AMI가 [AMI 지정](launch-templates.md#launch-template-custom-ami)의 요구 사항을 충족해야 합니다. 노드 그룹을 최신 버전의 시작 템플릿으로 업그레이드하면 지정된 시작 템플릿 버전의 새 구성과 일치하도록 모든 노드가 재활용됩니다. 시작 템플릿 없이 배포된 노드 그룹은 새 시작 템플릿 버전으로 직접 업그레이드할 수 없습니다. 대신 시작 템플릿을 사용하여 새 노드 그룹을 배포하여 노드 그룹을 새 시작 템플릿 버전으로 업데이트해야 합니다. 노드 그룹을 컨트롤 플레인의 Kubernetes 버전과 동일한 버전으로 업그레이드할 수 있습니다. 예를 들어 Kubernetes `1.35`을 실행하는 클러스터가 있는 경우 다음 명령을 사용하여 현재 Kubernetes `1.34`을 실행 중인 노드를 버전 `1.35`으로 업그레이드할 수 있습니다. ``` eksctl upgrade nodegroup \ --name=node-group-name \ --cluster=my-cluster \ --region=region-code \ --kubernetes-version=1.35 ``` ## AWS Management Console **AWS Management Console를 사용하여 관리형 노드 그룹 업데이트** 1. [Amazon EKS 콘솔](https://console.aws.amazon.com/eks/home#/clusters)을 엽니다. 1. 업데이트할 노드 그룹이 포함된 클러스터를 선택합니다. 1. 하나 이상의 노드 그룹에 사용 가능한 업데이트가 있는 경우 페이지 상단에 사용 가능한 업데이트를 알리는 상자가 나타납니다. **컴퓨팅** 탭을 선택하면 사용 가능한 업데이트가 있는 노드 그룹에 대한 **노드 그룹** 테이블의 **AMI 릴리스 버전** 열에 **지금 업데이트**가 표시됩니다. 노드 그룹을 업데이트하려면 **지금 업데이트**를 선택합니다. 사용자 지정 AMI와 함께 배포된 노드 그룹에 대한 알림이 표시되지 않습니다. 노드가 사용자 지정 AMI와 함께 배포된 경우 다음 단계를 완료하여 새로운 업데이트된 사용자 지정 AMI를 배포합니다. 1. AMI의 새 버전을 생성합니다. 1. 새 AMI ID를 사용하여 새 시작 템플릿 버전을 생성합니다. 1. 노드를 새 버전의 시작 템플릿으로 업그레이드합니다. 1. **노드 그룹 버전 업데이트** 대화 상자에서 다음과 같은 옵션을 활성화하거나 비활성화합니다. + **노드 그룹 버전 업데이트** - 사용자 지정 AMI를 배포했거나 Amazon EKS에 최적화된 AMI가 현재 클러스터의 최신 버전에 있는 경우에는 이 옵션을 사용할 수 없습니다. + **시작 템플릿 버전 변경** - 노드 그룹이 사용자 지정 시작 템플릿 없이 배포된 경우에는 이 옵션을 사용할 수 없습니다. 사용자 지정 시작 템플릿을 사용하여 배포된 노드 그룹의 시작 템플릿 버전만 업데이트할 수 있습니다. 노드 그룹을 업데이트할 **시작 템플릿 버전**을 선택합니다. 노드 그룹이 사용자 지정 AMI로 구성된 경우 선택한 버전에서도 AMI를 지정해야 합니다. 최신 버전의 시작 템플릿으로 업그레이드하면 지정된 시작 템플릿 버전의 새 구성과 일치하도록 모든 노드가 재활용됩니다. 1. **전략 업데이트**의 경우, 다음과 같은 옵션 중 하나를 선택합니다. + **롤링 업데이트** - 이 옵션은 클러스터에 대한 포드 중단 예산을 고려합니다. 포드 중단 예산 문제로 인해 Amazon EKS에서 이 노드 그룹에서 실행 중인 포드를 적절하게 드레이닝할 수 없는 경우 업데이트에 실패합니다. + **강제 업데이트** - 이 옵션은 포드 중단 예산을 따르지 않습니다. 노드 재시작을 강제로 적용하여 포드 중단 예산 문제와 관계없이 업데이트가 수행됩니다. 1. **업데이트**를 선택합니다. ## 노드 그룹 구성 편집 관리형 노드 그룹의 일부 구성을 수정할 수 있습니다. 1. [Amazon EKS 콘솔](https://console.aws.amazon.com/eks/home#/clusters)을 엽니다. 1. 편집할 노드 그룹이 포함된 클러스터를 선택합니다. 1. **컴퓨팅** 탭을 선택합니다. 1. 편집할 노드 그룹을 선택한 다음에 **편집**을 선택합니다. 1. (선택사항) **노드 그룹 편집** 페이지에서 다음을 수행합니다. 1. **노드 그룹 크기 조정 구성**을 편집합니다. + **원하는 크기** - 관리형 노드 그룹에서 유지해야 하는 현재 노드 수를 지정합니다. + **최소 크기**-관리형 노드 그룹이 확장될 수 있는 최소 노드 수를 지정합니다. + **최대 크기** - 관리형 노드 그룹이 확장될 수 있는 최대 노드 수를 지정합니다. 노드 그룹에서 지원되는 최대 노드 수는 [Amazon EKS 및 Fargate Service Quotas 보기 및 관리](service-quotas.md) 섹션을 참조하세요. 1. (선택 사항) **Kubernetes 레이블**을 노드 그룹의 노드에 추가하거나 제거합니다. 여기에 표시된 레이블은 Amazon EKS에 적용한 레이블일 뿐입니다. 여기에 표시되지 않는 노드에 다른 레이블이 존재할 수 있습니다. 1. (선택 사항) **Kubernetes 테인트**를 노드 그룹의 노드에 추가하거나 제거합니다. 추가된 테인트는 ` NoSchedule `,` NoExecute ` 또는 ` PreferNoSchedule ` 중 하나의 효과를 가질 수 있습니다. 자세한 내용은 [레시피: 특정 노드에서 포드가 예약되지 않도록 방지](node-taints-managed-node-groups.md) 섹션을 참조하세요. 1. (선택사항) **태그**를 추가하거나 노드 그룹 리소스에서 제거합니다. 이러한 태그는 Amazon EKS 노드 그룹에만 적용됩니다. 노드 그룹의 서브넷 또는 Amazon EC2 인스턴스 등의 다른 리소스로 전파되지 않습니다. 1. (선택사항) **노드 그룹 업데이트 구성**을 편집합니다. **숫자** 또는 **비율**을 선택합니다. + **숫자** - 노드 그룹에서 병렬로 업데이트할 수 있는 노드 수를 선택하고 지정합니다. 이러한 노드는 업데이트 중에 사용할 수 없습니다. + **비율** - 노드 그룹에서 병렬로 업데이트할 수 있는 노드의 비율을 선택하고 지정합니다. 이러한 노드는 업데이트 중에 사용할 수 없습니다. 이 기능은 노드 그룹에 많은 노드가 있는 경우에 유용합니다. 1. 편집을 마쳤으면 **변경 사항 저장**을 선택합니다. **중요** 노드 그룹 구성을 업데이트할 때 [https://docs.aws.amazon.com/eks/latest/APIReference/API_NodegroupScalingConfig.html](https://docs.aws.amazon.com/eks/latest/APIReference/API_NodegroupScalingConfig.html)를 수정해도 포드 중단 예산(PDB)이 반영되지 않습니다. 업그레이드 단계에서 노드를 소모시키고 PDB를 고려하는 [노드 그룹 업데이트](managed-node-update-behavior.md) 프로세스와 달리, 스케일링 구성을 업데이트하면 Auto Scaling 그룹(ASG) 스케일 다운 직접 호출을 통해 노드가 즉시 종료됩니다. 이는 스케일 다운하려는 대상 크기와 상관없이 PDB를 고려하지 않고 이루어집니다. 즉, Amazon EKS 관리형 노드 그룹의 `desiredSize`를 줄이면 포드는 PDB를 적용하지 않고 노드가 종료되는 즉시 제거됩니다. # 노드 업데이트의 각 단계 이해 Amazon EKS 관리형 작업자 노드 업그레이드 전략에는 다음 섹션에서 설명하는 4가지 단계가 있습니다. ## 설정 단계 설정 단계는 다음과 같습니다. 1. 노드 그룹과 연결된 Auto Scaling 그룹의 새 Amazon EC2 시작 템플릿 버전을 생성합니다. 새 시작 템플릿 버전은 업데이트를 위해 대상 AMI 또는 사용자 지정 시작 템플릿 버전을 사용합니다. 1. 최신 시작 템플릿 버전을 사용하도록 Auto Scaling 그룹을 업데이트합니다. 1. 노드 그룹의 `updateConfig` 속성을 사용하여 병렬로 업그레이드할 최대 노드 수를 결정합니다. 사용할 수 없는 최대 노드의 할당량은 100개입니다. 기본값은 노드 1개입니다. 자세한 내용은 *Amazon EKS API 참조*에서 [updateConfig](https://docs.aws.amazon.com/eks/latest/APIReference/API_UpdateNodegroupConfig.html#API_UpdateNodegroupConfig_RequestSyntax) 속성을 참조하세요. ## 확장 단계 관리형 노드 그룹의 노드를 업그레이드할 때 업그레이드된 노드는 업그레이드 중인 노드와 동일한 가용 영역에서 시작됩니다. 이 배치를 보장하기 위해 Amazon EC2의 가용 영역 재분배를 사용합니다. 자세한 내용은 *Amazon EC2 Auto Scaling 사용 설명서*의 [가용 영역 재분배](https://docs.aws.amazon.com/autoscaling/ec2/userguide/auto-scaling-benefits.html#AutoScalingBehavior.InstanceUsage)를 참조하세요. 이 요구 사항이 충족되도록 관리형 노드 그룹의 가용 영역당 최대 2개의 인스턴스를 시작할 수 있습니다. 확장 단계는 다음과 같습니다. 1. Auto Scaling 그룹의 최대 크기와 원하는 크기를 다음 중 더 큰 값으로 늘립니다. + Auto Scaling 그룹이 배포된 가용 영역 수의 최대 2배. + 업그레이드할 수 없는 최대값입니다. 예를 들어, 노드 그룹에 5개의 가용 영역이 있고 `maxUnavailable`이 하나인 경우 업그레이드 프로세스에서 최대 10개의 노드를 시작할 수 있습니다. 하지만 `maxUnavailable`이 20이거나 10보다 크면 프로세스에서 20개의 새 노드를 시작합니다. 1. Auto Scaling 그룹 크기를 조정한 후 해당 노드 그룹에 최신 설정을 사용하는 노드가 있는지 확인합니다. 이 단계는 다음 기준을 충족하는 경우에만 성공합니다. + 노드가 있는 모든 가용 영역에서 하나 이상의 새 노드가 시작됩니다. + 모든 새 노드는 `Ready` 상태여야 합니다. + 새 노드에 Amazon EKS 적용 레이블이 있어야 합니다. 다음은 일반 노드 그룹에 있는 작업자 노드의 Amazon EKS 적용 레이블입니다. + `eks.amazonaws.com/nodegroup-image=$amiName` + `eks.amazonaws.com/nodegroup=$nodeGroupName` 다음은 사용자 정의 시작 템플릿 또는 AMI 노드 그룹에 있는 작업자 노드의 Amazon EKS 적용 레이블입니다. + `eks.amazonaws.com/nodegroup-image=$amiName` + `eks.amazonaws.com/nodegroup=$nodeGroupName` + `eks.amazonaws.com/sourceLaunchTemplateId=$launchTemplateId` + `eks.amazonaws.com/sourceLaunchTemplateVersion=$launchTemplateVersion` 1. 새 포드의 예약을 피하기 위해 노드를 스케줄 불가능으로 표시합니다. 또한 노드를 종료하기 전에 로드 밸런서에서 이전 노드를 제거하도록 `node.kubernetes.io/exclude-from-external-load-balancers=true`로 노드에 레이블을 지정합니다. 이 단계에서 `NodeCreationFailure` 오류가 발생하는 알려진 이유는 다음과 같습니다. **가용 영역의 용량 부족** 요청된 인스턴스 유형의 용량이 가용 영역에 없을 가능성이 있습니다. 관리형 노드 그룹을 생성하는 동안 여러 인스턴스 유형을 구성하는 것이 좋습니다. **계정의 EC2 인스턴스 제한** Service Quotas를 사용하여 계정이 동시에 실행할 수 있는 Amazon EC2 인스턴스 수를 늘려야 할 수 있습니다. 자세한 내용은 *Linux 인스턴스용 Amazon Elastic Compute Cloud 사용 설명서*의 [EC2 Service Quotas](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ec2-resource-limits.html)를 참조하세요. **사용자 정의 사용자 데이터** 사용자 정의 사용자 데이터로 인해 부트스트랩 프로세스가 중단될 수 있습니다. 이 시나리오에서는 노드에서 `kubelet`이 시작되지 않거나 예상되는 Amazon EKS 레이블을 가져오지 못할 수 있습니다. 자세한 내용은 [AMI 지정](launch-templates.md#launch-template-custom-ami) 섹션을 참조하세요. **노드를 비정상적이거나 준비되지 않은 상태로 만드는 모든 변경 사항** 노드 디스크 압력, 메모리 압력 및 이와 유사한 조건으로 인해 노드가 `Ready` 상태가 되지 않을 수 있습니다. **15분 내에 각 노드 대부분 부트스트랩** 노드가 클러스터를 부트스트랩하고 조인하는 데 15분 이상 걸리는 경우 업그레이드 시간이 초과됩니다. 새 노드가 필요한 시점부터 클러스터에 조인할 때까지 측정된 새 노드 부트스트래핑을 위한 총 런타임입니다. 관리형 노드 그룹을 업그레이드할 때 Auto Scaling 그룹 크기가 커지는 즉시 시간 카운터가 시작됩니다. ## 업그레이드 단계 업그레이드 단계는 *업데이트 전략*에 따라 두 가지 방식으로 작동합니다. **기본**과 **최소**의 두 가지 업데이트 전략이 있습니다. 대부분의 시나리오에서는 기본 전략을 사용하는 것이 좋습니다. 이 전략은 이전 노드를 종료하기 전에 새 노드를 생성하므로 업그레이드 단계에서 사용 가능한 용량이 유지됩니다. 최소 전략은 GPU 등의 하드웨어 액셀러레이터와 같이 리소스 또는 비용에 제약이 있는 시나리오에서 유용합니다. 이 전략은 새 노드를 생성하기 전에 이전 노드를 종료하므로 총 용량이 구성된 수량을 초과하여 증가하지 않습니다. *기본* 업데이트 전략에는 다음 단계가 있습니다. 1. Auto Scaling 그룹에서 노드의 양(원하는 수)을 늘려 노드 그룹이 추가 노드를 생성하게 합니다. 1. 노드 그룹에 대해 구성된 사용 불가능한 최대값까지 업그레이드해야 하는 노드를 무작위로 선택합니다. 1. 노드에서 포드를 드레이닝합니다. 포드가 15분 이내에 노드를 떠나지 않고 force 플래그가 없으면 `PodEvictionFailure` 오류와 함께 업그레이드 단계가 실패합니다. 이 시나리오에서는 `update-nodegroup-version` 요청과 함께 force 플래그를 적용하여 포드를 삭제할 수 있습니다. 1. 모든 포드가 제거된 후 노드를 차단하고 60초 동안 기다립니다. 이 작업은 서비스 컨트롤러가 이 노드에 새 요청을 보내지 않고 활성 노드 목록에서 이 노드를 제거하도록 하기 위해 수행됩니다. 1. 코드화된 노드에 대한 Auto Scaling 그룹에 종료 요청을 보냅니다. 1. 이전 버전의 시작 템플릿으로 배포된 노드 그룹에 노드가 없을 때까지 이전 업그레이드 단계를 반복합니다. *최소* 업데이트 전략에는 다음 단계가 있습니다. 1. 서비스 컨트롤러가 이러한 노드에 새 요청을 보내지 않도록 처음부터 노드 그룹의 모든 노드를 차단합니다. 1. 노드 그룹에 대해 구성된 사용 불가능한 최대값까지 업그레이드해야 하는 노드를 무작위로 선택합니다. 1. 선택한 노드에서 포드를 드레이닝합니다. 포드가 15분 이내에 노드를 떠나지 않고 force 플래그가 없으면 `PodEvictionFailure` 오류와 함께 업그레이드 단계가 실패합니다. 이 시나리오에서는 `update-nodegroup-version` 요청과 함께 force 플래그를 적용하여 포드를 삭제할 수 있습니다. 1. 모든 포드가 제거되면 60초 동안 기다린 후 선택한 노드의 Auto Scaling 그룹에 종료 요청을 전송합니다. Auto Scaling 그룹이 누락된 용량을 대체하기 위해 (선택한 노드 수와 동일하게) 새 노드를 생성합니다. 1. 이전 버전의 시작 템플릿으로 배포된 노드 그룹에 노드가 없을 때까지 이전 업그레이드 단계를 반복합니다. ### 업그레이드 단계 중 `PodEvictionFailure` 오류 이 단계에서 `PodEvictionFailure` 오류가 발생하는 알려진 이유는 다음과 같습니다. **적극적인 PDB** 적극적인 PDB가 포드에 정의되어 있거나 동일한 포드를 가리키는 여러 PDB가 있습니다. **모든 테인트를 허용하는 배포** 모든 포드가 제거되면 이전 단계에서 노드가 [테인트](https://kubernetes.io/docs/concepts/scheduling-eviction/taint-and-toleration/)되었기 때문에 노드가 비어 있어야 합니다. 그러나 배포가 모든 테인트를 허용하는 경우 노드가 비어 있지 않을 가능성이 높아져 포드 제거 실패로 이어집니다. ## 축소 단계 축소 단계는 Auto Scaling 그룹의 최대 크기와 원하는 크기를 하나씩 줄여 업데이트가 시작되기 전의 값으로 돌아갑니다. 업그레이드 워크플로에서 Cluster Autoscaler가 워크플로의 축소 단계에서 노드 그룹을 확장하고 있다고 판단하면 노드 그룹을 원래 크기로 되돌리지 않고 즉시 종료됩니다. # 시작 템플릿을 사용한 관리형 노드 사용자 지정 최고 수준의 사용자 지정을 위해 이 페이지의 단계에 기반한 자체 시작 템플릿을 사용하여 관리형 노드를 배포할 수 있습니다. 시작 템플릿을 사용하면 노드 배포 중에 부트스트랩 인수(예: 추가 [kubelet](https://kubernetes.io/docs/reference/command-line-tools-reference/kubelet/) 인수)를 제공하거나 노드에 할당된 IP 주소와 다른 CIDR 블록의 포드에 IP 주소를 할당하거나 노드에 자체 사용자 지정 AMI를 배포하거나 노드에 자체 사용자 지정 CNI를 배포하는 등의 기능을 허용합니다. 관리형 노드 그룹을 처음 만들 때 자체 시작 템플릿을 제공하면 나중에 더 유연하게 사용할 수 있습니다. 자체 시작 템플릿을 사용하여 관리형 노드 그룹을 배포한 후 동일한 시작 템플릿의 다른 버전으로 업데이트할 수 있습니다. 노드 그룹을 다른 버전의 시작 템플릿으로 업데이트하면 그룹의 모든 노드가 지정된 시작 템플릿 버전의 새 구성과 일치하도록 재활용됩니다. 관리형 노드 그룹은 항상 Amazon EC2 Auto Scaling 그룹에서 사용할 시작 템플릿과 함께 배포됩니다. Amazon EKS API는 사용자가 제공한 템플릿을 복사하거나 계정의 기본값으로 자동 생성하여 이 시작 템플릿을 생성합니다. 자동 생성된 시작 템플릿을 수정하지 않는 것이 좋습니다. 사용자 정의 시작 템플릿을 사용하지 않는 기존 노드 그룹은 직접 업데이트할 수 없습니다. 대신 사용자 정의 시작 템플릿을 사용하여 새 노드 그룹을 생성해야 합니다. ## 시작 템플릿 기본 사항 AWS Management Console, AWS CLI 또는 AWS SDK를 사용하여 Amazon EC2 Auto Scaling 시작 템플릿을 생성할 수 있습니다. 자세한 내용을 알아보려면 *Amazon EC2 Auto Scaling 사용 설명서*의 [Auto Scaling 그룹을 위한 시작 템플릿 생성](https://docs.aws.amazon.com/autoscaling/ec2/userguide/create-launch-template.html)을 참조하세요. 시작 템플릿의 일부 설정은 관리형 노드 구성에 사용되는 설정과 유사합니다. 시작 템플릿을 사용하여 노드 그룹을 배포하거나 업데이트할 때 노드 그룹 구성 또는 시작 템플릿에 일부 설정을 지정해야 합니다. 두 위치 모두에 설정을 지정하지 않습니다. 잘못된 위치에 설정이 있으면 노드 그룹 생성 또는 업데이트와 같은 작업이 실패합니다. 다음 표에는 시작 템플릿에서 금지된 설정이 나열되어 있습니다. 사용 가능한 경우 관리형 노드 그룹 구성에 필요한 유사한 설정도 나열되어 있습니다. 나열된 설정은 콘솔에 표시되는 설정입니다. AWS CLI 및 SDK에서 비슷하지만 다른 이름을 가질 수 있습니다. | 시작 템플릿 - 금지됨 | Amazon EKS 노드 그룹 구성 | | --- | --- | | **네트워크 인터페이스**의 **서브넷**(**네트워크 인터페이스 추가**) | **네트워킹 지정** 페이지의 **노드 그룹 네트워크 구성**에 있는 **서브넷** | | **고급 세부 정보**의 **IAM 인스턴스 프로필** | **노드 그룹 구성** 페이지의 **노드 그룹 구성**에 있는 **노드 IAM 역할** | | **고급 세부 정보**의 **종료 동작** 및 **중지 - 최대 절전 모드 동작**. 두 설정 모두 실행 템플릿에서 기본값인 **실행 템플릿 설정에 포함하지 않음**을 유지합니다. | 동일한 사항 없음 Amazon EKS는 Auto Scaling 그룹이 아니라 인스턴스 수명 주기를 제어해야 합니다. | 다음 표에는 관리형 노드 그룹 구성에서 금지된 설정이 나열되어 있습니다. 사용 가능한 경우 시작 템플릿에 필요한 유사한 설정도 나열되어 있습니다. 나열된 설정은 콘솔에 표시되는 설정입니다. AWS CLI 및 SDK에서 비슷한 이름을 가질 수 있습니다. | Amazon EKS 노드 그룹 구성 — 금지됨 | 시작 템플릿 | | --- | --- | | (시작 템플릿에서 사용자 정의 AMI를 지정한 경우,에만 해당) **컴퓨팅 및 크기 조정 구성 설정** 페이지의 **노드 그룹 컴퓨팅 구성**에 있는 **AMI 유형** - 콘솔에 **시작 템플릿에서 지정됨**이라는 메시지와 지정된 AMI ID가 표시됩니다. 시작 템플릿에 **애플리케이션 및 OS 이미지(Amazon 머신 이미지)**가 지정되지 않은 경우, 노드 그룹 구성에서 AMI를 선택할 수 있습니다. | **시작 템플릿 컨텐츠**의 **애플리케이션 및 OS 이미지(Amazon Machine Image)** - 다음 요구 사항 중 하나가 있는 경우, ID를 지정해야 합니다. [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ko_kr/eks/latest/userguide/launch-templates.html) | | **컴퓨팅 및 크기 조정 구성 설정** 페이지의 **노드 그룹 컴퓨팅 구성**에 있는 **디스크 크기** - 콘솔에 **시작 템플릿에 지정됨**이라는 메시지가 표시됩니다. | **스토리지(볼륨)**의 **크기**(**새 볼륨 추가**). 시작 템플릿에서 이 옵션을 지정해야 합니다. | | **네트워킹 지정** 페이지의 **노드 그룹 구성**에 있는 **SSH 키 페어** - 콘솔에 시작 템플릿에 지정되어 있는 키가 표시되거나 **시작 템플릿에 지정되지 않음**이라는 메시지가 표시됩니다. | **키 페어(로그인)**의 **키 페어 이름**. | | 시작 템플릿을 사용할 때 원격 액세스가 허용되는 소스 보안 그룹을 지정할 수 없습니다. | 인스턴스의 **네트워크 설정**에 있는 **보안 그룹** 또는 **네트워크 인터페이스**의 **보안 그룹**(**네트워크 인터페이스 추가**), 두 가지 모두 설정할 수는 없습니다. 자세한 내용은 [사용자 지정 보안 그룹 사용](#launch-template-security-groups) 섹션을 참조하세요. | **참고** 시작 템플릿을 사용하여 노드 그룹을 배포하는 경우 시작 템플릿의 **시작 템플릿 콘텐츠**에서 **인스턴스 유형**을 0개 또는 1개 지정합니다. 또는 콘솔의 **컴퓨팅 및 크기 조정 구성 설정** 페이지에서 **인스턴스 유형**에 대해 0\$120개의 인스턴스 유형을 지정할 수 있습니다. 또는 Amazon EKS API를 사용하는 다른 도구로 인스턴스 유형을 지정할 수 있습니다. 시작 템플릿에서 인스턴스 유형을 지정하고 해당 시작 템플릿을 사용하여 노드 그룹을 배포하는 경우 콘솔에서 인스턴스 유형을 지정하거나 Amazon EKS API를 사용하는 다른 도구를 사용하여 인스턴스 유형을 지정할 수 없습니다. 시작 템플릿, 콘솔 또는 Amazon EKS API를 사용하는 다른 도구를 사용하여 인스턴스 유형을 지정하지 않으면 `t3.medium` 인스턴스 유형이 사용됩니다. 노드 그룹에서 스팟 용량 유형을 사용하는 경우 콘솔을 사용하여 여러 인스턴스 유형을 지정하는 것이 좋습니다. 자세한 내용은 [관리형 노드 그룹 용량](managed-node-groups.md#managed-node-group-capacity-types) 섹션을 참조하세요. 노드 그룹에 배포하는 컨테이너가 인스턴스 메타데이터 서비스 버전 2를 사용하는 경우 시작 템플릿에 **메타데이터 응답 홉 제한**이 `2`로 설정되어 있어야 합니다. 자세한 내용은 **Amazon EC2 사용 설명서의 [인스턴스 메타데이터 및 사용자 데이터](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ec2-instance-metadata.html)를 참조하세요. 시작 템플릿은 유연한 인스턴스 유형 선택을 허용하는 `InstanceRequirements` 기능을 지원하지 않습니다. ## Amazon EC2 인스턴스 태깅 시작 템플릿의 `TagSpecification` 파라미터를 사용하여 노드 그룹의 Amazon EC2 인스턴스에 적용할 태그를 지정할 수 있습니다. `CreateNodegroup` 또는 `UpdateNodegroupVersion`API를 직접 호출하는 IAM 엔터티에는 `ec2:RunInstances` 및 `ec2:CreateTags`에 대한 권한이 있어야 하며, 시작 템플릿에 태그가 추가되어 있어야 합니다. ## 사용자 지정 보안 그룹 사용 시작 템플릿을 사용하여 사용자 지정 Amazon EC2 [보안 그룹](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ec2-security-groups.html) 지정하고 노드 그룹의 인스턴스에 적용할 수 있습니다. 이는 인스턴스 수준 보안 그룹 파라라미터 또는 네트워크 인터페이스 구성 파라미터의 일부로 사용할 수 있습니다. 하지만 인스턴스 수준 및 네트워크 인터페이스 보안 그룹을 모두 지정하는 시작 템플릿을 생성할 수 없습니다. 관리형 노드 그룹과 함께 사용자 지정 보안 그룹을 사용할 때 적용되는 다음 조건을 고려하세요. + AWS Management Console을 사용하면 Amazon EKS는 단일 네트워크 인터페이스 사양이 있는 시작 템플릿만 허용합니다. + 기본적으로 Amazon EKS는 [클러스터 보안 그룹](sec-group-reqs.md)을 노드 그룹의 인스턴스에 적용하여 노드와 제어 플레인 간의 통신을 용이하게 합니다. 앞에서 언급한 옵션 중 하나를 사용하여 시작 템플릿에 사용자 지정 보안 그룹을 지정하는 경우 Amazon EKS는 클러스터 보안 그룹을 추가하지 않습니다. 따라서 보안 그룹의 인바운드 및 아웃바운드 규칙이 클러스터 엔드포인트와의 통신을 사용 설정하는지 확인해야 합니다. 보안 그룹 규칙이 올바르지 않으면 작업자 노드가 클러스터에 참여할 수 없습니다. 보안 그룹 규칙에 대한 자세한 내용은 [클러스터에 대한 Amazon EKS 보안 그룹 요구 사항 보기](sec-group-reqs.md) 부분을 참조하세요. + 노드 그룹의 인스턴스에 대한 SSH 액세스가 필요한 경우 해당 액세스를 허용하는 보안 그룹을 포함합니다. ## Amazon EC2 사용자 데이터 시작 템플릿에는 사용자 정의 사용자 데이터에 대한 부분이 포함되어 있습니다. 개별 사용자 정의 AMI를 수동으로 생성하지 않고 이 섹션에서 노드 그룹에 대한 구성 설정을 지정할 수 있습니다. Bottlerocket에 사용할 수 있는 설정에 대한 자세한 내용은 GitHub의 [Using user data](https://github.com/bottlerocket-os/bottlerocket#using-user-data)을 참조하세요. 인스턴스를 시작할 때 `cloud-init`를 사용하여 시작 템플릿에 Amazon EC2 사용자 데이터를 제공할 수 있습니다. 자세한 내용은 [cloud-init 설명서](https://cloudinit.readthedocs.io/en/latest/index.html)를 참조하세요. 사용자 데이터를 사용하여 일반적인 구성 작업을 수행할 수 있습니다. 여기에는 다음 옵션이 포함됩니다. + [사용자 또는 그룹 포함](https://cloudinit.readthedocs.io/en/latest/topics/examples.html#including-users-and-groups) + [패키지 설치](https://cloudinit.readthedocs.io/en/latest/topics/examples.html#install-arbitrary-packages) 관리형 노드 그룹과 함께 사용되는 시작 템플릿의 Amazon EC2 사용자 데이터는 Amazon Linux AMI의 경우 [MIME 멀티파트 아카이브](https://cloudinit.readthedocs.io/en/latest/topics/format.html#mime-multi-part-archive) 형식이어야 하고 Bottlerocket AMI의 경우 TOML 형식이어야 합니다. 이는 사용자 데이터가 노드가 클러스터에 조인하는 데 필요한 Amazon EKS 사용자 데이터와 병합되기 때문입니다. `kubelet`을 시작하거나 수정하는 명령을 사용자 데이터에 지정하지 마세요. 이는 Amazon EKS에 의해 병합된 사용자 데이터의 일부로 수행됩니다. 노드의 레이블 설정과 같은 특정 `kubelet` 파라미터는 관리형 노드 그룹 API를 통해 직접 구성될 수 있습니다. **참고** 수동으로 시작하거나 사용자 정의 구성 파라미터를 전달하는 등의 고급 `kubelet` 사용자 지정에 대한 자세한 내용은 [AMI 지정](#launch-template-custom-ami) 부분을 참조하세요. 시작 템플릿에 사용자 정의 AMI ID가 지정된 경우 Amazon EKS는 사용자 데이터를 병합하지 않습니다. 다음 세부 정보는 사용자 데이터 섹션에 대한 자세한 정보를 제공합니다. **Amazon Linux 2 사용자 데이터** 여러 사용자 데이터 블록을 단일 MIME 멀티파트 파일로 결합할 수 있습니다. 예를 들어 Docker 대몬을 구성하는 클라우드 boothook를 사용자 지정 패키지를 설치하는 사용자 데이터 셸 스크립트와 결합할 수 있습니다. MIME 멀티파트 파일은 다음과 같은 구성 요소로 이루어집니다. + 콘텐츠 유형 및 요소 경계 선언 - `Content-Type: multipart/mixed; boundary="==MYBOUNDARY=="` + MIME 버전 선언 - `MIME-Version: 1.0` + 다음 구성 요소를 포함하는 하나 이상의 사용자 데이터 블록: + 사용자 데이터 블록의 시작을 나타내는 열린 경계 - `--==MYBOUNDARY==` + 블록에 대한 콘텐츠 유형 선언: `Content-Type: text/cloud-config; charset="us-ascii"`. 콘텐츠 유형에 대한 자세한 내용은 [cloud-init](https://cloudinit.readthedocs.io/en/latest/topics/format.html) 문서를 참조하세요. + 사용자 데이터 콘텐츠(예: 셸 명령 또는 `cloud-init` 지시어 목록) + MIME 멀티파트 파일의 끝을 나타내는 폐쇄 경계: `--==MYBOUNDARY==--` 다음은 직접 파일을 작성하는 데 사용할 수 있는 MIME 멀티파트 파일의 예입니다. ``` MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="==MYBOUNDARY==" --==MYBOUNDARY== Content-Type: text/x-shellscript; charset="us-ascii" #!/bin/bash echo "Running custom user data script" --==MYBOUNDARY==-- ``` **Amazon Linux 2023 사용자 데이터** Amazon Linux 2023(AL2023)에 YAML 구성 스키마를 사용하는 새로운 노드 초기화 프로세스 `nodeadm`이 도입됩니다. 자체 관리형 노드 그룹 또는 시작 템플릿이 있는 AMI를 사용하는 경우 이제 새 노드 그룹을 생성할 때 추가 클러스터 메타데이터를 명시적으로 제공해야 합니다. 최소 필수 파라미터의 [예시](https://awslabs.github.io/amazon-eks-ami/nodeadm/)는 다음과 같으며, 여기에서 `apiServerEndpoint`, `certificateAuthority` 및 서비스 `cidr`가 필수입니다. ``` --- apiVersion: node.eks.aws/v1alpha1 kind: NodeConfig spec: cluster: name: my-cluster apiServerEndpoint: https://example.com certificateAuthority: Y2VydGlmaWNhdGVBdXRob3JpdHk= cidr: 10.100.0.0/16 ``` 대체로 이 구성은 사용자 데이터에 있는 그대로 또는 MIME 멀티파트 문서에 포함되도록 설정합니다. ``` MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="BOUNDARY" --BOUNDARY Content-Type: application/node.eks.aws --- apiVersion: node.eks.aws/v1alpha1 kind: NodeConfig spec: [...] --BOUNDARY-- ``` AL2에서 이러한 파라미터의 메타데이터는 Amazon EKS `DescribeCluster` API 직접 호출에서 확인되었습니다. AL2023 버전에서는 대형 노드 스케일 업 도중 추가 API 직접 호출로 인해 제한이 발생할 위험이 있기 때문에 이러한 동작이 변경되었습니다. 시작 템플릿이 없는 관리형 노드 그룹을 사용하거나 Karpenter를 사용하는 경우 이 변경 사항이 영향을 미치지 않습니다. `certificateAuthority` 및 서비스 `cidr`에 대한 자세한 내용은 *Amazon EKS API 참조*의 [https://docs.aws.amazon.com/eks/latest/APIReference/API_DescribeCluster.html](https://docs.aws.amazon.com/eks/latest/APIReference/API_DescribeCluster.html)를 참조하세요. 다음은 노드를 사용자 지정하기 위한 쉘 스크립트(예: 패키지 설치 또는 컨테이너 이미지 사전 캐싱)를 필수 `nodeadm` 구성과 결합하는 AL2023 사용자 데이터의 전체 예제입니다. 이 예제는 다음을 포함한 일반적인 사용자 지정을 보여줍니다. \$1 추가 시스템 패키지 설치 \$1 포드 시작 시간을 개선하기 위해 컨테이너 이미지 사전 캐싱 \$1 HTTP 프록시 구성 설정 \$1 노드 레이블 지정을 위한 `kubelet` 플래그 구성 ``` MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="BOUNDARY" --BOUNDARY Content-Type: text/x-shellscript; charset="us-ascii" #!/bin/bash set -o errexit set -o pipefail set -o nounset # Install additional packages yum install -y htop jq iptables-services # Pre-cache commonly used container images nohup docker pull public.ecr.aws/eks-distro/kubernetes/pause:3.2 & # Configure HTTP proxy if needed cat > /etc/profile.d/http-proxy.sh << 'EOF' export HTTP_PROXY="http://proxy.example.com:3128" export HTTPS_PROXY="http://proxy.example.com:3128" export NO_PROXY="localhost,127.0.0.1,169.254.169.254,.internal" EOF --BOUNDARY Content-Type: application/node.eks.aws apiVersion: node.eks.aws/v1alpha1 kind: NodeConfig spec: cluster: name: my-cluster apiServerEndpoint: https://example.com certificateAuthority: Y2VydGlmaWNhdGVBdXRob3JpdHk= cidr: 10.100.0.0/16 kubelet: config: clusterDNS: - 10.100.0.10 flags: - --node-labels=app=my-app,environment=production --BOUNDARY-- ``` **Bottlerocket 사용자 데이터** Bottlerocket은 사용자 데이터를 TOML 형식으로 구성합니다. Amazon EKS에서 제공하는 사용자 데이터와 병합할 사용자 데이터를 제공할 수 있습니다. 예를 들어, 추가 `kubelet` 설정을 제공할 수 있습니다. ``` [settings.kubernetes.system-reserved] cpu = "10m" memory = "100Mi" ephemeral-storage= "1Gi" ``` 지원되는 설정에 대한 자세한 내용은 [Bottlerocket 설명서](https://github.com/bottlerocket-os/bottlerocket)를 참조하세요. 사용자 데이터에서 노드 레이블과 [테인트](node-taints-managed-node-groups.md)를 구성할 수 있습니다. 그러나 대신 노드 그룹 내에서 구성하는 것이 좋습니다. 그러면 Amazon EKS에서 이러한 구성을 적용합니다. 사용자 데이터가 병합되면 서식이 유지되지 않지만 내용은 동일하게 유지됩니다. 사용자 데이터에 제공하는 구성은 Amazon EKS에서 구성하는 모든 설정을 재정의합니다. 따라서 `settings.kubernetes.max-pods` 또는 `settings.kubernetes.cluster-dns-ip`를 설정하면 사용자 데이터의 값이 노드에 적용됩니다. Amazon EKS는 모든 유효한 TOML을 지원하지 않습니다. 다음은 지원되지 않는 알려진 형식 목록입니다. + 따옴표 붙은 키 안의 따옴표: `'quoted "value"' = "value"` + 값의 이스케이프된 따옴표: `str = "I’m a string. \"You can quote me\""` + 혼합 부동 소수점 및 정수: `numbers = [ 0.1, 0.2, 0.5, 1, 2, 5 ]` + 배열의 혼합 유형: `contributors = ["[foo@example.com](mailto:foo@example.com)", { name = "Baz", email = "[baz@example.com](mailto:baz@example.com)" }]` + 따옴표 붙은 키가 있는 대괄호로 묶은 헤더: `[foo."bar.baz"]` **Windows 사용자 데이터** Windows 사용자 데이터는 PowerShell 명령을 사용합니다. 관리형 노드 그룹을 생성할 때 사용자 지정 사용자 데이터는 Amazon EKS 관리형 사용자 데이터와 결합됩니다. PowerShell 명령과 관리형 사용자 데이터 명령이 모두 하나의 `` 태그 내에서 차례로 나타납니다. Windows 노드 그룹을 생성할 때 Amazon EKS는 Linux 기반 노드가 클러스터에 조인할 수 있도록 `aws-auth` `ConfigMap`을 업데이트합니다. 서비스는 Windows AMI에 대한 권한을 자동으로 구성하지 않습니다. Windows 노드를 사용하는 경우 액세스 항목 API를 통해 또는 `aws-auth` `ConfigMap`을 직접 업데이트하여 액세스를 관리해야 합니다. 자세한 내용은 [EKS 클러스터에 Windows 노드 배포](windows-support.md) 섹션을 참조하세요. 시작 템플릿에 AMI ID가 지정되어 있지 않으면 사용자 데이터의 Windows Amazon EKS Bootstrap 스크립트를 사용하여 Amazon EKS를 구성하지 마세요. 예시 사용자 데이터는 다음과 같습니다. ``` Write-Host "Running custom user data script" ``` ## AMI 지정 다음 요구 사항 중 하나가 있는 경우 시작 템플릿의 `ImageId` 필드에 AMI ID를 지정합니다. 추가 정보를 보려면 요구 사항을 선택하세요. ### Amazon EKS 최적화 Linux/Bottlerocket AMI에 포함된 `bootstrap.sh` 파일에 인수를 전달하기 위해 사용자 데이터를 제공함 부트스트래핑은 인스턴스가 시작될 때 실행할 수 있는 명령의 추가에 대해 설명하는 데 사용되는 용어입니다. 예를 들어, 부트스트랩을 사용하면 추가 [kubelet](https://kubernetes.io/docs/reference/command-line-tools-reference/kubelet/) 인수를 사용할 수 있습니다. 시작 템플릿을 지정하지 않고 `eksctl`을 사용하여 `bootstrap.sh` 스크립트에 인수를 전달할 수 있습니다. 이를 위해 시작 템플릿의 사용자 데이터 부분에 정보를 지정할 수도 있습니다. **시작 템플릿을 지정하지 않고 eksctl** 다음 내용으로 *my-nodegroup.yaml*이라는 파일을 만듭니다. 모든 *예제 값*을 자신의 값으로 바꾸세요. `--apiserver-endpoint`, `--b64-cluster-ca` 및 `--dns-cluster-ip` 인수는 선택 사항입니다. 그러나 이를 정의하면 `bootstrap.sh` 스크립트가 `describeCluster`를 직접 호출하는 것을 방지할 수 있습니다. 이는 노드를 자주 확장하고 축소하는 프라이빗 클러스터 설정이나 클러스터에서 유용합니다. `bootstrap.sh` 스크립트에 대한 자세한 내용은 GitHub의 [bootstrap.sh](https://github.com/awslabs/amazon-eks-ami/blob/main/templates/al2/runtime/bootstrap.sh) 파일을 참조하세요. + 유일한 필수 인수는 클러스터 이름(*my-cluster*)입니다. + `ami-1234567890abcdef0 `에 대해 최적화된 AMI ID를 검색하려면 다음 섹션을 참조하세요. + [권장 Amazon Linux AMI ID 검색](retrieve-ami-id.md) + [권장 Bottlerocket AMI ID 검색](retrieve-ami-id-bottlerocket.md) + [권장 Microsoft Windows AMI ID 검색](retrieve-windows-ami-id.md) + 클러스터의 *certificate-authority*를 검색하려면 다음 명령을 실행합니다. ``` aws eks describe-cluster --query "cluster.certificateAuthority.data" --output text --name my-cluster --region region-code ``` + 클러스터의 *api-server-endpoint*를 검색하려면 다음 명령을 실행합니다. ``` aws eks describe-cluster --query "cluster.endpoint" --output text --name my-cluster --region region-code ``` + `--dns-cluster-ip`의 값은 `.10`으로 끝나는 서비스 CIDR입니다. 클러스터의 *service-cidr*를 검색하려면 다음 명령을 실행합니다. 예를 들어, 반환된 값이 `ipv4 10.100.0.0/16`인 경우 값은 *10.100.0.10*입니다. ``` aws eks describe-cluster --query "cluster.kubernetesNetworkConfig.serviceIpv4Cidr" --output text --name my-cluster --region region-code ``` + 이 예에서는 추가 `kubelet` 인수를 제공하여 Amazon EKS 최적화 AMI에 포함된 `bootstrap.sh` 스크립트로 사용자 지정 `max-pods` 값을 설정합니다. 노드 그룹 이름은 63자를 초과할 수 없습니다. 문자나 숫자로 시작하되, 나머지 문자의 경우 하이픈과 밑줄을 포함할 수 있습니다. *my-max-pods-value*를 선택하는 방법에 대한 도움말은 을 참조하세요. 관리형 노드 그룹을 사용할 때 `maxPods`를 결정하는 방법에 대한 자세한 내용은 [maxPods 결정 방법](choosing-instance-type.md#max-pods-precedence) 섹션을 참조하세요. ``` --- apiVersion: eksctl.io/v1alpha5 kind: ClusterConfig metadata: name: my-cluster region: region-code managedNodeGroups: - name: my-nodegroup ami: ami-1234567890abcdef0 instanceType: m5.large privateNetworking: true disableIMDSv1: true labels: { x86-al2-specified-mng } overrideBootstrapCommand: | #!/bin/bash /etc/eks/bootstrap.sh my-cluster \ --b64-cluster-ca certificate-authority \ --apiserver-endpoint api-server-endpoint \ --dns-cluster-ip service-cidr.10 \ --kubelet-extra-args '--max-pods=my-max-pods-value' \ --use-max-pods false ``` 사용 가능한 모든 `eksctl` `config` 파일 옵션은 `eksctl` 설명서의 [구성 파일 스키마](https://eksctl.io/usage/schema/)를 참조하세요. `eksctl` 유틸리티는 여전히 사용자를 위해 시작 템플릿을 생성하고 해당 사용자 데이터를 `config` 파일에서 제공되는 데이터로 채웁니다. 다음 명령을 사용하여 노드 그룹을 생성합니다. ``` eksctl create nodegroup --config-file=my-nodegroup.yaml ``` **시작 템플릿의 사용자 데이터** 시작 템플릿의 사용자 데이터 부분에서 다음 정보를 지정합니다. 모든 *예제 값*을 자신의 값으로 바꾸세요. `--apiserver-endpoint`, `--b64-cluster-ca` 및 `--dns-cluster-ip` 인수는 선택 사항입니다. 그러나 이를 정의하면 `bootstrap.sh` 스크립트가 `describeCluster`를 직접 호출하는 것을 방지할 수 있습니다. 이는 노드를 자주 확장하고 축소하는 프라이빗 클러스터 설정이나 클러스터에서 유용합니다. `bootstrap.sh` 스크립트에 대한 자세한 내용은 GitHub의 [bootstrap.sh](https://github.com/awslabs/amazon-eks-ami/blob/main/templates/al2/runtime/bootstrap.sh) 파일을 참조하세요. + 유일한 필수 인수는 클러스터 이름(*my-cluster*)입니다. + 클러스터의 *certificate-authority*를 검색하려면 다음 명령을 실행합니다. ``` aws eks describe-cluster --query "cluster.certificateAuthority.data" --output text --name my-cluster --region region-code ``` + 클러스터의 *api-server-endpoint*를 검색하려면 다음 명령을 실행합니다. ``` aws eks describe-cluster --query "cluster.endpoint" --output text --name my-cluster --region region-code ``` + `--dns-cluster-ip`의 값은 `.10`으로 끝나는 서비스 CIDR입니다. 클러스터의 *service-cidr*를 검색하려면 다음 명령을 실행합니다. 예를 들어, 반환된 값이 `ipv4 10.100.0.0/16`인 경우 값은 *10.100.0.10*입니다. ``` aws eks describe-cluster --query "cluster.kubernetesNetworkConfig.serviceIpv4Cidr" --output text --name my-cluster --region region-code ``` + 이 예에서는 추가 `kubelet` 인수를 제공하여 Amazon EKS 최적화 AMI에 포함된 `bootstrap.sh` 스크립트로 사용자 지정 `max-pods` 값을 설정합니다. *my-max-pods-value*를 선택하는 방법에 대한 도움말은 을 참조하세요. 관리형 노드 그룹을 사용할 때 `maxPods`를 결정하는 방법에 대한 자세한 내용은 [maxPods 결정 방법](choosing-instance-type.md#max-pods-precedence) 섹션을 참조하세요. ``` MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="==MYBOUNDARY==" --==MYBOUNDARY== Content-Type: text/x-shellscript; charset="us-ascii" #!/bin/bash set -ex /etc/eks/bootstrap.sh my-cluster \ --b64-cluster-ca certificate-authority \ --apiserver-endpoint api-server-endpoint \ --dns-cluster-ip service-cidr.10 \ --kubelet-extra-args '--max-pods=my-max-pods-value' \ --use-max-pods false --==MYBOUNDARY==-- ``` ### Amazon EKS 최적화 Windows AMI에 포함된 `Start-EKSBootstrap.ps1` 파일에 인수를 전달하기 위해 사용자 데이터를 제공함 부트스트래핑은 인스턴스가 시작될 때 실행할 수 있는 명령의 추가에 대해 설명하는 데 사용되는 용어입니다. 시작 템플릿을 지정하지 않고 `eksctl`을 사용하여 `Start-EKSBootstrap.ps1` 스크립트에 인수를 전달할 수 있습니다. 이를 위해 시작 템플릿의 사용자 데이터 부분에 정보를 지정할 수도 있습니다. 사용자 지정 Windows AMI ID를 지정하려면 다음과 같은 사항을 고려하세요. + 시작 템플릿을 사용하고 사용자 데이터 부분의 필수 부트스트랩 명령을 제공해야 합니다. 원하는 Windows ID를 검색하려면 [최적화된 Windows AMI가 있는 노드 생성](eks-optimized-windows-ami.md) 테이블을 사용할 수 있습니다. + 몇 가지 제한과 조건이 있습니다. 예를 들어, AWS IAM Authenticator 구성 맵에 `eks:kube-proxy-windows`를 추가해야 합니다. 자세한 내용은 [AMI ID 지정 시 제한과 조건](#mng-ami-id-conditions) 섹션을 참조하세요. 시작 템플릿의 사용자 데이터 부분에서 다음 정보를 지정합니다. 모든 *예제 값*을 자신의 값으로 바꾸세요. `-APIServerEndpoint`, `-Base64ClusterCA` 및 `-DNSClusterIP` 인수는 선택 사항입니다. 그러나 이를 정의하면 `Start-EKSBootstrap.ps1` 스크립트가 `describeCluster`를 직접 호출하는 것을 방지할 수 있습니다. + 유일한 필수 인수는 클러스터 이름(*my-cluster*)입니다. + 클러스터의 *certificate-authority*를 검색하려면 다음 명령을 실행합니다. ``` aws eks describe-cluster --query "cluster.certificateAuthority.data" --output text --name my-cluster --region region-code ``` + 클러스터의 *api-server-endpoint*를 검색하려면 다음 명령을 실행합니다. ``` aws eks describe-cluster --query "cluster.endpoint" --output text --name my-cluster --region region-code ``` + `--dns-cluster-ip`의 값은 `.10`으로 끝나는 서비스 CIDR입니다. 클러스터의 *service-cidr*를 검색하려면 다음 명령을 실행합니다. 예를 들어, 반환된 값이 `ipv4 10.100.0.0/16`인 경우 값은 *10.100.0.10*입니다. ``` aws eks describe-cluster --query "cluster.kubernetesNetworkConfig.serviceIpv4Cidr" --output text --name my-cluster --region region-code ``` + 추가 인수는 [부트스트랩 스크립트 구성 파라미터](eks-optimized-windows-ami.md#bootstrap-script-configuration-parameters) 부분을 참조하세요. **참고** 사용자 지정 서비스 CIDR을 사용하는 경우 `-ServiceCIDR` 파라미터를 사용하여 CIDR을 지정해야 합니다. 그렇지 않으면 클러스터의 포드에 대한 DNS 확인이 실패합니다. ``` [string]$EKSBootstrapScriptFile = "$env:ProgramFiles\Amazon\EKS\Start-EKSBootstrap.ps1" & $EKSBootstrapScriptFile -EKSClusterName my-cluster ` -Base64ClusterCA certificate-authority ` -APIServerEndpoint api-server-endpoint ` -DNSClusterIP service-cidr.10 ``` ### 특정 보안, 규정 준수 또는 내부 정책 요구 사항으로 인해 사용자 정의 AMI 실행함 자세한 내용은 *Amazon EC2 사용 설명서*에서 [Amazon Machine Image(AMI)](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/AMIs.html)를 참조하세요. Amazon EKS AMI 빌드 사양에는 Amazon Linux를 기반으로 사용자 지정 Amazon EKS AMI를 구축하기 위한 리소스 및 구성 스크립트가 포함되어 있습니다. 자세한 내용은 GitHub에서 [Amazon EKS AMI 빌드 사양](https://github.com/awslabs/amazon-eks-ami/) 섹션을 참조하세요. 다른 운영 체제와 함께 설치된 사용자 지정 AMI를 생성하려면 GitHub에서 [Amazon EKS 샘플 사용자 지정 AMI](https://github.com/aws-samples/amazon-eks-custom-amis) 섹션을 참조하세요. 관리형 노드 그룹에 사용되는 시작 템플릿에서는 AMI ID에 동적 파라미터 참조를 사용할 수 없습니다. **중요** AMI를 지정할 때 Amazon EKS는 클러스터의 컨트롤 플레인 버전을 기준으로 AMI에 포함된 Kubernetes 버전을 검증하지 않습니다. 사용자 지정 AMI의 Kubernetes 버전이 [Kubernetes 버전 스큐 정책](https://kubernetes.io/releases/version-skew-policy)을 준수하는지 확인하는 것은 사용자의 책임입니다. 노드의 `kubelet` 버전은 클러스터 버전보다 최신 버전이어서는 안 됨 노드의 `kubelet` 버전은 클러스터 버전 뒤로 최대 3개 이상의 마이너 버전(Kubernetes 버전 `1.28` 이상의 경우)이거나 클러스터 버전 뒤로 최대 2개의 마이너 버전(Kubernetes 버전 `1.27` 이하의 경우)이어야 함 버전 스큐를 위반하는 관리형 노드 그룹을 생성하면 다음과 같은 상황이 발생할 수 있습니다. 노드가 클러스터에 조인하지 못함 정의되지 않은 동작 또는 API 비호환성 클러스터 불안정성 또는 워크로드 장애 AMI를 지정할 때 Amazon EKS는 사용자 데이터를 병합하지 않습니다. 사용자가 필요한 `bootstrap` 명령을 사용하여 노드를 클러스터에 조인해야 합니다. 노드가 클러스터에 조인되지 않은 경우 Amazon EKS `CreateNodegroup` 및 `UpdateNodegroupVersion` 작업도 실패합니다. ## AMI ID 지정 시 제한과 조건 다음은 관리형 노드 그룹으로 AMI ID를 지정하는 것과 관련된 제한 및 조건입니다. + 시작 템플릿에서 AMI ID를 지정하는 것과 AMI ID를 지정하지 않는 것 사이를 전환하려면 새 노드 그룹을 생성해야 합니다. + 최신 AMI 버전을 사용할 수 있는 경우에도 콘솔에 알림이 표시되지 않습니다. 노드 그룹을 최신 AMI 버전으로 업데이트하려면 업데이트된 AMI ID로 시작 템플릿의 새 버전을 생성해야 합니다. 그런 다음 새 시작 템플릿 버전으로 노드 그룹을 업데이트해야 합니다. + AMI ID를 지정하는 경우 API에서 다음 필드를 설정할 수 없습니다. + `amiType` + `releaseVersion` + `version` + AMI ID를 지정하는 경우 API에 설정된 모든 `taints`가 비동기적으로 적용됩니다. 노드가 클러스터에 합류하기 전에 테인트를 적용하려면 `kubelet` 명령줄 플래그를 사용하여 사용자 데이터의 `--register-with-taints`에 테인트를 전달해야 합니다. 자세한 내용은 Kubernetes 문서의 [kubelet](https://kubernetes.io/docs/reference/command-line-tools-reference/kubelet/)를 참조하세요. + Windows 관리형 노드 그룹에 사용자 지정 AMI ID를 지정할 때는 AWS IAM Authenticator 구성 맵에 `eks:kube-proxy-windows`를 추가합니다. DNS가 제대로 작동하려면 필요합니다. 1. 편집을 위해 AWS IAM Authenticator 구성 맵을 엽니다. ``` kubectl edit -n kube-system cm aws-auth ``` 1. Windows 노드와 연결된 각 `rolearn` 아래의 `groups` 목록에 이 항목을 추가합니다. 구성 맵은 [aws-auth-cm-windows.yaml ](https://s3.us-west-2.amazonaws.com/amazon-eks/cloudformation/2020-10-29/aws-auth-cm-windows.yaml)과 비슷해야 합니다. ``` - eks:kube-proxy-windows ``` 1. 파일을 저장하고 텍스트 편집기를 종료합니다. + 사용자 지정 시작 템플릿을 사용하는 모든 AMI의 경우 관리형 노드 그룹의 `HttpPutResponseHopLimit` 기본값은 `2`로 설정됩니다. # 클러스터에서 관리형 노드 그룹 삭제 이 주제에서는 Amazon EKS 관리형 노드 그룹을 삭제하는 방법에 대해 설명합니다. 관리형 노드 그룹을 삭제하면 Amazon EKS는 먼저 Auto Scaling 그룹의 최소, 최대 및 원하는 크기를 0으로 설정합니다. 그러면 노드 그룹이 축소됩니다. 각 인스턴스가 종료되기 전에 Amazon EKS는 해당 노드를 드레이닝하기 위해 신호를 전송합니다. 드레이닝 프로세스 중에 Kubernetes는 노드의 각 포드에서 다음을 수행합니다. 구성된 `preStop` 수명 주기 후크를 실행하고, `SIGTERM` 신호를 컨테이너로 전송한 다음, 정상적으로 종료될 때까지 `terminationGracePeriodSeconds`의 시간을 기다립니다. 5분 후에 노드가 드레이닝되지 않을 경우 Amazon EKS는 오토 스케일링을 통해 인스턴스 종료를 계속 강제로 수행할 수 있습니다. 모든 인스턴스가 종료되면 Auto Scaling 그룹이 삭제됩니다. **중요** 클러스터의 다른 관리형 노드 그룹에서 사용하지 않는 노드 IAM 역할을 사용하는 관리형 노드 그룹을 삭제하면 역할이 `aws-auth` `ConfigMap`에서 제거됩니다. 클러스터의 자체 관리형 노드 그룹이 동일한 노드 IAM 역할을 사용하는 경우 자체 관리형 노드는 `NotReady` 상태로 전환됩니다. 또한 클러스터 작업도 중단됩니다. 자체 관리 노드 그룹에만 사용하는 역할에 대한 매핑을 추가하려면 클러스터의 플랫폼 버전이 [EKS 액세스 항목으로 IAM 사용자에게 Kubernetes 액세스 권한 부여](access-entries.md)의 전제 조건 섹션에 나열된 최소 버전 이상인 경우 [액세스 항목 생성](creating-access-entries.md)를 참조하세요. 플랫폼 버전이 액세스 항목에 필요한 최소 버전보다 이전인 경우 항목을 `aws-auth` `ConfigMap`에 다시 추가할 수 있습니다. 자세한 내용을 보려면 터미널에 `eksctl create iamidentitymapping --help`를 입력합니다. 관리되는 노드 그룹은 다음을 사용하여 삭제할 수 있습니다: + [`eksctl`](#eksctl-delete-managed-nodegroup) + [AWS Management Console](#console-delete-managed-nodegroup) + [AWS CLI](#awscli-delete-managed-nodegroup) ## `eksctl` **`eksctl`로 관리되는 노드 그룹 삭제** 다음 명령을 입력하십시오. 모든 ``를 고유한 값으로 바꿉니다. ``` eksctl delete nodegroup \ --cluster \ --name \ --region ``` 추가 옵션은 `eksctl` 설명서의 [Deleting and draining nodegroups](https://eksctl.io/usage/nodegroups/#deleting-and-draining-nodegroups)를 참조하세요. ## AWS Management Console **로 관리되는 노드 그룹 삭제AWS Management Console** 1. [Amazon EKS 콘솔](https://console.aws.amazon.com/eks/home#/clusters)을 엽니다. 1. **클러스터** 페이지에서 삭제할 노드 그룹이 포함된 클러스터를 선택합니다. 1. 선택한 클러스터 페이지에서 **컴퓨팅** 탭을 선택합니다. 1. **노드 그룹** 섹션에서 삭제할 노드 그룹을 선택합니다. 그런 다음 **삭제**를 선택합니다. 1. **노드 그룹 삭제** 확인 대화 상자에서 노드 그룹의 이름을 입력합니다. 그런 다음 **삭제**를 선택합니다. ## AWS CLI **AWS CLI을 사용하여 관리형 노드 그룹을 삭제** 1. 다음 명령을 입력하십시오. 모든 ``를 고유한 값으로 바꿉니다. ``` aws eks delete-nodegroup \ --cluster-name \ --nodegroup-name \ --region ``` 1. CLI 구성에 `cli_pager=`가 설정된 경우 키보드의 화살표 키를 사용하여 응답 출력을 스크롤하세요. 작업을 마치면 `q` 키를 누릅니다. 자세한 옵션은 *AWS CLI 명령 참조*에서 ` [delete-nodegroup](https://docs.aws.amazon.com/cli/latest/reference/eks/delete-nodegroup.html) ` 명령을 참조하세요.