클러스터용 관리형 노드 그룹 생성

Amazon EKS 클러스터에 등록되는 관리형 노드 그룹을 시작하는 방법을 설명합니다.

출처: 문서

본문

이 주제는 Amazon EKS 클러스터에 등록되는 Amazon EKS 관리형 노드 그룹을 시작하는 방법을 설명합니다. 노드가 클러스터에 가입한 후 Kubernetes 애플리케이션을 배포할 수 있습니다.

Amazon EKS 관리형 노드 그룹을 처음 시작한다면 "Amazon EKS 시작하기"의 안내 중 하나를 따를 것을 권장합니다. 이 안내는 노드가 있는 Amazon EKS 클러스터 생성에 대한 연습을 제공합니다.

중요: Amazon EKS 노드는 표준 Amazon EC2 인스턴스입니다. 일반적인 Amazon EC2 가격에 따라 요금이 부과됩니다. 자세한 내용은 Amazon EC2 요금을 참고하세요.

AWS Outposts나 AWS Wavelength가 활성화된 AWS 리전에서는 관리형 노드를 만들 수 없습니다. 대신 자체 관리형 노드를 만들 수 있습니다. 자세한 내용은 "자체 관리형 Amazon Linux 노드 생성", "자체 관리형 Microsoft Windows 노드 생성", "자체 관리형 Bottlerocket 노드 생성"을 참고하세요. Outpost에서 자체 관리형 Amazon Linux 노드 그룹을 만들 수도 있습니다. 자세한 내용은 "AWS Outposts에서 Amazon Linux 노드 생성"을 참고하세요.

Amazon EKS 최적화 Linux 또는 Bottlerocket에 포함된 bootstrap.sh 파일에 AMI ID를 지정하지 않으면, 관리형 노드 그룹은 maxPods 값에 최대 수를 적용합니다. vCPU가 30개 미만인 인스턴스의 경우 최대 수는 110입니다. vCPU가 30개보다 많은 인스턴스의 경우 최대 수는 250으로 점프합니다. 이 적용은 maxPodsExpression을 포함한 다른 maxPods 구성을 재정의합니다. maxPods가 결정되는 방법과 사용자 지정하는 방법에 대한 자세한 내용은 "How maxPods is determined"를 참고하세요.

전제 조건

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

다음 중 하나로 관리형 노드 그룹을 만들 수 있습니다: eksctl 또는 AWS Management Console.

eksctl

이 절차는 eksctl 버전 0.215.0 이상이 필요합니다. 다음 명령으로 버전을 확인할 수 있습니다.

eksctl version

eksctl 설치 또는 업그레이드 방법은 eksctl 문서의 "Installation"을 참고하세요.

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

사용자 지정 런치 템플릿을 사용하거나 사용하지 않고 관리형 노드 그룹을 생성합니다. 런치 템플릿을 수동으로 지정하면 노드 그룹을 더 많이 사용자 지정할 수 있습니다. 예를 들어 사용자 지정 AMI를 배포하거나 Amazon EKS 최적화 AMI의 bootstrap.sh 스크립트에 인수를 제공할 수 있습니다. 사용 가능한 모든 옵션과 기본값의 전체 목록을 보려면 다음 명령을 입력하세요.

eksctl create nodegroup --help

다음 명령에서 my-cluster를 클러스터 이름으로, my-mng를 노드 그룹 이름으로 바꾸세요. 노드 그룹 이름은 63자를 넘을 수 없습니다. 문자나 숫자로 시작해야 하며, 나머지 문자에는 하이픈과 밑줄을 포함할 수 있습니다.

중요: 관리형 노드 그룹을 처음 만들 때 사용자 지정 런치 템플릿을 사용하지 않았다면, 나중에 노드 그룹에 런치 템플릿을 사용하지 마세요. 사용자 지정 런치 템플릿을 지정하지 않으면 시스템이 자동 생성 런치 템플릿을 만드는데, 이는 수동으로 수정하지 않을 것을 권장합니다. 이 자동 생성 런치 템플릿을 수동으로 수정하면 오류가 발생할 수 있습니다.

