**이 페이지 개선에 도움 주기** 이 사용자 가이드에 기여하려면 모든 페이지의 오른쪽 창에 있는 **GitHub에서 이 페이지 편집** 링크를 선택합니다. # 노드를 사용하여 컴퓨팅 리소스 관리 Kubernetes 노드는 컨테이너화된 애플리케이션을 실행하는 시스템입니다. 각 노드에는 다음과 같은 구성 요소가 있습니다. + ** [컨테이너 런타임](https://kubernetes.io/docs/setup/production-environment/container-runtimes/) ** – 컨테이너 실행을 담당하는 소프트웨어입니다. + ** [kubelet](https://kubernetes.io/docs/reference/command-line-tools-reference/kubelet/) ** – 컨테이너가 정상 상태이고 연결된 포드 내에서 실행되고 있는지 확인합니다. + ** [kube-proxy](https://kubernetes.io/docs/reference/command-line-tools-reference/kube-proxy/) ** – 포드에 대한 통신을 허용하는 네트워크 규칙을 유지 관리합니다. 자세한 내용은 Kubernetes 문서의 [노드](https://kubernetes.io/docs/concepts/architecture/nodes/)를 참조하세요. Amazon EKS 클러스터는 [EKS 자동 모드 관리형 노드](automode.md), [자체 관리형 노드](worker.md), [Amazon EKS 관리형 노드 그룹](managed-node-groups.md), [AWS Fargate](fargate.md), [Amazon EKS Hybrid Nodes](hybrid-nodes-overview.md)의 모든 조합에서 포드를 예약할 수 있습니다. 클러스터에 배포된 노드에 대한 자세한 내용은 [AWS Management Console에서 Kubernetes 리소스 보기](view-kubernetes-resources.md) 부분을 참조하세요. **참고** 하이브리드 노드를 제외한 노드는 클러스터를 생성할 때 선택한 서브넷과 동일한 VPC에 있어야 합니다. 하지만 노드가 동일한 서브넷에 있을 필요는 없습니다. ## 컴퓨팅 옵션 비교 다음 표에는 요구 사항에 가장 적합한 옵션을 결정할 때 평가할 몇 가지 기준이 나와 있습니다. 자체 관리형 노드는 나열된 모든 기준을 지원하는 또 다른 옵션이지만 필요한 수동 유지 관리 작업이 훨씬 더 많습니다. 자세한 내용은 [자체 관리형 노드로 노드 직접 유지](worker.md) 단원을 참조하십시오. **참고** Bottlerocket은 이 표의 일반 정보와 몇 가지 구체적인 차이점이 있습니다. 자세한 내용은 GitHub의 Bottlerocket [설명서](https://github.com/bottlerocket-os/bottlerocket/blob/develop/README.md)를 참조하세요. | 기준 | EKS 관리형 노드 그룹 | EKS Auto Mode | Amazon EKS Hybrid Nodes | | --- | --- | --- | --- | | [AWS Outposts](https://docs.aws.amazon.com/outposts/latest/userguide/what-is-outposts.html)에 배포 가능 | 아니요 | 아니요 | 아니요 | | [AWS Local Zones](local-zones.md)에 배포할 수 있습니다. | 예 | 아니요 | 아니요 | | Windows가 필요한 컨테이너를 실행할 수 있습니다. | 예 | 아니요 | 아니요 | | Linux가 필요한 컨테이너를 실행할 수 있습니다. | 예 | 예 | 예 | | Inferentia 칩이 필요한 워크로드를 실행할 수 있습니다. | [예](inferentia-support.md) — Amazon Linux 노드만 해당 | 예 | 아니요 | | GPU가 필요한 워크로드를 실행할 수 있습니다. | [예](eks-optimized-ami.md#gpu-ami) — Amazon Linux 노드만 해당 | 예 | 예 | | Arm 프로세서가 필요한 워크로드를 실행할 수 있습니다. | [예](eks-optimized-ami.md#arm-ami) | 예 | 예 | | AWS [Bottlerocket](https://aws.amazon.com/bottlerocket/)을 실행할 수 있습니다. | 예 | 예 | 아니요 | | 포드가 CPU, 메모리, 스토리지 및 네트워크 리소스를 다른 포드와 공유합니다. | 예 | 예 | 예 | | Amazon EC2 인스턴스를 배포하고 관리해야 합니다. | 예 | 아니요-[EC2 관리형 인스턴스](automode-learn-instances.md) 알아보기 | 예-온프레미스의 물리적 또는 가상 머신은 사용자가 선택한 도구로 관리합니다. | | Amazon EC2 인스턴스의 운영 체제를 보호, 유지 관리 및 패치해야 합니다. | 예 | 아니요 | 예-물리적 머신 또는 가상 머신에서 실행되는 운영 체제는 사용자가 선택한 도구로 관리합니다. | | 노드 배포 시 추가 [kubelet](https://kubernetes.io/docs/reference/command-line-tools-reference/kubelet/) 인수와 같은 부트스트랩 인수를 제공할 수 있습니다. | 예-사용자 지정 AMI와 함께 `eksctl` 또는 [시작 템플릿](launch-templates.md)을 사용합니다. | 아니요-[`NodeClass`를 사용하여 노드 구성](create-node-class.md) | 예-nodeadm을 사용하여 부트스트랩 인수를 사용자 지정할 수 있습니다. [하이브리드 노드 `nodeadm` 참조](hybrid-nodes-nodeadm.md) 섹션을 참조하세요. | | 노드에 할당된 IP 주소와 다른 CIDR 블록의 포드에 IP 주소를 할당할 수 있습니다. | 예 - 사용자 지정 AMI와 함께 시작 템플릿 사용. 자세한 내용은 [시작 템플릿을 사용한 관리형 노드 사용자 지정](launch-templates.md) 단원을 참조하십시오. | 아니요 | 예-[하이브리드 노드에 대한 CNI 구성](hybrid-nodes-cni.md) 섹션을 참조하세요. | | 노드에 SSH를 연결할 수 있습니다. | 예 | 아니요-[노드 문제 해결 방법 알아보기](auto-troubleshoot.md) | 예 | | 사용자 지정 AMI 노드에 배포할 수 있습니다. | 예 - [시작 템플릿](launch-templates.md) 사용 | 아니요 | 예 | | 사용자 지정 CNI 노드에 배포할 수 있습니다. | 예 — 사용자 지정 AMI와 함께 [시작 템플릿](launch-templates.md) 사용 | 아니요 | 예 | | 노드 AMI를 직접 업데이트해야 합니다. | [예](update-managed-node-group.md) - Amazon EKS 최적화 AMI를 배포한 경우 업데이트가 제공되면 Amazon EKS 콘솔에 알림이 표시됩니다. 콘솔에서 클릭 한 번으로 업데이트를 수행할 수 있습니다. 사용자 정의 AMI를 배포한 경우 업데이트가 제공되면 Amazon EKS 콘솔에 알림이 표시되지 않습니다. 업데이트는 직접 수행해야 합니다. | 아니요 | 예-물리적 머신 또는 가상 머신에서 실행되는 운영 체제는 사용자가 선택한 도구로 관리합니다. [하이브리드 노드용 운영 체제 준비](hybrid-nodes-os.md) 섹션을 참조하세요. | | 노드 Kubernetes 버전을 직접 업데이트해야 합니다. | [예](update-managed-node-group.md) - Amazon EKS 최적화 AMI를 배포한 경우 업데이트가 제공되면 Amazon EKS 콘솔에 알림이 표시됩니다. 콘솔에서 클릭 한 번으로 업데이트를 수행할 수 있습니다. 사용자 정의 AMI를 배포한 경우 업데이트가 제공되면 Amazon EKS 콘솔에 알림이 표시되지 않습니다. 업데이트는 직접 수행해야 합니다. | 아니요 | 예-자체 선택 도구 또는 `nodeadm`을 사용하여 하이브리드 노드 업그레이드를 관리합니다. [클러스터의 하이브리드 노드 업그레이드](hybrid-nodes-upgrade.md) 섹션을 참조하세요. | | 포트에 Amazon EBS 스토리지를 사용할 수 있습니다. | [예](ebs-csi.md) | 예-통합 기능으로 사용할 수 있습니다. [스토리지 클래스 생성](create-storage-class.md) 방법을 알아봅니다. | 아니요 | | 포드에 Amazon EFS 스토리지를 사용할 수 있습니다. | [예](efs-csi.md) | 예 | 아니요 | | 포트에 Amazon FSx for Lustre 스토리지를 사용할 수 있습니다. | [예](fsx-csi.md) | 예 | 아니요 | | 서비스에 Network Load Balancer를 사용할 수 있습니다. | [예](network-load-balancing.md) | 예 | 예-대상 유형 `ip`를 사용해야 합니다. | | 포드가 퍼블릭 서브넷에서 실행될 수 있습니다. | 예 | 예 | 아니요-포드는 온프레미스 환경에서 실행됩니다. | | 개별 포드에 서로 다른 VPC 보안 그룹을 할당할 수 있습니다. | [예](security-groups-for-pods.md) — Linux 노드만 | 아니요 | 아니요 | | Kubernetes DaemonSet를 실행할 수 있습니다. | 예 | 예 | 예 | | 포드 매니페스트에서 `HostPort` 및 `HostNetwork`를 지원합니다. | 예 | 예 | 예 | | AWS 리전 가용성 | [모든 Amazon EKS 지원 리전](https://docs.aws.amazon.com/general/latest/gr/eks.html) | [모든 Amazon EKS 지원 리전](https://docs.aws.amazon.com/general/latest/gr/eks.html) | AWS GovCloud(미국) 리전 및 중국 리전을 제외한 [모든 Amazon EKS 지원 리전](https://docs.aws.amazon.com/general/latest/gr/eks.html) | | Amazon EC2 전용 호스트에서 컨테이너를 실행할 수 있습니다. | 예 | 아니요 | 아니요 | | 요금 | 여러 포드를 실행하는 Amazon EC2 인스턴스의 비용입니다. 자세한 설명은 [Amazon EC2 요금](https://aws.amazon.com/ec2/pricing/)을 참조하세요. | 클러스터에서 EKS Auto Mode가 활성화된 경우 Auto Mode의 컴퓨팅 기능을 사용하여 시작된 인스턴스에 대해 표준 EC2 인스턴스 요금 외에 별도의 요금을 지불합니다. 금액은 시작된 인스턴스 유형과 클러스터가 위치한 AWS 리전에 따라 다릅니다. 자세한 내용은 [Amazon EKS 요금](https://aws.amazon.com/eks/pricing/)을 참조하세요. | 시간당 하이브리드 노드 vCPU 비용. 자세한 내용은 [Amazon EKS 요금](https://aws.amazon.com/eks/pricing/)을 참조하세요. | # 관리형 노드 그룹을 사용한 노드 수명 주기 간소화 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) ` 명령을 참조하세요. # 자체 관리형 노드로 노드 직접 유지 클러스터에는 포드가 예약된 하나 이상의 Amazon EC2 노드가 포함되어 있습니다. Amazon EKS 노드는 AWS 계정에서 실행되고 클러스터 API 서버 엔드포인트를 통해 클러스터의 제어 영역에 연결됩니다. Amazon EC2 가격을 기준으로 요금이 청구됩니다. 자세한 설명은 [Amazon EC2 요금](https://aws.amazon.com/ec2/pricing/)을 참조하세요. 클러스터에는 여러 노드 그룹이 포함될 수 있습니다. 각 노드 그룹에는 [Amazon EC2 Auto Scaling 그룹](https://docs.aws.amazon.com/autoscaling/ec2/userguide/AutoScalingGroup.html)에 배포된 하나 이상의 노드가 포함되어 있습니다. 그룹 내 노드의 인스턴스 유형은 [Karpenter](https://karpenter.sh/)를 사용한 [attribute-based 인스턴스 유형 선택](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ec2-fleet-attribute-based-instance-type-selection.html)을 사용하는 경우와 같이 달라질 수 있습니다. 노드 그룹의 모든 인스턴스는 [Amazon EKS 노드 IAM 역할](create-node-role.md)을 사용해야 합니다. Amazon EKS에서는 Amazon EKS 최적화 AMI라는 특별한 Amazon Machine Image(AMI)를 제공합니다. AMI는 Amazon EKS와 함께 작동하도록 구성되어 있습니다. 구성 요소에는 `containerd`, `kubelet`, AWS IAM 인증자가 포함됩니다. 또한 AMI에는 특별한 [부트스트랩 스크립트](https://github.com/awslabs/amazon-eks-ami/blob/main/templates/al2/runtime/bootstrap.sh)도 포함되어 있어 클러스터의 제어 영역을 자동으로 찾고 연결할 수 있습니다. CIDR 블록을 사용하여 클러스터의 퍼블릭 엔드포인트에 대한 액세스를 제한하는 경우 프라이빗 엔드포인트 액세스도 사용 설정하는 것이 좋습니다. 이는 노드가 클러스터와 통신할 수 있도록 하기 위한 것입니다. 프라이빗 엔드포인트를 활성화하지 않은 경우, 퍼블릭 액세스에 대해 지정하는 CIDR 블록에는 VPC의 송신 소스가 포함되어야 합니다. 자세한 내용은 [클러스터 API 서버 엔드포인트](cluster-endpoint.md) 섹션을 참조하세요. Amazon EKS 클러스터에 자체 관리형 노드를 추가하려면 다음 항목을 참조하세요. 자체 관리형 노드를 수동으로 시작하는 경우 ``이 클러스터와 일치하는지 확인하면서 각 노드에 다음 태그를 추가합니다. 자세한 내용은 [개별 리소스에 대한 태그 추가 및 삭제](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/Using_Tags.html#adding-or-deleting-tags)를 참조하세요. 가이드의 단계를 수행하면 필수 태그가 자동으로 노드에 추가됩니다. | 키 | 값 | | --- | --- | | `kubernetes.io/cluster/` | `owned` | **중요** Amazon EC2 인스턴스 메타데이터 서비스(IMDS)의 태그는 EKS 노드와 호환되지 않습니다. 인스턴스 메타데이터 태그가 활성화되면 태그 값에 슬래시('/')를 사용할 수 없습니다. 이러한 제한으로 인해 인스턴스 시작이 실패할 수 있습니다. 특히 Karpenter 또는 Cluster Autoscaler와 같은 노드 관리 도구를 사용하는 경우 적절한 기능을 위해 슬래시가 포함된 태그에 의존하기 때문입니다. 일반 Kubernetes 관점에서 노드에 대한 자세한 내용은 Kubernetes 문서의 [노드](https://kubernetes.io/docs/concepts/architecture/nodes/)를 참조하세요. **Topics** + [자체 관리형 Amazon Linux 노드 생성](launch-workers.md) + [자체 관리형 Bottlerocket 노드 생성](launch-node-bottlerocket.md) + [자체 관리형 Microsoft Windows 노드 생성](launch-windows-workers.md) + [자체 관리형 Ubuntu Linux 노드 생성](launch-node-ubuntu.md) + [클러스터의 자체 관리형 노드 업데이트](update-workers.md) # 자체 관리형 Amazon Linux 노드 생성 이 주제에서는 Amazon EKS 클러스터에 등록하는 Linux 노드의 Auto Scaling 그룹을 시작하는 방법을 설명합니다. 노드가 클러스터에 조인한 이후 Kubernetes 애플리케이션을 배포할 수 있습니다. `eksctl` 또는 AWS Management Console을 사용하여 자체 관리형 Amazon Linux 노드를 시작할 수도 있습니다. AWS Outposts에서 노드를 시작해야 하는 경우 [AWS Outposts에 Amazon Linux 노드 생성](eks-outposts-self-managed-nodes.md) 부분을 참조하세요. + 기존 Amazon EKS 클러스터. 배포하려면 [Amazon EKS 클러스터 생성](create-cluster.md) 섹션을 참조하세요. AWS Outposts, AWS Wavelength 또는 AWS Local Zones이 사용된 AWS 리전에 서브넷이 있는 경우 클러스터를 생성할 때 해당 서브넷이 전달되지 않은 상태여야 합니다. + 노드가 사용할 기존 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에 대한 추가 전제 조건이 있을 수 있습니다. 다음 중 하나를 사용하여 자체 관리형 Linux 노드를 시작할 수 있습니다. + [`eksctl`](#eksctl_create_managed_amazon_linux) + [AWS Management Console](#console_create_managed_amazon_linux) ## `eksctl` **`eksctl`을 사용하여 자체 관리형 Linux 노드 시작 ** 1. 장치에 설치된 `eksctl` 명령줄 도구의 버전 `0.215.0` 이상 또는 AWS CloudShell이 필요합니다. `eksctl`을 설치 또는 업그레이드하려면 `eksctl` 설명서에서 [설치](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. 다음 명령은 기존 클러스터의 노드 그룹을 생성합니다. *al-nodes*를 노드 그룹의 이름으로 바꿉니다. 노드 그룹 이름은 63자를 초과할 수 없습니다. 문자나 숫자로 시작하되, 나머지 문자의 경우 하이픈과 밑줄을 포함할 수 있습니다. *my-cluster*를 해당 클러스터의 이름으로 바꿉니다. 이름에는 영숫자(대소문자 구분)와 하이픈만 사용할 수 있습니다. 영숫자로 시작해야 하며 100자 이하여야 합니다. 이름은 클러스터를 생성하는 AWS 리전과 AWS 계정 내에서 고유해야 합니다. 나머지 *예제 값*을 자신의 값으로 바꿉니다. 노드는 기본적으로 제어 영역과 동일한 Kubernetes 버전으로 작성됩니다. `--node-type`에 대한 값을 선택하기 전에 [최적의 Amazon EC2 노드 인스턴스 유형 선택](choosing-instance-type.md)을 검토합니다. *my-key*를 Amazon EC2 키 페어 또는 퍼블릭 키 이름으로 바꿉니다. 이 키는 노드를 시작한 후 SSH로 연결하는 데 사용됩니다. Amazon EC2 키 페어가 아직 없는 경우 AWS Management Console에서 새로 생성할 수 있습니다. 자세한 내용을 알아보려면 *Amazon EC2 key pairs*의 [Amazon EC2 키 페어](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ec2-key-pairs.html)를 참조하세요. 다음 명령을 사용하여 노드 그룹을 생성합니다. **중요** 노드 그룹을 AWS Outposts, Wavelength 또는 Local Zones 서브넷에 배포하려는 경우 추가 고려 사항이 있습니다. 클러스터를 생성할 때 서브넷이 전달되지 않았어야 합니다. 서브넷과 ` [volumeType](https://eksctl.io/usage/schema/#nodeGroups-volumeType): gp2`을 지정하는 구성 파일로 노드 그룹을 생성해야 합니다. 자세한 내용은 `eksctl` 문서의 [구성 파일을 사용하여 nodegroup 생성](https://eksctl.io/usage/nodegroups/#creating-a-nodegroup-from-a-config-file) 및 [구성 파일 스키마](https://eksctl.io/usage/schema/) 부분을 참조하세요. ``` eksctl create nodegroup \ --cluster my-cluster \ --name al-nodes \ --node-type t3.medium \ --nodes 3 \ --nodes-min 1 \ --nodes-max 4 \ --ssh-access \ --managed=false \ --ssh-public-key my-key ``` 다음과 같은 노드 그룹을 배포할 수 있습니다. + 포드에 기본 구성보다 훨씬 더 많은 수의 IP 주소를 할당할 수 있는 노드 그룹을 배포하려면 [접두사를 사용하여 Amazon EKS 노드에 추가 IP 주소 할당](cni-increase-ip-addresses.md) 섹션을 참조하세요. + 인스턴스와 다른 CIDR 블록의 포드에 `IPv4` 주소를 할당할 수 있는 노드 그룹을 배포하려면 [사용자 지정 네트워킹을 통해 대체 서브넷에 포드 배포](cni-custom-network.md) 섹션을 참조하세요. + 포드 및 서비스에 `IPv6` 주소를 할당할 수 있는 노드 그룹을 배포하려면 [클러스터, 포드 및 서비스에 대한 IPv6 주소에 대해 알아보기](cni-ipv6.md) 섹션을 참조하세요. + 아웃바운드 인터넷 액세스가 없는 노드 그룹을 배포하려면 [인터넷 액세스가 제한된 프라이빗 클러스터 배포](private-clusters.md) 부분을 참조하세요. 사용 가능한 모든 옵션 및 기본값의 전체 목록을 보려면 다음 명령을 입력합니다. ``` eksctl create nodegroup --help ``` 노드가 클러스터에 조인하지 못한 경우 문제 해결 장의 [노드가 클러스터 조인에 실패](troubleshooting.md#worker-node-fail) 섹션을 참조하세요. 예제 출력은 다음과 같습니다. 노드가 생성되는 동안 여러 줄이 출력됩니다. 출력의 마지막 줄 중 하나는 다음 예제 줄과 유사합니다. ``` [✔] created 1 nodegroup(s) in cluster "my-cluster" ``` 1. (선택 사항) [샘플 애플리케이션](sample-deployment.md)을 배포하여 클러스터 및 Linux 노드를 테스트합니다. 1. 다음과 같은 조건에 해당하면 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) 부분을 참조하세요. ## AWS Management Console **1단계: AWS Management Console을 사용하여 자체 관리형 Linux 노드 시작 ** 1. AWS CloudFormation 템플릿의 최신 버전 다운로드 ``` curl -O https://s3.us-west-2.amazonaws.com/amazon-eks/cloudformation/2025-11-26/amazon-eks-nodegroup.yaml ``` 1. 클러스터 상태가 `ACTIVE`가 되기를 기다립니다. 클러스터가 활성화되기 전에 노드를 시작하면 노드가 클러스터에 등록되지 않고 노드를 다시 시작해야 합니다. 1. [AWSCloudFormation 콘솔](https://console.aws.amazon.com/cloudformation/)을 엽니다. 1. **스택 생성**을 선택한 다음 **새 리소스 사용(표준)**을 선택합니다. 1. **템플릿 지정**에서 **템플릿 파일 업로드**를 선택한 다음 **파일 선택**을 선택합니다. 1. 다운로드한 `amazon-eks-nodegroup.yaml` 파일을 선택합니다. 1. **다음**을 선택합니다. 1. **스택 세부 정보 지정** 페이지에서 이에 따라 다음 파라미터를 입력한 후 **다음**을 선택합니다. + **스택 이름**: AWS CloudFormation 스택에 대한 스택 이름을 선택합니다. 예를 들어, *my-cluster-nodes*로 지정할 수 있습니다. 이름에는 영숫자(대소문자 구분)와 하이픈만 사용할 수 있습니다. 영숫자로 시작해야 하며 100자 이하여야 합니다. 이름은 클러스터를 생성하는 AWS 리전과 AWS 계정 내에서 고유해야 합니다. + **ClusterName**: Amazon EKS 클러스터 생성 시 사용할 이름을 입력합니다. 이 이름은 클러스터 이름과 같아야 합니다. 그렇지 않으면 노드가 클러스터에 조인할 수 없습니다. + **ClusterControlPlaneSecurityGroup**: [VPC](creating-a-vpc.md)를 생성할 때 생성한 AWS CloudFormation 출력에서 **SecurityGroups**값을 선택합니다. 다음 단계에서는 해당 그룹을 검색하는 한 가지 작업을 보여줍니다. 1. [Amazon EKS 콘솔](https://console.aws.amazon.com/eks/home#/clusters)을 엽니다. 1. 클러스터의 이름을 선택합니다. 1. **네트워킹** 탭을 선택합니다. 1. **ClusterControlPlaneSecurityGroup** 드롭다운 목록에서 선택할 때 **추가 보안 그룹** 값을 참조로 사용하세요. + **ApiServerEndpoint**: EKS 클러스터의 API 서버 엔드포인트를 입력합니다. 이는 EKS 클러스터 콘솔의 세부 정보에서 확인할 수 있습니다. + **CertificateAuthorityData**: base64로 인코딩된 인증 기관 데이터를 입력합니다. 이는 EKS 클러스터 콘솔의 세부 정보 섹션에서도 확인할 수 있습니다. + **ServiceCidr**: 클러스터 내 Kubernetes 서비스에 IP 주소를 할당하는 데 사용되는 CIDR 범위를 입력합니다. 이는 EKS 클러스터 콘솔의 네트워킹 탭에 있습니다. + **AuthenticationMode**: EKS 클러스터 콘솔의 액세스 탭을 검토하여 EKS 클러스터에서 사용 중인 인증 모드를 선택합니다. + **NodeGroupName**: 노드 그룹의 이름을 입력합니다. 이 이름은 나중에 노드에 대해 생성된 Auto Scaling 노드 그룹을 식별하는 데 사용할 수 있습니다. 노드 그룹 이름은 63자를 초과할 수 없습니다. 문자나 숫자로 시작하되, 나머지 문자의 경우 하이픈과 밑줄을 포함할 수 있습니다. + **NodeAutoScalingGroupMinSize**: Auto Scaling 그룹이 축소할 수 있는 노드의 최소 노드 수를 입력합니다. + **NodeAutoScalingGroupDesiredCapacity**: 스택을 생성할 때 조정할 원하는 노드 수를 입력합니다. + **NodeAutoScalingGroupMaxSize**: Auto Scaling 그룹이 확장할 수 있는 노드의 최대 노드 수를 입력합니다. + **NodeInstanceType**: 노드에 대한 인스턴스 유형을 선택합니다. 자세한 내용은 [최적의 Amazon EC2 노드 인스턴스 유형 선택](choosing-instance-type.md) 섹션을 참조하세요. + **NodeImageIdSSMParam**: 가변 Kubernetes 버전에 대한 최신 Amazon EKS 최적화 Amazon Linux 2023 AMI의 Amazon EC2 Systems Manager 파라미터로 미리 채워집니다. Amazon EKS에서 지원되는 다른 Kubernetes 마이너 버전을 사용하려면 *1.XX*를 다른 [지원되는 버전](https://docs.aws.amazon.com/eks/latest/userguide/kubernetes-versions.html)으로 바꿉니다. 클러스터와 동일한 Kubernetes 버전을 지정하는 것이 좋습니다. *amazon-linux-2023*를 다른 AMI 유형으로 바꿀 수도 있습니다. 자세한 내용은 [권장 Amazon Linux AMI ID 검색](retrieve-ami-id.md) 섹션을 참조하세요. **참고** Amazon EKS 노드 AMI는 Amazon Linux를 기반으로 합니다. [Amazon Linux 보안 센터](https://alas.aws.amazon.com/alas2023.html)에서 Amazon Linux 2023의 보안 또는 프라이버시 이벤트를 추적하거나 관련 [RSS 피드](https://alas.aws.amazon.com/AL2023/alas.rss)를 구독하세요. 보안 및 프라이버시 이벤트에는 문제의 개요, 영향을 받는 패키지 및 인스턴스를 업데이트하여 문제를 해결하는 방법이 포함됩니다. + **NodeImageId**: (선택사항) Amazon EKS 최적화 AMI 대신 사용자 정의 AMI를 사용 중인 경우, 해당 AWS 리전에 노드 AMI ID를 입력합니다. 여기에서 값을 지정하면 **NodeImageIdSSMParam** 필드에 있는 모든 값이 재정의됩니다. + **NodeVolumeSize**: 노드에 대해 루트 볼륨 크기를 GiB 단위로 지정합니다. + **NodeVolumeType**: 노드의 루트 볼륨 유형을 지정합니다. + **KeyName**: 시작 이후 SSH를 사용하여 노드에 연결하는 데 사용할 수 있는 Amazon EC2 SSH 키 페어 이름을 입력합니다. Amazon EC2 키 페어가 아직 없는 경우 AWS Management Console에서 새로 생성할 수 있습니다. 자세한 내용을 알아보려면 *Amazon EC2 key pairs*의 [Amazon EC2 키 페어](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ec2-key-pairs.html)를 참조하세요. + **VpcId**: 생성한 [VPC](creating-a-vpc.md)에 대한 ID를 입력합니다. + **서브넷**: VPC용으로 생성한 서브넷을 선택합니다. [Amazon EKS 클러스터를 위한 Amazon VPC 만들기](creating-a-vpc.md)에 설명된 단계를 사용하여 VPC를 만든 경우, 노드가 시작될 VPC 내의 사설 서브넷만 지정하세요. 클러스터의 **Networking**에서 각 서브넷 링크를 열면 어떤 서브넷이 프라이빗인지 확인할 수 있습니다. **중요** 서브넷 중 하나가 퍼블릭 서브넷인 경우 자동 퍼블릭 IP 주소 할당 설정을 사용하도록 설정해야 합니다. 퍼블릭 서브넷에 대해 이 설정을 사용하지 않으면 해당 퍼블릭 서브넷에 배포하는 노드에는 퍼블릭 IP 주소가 할당되지 않으며 클러스터 또는 기타 AWS 서비스와 통신할 수 없습니다. 서브넷이 2020년 3월 26일 이전에 [Amazon EKS AWS CloudFormation VPC 템플릿](creating-a-vpc.md) 또는 `eksctl`을 사용하여 배포된 경우 퍼블릭 서브넷에 대해 자동 퍼블릭 IP 주소 할당이 사용 중지됩니다. 서브넷에 퍼블릭 IP 주소 할당을 활성화하는 방법에 대한 자세한 내용은 [서브넷에 대한 퍼블릭 IPv4 주소 지정 속성 수정](https://docs.aws.amazon.com/vpc/latest/userguide/vpc-ip-addressing.html#subnet-public-ip)을 참조하세요. 노드가 프라이빗 서브넷에 배포되면 NAT 게이트웨이를 통해 클러스터 및 다른 AWS 서비스와 통신할 수 있습니다. 서브넷에서 인터넷에 액세스할 수 없는 경우 [인터넷 액세스가 제한된 비공개 클러스터 배포하기](private-clusters.md)의 고려 사항과 추가 단계를 숙지하고 있는지 확인하세요. AWS Outposts, Wavelength 또는 Local Zones 서브넷을 선택하는 경우 클러스터를 생성할 때 해당 서브넷이 전달되지 않은 상태여야 합니다. 1. **스택 옵션 구성** 페이지에서 원하는 선택 항목을 선택한 후 **다음**을 선택합니다. 1. **AWS CloudFormation에서 IAM 리소스를 생성할 수 있음을 인정합니다**의 왼쪽에 있는 확인란을 선택한 다음 **스택 생성**을 선택합니다. 1. 스택이 생성된 후 콘솔에서 이를 선택하고 **출력**을 선택합니다. `EKS API` 또는 `EKS API and ConfigMap` 인증 모드를 사용하는 경우 마지막 단계입니다. 1. `ConfigMap` 인증 모드를 사용하는 경우 생성된 노드 그룹의 **NodeInstanceRole**을 기록하세요. **2단계: 노드가 클러스터에 조인하도록 하려면** **참고** 다음 두 단계는 EKS 클러스터 내에서 Configmap 인증 모드를 사용하는 경우에만 필요합니다. 또한 아웃바운드 인터넷 액세스 없이 프라이빗 VPC 내에서 노드를 시작한 경우 VPC 내에서 노드가 클러스터에 조인하도록 설정해야 합니다. 1. `aws-auth` `ConfigMap`이 이미 있는지 확인합니다. ``` kubectl describe configmap -n kube-system aws-auth ``` 1. `aws-auth` `ConfigMap`이 표시되면 필요에 따라 이를 업데이트합니다. 1. 편집을 위해 `ConfigMap`을 엽니다. ``` kubectl edit -n kube-system configmap/aws-auth ``` 1. 필요에 따라 새 `mapRoles` 항목을 추가합니다. `rolearn` 값을 이전 절차에서 기록한 **NodeInstanceRole** 값으로 설정합니다. ``` [...] data: mapRoles: | - rolearn: username: system:node:{{EC2PrivateDNSName}} groups: - system:bootstrappers - system:nodes [...] ``` 1. 파일을 저장하고 텍스트 편집기를 종료합니다. 1. "`Error from server (NotFound): configmaps "aws-auth" not found`라는 오류 메시지가 표시되면 스톡 `ConfigMap`을 적용합니다. 1. 구성 맵을 다운로드합니다. ``` curl -O https://s3.us-west-2.amazonaws.com/amazon-eks/cloudformation/2020-10-29/aws-auth-cm.yaml ``` 1. `aws-auth-cm.yaml` 파일에서 `rolearn` 값을 이전 절차에서 기록한 **NodeInstanceRole** 값으로 설정합니다. 이 작업은 텍스트 편집기를 사용하거나 *my-node-instance-role*을 대체하고 다음 명령을 실행하여 수행할 수 있습니다. ``` sed -i.bak -e 's||my-node-instance-role|' aws-auth-cm.yaml ``` 1. 구성을 적용합니다. 이 명령을 완료하는 데 몇 분이 걸릴 수 있습니다. ``` kubectl apply -f aws-auth-cm.yaml ``` 1. 노드의 상태를 확인하고 `Ready` 상태가 될 때까지 대기합니다. ``` kubectl get nodes --watch ``` `Ctrl`\$1`C`를 입력하여 쉘 프롬프트로 돌아갑니다. **참고** 권한 부여 또는 리소스 유형 오류가 표시되는 경우 문제 해결 주제의 [권한이 없거나 액세스가 거부됨(`kubectl`)](troubleshooting.md#unauthorized) 부분을 참조하세요. 노드가 클러스터에 조인하지 못한 경우 문제 해결 장의 [노드가 클러스터 조인에 실패](troubleshooting.md#worker-node-fail) 섹션을 참조하세요. 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 ``` **3단계: 추가 작업** 1. (선택 사항) [샘플 애플리케이션](sample-deployment.md)을 배포하여 클러스터 및 Linux 노드를 테스트합니다. 1. (선택 사항) **AmazonEKS\$1CNI\$1Policy** 관리형 IAM 정책(`IPv4` 클러스터를 사용하는 경우) 또는 *AmazonEKS\$1CNI\$1IPv6\$1Policy*(`IPv6` 클러스터를 사용하는 경우 [직접 생성한 항목](cni-iam-role.md#cni-iam-role-create-ipv6-policy))가 [Amazon EKS 노드 IAM 역할](create-node-role.md)에 연결되어 있는 경우 대신 Kubernetes `aws-node` 서비스 계정에 연결하는 IAM 역할에 할당하는 것이 좋습니다. 자세한 내용은 [IRSA를 사용하도록 Amazon VPC CNI 플러그인 구성](cni-iam-role.md) 섹션을 참조하세요. 1. 다음과 같은 조건에 해당하면 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) 섹션을 참조하세요. # 자체 관리형 Bottlerocket 노드 생성 **참고** 관리형 노드 그룹은 사용 사례에 대한 몇 가지 이점을 제공할 수 있습니다. 자세한 내용은 [관리형 노드 그룹을 사용한 노드 수명 주기 간소화](managed-node-groups.md) 섹션을 참조하세요. 이 주제에서는 Amazon EKS 클러스터에 등록하는 [Bottlerocket](https://aws.amazon.com/bottlerocket/) 노드의 Auto Scaling 그룹을 시작하는 방법을 설명합니다. Bottlerocket은 가상 머신 또는 베어메탈 호스트에서 컨테이너를 실행하는 데 사용할 수 있는 AWS의 Linux 기반 오픈 소스 운영 체제입니다. 노드가 클러스터에 조인한 이후 Kubernetes 애플리케이션을 배포할 수 있습니다. Bottlerocket에 대한 자세한 내용은 GitHub의 [Using a Bottlerocket AMI with Amazon EKS](https://github.com/bottlerocket-os/bottlerocket/blob/develop/QUICKSTART-EKS.md)와 `eksctl` 설명서의 [사용자 정의 AMI 지원](https://eksctl.io/usage/custom-ami-support/)을 참조하세요. 현재 위치 업그레이드에 대한 자세한 내용은 GitHub의 [Bottlerocket Update Operator](https://github.com/bottlerocket-os/bottlerocket-update-operator)를 참조하세요. **중요** Amazon EKS 노드는 표준 Amazon EC2 인스턴스이고, 일반 Amazon EC2 인스턴스 가격을 기반으로 비용이 청구됩니다. 자세한 설명은 [Amazon EC2 요금](https://aws.amazon.com/ec2/pricing/)을 참조하세요. Bottlerocket 노드를 AWS Outposts의 Amazon EKS 확장 클러스터에서 시작할 수 있지만 AWS Outposts의 로컬 클러스터에서는 시작할 수 없습니다. 자세한 내용은 [AWS Outposts를 사용한 Amazon EKS 온프레미스 배포](eks-outposts.md) 섹션을 참조하세요. `x86` 또는 Arm프로세서가 있는 Amazon EC2 인스턴스에 배포할 수 있습니다. 그러나 Inferentia 칩이 있는 인스턴스에는 배포할 수 없습니다. Bottlerocket은 AWS CloudFormation과 호환됩니다. 그러나 Amazon EKS용 Bottlerocket 노드를 배포하기 위해 복사할 수 있는 공식 CloudFormation 템플릿은 없습니다. Bottlerocket 이미지는 SSH 서버나 쉘과 함께 제공되지 않습니다. 대역 외 액세스 방법을 사용하여 SSH가 관리 컨테이너를 사용 설정하고 사용자 데이터와 함께 일부 부트스트래핑 구성 단계를 전달하도록 할 수 있습니다. 자세한 내용은 GitHub의 [bottlerocket Readme.md](https://github.com/bottlerocket-os/bottlerocket)에 있는 관련 섹션을 참조하세요. [탐색](https://github.com/bottlerocket-os/bottlerocket#exploration) [관리자 컨테이너](https://github.com/bottlerocket-os/bottlerocket#admin-container) [Kubernetes 설정](https://github.com/bottlerocket-os/bottlerocket#kubernetes-settings) 이 절차에는 `eksctl` 버전 `0.215.0` 이상이 필요합니다. 버전은 다음 명령을 통해 확인할 수 있습니다. ``` eksctl version ``` `eksctl`을 설치하거나 업그레이드하는 방법에 대한 지침은 `eksctl` 문서의 [설치](https://eksctl.io/installation)를 참조하세요.참고: 이 절차는 `eksctl`로 생성한 클러스터에서만 작동합니다. 1. 다음 콘텐츠를 디바이스에 복사합니다. *my-cluster*를 해당 클러스터의 이름으로 바꿉니다. 이름에는 영숫자(대소문자 구분)와 하이픈만 사용할 수 있습니다. 영숫자로 시작해야 하며 100자 이하여야 합니다. 이름은 클러스터를 생성하는 AWS 리전과 AWS 계정 내에서 고유해야 합니다. *no-bottlerocket*을 노드 그룹의 이름으로 바꿉니다. 노드 그룹 이름은 63자를 초과할 수 없습니다. 문자나 숫자로 시작하되, 나머지 문자의 경우 하이픈과 밑줄을 포함할 수 있습니다. Arm 인스턴스에 배포하려면 *m5.large*을 Arm 인스턴스 유형으로 바꿉니다. *my-ec2-keypair-name*을 시작 이후 SSH를 사용하여 노드에 연결하는 데 사용할 수 있는 Amazon EC2 SSH 키 페어 이름으로 변경합니다. Amazon EC2 키 페어가 아직 없는 경우 AWS Management Console에서 새로 생성할 수 있습니다. 자세한 내용을 알아보려면 *Amazon EC2 key pairs*의 [Amazon EC2 키 페어](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ec2-key-pairs.html)를 참조하세요. 나머지 예제 값을 자신의 값으로 바꿉니다. 다 바꾼 후 수정된 명령을 실행하여 `bottlerocket.yaml` 파일을 생성합니다. Arm Amazon EC2 인스턴스 유형을 지정하는 경우 배포하기 전에 [Amazon EKS 최적화 Arm Amazon Linux AMI](eks-optimized-ami.md#arm-ami)의 고려 사항을 검토하세요. 사용자 정의 AMI를 사용하여 배포하는 방법에 대한 지침은 GitHub의 [Building Bottlerocket](https://github.com/bottlerocket-os/bottlerocket/blob/develop/BUILDING.md)과 `eksctl` 문서의 [사용자 정의 AMI 지원](https://eksctl.io/usage/custom-ami-support/)을 참조하세요. 관리형 노드 그룹을 배포하려면 시작 템플릿을 사용하여 사용자 정의 AMI를 배포합니다. 자세한 내용은 [시작 템플릿을 사용한 관리형 노드 사용자 지정](launch-templates.md) 섹션을 참조하세요. **중요** 노드 그룹을 AWS Outposts, AWS Wavelength 또는 AWS Local Zones 서브넷에 배포하려면 클러스터를 생성할 때 AWS Outposts, AWS Wavelength 또는 AWS 로컬 영역 서브넷을 전달하지 마세요. 다음 예에서는 서브넷을 지정해야 합니다. 자세한 내용은 `eksctl` 문서에서 [구성 파일을 사용하여 nodegroup 생성](https://eksctl.io/usage/nodegroups/#creating-a-nodegroup-from-a-config-file) 및 [구성 파일 스키마](https://eksctl.io/usage/schema/) 부분을 참조하세요. *region-code*를 클러스터가 있는 AWS 리전으로 바꿉니다. ``` cat >bottlerocket.yaml < 이 주제에서는 Amazon EKS 클러스터에 등록하는 Windows 노드의 오토 스케일링 그룹을 시작하는 방법을 설명합니다. 노드가 클러스터에 조인한 이후 Kubernetes 애플리케이션을 배포할 수 있습니다. **중요** Amazon EKS 노드는 표준 Amazon EC2 인스턴스이고, 일반 Amazon EC2 인스턴스 가격을 기반으로 비용이 청구됩니다. 자세한 설명은 [Amazon EC2 요금](https://aws.amazon.com/ec2/pricing/)을 참조하세요. Windows 노드를 AWS Outposts의 Amazon EKS 확장 클러스터에서 시작할 수 있지만 AWS Outposts의 로컬 클러스터에서는 시작할 수 없습니다. 자세한 내용은 [AWS Outposts를 사용한 Amazon EKS 온프레미스 배포](eks-outposts.md) 섹션을 참조하세요. 클러스터에 Windows 지원 사용 Windows 노드 그룹을 시작하기 전에 중요한 고려 사항을 검토하는 것이 좋습니다. 자세한 내용은 [Windows 지원 사용](windows-support.md#enable-windows-support) 섹션을 참조하세요. 다음 중 하나를 사용하여 자체 관리형 Windows 노드를 시작할 수 있습니다. + [`eksctl`](#eksctl_create_windows_nodes) + [AWS Management Console](#console_create_windows_nodes) ## `eksctl` **`eksctl`을 사용하여 자체 관리형 Windows 노드 시작 ** 이 절차에서는 `eksctl`을 설치하고 `eksctl` 버전 `0.215.0` 이상을 요구합니다. 버전은 다음 명령을 통해 확인할 수 있습니다. ``` eksctl version ``` `eksctl` 설치 또는 업데이트에 대한 지침은 `eksctl` 설명서에서 [설치](https://eksctl.io/installation)를 참조하세요. **참고** 이 방법은 `eksctl`로 생성된 클러스터에만 사용할 수 있습니다. 1. (선택 사항) **AmazonEKS\$1CNI\$1Policy** 관리형 IAM 정책(`IPv4` 클러스터를 사용하는 경우) 또는 *AmazonEKS\$1CNI\$1IPv6\$1Policy*(`IPv6` 클러스터를 사용하는 경우 [직접 만든 것](cni-iam-role.md#cni-iam-role-create-ipv6-policy))이 [Amazon EKS 노드 IAM 역할](create-node-role.md)에 연결되어 있는 경우 대신 Kubernetes `aws-node` 서비스 계정에 연결하는 IAM 역할에 할당하는 것을 권장합니다. 자세한 내용은 [IRSA를 사용하도록 Amazon VPC CNI 플러그인 구성](cni-iam-role.md) 섹션을 참조하세요. 1. 이 절차에서는 기존 클러스터가 있다고 가정합니다. Windows 노드 그룹을 추가할 Amazon EKS 클러스터 및 Amazon Linux 노드 그룹이 아직 없는 경우에는 [Amazon EKS 시작하기 – `eksctl`](getting-started-eksctl.md) 가이드를 따르는 것이 좋습니다. 이 설명서에서는 Amazon Linux 노드로 Amazon EKS 클러스터를 생성하는 방법에 대한 전체 시연을 제공합니다. 다음 명령을 사용하여 노드 그룹을 생성합니다. *region-code*를 클러스터가 있는 AWS 리전으로 바꿉니다. **을 클러스터 이름으로 바꿉니다. 이름에는 영숫자(대소문자 구분)와 하이픈만 사용할 수 있습니다. 영숫자로 시작해야 하며 100자 이하여야 합니다. 이름은 클러스터를 생성하는 AWS 리전과 AWS 계정 내에서 고유해야 합니다. *ng-windows*을 노드 그룹의 이름으로 바꿉니다. 노드 그룹 이름은 63자를 초과할 수 없습니다. 문자나 숫자로 시작하되, 나머지 문자의 경우 하이픈과 밑줄을 포함할 수 있습니다. Windows Server 2022를 사용하기 위해 *2019*를 `2022`로 대체하거나 Windows Server 2025를 사용하기 위해 `2025`로 대체할 수 있습니다. 나머지 예제 값을 자신의 값으로 대체합니다. **중요** 노드 그룹을 AWS Outposts, AWS Wavelength 또는 AWS Local Zones 서브넷에 배포하려면 클러스터를 생성할 때 AWS Outposts, Wavelength 또는 로컬 영역 서브넷을 전달하지 마세요. 구성 파일을 사용하여 노드 그룹을 생성합니다. 이때 AWS Outposts, Wavelength 또는 Local Zones 서브넷을 지정합니다. 자세한 내용은 `eksctl` 문서의 [구성 파일을 사용하여 nodegroup 생성](https://eksctl.io/usage/nodegroups/#creating-a-nodegroup-from-a-config-file) 및 [구성 파일 스키마](https://eksctl.io/usage/schema/) 섹션을 참조하세요. ``` eksctl create nodegroup \ --region region-code \ --cluster my-cluster \ --name ng-windows \ --node-type t2.large \ --nodes 3 \ --nodes-min 1 \ --nodes-max 4 \ --managed=false \ --node-ami-family WindowsServer2019FullContainer ``` **참고** 노드가 클러스터에 조인하지 못한 경우 문제 해결 안내서의 [노드가 클러스터 조인에 실패](troubleshooting.md#worker-node-fail) 부분을 참조하세요. `eksctl` 명령에 사용 가능한 옵션을 보려면 다음 명령을 입력합니다. ``` eksctl command -help ``` 예제 출력은 다음과 같습니다. 노드가 생성되는 동안 여러 줄이 출력됩니다. 출력의 마지막 줄 중 하나는 다음 예제 줄과 유사합니다. ``` [✔] created 1 nodegroup(s) in cluster "my-cluster" ``` 1. (선택 사항) [샘플 애플리케이션](sample-deployment.md)을 배포하여 클러스터 및 Windows 노드를 테스트합니다. 1. 다음과 같은 조건에 해당하면 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) 섹션을 참조하세요. ## AWS Management Console **사전 조건** + 기존 Amazon EKS 클러스터 및 Linux 노드 그룹. 이러한 리소스가 없는 경우 [Amazon EKS 시작하기](getting-started.md)의 가이드 중 하나를 사용하여 생성하는 것이 좋습니다. 이러한 가이드에서는 Linux 노드로 Amazon EKS 클러스터를 생성하는 방법에 대해 설명합니다. + Amazon EKS 클러스터의 요구 사항을 충족하는 기존 VPC 및 전용 보안 그룹. 자세한 내용은 [VPC 및 서브넷에 대한 Amazon EKS 네트워킹 요구 사항 보기](network-reqs.md) 및 [클러스터에 대한 Amazon EKS 보안 그룹 요구 사항 보기](sec-group-reqs.md) 섹션을 참조하세요. [Amazon EKS 시작하기](getting-started.md)의 가이드에 따라 요구 사항을 충족하는 VPC를 만듭니다. 또는 [Amazon EKS 클러스터에 대한 Amazon VPC 생성](creating-a-vpc.md)을 따라 수동으로 생성할 수도 있습니다. + Amazon EKS 클러스터의 요구 사항을 충족하는 VPC 및 보안 그룹을 사용하는 기존 Amazon EKS 클러스터. 자세한 내용은 [Amazon EKS 클러스터 생성](create-cluster.md) 섹션을 참조하세요. AWS Outposts, AWS Wavelength 또는 AWS Local Zones이 사용된 AWS 리전에 서브넷이 있는 경우 클러스터를 생성할 때 해당 서브넷이 전달되지 않은 상태여야 합니다. **1단계: AWS Management Console을 사용하여 자체 관리형 Windows 노드를 시작하려면** 1. 클러스터 상태가 `ACTIVE`가 되기를 기다립니다. 클러스터가 활성화되기 전에 노드를 시작하면 노드가 클러스터에 등록되지 않고 노드를 다시 시작해야 합니다. 1. [AWS CloudFormation 콘솔](https://console.aws.amazon.com/cloudformation/) 열기 1. **스택 생성**을 선택합니다. 1. **템플릿 지정**에서 **Amazon S3 URL**을 선택합니다. 1. 다음과 같은 URL을 복사하여 **Amazon S3 URL**에 붙여 넣습니다. ``` https://s3.us-west-2.amazonaws.com/amazon-eks/cloudformation/2023-02-09/amazon-eks-windows-nodegroup.yaml ``` 1. **다음**을 두 번 선택합니다 1. **빠른 스택 생성** 페이지에서 다음 파라미터를 적절하게 입력합니다. + **스택 이름**: AWS CloudFormation 스택에 대한 스택 이름을 선택합니다. 예를 들어 `my-cluster-nodes`라고 할 수 있습니다. + **ClusterName**: Amazon EKS 클러스터 생성 시 사용할 이름을 입력합니다. **중요** 이 이름은 [1단계: Amazon EKS 클러스터 생성](getting-started-console.md#eks-create-cluster)에서 사용한 이름과 정확히 일치해야 합니다. 그렇지 않으면 노드가 클러스터에 가입할 수 없습니다. + **ClusterControlPlaneSecurityGroup**: [VPC](creating-a-vpc.md)를 만들 때 생성한 AWS CloudFormation 출력에서 보안 그룹을 선택합니다. 다음 단계에서는 해당 그룹을 검색하는 한 가지 방법을 보여줍니다. 1. [Amazon EKS 콘솔](https://console.aws.amazon.com/eks/home#/clusters)을 엽니다. 1. 클러스터의 이름을 선택합니다. 1. **네트워킹** 탭을 선택합니다. 1. **ClusterControlPlaneSecurityGroup** 드롭다운 목록에서 선택할 때 **추가 보안 그룹** 값을 참조로 사용하세요. + **NodeGroupName**: 노드 그룹의 이름을 입력합니다. 이 이름은 나중에 노드에 대해 생성된 Auto Scaling 노드 그룹을 식별하는 데 사용할 수 있습니다. 노드 그룹 이름은 63자를 초과할 수 없습니다. 문자나 숫자로 시작하되, 나머지 문자의 경우 하이픈과 밑줄을 포함할 수 있습니다. + **NodeAutoScalingGroupMinSize**: Auto Scaling 그룹이 축소할 수 있는 노드의 최소 노드 수를 입력합니다. + **NodeAutoScalingGroupDesiredCapacity**: 스택을 생성할 때 조정할 원하는 노드 수를 입력합니다. + **NodeAutoScalingGroupMaxSize**: Auto Scaling 그룹이 확장할 수 있는 노드의 최대 노드 수를 입력합니다. + **NodeInstanceType**: 노드에 대한 인스턴스 유형을 선택합니다. 자세한 내용은 [최적의 Amazon EC2 노드 인스턴스 유형 선택](choosing-instance-type.md) 섹션을 참조하세요. **참고** 최신 버전의 [Kubernetes용 Amazon VPC CNI 플러그 인](https://github.com/aws/amazon-vpc-cni-k8s)에 대해 지원되는 인스턴스 유형은 GitHub의 [vpc\$1ip\$1resource\$1limit.go](https://github.com/aws/amazon-vpc-cni-k8s/blob/master/pkg/vpc/vpc_ip_resource_limit.go)에 나열되어 있습니다. 지원되는 최신 인스턴스 유형을 사용하려면 CNI 버전을 업데이트해야 할 수 있습니다. 자세한 내용은 [Amazon VPC CNI를 통해 포드에 IP 할당](managing-vpc-cni.md) 섹션을 참조하세요. + **NodeImageIdSSMParam**: 현재 권장되는 Amazon EKS 최적화 Windows Core AMI ID의 Amazon EC2 Systems Manager 파라미터로 미리 채워집니다. 전체 버전의 Windows를 사용하려면 *Core*를 `Full`로 바꿉니다. + **NodeImageId**: (선택사항) Amazon EKS 최적화 AMI 대신 사용자 정의 AMI를 사용 중인 경우, 해당 AWS 리전에 노드 AMI ID를 입력합니다. 이 필드의 값을 지정하면 **NodeImageIdSSMParam** 필드에 있는 모든 값이 재정의됩니다. + **NodeVolumeSize**: 노드에 대해 루트 볼륨 크기를 GiB 단위로 지정합니다. + **KeyName**: 시작 이후 SSH를 사용하여 노드에 연결하는 데 사용할 수 있는 Amazon EC2 SSH 키 페어 이름을 입력합니다. Amazon EC2 키 페어가 아직 없는 경우 AWS Management Console에서 새로 생성할 수 있습니다. 자세한 내용을 알아보려면 *Amazon EC2 key pairs*의 [Amazon EC2 키 페어](https://docs.aws.amazon.com/AWSEC2/latest/WindowsGuide/ec2-key-pairs.html)를 참조하세요. **참고** 여기에 키 페어을 제공하지 않으면 AWS CloudFormation 스택이 생성되지 않습니다. + **BootstrapArguments**: `-KubeletExtraArgs`를 사용하여 별도의 `kubelet` 인수와 같이 노드 부트스트랩 스크립트에 전달할 선택적 인수를 지정합니다. + **DisableIMDSv1**: 기본적으로 각 노드는 인스턴스 메타데이터 서비스 버전 1(IMDSv1) 및 IMDSv2를 지원합니다. IMDSv1을 사용 중지할 수 있습니다. 향후 노드 그룹의 노드와 포드가 MDSv1을 사용하지 못하게 하려면 **DisableIMDSv1**을 **true**로 설정합니다. IMDS에 대한 자세한 내용은 [인스턴스 메타데이터 서비스 구성](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/configuring-instance-metadata-service.html)을 참조하세요. + **VpcId**: 생성한 [VPC](creating-a-vpc.md)에 대한 ID를 선택합니다. + **NodeSecurityGroups**: [VPC](creating-a-vpc.md)를 생성할 때 Linux 노드 그룹에 대해 생성된 보안 그룹을 선택합니다. Linux 노드에 둘 이상의 보안 그룹이 연결되어 있는 경우 모든 보안 그룹을 지정합니다. 예를 들어 Linux 노드 그룹이 `eksctl`로 생성된 경우입니다. + **서브넷**: 생성한 서브넷을 선택합니다. [Amazon EKS 클러스터를 위한 Amazon VPC 만들기](creating-a-vpc.md)의 단계를 사용하여 VPC를 만든 경우, 노드가 실행할 VPC 내의 사설 서브넷만 지정합니다. **중요** 서브넷 중 하나가 퍼블릭 서브넷인 경우 자동 퍼블릭 IP 주소 할당 설정을 사용하도록 설정해야 합니다. 퍼블릭 서브넷에 대해 이 설정을 사용하지 않으면 해당 퍼블릭 서브넷에 배포하는 노드에는 퍼블릭 IP 주소가 할당되지 않으며 클러스터 또는 기타 AWS 서비스와 통신할 수 없습니다. 서브넷이 2020년 3월 26일 이전에 [Amazon EKS AWS CloudFormation VPC 템플릿](creating-a-vpc.md) 또는 `eksctl`을 사용하여 배포된 경우 퍼블릭 서브넷에 대해 자동 퍼블릭 IP 주소 할당이 사용 중지됩니다. 서브넷에 퍼블릭 IP 주소 할당을 활성화하는 방법에 대한 자세한 내용은 [서브넷에 대한 퍼블릭 IPv4 주소 지정 속성 수정](https://docs.aws.amazon.com/vpc/latest/userguide/vpc-ip-addressing.html#subnet-public-ip)을 참조하세요. 노드가 프라이빗 서브넷에 배포되면 NAT 게이트웨이를 통해 클러스터 및 다른 AWS 서비스와 통신할 수 있습니다. 서브넷에서 인터넷에 액세스할 수 없는 경우 [인터넷 액세스가 제한된 비공개 클러스터 배포하기](private-clusters.md)의 고려 사항과 추가 단계를 숙지하고 있는지 확인하세요. AWS Outposts, Wavelength 또는 Local Zones 서브넷을 선택하는 경우 클러스터를 생성할 때 해당 서브넷이 전달되지 않은 상태여야 합니다. 1. 스택에서 IAM 리소스를 생성할 수 있는지 확인한 다음 **스택 생성**을 선택합니다. 1. 스택이 생성된 후 콘솔에서 이를 선택하고 **출력**을 선택합니다. 1. 생성된 노드 그룹에 대해 **NodeInstanceRole**을 기록합니다. Amazon EKS Windows 노드를 구성할 때 필요합니다. **2단계: 노드가 클러스터에 조인하도록 하려면** 1. `aws-auth` `ConfigMap`이 이미 있는지 확인합니다. ``` kubectl describe configmap -n kube-system aws-auth ``` 1. `aws-auth` `ConfigMap`이 표시되면 필요에 따라 이를 업데이트합니다. 1. 편집을 위해 `ConfigMap`을 엽니다. ``` kubectl edit -n kube-system configmap/aws-auth ``` 1. 필요에 따라 새 `mapRoles` 항목을 추가합니다. `rolearn` 값을 이전 절차에서 기록한 **NodeInstanceRole** 값으로 설정합니다. ``` [...] data: mapRoles: | - rolearn: username: system:node:{{EC2PrivateDNSName}} groups: - system:bootstrappers - system:nodes - rolearn: username: system:node:{{EC2PrivateDNSName}} groups: - system:bootstrappers - system:nodes - eks:kube-proxy-windows [...] ``` 1. 파일을 저장하고 텍스트 편집기를 종료합니다. 1. "`Error from server (NotFound): configmaps "aws-auth" not found`라는 오류 메시지가 표시되면 스톡 `ConfigMap`을 적용합니다. 1. 구성 맵을 다운로드합니다. ``` curl -O https://s3.us-west-2.amazonaws.com/amazon-eks/cloudformation/2020-10-29/aws-auth-cm-windows.yaml ``` 1. `aws-auth-cm-windows.yaml` 파일에서 `rolearn` 값을 이전 절차에서 기록한 해당 **NodeInstanceRole** 값으로 설정합니다. 이 작업은 텍스트 편집기를 사용하거나 예제 값을 바꾸고 다음 명령을 실행하여 수행할 수 있습니다. ``` sed -i.bak -e 's||my-node-linux-instance-role|' \ -e 's||my-node-windows-instance-role|' aws-auth-cm-windows.yaml ``` **중요** 이 파일에서 어떠한 행도 수정하지 마세요. Windows 및 Linux 노드 모두에 동일한 IAM 역할을 사용하지 마세요. 1. 구성을 적용합니다. 이 명령을 완료하는 데 몇 분이 걸릴 수 있습니다. ``` kubectl apply -f aws-auth-cm-windows.yaml ``` 1. 노드의 상태를 확인하고 `Ready` 상태가 될 때까지 대기합니다. ``` kubectl get nodes --watch ``` `Ctrl`\$1`C`를 입력하여 쉘 프롬프트로 돌아갑니다. **참고** 권한 부여 또는 리소스 유형 오류가 표시되는 경우 문제 해결 주제의 [권한이 없거나 액세스가 거부됨(`kubectl`)](troubleshooting.md#unauthorized) 부분을 참조하세요. 노드가 클러스터에 조인하지 못한 경우 문제 해결 장의 [노드가 클러스터 조인에 실패](troubleshooting.md#worker-node-fail) 섹션을 참조하세요. **3단계: 추가 작업** 1. (선택 사항) [샘플 애플리케이션](sample-deployment.md)을 배포하여 클러스터 및 Windows 노드를 테스트합니다. 1. (선택 사항) **AmazonEKS\$1CNI\$1Policy** 관리형 IAM 정책(`IPv4` 클러스터를 사용하는 경우) 또는 *AmazonEKS\$1CNI\$1IPv6\$1Policy*(`IPv6` 클러스터를 사용하는 경우 [직접 생성한 항목](cni-iam-role.md#cni-iam-role-create-ipv6-policy))가 [Amazon EKS 노드 IAM 역할](create-node-role.md)에 연결되어 있는 경우 대신 Kubernetes `aws-node` 서비스 계정에 연결하는 IAM 역할에 할당하는 것이 좋습니다. 자세한 내용은 [IRSA를 사용하도록 Amazon VPC CNI 플러그인 구성](cni-iam-role.md) 섹션을 참조하세요. 1. 다음과 같은 조건에 해당하면 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) 섹션을 참조하세요. # 자체 관리형 Ubuntu Linux 노드 생성 **참고** 관리형 노드 그룹은 사용 사례에 대한 몇 가지 이점을 제공할 수 있습니다. 자세한 내용은 [관리형 노드 그룹을 사용한 노드 수명 주기 간소화](managed-node-groups.md) 섹션을 참조하세요. 이 주제에서는 Amazon EKS 클러스터에 등록하는 [Amazon Elastic Kubernetes Service(EKS)의 Ubuntu](https://cloud-images.ubuntu.com/aws-eks/) 또는 [Amazon Elastic Kubernetes Service(EKS)의 Ubuntu Pro](https://ubuntu.com/blog/ubuntu-pro-for-eks-is-now-generally-available) 노드의 Auto Scaling 그룹을 시작하는 방법을 설명합니다. Ubuntu 및 Ubuntu Pro for EKS는 공식 Ubuntu Minimal LTS를 기반으로 하며, AWS와 공동으로 개발되고 EKS용으로 특별히 구축된 사용자 지정 AWS 커널을 포함합니다. Ubuntu Pro는 EKS 확장 지원 기간, 커널 라이브패치, FIPS 규정 준수 및 무제한 Pro 컨테이너를 실행할 수 있는 기능을 지원하여 보안 범위를 추가합니다. 노드가 클러스터에 조인한 이후 컨테이너화된 애플리케이션을 배포할 수 있습니다. 자세한 내용은 `eksctl` 설명서의 [AWS 상의 Ubuntu](https://documentation.ubuntu.com/aws/en/latest/) 및 [사용자 지정 AMI 지원](https://eksctl.io/usage/custom-ami-support/)을 참조하세요. **중요** Amazon EKS 노드는 표준 Amazon EC2 인스턴스이고, 일반 Amazon EC2 인스턴스 가격을 기반으로 비용이 청구됩니다. 자세한 설명은 [Amazon EC2 요금](https://aws.amazon.com/ec2/pricing/)을 참조하세요. Ubuntu 노드를 AWSOutposts의 Amazon EKS 확장 클러스터에서 시작할 수 있지만 AWS Outposts의 로컬 클러스터에서는 시작할 수 없습니다. 자세한 내용은 [AWS Outposts를 사용한 Amazon EKS 온프레미스 배포](eks-outposts.md) 섹션을 참조하세요. `x86` 또는 Arm프로세서가 있는 Amazon EC2 인스턴스에 배포할 수 있습니다. 하지만 Inferentia 칩이 있는 인스턴스의 경우 먼저 [Neuron SDK](https://awsdocs-neuron.readthedocs-hosted.com/en/latest/)를 설치해야 할 수 있습니다. 이 절차에는 `eksctl` 버전 `0.215.0` 이상이 필요합니다. 버전은 다음 명령을 통해 확인할 수 있습니다. ``` eksctl version ``` `eksctl`을 설치하거나 업그레이드하는 방법에 대한 지침은 `eksctl` 문서의 [설치](https://eksctl.io/installation)를 참조하세요.참고: 이 절차는 `eksctl`로 생성한 클러스터에서만 작동합니다. 1. 다음 콘텐츠를 디바이스에 복사합니다. `my-cluster`를 클러스터 이름으로 바꿉니다. 이름에는 영숫자(대소문자 구분)와 하이픈만 사용할 수 있습니다. 영문자로 시작해야 하며 100자 이하여야 합니다. `ng-ubuntu`을 노드 그룹의 이름으로 바꿉니다. 노드 그룹 이름은 63자를 초과할 수 없습니다. 문자나 숫자로 시작하되, 나머지 문자의 경우 하이픈과 밑줄을 포함할 수 있습니다. Arm 인스턴스에 배포하려면 `m5.large`을 Arm 인스턴스 유형으로 바꿉니다. `my-ec2-keypair-name`을 시작 이후 SSH를 사용하여 노드에 연결하는 데 사용할 수 있는 Amazon EC2 SSH 키 페어 이름으로 변경합니다. Amazon EC2 키 페어가 아직 없는 경우 AWS Management Console에서 새로 생성할 수 있습니다. 자세한 내용을 알아보려면 Amazon EC2 사용 설명서의 [Amazon EC2 키 페어](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ec2-key-pairs.html)를 참조하세요. 나머지 예제 값을 자신의 값으로 바꿉니다. 다 바꾼 후 수정된 명령을 실행하여 `ubuntu.yaml` 파일을 생성합니다. **중요** 노드 그룹을 AWS Outposts, AWS Wavelength 또는 AWS Local Zones 서브넷에 배포하려면 클러스터를 생성할 때 AWS Outposts, AWS Wavelength 또는 AWS 로컬 영역 서브넷을 전달하지 마세요. 다음 예에서는 서브넷을 지정해야 합니다. 자세한 내용은 `eksctl` 문서에서 [구성 파일을 사용하여 nodegroup 생성](https://eksctl.io/usage/nodegroups/#creating-a-nodegroup-from-a-config-file) 및 [구성 파일 스키마](https://eksctl.io/usage/schema/) 부분을 참조하세요. *region-code*를 클러스터가 있는 AWS 리전으로 바꿉니다. ``` cat >ubuntu.yaml < 새로운 Amazon EKS 최적화 AMI가 릴리스되면 자체 관리형 노드 그룹의 노드를 새 AMI로 교체하는 것을 고려합니다. 마찬가지로, Amazon EKS 클러스터용 Kubernetes 버전을 업데이트한 경우 동일한 Kubernetes 버전이 있는 노드를 사용하도록 노드를 업데이트합니다. **중요** 이 주제에서는 자체 관리형 노드 그룹에 대한 노드 업데이트에 대해 설명합니다. [관리형 노드 그룹](managed-node-groups.md)을 사용하는 경우 [클러스터에 대한 관리형 노드 그룹 업데이트](update-managed-node-group.md) 섹션을 참조하세요. 새 AMI를 사용하도록 클러스터의 자체 관리형 노드 그룹을 업데이트하는 기본 방법에는 두 가지가 있습니다. ** [애플리케이션을 새 노드 그룹으로 마이그레이션](migrate-stack.md) ** 새 노드 그룹을 생성하고 포드를 해당 그룹으로 마이그레이션합니다. 기존 AWS CloudFormation 스택에서 단순히 AMI ID를 업데이트하는 것보다 새 노드 그룹으로 마이그레이션하는 것이 낫습니다. 이는 마이그레이션 프로세스가 이전 노드 그룹을 `NoSchedule`로 [테인트](https://kubernetes.io/docs/concepts/scheduling-eviction/taint-and-toleration/)하고 새 스택이 기존 포드 워크로드를 수락할 준비가 된 후 노드를 드레이닝하기 때문입니다. ** [AWS CloudFormation 노드 스택 업데이트](update-stack.md) ** 새 AMI를 사용하도록 기존 노드 그룹의 AWSCloudFormation 스택을 업데이트합니다. 이 방법은 `eksctl`로 생성한 노드 그룹에는 사용할 수 없습니다. # 애플리케이션을 새 노드 그룹으로 마이그레이션 이 주제에서는 새로운 노드 그룹을 생성하고, 기존 애플리케이션을 새 그룹으로 안정적으로 마이그레이션한 다음, 이전 노드 그룹을 클러스터에서 제거하는 방법을 설명합니다. `eksctl` 또는 AWS Management Console을 사용하여 새 노드 그룹으로 마이그레이션할 수 있습니다. + [`eksctl`](#eksctl_migrate_apps) + [AWS Management Console 및 AWS CLI](#console_migrate_apps) ## `eksctl` **`eksctl`을 사용하여 애플리케이션을 새 노드 그룹으로 마이그레이션하려면** 마이그레이션에 eksctl을 사용하는 방법에 대한 자세한 내용은 `eksctl` 설명서의 [비관리형 노드 그룹](https://eksctl.io/usage/nodegroup-unmanaged/)을 참조하세요. 이 절차에는 `eksctl` 버전 `0.215.0` 이상이 필요합니다. 버전은 다음 명령을 통해 확인할 수 있습니다. ``` eksctl version ``` `eksctl` 설치 또는 업데이트에 대한 지침은 `eksctl` 설명서에서 [설치](https://eksctl.io/installation)를 참조하세요. **참고** 이 절차는 `eksctl`을 사용하여 생성한 클러스터 및 노드 그룹에 대해서만 사용할 수 있습니다. 1. *my-cluster*를 클러스터 이름으로 바꿔서 기존 노드 그룹의 이름을 검색합니다. ``` eksctl get nodegroups --cluster=my-cluster ``` 예제 출력은 다음과 같습니다. ``` CLUSTER NODEGROUP CREATED MIN SIZE MAX SIZE DESIRED CAPACITY INSTANCE TYPE IMAGE ID default standard-nodes 2019-05-01T22:26:58Z 1 4 3 t3.medium ami-05a71d034119ffc12 ``` 1. 다음 명령어로 `eksctl`을 사용하여 새 노드 그룹을 시작합니다. 명령에서 모든 *예제 값*을 고유한 값으로 바꿉니다. 버전 번호는 컨트롤 플레인의 Kubernetes 버전보다 이후일 수 없습니다. 또한 컨트롤 플레인의 Kubernetes 버전보다 이전인 마이너 버전이 2개를 초과할 수 없습니다. 컨트롤 플레인과 동일한 버전을 사용하는 것이 좋습니다. 다음과 같은 조건에 해당하면 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` 옵션을 다음 명령에 추가합니다. **참고** 사용 가능한 플래그 및 설명에 대한 자세한 내용은 https://eksctl.io/를 참조하세요. ``` eksctl create nodegroup \ --cluster my-cluster \ --version 1.35 \ --name standard-nodes-new \ --node-type t3.medium \ --nodes 3 \ --nodes-min 1 \ --nodes-max 4 \ --managed=false ``` 1. 이전 명령이 완료되면 다음 명령으로 모든 노드가 `Ready` 상태가 되었는지 확인합니다. ``` kubectl get nodes ``` 1. 다음 명령을 사용하여 원래 노드 그룹을 삭제합니다. 명령에서 모든 *예제 값*을 클러스터 이름과 노드 그룹 이름으로 바꿉니다. ``` eksctl delete nodegroup --cluster my-cluster --name standard-nodes-old ``` ## AWS Management Console 및 AWS CLI **AWS Management Console 및 AWS CLI에서 애플리케이션을 새 노드 그룹으로 마이그레이션하려면** 1. [자체 관리 Amazon Linux 노드 생성](launch-workers.md)에 설명된 단계에 따라 새 노드 그룹을 시작합니다. 1. 스택이 생성된 후 콘솔에서 이를 선택하고 **출력**을 선택합니다. 1. 생성된 노드 그룹에 대해 **NodeInstanceRole**을 기록합니다. 새 Amazon EKS 노드를 클러스터에 추가하려면 이 정보가 필요합니다. **참고** 추가 IAM 정책을 이전 노드 그룹의 IAM 역할에 연결한 경우 새 그룹에서 해당 기능을 유지하려면 동일한 정책을 새 노드 그룹의 IAM 역할에 연결해야 합니다. 이는 예를 들어, Kubernetes [Cluster Autoscaler](https://github.com/kubernetes/autoscaler/tree/master/cluster-autoscaler)에 대한 권한을 추가한 경우에 적용됩니다. 1. 두 노드 그룹이 서로 통신할 수 있도록 두 노드 그룹의 보안 그룹을 업데이트합니다. 자세한 내용은 [클러스터에 대한 Amazon EKS 보안 그룹 요구 사항 보기](sec-group-reqs.md) 섹션을 참조하세요. 1. 두 노드 그룹에 대한 보안 그룹 ID를 모두 기록합니다. 이는 AWS CloudFormation 스택 출력에 **NodeSecurityGroup** 값으로 표시됩니다. 다음 AWS CLI 명령을 사용하여 스택 이름에서 보안 그룹 ID를 가져옵니다. 이러한 명령에서 `oldNodes`는 이전 노드 스택의 AWS CloudFormation 스택 이름이고 `newNodes`는 마이그레이션하는 대상 스택의 이름입니다. 모든 *예제 값*을 자신의 값으로 바꾸세요. ``` oldNodes="old_node_CFN_stack_name" newNodes="new_node_CFN_stack_name" oldSecGroup=$(aws cloudformation describe-stack-resources --stack-name $oldNodes \ --query 'StackResources[?ResourceType==`AWS::EC2::SecurityGroup`].PhysicalResourceId' \ --output text) newSecGroup=$(aws cloudformation describe-stack-resources --stack-name $newNodes \ --query 'StackResources[?ResourceType==`AWS::EC2::SecurityGroup`].PhysicalResourceId' \ --output text) ``` 1. 각 노드 보안 그룹이 서로의 트래픽을 수락하도록 노드 보안 그룹에 인그레스 규칙을 추가합니다. 다음 AWS CLI 명령은 상대 보안 그룹의 모든 프로토콜에서 모든 트래픽을 허용하는 인바운드 규칙을 각 보안 그룹에 추가합니다. 이렇게 구성하면 워크로드를 새 그룹으로 마이그레이션하는 동안 각 노드 그룹의 포드가 서로 통신할 수 있습니다. ``` aws ec2 authorize-security-group-ingress --group-id $oldSecGroup \ --source-group $newSecGroup --protocol -1 aws ec2 authorize-security-group-ingress --group-id $newSecGroup \ --source-group $oldSecGroup --protocol -1 ``` 1. `aws-auth` configmap을 편집하여 RBAC에서 새 노드 인스턴스 역할을 매핑합니다. ``` kubectl edit configmap -n kube-system aws-auth ``` 새 노드 그룹에 대한 새 `mapRoles` 항목을 추가합니다. ``` apiVersion: v1 data: mapRoles: | - rolearn: ARN of instance role (not instance profile) username: system:node:{{EC2PrivateDNSName}} groups: - system:bootstrappers - system:nodes> - rolearn: arn:aws:iam::111122223333:role/nodes-1-16-NodeInstanceRole-U11V27W93CX5 username: system:node:{{EC2PrivateDNSName}} groups: - system:bootstrappers - system:nodes ``` *ARN of instance role (not instance profile)* 조각을 [이전 절차](#node-instance-role-step)에서 기록한 **NodeInstanceRole **값으로 교체하고 파일을 저장합니다. 그런 다음 파일을 저장하고 닫아서 업데이트된 configmap을 적용합니다. 1. 노드의 상태를 보면서 새 노드가 클러스터에 조인하고 `Ready` 상태에 도달할 때까지 기다립니다. ``` kubectl get nodes --watch ``` 1. (선택사항) [Kubernetes Cluster Autoscaler](https://github.com/kubernetes/autoscaler/tree/master/cluster-autoscaler)를 사용하는 경우, 배포를 복제본 0개로 축소하여 조정 작업의 충돌을 방지합니다. ``` kubectl scale deployments/cluster-autoscaler --replicas=0 -n kube-system ``` 1. 다음 명령을 사용하여 `NoSchedule`로 제거하려는 각 노드를 테인트합니다. 이는 바꾸고 있는 노드에서 새 포드가 예약되거나 다시 예약되지 않도록 하기 위한 것입니다. 자세한 내용은 Kubernetes 설명서의 [테인트와 허용 오차](https://kubernetes.io/docs/concepts/scheduling-eviction/taint-and-toleration/)를 참조하세요. ``` kubectl taint nodes node_name key=value:NoSchedule ``` 노드를 새 Kubernetes 버전으로 업그레이드하는 경우 다음 코드 조각을 사용하여 특정 Kubernetes 버전(이 경우 `1.33`)의 모든 노드를 식별하고 테인트할 수 있습니다. 버전 번호는 컨트롤 플레인의 Kubernetes 버전보다 이후일 수 없습니다. 또한 컨트롤 플레인의 Kubernetes 버전보다 이전인 마이너 버전이 2개를 초과할 수 없습니다. 컨트롤 플레인과 동일한 버전을 사용하는 것이 좋습니다. ``` K8S_VERSION=1.33 nodes=$(kubectl get nodes -o jsonpath="{.items[?(@.status.nodeInfo.kubeletVersion==\"v$K8S_VERSION\")].metadata.name}") for node in ${nodes[@]} do echo "Tainting $node" kubectl taint nodes $node key=value:NoSchedule done ``` 1. 클러스터의 DNS 공급자를 결정합니다. ``` kubectl get deployments -l k8s-app=kube-dns -n kube-system ``` 예제 출력은 다음과 같습니다. 이 클러스터는 DNS 확인에 CoreDNS를 사용하고 있지만, 클러스터는 그 대신 `kube-dns`를 반환할 수 있습니다. ``` NAME DESIRED CURRENT UP-TO-DATE AVAILABLE AGE coredns 1 1 1 1 31m ``` 1. 현재 배포가 두 개 미만의 복제본을 실행하고 있는 경우, 배포를 복제본 두 개로 확장합니다. 이전 명령 출력에서 해당 값이 대신 반환된 경우 *coredns*을 `kubedns`로 교체합니다. ``` kubectl scale deployments/coredns --replicas=2 -n kube-system ``` 1. 다음 명령을 사용하여 클러스터에서 제거할 각 노드를 드레이닝합니다. ``` kubectl drain node_name --ignore-daemonsets --delete-local-data ``` 노드를 새 Kubernetes 버전으로 업그레이드하는 경우 다음 코드 조각을 사용하여 특정 Kubernetes 버전(이 경우 *1.33*)의 모든 노드를 식별하고 드레이닝합니다. ``` K8S_VERSION=1.33 nodes=$(kubectl get nodes -o jsonpath="{.items[?(@.status.nodeInfo.kubeletVersion==\"v$K8S_VERSION\")].metadata.name}") for node in ${nodes[@]} do echo "Draining $node" kubectl drain $node --ignore-daemonsets --delete-local-data done ``` 1. 이전 노드가 드레이닝을 완료한 후 앞서 권한을 부여한 보안 그룹 인바운드 규칙을 취소합니다. 그런 다음 AWS CloudFormation 스택을 삭제하여 인스턴스를 종료합니다. **참고** [Kubernetes 클러스터 오토스케일러](https://github.com/kubernetes/autoscaler/tree/master/cluster-autoscaler)에 대한 사용 권한 추가와 같이 이전 노드 그룹 IAM 역할에 추가 IAM 정책을 첨부한 경우, AWS CloudFormation 스택을 삭제하기 전에 해당 추가 정책을 역할에서 분리해야 합니다. 1. 위에서 노드 보안 그룹에 대해 생성한 인바운드 규칙을 취소합니다. 이러한 명령에서 `oldNodes`는 이전 노드 스택의 AWS CloudFormation 스택 이름이고 `newNodes`는 마이그레이션하는 대상 스택의 이름입니다. ``` oldNodes="old_node_CFN_stack_name" newNodes="new_node_CFN_stack_name" oldSecGroup=$(aws cloudformation describe-stack-resources --stack-name $oldNodes \ --query 'StackResources[?ResourceType==`AWS::EC2::SecurityGroup`].PhysicalResourceId' \ --output text) newSecGroup=$(aws cloudformation describe-stack-resources --stack-name $newNodes \ --query 'StackResources[?ResourceType==`AWS::EC2::SecurityGroup`].PhysicalResourceId' \ --output text) aws ec2 revoke-security-group-ingress --group-id $oldSecGroup \ --source-group $newSecGroup --protocol -1 aws ec2 revoke-security-group-ingress --group-id $newSecGroup \ --source-group $oldSecGroup --protocol -1 ``` 1. [AWS CloudFormation 콘솔](https://console.aws.amazon.com/cloudformation/)을 엽니다. 1. 이전 노드 스택을 선택합니다. 1. **삭제**를 선택합니다. 1. **스택 삭제** 확인 대화 상자에서 **스택 삭제**를 선택합니다. 1. `aws-auth` configmap을 편집하여 RBAC에서 이전 노드 인스턴스 역할을 제거합니다. ``` kubectl edit configmap -n kube-system aws-auth ``` 이전 노드 그룹에 대한 `mapRoles` 항목을 삭제합니다. ``` apiVersion: v1 data: mapRoles: | - rolearn: arn:aws:iam::111122223333:role/nodes-1-16-NodeInstanceRole-W70725MZQFF8 username: system:node:{{EC2PrivateDNSName}} groups: - system:bootstrappers - system:nodes - rolearn: arn:aws:iam::111122223333:role/nodes-1-15-NodeInstanceRole-U11V27W93CX5 username: system:node:{{EC2PrivateDNSName}} groups: - system:bootstrappers - system:nodes> ``` 파일을 저장하고 닫아서 업데이트된 configmap을 적용합니다. 1. (선택사항) Kubernetes [Cluster Autoscaler](https://github.com/kubernetes/autoscaler/tree/master/cluster-autoscaler)를 사용하는 경우, 배포를 다시 복제본 한 개로 축소합니다. **참고** 또한 새 Auto Scaling 그룹에 적절한 태그를 지정하고(예: `k8s.io/cluster-autoscaler/enabled,k8s.io/cluster-autoscaler/my-cluster`) 태그가 새로 지정된 Auto Scaling 그룹을 가리키도록 Cluster Autoscaler 배포에 대한 명령을 업데이트해야 합니다. 자세한 내용은 [AWS의 Cluster Autoscaler](https://github.com/kubernetes/autoscaler/tree/cluster-autoscaler-release-1.3/cluster-autoscaler/cloudprovider/aws)를 참조하세요. ``` kubectl scale deployments/cluster-autoscaler --replicas=1 -n kube-system ``` 1. (선택사항) 최신 버전의 [Kubernetes용 Amazon VPC CNI 플러그인](https://github.com/aws/amazon-vpc-cni-k8s)을 사용하고 있는지 확인합니다. 지원되는 최신 인스턴스 유형을 사용하려면 CNI 버전을 업데이트해야 할 수 있습니다. 자세한 내용은 [Amazon VPC CNI를 통해 포드에 IP 할당](managing-vpc-cni.md) 섹션을 참조하세요. 1. 클러스터가 DNS 확인에 `kube-dns`를 사용하는 경우,([[migrate-determine-dns-step]](#migrate-determine-dns-step) 단계 참조) `kube-dns` 배포를 복제본 한 개로 축소합니다. ``` kubectl scale deployments/kube-dns --replicas=1 -n kube-system ``` # AWS CloudFormation 노드 스택 업데이트 이 주제에서는 기존 AWS CloudFormation 자체 관리형 노드 스택을 새 AMI로 업데이트하는 방법을 설명합니다. 이 절차를 사용하여 클러스터 업데이트 후 새 버전의 Kubernetes로 노드를 업데이트할 수 있습니다. 그렇지 않으면 기존 Kubernetes 버전에 대해 최신 Amazon EKS 최적화 AMI로 업데이트할 수 있습니다. **중요** 이 주제에서는 자체 관리형 노드 그룹에 대한 노드 업데이트에 대해 설명합니다. [관리형 노드 그룹에서 Simplify 노드 수명 주기](managed-node-groups.md)를 사용하는 방법에 대한 자세한 내용은 [클러스터에 대한 관리형 노드 그룹 업데이트](update-managed-node-group.md)을 참조하세요. 최신 기본 Amazon EKS 노드 AWS CloudFormation 템플릿은 예전 인스턴스를 제거하기 전에 한 번에 하나씩 새 AMI로 인스턴스를 시작하도록 구성되어 있습니다. 이렇게 구성하면 업데이트를 적용하는 동안 클러스터의 Auto Scaling 그룹에 항상 활성 인스턴스 수를 원하는 대로 항상 유지할 수 있습니다. **참고** 이 방법은 `eksctl`로 생성한 노드 그룹에는 사용할 수 없습니다. `eksctl`을 사용하여 클러스터 또는 노드 그룹을 생성한 경우, [애플리케이션을 새 노드 그룹으로 마이그레이션](migrate-stack.md) 부분을 참조하세요. 1. 클러스터의 DNS 공급자를 결정합니다. ``` kubectl get deployments -l k8s-app=kube-dns -n kube-system ``` 예제 출력은 다음과 같습니다. 이 클러스터는 DNS 확인에 CoreDNS를 사용하고 있지만, 클러스터는 그 대신 `kube-dns`를 반환할 수 있습니다. 사용 중인 `kubectl` 버전에 따라 출력물이 다르게 보일 수 있습니다. ``` NAME DESIRED CURRENT UP-TO-DATE AVAILABLE AGE coredns 1 1 1 1 31m ``` 1. 현재 배포가 두 개 미만의 복제본을 실행하고 있는 경우, 배포를 복제본 두 개로 확장합니다. 이전 명령 출력에서 해당 값이 대신 반환된 경우 *coredns*을 `kube-dns`로 교체합니다. ``` kubectl scale deployments/coredns --replicas=2 -n kube-system ``` 1. (선택사항) [Kubernetes Cluster Autoscaler](https://github.com/kubernetes/autoscaler/blob/master/cluster-autoscaler/cloudprovider/aws/README.md)를 사용하는 경우, 배포를 복제본 0개로 축소하여 조정 작업의 충돌을 방지합니다. ``` kubectl scale deployments/cluster-autoscaler --replicas=0 -n kube-system ``` 1. 현재 노드 그룹의 인스턴스 유형과 원하는 인스턴스 수를 결정합니다. 나중에 그룹에 대한 AWS CloudFormation 템플릿을 업데이트할 때 이러한 값을 입력합니다. 1. https://console.aws.amazon.com/ec2/에서 Amazon EC2 콘솔을 엽니다. 1. 왼쪽 탐색 창에서 **시작 구성**을 선택하고 기존 노드 시작 구성에 대한 인스턴스 유형을 기록해 둡니다. 1. 왼쪽 탐색 창에서 **Auto Scaling 그룹**을 선택하고 기존 노드 Auto Scaling 그룹에 대해 **원하는** 인스턴스 수를 적어둡니다. 1. [AWS CloudFormation 콘솔](https://console.aws.amazon.com/cloudformation/)을 엽니다. 1. 노드 그룹 스택을 선택한 다음 **업데이트**를 선택합니다. 1. **현재 템플릿 대치**를 선택하고 **Amazon S3 URL**을 선택합니다. 1. **Amazon S3 URL**에서 다음 URL을 텍스트 영역에 붙여 넣어 최신 버전의 노드 AWS CloudFormation 템플릿을 사용하고 있는지 확인합니다. 그리고 **다음**을 선택합니다. ``` https://s3.us-west-2.amazonaws.com/amazon-eks/cloudformation/2022-12-23/amazon-eks-nodegroup.yaml ``` 1. **스택 세부 정보 지정** 페이지에서 다음 파라미터를 입력하고 **다음**을 선택합니다. + **NodeAutoScalingGroupDesiredCapacity** - [이전 단계](#existing-worker-settings-step)에서 기록한 원하는 인스턴스 수를 입력합니다. 또는 스택을 업데이트할 때 조정할 원하는 새 노드 수를 입력합니다. + **NodeAutoScalingGroupMaxSize** - Auto Scaling 그룹이 확장할 수 있는 노드의 최대 노드 수를 입력합니다. 이 값은 원하는 용량보다 하나 이상의 노드여야 합니다. 이는 업데이트 중에 노드 수를 줄이지 않고 노드의 롤링 업데이트를 수행할 수 있도록 하기 위한 것입니다. + **NodeInstanceType** - [이전 단계](#existing-worker-settings-step)에서 기록한 인스턴스 유형을 선택합니다. 또는 노드에 대해 다른 인스턴스 유형을 선택합니다. 다른 인스턴스 유형을 선택하기 전에 [최적의 Amazon EC2 노드 인스턴스 유형 선택](choosing-instance-type.md)을 검토합니다. 각 Amazon EC2 인스턴스 유형은 탄력적 네트워크 인터페이스(네트워크 인터페이스)의 최대 수를 지원하며 각 네트워크 인터페이스는 최대 IP 주소 수를 지원합니다. 각 워커 노드와 포드에는 고유한 IP 주소가 할당되므로 각 Amazon EC2 노드에서 실행할 최대 포드 수를 지원하는 인스턴스 유형을 선택하는 것이 중요합니다. 인스턴스 유형이 지원하는 네트워크 인터페이스 및 IP 주소의 수 목록은 [인스턴스 유형별 네트워크 인터페이스당 IP 주소](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/using-eni.html#AvailableIpPerENI)를 참조하세요. 예를 들어, `m5.large` 인스턴스 유형은 워커 노드 및 포드에 대해 최대 30개의 IP 주소를 지원합니다. **참고** 최신 버전의 [Kubernetes용 Amazon VPC CNI 플러그 인](https://github.com/aws/amazon-vpc-cni-k8s)에 대해 지원되는 인스턴스 유형은 GitHub의 [vpc\$1ip\$1resource\$1limit.go](https://github.com/aws/amazon-vpc-cni-k8s/blob/master/pkg/vpc/vpc_ip_resource_limit.go)에 나와 있습니다. 지원되는 최신 인스턴스 유형을 사용하려면 Kubernetes용 Amazon VPC CNI 플러그인 버전을 업데이트해야 할 수 있습니다. 자세한 내용은 [Amazon VPC CNI를 통해 포드에 IP 할당](managing-vpc-cni.md) 섹션을 참조하세요. **중요** AWS 리전에 따라 일부 인스턴스 유형은 사용할 수 없습니다. + **NodeImageIdSSMParam** – 업데이트하려는 AMI ID의 Amazon EC2 Systems Manager 파라미터입니다. 다음 값에서는 Kubernetes 버전 `1.35`에 대해 최신 Amazon EKS 최적화 AMI를 사용합니다. ``` /aws/service/eks/optimized-ami/1.35/amazon-linux-2/recommended/image_id ``` *1.35*을 동일한 [플랫폼 버전](https://docs.aws.amazon.com/eks/latest/userguide/platform-versions.html)으로 바꿀 수 있습니다. 또는 제어 영역에서 실행 중인 Kubernetes 버전보다 최대 한 버전 이전이어야 합니다. 노드를 제어 영역과 동일한 버전으로 유지하는 것이 좋습니다. *amazon-linux-2*를 다른 AMI 유형으로 바꿀 수도 있습니다. 자세한 내용은 [권장 Amazon Linux AMI ID 검색](retrieve-ami-id.md) 섹션을 참조하세요. **참고** Amazon EC2 Systems Manager 파라미터를 사용하면 AMI ID를 조회하고 지정하지 않아도 나중에 노드를 업데이트할 수 있습니다. AWS CloudFormation 스택에서 이 값을 사용 중이라면 모든 스택 업데이트는 지정된 Kubernetes 버전에 권장되는 최신 Amazon EKS 최적화 AMI를 항상 시작합니다. 템플릿에서 값을 변경하지 않은 경우에도 마찬가지입니다. + **NodeImageId** – 고유한 사용자 지정 AMI를 사용하려면 사용할 AMI의 ID를 입력하세요. **중요** 이 값은 **NodeImageIdSSMParam**에 지정된 값을 재정의합니다. **NodeImageIdSSMParam** 값을 사용하려면 **NodeImageId**의 값이 비어 있는지 확인하세요. + **DisableIMDSv1** - 기본적으로 각 노드는 인스턴스 메타데이터 서비스 버전 1(IMDSv1) 및 IMDSv2를 지원합니다. 그러나 IMDSv1을 사용 중지할 수 있습니다. 노드 그룹에서 예약된 노드 또는 포드가 IMDSv1을 사용하지 않도록 하려면 **true**를 선택합니다. IMDS에 대한 자세한 내용은 [인스턴스 메타데이터 서비스 구성](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/configuring-instance-metadata-service.html)을 참조하세요. 서비스 계정에 대한 IAM 역할을 구현한 경우 AWS 서비스에 대한 액세스 권한이 필요한 모든 포드에 직접 필요한 권한을 할당합니다. 이렇게 하면 현재 AWS 리전 검색 등의 다른 이유로 클러스터의 포드가 IMDS에 액세스할 필요가 없습니다. 그런 다음 호스트 네트워킹을 사용하지 않는 포드에 대해 IMDSv2 액세스를 사용 중지할 수도 있습니다. 자세한 내용은 [작업자 노드에 할당된 인스턴스 프로필에 대한 액세스 제한](https://aws.github.io/aws-eks-best-practices/security/docs/iam/#restrict-access-to-the-instance-profile-assigned-to-the-worker-node) 부분을 참조하세요. 1. (선택사항) **옵션** 페이지에서 스택 리소스에 태그를 지정합니다. **다음**을 선택합니다. 1. **검토** 페이지에서 정보를 검토하고, 스택이 IAM 리소스를 생성할 수 있는지 확인한 다음, **스택 업데이트**를 선택합니다. **참고** 클러스터의 각 노드를 업데이트하는 데 몇 분 정도 걸립니다. 모든 노드의 업데이트가 완료될 때까지 기다린 후 다음 단계를 수행합니다. 1. 클러스터의 DNS 공급자가 `kube-dns`인 경우 `kube-dns` 배포를 복제본 한 개로 축소합니다. ``` kubectl scale deployments/kube-dns --replicas=1 -n kube-system ``` 1. (선택 사항) Kubernetes [Cluster Autoscaler](https://github.com/kubernetes/autoscaler/blob/master/cluster-autoscaler/cloudprovider/aws/README.md)를 사용하는 경우 배포를 다시 원하는 양의 복제본으로 조정합니다. ``` kubectl scale deployments/cluster-autoscaler --replicas=1 -n kube-system ``` 1. (선택사항) 최신 버전의 [Kubernetes용 Amazon VPC CNI 플러그인](https://github.com/aws/amazon-vpc-cni-k8s)을 사용하고 있는지 확인합니다. 지원되는 최신 인스턴스 유형을 사용하려면 Kubernetes용 Amazon VPC CNI 플러그인 버전을 업데이트해야 할 수 있습니다. 자세한 내용은 [Amazon VPC CNI를 통해 포드에 IP 할당](managing-vpc-cni.md) 섹션을 참조하세요. # AWS Fargate를 사용한 컴퓨팅 관리 간소화 이 주제에서는 AWS Fargate에서 Amazon EKS를 사용하여 Kubernetes 포드를 실행하는 방법을 설명합니다. Fargate는 [컨테이너](https://aws.amazon.com/what-are-containers)에 대한 적정 규모의 온디맨드 컴퓨팅 용량을 제공하는 기술입니다. Fargate를 사용하면 컨테이너를 실행하려면 직접 가상 머신 그룹을 프로비저닝, 구성 또는 크기를 조정할 필요가 없습니다. 따라서 서버 유형을 선택하거나, 노드 그룹을 조정할 시점을 결정하거나, 클러스터 패킹을 최적화할 필요가 없습니다. Fargate에서 시작하는 포드와 [Fargate 프로필](fargate-profile.md)에서 실행되는 방법을 제어할 수 있습니다. Fargate 프로필은 Amazon EKS 클러스터의 일부로 정의됩니다. Amazon EKS는 Kubernetes에서 제공한 확장 가능한 업스트림 모델을 사용하여 AWS에서 빌드한 컨트롤러를 사용하여 Kubernetes를 Fargate와 통합합니다. 이러한 컨트롤러는 Amazon EKS 관리형 Kubernetes 컨트롤 플레인의 일부로 실행되며 Fargate에 기본 Kubernetes 포드를 예약합니다. Fargate 컨트롤러에는 여러 개의 변형 및 검증 승인 컨트롤러 외에도 기본 Kubernetes 스케줄러와 함께 실행되는 새 스케줄러가 포함되어 있습니다. Fargate에서 실행하기 위한 조건을 충족하는 포드를 시작하면 클러스터에서 실행되는 Fargate 컨트롤러가 해당 포드를 인식하고 업데이트하고 Fargate에 예약합니다. 이 주제에서는 Fargate에서 실행되는 포드의 여러 구성 요소에 대해 설명하고 Amazon EKS에서 Fargate를 사용하기 위한 특별한 고려 사항을 살펴봅니다. ## AWS Fargate 고려 사항 Amazon EKS에서 Fargate를 사용할 때 고려해야 할 몇 가지 사항이 있습니다. + Fargate에서 실행되는 각 포드에는 자체 컴퓨팅 경계가 있습니다. 기본 커널, CPU 리소스, 메모리 리소스 또는 탄력적 네트워크 인터페이스를 다른 포드와 공유하지 않습니다. + Network Load Balancer 및 Application Load Balancer(ALB)는 IP 대상을 통해서만 Fargate에서 사용할 수 있습니다. 자세한 내용은 [Network Load Balancer 생성](network-load-balancing.md#network-load-balancer) 및 [Application Load Balancer를 사용하여 애플리케이션 및 HTTP 트래픽 라우팅](alb-ingress.md) 섹션을 참조하세요. + Fargate 노출 서비스는 노드 IP 모드가 아닌 대상 유형 IP 모드에서만 실행됩니다. 관리형 노드에서 실행 중인 서비스와 Fargate에서 실행 중인 서비스의 연결을 확인하는 권장 방법은 서비스 이름을 통해 연결하는 것입니다. + 포드는 Fargate에서 실행되도록 예약된 시간에 Fargate 프로필과 일치해야 합니다. Fargate 프로필과 일치하지 않는 포드는 `Pending`과 같이 중단될 수 있습니다. 일치하는 Fargate 프로필이 있는 경우 사용자가 생성한 보류 중인 포드를 삭제하여 Fargate에 다시 예약할 수 있습니다. + DaemonSets는 Fargate에서 지원되지 않습니다. 애플리케이션에 대몬이 필요한 경우 포드에서 사이드카 컨테이너로 실행되도록 해당 대몬을 다시 구성합니다. + 권한 있는(Privileged) 컨테이너는 Fargate에서 지원되지 않습니다. + Fargate에서 실행되는 포드는 포드 매니페스트에서 `HostPort` 또는 `HostNetwork`를 지정할 수 없습니다. + Fargate 포드의 경우 기본 `nofile` 및 `nproc` 소프트 제한은 1,024이고 하드 제한은 6만 5,535입니다. + GPU는 현재 Fargate에서 사용할 수 없습니다. + Fargate에서 실행되는 포드는 인터넷 게이트웨이에 대한 직접 경로가 없고 AWS 서비스에 대한 NAT 게이트웨이 액세스 권한이 있는 프라이빗 서브넷에서만 지원되므로 클러스터의 VPC에 프라이빗 서브넷이 있어야 합니다. 아웃바운드 인터넷 액세스가 없는 클러스터의 경우 [인터넷 액세스가 제한된 프라이빗 클러스터 배포](private-clusters.md)을 참조하세요. + [Vertical Pod Autoscaler로 포드 리소스 조정](vertical-pod-autoscaler.md)을 사용하여 Fargate 포드의 초기 올바른 CPU 및 메모리 크기를 설정한 다음 [Horizontal Pod Autoscaler로 포드 배포 확장](horizontal-pod-autoscaler.md)을 사용하여 해당 포드의 규모를 조정할 수 있습니다. Vertical Pod Autoscaler가 더 큰 CPU 및 메모리 조합으로 포드를 Fargate에 자동으로 다시 배포하도록 하려면 Vertical Pod Autoscaler의 모드를 `Auto` 또는 `Recreate`로 설정하여 올바로 작동하게 해야 합니다. 자세한 내용은 GitHub에서 [Vertical Pod Autoscaler](https://github.com/kubernetes/autoscaler/tree/master/vertical-pod-autoscaler#quick-start) 문서를 참조하세요. + VPC에 대해 DNS 확인 및 DNS 호스트 이름을 활성화해야 합니다. 자세한 내용은 [VPC에 대한 DNS 지원 보기 및 업데이트](https://docs.aws.amazon.com/vpc/latest/userguide/vpc-dns.html#vpc-dns-updating)를 참조하세요. + Amazon EKS Fargate는 가상 머신(VM) 내에서 각 포드를 격리하여 Kubernetes 애플리케이션에 대한 심층 방어 기능을 추가합니다. 이 VM 경계를 통해 컨테이너 이스케이프 시 다른 포드에서 사용하는 호스트 기반 리소스에 대한 액세스를 방지하는데, 이 방법은 컨테이너화된 애플리케이션을 공격하고 컨테이너 외부의 리소스에 대한 액세스 권한을 얻는 일반적인 방법입니다. Amazon EKS를 사용해도 [공동 책임 모델](security.md)에서 책임은 변경되지 않습니다. 클러스터 보안 및 거버넌스 제어의 구성을 신중하게 고려해야 합니다. 애플리케이션을 격리하는 가장 안전한 방법은 항상 별도의 클러스터에서 실행하는 것입니다. + Fargate 프로필은 VPC 보조 CIDR 블록의 서브넷 지정을 지원합니다. 보조 CIDR 블록을 지정할 수도 있습니다. 서브넷에서 사용 가능한 IP 주소의 수는 제한되어 있기 때문입니다. 따라서 클러스터에서 생성할 수 있는 포드의 수가 제한되어 있습니다. 포드에 다른 서브넷을 사용하여 사용 가능한 IP 주소의 수를 늘릴 수 있습니다. 자세한 내용은 [VPC에 IPv4 CIDR 블록 추가](https://docs.aws.amazon.com/vpc/latest/userguide/VPC_Subnets.html#vpc-resize)를 참조하세요. + Amazon EC2 인스턴스 메타데이터 서비스(IMDS)는 Fargate 노드에 배포된 포드에는 사용할 수 없습니다. IAM 자격 증명이 필요한 포드를 Fargate에 배포한 경우 [서비스 계정용 IAM 역할](iam-roles-for-service-accounts.md)을 사용하여 포드에 할당합니다. 포드가 IMDS를 통해 제공되는 다른 정보에 액세스해야 할 경우 이 정보를 포드 사양에 하드 코딩해야 합니다. 여기에는 포드가 배포된 AWS 리전 또는 가용 영역이 포함됩니다. + Fargate 포드는 AWS Outposts, AWS Wavelength 또는 AWS 로컬 영역에 배포할 수 없습니다. + Amazon EKS는 정기적으로 Fargate 포드를 패치하여 보안을 유지해야 합니다. 영향을 줄이는 방식으로 업데이트를 시도하지만 포드가 성공적으로 제거되지 않으면 포드를 삭제해야 하는 경우가 있습니다. 중단을 최소화하기 위해 취할 수 있는 몇 가지 조치가 있습니다. 자세한 내용은 [AWS Fargate OS 패치 이벤트에 대한 작업 설정](fargate-pod-patching.md) 섹션을 참조하세요. + [Amazon EKS용 Amazon VPC CNI 플러그인](https://github.com/aws/amazon-vpc-cni-plugins)은 Fargate 노드에 설치됩니다. Fargate 노드가 있는 [Amazon EKS 클러스터에는 대체 CNI 플러그인](alternate-cni-plugins.md)을 사용할 수 없습니다. + Fargate에서 실행되는 포드는 수동 드라이버 설치 단계 없이 Amazon EFS 파일 시스템을 자동으로 탑재합니다. Fargate 노드에는 동적 영구 볼륨 프로비저닝을 사용할 수 없지만 고정적인 프로비저닝은 사용할 수 있습니다. + Amazon EKS는 Fargate 스팟을 지원하지 않습니다. + Amazon EBS 볼륨을 Fargate 포드에 탑재할 수 없습니다. + Amazon EBS CSI 컨트롤러는 Fargate 노드에서 실행할 수 있지만 Amazon EBS CSI 노드 DaemonSet은 Amazon EC2 인스턴스에서만 실행할 수 있습니다. + [Kubernetes 작업](https://kubernetes.io/docs/concepts/workloads/controllers/job/)이 `Completed` 또는 `Failed`로 표시된 후에도 작업이 생성하는 포드는 정상적으로 계속 존재합니다. 이 동작을 통해 로그와 결과를 볼 수 있지만 Fargate를 사용하는 경우 나중에 작업을 정리하지 않으면 비용이 발생합니다. 작업이 완료되거나 실패한 후 관련 포드를 자동으로 삭제하려면 TTL(Time-to-Live) 컨트롤러를 사용하여 기간을 지정할 수 있습니다. 다음 예제에서는 작업 매니페스트에 `.spec.ttlSecondsAfterFinished`를 지정하는 방법을 보여줍니다. ``` apiVersion: batch/v1 kind: Job metadata: name: busybox spec: template: spec: containers: - name: busybox image: busybox command: ["/bin/sh", "-c", "sleep 10"] restartPolicy: Never ttlSecondsAfterFinished: 60 # <-- TTL controller ``` ## Fargate 비교 테이블 | 기준 | AWS Fargate | | --- | --- | | [AWS Outposts](https://docs.aws.amazon.com/outposts/latest/userguide/what-is-outposts.html)에 배포 가능 | 아니요 | | [AWS Local Zones](local-zones.md)에 배포할 수 있습니다. | 아니요 | | Windows가 필요한 컨테이너를 실행할 수 있습니다. | 아니요 | | Linux가 필요한 컨테이너를 실행할 수 있습니다. | 예 | | Inferentia 칩이 필요한 워크로드를 실행할 수 있습니다. | 아니요 | | GPU가 필요한 워크로드를 실행할 수 있습니다. | 아니요 | | Arm 프로세서가 필요한 워크로드를 실행할 수 있습니다. | 아니요 | | AWS [Bottlerocket](https://aws.amazon.com/bottlerocket/)을 실행할 수 있습니다. | 아니요 | | 포드가 커널 런타임 환경을 다른 포드와 공유합니다. | 아니요 - 각 포드에는 전용 커널이 있습니다. | | 포드가 CPU, 메모리, 스토리지 및 네트워크 리소스를 다른 포드와 공유합니다. | 아니요 - 각 포드에는 전용 리소스가 있으며 독립적으로 크기를 조정하여 리소스 활용도를 극대화할 수 있습니다. | | 포드가 포드 사양에서 요청한 것보다 더 많은 하드웨어 및 메모리를 사용할 수 있습니다. | 아니요 - 더 큰 vCPU 및 메모리 구성을 사용하여 포드를 다시 배포할 수 있습니다. | | Amazon EC2 인스턴스를 배포하고 관리해야 합니다. | 아니요 | | Amazon EC2 인스턴스의 운영 체제를 보호, 유지 관리 및 패치해야 합니다. | 아니요 | | 노드 배포 시 추가 [kubelet](https://kubernetes.io/docs/reference/command-line-tools-reference/kubelet/) 인수와 같은 부트스트랩 인수를 제공할 수 있습니다. | 아니요 | | 노드에 할당된 IP 주소와 다른 CIDR 블록의 포드에 IP 주소를 할당할 수 있습니다. | 아니요 | | 노드에 SSH를 연결할 수 있습니다. | 아니요 - SSH에 사용할 노드 호스트 운영 체제가 없습니다. | | 사용자 지정 AMI 노드에 배포할 수 있습니다. | 아니요 | | 사용자 지정 CNI 노드에 배포할 수 있습니다. | 아니요 | | 노드 AMI를 직접 업데이트해야 합니다. | 아니요 | | 노드 Kubernetes 버전을 직접 업데이트해야 합니다. | 아니요 — 노드를 관리하지 않습니다. | | 포드에 Amazon EBS 스토리지를 사용할 수 있습니다. | 아니요 | | 포드에 Amazon EFS 스토리지를 사용할 수 있습니다. | [예](efs-csi.md) | | 포드에 Amazon FSx for Lustre 스토리지를 사용할 수 있습니다. | 아니요 | | 서비스에 Network Load Balancer를 사용할 수 있습니다. | 예, [네트워크 로드 밸런서 생성](network-load-balancing.md#network-load-balancer) 사용 시 | | 포드가 퍼블릭 서브넷에서 실행될 수 있습니다. | 아니요 | | 개별 포드에 서로 다른 VPC 보안 그룹을 할당할 수 있습니다. | 예 | | Kubernetes DaemonSet를 실행할 수 있습니다. | 아니요 | | 포드 매니페스트에서 `HostPort` 및 `HostNetwork`를 지원할 수 있습니다. | 아니요 | | AWS 리전 가용성 | [일부 Amazon EKS 지원 리전](https://docs.aws.amazon.com/general/latest/gr/eks.html) | | Amazon EC2 전용 호스트에서 컨테이너를 실행할 수 있습니다. | 아니요 | | 요금 | 개별 Fargate 메모리 및 CPU 구성 비용입니다. 각 포드에는 자체 비용이 있습니다. 자세한 내용은 [AWS Fargate 요금](https://aws.amazon.com/fargate/pricing/)을 참조하세요. | # 클러스터를 위한 AWS Fargate 시작하기 이 주제에서는 Amazon EKS 클러스터를 사용하여 AWS Fargate에서 포드 실행을 시작하는 방법을 설명합니다. CIDR 블록을 사용하여 클러스터의 퍼블릭 엔드포인트에 대한 액세스를 제한하는 경우 프라이빗 엔드포인트 액세스도 사용 설정하는 것이 좋습니다. 이렇게 하면 Fargate 포드가 클러스터와 통신할 수 있습니다. 프라이빗 엔드포인트를 활성화하지 않은 경우, 퍼블릭 액세스에 대해 지정하는 CIDR 블록에는 VPC의 아웃바운드 소스가 포함되어야 합니다. 자세한 내용은 [클러스터 API 서버 엔드포인트](cluster-endpoint.md) 섹션을 참조하세요. **전제 조건** 기존 클러스터가 있어야 합니다. Amazon EKS 클러스터가 아직 없는 경우 [Amazon EKS 시작하기](getting-started.md) 부분을 참조하세요. ## 1단계: 기존 노드가 Fargate 포드와 통신할 수 있는지 확인 노드가 없는 새 클러스터 또는 [관리형 노드 그룹을 사용한 노드 수명 주기 간소화](managed-node-groups.md) 관리형 노드 그룹만 있는 클러스터로 작업하는 경우 [2단계: Fargate 포드 실행 역할 생성](#fargate-sg-pod-execution-role)로 건너뛸 수 있습니다. 이미 연결된 노드가 있는 기존 클러스터로 작업하고 있다고 가정합니다. 이러한 노드의 포드가 Fargate에서 실행되는 포드와 자유롭게 통신할 수 있는지 확인합니다. Fargate에서 실행되는 포드는 연결된 클러스터에 대해 클러스터 보안 그룹을 사용하도록 자동으로 구성됩니다. 클러스터의 기존 노드가 클러스터 보안 그룹과 트래픽을 주고 받을 수 있는지 확인합니다. 관리형 노드 그룹은 클러스터 보안 그룹도 사용하도록 자동으로 구성되므로 이 호환성을 수정하거나 확인할 필요가 없습니다([관리형 노드 그룹을 사용한 노드 수명 주기 간소화](managed-node-groups.md) 참조). `eksctl` 또는 Amazon EKS 관리형 AWS CloudFormation 템플릿을 사용하여 생성한 기존 노드 그룹의 경우 클러스터 보안 그룹을 노드에 수동으로 추가할 수 있습니다. 또는 노드 그룹에 대한 Auto Scaling 그룹 시작 템플릿을 수정하여 클러스터 보안 그룹을 인스턴스에 연결할 수 있습니다. 자세한 내용은 *Amazon VPC 사용 설명서*의 [인스턴스의 보안 그룹 변경](https://docs.aws.amazon.com/vpc/latest/userguide/VPC_SecurityGroups.html#SG_Changing_Group_Membership) 부분을 참조하세요. 클러스터에 대한 **네트워킹** 섹션의 AWS Management Console에서 해당 클러스터에 대한 보안 그룹을 확인할 수 있습니다. 또는 다음 AWS CLI 명령을 사용하여 확인할 수 있습니다. 이 명령을 사용하는 경우 ``를 클러스터의 이름으로 바꿉니다. ``` aws eks describe-cluster --name --query cluster.resourcesVpcConfig.clusterSecurityGroupId ``` ## 2단계: Fargate 포드 실행 역할 생성 클러스터가 AWS Fargate에서 포드를 생성하는 경우 Fargate 인프라에서 실행되는 구성 요소는 사용자를 대신하여 AWS API를 직접적으로 직접 호출해야 합니다. Amazon EKS 포드 실행 역할은 이 작업을 수행할 수 있는 IAM 권한을 제공합니다. AWS Fargate 포드 실행 역할을 생성하려면 [Amazon EKS 포드 실행 IAM 역할](pod-execution-role.md) 섹션을 참조하세요. **참고** `--fargate` 옵션을 사용하여 `eksctl`로 클러스터를 생성한 경우 클러스터에는 이미 패턴 `eksctl-my-cluster-FargatePodExecutionRole-ABCDEFGHIJKL`에서 IAM 콘솔을 찾을 수 있는 포드 실행 역할이 있습니다. 마찬가지로 `eksctl`을 사용하여 Fargate 프로필을 생성하는 경우 포드 실행 역할이 생성되지 않았으면 `eksctl`을 사용하여 포드 실행 역할을 생성합니다. ## 3단계: 클러스터에 대한 Fargate 프로필 생성 클러스터의 Fargate에서 실행되는 포드를 예약하려면 먼저 포드가 시작될 때 Fargate를 사용할 포드를 지정하는 Fargate 프로필을 정의해야 합니다. 자세한 내용은 [시작 시 AWS Fargate를 사용하는 포드 정의](fargate-profile.md) 섹션을 참조하세요. **참고** `--fargate` 옵션을 사용하여 `eksctl`로 클러스터를 생성한 경우 `kube-system` 및 `default` 네임스페이스의 모든 포드에 대한 선택기를 사용하여 클러스터에 대한 Fargate 프로필이 이미 생성되어 있습니다. Fargate에서 사용할 다른 네임스페이스에 대한 Fargate 프로필을 생성하려면 다음 절차를 따르세요. 다음 도구 중 하나를 사용하여 Fargate 프로필을 생성할 수 있습니다. + [`eksctl`](#eksctl_fargate_profile_create) + [AWS Management Console](#console_fargate_profile_create) ### `eksctl` 이 절차에는 `eksctl` 버전 `0.215.0` 이상이 필요합니다. 버전은 다음 명령을 통해 확인할 수 있습니다. ``` eksctl version ``` `eksctl` 설치 또는 업데이트에 대한 지침은 `eksctl` 설명서의 [Installation](https://eksctl.io/installation)를 참조하세요. **을 사용하여 Fargate 프로필을 생성하려면`eksctl`** 다음 `eksctl` 명령으로 Fargate 프로파일을 생성하고 모든 ``를 고유한 값으로 바꿉니다. 네임스페이스를 지정해야 합니다. 그러나 `--labels` 옵션은 필요하지 않습니다. ``` eksctl create fargateprofile \ --cluster \ --name \ --namespace \ --labels ``` `` 및 `` 레이블에 특정 와일드카드를 사용할 수 있습니다. 자세한 내용은 [Fargate 프로필 와일드카드](fargate-profile.md#fargate-profile-wildcards) 섹션을 참조하세요. ### AWS Management Console **을 사용하여 Fargate 프로필을 생성하려면AWS Management Console** 1. [Amazon EKS 콘솔](https://console.aws.amazon.com/eks/home#/clusters)을 엽니다. 1. Fargate 프로필을 생성할 클러스터를 선택합니다. 1. **컴퓨팅** 탭을 선택합니다. 1. **Fargate 프로필**에서 **Fargate 프로필 추가**를 선택합니다. 1. **Fargate 프로필 구성** 페이지에서 다음을 수행합니다. 1. **이름**에 Fargate 프로필의 이름을 입력합니다. 이름은 고유해야 합니다. 1. **포드 실행 역할**에서 Fargate 프로필과 함께 사용할 포드 실행 역할을 선택합니다. `eks-fargate-pods.amazonaws.com` 서비스 보안 주체가 있는 IAM 역할만 표시됩니다. 나열된 역할이 표시되지 않으면 역할을 만들어야 합니다. 자세한 내용은 [Amazon EKS 포드 실행 IAM 역할](pod-execution-role.md) 섹션을 참조하세요. 1. 선택한 **서브넷**을 필요에 따라 수정합니다. **참고** Fargate에서 실행되는 포드에는 프라이빗 서브넷만 지원됩니다. 1. **태그**의 경우, 선택적으로 Fargate 프로필에 태그를 지정할 수 있습니다. 이러한 태그는 프로필과 연결된 다른 리소스(예: 포드)에 전파되지 않습니다. 1. **다음**을 선택합니다. 1. **포드 선택 구성** 페이지에서 다음을 수행합니다. 1. **네임스페이스**에 포드에 대해 일치시킬 네임스페이스를 입력합니다. + `kube-system` 또는 `default`와 같은 특정 네임스페이스를 사용하여 일치시킬 수 있습니다. + 특정 와일드카드(예: `prod-*`)를 사용하여 여러 네임스페이스(예: `prod-deployment` 및 `prod-test`)를 일치시킬 수 있습니다. 자세한 내용은 [Fargate 프로필 와일드카드](fargate-profile.md#fargate-profile-wildcards) 섹션을 참조하세요. 1. (선택 사항) 선택기에 Kubernetes 레이블을 추가합니다. 특히 지정된 네임스페이스의 포드가 일치해야 하는 포드에 추가합니다. + `infrastructure: fargate` 레이블도 있는 지정된 네임스페이스의 포드만 선택기와 일치하도록 `infrastructure: fargate` Kubernetes 레이블을 선택기에 추가할 수 있습니다. + 특정 와일드카드(예: `key?: value?`)를 사용하여 여러 네임스페이스(예: `keya: valuea` 및 `keyb: valueb`)를 일치시킬 수 있습니다. 자세한 내용은 [Fargate 프로필 와일드카드](fargate-profile.md#fargate-profile-wildcards) 섹션을 참조하세요. 1. **다음**을 선택합니다. 1. **검토 및 생성** 페이지에서 Fargate 프로필에 대한 정보를 검토하고 **생성**을 선택합니다. ## 4단계: CoreDNS 업데이트 기본적으로 CoreDNS는 Amazon EKS 클러스터의 Amazon EC2 인프라에서 실행되도록 구성됩니다. 클러스터의 Fargate에서*만* 포드를 실행하려면 다음 단계를 수행하세요. **참고** `--fargate` 옵션을 사용하여 `eksctl`로 클러스터를 생성한 경우 [다음 단계](#fargate-gs-next-steps)로 건너뛸 수 있습니다. 1. 다음 명령을 사용하여 CoreDNS에 대한 Fargate 프로필을 삭제합니다. ``를 클러스터 이름으로, `<111122223333>`을 계정 ID로, ``을 포드 실행 역할 이름으로, `<000000000000000a>`, `<000000000000000b>`, `<000000000000000c>`를 프라이빗 서브넷의 ID로 바꿉니다. 포드 실행 역할이 없는 경우 먼저 생성해야 합니다([2단계: Fargate 포드 실행 역할 생성](#fargate-sg-pod-execution-role) 참조). **중요** 역할 ARN에 `/` 이외의 [경로](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_identifiers.html#identifiers-friendly-names)를 포함할 수 없습니다. 예를 들어, 역할 이름이 `development/apps/AmazonEKSFargatePodExecutionRole`인 경우 역할에 대한 ARN을 지정할 때 역할 이름을 `AmazonEKSFargatePodExecutionRole`로 변경해야 합니다. 역할 ARN의 형식은 ` arn:aws:iam::<111122223333>:role/`이어야 합니다. ``` aws eks create-fargate-profile \ --fargate-profile-name coredns \ --cluster-name \ --pod-execution-role-arn arn:aws:iam::<111122223333>:role/ \ --selectors namespace=kube-system,labels={k8s-app=kube-dns} \ --subnets subnet-<000000000000000a> subnet-<000000000000000b> subnet-<000000000000000c> ``` 1. `coredns` 배포의 롤아웃을 트리거합니다. ``` kubectl rollout restart -n kube-system deployment coredns ``` ## 다음 단계 + 다음 워크플로를 사용하여 Fargate에서 실행할 기존 애플리케이션 마이그레이션을 시작할 수 있습니다. 1. 애플리케이션의 Kubernetes 네임스페이스 및 Kubernetes 레이블과 일치하는 [Fargate 프로필 생성](fargate-profile.md#create-fargate-profile). 1. Fargate에 예약되도록 기존 포드를 삭제하고 다시 생성합니다. ``와 ``을 수정하여 특정 포드를 업데이트합니다. ``` kubectl rollout restart -n deployment ``` + [Application Load Balancer를 사용하여 애플리케이션 및 HTTP 트래픽 라우팅](alb-ingress.md)를 배포하여 Fargate에서 실행되는 포드에 대해 수신 객체를 허용합니다. + [Vertical Pod Autoscaler를 사용하여 포드 리소스 조정](vertical-pod-autoscaler.md)를 사용하여 Fargate 포드의 올바른 초기 CPU 및 메모리 크기를 설정한 다음 [Horizontal Pod Autoscaler를 사용하여 포드 배포 확장](horizontal-pod-autoscaler.md)를 사용하여 해당 포드의 규모를 조정할 수 있습니다. Vertical Pod Autoscaler가 더 높은 CPU 및 메모리 조합으로 포드를 Fargate에 자동으로 다시 배포하도록 하려면 Vertical Pod Autoscaler의 모드를 `Auto` 또는 `Recreate`로 설정합니다. 이를 통해 기능을 올바르게 사용할 수 있습니다. 자세한 내용은 GitHub에서 [Vertical Pod Autoscaler](https://github.com/kubernetes/autoscaler/tree/master/vertical-pod-autoscaler#quick-start) 문서를 참조하세요. + [이러한 지침](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/Container-Insights-EKS-otel.html)을 따라 애플리케이션을 모니터링하도록 [AWS Distro for OpenTelemetry(ADOT)](https://aws.amazon.com/otel) 컬렉터를 설정할 수 있습니다. # 시작 시 AWS Fargate를 사용하는 포드 정의 클러스터의 Fargate에 포드를 예약하기 전에 먼저 포드가 시작될 때 Fargate를 사용할 포드를 지정하는 Fargate 프로필을 하나 이상 정의해야 합니다. 관리자는 Fargate 프로필을 사용하여 Fargate에서 실행되는 포드를 선언할 수 있습니다. 프로필의 선택기를 통해 이 작업을 수행할 수 있습니다. 각 프로필에 최대 5개의 셀렉터를 추가할 수 있습니다. 각 셀렉터에 네임스페이스를 포함해야 합니다. 레이블도 셀렉터에 포함될 수 있습니다. 레이블 필드는 여러 개의 선택적 키-값 페어로 구성됩니다. 셀렉터와 일치하는 포드는 Fargate에 예약되어 있습니다. 포드는 선택기에 지정된 네임스페이스와 레이블을 사용하여 일치됩니다. 네임스페이스 선택기가 레이블 없이 정의되면 Amazon EKS는 프로필을 사용하여 해당 네임스페이스에서 실행되는 모든 포드를 Fargate에 예약하려고 시도합니다. 예약할 포드가 Fargate 프로필의 선택기와 일치하는 경우 해당 포드가 Fargate에 예약됩니다. 포드가 여러 Fargate 프로필과 일치하는 경우 포드 사양에 Kubernetes 레이블 `eks.amazonaws.com/fargate-profile: my-fargate-profile`을 추가하여 포드가 사용하는 프로필을 지정할 수 있습니다. 포드는 Fargate에 예약하기 위해 해당 프로필의 선택기와 일치해야 합니다. Kubernetes 선호도/반선호도 규칙은 Amazon EKS Fargate 포드에 적용되지 않으며 불필요합니다. Fargate 프로필을 생성할 때 포드 실행 역할을 지정해야 합니다. 이 실행 역할은 프로필을 사용하여 Fargate 인프라에서 실행되는 Amazon EKS 구성 요소를 위한 것입니다. 이 역할은 권한 부여를 위해 클러스터의 Kubernetes [역할 기반 액세스 컨트롤](https://kubernetes.io/docs/reference/access-authn-authz/rbac/)(RBAC)에 추가됩니다. 이렇게 하면 Fargate 인프라에서 실행되는 `kubelet`이 Amazon EKS 클러스터에 등록되어 클러스터에 노드로 표시될 수 있습니다. 또한 포드 실행 역할은 Amazon ECR 이미지 리포지토리에 대한 읽기 액세스를 허용하는 Fargate 인프라에 대한 IAM 권한을 제공합니다. 자세한 내용은 [Amazon EKS 포드 실행 IAM 역할](pod-execution-role.md) 단원을 참조하십시오. Fargate 프로필은 변경할 수 없습니다. 그러나 업데이트된 프로필을 새로 생성하여 기존 프로필을 바꾼 다음 원본을 삭제할 수 있습니다. **참고** Fargate 프로필을 사용하여 실행 중인 모든 포드는 중지되고 프로필이 삭제되면 보류 상태로 전환됩니다. 클러스터의 Fargate 프로필이 `DELETING` 상태인 경우 해당 클러스터에 다른 프로필을 생성하려면 Fargate 프로필이 삭제될 때까지 기다려야 합니다. **참고** Fargate는 현재 Kubernetes [topologySpreadConstraints](https://kubernetes.io/docs/concepts/scheduling-eviction/topology-spread-constraints/)를 지원하지 않습니다. Amazon EKS 및 Fargate는 Fargate 프로필에 정의된 각 서브넷에 포드를 분산시킵니다. 그러나 고르게 분산되지 않을 수 있습니다. 고른 분산이 필요한 경우 Fargate 프로필을 2개 사용합니다. 복제본을 2개 배포하려고 하고 가동 중지를 원하지 않는 경우 고른 분산이 중요합니다. 각 프로필에는 서브넷이 하나만 있는 것이 좋습니다. ## Fargate 프로필 구성 요소 다음 구성 요소는 Fargate 프로필에 포함되어 있습니다. **포드 실행 역할** 클러스터가 AWS Fargate에서 포드를 생성하면, Fargate 인프라에서 실행 중인 `kubelet`가 사용자를 대신하여 AWS API를 직접적으로 호출해야 합니다. 예를 들어, Amazon ECR에서 컨테이너 이미지를 가져오기 위해 호출해야 합니다. Amazon EKS 포드 실행 역할은 이 작업을 수행할 수 있는 IAM 권한을 제공합니다. Fargate 프로필을 생성할 때 포드와 함께 사용할 포드 실행 역할을 지정해야 합니다. 이 역할은 권한 부여를 위해 클러스터의 Kubernetes [역할 기반 액세스 제어](https://kubernetes.io/docs/reference/access-authn-authz/rbac/)(RBAC)에 추가됩니다. 이렇게 하면 Fargate 인프라에서 실행 중인 `kubelet`이 Amazon EKS 클러스터에 등록되어 클러스터에 노드로 표시될 수 있습니다. 자세한 내용은 [Amazon EKS 포드 실행 IAM 역할](pod-execution-role.md) 섹션을 참조하세요. **서브넷** 이 프로필을 사용하는 포드를 시작할 서브넷의 ID입니다. 현재 Fargate에서 실행 중인 포드에는 퍼블릭 IP 주소가 할당되지 않습니다. 따라서 이 파라미터에 대해서는 인터넷 게이트웨이로 가는 직접 경로가 없는 프라이빗 서브넷만 허용됩니다. **선택기** 포드가 이 Fargate 프로필을 사용하기 위해 일치시킬 선택기입니다. Fargate 프로필에 선택기를 최대 5개까지 지정할 수 있습니다. 셀렉터에는 다음 구성 요소가 있습니다. + **네임스페이스** - 셀렉터에 대한 네임스페이스를 지정해야 합니다. 선택기는 이 네임스페이스에서 생성된 포드만 일치시킵니다. 그러나 여러 셀렉터를 생성하여 여러 네임스페이스를 대상으로 지정할 수 있습니다. + **레이블** - 선택적으로 선택기에 대해 일치시킬 Kubernetes 레이블을 지정할 수 있습니다. 선택기는 선택기에 지정된 모든 레이블이 있는 포드만 일치시킵니다. ## Fargate 프로필 와일드카드 Kubernetes에서 허용하는 문자 외에도 네임스페이스, 레이블 키 및 레이블 값에 대한 선택기 기준에 `*`와 `?`를 사용할 수 있습니다. + `*`는 없음, 하나 또는 여러 문자를 나타냅니다. 예를 들어, `prod*`는 `prod`와 `prod-metrics`를 나타낼 수 있습니다. + `?`는 단일 문자를 나타냅니다. 예를 들어, `value?`는 `valuea`를 나타낼 수 있습니다. 그러나 `?`는 정확히 하나의 문자만 나타낼 수 있기 때문에 `value`와 `value-a`를 나타낼 수는 없습니다. 이러한 와일드카드 문자는 모든 위치에서 조합하여 사용할 수 있습니다(예: `prod*`, `*dev` 및 `frontend*?`). 다른 와일드카드와 패턴 일치 형식(정규식 등)은 지원되지 않습니다. 포드 사양의 네임스페이스 및 레이블에 대해 일치하는 프로필이 여러 개 있는 경우 Fargate는 프로필 이름별 영숫자 정렬을 기준으로 프로필을 선택합니다. 예를 들어, 프로필 A(이름 `beta-workload`)와 프로필 B(이름 `prod-workload`)에 시작할 포드에 대해 일치하는 선택기가 있는 경우 Fargate는 포드에 대해 프로필 A(`beta-workload`)를 선택합니다. 포드에 프로필 A라는 레이블이 있습니다(예: `eks.amazonaws.com/fargate-profile=beta-workload`). 와일드카드를 사용하는 새 프로필로 기존 Fargate 포드를 마이그레이션하려는 경우 다음 두 가지 방법이 있습니다. + 일치하는 셀렉터로 새 프로파일을 생성한 다음 이전 프로파일을 삭제합니다. 이전 프로필로 레이블이 지정된 포드는 일치하는 새 프로필로 다시 예약됩니다. + 워크로드를 마이그레이션하고 싶지만 각 Fargate 포드에 어떤 Fargate 레이블이 있는지 확실하지 않은 경우 다음 방법을 사용할 수 있습니다. 동일한 클러스터의 프로파일 중에서 영숫자순으로 먼저 정렬되는 이름으로 새 프로파일을 생성합니다. 그런 다음 새 프로필로 마이그레이션해야 하는 Fargate 포드를 재활용합니다. ## Fargate 프로필 생성 이 섹션에서는 Fargate 프로필을 생성하는 방법을 설명합니다. 또한 Fargate 프로필에 사용할 포드 실행 역할을 생성해야 합니다. 자세한 내용은 [Amazon EKS 포드 실행 IAM 역할](pod-execution-role.md) 단원을 참조하십시오. Fargate에서 실행되는 포드는 인터넷 게이트웨이에 대한 직접 경로가 없고 AWS 서비스에 대한 [NAT 게이트웨이](https://docs.aws.amazon.com/vpc/latest/userguide/vpc-nat-gateway.html) 액세스 권한이 있는 프라이빗 서브넷에서만 지원됩니다. 이를 위해서는 클러스터의 VPC에 사용 가능한 프라이빗 서브넷이 있어야 합니다. 다음을 사용하여 프로필을 만들 수 있습니다. + [`eksctl`](#eksctl_create_a_fargate_profile) + [AWS Management Console](#console_create_a_fargate_profile) ## `eksctl` **`eksctl`을 사용하여 Fargate 프로필을 생성하려면** 다음 `eksctl` 명령으로 Fargate 프로필을 생성하고 모든 예제 값을 고유한 값으로 바꿉니다. 네임스페이스를 지정해야 합니다. 그러나 `--labels` 옵션은 필요하지 않습니다. ``` eksctl create fargateprofile \ --cluster my-cluster \ --name my-fargate-profile \ --namespace my-kubernetes-namespace \ --labels key=value ``` `my-kubernetes-namespace` 및 `key=value` 레이블에 특정 와일드카드를 사용할 수 있습니다. 자세한 내용은 [Fargate 프로필 와일드카드](#fargate-profile-wildcards) 단원을 참조하십시오. ## AWS Management Console **AWS Management Console을 사용하여 Fargate 프로필을 생성하려면** 1. [Amazon EKS 콘솔](https://console.aws.amazon.com/eks/home#/clusters)을 엽니다. 1. Fargate 프로필을 생성할 클러스터를 선택합니다. 1. **컴퓨팅** 탭을 선택합니다. 1. **Fargate 프로필**에서 **Fargate 프로필 추가**를 선택합니다. 1. **Fargate 프로파일 구성(Configure Fargate profile)** 페이지에서 다음을 수행합니다. 1. **이름(Name)**에 Fargate 프로파일(예: `my-profile`)의 고유한 이름을 입력합니다. 1. **포드 실행 역할**에서 Fargate 프로필과 함께 사용할 포드 실행 역할을 선택합니다. `eks-fargate-pods.amazonaws.com` 서비스 보안 주체가 있는 IAM 역할만 표시됩니다. 나열된 역할이 표시되지 않으면 역할을 만들어야 합니다. 자세한 내용은 [Amazon EKS 포드 실행 IAM 역할](pod-execution-role.md) 섹션을 참조하세요. 1. 선택한 **서브넷**을 필요에 따라 수정합니다. **참고** Fargate에서 실행되는 포드에는 프라이빗 서브넷만 지원됩니다. 1. **태그**의 경우, 선택적으로 Fargate 프로필에 태그를 지정할 수 있습니다. 이러한 태그는 프로필과 연결된 다른 리소스(예: 포드)에 전파되지 않습니다. 1. **Next**(다음)를 선택합니다. 1. **포드 선택 구성** 페이지에서 다음을 수행합니다. 1. **네임스페이스**에 포드에 대해 일치시킬 네임스페이스를 입력합니다. + `kube-system` 또는 `default`와 같은 특정 네임스페이스를 사용하여 일치시킬 수 있습니다. + 특정 와일드카드(예: `prod-*`)를 사용하여 여러 네임스페이스(예: `prod-deployment` 및 `prod-test`)를 일치시킬 수 있습니다. 자세한 내용은 [Fargate 프로필 와일드카드](#fargate-profile-wildcards) 단원을 참조하십시오. 1. (선택 사항) 선택기에 Kubernetes 레이블을 추가합니다. 특히 지정된 네임스페이스의 포드가 일치해야 하는 포드에 추가합니다. + `infrastructure: fargate` 레이블도 있는 지정된 네임스페이스의 포드만 선택기와 일치하도록 `infrastructure: fargate` Kubernetes 레이블을 선택기에 추가할 수 있습니다. + 특정 와일드카드(예: `key?: value?`)를 사용하여 여러 네임스페이스(예: `keya: valuea` 및 `keyb: valueb`)를 일치시킬 수 있습니다. 자세한 내용은 [Fargate 프로필 와일드카드](#fargate-profile-wildcards) 섹션을 참조하세요. 1. **다음**을 선택합니다. 1. **검토 및 생성** 페이지에서 Fargate 프로필에 대한 정보를 검토하고 **생성**을 선택합니다. # Fargate 프로필 삭제 이 주제에서는 Fargate 프로필을 삭제하는 방법을 설명합니다. Fargate 프로필을 삭제하면 해당 프로필을 사용하여 Fargate에 예약된 모든 포드가 삭제됩니다. 이러한 포드가 다른 Fargate 프로필과 일치하면 해당 프로필을 사용하여 Fargate에 예약됩니다. Fargate 프로필과 더이상 일치하지 않으면 Fargate에 예약되지 않고 보류 상태로 남아있을 수 있습니다. 클러스터의 Fargate 프로필은 한 번에 하나만 `DELETING` 상태가 될 수 있습니다. Fargate 프로필이 삭제될 때까지 기다려야 해당 클러스터에서 다른 프로필을 삭제할 수 있습니다. 다음 도구 중 하나를 사용하여 프로필을 삭제할 수 있습니다. + [`eksctl`](#eksctl_delete_a_fargate_profile) + [AWS Management Console](#console_delete_a_fargate_profile) + [AWS CLI](#awscli_delete_a_fargate_profile) ## `eksctl` **`eksctl`를 사용하여 Fargate 프로필 삭제** 다음 명령을 사용하여 클러스터에서 프로필을 삭제합니다. 모든 *예제 값*을 자신의 값으로 바꾸세요. ``` eksctl delete fargateprofile --name my-profile --cluster my-cluster ``` ## AWS Management Console **AWS Management Console를 사용하여 Fargate 프로필 삭제** 1. [Amazon EKS 콘솔](https://console.aws.amazon.com/eks/home#/clusters)을 엽니다. 1. 좌측 탐색 창에서 **클러스터**를 선택합니다. 목록 클러스터에서 Fargate 프로필을 삭제할 클러스터를 선택합니다. 1. **컴퓨팅** 탭을 선택합니다. 1. 삭제할 Fargate 프로필을 선택한 다음 **삭제**를 선택합니다. 1. **Fargate 프로필 삭제** 페이지에서 프로필 이름을 입력한 다음 **삭제**를 선택합니다. ## AWS CLI **AWS CLI를 사용하여 Fargate 프로필 삭제** 다음 명령을 사용하여 클러스터에서 프로필을 삭제합니다. 모든 *예제 값*을 자신의 값으로 바꾸세요. ``` aws eks delete-fargate-profile --fargate-profile-name my-profile --cluster-name my-cluster ``` # Fargate 포드 구성 세부 정보 이해 이 섹션에서는 AWS Fargate에서 Kubernetes 포드를 실행하기 위한 몇 가지 고유한 포드 구성 세부 정보에 대해 설명합니다. ## 포드 CPU 및 메모리 Kubernetes를 사용하면 포드의 각 컨테이너에 할당되는 요청, 즉 최소량의 vCPU 및 메모리 리소스를 정의할 수 있습니다. 최소한 각 포드에 대해 요청된 리소스를 컴퓨팅 리소스에서 사용할 수 있도록 Kubernetes에서 포드를 예약합니다. 자세한 내용은 Kubernetes 설명서의 [컨테이너의 컴퓨팅 리소스 관리](https://kubernetes.io/docs/concepts/configuration/manage-compute-resources-container/)를 참조하십시오. **참고** Amazon EKS Fargate는 노드당 하나의 포드만 실행하므로 리소스가 더 적은 경우 포드를 제거하는 시나리오가 발생하지 않습니다. 모든 Amazon EKS Fargate 포드는 보장된 우선순위로 실행되므로 요청된 CPU와 메모리는 모든 컨테이너의 한도와 같아야 합니다. 자세한 내용은 쿠버네티스 문서의 [Configure Quality of Service for Pods](https://kubernetes.io/docs/tasks/configure-pod-container/quality-service-pod/)를 참조하세요. 포드가 Fargate에 예약되면 포드 사양 내의 vCPU 및 메모리 예약에 따라 포드에 프로비저닝할 CPU 및 메모리 양이 결정됩니다. + Init 컨테이너의 최대 요청은 Init 요청 vCPU 및 메모리 요구 사항을 결정하는 데 사용됩니다. + 장기 실행 요청 vCPU 및 메모리 요구 사항을 결정하기 위해 모든 장기 실행 컨테이너에 대한 요청이 추가됩니다. + 포드에 사용할 vCPU 및 메모리 요청에 대해서는 이전의 두 값 중 큰 값이 선택됩니다. + Fargate는 필요한 Kubernetes 구성 요소(`kubelet`, `kube-proxy` 및 `containerd`)에 대한 각 포드의 메모리 예약에 256MB를 추가합니다. Fargate는 포드가 실행해야 하는 리소스를 항상 보유하도록 vCPU 및 메모리 요청의 합계와 가장 일치하는 다음의 컴퓨팅 구성으로 올림 처리합니다. vCPU 및 메모리 조합을 지정하지 않으면 사용 가능한 가장 작은 조합(.25 vCPU 및 0.5GB 메모리)이 사용됩니다. 아래 표에는 Fargate에서 실행되는 포드에 사용할 수 있는 vCPU 및 메모리 조합이 나와 있습니다. | vCPU 값 | 메모리 값 | | --- | --- | | .25 vCPU | 0.5GB, 1GB, 2GB | | .5 vCPU | 1GB, 2GB, 3GB, 4GB | | 1 vCPU | 2GB, 3GB, 4GB, 5GB, 6GB, 7GB, 8GB | | 2 vCPU | 4\$116GB(1GB 증분) | | 4 vCPU | 8\$130GB(1GB 증분) | | 8 vCPU | 16\$160GB(4GB 단위) | | 16 vCPU | 32\$1120GB(8GB 단위) | Kubernetes 구성 요소에 예약된 추가 메모리로 인해 요청된 것보다 많은 vCPU를 사용하는 Fargate 태스크가 프로비저닝될 수 있습니다. 예를 들어 1개의 vCPU 및 8GB 메모리에 대한 요청의 경우 해당 메모리 요청에 256MB가 추가되며, vCPU 1개와 9GB 메모리를 사용하는 태스크가 없으므로 2개의 vCPU 및 9GB 메모리로 Fargate 태스크를 프로비저닝합니다. Fargate에서 실행 중인 포드의 크기와 `kubectl get nodes`를 사용하여 Kubernetes가 보고하는 노드 크기 사이에는 상관 관계가 없습니다. 보고된 노드 크기는 대개 포드의 용량보다 큽니다. 다음 명령을 사용하여 포드 용량을 확인할 수 있습니다. *default*를 포드의 네임스페이스로, *pod-name*을 포드의 이름으로 바꿉니다. ``` kubectl describe pod --namespace default pod-name ``` 예제 출력은 다음과 같습니다. ``` [...] annotations: CapacityProvisioned: 0.25vCPU 0.5GB [...] ``` `CapacityProvisioned` 주석은 적용된 포드 용량을 나타내며 Fargate에서 실행되는 포드의 비용을 결정합니다. 이러한 컴퓨팅 구성에 대한 요금 정보는 [AWS Fargate 요금](https://aws.amazon.com/fargate/pricing/)을 참조하세요. ## Fargate 스토리지 Fargate에서 실행되는 포드는 수동 드라이버 설치 단계 없이 Amazon EFS 파일 시스템을 자동으로 탑재합니다. Fargate 노드에는 동적 영구 볼륨 프로비저닝을 사용할 수 없지만 고정적인 프로비저닝은 사용할 수 있습니다. 자세한 내용은 GitHub에서 [Amazon EFS CSI 드라이버](https://github.com/kubernetes-sigs/aws-efs-csi-driver/blob/master/docs/README.md)를 참조하세요. 프로비저닝이 완료되면 Fargate에서 실행되는 각 포드는 기본적으로 20GiB의 임시 스토리지를 받습니다. 이 유형의 스토리지는 포드가 중지된 후에 삭제됩니다. Fargate에서 시작된 새 포드에는 임시 스토리지 볼륨의 암호화가 기본적으로 활성화되어 있습니다. 임시 포드 스토리지는 AWS Fargate 관리형 키를 사용하여 AES-256 암호화 알고리즘으로 암호화됩니다. **참고** Fargate에서 실행되는 Amazon EKS 포드의 기본 가용 스토리지는 20GiB 미만입니다. 이는 일부 공간을 `kubelet` 및 포드 내부에 로드되는 기타 Kubernetes 모듈에서 사용하기 때문입니다. 임시 스토리지의 총량은 최대 175GiB까지 높일 수 있습니다. Kubernetes를 사용하여 크기를 구성하려면 포드의 각 컨테이너에 대한 `ephemeral-storage` 리소스 요청을 지정합니다. Kubernetes 가 포드를 예약할 때 이는 각 포드에 대한 리소스 요청의 합계가 Fargate 태스크의 용량보다 작도록 보장합니다. 자세한 내용은 쿠버네티스 문서의 [포드 및 컨테이너 리소스 관리](https://kubernetes.io/docs/concepts/configuration/manage-compute-resources-container/)를 참조하세요. Amazon EKS Fargate는 시스템 사용 목적으로 요청한 것보다 더 많은 임시 스토리지를 프로비저닝합니다. 예를 들어, 100GiB를 요청하면 Fargate 작업에 115GiB의 임시 스토리지가 프로비저닝됩니다. # AWS Fargate OS 패치 이벤트에 대한 작업 설정 Amazon EKS는 AWSFargate 노드의 OS를 주기적으로 패치하여 보안을 유지합니다. 패치 적용 프로세스의 일부로 노드를 재활용하여 OS 패치를 설치합니다. 서비스에 미치는 영향이 가장 적은 방식으로 업데이트가 시도됩니다. 그러나 포드가 성공적으로 제거되지 않으면 포드를 삭제해야 할 때가 있습니다. 다음 작업은 중단 가능성을 최소화하기 위해 수행할 수 있는 작업입니다. + 적절한 포드 중단 예산(PDB)을 설정하여 동시에 중단되는 포드의 수를 제어한다. + 포드가 삭제되기 전에 실패한 제거를 처리하는 Amazon EventBridge 규칙을 생성합니다. + 수신한 알림에 게시된 제거 날짜 이전에 영향을 받는 포드를 수동으로 다시 시작합니다. + AWS 사용자 알림에서 알림 구성을 생성합니다. Amazon EKS는 Kubernetes 커뮤니티와 밀접하게 협력하여 버그 수정 및 보안 패치를 최대한 빨리 사용할 수 있도록 합니다. 모든 Fargate 포드는 Kubernetes 패치의 최신 버전에서 시작됩니다. 이 버전은 클러스터의 Kubernetes 버전에 대한 Amazon EKS에서 사용할 수 있습니다. 이전 패치 버전의 포드가 있는 경우 Amazon EKS는 해당 포드를 재활용하여 최신 버전으로 업데이트할 수 있습니다. 이렇게 하면 포드에 최신 보안 업데이트가 설치됩니다. 그렇게 하면 중요한 [일반 취약성 및 노출](https://cve.mitre.org/)(CVE) 문제가 있는 경우, 최신 상태로 유지되어 보안 위험을 줄여줍니다. AWS Fargate OS가 업데이트되면 Amazon EKS가 영향을 받는 리소스와 향후 포드 제거 날짜가 포함된 알림을 보냅니다. 제공된 제거 날짜가 불편한 경우 알림에 게시된 제거 날짜 이전에 영향을 받는 포드를 수동으로 다시 시작할 수 있습니다. 알림을 수신하기 전에 생성한 모든 포드는 제거 대상입니다. 포드를 수동으로 다시 시작하는 방법에 대한 자세한 지침은 [Kubernetes 설명서](https://kubernetes.io/docs/reference/kubectl/generated/kubectl_rollout/kubectl_rollout_restart)를 참조하세요. 포드를 재활용할 때 한 번에 중단되는 포드 수를 제한하려면 포드 중단 예산(PDB)을 설정할 수 있습니다. PDB를 사용하여 각 애플리케이션의 요구 사항에 따라 최소 가용성을 정의하면서 계속 업데이트도 할 수 있습니다. PDB의 최소 가용성은 100% 미만이어야 합니다. 자세한 내용은 Kubernetes Documentation의 [Specifying a Disruption Budget for your Application](https://kubernetes.io/docs/tasks/run-application/configure-pdb/)을 참조하세요. Amazon EKS가 [제거 API](https://kubernetes.io/docs/tasks/administer-cluster/safely-drain-node/#eviction-api)를 사용하여 애플리케이션에 대해 설정한 PDB를 준수하면서 포드를 안전하게 드레이닝합니다. 가용 영역에서 포드를 제거하여 영향을 최소화합니다. 제거가 성공하면 새 포드가 최신 패치를 받아 추가 작업이 필요하지 않습니다. 포드의 제거가 실패하면 Amazon EKS는 제거에 실패한 포드에 대한 세부 정보와 함께 이벤트를 계정에 전송합니다. 예약된 종료 시간 전에는 메시지에서 작업할 수 있습니다. 특정 시간은 패치의 긴급성에 따라 다릅니다. 시간이 되면 Amazon EKS는 포드를 다시 제거하려고 시도합니다. 그러나 이번에는 제거가 실패하면 새 이벤트가 전송되지 않습니다. 제거가 다시 실패하면 새 포드가 최신 패치를 받을 수 있도록 기존 포드가 정기적으로 삭제됩니다. 다음 이벤트는 포드 제거가 실패할 때 수신되는 샘플 이벤트입니다. 여기에는 클러스터, 포드 이름, 포드 네임스페이스, Fargate 프로필 및 예약된 종료 시간에 대한 세부 정보가 포함되어 있습니다. ``` { "version": "0", "id": "12345678-90ab-cdef-0123-4567890abcde", "detail-type": "EKS Fargate Pod Scheduled Termination", "source": "aws.eks", "account": "111122223333", "time": "2021-06-27T12:52:44Z", "region": "region-code", "resources": [ "default/my-database-deployment" ], "detail": { "clusterName": "my-cluster", "fargateProfileName": "my-fargate-profile", "podName": "my-pod-name", "podNamespace": "default", "evictErrorMessage": "Cannot evict pod as it would violate the pod's disruption budget", "scheduledTerminationTime": "2021-06-30T12:52:44.832Z[UTC]" } } ``` 또한 여러 PDB가 포드에 연결되어 있으면 제거 실패 이벤트가 발생할 수 있습니다. 이 이벤트는 다음과 같은 오류 메시지를 반환합니다. ``` "evictErrorMessage": "This pod has multiple PodDisruptionBudget, which the eviction subresource does not support", ``` 이 이벤트를 기반으로 원하는 작업을 생성할 수 있습니다. 예를 들어 포드 중단 예산(PDB)을 조정하여 포드가 제거되는 방식을 제어할 수 있습니다. 조금 더 구체적으로, 사용 가능한 포드의 대상 백분율을 지정하는 PDB로 시작한다고 가정합니다. 업그레이드 중에 포드가 강제 종료되기 전에 PDB를 다른 백분율의 포드로 조정할 수 있습니다. 이 이벤트를 수신하려면 클러스터가 속한 AWS 계정 및 AWS 리전에서 Amazon EventBridge 규칙을 생성해야 합니다. 규칙은 다음과 같은 **사용자 지정 패턴**을 사용해야 합니다. 자세한 내용을 알아보려면 *Amazon EventBridge 사용 설명서*의 [이벤트에 응답하는 Amazon EventBridge 규칙 생성](https://docs.aws.amazon.com/eventbridge/latest/userguide/eb-create-rule.html)을 참조하세요. ``` { "source": ["aws.eks"], "detail-type": ["EKS Fargate Pod Scheduled Termination"] } ``` 이벤트를 캡처하기 위해 적합한 대상을 설정할 수 있습니다. 사용 가능한 대상의 전체 목록은 *Amazon EventBridge 사용 설명서*의 [Amazon EventBridge 대상](https://docs.aws.amazon.com/eventbridge/latest/userguide/eb-targets.html)을 참조하세요. AWS 사용자 알림에서 알림 구성을 생성할 수도 있습니다. AWS Management Console를 사용하여 알림을 생성할 때, **이벤트 규칙**에서 **AWS 서비스 이름**에 **Elastic Kubernetes Service(EKS)**를 선택하고 **이벤트 유형**에 **EKS Fargate 포드 예약 종료**를 선택합니다. 자세한 내용은 AWS User Notifications User Guide의 [Getting started with AWS User Notifications](https://docs.aws.amazon.com/notifications/latest/userguide/getting-started.html)를 참조하세요. EKS 포드 제거와 관련하여 자주 묻는 질문은 * AWS re:Post*의 [FAQ: Fargate 포드 제거 공지](https://repost.aws/knowledge-center/fargate-pod-eviction-notice)를 참조하세요. # AWS Fargate 앱 및 사용량 지표 수집 시스템 지표 및 AWS Fargate의 CloudWatch 사용량 지표를 수집할 수 있습니다. ## 애플리케이션 지표 Amazon EKS 및 AWS Fargate에서 실행되는 애플리케이션의 경우 AWS Distro for OpenTelemetry(ADOT)를 사용할 수 있습니다. ADOT를 사용하면 시스템 지표를 수집하여 CloudWatch 컨테이너 인사이트 대시보드로 전송할 수 있습니다. Fargate에서 실행되는 애플리케이션용 ADOT로 시작하려면 ADOT 설명서의 [AWS Distro for OpenTelemetry를 통한 CloudWatch 컨테이너 인사이트 사용](https://aws-otel.github.io/docs/getting-started/container-insights)을 참조하세요. ## 사용량 지표 CloudWatch 사용량 지표를 사용하여 계정의 리소스 사용량을 확인할 수 있습니다. 이러한 지표를 사용하여 CloudWatch 그래프 및 대시보드에서 현재 서비스 사용량을 시각화합니다. AWS Fargate 사용량 지표는 AWS 서비스 할당량에 해당합니다. 사용량이 서비스 할당량에 가까워지면 경고하는 경보를 구성할 수 있습니다. Fargate 서비스 할당량에 대한 자세한 정보는 [Amazon EKS 및 Fargate Service Quotas 보기 및 관리](service-quotas.md) 섹션을 참조하세요. AWS Fargate는 ` AWS/Usage` 네임스페이스에 다음 지표를 게시합니다. | 지표 | 설명 | | --- | --- | | `ResourceCount` | 계정에서 실행 중인 지정된 리소스의 총 수입니다. 리소스는 지표와 연결된 차원으로 정의됩니다. | 다음 차원은 AWS Fargate에 의해 게시되는 사용량 지표를 구체화하는 데 사용됩니다. | 차원 | 설명 | | --- | --- | | `Service` | 리소스가 포함된 AWS 서비스의 이름 AWS Fargate 사용량 지표의 경우 이 차원 값은 `Fargate`입니다. | | `Type` | 보고되는 엔터티의 유형입니다. 현재 AWS Fargate 사용량 지표에 대한 유일한 유효 값은 `Resource`입니다. | | `Resource` | 실행 중인 리소스의 유형입니다. 현재 AWS Fargate 는 Fargate 온디맨드 사용량에 대한 정보를 반환합니다. Fargate 온디맨드 사용량에 대한 리소스 값은 `OnDemand`입니다. [참고] ==== Fargate 온디맨드 사용량은 Fargate를 사용하는 Amazon EKS 포드, Fargate 시작 유형을 사용하는 Amazon ECS 태스크 및 `FARGATE` 용량 제공업체를 사용하는 Amazon ECS가 합쳐진 값입니다. ==== | | `Class` | 추적 중인 리소스의 클래스입니다. 현재 AWS Fargate에서는 클래스 차원을 사용하지 않습니다. | ### Fargate 리소스 사용량 지표 모니터링을 위한 CloudWatch 경보 생성 AWS Fargate는 Fargate 온디맨드 리소스 사용량에 대한 AWS 서비스 할당량에 해당하는 CloudWatch 사용량 지표를 제공합니다. Service Quotas 콘솔에서 사용량을 그래프로 시각화할 수 있습니다. 사용량이 서비스 할당량에 가까워지면 경고하는 경보를 구성할 수도 있습니다. 자세한 내용은 [AWS Fargate 앱 및 사용량 지표 수집](#monitoring-fargate-usage) 섹션을 참조하세요. 다음 단계를 사용하여 Fargate 리소스 사용량 지표에 기반하여 CloudWatch 경보를 생성합니다. 1. https://console.aws.amazon.com/servicequotas/에서 Service Quotas 콘솔을 엽니다. 1. 왼쪽 탐색 창에서 **AWS 서비스**를 선택합니다. 1. **AWS 서비스** 목록에서 ** AWS Fargate**를 검색하여 선택합니다. 1. **Service quotas** 목록에서 경보를 만들려는 Fargate 사용량 할당량을 선택합니다. 1. Amazon CloudWatch 경보 섹션에서 **생성**을 선택합니다. 1. **경보 임계값**에서 경보 값으로 설정할 적용된 할당량 값의 백분율을 선택합니다. 1. **경보 이름**에서 경보 이름을 입력한 다음 **생성**을 선택합니다. # 클러스터에 대한 AWS Fargate 로깅 시작하기 Amazon EKS on Fargate는 Fluent Bit를 기반으로 내장된 로그 라우터를 제공합니다. 즉, 사용자가 Fluent Bit 컨테이너를 사이드카로 명시적으로 실행하지는 않지만 Amazon이 자동으로 실행합니다. 로그 라우터를 구성하기만 하면 됩니다. 이 구성은 다음 기준을 충족해야 하는 전용 `ConfigMap`을 통해 이루어집니다. + `aws-logging`으로 이름 지정 + `aws-observability`라는 전용 네임스페이스에서 생성 + 5300자를 초과할 수 없습니다. `ConfigMap`을 생성하고 나면 Fargate의 Amazon EKS가 자동으로 감지하고 로그 라우터를 구성합니다. Fargate는 AWS for Fluent Bit의 한 버전인 AWS 관리형 Fluent Bit의 업스트림 호환 배포판을 사용합니다. 자세한 내용은 GitHub에서 [AWS for Fluent Bit](https://github.com/aws/aws-for-fluent-bit)를 참조하세요. 로그 라우터를 사용하면 AWS에서 로그 분석 및 저장을 위한 다양한 서비스를 사용할 수 있습니다. Fargate에서 Amazon CloudWatch, Amazon OpenSearch Service로 로그를 직접 스트리밍할 수 있습니다. [Amazon S3](https://aws.amazon.com/s3/), [Amazon Kinesis Data Streams](https://aws.amazon.com/kinesis/data-streams/), [Amazon Data Firehose](https://aws.amazon.com/kinesis/data-firehose/)를 통한 파트너 도구 등의 대상으로 로그를 스트리밍할 수도 있습니다. + Fargate 포드를 배포할 기존 Kubernetes 네임스페이스를 지정하는 기존 Fargate 프로필. 자세한 내용은 [3단계: 클러스터에 대한 Fargate 프로필 생성](fargate-getting-started.md#fargate-gs-create-profile) 섹션을 참조하세요. + 기존 Fargate 포드 실행 역할. 자세한 내용은 [2단계: Fargate 포드 실행 역할 생성](fargate-getting-started.md#fargate-sg-pod-execution-role) 섹션을 참조하세요. ## 로그 라우터 구성 **중요** 로그가 성공적으로 게시되려면 클러스터가 있는 VPC에서 로그 대상으로 네트워크 액세스가 있어야 합니다. 이는 주로 VPC에 대한 송신 규칙을 사용자 지정하는 사용자와 관련이 있습니다. CloudWatch를 사용하는 예제는 *Amazon CloudWatch Logs 사용 설명서*의 [인터페이스 VPC 엔드포인트에서 CloudWatch Logs 사용](https://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/cloudwatch-logs-and-interface-VPC.html)을 참조하세요. 다음 단계에서 모든 *예제 값*을 고유한 값으로 바꿉니다. 1. `aws-observability`라는 전용 Kubernetes 네임스페이스를 생성합니다. 1. 다음 콘텐츠를 컴퓨터에 `aws-observability-namespace.yaml`이라는 파일에 저장합니다. `name`의 값은 `aws-observability`여야 하며 `aws-observability: enabled` 레이블이 필요합니다. ``` kind: Namespace apiVersion: v1 metadata: name: aws-observability labels: aws-observability: enabled ``` 1. 네임스페이스를 생성합니다. ``` kubectl apply -f aws-observability-namespace.yaml ``` 1. `Fluent Conf` 데이터 값을 사용하여 `ConfigMap`을 생성함으로써 컨테이너 로그를 대상에 전달합니다. Fluent Conf는 Fluent Bit입니다. 이는 원하는 로그 대상에 컨테이너 로그를 라우팅하는 데 사용되는 빠르고 가벼운 로그 프로세서 구성 언어입니다. 자세한 내용은 Fluent Bit 문서의 [구성 파일(Configuration File)](https://docs.fluentbit.io/manual/administration/configuring-fluent-bit/classic-mode/configuration-file)을 참조하세요. **중요** 일반적인 `Fluent Conf`에 포함된 주요 단원은 `Service`, `Input`, `Filter`, `Output`입니다. 하지만 Fargate 로그 라우터는 다음 부분만 수락합니다. `Filter` 및`Output` 부분입니다. `Parser` 부분. 기타 부분을 제공하는 경우 해당 부분은 거부됩니다. Fargate 로그 라우터에서는 `Service` 및`Input` 부분을 관리합니다. 여기에는 수정할 수 없고 `ConfigMap`에서 필요하지 않은 다음과 같은 `Input` 부분이 있습니다. 그러나 메모리 버퍼 제한과 로그에 적용된 태그와 같은 인사이트를 얻을 수 있습니다. ``` [INPUT] Name tail Buffer_Max_Size 66KB DB /var/log/flb_kube.db Mem_Buf_Limit 45MB Path /var/log/containers/*.log Read_From_Head On Refresh_Interval 10 Rotate_Wait 30 Skip_Long_Lines On Tag kube.* ``` `ConfigMap` 생성 시에는 Fargate가 필드를 검증하는 데 사용하는 다음 규칙을 고려하세요. + `[FILTER]`, `[OUTPUT]`, `[PARSER]`는 각 해당 키 아래에 지정되어야 합니다. 예를 들어, `filters.conf`은 `[FILTER]`에 있어야 합니다. `filters.conf`에 하나 이상의 `[FILTER]`가 있을 수 있습니다. `[OUTPUT]` 및 `[PARSER]` 부분도 해당 키 아래에 있어야 합니다. 여러 개의 `[OUTPUT]` 부분을 지정하여 로그를 여러 대상으로 동시에 라우팅할 수 있습니다. + Fargate는 각 섹션에 필요한 키를 검증합니다 `Name` 및 `match`는 `[FILTER]` 및 `[OUTPUT]`에 각각 필요합니다. `Name` 및 `format`은 `[PARSER]`에 각각 필요합니다. 태그는 대/소문자를 구분합니다. + `${ENV_VAR}`과 같은 환경 변수는 `ConfigMap`에서 허용되지 않습니다. + 들여쓰기는 각 `filters.conf`, `output.conf`, `parsers.conf` 내의 지시문 또는 키 값 페어에 대해 동일해야합니다. 키 값 페어는 지시문보다 들여 써야 합니다. + Fargate는 `grep`, `parser`, `record_modifier`, `rewrite_tag`, `throttle`, `nest`, `modify`, `kubernetes` 등의 지원 필터에 대해 검증을 실시합니다. + Fargate는 다음과 같은 지원되는 출력에 대해 검증합니다. `es`, `firehose`, `kinesis_firehose`, `cloudwatch`, `cloudwatch_logs` 및 `kinesis`. + 로깅을 사용 설정하려면 `ConfigMap`에서 지원되는 `Output` 플러그 인이 1개 이상 제공되어야 합니다. `Filter` 및 `Parser`는 로깅을 사용 설정하는 데 필요하지 않습니다. 검증에서 발생하는 문제를 해결하기 위해 원하는 구성을 사용하여 Amazon EC2 Fluent Bit를 실행할 수 있습니다. 다음 예 중 하나를 사용하여 `ConfigMap`을 생성합니다. **중요** Amazon EKS Fargate 로깅은 `ConfigMap`의 동적 구성을 지원하지 않습니다. `ConfigMap`에 대한 모든 변경 사항은 새 포드에만 적용됩니다. 기존 포드에는 변경 사항이 적용되지 않습니다. 원하는 로그 대상에 대한 예제를 사용하여 `ConfigMap`을 생성합니다. **참고** 로그 대상에 Amazon Kinesis Data Streams를 사용할 수도 있습니다. Kinesis Data Streams를 사용하는 경우 포드 실행 역할에 `kinesis:PutRecords` 권한이 부여되었는지 확인하세요. 자세한 내용은 *Fluent Bit: 공식 설명서*의 Amazon Kinesis Data Streams [권한](https://docs.fluentbit.io/manual/pipeline/outputs/kinesis#permissions)을 참조하세요. **Example** ------ #### [ CloudWatch ] CloudWatch를 사용할 때는 다음 두 가지 출력 옵션이 있습니다. + [C로 작성된 출력 플러그 인](https://docs.fluentbit.io/manual/v/1.5/pipeline/outputs/cloudwatch) + [Golang으로 작성된 출력 플러그 인](https://github.com/aws/amazon-cloudwatch-logs-for-fluent-bit) 다음 예에서는 `cloudwatch_logs` 플러그 인을 사용하여 CloudWatch로 로그를 전송하는 방법을 보여줍니다. 1. 다음 콘텐츠를 `aws-logging-cloudwatch-configmap.yaml`이라는 파일에 저장합니다. *region-code*를 클러스터가 있는 AWS 리전으로 바꿉니다. `[OUTPUT]` 아래의 파라미터는 필수입니다. ``` kind: ConfigMap apiVersion: v1 metadata: name: aws-logging namespace: aws-observability data: flb_log_cw: "false" # Set to true to ship Fluent Bit process logs to CloudWatch. filters.conf: | [FILTER] Name parser Match * Key_name log Parser crio [FILTER] Name kubernetes Match kube.* Merge_Log On Keep_Log Off Buffer_Size 0 Kube_Meta_Cache_TTL 300s output.conf: | [OUTPUT] Name cloudwatch_logs Match kube.* region region-code log_group_name my-logs log_stream_prefix from-fluent-bit- log_retention_days 60 auto_create_group true parsers.conf: | [PARSER] Name crio Format Regex Regex ^(?