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