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