자체 관리형 Ubuntu Linux 노드 생성
자체 관리형 Ubuntu Linux 노드 생성
Amazon EKS 클러스터에 등록되는 Ubuntu 또는 Ubuntu Pro 노드의 Auto Scaling 그룹을 시작하는 방법을 설명합니다.
출처: 문서
본문
참고: 관리형 노드 그룹이 사용 사례에 몇 가지 이점을 제공할 수 있습니다. 자세한 내용은 "관리형 노드 그룹으로 노드 라이프사이클 간소화"를 참고하세요.
이 주제는 Amazon Elastic Kubernetes Service(EKS)의 Ubuntu 또는 EKS의 Ubuntu Pro 노드의 Auto Scaling 그룹을 시작해 Amazon EKS 클러스터에 등록하는 방법을 설명합니다. EKS용 Ubuntu와 Ubuntu Pro는 공식 Ubuntu Minimal LTS를 기반으로 하며, AWS와 공동 개발한 사용자 지정 AWS 커널을 포함하고 EKS용으로 특별히 구축되었습니다. Ubuntu Pro는 EKS 확장 지원 기간, 커널 라이브패치, FIPS 규정 준수, 무제한 Pro 컨테이너 실행 능력을 지원해 추가 보안 커버리지를 제공합니다.
노드가 클러스터에 가입한 후 컨테이너화된 애플리케이션을 배포할 수 있습니다. 자세한 내용은 AWS의 Ubuntu 문서와 eksctl 문서의 "Custom AMI support"를 참고하세요.
중요: Amazon EKS 노드는 표준 Amazon EC2 인스턴스이며, 일반적인 Amazon EC2 인스턴스 가격에 따라 요금이 부과됩니다. 자세한 내용은 Amazon EC2 요금을 참고하세요.
AWS Outposts의 Amazon EKS 확장 클러스터에서는 Ubuntu 노드를 시작할 수 있지만, AWS Outposts의 로컬 클러스터에서는 시작할 수 없습니다. 자세한 내용은 "AWS Outposts로 Amazon EKS 온프레미스 배포"를 참고하세요.
x86 또는 Arm 프로세서가 있는 Amazon EC2 인스턴스에 배포할 수 있습니다. 하지만 Inferentia 칩이 있는 인스턴스는 먼저 Neuron SDK를 설치해야 할 수 있습니다.
이 절차는 eksctl 버전 0.215.0 이상이 필요합니다. 다음 명령으로 버전을 확인할 수 있습니다.
eksctl version
eksctl 설치 또는 업그레이드 방법은 eksctl 문서의 "Installation"을 참고하세요.
참고: 이 절차는
eksctl로 생성된 클러스터에만 적용됩니다.
다음 내용을 기기에 복사합니다. 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 키 페어"를 참고하세요. 나머지 모든 예제 값을 자신의 값으로 바꾸세요. 바꾼 후 수정된 명령을 실행해 ubuntu.yaml 파일을 만듭니다.
중요: AWS Outposts, AWS Wavelength 또는 AWS Local Zone 서브넷에 노드 그룹을 배포하려면 클러스터를 만들 때 AWS Outposts, AWS Wavelength 또는 AWS Local Zone 서브넷을 전달하지 마세요. 다음 예제에서 서브넷을 지정해야 합니다. 자세한 내용은
eksctl문서의 "구성 파일에서 노드 그룹 생성" 및 "Config file schema"를 참고하세요.region-code를 클러스터가 있는 AWS 리전으로 바꾸세요.
cat >ubuntu.yaml
(선택 사항) Ubuntu 노드를 테스트할 샘플 애플리케이션을 배포합니다.
다음 조건이 모두 참이라면 Pod의 IMDS 액세스 차단을 권장합니다.
- 모든 Kubernetes 서비스 계정에 IAM 역할을 할당하여 Pod가 필요한 최소 권한만 갖도록 계획 중인 경우.
- 클러스터의 어떤 Pod도 현재 AWS 리전 검색 같은 다른 이유로 IMDS에 액세스할 필요가 없는 경우.
자세한 내용은 "워커 노드에 할당된 인스턴스 프로파일 액세스 제한"을 참고하세요.