자체 관리형 Amazon Linux 노드 생성

Amazon EKS 클러스터에 등록되는 Amazon Linux 노드의 Auto Scaling 그룹을 시작하는 방법을 설명합니다.

출처: 문서

본문

이 주제는 Amazon EKS 클러스터에 등록되는 Linux 노드의 Auto Scaling 그룹을 시작하는 방법을 설명합니다. 노드가 클러스터에 가입한 후 Kubernetes 애플리케이션을 배포할 수 있습니다. eksctl 또는 AWS Management Console로 자체 관리형 Amazon Linux 노드를 시작할 수도 있습니다. AWS Outposts에서 노드를 시작해야 한다면 "AWS Outposts에서 Amazon Linux 노드 생성"을 참고하세요.

전제 조건

기존 Amazon EKS 클러스터. 배포하려면 "Amazon EKS 클러스터 생성"을 참고하세요. AWS Outposts, AWS Wavelength 또는 AWS Local Zones가 활성화된 AWS 리전에 서브넷이 있다면, 클러스터를 만들 때 해당 서브넷을 전달하지 않았어야 합니다.
노드가 사용할 기존 IAM 역할. 생성하려면 "Amazon EKS 노드 IAM 역할"을 참고하세요. 이 역할에 VPC CNI 정책이 둘 다 없으면 VPC CNI Pod에는 다음의 별도 역할이 필요합니다.
(선택 사항이지만 권장) 자체 IAM 역할이 있고 필요한 IAM 정책이 연결된 Amazon VPC CNI plugin for Kubernetes 애드온. 자세한 내용은 "IRSA를 사용하도록 Amazon VPC CNI 플러그인 구성"을 참고하세요.
"최적의 Amazon EC2 노드 인스턴스 유형 선택"에 나열된 고려 사항에 대한 이해. 선택한 인스턴스 유형에 따라 클러스터와 VPC에 추가 전제 조건이 있을 수 있습니다.

다음 중 하나로 자체 관리형 Linux 노드를 시작할 수 있습니다: eksctl 또는 AWS Management Console.

eksctl

사용 기기나 AWS CloudShell에 eksctl 명령줄 도구 버전 0.215.0 이상이 설치되어 있어야 합니다. eksctl을 설치하거나 업데이트하려면 eksctl 문서의 "Installation"을 참고하세요.

(선택 사항) AmazonEKS_CNI_Policy 관리형 IAM 정책이 Amazon EKS 노드 IAM 역할에 연결되어 있다면, 이를 Kubernetes aws-node 서비스 계정에 연결하는 IAM 역할에 할당할 것을 권장합니다. 자세한 내용은 "IRSA를 사용하도록 Amazon VPC CNI 플러그인 구성"을 참고하세요.

다음 명령은 기존 클러스터에 노드 그룹을 생성합니다. al-nodes를 노드 그룹 이름으로 바꾸세요. 노드 그룹 이름은 63자를 넘을 수 없습니다. 문자나 숫자로 시작해야 하며, 나머지 문자에는 하이픈과 밑줄을 포함할 수 있습니다. my-cluster를 클러스터 이름으로 바꾸세요. 이름에는 영숫자(대소문자 구분)와 하이픈만 포함할 수 있습니다. 영숫자로 시작해야 하며 100자를 넘을 수 없습니다. 이름은 클러스터를 만드는 AWS 리전과 AWS 계정 내에서 고유해야 합니다. 나머지 example value를 자신의 값으로 바꾸세요. 노드는 기본적으로 컨트롤 플레인과 같은 Kubernetes 버전으로 생성됩니다.

--node-type 값을 선택하기 전에 "최적의 Amazon EC2 노드 인스턴스 유형 선택"을 검토하세요.