런치 템플릿 없이

eksctl은 계정에 기본 Amazon EC2 런치 템플릿을 만들고, 지정한 옵션을 기반으로 생성한 런치 템플릿으로 노드 그룹을 배포합니다. --node-type 값을 지정하기 전에 "최적의 Amazon EC2 노드 인스턴스 유형 선택"을 참고하세요.

ami-family를 허용된 키워드로 바꾸세요. 자세한 내용은 eksctl 문서의 "노드 AMI 패밀리 설정"을 참고하세요. my-key를 Amazon EC2 키 페어 또는 공개 키 이름으로 바꾸세요. 이 키는 노드가 시작된 후 노드에 SSH로 접속하는 데 사용됩니다.

참고: Windows의 경우 이 명령은 SSH를 활성화하지 않습니다. 대신 Amazon EC2 키 페어를 인스턴스와 연결하고 인스턴스에 RDP로 접속할 수 있게 합니다.

Amazon EC2 키 페어가 없다면 AWS Management Console에서 만들 수 있습니다. Linux 정보는 Amazon EC2 사용 설명서의 "Amazon EC2 키 페어 및 Linux 인스턴스"를, Windows 정보는 "Amazon EC2 키 페어 및 Windows 인스턴스"를 참고하세요.

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

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

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

Pod의 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

인스턴스는 선택적으로 Pod에 훨씬 더 많은 IP 주소를 할당하고, 인스턴스와 다른 CIDR 블록에서 Pod에 IP 주소를 할당하며, 인터넷 액세스가 없는 클러스터에 배포될 수 있습니다. 자세한 내용은 "접두사를 사용해 Amazon EKS 노드에 더 많은 IP 주소 할당", "사용자 지정 네트워킹으로 대체 서브넷에 Pod 배포", "인터넷 액세스가 제한된 프라이빗 클러스터 배포"를 이전 명령에 추가할 옵션으로 참고하세요.

관리형 노드 그룹은 인스턴스 유형을 기반으로 노드 그룹의 각 노드에서 실행할 수 있는 최대 Pod 수의 단일 값을 계산하고 적용합니다. 다른 인스턴스 유형으로 노드 그룹을 만들면 모든 인스턴스 유형에서 계산된 가장 작은 값이 노드 그룹의 모든 인스턴스 유형에서 실행할 수 있는 최대 Pod 수로 적용됩니다. 이 값이 계산되는 방법에 대한 자세한 내용은 "How maxPods is determined"를 참고하세요.

런치 템플릿 사용

런치 템플릿은 이미 존재해야 하며 "런치 템플릿 구성 기본 사항"에 지정된 요구 사항을 충족해야 합니다.

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

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

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

Pod의 IMDS 액세스를 차단하려면 런치 템플릿에서 필요한 설정을 지정하세요.

다음 내용을 기기에 복사합니다. 예제 값을 바꾼 다음 수정된 명령을 실행해 eks-nodegroup.yaml 파일을 만듭니다. 런치 템플릿 없이 배포할 때 지정하는 여러 설정이 런치 템플릿으로 이동합니다. version을 지정하지 않으면 템플릿의 기본 버전이 사용됩니다.

cat >eks-nodegroup.yaml Config file schema in the `eksctl` documentation.

인스턴스는 선택적으로 Pod에 훨씬 더 많은 IP 주소를 할당하고, 인스턴스와 다른 CIDR 블록에서 Pod에 IP 주소를 할당하며, 아웃바운드 인터넷 액세스가 없는 클러스터에 배포될 수 있습니다. 자세한 내용은 "접두사를 사용해 Amazon EKS 노드에 더 많은 IP 주소 할당", "사용자 지정 네트워킹으로 대체 서브넷에 Pod 배포", "인터넷 액세스가 제한된 프라이빗 클러스터 배포"를 구성 파일에 추가할 옵션으로 참고하세요.

