

 **이 페이지 개선에 도움 주기** 

이 사용자 가이드에 기여하려면 모든 페이지의 오른쪽 창에 있는 **GitHub에서 이 페이지 편집** 링크를 선택합니다.

# 자체 관리형 Microsoft Windows 노드 생성
<a name="launch-windows-workers"></a>

이 주제에서는 Amazon EKS 클러스터에 등록하는 Windows 노드의 오토 스케일링 그룹을 시작하는 방법을 설명합니다. 노드가 클러스터에 조인한 이후 Kubernetes 애플리케이션을 배포할 수 있습니다.

**중요**  
Amazon EKS 노드는 표준 Amazon EC2 인스턴스이고, 일반 Amazon EC2 인스턴스 가격을 기반으로 비용이 청구됩니다. 자세한 설명은 [Amazon EC2 요금](https://aws.amazon.com/ec2/pricing/)을 참조하세요.
Windows 노드를 AWS Outposts의 Amazon EKS 확장 클러스터에서 시작할 수 있지만 AWS Outposts의 로컬 클러스터에서는 시작할 수 없습니다. 자세한 내용은 [AWS Outposts를 사용한 Amazon EKS 온프레미스 배포](eks-outposts.md) 섹션을 참조하세요.

클러스터에 Windows 지원 사용 Windows 노드 그룹을 시작하기 전에 중요한 고려 사항을 검토하는 것이 좋습니다. 자세한 내용은 [Windows 지원 사용](windows-support.md#enable-windows-support) 섹션을 참조하세요.

다음 중 하나를 사용하여 자체 관리형 Windows 노드를 시작할 수 있습니다.
+  [`eksctl`](#eksctl_create_windows_nodes) 
+  [AWS Management Console](#console_create_windows_nodes) 

## `eksctl`
<a name="eksctl_create_windows_nodes"></a>

 **`eksctl`을 사용하여 자체 관리형 Windows 노드 시작 ** 

이 절차에서는 `eksctl`을 설치하고 `eksctl` 버전 `0.215.0` 이상을 요구합니다. 버전은 다음 명령을 통해 확인할 수 있습니다.

```
eksctl version
```

`eksctl` 설치 또는 업데이트에 대한 지침은 `eksctl` 설명서에서 [설치](https://eksctl.io/installation)를 참조하세요.

**참고**  
이 방법은 `eksctl`로 생성된 클러스터에만 사용할 수 있습니다.

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. 이 절차에서는 기존 클러스터가 있다고 가정합니다. Windows 노드 그룹을 추가할 Amazon EKS 클러스터 및 Amazon Linux 노드 그룹이 아직 없는 경우에는 [Amazon EKS 시작하기 – `eksctl`](getting-started-eksctl.md) 가이드를 따르는 것이 좋습니다. 이 설명서에서는 Amazon Linux 노드로 Amazon EKS 클러스터를 생성하는 방법에 대한 전체 시연을 제공합니다.

   다음 명령을 사용하여 노드 그룹을 생성합니다. *region-code*를 클러스터가 있는 AWS 리전으로 바꿉니다. *<cluster-name>*을 클러스터 이름으로 바꿉니다. 이름에는 영숫자(대소문자 구분)와 하이픈만 사용할 수 있습니다. 영숫자로 시작해야 하며 100자 이하여야 합니다. 이름은 클러스터를 생성하는 AWS 리전과 AWS 계정 내에서 고유해야 합니다. *ng-windows*을 노드 그룹의 이름으로 바꿉니다. 노드 그룹 이름은 63자를 초과할 수 없습니다. 문자나 숫자로 시작하되, 나머지 문자의 경우 하이픈과 밑줄을 포함할 수 있습니다. Windows Server 2022를 사용하기 위해 *2019*를 `2022`로 대체하거나 Windows Server 2025를 사용하기 위해 `2025`로 대체할 수 있습니다. 나머지 예제 값을 자신의 값으로 대체합니다.
**중요**  
노드 그룹을 AWS Outposts, AWS Wavelength 또는 AWS Local Zones 서브넷에 배포하려면 클러스터를 생성할 때 AWS Outposts, Wavelength 또는 로컬 영역 서브넷을 전달하지 마세요. 구성 파일을 사용하여 노드 그룹을 생성합니다. 이때 AWS Outposts, Wavelength 또는 Local Zones 서브넷을 지정합니다. 자세한 내용은 `eksctl` 문서의 [구성 파일을 사용하여 nodegroup 생성](https://eksctl.io/usage/nodegroups/#creating-a-nodegroup-from-a-config-file) 및 [구성 파일 스키마](https://eksctl.io/usage/schema/) 섹션을 참조하세요.

   ```
   eksctl create nodegroup \
       --region region-code \
       --cluster my-cluster \
       --name ng-windows \
       --node-type t2.large \
       --nodes 3 \
       --nodes-min 1 \
       --nodes-max 4 \
       --managed=false \
       --node-ami-family WindowsServer2019FullContainer
   ```
**참고**  
노드가 클러스터에 조인하지 못한 경우 문제 해결 안내서의 [노드가 클러스터 조인에 실패](troubleshooting.md#worker-node-fail) 부분을 참조하세요.
`eksctl` 명령에 사용 가능한 옵션을 보려면 다음 명령을 입력합니다.  

     ```
     eksctl command -help
     ```

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

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

1. (선택 사항) [샘플 애플리케이션](sample-deployment.md)을 배포하여 클러스터 및 Windows 노드를 테스트합니다.

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
<a name="console_create_windows_nodes"></a>

 **사전 조건** 
+ 기존 Amazon EKS 클러스터 및 Linux 노드 그룹. 이러한 리소스가 없는 경우 [Amazon EKS 시작하기](getting-started.md)의 가이드 중 하나를 사용하여 생성하는 것이 좋습니다. 이러한 가이드에서는 Linux 노드로 Amazon EKS 클러스터를 생성하는 방법에 대해 설명합니다.
+ Amazon EKS 클러스터의 요구 사항을 충족하는 기존 VPC 및 전용 보안 그룹. 자세한 내용은 [VPC 및 서브넷에 대한 Amazon EKS 네트워킹 요구 사항 보기](network-reqs.md) 및 [클러스터에 대한 Amazon EKS 보안 그룹 요구 사항 보기](sec-group-reqs.md) 섹션을 참조하세요. [Amazon EKS 시작하기](getting-started.md)의 가이드에 따라 요구 사항을 충족하는 VPC를 만듭니다. 또는 [Amazon EKS 클러스터에 대한 Amazon VPC 생성](creating-a-vpc.md)을 따라 수동으로 생성할 수도 있습니다.
+ Amazon EKS 클러스터의 요구 사항을 충족하는 VPC 및 보안 그룹을 사용하는 기존 Amazon EKS 클러스터. 자세한 내용은 [Amazon EKS 클러스터 생성](create-cluster.md) 섹션을 참조하세요. AWS Outposts, AWS Wavelength 또는 AWS Local Zones이 사용된 AWS 리전에 서브넷이 있는 경우 클러스터를 생성할 때 해당 서브넷이 전달되지 않은 상태여야 합니다.

 **1단계: AWS Management Console을 사용하여 자체 관리형 Windows 노드를 시작하려면** 

1. 클러스터 상태가 `ACTIVE`가 되기를 기다립니다. 클러스터가 활성화되기 전에 노드를 시작하면 노드가 클러스터에 등록되지 않고 노드를 다시 시작해야 합니다.

1. [AWS CloudFormation 콘솔](https://console.aws.amazon.com/cloudformation/) 열기 

1. **스택 생성**을 선택합니다.

1. **템플릿 지정**에서 **Amazon S3 URL**을 선택합니다.

1. 다음과 같은 URL을 복사하여 **Amazon S3 URL**에 붙여 넣습니다.

   ```
   https://s3.us-west-2.amazonaws.com/amazon-eks/cloudformation/2023-02-09/amazon-eks-windows-nodegroup.yaml
   ```

1. **다음**을 두 번 선택합니다

1. **빠른 스택 생성** 페이지에서 다음 파라미터를 적절하게 입력합니다.
   +  **스택 이름**: AWS CloudFormation 스택에 대한 스택 이름을 선택합니다. 예를 들어 `my-cluster-nodes`라고 할 수 있습니다.
   +  **ClusterName**: Amazon EKS 클러스터 생성 시 사용할 이름을 입력합니다.
**중요**  
이 이름은 [1단계: Amazon EKS 클러스터 생성](getting-started-console.md#eks-create-cluster)에서 사용한 이름과 정확히 일치해야 합니다. 그렇지 않으면 노드가 클러스터에 가입할 수 없습니다.
   +  **ClusterControlPlaneSecurityGroup**: [VPC](creating-a-vpc.md)를 만들 때 생성한 AWS CloudFormation 출력에서 보안 그룹을 선택합니다. 다음 단계에서는 해당 그룹을 검색하는 한 가지 방법을 보여줍니다.

     1. [Amazon EKS 콘솔](https://console.aws.amazon.com/eks/home#/clusters)을 엽니다.

     1. 클러스터의 이름을 선택합니다.

     1. **네트워킹** 탭을 선택합니다.

     1. **ClusterControlPlaneSecurityGroup** 드롭다운 목록에서 선택할 때 **추가 보안 그룹** 값을 참조로 사용하세요.
   +  **NodeGroupName**: 노드 그룹의 이름을 입력합니다. 이 이름은 나중에 노드에 대해 생성된 Auto Scaling 노드 그룹을 식별하는 데 사용할 수 있습니다. 노드 그룹 이름은 63자를 초과할 수 없습니다. 문자나 숫자로 시작하되, 나머지 문자의 경우 하이픈과 밑줄을 포함할 수 있습니다.
   +  **NodeAutoScalingGroupMinSize**: Auto Scaling 그룹이 축소할 수 있는 노드의 최소 노드 수를 입력합니다.
   +  **NodeAutoScalingGroupDesiredCapacity**: 스택을 생성할 때 조정할 원하는 노드 수를 입력합니다.
   +  **NodeAutoScalingGroupMaxSize**: Auto Scaling 그룹이 확장할 수 있는 노드의 최대 노드 수를 입력합니다.
   +  **NodeInstanceType**: 노드에 대한 인스턴스 유형을 선택합니다. 자세한 내용은 [최적의 Amazon EC2 노드 인스턴스 유형 선택](choosing-instance-type.md) 섹션을 참조하세요.
**참고**  
최신 버전의 [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)에 나열되어 있습니다. 지원되는 최신 인스턴스 유형을 사용하려면 CNI 버전을 업데이트해야 할 수 있습니다. 자세한 내용은 [Amazon VPC CNI를 통해 포드에 IP 할당](managing-vpc-cni.md) 섹션을 참조하세요.
   +  **NodeImageIdSSMParam**: 현재 권장되는 Amazon EKS 최적화 Windows Core AMI ID의 Amazon EC2 Systems Manager 파라미터로 미리 채워집니다. 전체 버전의 Windows를 사용하려면 *Core*를 `Full`로 바꿉니다.
   +  **NodeImageId**: (선택사항) Amazon EKS 최적화 AMI 대신 사용자 정의 AMI를 사용 중인 경우, 해당 AWS 리전에 노드 AMI ID를 입력합니다. 이 필드의 값을 지정하면 **NodeImageIdSSMParam** 필드에 있는 모든 값이 재정의됩니다.
   +  **NodeVolumeSize**: 노드에 대해 루트 볼륨 크기를 GiB 단위로 지정합니다.
   +  **KeyName**: 시작 이후 SSH를 사용하여 노드에 연결하는 데 사용할 수 있는 Amazon EC2 SSH 키 페어 이름을 입력합니다. Amazon EC2 키 페어가 아직 없는 경우 AWS Management Console에서 새로 생성할 수 있습니다. 자세한 내용을 알아보려면 *Amazon EC2 key pairs*의 [Amazon EC2 키 페어](https://docs.aws.amazon.com/AWSEC2/latest/WindowsGuide/ec2-key-pairs.html)를 참조하세요.
**참고**  
여기에 키 페어을 제공하지 않으면 AWS CloudFormation 스택이 생성되지 않습니다.
   +  **BootstrapArguments**: `-KubeletExtraArgs`를 사용하여 별도의 `kubelet` 인수와 같이 노드 부트스트랩 스크립트에 전달할 선택적 인수를 지정합니다.
   +  **DisableIMDSv1**: 기본적으로 각 노드는 인스턴스 메타데이터 서비스 버전 1(IMDSv1) 및 IMDSv2를 지원합니다. IMDSv1을 사용 중지할 수 있습니다. 향후 노드 그룹의 노드와 포드가 MDSv1을 사용하지 못하게 하려면 **DisableIMDSv1**을 **true**로 설정합니다. IMDS에 대한 자세한 내용은 [인스턴스 메타데이터 서비스 구성](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/configuring-instance-metadata-service.html)을 참조하세요.
   +  **VpcId**: 생성한 [VPC](creating-a-vpc.md)에 대한 ID를 선택합니다.
   +  **NodeSecurityGroups**: [VPC](creating-a-vpc.md)를 생성할 때 Linux 노드 그룹에 대해 생성된 보안 그룹을 선택합니다. Linux 노드에 둘 이상의 보안 그룹이 연결되어 있는 경우 모든 보안 그룹을 지정합니다. 예를 들어 Linux 노드 그룹이 `eksctl`로 생성된 경우입니다.
   +  **서브넷**: 생성한 서브넷을 선택합니다. [Amazon EKS 클러스터를 위한 Amazon VPC 만들기](creating-a-vpc.md)의 단계를 사용하여 VPC를 만든 경우, 노드가 실행할 VPC 내의 사설 서브넷만 지정합니다.
**중요**  
서브넷 중 하나가 퍼블릭 서브넷인 경우 자동 퍼블릭 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. 스택에서 IAM 리소스를 생성할 수 있는지 확인한 다음 **스택 생성**을 선택합니다.

1. 스택이 생성된 후 콘솔에서 이를 선택하고 **출력**을 선택합니다.

1. 생성된 노드 그룹에 대해 **NodeInstanceRole**을 기록합니다. Amazon EKS Windows 노드를 구성할 때 필요합니다.

 **2단계: 노드가 클러스터에 조인하도록 하려면** 

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: <ARN of linux instance role (not instance profile)>
            username: system:node:{{EC2PrivateDNSName}}
            groups:
              - system:bootstrappers
              - system:nodes
          - rolearn: <ARN of windows instance role (not instance profile)>
            username: system:node:{{EC2PrivateDNSName}}
            groups:
              - system:bootstrappers
              - system:nodes
              - eks:kube-proxy-windows
      [...]
      ```

   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-windows.yaml
      ```

   1. `aws-auth-cm-windows.yaml` 파일에서 `rolearn` 값을 이전 절차에서 기록한 해당 **NodeInstanceRole** 값으로 설정합니다. 이 작업은 텍스트 편집기를 사용하거나 예제 값을 바꾸고 다음 명령을 실행하여 수행할 수 있습니다.

      ```
      sed -i.bak -e 's|<ARN of linux instance role (not instance profile)>|my-node-linux-instance-role|' \
          -e 's|<ARN of windows instance role (not instance profile)>|my-node-windows-instance-role|' aws-auth-cm-windows.yaml
      ```
**중요**  
이 파일에서 어떠한 행도 수정하지 마세요.
Windows 및 Linux 노드 모두에 동일한 IAM 역할을 사용하지 마세요.

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

      ```
      kubectl apply -f aws-auth-cm-windows.yaml
      ```

1. 노드의 상태를 확인하고 `Ready` 상태가 될 때까지 대기합니다.

   ```
   kubectl get nodes --watch
   ```

   `Ctrl`\$1`C`를 입력하여 쉘 프롬프트로 돌아갑니다.
**참고**  
권한 부여 또는 리소스 유형 오류가 표시되는 경우 문제 해결 주제의 [권한이 없거나 액세스가 거부됨(`kubectl`)](troubleshooting.md#unauthorized) 부분을 참조하세요.

   노드가 클러스터에 조인하지 못한 경우 문제 해결 장의 [노드가 클러스터 조인에 실패](troubleshooting.md#worker-node-fail) 섹션을 참조하세요.

 **3단계: 추가 작업** 

1. (선택 사항) [샘플 애플리케이션](sample-deployment.md)을 배포하여 클러스터 및 Windows 노드를 테스트합니다.

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) 섹션을 참조하세요.