**이 페이지 개선에 도움 주기** 이 사용자 가이드에 기여하려면 모든 페이지의 오른쪽 창에 있는 **GitHub에서 이 페이지 편집** 링크를 선택합니다. # 자체 관리형 노드로 노드 직접 유지 클러스터에는 포드가 예약된 하나 이상의 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) 섹션을 참조하세요.