런치 템플릿에서 AMI ID를 지정하지 않았다면, 관리형 노드 그룹은 인스턴스 유형을 기반으로 노드 그룹의 각 노드에서 실행할 수 있는 최대 Pod 수의 단일 값을 계산하고 적용합니다. 다른 인스턴스 유형으로 노드 그룹을 만들면 모든 인스턴스 유형에서 계산된 가장 작은 값이 노드 그룹의 모든 인스턴스 유형에서 실행할 수 있는 최대 Pod 수로 적용됩니다. 이 값이 계산되는 방법에 대한 자세한 내용은 "How maxPods is determined"를 참고하세요.

런치 템플릿에서 AMI ID를 지정했다면, 사용자 지정 네트워킹을 사용하거나 인스턴스에 할당된 IP 주소 수를 늘리려면 노드 그룹의 각 노드에서 실행할 수 있는 최대 Pod 수를 지정하세요. 자세한 내용은 "How maxPods is determined"를 참고하세요.

다음 명령으로 노드 그룹을 배포합니다.

eksctl create nodegroup --config-file eks-nodegroup.yaml

AWS Management Console

클러스터 상태가 ACTIVE로 표시될 때까지 기다립니다. 이미 ACTIVE가 아닌 클러스터에는 관리형 노드 그룹을 만들 수 없습니다.

Amazon EKS 콘솔을 엽니다.
관리형 노드 그룹을 만들 클러스터의 이름을 선택합니다.
Compute 탭을 선택합니다.
Add node group을 선택합니다.
Configure node group 페이지에서 매개변수를 채운 다음 Next를 선택합니다.
- Name – 관리형 노드 그룹의 고유한 이름을 입력합니다. 노드 그룹 이름은 63자를 넘을 수 없습니다. 문자나 숫자로 시작해야 하며, 나머지 문자에는 하이픈과 밑줄을 포함할 수 있습니다.
- Node IAM role – 노드 그룹에 사용할 노드 인스턴스 역할을 선택합니다. 자세한 내용은 "Amazon EKS 노드 IAM 역할"을 참고하세요.

중요: 클러스터를 생성하는 데 사용된 동일한 역할은 사용할 수 없습니다. 새 자체 관리형 노드 그룹과 함께 사용할 계획이 아니라면 현재 어떤 자체 관리형 노드 그룹에서도 사용되지 않는 역할을 사용할 것을 권장합니다. 자세한 내용은 "클러스터에서 관리형 노드 그룹 삭제"를 참고하세요.

Use launch template – (선택 사항) 기존 런치 템플릿을 사용하려면 선택합니다. Launch Template Name을 선택한 다음 Launch template version을 선택합니다. 버전을 선택하지 않으면 Amazon EKS가 템플릿의 기본 버전을 사용합니다. 런치 템플릿을 사용하면 노드 그룹을 더 많이 사용자 지정할 수 있습니다. 예를 들어 사용자 지정 AMI 배포, Pod에 훨씬 더 많은 IP 주소 할당, 인스턴스와 다른 CIDR 블록에서 Pod에 IP 주소 할당, 아웃바운드 인터넷 액세스가 없는 클러스터에 노드 배포가 가능합니다. 자세한 내용은 "접두사를 사용해 Amazon EKS 노드에 더 많은 IP 주소 할당", "사용자 지정 네트워킹으로 대체 서브넷에 Pod 배포", "인터넷 액세스가 제한된 프라이빗 클러스터 배포"를 참고하세요.

런치 템플릿은 "런치 템플릿으로 관리형 노드 사용자 지정"의 요구 사항을 충족해야 합니다. 자체 런치 템플릿을 사용하지 않으면 Amazon EKS API가 계정에 기본 Amazon EC2 런치 템플릿을 만들고 기본 런치 템플릿으로 노드 그룹을 배포합니다.