my-key를 Amazon EC2 키 페어 또는 공개 키 이름으로 바꾸세요. 이 키는 노드가 시작된 후 노드에 SSH로 접속하는 데 사용됩니다. Amazon EC2 키 페어가 없다면 AWS Management Console에서 만들 수 있습니다. 자세한 내용은 Amazon EC2 사용 설명서의 "Amazon EC2 키 페어"를 참고하세요.

다음 명령으로 노드 그룹을 생성합니다.

중요: AWS Outposts, Wavelength 또는 Local Zone 서브넷에 노드 그룹을 배포하려면 추가 고려 사항이 있습니다.

클러스터를 만들 때 서브넷이 전달되지 않았어야 합니다.

서브넷과 volumeType: gp2를 지정하는 구성 파일로 노드 그룹을 만들어야 합니다. 자세한 내용은 eksctl 문서의 "구성 파일에서 노드 그룹 생성" 및 "Config file 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

다음과 같은 노드 그룹을 배포하려면:

기본 구성보다 Pod에 훨씬 더 많은 IP 주소를 할당할 수 있는 노드 그룹. "접두사를 사용해 Amazon EKS 노드에 더 많은 IP 주소 할당"을 참고하세요.
인스턴스와 다른 CIDR 블록에서 Pod에 IPv4 주소를 할당할 수 있는 노드 그룹. "사용자 지정 네트워킹으로 대체 서브넷에 Pod 배포"를 참고하세요.
Pod와 서비스에 IPv6 주소를 할당할 수 있는 노드 그룹. "클러스터, Pod 및 서비스의 IPv6 주소 알아보기"를 참고하세요.
아웃바운드 인터넷 액세스가 없는 노드 그룹. "인터넷 액세스가 제한된 프라이빗 클러스터 배포"를 참고하세요.

모든 사용 가능한 옵션과 기본값의 전체 목록은 다음 명령을 입력하세요.

eksctl create nodegroup --help

노드가 클러스터에 가입하지 못하면 문제 해결 챕터의 "노드가 클러스터에 가입하지 못함"을 참고하세요.

예제 출력은 다음과 같습니다. 노드가 생성되는 동안 여러 줄이 출력됩니다. 마지막 줄 중 하나는 다음 예제 줄입니다.

[✔]  created 1 nodegroup(s) in cluster "my-cluster"

(선택 사항) 클러스터와 Linux 노드를 테스트할 샘플 애플리케이션을 배포합니다.

다음 조건이 모두 참이라면 Pod의 IMDS 액세스 차단을 권장합니다.

모든 Kubernetes 서비스 계정에 IAM 역할을 할당하여 Pod가 필요한 최소 권한만 갖도록 계획 중인 경우.
클러스터의 어떤 Pod도 현재 AWS 리전 검색 같은 다른 이유로 IMDS에 액세스할 필요가 없는 경우.

자세한 내용은 "워커 노드에 할당된 인스턴스 프로파일 액세스 제한"을 참고하세요.

AWS Management Console

1단계: AWS Management Console로 자체 관리형 Linux 노드 시작

최신 버전의 AWS CloudFormation 템플릿을 다운로드합니다.

curl -O https://s3.us-west-2.amazonaws.com/amazon-eks/cloudformation/2025-11-26/amazon-eks-nodegroup.yaml

