**이 페이지 개선에 도움 주기** 이 사용자 가이드에 기여하려면 모든 페이지의 오른쪽 창에 있는 **GitHub에서 이 페이지 편집** 링크를 선택합니다. # 시작 템플릿을 사용한 관리형 노드 사용자 지정 최고 수준의 사용자 지정을 위해 이 페이지의 단계에 기반한 자체 시작 템플릿을 사용하여 관리형 노드를 배포할 수 있습니다. 시작 템플릿을 사용하면 노드 배포 중에 부트스트랩 인수(예: 추가 [kubelet](https://kubernetes.io/docs/reference/command-line-tools-reference/kubelet/) 인수)를 제공하거나 노드에 할당된 IP 주소와 다른 CIDR 블록의 포드에 IP 주소를 할당하거나 노드에 자체 사용자 지정 AMI를 배포하거나 노드에 자체 사용자 지정 CNI를 배포하는 등의 기능을 허용합니다. 관리형 노드 그룹을 처음 만들 때 자체 시작 템플릿을 제공하면 나중에 더 유연하게 사용할 수 있습니다. 자체 시작 템플릿을 사용하여 관리형 노드 그룹을 배포한 후 동일한 시작 템플릿의 다른 버전으로 업데이트할 수 있습니다. 노드 그룹을 다른 버전의 시작 템플릿으로 업데이트하면 그룹의 모든 노드가 지정된 시작 템플릿 버전의 새 구성과 일치하도록 재활용됩니다. 관리형 노드 그룹은 항상 Amazon EC2 Auto Scaling 그룹에서 사용할 시작 템플릿과 함께 배포됩니다. Amazon EKS API는 사용자가 제공한 템플릿을 복사하거나 계정의 기본값으로 자동 생성하여 이 시작 템플릿을 생성합니다. 자동 생성된 시작 템플릿을 수정하지 않는 것이 좋습니다. 사용자 정의 시작 템플릿을 사용하지 않는 기존 노드 그룹은 직접 업데이트할 수 없습니다. 대신 사용자 정의 시작 템플릿을 사용하여 새 노드 그룹을 생성해야 합니다. ## 시작 템플릿 기본 사항 AWS Management Console, AWS CLI 또는 AWS SDK를 사용하여 Amazon EC2 Auto Scaling 시작 템플릿을 생성할 수 있습니다. 자세한 내용을 알아보려면 *Amazon EC2 Auto Scaling 사용 설명서*의 [Auto Scaling 그룹을 위한 시작 템플릿 생성](https://docs.aws.amazon.com/autoscaling/ec2/userguide/create-launch-template.html)을 참조하세요. 시작 템플릿의 일부 설정은 관리형 노드 구성에 사용되는 설정과 유사합니다. 시작 템플릿을 사용하여 노드 그룹을 배포하거나 업데이트할 때 노드 그룹 구성 또는 시작 템플릿에 일부 설정을 지정해야 합니다. 두 위치 모두에 설정을 지정하지 않습니다. 잘못된 위치에 설정이 있으면 노드 그룹 생성 또는 업데이트와 같은 작업이 실패합니다. 다음 표에는 시작 템플릿에서 금지된 설정이 나열되어 있습니다. 사용 가능한 경우 관리형 노드 그룹 구성에 필요한 유사한 설정도 나열되어 있습니다. 나열된 설정은 콘솔에 표시되는 설정입니다. AWS CLI 및 SDK에서 비슷하지만 다른 이름을 가질 수 있습니다. | 시작 템플릿 - 금지됨 | Amazon EKS 노드 그룹 구성 | | --- | --- | | **네트워크 인터페이스**의 **서브넷**(**네트워크 인터페이스 추가**) | **네트워킹 지정** 페이지의 **노드 그룹 네트워크 구성**에 있는 **서브넷** | | **고급 세부 정보**의 **IAM 인스턴스 프로필** | **노드 그룹 구성** 페이지의 **노드 그룹 구성**에 있는 **노드 IAM 역할** | | **고급 세부 정보**의 **종료 동작** 및 **중지 - 최대 절전 모드 동작**. 두 설정 모두 실행 템플릿에서 기본값인 **실행 템플릿 설정에 포함하지 않음**을 유지합니다. | 동일한 사항 없음 Amazon EKS는 Auto Scaling 그룹이 아니라 인스턴스 수명 주기를 제어해야 합니다. | 다음 표에는 관리형 노드 그룹 구성에서 금지된 설정이 나열되어 있습니다. 사용 가능한 경우 시작 템플릿에 필요한 유사한 설정도 나열되어 있습니다. 나열된 설정은 콘솔에 표시되는 설정입니다. AWS CLI 및 SDK에서 비슷한 이름을 가질 수 있습니다. | Amazon EKS 노드 그룹 구성 — 금지됨 | 시작 템플릿 | | --- | --- | | (시작 템플릿에서 사용자 정의 AMI를 지정한 경우,에만 해당) **컴퓨팅 및 크기 조정 구성 설정** 페이지의 **노드 그룹 컴퓨팅 구성**에 있는 **AMI 유형** - 콘솔에 **시작 템플릿에서 지정됨**이라는 메시지와 지정된 AMI ID가 표시됩니다. 시작 템플릿에 **애플리케이션 및 OS 이미지(Amazon 머신 이미지)**가 지정되지 않은 경우, 노드 그룹 구성에서 AMI를 선택할 수 있습니다. | **시작 템플릿 컨텐츠**의 **애플리케이션 및 OS 이미지(Amazon Machine Image)** - 다음 요구 사항 중 하나가 있는 경우, ID를 지정해야 합니다. [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ko_kr/eks/latest/userguide/launch-templates.html) | | **컴퓨팅 및 크기 조정 구성 설정** 페이지의 **노드 그룹 컴퓨팅 구성**에 있는 **디스크 크기** - 콘솔에 **시작 템플릿에 지정됨**이라는 메시지가 표시됩니다. | **스토리지(볼륨)**의 **크기**(**새 볼륨 추가**). 시작 템플릿에서 이 옵션을 지정해야 합니다. | | **네트워킹 지정** 페이지의 **노드 그룹 구성**에 있는 **SSH 키 페어** - 콘솔에 시작 템플릿에 지정되어 있는 키가 표시되거나 **시작 템플릿에 지정되지 않음**이라는 메시지가 표시됩니다. | **키 페어(로그인)**의 **키 페어 이름**. | | 시작 템플릿을 사용할 때 원격 액세스가 허용되는 소스 보안 그룹을 지정할 수 없습니다. | 인스턴스의 **네트워크 설정**에 있는 **보안 그룹** 또는 **네트워크 인터페이스**의 **보안 그룹**(**네트워크 인터페이스 추가**), 두 가지 모두 설정할 수는 없습니다. 자세한 내용은 [사용자 지정 보안 그룹 사용](#launch-template-security-groups) 섹션을 참조하세요. | **참고** 시작 템플릿을 사용하여 노드 그룹을 배포하는 경우 시작 템플릿의 **시작 템플릿 콘텐츠**에서 **인스턴스 유형**을 0개 또는 1개 지정합니다. 또는 콘솔의 **컴퓨팅 및 크기 조정 구성 설정** 페이지에서 **인스턴스 유형**에 대해 0\$120개의 인스턴스 유형을 지정할 수 있습니다. 또는 Amazon EKS API를 사용하는 다른 도구로 인스턴스 유형을 지정할 수 있습니다. 시작 템플릿에서 인스턴스 유형을 지정하고 해당 시작 템플릿을 사용하여 노드 그룹을 배포하는 경우 콘솔에서 인스턴스 유형을 지정하거나 Amazon EKS API를 사용하는 다른 도구를 사용하여 인스턴스 유형을 지정할 수 없습니다. 시작 템플릿, 콘솔 또는 Amazon EKS API를 사용하는 다른 도구를 사용하여 인스턴스 유형을 지정하지 않으면 `t3.medium` 인스턴스 유형이 사용됩니다. 노드 그룹에서 스팟 용량 유형을 사용하는 경우 콘솔을 사용하여 여러 인스턴스 유형을 지정하는 것이 좋습니다. 자세한 내용은 [관리형 노드 그룹 용량](managed-node-groups.md#managed-node-group-capacity-types) 섹션을 참조하세요. 노드 그룹에 배포하는 컨테이너가 인스턴스 메타데이터 서비스 버전 2를 사용하는 경우 시작 템플릿에 **메타데이터 응답 홉 제한**이 `2`로 설정되어 있어야 합니다. 자세한 내용은 **Amazon EC2 사용 설명서의 [인스턴스 메타데이터 및 사용자 데이터](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ec2-instance-metadata.html)를 참조하세요. 시작 템플릿은 유연한 인스턴스 유형 선택을 허용하는 `InstanceRequirements` 기능을 지원하지 않습니다. ## Amazon EC2 인스턴스 태깅 시작 템플릿의 `TagSpecification` 파라미터를 사용하여 노드 그룹의 Amazon EC2 인스턴스에 적용할 태그를 지정할 수 있습니다. `CreateNodegroup` 또는 `UpdateNodegroupVersion`API를 직접 호출하는 IAM 엔터티에는 `ec2:RunInstances` 및 `ec2:CreateTags`에 대한 권한이 있어야 하며, 시작 템플릿에 태그가 추가되어 있어야 합니다. ## 사용자 지정 보안 그룹 사용 시작 템플릿을 사용하여 사용자 지정 Amazon EC2 [보안 그룹](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ec2-security-groups.html) 지정하고 노드 그룹의 인스턴스에 적용할 수 있습니다. 이는 인스턴스 수준 보안 그룹 파라라미터 또는 네트워크 인터페이스 구성 파라미터의 일부로 사용할 수 있습니다. 하지만 인스턴스 수준 및 네트워크 인터페이스 보안 그룹을 모두 지정하는 시작 템플릿을 생성할 수 없습니다. 관리형 노드 그룹과 함께 사용자 지정 보안 그룹을 사용할 때 적용되는 다음 조건을 고려하세요. + AWS Management Console을 사용하면 Amazon EKS는 단일 네트워크 인터페이스 사양이 있는 시작 템플릿만 허용합니다. + 기본적으로 Amazon EKS는 [클러스터 보안 그룹](sec-group-reqs.md)을 노드 그룹의 인스턴스에 적용하여 노드와 제어 플레인 간의 통신을 용이하게 합니다. 앞에서 언급한 옵션 중 하나를 사용하여 시작 템플릿에 사용자 지정 보안 그룹을 지정하는 경우 Amazon EKS는 클러스터 보안 그룹을 추가하지 않습니다. 따라서 보안 그룹의 인바운드 및 아웃바운드 규칙이 클러스터 엔드포인트와의 통신을 사용 설정하는지 확인해야 합니다. 보안 그룹 규칙이 올바르지 않으면 작업자 노드가 클러스터에 참여할 수 없습니다. 보안 그룹 규칙에 대한 자세한 내용은 [클러스터에 대한 Amazon EKS 보안 그룹 요구 사항 보기](sec-group-reqs.md) 부분을 참조하세요. + 노드 그룹의 인스턴스에 대한 SSH 액세스가 필요한 경우 해당 액세스를 허용하는 보안 그룹을 포함합니다. ## Amazon EC2 사용자 데이터 시작 템플릿에는 사용자 정의 사용자 데이터에 대한 부분이 포함되어 있습니다. 개별 사용자 정의 AMI를 수동으로 생성하지 않고 이 섹션에서 노드 그룹에 대한 구성 설정을 지정할 수 있습니다. Bottlerocket에 사용할 수 있는 설정에 대한 자세한 내용은 GitHub의 [Using user data](https://github.com/bottlerocket-os/bottlerocket#using-user-data)을 참조하세요. 인스턴스를 시작할 때 `cloud-init`를 사용하여 시작 템플릿에 Amazon EC2 사용자 데이터를 제공할 수 있습니다. 자세한 내용은 [cloud-init 설명서](https://cloudinit.readthedocs.io/en/latest/index.html)를 참조하세요. 사용자 데이터를 사용하여 일반적인 구성 작업을 수행할 수 있습니다. 여기에는 다음 옵션이 포함됩니다. + [사용자 또는 그룹 포함](https://cloudinit.readthedocs.io/en/latest/topics/examples.html#including-users-and-groups) + [패키지 설치](https://cloudinit.readthedocs.io/en/latest/topics/examples.html#install-arbitrary-packages) 관리형 노드 그룹과 함께 사용되는 시작 템플릿의 Amazon EC2 사용자 데이터는 Amazon Linux AMI의 경우 [MIME 멀티파트 아카이브](https://cloudinit.readthedocs.io/en/latest/topics/format.html#mime-multi-part-archive) 형식이어야 하고 Bottlerocket AMI의 경우 TOML 형식이어야 합니다. 이는 사용자 데이터가 노드가 클러스터에 조인하는 데 필요한 Amazon EKS 사용자 데이터와 병합되기 때문입니다. `kubelet`을 시작하거나 수정하는 명령을 사용자 데이터에 지정하지 마세요. 이는 Amazon EKS에 의해 병합된 사용자 데이터의 일부로 수행됩니다. 노드의 레이블 설정과 같은 특정 `kubelet` 파라미터는 관리형 노드 그룹 API를 통해 직접 구성될 수 있습니다. **참고** 수동으로 시작하거나 사용자 정의 구성 파라미터를 전달하는 등의 고급 `kubelet` 사용자 지정에 대한 자세한 내용은 [AMI 지정](#launch-template-custom-ami) 부분을 참조하세요. 시작 템플릿에 사용자 정의 AMI ID가 지정된 경우 Amazon EKS는 사용자 데이터를 병합하지 않습니다. 다음 세부 정보는 사용자 데이터 섹션에 대한 자세한 정보를 제공합니다. **Amazon Linux 2 사용자 데이터** 여러 사용자 데이터 블록을 단일 MIME 멀티파트 파일로 결합할 수 있습니다. 예를 들어 Docker 대몬을 구성하는 클라우드 boothook를 사용자 지정 패키지를 설치하는 사용자 데이터 셸 스크립트와 결합할 수 있습니다. MIME 멀티파트 파일은 다음과 같은 구성 요소로 이루어집니다. + 콘텐츠 유형 및 요소 경계 선언 - `Content-Type: multipart/mixed; boundary="==MYBOUNDARY=="` + MIME 버전 선언 - `MIME-Version: 1.0` + 다음 구성 요소를 포함하는 하나 이상의 사용자 데이터 블록: + 사용자 데이터 블록의 시작을 나타내는 열린 경계 - `--==MYBOUNDARY==` + 블록에 대한 콘텐츠 유형 선언: `Content-Type: text/cloud-config; charset="us-ascii"`. 콘텐츠 유형에 대한 자세한 내용은 [cloud-init](https://cloudinit.readthedocs.io/en/latest/topics/format.html) 문서를 참조하세요. + 사용자 데이터 콘텐츠(예: 셸 명령 또는 `cloud-init` 지시어 목록) + MIME 멀티파트 파일의 끝을 나타내는 폐쇄 경계: `--==MYBOUNDARY==--` 다음은 직접 파일을 작성하는 데 사용할 수 있는 MIME 멀티파트 파일의 예입니다. ``` MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="==MYBOUNDARY==" --==MYBOUNDARY== Content-Type: text/x-shellscript; charset="us-ascii" #!/bin/bash echo "Running custom user data script" --==MYBOUNDARY==-- ``` **Amazon Linux 2023 사용자 데이터** Amazon Linux 2023(AL2023)에 YAML 구성 스키마를 사용하는 새로운 노드 초기화 프로세스 `nodeadm`이 도입됩니다. 자체 관리형 노드 그룹 또는 시작 템플릿이 있는 AMI를 사용하는 경우 이제 새 노드 그룹을 생성할 때 추가 클러스터 메타데이터를 명시적으로 제공해야 합니다. 최소 필수 파라미터의 [예시](https://awslabs.github.io/amazon-eks-ami/nodeadm/)는 다음과 같으며, 여기에서 `apiServerEndpoint`, `certificateAuthority` 및 서비스 `cidr`가 필수입니다. ``` --- apiVersion: node.eks.aws/v1alpha1 kind: NodeConfig spec: cluster: name: my-cluster apiServerEndpoint: https://example.com certificateAuthority: Y2VydGlmaWNhdGVBdXRob3JpdHk= cidr: 10.100.0.0/16 ``` 대체로 이 구성은 사용자 데이터에 있는 그대로 또는 MIME 멀티파트 문서에 포함되도록 설정합니다. ``` MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="BOUNDARY" --BOUNDARY Content-Type: application/node.eks.aws --- apiVersion: node.eks.aws/v1alpha1 kind: NodeConfig spec: [...] --BOUNDARY-- ``` AL2에서 이러한 파라미터의 메타데이터는 Amazon EKS `DescribeCluster` API 직접 호출에서 확인되었습니다. AL2023 버전에서는 대형 노드 스케일 업 도중 추가 API 직접 호출로 인해 제한이 발생할 위험이 있기 때문에 이러한 동작이 변경되었습니다. 시작 템플릿이 없는 관리형 노드 그룹을 사용하거나 Karpenter를 사용하는 경우 이 변경 사항이 영향을 미치지 않습니다. `certificateAuthority` 및 서비스 `cidr`에 대한 자세한 내용은 *Amazon EKS API 참조*의 [https://docs.aws.amazon.com/eks/latest/APIReference/API_DescribeCluster.html](https://docs.aws.amazon.com/eks/latest/APIReference/API_DescribeCluster.html)를 참조하세요. 다음은 노드를 사용자 지정하기 위한 쉘 스크립트(예: 패키지 설치 또는 컨테이너 이미지 사전 캐싱)를 필수 `nodeadm` 구성과 결합하는 AL2023 사용자 데이터의 전체 예제입니다. 이 예제는 다음을 포함한 일반적인 사용자 지정을 보여줍니다. \$1 추가 시스템 패키지 설치 \$1 포드 시작 시간을 개선하기 위해 컨테이너 이미지 사전 캐싱 \$1 HTTP 프록시 구성 설정 \$1 노드 레이블 지정을 위한 `kubelet` 플래그 구성 ``` MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="BOUNDARY" --BOUNDARY Content-Type: text/x-shellscript; charset="us-ascii" #!/bin/bash set -o errexit set -o pipefail set -o nounset # Install additional packages yum install -y htop jq iptables-services # Pre-cache commonly used container images nohup docker pull public.ecr.aws/eks-distro/kubernetes/pause:3.2 & # Configure HTTP proxy if needed cat > /etc/profile.d/http-proxy.sh << 'EOF' export HTTP_PROXY="http://proxy.example.com:3128" export HTTPS_PROXY="http://proxy.example.com:3128" export NO_PROXY="localhost,127.0.0.1,169.254.169.254,.internal" EOF --BOUNDARY Content-Type: application/node.eks.aws apiVersion: node.eks.aws/v1alpha1 kind: NodeConfig spec: cluster: name: my-cluster apiServerEndpoint: https://example.com certificateAuthority: Y2VydGlmaWNhdGVBdXRob3JpdHk= cidr: 10.100.0.0/16 kubelet: config: clusterDNS: - 10.100.0.10 flags: - --node-labels=app=my-app,environment=production --BOUNDARY-- ``` **Bottlerocket 사용자 데이터** Bottlerocket은 사용자 데이터를 TOML 형식으로 구성합니다. Amazon EKS에서 제공하는 사용자 데이터와 병합할 사용자 데이터를 제공할 수 있습니다. 예를 들어, 추가 `kubelet` 설정을 제공할 수 있습니다. ``` [settings.kubernetes.system-reserved] cpu = "10m" memory = "100Mi" ephemeral-storage= "1Gi" ``` 지원되는 설정에 대한 자세한 내용은 [Bottlerocket 설명서](https://github.com/bottlerocket-os/bottlerocket)를 참조하세요. 사용자 데이터에서 노드 레이블과 [테인트](node-taints-managed-node-groups.md)를 구성할 수 있습니다. 그러나 대신 노드 그룹 내에서 구성하는 것이 좋습니다. 그러면 Amazon EKS에서 이러한 구성을 적용합니다. 사용자 데이터가 병합되면 서식이 유지되지 않지만 내용은 동일하게 유지됩니다. 사용자 데이터에 제공하는 구성은 Amazon EKS에서 구성하는 모든 설정을 재정의합니다. 따라서 `settings.kubernetes.max-pods` 또는 `settings.kubernetes.cluster-dns-ip`를 설정하면 사용자 데이터의 값이 노드에 적용됩니다. Amazon EKS는 모든 유효한 TOML을 지원하지 않습니다. 다음은 지원되지 않는 알려진 형식 목록입니다. + 따옴표 붙은 키 안의 따옴표: `'quoted "value"' = "value"` + 값의 이스케이프된 따옴표: `str = "I’m a string. \"You can quote me\""` + 혼합 부동 소수점 및 정수: `numbers = [ 0.1, 0.2, 0.5, 1, 2, 5 ]` + 배열의 혼합 유형: `contributors = ["[foo@example.com](mailto:foo@example.com)", { name = "Baz", email = "[baz@example.com](mailto:baz@example.com)" }]` + 따옴표 붙은 키가 있는 대괄호로 묶은 헤더: `[foo."bar.baz"]` **Windows 사용자 데이터** Windows 사용자 데이터는 PowerShell 명령을 사용합니다. 관리형 노드 그룹을 생성할 때 사용자 지정 사용자 데이터는 Amazon EKS 관리형 사용자 데이터와 결합됩니다. PowerShell 명령과 관리형 사용자 데이터 명령이 모두 하나의 `` 태그 내에서 차례로 나타납니다. Windows 노드 그룹을 생성할 때 Amazon EKS는 Linux 기반 노드가 클러스터에 조인할 수 있도록 `aws-auth` `ConfigMap`을 업데이트합니다. 서비스는 Windows AMI에 대한 권한을 자동으로 구성하지 않습니다. Windows 노드를 사용하는 경우 액세스 항목 API를 통해 또는 `aws-auth` `ConfigMap`을 직접 업데이트하여 액세스를 관리해야 합니다. 자세한 내용은 [EKS 클러스터에 Windows 노드 배포](windows-support.md) 섹션을 참조하세요. 시작 템플릿에 AMI ID가 지정되어 있지 않으면 사용자 데이터의 Windows Amazon EKS Bootstrap 스크립트를 사용하여 Amazon EKS를 구성하지 마세요. 예시 사용자 데이터는 다음과 같습니다. ``` Write-Host "Running custom user data script" ``` ## AMI 지정 다음 요구 사항 중 하나가 있는 경우 시작 템플릿의 `ImageId` 필드에 AMI ID를 지정합니다. 추가 정보를 보려면 요구 사항을 선택하세요. ### Amazon EKS 최적화 Linux/Bottlerocket AMI에 포함된 `bootstrap.sh` 파일에 인수를 전달하기 위해 사용자 데이터를 제공함 부트스트래핑은 인스턴스가 시작될 때 실행할 수 있는 명령의 추가에 대해 설명하는 데 사용되는 용어입니다. 예를 들어, 부트스트랩을 사용하면 추가 [kubelet](https://kubernetes.io/docs/reference/command-line-tools-reference/kubelet/) 인수를 사용할 수 있습니다. 시작 템플릿을 지정하지 않고 `eksctl`을 사용하여 `bootstrap.sh` 스크립트에 인수를 전달할 수 있습니다. 이를 위해 시작 템플릿의 사용자 데이터 부분에 정보를 지정할 수도 있습니다. **시작 템플릿을 지정하지 않고 eksctl** 다음 내용으로 *my-nodegroup.yaml*이라는 파일을 만듭니다. 모든 *예제 값*을 자신의 값으로 바꾸세요. `--apiserver-endpoint`, `--b64-cluster-ca` 및 `--dns-cluster-ip` 인수는 선택 사항입니다. 그러나 이를 정의하면 `bootstrap.sh` 스크립트가 `describeCluster`를 직접 호출하는 것을 방지할 수 있습니다. 이는 노드를 자주 확장하고 축소하는 프라이빗 클러스터 설정이나 클러스터에서 유용합니다. `bootstrap.sh` 스크립트에 대한 자세한 내용은 GitHub의 [bootstrap.sh](https://github.com/awslabs/amazon-eks-ami/blob/main/templates/al2/runtime/bootstrap.sh) 파일을 참조하세요. + 유일한 필수 인수는 클러스터 이름(*my-cluster*)입니다. + `ami-1234567890abcdef0 `에 대해 최적화된 AMI ID를 검색하려면 다음 섹션을 참조하세요. + [권장 Amazon Linux AMI ID 검색](retrieve-ami-id.md) + [권장 Bottlerocket AMI ID 검색](retrieve-ami-id-bottlerocket.md) + [권장 Microsoft Windows AMI ID 검색](retrieve-windows-ami-id.md) + 클러스터의 *certificate-authority*를 검색하려면 다음 명령을 실행합니다. ``` aws eks describe-cluster --query "cluster.certificateAuthority.data" --output text --name my-cluster --region region-code ``` + 클러스터의 *api-server-endpoint*를 검색하려면 다음 명령을 실행합니다. ``` aws eks describe-cluster --query "cluster.endpoint" --output text --name my-cluster --region region-code ``` + `--dns-cluster-ip`의 값은 `.10`으로 끝나는 서비스 CIDR입니다. 클러스터의 *service-cidr*를 검색하려면 다음 명령을 실행합니다. 예를 들어, 반환된 값이 `ipv4 10.100.0.0/16`인 경우 값은 *10.100.0.10*입니다. ``` aws eks describe-cluster --query "cluster.kubernetesNetworkConfig.serviceIpv4Cidr" --output text --name my-cluster --region region-code ``` + 이 예에서는 추가 `kubelet` 인수를 제공하여 Amazon EKS 최적화 AMI에 포함된 `bootstrap.sh` 스크립트로 사용자 지정 `max-pods` 값을 설정합니다. 노드 그룹 이름은 63자를 초과할 수 없습니다. 문자나 숫자로 시작하되, 나머지 문자의 경우 하이픈과 밑줄을 포함할 수 있습니다. *my-max-pods-value*를 선택하는 방법에 대한 도움말은 을 참조하세요. 관리형 노드 그룹을 사용할 때 `maxPods`를 결정하는 방법에 대한 자세한 내용은 [maxPods 결정 방법](choosing-instance-type.md#max-pods-precedence) 섹션을 참조하세요. ``` --- apiVersion: eksctl.io/v1alpha5 kind: ClusterConfig metadata: name: my-cluster region: region-code managedNodeGroups: - name: my-nodegroup ami: ami-1234567890abcdef0 instanceType: m5.large privateNetworking: true disableIMDSv1: true labels: { x86-al2-specified-mng } overrideBootstrapCommand: | #!/bin/bash /etc/eks/bootstrap.sh my-cluster \ --b64-cluster-ca certificate-authority \ --apiserver-endpoint api-server-endpoint \ --dns-cluster-ip service-cidr.10 \ --kubelet-extra-args '--max-pods=my-max-pods-value' \ --use-max-pods false ``` 사용 가능한 모든 `eksctl` `config` 파일 옵션은 `eksctl` 설명서의 [구성 파일 스키마](https://eksctl.io/usage/schema/)를 참조하세요. `eksctl` 유틸리티는 여전히 사용자를 위해 시작 템플릿을 생성하고 해당 사용자 데이터를 `config` 파일에서 제공되는 데이터로 채웁니다. 다음 명령을 사용하여 노드 그룹을 생성합니다. ``` eksctl create nodegroup --config-file=my-nodegroup.yaml ``` **시작 템플릿의 사용자 데이터** 시작 템플릿의 사용자 데이터 부분에서 다음 정보를 지정합니다. 모든 *예제 값*을 자신의 값으로 바꾸세요. `--apiserver-endpoint`, `--b64-cluster-ca` 및 `--dns-cluster-ip` 인수는 선택 사항입니다. 그러나 이를 정의하면 `bootstrap.sh` 스크립트가 `describeCluster`를 직접 호출하는 것을 방지할 수 있습니다. 이는 노드를 자주 확장하고 축소하는 프라이빗 클러스터 설정이나 클러스터에서 유용합니다. `bootstrap.sh` 스크립트에 대한 자세한 내용은 GitHub의 [bootstrap.sh](https://github.com/awslabs/amazon-eks-ami/blob/main/templates/al2/runtime/bootstrap.sh) 파일을 참조하세요. + 유일한 필수 인수는 클러스터 이름(*my-cluster*)입니다. + 클러스터의 *certificate-authority*를 검색하려면 다음 명령을 실행합니다. ``` aws eks describe-cluster --query "cluster.certificateAuthority.data" --output text --name my-cluster --region region-code ``` + 클러스터의 *api-server-endpoint*를 검색하려면 다음 명령을 실행합니다. ``` aws eks describe-cluster --query "cluster.endpoint" --output text --name my-cluster --region region-code ``` + `--dns-cluster-ip`의 값은 `.10`으로 끝나는 서비스 CIDR입니다. 클러스터의 *service-cidr*를 검색하려면 다음 명령을 실행합니다. 예를 들어, 반환된 값이 `ipv4 10.100.0.0/16`인 경우 값은 *10.100.0.10*입니다. ``` aws eks describe-cluster --query "cluster.kubernetesNetworkConfig.serviceIpv4Cidr" --output text --name my-cluster --region region-code ``` + 이 예에서는 추가 `kubelet` 인수를 제공하여 Amazon EKS 최적화 AMI에 포함된 `bootstrap.sh` 스크립트로 사용자 지정 `max-pods` 값을 설정합니다. *my-max-pods-value*를 선택하는 방법에 대한 도움말은 을 참조하세요. 관리형 노드 그룹을 사용할 때 `maxPods`를 결정하는 방법에 대한 자세한 내용은 [maxPods 결정 방법](choosing-instance-type.md#max-pods-precedence) 섹션을 참조하세요. ``` MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="==MYBOUNDARY==" --==MYBOUNDARY== Content-Type: text/x-shellscript; charset="us-ascii" #!/bin/bash set -ex /etc/eks/bootstrap.sh my-cluster \ --b64-cluster-ca certificate-authority \ --apiserver-endpoint api-server-endpoint \ --dns-cluster-ip service-cidr.10 \ --kubelet-extra-args '--max-pods=my-max-pods-value' \ --use-max-pods false --==MYBOUNDARY==-- ``` ### Amazon EKS 최적화 Windows AMI에 포함된 `Start-EKSBootstrap.ps1` 파일에 인수를 전달하기 위해 사용자 데이터를 제공함 부트스트래핑은 인스턴스가 시작될 때 실행할 수 있는 명령의 추가에 대해 설명하는 데 사용되는 용어입니다. 시작 템플릿을 지정하지 않고 `eksctl`을 사용하여 `Start-EKSBootstrap.ps1` 스크립트에 인수를 전달할 수 있습니다. 이를 위해 시작 템플릿의 사용자 데이터 부분에 정보를 지정할 수도 있습니다. 사용자 지정 Windows AMI ID를 지정하려면 다음과 같은 사항을 고려하세요. + 시작 템플릿을 사용하고 사용자 데이터 부분의 필수 부트스트랩 명령을 제공해야 합니다. 원하는 Windows ID를 검색하려면 [최적화된 Windows AMI가 있는 노드 생성](eks-optimized-windows-ami.md) 테이블을 사용할 수 있습니다. + 몇 가지 제한과 조건이 있습니다. 예를 들어, AWS IAM Authenticator 구성 맵에 `eks:kube-proxy-windows`를 추가해야 합니다. 자세한 내용은 [AMI ID 지정 시 제한과 조건](#mng-ami-id-conditions) 섹션을 참조하세요. 시작 템플릿의 사용자 데이터 부분에서 다음 정보를 지정합니다. 모든 *예제 값*을 자신의 값으로 바꾸세요. `-APIServerEndpoint`, `-Base64ClusterCA` 및 `-DNSClusterIP` 인수는 선택 사항입니다. 그러나 이를 정의하면 `Start-EKSBootstrap.ps1` 스크립트가 `describeCluster`를 직접 호출하는 것을 방지할 수 있습니다. + 유일한 필수 인수는 클러스터 이름(*my-cluster*)입니다. + 클러스터의 *certificate-authority*를 검색하려면 다음 명령을 실행합니다. ``` aws eks describe-cluster --query "cluster.certificateAuthority.data" --output text --name my-cluster --region region-code ``` + 클러스터의 *api-server-endpoint*를 검색하려면 다음 명령을 실행합니다. ``` aws eks describe-cluster --query "cluster.endpoint" --output text --name my-cluster --region region-code ``` + `--dns-cluster-ip`의 값은 `.10`으로 끝나는 서비스 CIDR입니다. 클러스터의 *service-cidr*를 검색하려면 다음 명령을 실행합니다. 예를 들어, 반환된 값이 `ipv4 10.100.0.0/16`인 경우 값은 *10.100.0.10*입니다. ``` aws eks describe-cluster --query "cluster.kubernetesNetworkConfig.serviceIpv4Cidr" --output text --name my-cluster --region region-code ``` + 추가 인수는 [부트스트랩 스크립트 구성 파라미터](eks-optimized-windows-ami.md#bootstrap-script-configuration-parameters) 부분을 참조하세요. **참고** 사용자 지정 서비스 CIDR을 사용하는 경우 `-ServiceCIDR` 파라미터를 사용하여 CIDR을 지정해야 합니다. 그렇지 않으면 클러스터의 포드에 대한 DNS 확인이 실패합니다. ``` [string]$EKSBootstrapScriptFile = "$env:ProgramFiles\Amazon\EKS\Start-EKSBootstrap.ps1" & $EKSBootstrapScriptFile -EKSClusterName my-cluster ` -Base64ClusterCA certificate-authority ` -APIServerEndpoint api-server-endpoint ` -DNSClusterIP service-cidr.10 ``` ### 특정 보안, 규정 준수 또는 내부 정책 요구 사항으로 인해 사용자 정의 AMI 실행함 자세한 내용은 *Amazon EC2 사용 설명서*에서 [Amazon Machine Image(AMI)](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/AMIs.html)를 참조하세요. Amazon EKS AMI 빌드 사양에는 Amazon Linux를 기반으로 사용자 지정 Amazon EKS AMI를 구축하기 위한 리소스 및 구성 스크립트가 포함되어 있습니다. 자세한 내용은 GitHub에서 [Amazon EKS AMI 빌드 사양](https://github.com/awslabs/amazon-eks-ami/) 섹션을 참조하세요. 다른 운영 체제와 함께 설치된 사용자 지정 AMI를 생성하려면 GitHub에서 [Amazon EKS 샘플 사용자 지정 AMI](https://github.com/aws-samples/amazon-eks-custom-amis) 섹션을 참조하세요. 관리형 노드 그룹에 사용되는 시작 템플릿에서는 AMI ID에 동적 파라미터 참조를 사용할 수 없습니다. **중요** AMI를 지정할 때 Amazon EKS는 클러스터의 컨트롤 플레인 버전을 기준으로 AMI에 포함된 Kubernetes 버전을 검증하지 않습니다. 사용자 지정 AMI의 Kubernetes 버전이 [Kubernetes 버전 스큐 정책](https://kubernetes.io/releases/version-skew-policy)을 준수하는지 확인하는 것은 사용자의 책임입니다. 노드의 `kubelet` 버전은 클러스터 버전보다 최신 버전이어서는 안 됨 노드의 `kubelet` 버전은 클러스터 버전 뒤로 최대 3개 이상의 마이너 버전(Kubernetes 버전 `1.28` 이상의 경우)이거나 클러스터 버전 뒤로 최대 2개의 마이너 버전(Kubernetes 버전 `1.27` 이하의 경우)이어야 함 버전 스큐를 위반하는 관리형 노드 그룹을 생성하면 다음과 같은 상황이 발생할 수 있습니다. 노드가 클러스터에 조인하지 못함 정의되지 않은 동작 또는 API 비호환성 클러스터 불안정성 또는 워크로드 장애 AMI를 지정할 때 Amazon EKS는 사용자 데이터를 병합하지 않습니다. 사용자가 필요한 `bootstrap` 명령을 사용하여 노드를 클러스터에 조인해야 합니다. 노드가 클러스터에 조인되지 않은 경우 Amazon EKS `CreateNodegroup` 및 `UpdateNodegroupVersion` 작업도 실패합니다. ## AMI ID 지정 시 제한과 조건 다음은 관리형 노드 그룹으로 AMI ID를 지정하는 것과 관련된 제한 및 조건입니다. + 시작 템플릿에서 AMI ID를 지정하는 것과 AMI ID를 지정하지 않는 것 사이를 전환하려면 새 노드 그룹을 생성해야 합니다. + 최신 AMI 버전을 사용할 수 있는 경우에도 콘솔에 알림이 표시되지 않습니다. 노드 그룹을 최신 AMI 버전으로 업데이트하려면 업데이트된 AMI ID로 시작 템플릿의 새 버전을 생성해야 합니다. 그런 다음 새 시작 템플릿 버전으로 노드 그룹을 업데이트해야 합니다. + AMI ID를 지정하는 경우 API에서 다음 필드를 설정할 수 없습니다. + `amiType` + `releaseVersion` + `version` + AMI ID를 지정하는 경우 API에 설정된 모든 `taints`가 비동기적으로 적용됩니다. 노드가 클러스터에 합류하기 전에 테인트를 적용하려면 `kubelet` 명령줄 플래그를 사용하여 사용자 데이터의 `--register-with-taints`에 테인트를 전달해야 합니다. 자세한 내용은 Kubernetes 문서의 [kubelet](https://kubernetes.io/docs/reference/command-line-tools-reference/kubelet/)를 참조하세요. + Windows 관리형 노드 그룹에 사용자 지정 AMI ID를 지정할 때는 AWS IAM Authenticator 구성 맵에 `eks:kube-proxy-windows`를 추가합니다. DNS가 제대로 작동하려면 필요합니다. 1. 편집을 위해 AWS IAM Authenticator 구성 맵을 엽니다. ``` kubectl edit -n kube-system cm aws-auth ``` 1. Windows 노드와 연결된 각 `rolearn` 아래의 `groups` 목록에 이 항목을 추가합니다. 구성 맵은 [aws-auth-cm-windows.yaml ](https://s3.us-west-2.amazonaws.com/amazon-eks/cloudformation/2020-10-29/aws-auth-cm-windows.yaml)과 비슷해야 합니다. ``` - eks:kube-proxy-windows ``` 1. 파일을 저장하고 텍스트 편집기를 종료합니다. + 사용자 지정 시작 템플릿을 사용하는 모든 AMI의 경우 관리형 노드 그룹의 `HttpPutResponseHopLimit` 기본값은 `2`로 설정됩니다.