서비스 계정용 IAM 역할을 구현하고, AWS 서비스에 액세스해야 하는 모든 Pod에 필요한 권한을 직접 할당하며, 클러스터의 어떤 Pod도 현재 AWS 리전 검색 같은 다른 이유로 IMDS 액세스가 필요하지 않다면, 호스트 네트워킹을 사용하지 않는 Pod의 IMDS 액세스를 런치 템플릿에서 비활성화할 수도 있습니다. 자세한 내용은 "워커 노드에 할당된 인스턴스 프로파일 액세스 제한"을 참고하세요.

Kubernetes labels – (선택 사항) 관리형 노드 그룹의 노드에 Kubernetes 라벨을 적용하도록 선택할 수 있습니다.
Kubernetes taints – (선택 사항) 관리형 노드 그룹의 노드에 Kubernetes taint를 적용하도록 선택할 수 있습니다. Effect 메뉴의 사용 가능한 옵션은 NoSchedule, NoExecute, PreferNoSchedule입니다. 자세한 내용은 "레시피: 특정 노드에 Pod가 스케줄되는 것 방지"를 참고하세요.
Tags – (선택 사항) Amazon EKS 관리형 노드 그룹에 태그를 지정하도록 선택할 수 있습니다. 이러한 태그는 Auto Scaling 그룹이나 인스턴스 같은 노드 그룹의 다른 리소스로 전파되지 않습니다. 자세한 내용은 "태그로 Amazon EKS 리소스 구성"을 참고하세요.

Set compute and scaling configuration 페이지에서 매개변수를 채운 다음 Next를 선택합니다.
- AMI type – AMI 유형을 선택합니다. Arm 인스턴스를 배포하는 경우 배포 전에 "Amazon EKS 최적화 Arm Amazon Linux AMI"의 고려 사항을 검토하세요. 이전 페이지에서 런치 템플릿을 지정하고 런치 템플릿에 AMI를 지정했다면 값을 선택할 수 없습니다. 템플릿의 값이 표시됩니다. 템플릿에 지정된 AMI는 "AMI 지정"의 요구 사항을 충족해야 합니다.
- Capacity type – 용량 유형을 선택합니다. 용량 유형 선택에 대한 자세한 내용은 "관리형 노드 그룹 용량 유형"을 참고하세요. 같은 노드 그룹 내에서 다른 용량 유형을 혼합할 수 없습니다. 두 용량 유형을 모두 사용하려면 각각 자체 용량과 인스턴스 유형을 가진 별도의 노드 그룹을 만드세요. GPU 가속 워커 노드의 프로비저닝과 스케일링에 대한 정보는 "노드 그룹으로 Amazon EKS의 AI/ML 워크로드용 컴퓨팅 관리"를 참고하세요.
- Instance types – 기본적으로 하나 이상의 인스턴스 유형이 지정됩니다. 기본 인스턴스 유형을 제거하려면 인스턴스 유형 오른쪽의 X를 선택합니다. 관리형 노드 그룹에 사용할 인스턴스 유형을 선택합니다. 자세한 내용은 "최적의 Amazon EC2 노드 인스턴스 유형 선택"을 참고하세요.

콘솔은 일반적으로 사용되는 인스턴스 유형 집합을 표시합니다. 표시되지 않는 인스턴스 유형으로 관리형 노드 그룹을 만들어야 한다면 eksctl, AWS CLI, AWS CloudFormation 또는 SDK를 사용해 노드 그룹을 만드세요. 이전 페이지에서 런치 템플릿을 지정했다면 인스턴스 유형을 런치 템플릿에서 지정해야 하므로 값을 선택할 수 없습니다. 런치 템플릿의 값이 표시됩니다. Capacity type에서 Spot을 선택했다면 가용성을 높이기 위해 여러 인스턴스 유형을 지정할 것을 권장합니다.