클러스터 상태가 ACTIVE로 표시될 때까지 기다립니다. 클러스터가 활성화되기 전에 노드를 시작하면 노드가 클러스터에 등록되지 못하므로 다시 시작해야 합니다.
AWS CloudFormation 콘솔을 엽니다.
Create stack을 선택한 다음 With new resources (standard)를 선택합니다.
Specify template에서 Upload a template file을 선택한 다음 Choose file을 선택합니다.
다운로드한 amazon-eks-nodegroup.yaml 파일을 선택합니다.
Next를 선택합니다.
Specify stack details 페이지에서 다음 매개변수를 입력한 다음 Next를 선택합니다.
- Stack name – AWS CloudFormation 스택의 이름을 선택합니다. 예를 들어 my-cluster-nodes라고 할 수 있습니다. 이름에는 영숫자(대소문자 구분)와 하이픈만 포함할 수 있습니다. 영숫자로 시작해야 하며 100자를 넘을 수 없습니다. 이름은 클러스터를 만드는 AWS 리전과 AWS 계정 내에서 고유해야 합니다.
- ClusterName – Amazon EKS 클러스터를 만들 때 사용한 이름을 입력합니다. 이 이름은 클러스터 이름과 같아야 합니다. 그렇지 않으면 노드가 클러스터에 가입할 수 없습니다.
- ClusterControlPlaneSecurityGroup – VPC를 만들 때 생성한 AWS CloudFormation 출력의 SecurityGroups 값을 선택합니다.
다음 단계는 적용 가능한 그룹을 검색하는 한 가지 작업을 보여줍니다.
- Amazon EKS 콘솔을 엽니다.
- 클러스터의 이름을 선택합니다.
- Networking 탭을 선택합니다.
- ClusterControlPlaneSecurityGroup 드롭다운 목록에서 선택할 때 Additional security groups 값을 참조로 사용합니다.
- ApiServerEndpoint – EKS 클러스터의 API Server Endpoint를 입력합니다. EKS 클러스터 콘솔의 Details 섹션에서 찾을 수 있습니다.
- CertificateAuthorityData – EKS 클러스터 콘솔의 Details 섹션에서도 찾을 수 있는 base64 인코딩 Certificate Authority 데이터를 입력합니다.
- ServiceCidr – 클러스터 내 Kubernetes 서비스에 IP 주소를 할당하는 데 사용되는 CIDR 범위를 입력합니다. 이 값은 EKS 클러스터 콘솔의 networking 탭에서 찾을 수 있습니다.
- AuthenticationMode – EKS 클러스터 콘솔의 access 탭을 검토하여 사용 중인 인증 모드를 선택합니다.
- NodeGroupName – 노드 그룹의 이름을 입력합니다. 이 이름은 나중에 노드용으로 생성된 Auto Scaling 노드 그룹을 식별하는 데 사용할 수 있습니다. 노드 그룹 이름은 63자를 넘을 수 없습니다. 문자나 숫자로 시작해야 하며, 나머지 문자에는 하이픈과 밑줄을 포함할 수 있습니다.
- NodeAutoScalingGroupMinSize – 노드 Auto Scaling 그룹이 축소할 수 있는 최소 노드 수를 입력합니다.
- NodeAutoScalingGroupDesiredCapacity – 스택이 생성될 때 확장할 원하는 노드 수를 입력합니다.
- NodeAutoScalingGroupMaxSize – 노드 Auto Scaling 그룹이 확장할 수 있는 최대 노드 수를 입력합니다.
- NodeInstanceType – 노드의 인스턴스 유형을 선택합니다. 자세한 내용은 "최적의 Amazon EC2 노드 인스턴스 유형 선택"을 참고하세요.
- NodeImageIdSSMParam – 가변 Kubernetes 버전에 대한 최신 Amazon EKS 최적화 Amazon Linux 2023 AMI의 Amazon EC2 Systems Manager 매개변수로 미리 채워져 있습니다. Amazon EKS가 지원하는 다른 Kubernetes 부 버전을 사용하려면 1.XX를 다른 지원 버전으로 바꾸세요. 클러스터와 동일한 Kubernetes 버전을 지정할 것을 권장합니다.
amazon-linux-2023을 다른 AMI 유형으로 바꿀 수도 있습니다. 자세한 내용은 "권장 Amazon Linux AMI ID 검색"을 참고하세요.

참고: Amazon EKS 노드 AMI는 Amazon Linux를 기반으로 합니다. Amazon Linux 2023의 보안 또는 개인 정보 이벤트는 Amazon Linux Security Center에서 추적하거나 관련 RSS 피드를 구독할 수 있습니다. 보안 및 개인 정보 이벤트에는 문제 개요, 영향을 받는 패키지, 문제를 해결하기 위해 인스턴스를 업데이트하는 방법이 포함됩니다.