Disk size – 노드의 루트 볼륨에 사용할 디스크 크기(GiB)를 입력합니다. 이전 페이지에서 런치 템플릿을 지정했다면 런치 템플릿에서 지정해야 하므로 값을 선택할 수 없습니다.
Desired size – 관리형 노드 그룹이 시작 시 유지해야 하는 현재 노드 수를 지정합니다.

참고: Amazon EKS는 노드 그룹을 자동으로 확장하거나 축소하지 않습니다. 하지만 Kubernetes Cluster Autoscaler를 구성하면 할 수 있습니다. 자세한 내용은 "AWS의 Cluster Autoscaler"를 참고하세요.

Minimum size – 관리형 노드 그룹이 축소할 수 있는 최소 노드 수를 지정합니다.
Maximum size – 관리형 노드 그룹이 확장할 수 있는 최대 노드 수를 지정합니다.
Node group update configuration – (선택 사항) 병렬로 업데이트할 노드의 수 또는 백분율을 선택할 수 있습니다. 이 노드는 업데이트 중 사용할 수 없습니다. Maximum unavailable에서 다음 옵션 중 하나를 선택하고 Value를 지정합니다.
- Number – 노드 그룹에서 병렬로 업데이트할 수 있는 노드 수를 선택하고 지정합니다.
- Percentage – 노드 그룹에서 병렬로 업데이트할 수 있는 노드 백분율을 선택하고 지정합니다. 노드 그룹에 노드가 많을 때 유용합니다.
Node auto repair configuration – (선택 사항) Enable node auto repair 확인란을 활성화하면 감지된 문제가 발생할 때 Amazon EKS가 노드를 자동으로 교체합니다. 자세한 내용은 "노드 상태 문제 감지 및 자동 노드 복구 활성화"를 참고하세요.
Warm pool configuration – (선택 사항) Enable warm pool configuration 확인란을 활성화하면 Amazon EKS가 ASG에 웜 풀을 만듭니다. 자세한 내용은 "관리형 노드 그룹과 웜 풀을 사용한 부팅 시간이 긴 애플리케이션의 지연 시간 감소"를 참고하세요.

Specify networking 페이지에서 매개변수를 채운 다음 Next를 선택합니다.
- Subnets – 관리형 노드를 시작할 서브넷을 선택합니다.

중요: Amazon EBS 볼륨으로 백업되는 상태 저장 애플리케이션을 여러 가용 영역에 걸쳐 실행하면서 Kubernetes Cluster Autoscaler를 사용한다면, 각각 단일 가용 영역으로 범위가 지정된 여러 노드 그룹을 구성해야 합니다. 또한 --balance-similar-node-groups 기능을 활성화해야 합니다.

중요: 공용 서브넷을 선택하고 클러스터에 공용 API 서버 엔드포인트만 활성화되어 있다면, 인스턴스가 클러스터에 성공적으로 가입하려면 서브넷의 MapPublicIPOnLaunch가 true로 설정되어 있어야 합니다. 서브넷이 2020년 3월 26일 이후 eksctl 또는 Amazon EKS가 제공하는 AWS CloudFormation 템플릿으로 생성되었다면 이 설정이 이미 true로 설정되어 있습니다. 서브넷이 2020년 3월 26일 이전에 eksctl 또는 AWS CloudFormation 템플릿으로 생성되었다면 설정을 수동으로 변경해야 합니다. 자세한 내용은 "서브넷의 공용 IPv4 주소 지정 속성 수정"을 참고하세요.

런치 템플릿을 사용하고 여러 네트워크 인터페이스를 지정하면, MapPublicIpOnLaunch가 true로 설정되어 있어도 Amazon EC2가 공용 IPv4 주소를 자동 할당하지 않습니다. 이 시나리오에서 노드가 클러스터에 가입하려면 클러스터의 프라이빗 API 서버 엔드포인트를 활성화하거나, NAT Gateway 같은 대체 방법으로 아웃바운드 인터넷 액세스를 제공하는 프라이빗 서브넷에 노드를 시작해야 합니다. 자세한 내용은 Amazon EC2 사용 설명서의 "Amazon EC2 인스턴스 IP 주소 지정"을 참고하세요.

Configure SSH access to nodes (선택 사항). SSH를 활성화하면 문제가 있을 때 인스턴스에 연결해 진단 정보를 수집할 수 있습니다. 노드 그룹을 만들 때 원격 액세스를 활성화할 것을 강력히 권장합니다. 노드 그룹 생성 후에는 원격 액세스를 활성화할 수 없습니다.

런치 템플릿을 사용하기로 선택했다면 이 옵션이 표시되지 않습니다. 노드에 원격 액세스를 활성화하려면 런치 템플릿에 키 페어를 지정하고, 런치 템플릿에 지정한 보안 그룹에서 노드에 올바른 포트가 열려 있는지 확인하세요. 자세한 내용은 "사용자 지정 보안 그룹 사용"을 참고하세요.

참고: Windows의 경우 이 명령은 SSH를 활성화하지 않습니다. 대신 Amazon EC2 키 페어를 인스턴스와 연결하고 인스턴스에 RDP로 접속할 수 있게 합니다.

For SSH key pair (선택 사항) 사용할 Amazon EC2 SSH 키를 선택합니다. Linux 정보는 Amazon EC2 사용 설명서의 "Amazon EC2 키 페어 및 Linux 인스턴스"를, Windows 정보는 "Amazon EC2 키 페어 및 Windows 인스턴스"를 참고하세요. 런치 템플릿을 사용하기로 선택했다면 하나를 선택할 수 없습니다. Bottlerocket AMI를 사용하는 노드 그룹에 Amazon EC2 SSH 키가 제공되면 관리 컨테이너(admin container)도 활성화됩니다. 자세한 내용은 GitHub의 "Admin container"를 참고하세요.
Allow SSH remote access from – 특정 인스턴스로 액세스를 제한하려면 해당 인스턴스와 연결된 보안 그룹을 선택합니다. 특정 보안 그룹을 선택하지 않으면 인터넷 어디서든(0.0.0.0/0) SSH 액세스가 허용됩니다.

Review and create 페이지에서 관리형 노드 그룹 구성을 검토하고 Create를 선택합니다.

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

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

kubectl get nodes --watch

(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

Kubernetes 애드온 설치

이제 노드가 있는 작동하는 Amazon EKS 클러스터가 있으므로 Kubernetes 애드온 설치와 애플리케이션 배포를 시작할 준비가 되었습니다. 다음 문서 주제는 클러스터 기능을 확장하는 데 도움이 됩니다.

클러스터를 만든 IAM 보안 주체만 kubectl이나 AWS Management Console로 Kubernetes API 서버에 호출할 수 있습니다. 다른 IAM 보안 주체에게 클러스터 액세스 권한을 부여하려면 추가해야 합니다. 자세한 내용은 "IAM 사용자 및 역할에게 Kubernetes API 액세스 권한 부여"와 "필요한 권한"을 참고하세요.
다음 조건이 모두 참이라면 Pod의 IMDS 액세스 차단을 권장합니다.
- 모든 Kubernetes 서비스 계정에 IAM 역할을 할당하여 Pod가 필요한 최소 권한만 갖도록 계획 중인 경우.
- 클러스터의 어떤 Pod도 현재 AWS 리전 검색 같은 다른 이유로 IMDS에 액세스할 필요가 없는 경우.
자세한 내용은 "워커 노드에 할당된 인스턴스 프로파일 액세스 제한"을 참고하세요.
노드 그룹의 노드 수를 자동으로 조정하도록 Kubernetes Cluster Autoscaler를 구성합니다.
클러스터에 샘플 애플리케이션을 배포합니다.
클러스터를 관리하는 중요한 도구로 클러스터 리소스를 구성하고 모니터링합니다.

더 알아보기 (Learn more)

공식 문서