NodeImageId – (선택 사항) 자체 사용자 지정 AMI(Amazon EKS 최적화 AMI 대신)를 사용한다면 AWS 리전의 노드 AMI ID를 입력합니다. 여기에 값을 지정하면 NodeImageIdSSMParam 필드의 모든 값을 재정의합니다.
NodeVolumeSize – 노드의 루트 볼륨 크기를 GiB 단위로 지정합니다.
NodeVolumeType – 노드의 루트 볼륨 유형을 지정합니다.
KeyName – 노드가 시작된 후 SSH로 노드에 연결하는 데 사용할 수 있는 Amazon EC2 SSH 키 페어의 이름을 입력합니다. Amazon EC2 키 페어가 없다면 AWS Management Console에서 만들 수 있습니다. 자세한 내용은 Amazon EC2 사용 설명서의 "Amazon EC2 키 페어"를 참고하세요.
VpcId – 생성한 VPC의 ID를 입력합니다.
Subnets – VPC용으로 만든 서브넷을 선택합니다. "Amazon EKS 클러스터용 Amazon VPC 생성"에 설명된 단계로 VPC를 만들었다면 VPC 내의 프라이빗 서브넷만 지정해 노드를 시작해야 합니다. 어떤 서브넷이 프라이빗인지 알려면 클러스터의 Networking 탭에서 각 서브넷 링크를 열어 확인할 수 있습니다.

중요: 서브넷 중 하나라도 공용 서브넷이라면 자동 공용 IP 주소 할당 설정을 활성화해야 합니다. 공용 서브넷에서 설정이 활성화되지 않았다면 해당 공용 서브넷에 배포하는 모든 노드는 공용 IP 주소가 할당되지 않아 클러스터나 다른 AWS 서비스와 통신할 수 없습니다. 서브넷이 2020년 3월 26일 이전에 Amazon EKS AWS CloudFormation VPC 템플릿 중 하나로 배포되었거나 eksctl로 배포되었다면 공용 서브넷에 대해 자동 공용 IP 주소 할당이 비활성화됩니다. 서브넷에 공용 IP 주소 할당을 활성화하는 방법은 "서브넷의 공용 IPv4 주소 지정 속성 수정"을 참고하세요. 노드가 프라이빗 서브넷에 배포되면 NAT 게이트웨이를 통해 클러스터와 다른 AWS 서비스와 통신할 수 있습니다.

서브넷에 인터넷 액세스가 없다면 "인터넷 액세스가 제한된 프라이빗 클러스터 배포"의 고려 사항과 추가 단계를 알고 있어야 합니다. AWS Outposts, Wavelength 또는 Local Zone 서브넷을 선택한다면 클러스터를 만들 때 서브넷이 전달되지 않았어야 합니다.

Configure stack options 페이지에서 원하는 선택을 한 다음 Next를 선택합니다.
I acknowledge that AWS CloudFormation might create IAM resources. 왼쪽의 확인란을 선택한 다음 Create stack을 선택합니다.
스택 생성이 완료되면 콘솔에서 선택하고 Outputs를 선택합니다. EKS API 또는 EKS API and ConfigMap 인증 모드를 사용한다면 이것이 마지막 단계입니다.
ConfigMap 인증 모드를 사용한다면 생성된 노드 그룹의 NodeInstanceRole을 기록해 둡니다.

2단계: 노드가 클러스터에 가입하도록 활성화

참고: 다음 두 단계는 EKS 클러스터 내에서 ConfigMap 인증 모드를 사용하는 경우에만 필요합니다. 또한 아웃바운드 인터넷 액세스가 없는 프라이빗 VPC 내부에서 노드를 시작했다면, VPC 내부에서 노드가 클러스터에 가입할 수 있도록 활성화하세요.

이미 aws-auth ConfigMap이 있는지 확인합니다.

kubectl describe configmap -n kube-system aws-auth

aws-auth ConfigMap이 표시되면 필요에 따라 업데이트합니다.

편집을 위해 ConfigMap을 엽니다.

kubectl edit -n kube-system configmap/aws-auth

필요에 따라 새 mapRoles 항목을 추가합니다. rolearn 값을 이전 절차에서 기록한 NodeInstanceRole 값으로 설정합니다.

[...]
data:
  mapRoles: |
    - rolearn:
      username: system:node:{{EC2PrivateDNSName}}
      groups:
        - system:bootstrappers
        - system:nodes
[...]

파일을 저장하고 텍스트 편집기를 종료합니다.
"Error from server (NotFound): configmaps "aws-auth" not found" 오류를 받았다면 기본 ConfigMap을 적용합니다.
- 구성 맵을 다운로드합니다.

curl -O https://s3.us-west-2.amazonaws.com/amazon-eks/cloudformation/2020-10-29/aws-auth-cm.yaml

aws-auth-cm.yaml 파일에서 rolearn 값을 이전 절차에서 기록한 NodeInstanceRole 값으로 설정합니다. 텍스트 편집기로 하거나, my-node-instance-role을 바꾸고 다음 명령을 실행해 설정할 수 있습니다.

sed -i.bak -e 's||my-node-instance-role|' aws-auth-cm.yaml

구성을 적용합니다. 이 명령은 완료되는 데 몇 분이 걸릴 수 있습니다.

kubectl apply -f aws-auth-cm.yaml

노드 상태를 관찰하고 Ready 상태에 도달할 때까지 기다립니다.

kubectl get nodes --watch

Ctrl+C를 눌러 셸 프롬프트로 돌아갑니다.

참고: 인증 또는 리소스 유형 오류가 발생하면 문제 해결 주제의 "Unauthorized or access denied (kubectl)"을 참고하세요. 노드가 클러스터에 가입하지 못하면 문제 해결 챕터의 "노드가 클러스터에 가입하지 못함"을 참고하세요.

(GPU 노드 전용) GPU 인스턴스 유형과 Amazon EKS 최적화 가속 AMI를 선택했다면 Kubernetes용 NVIDIA device plugin을 클러스터에 DaemonSet으로 적용해야 합니다. 다음 명령을 실행하기 전에 vX.X.X를 원하는 NVIDIA/k8s-device-plugin 버전으로 바꾸세요.

kubectl apply -f https://raw.githubusercontent.com/NVIDIA/k8s-device-plugin/vX.X.X/deployments/static/nvidia-device-plugin.yml

3단계: 추가 작업

(선택 사항) 클러스터와 Linux 노드를 테스트할 샘플 애플리케이션을 배포합니다.
(선택 사항) AmazonEKS_CNI_Policy 관리형 IAM 정책(IPv4 클러스터의 경우) 또는 AmazonEKS_CNI_IPv6_Policy(IPv6 클러스터의 경우 직접 만든 정책)가 Amazon EKS 노드 IAM 역할에 연결되어 있다면, 이를 Kubernetes aws-node 서비스 계정에 연결하는 IAM 역할에 할당할 것을 권장합니다. 자세한 내용은 "IRSA를 사용하도록 Amazon VPC CNI 플러그인 구성"을 참고하세요.
다음 조건이 모두 참이라면 Pod의 IMDS 액세스 차단을 권장합니다.
- 모든 Kubernetes 서비스 계정에 IAM 역할을 할당하여 Pod가 필요한 최소 권한만 갖도록 계획 중인 경우.
- 클러스터의 어떤 Pod도 현재 AWS 리전 검색 같은 다른 이유로 IMDS에 액세스할 필요가 없는 경우.
자세한 내용은 "워커 노드에 할당된 인스턴스 프로파일 액세스 제한"을 참고하세요.

더 알아보기 (Learn more)

공식 문서