**이 페이지 개선에 도움 주기** 이 사용자 가이드에 기여하려면 모든 페이지의 오른쪽 창에 있는 **GitHub에서 이 페이지 편집** 링크를 선택합니다. # AWS Outposts를 사용한 Amazon EKS 온프레미스 배포 Amazon EKS를 사용하여 AWS Outposts에서 온프레미스 Kubernetes 애플리케이션을 실행할 수 있습니다. 다음과 같은 방법으로 Outposts에 Amazon EKS를 배포할 수 있습니다. + **확장 클러스터** - AWS 리전에서 Kubernetes 컨트롤 플레인을 실행하고 Outpost에서 노드를 실행합니다. + **로컬 클러스터** - Outpost에서 Kubernetes 컨트롤 플레인과 노드를 실행합니다. 두 배포 옵션 모두 AWS에서 Kubernetes 컨트롤 플레인을 완전히 관리합니다. 클라우드에서 사용하는 것과 동일한 Amazon EKS API, 도구 및 콘솔을 사용하여 Outposts에서 Amazon EKS를 생성하고 실행할 수 있습니다. 다음 다이어그램은 이러한 배포 옵션을 보여줍니다. ![\[Outpost 배포 옵션\]](http://docs.aws.amazon.com/ko_kr/eks/latest/userguide/images/outposts-deployment-options.png) ## 각 배포 옵션을 사용해야 하는 경우 로컬 클러스터와 확장 클러스터 모두 범용 배포 옵션이며 다양한 용도에 사용할 수 있습니다. 로컬 클러스터를 통해 전체 Amazon EKS 클러스터를 Outposts에서 로컬로 실행할 수 있습니다. 이 옵션을 통해 클라우드에 대한 일시적인 네트워크 연결 해제로 인해 발생할 수 있는 애플리케이션 가동 중지 위험을 완화할 수 있습니다. 광케이블 절단 또는 기상 현상이 이러한 네트워크 연결 해제의 원인일 수 있습니다. 전체 Amazon EKS 클러스터가 Outposts에서 로컬로 실행되기 때문에 애플리케이션을 계속 사용할 수 있습니다. 클라우드에 대한 네트워크 연결 해제 중 클러스터 작업을 수행할 수 있습니다. 자세한 내용은 [네트워크 연결 해제에 대비하여 AWS Outposts에 로컬 Amazon EKS 클러스터 준비](eks-outposts-network-disconnects.md) 섹션을 참조하세요. Outposts부터 상위 AWS 리전까지 네트워크 연결 품질이 우려되고 네트워크 연결 해제를 통한 고가용성이 필요한 경우 로컬 클러스터 배포 옵션을 사용합니다. 확장 클러스터가 있으면 Kubernetes 컨트롤 플레인이 상위 AWS 리전에서 실행되기 때문에 Outpost의 용량을 절약할 수 있습니다. Outpost부터 AWS 리전까지 안정적이고 중복된 네트워크 연결에 투자할 수 있으면 이 옵션이 적합합니다. 이 옵션에는 네트워크 연결 품질이 매우 중요합니다. Kubernetes에서 Kubernetes 컨트롤 플레인과 노드 간 네트워크 연결 해제를 처리하는 방법에서는 애플리케이션 가동 중지가 발생할 수도 있습니다. Kubernetes의 동작에 대한 자세한 내용은 쿠버네티스 문서의 [스케줄링, 선점(Preemption), 축출(Eviction)](https://kubernetes.io/docs/concepts/scheduling-eviction/)을 참조하세요. ## 배포 옵션 비교 다음 표에 두 옵션의 차이점이 비교되어 있습니다. | Feature | 확장 클러스터 | 로컬 클러스터 | | --- | --- | --- | | Kubernetes 제어 영역 위치 | AWS 리전 | Outpost | | Kubernetes 컨트롤 플레인 계정 | AWS 계정 | 사용자 계정 | | 지역별 가용성 | [서비스 엔드포인트](https://docs.aws.amazon.com/general/latest/gr/eks.html#eks_region) 참조 | 미국 동부(오하이오), 미국 동부(버지니아 북부), 미국 서부(캘리포니아 북부), 미국 서부(오레곤), 아시아 태평양(서울), 아시아 태평양(싱가포르), 아시아 태평양(시드니), 아시아 태평양(도쿄), 캐나다(중부), 유럽(프랑크푸르트), 유럽(아일랜드), 유럽(런던), 중동(바레인) 및 남아메리카(상파울루) | | Kubernetes 마이너 버전 | eks/latest/userguide/kubernetes-versions.html[Supported Amazon EKS versions,type="documentation"]. | eks/latest/userguide/kubernetes-versions.html[Supported Amazon EKS versions,type="documentation"]. | | 플랫폼 버전 | [EKS 플랫폼 버전](https://docs.aws.amazon.com/eks/latest/userguide/platform-versions.html) 참조 | [Kubernetes 및 AWS Outposts에 대한 Amazon EKS 플랫폼 버전 알아보기](eks-outposts-platform-versions.md) 섹션 참조 | | Outpost 폼 팩터 | Outpost 랙 | Outpost 랙 | | 사용자 인터페이스 | AWS Management Console, AWS CLI, Amazon EKS API, `eksctl`, AWS CloudFormation 및 Terraform | AWS Management Console, AWS CLI, Amazon EKS API, `eksctl`, AWS CloudFormation 및 Terraform | | 관리형 정책 | [AmazonEKSClusterPolicy](security-iam-awsmanpol.md#security-iam-awsmanpol-amazoneksclusterpolicy) 및 [AWS 관리형 정책: AmazonEKSServiceRolePolicy](security-iam-awsmanpol.md#security-iam-awsmanpol-amazoneksservicerolepolicy) | [AmazonEKSLocalOutpostClusterPolicy](security-iam-awsmanpol.md#security-iam-awsmanpol-amazonekslocaloutpostclusterpolicy) 및 [AWS 관리형 정책: AmazonEKSLocalOutpostServiceRolePolicy](security-iam-awsmanpol.md#security-iam-awsmanpol-amazonekslocaloutpostservicerolepolicy) | | 클러스터 VPC 및 서브넷 | [VPC 및 서브넷에 대한 Amazon EKS 네트워킹 요구 사항 보기](network-reqs.md) 섹션 참조 | [AWS 출력에서 Amazon EKS 클러스터를 위한 VPC 및 서브넷 생성](eks-outposts-vpc-subnet-requirements.md) 섹션 참조 | | 클러스터 엔드포인트 액세스 | 퍼블릭이나 프라이빗 또는 둘 다 | 프라이빗 전용 | | Kubernetes API 서버 인증 | AWS Identity and Access Management(IAM) 및 OIDC | IAM 및 `x.509` 인증서 | | 노드 유형 | 자체 관리형만 | 자체 관리형만 | | 노드 컴퓨팅 유형 | Amazon EC2 온디맨드 | Amazon EC2 온디맨드 | | 노드 스토리지 유형 | Amazon EBS `gp2` 및 로컬 NVMe SSD | Amazon EBS `gp2` 및 로컬 NVMe SSD | | Amazon EKS 최적화 AMI | Amazon Linux Windows 및 Bottlerocket | Amazon Linux만 해당 | | IP 버전 | `IPv4` 전용 | `IPv4` 전용 | | 추가 기능 | Amazon EKS 추가 기능 또는 자체 관리형 추가 기능 | 자체 관리형 추가 기능만 | | 기본 컨테이너 네트워크 인터페이스 | Kubernetes용 Amazon VPC CNI 플러그인 | Kubernetes용 Amazon VPC CNI 플러그인 | | Kubernetes 컨트롤 플레인 로그 | Amazon CloudWatch Logs | Amazon CloudWatch Logs | | 로드 밸런싱 | [AWS 로드 밸런서 컨트롤러](aws-load-balancer-controller.md)를 사용하여 Application Load Balancer만 프로비저닝(Network Load Balancer 없음) | [AWS 로드 밸런서 컨트롤러](aws-load-balancer-controller.md)를 사용하여 Application Load Balancer만 프로비저닝(Network Load Balancer 없음) | | 보안 암호 봉투 암호화 | [기존 클러스터에서 KMS를 사용하여 Kubernetes 비밀 암호화](enable-kms.md) 섹션 참조 | 지원되지 않음 | | 서비스 계정에 대한 IAM 역할 | [서비스 계정에 대한 IAM 역할](iam-roles-for-service-accounts.md) 섹션 참조 | 지원되지 않음 | | 문제 해결 | [Amazon EKS 클러스터 및 노드 관련 문제 해결](troubleshooting.md) 섹션 참조 | [AWS Outposts의 로컬 Amazon EKS 클러스터 문제 해결](eks-outposts-troubleshooting.md) 부분 참조 | **Topics** # 고가용성을 위해 AWS Outposts에서 로컬 Amazon EKS 클러스터 생성 로컬 클러스터를 사용하여 전체 Amazon EKS 클러스터를 AWS Outposts에서 로컬로 실행할 수 있습니다. 그러면 클라우드에 대한 일시적인 네트워크 연결 해제로 인해 발생할 수 있는 애플리케이션 가동 중지 위험 완화에 도움이 됩니다. 광케이블 절단 또는 기상 현상이 이러한 연결 해제의 원인일 수 있습니다. 전체 Kubernetes 클러스터가 Outposts에서 로컬로 실행되기 때문에 애플리케이션을 계속 사용할 수 있습니다. 클라우드에 대한 네트워크 연결 해제 중 클러스터 작업을 수행할 수 있습니다. 자세한 내용은 [네트워크 연결 해제에 대비하여 AWS Outposts에 로컬 Amazon EKS 클러스터 준비](eks-outposts-network-disconnects.md) 섹션을 참조하세요. 다음 다이어그램은 로컬 클러스터 배포를 보여줍니다. ![\[Outpost 로컬 클러스터\]](http://docs.aws.amazon.com/ko_kr/eks/latest/userguide/images/outposts-local-cluster.png) 로컬 클러스터는 일반적으로 Outposts 랙과 함께 사용할 수 있습니다. ## 지원되는 AWS 리전 미국 동부(오하이오), 미국 동부(버지니아 북부), 미국 서부(캘리포니아 북부), 미국 서부(오레곤), 아시아 태평양(서울), 아시아 태평양(싱가포르), 아시아 태평양(시드니), 아시아 태평양(도쿄), 캐나다(중부), 유럽(프랑크푸르트), 유럽(아일랜드), 유럽(런던), 중동(바레인) 및 남아메리카(상파울루) AWS 리전에서 로컬 클러스터를 생성할 수 있습니다. 지원되는 기능에 대한 자세한 내용을 알아보려면 [배포 옵션 비교](eks-outposts.md#outposts-overview-comparing-deployment-options) 섹션을 참조하세요. **Topics** # AWS Outposts에 Amazon EKS 클러스터 배포 이 주제에서는 Outpost에서 로컬 클러스터를 실행할 때 고려할 내용의 개요를 제공합니다. 이 주제에서는 Outpost에 로컬 클러스터를 배포하는 방법에 대한 지침도 제공합니다. **중요** 이러한 고려 사항은 관련 Amazon EKS 설명서에 나와 있지 않습니다. 기타 Amazon EKS 설명서 주제가 여기의 고려 사항과 충돌하는 경우 여기의 고려 사항을 따릅니다. 이러한 고려 사항은 변경될 수 있으며 자주 변경될 수 있습니다. 따라서 이 주제를 주기적으로 검토하는 것이 좋습니다. AWS 클라우드에서 클러스터를 생성하기 위한 고려 사항과 많은 고려 사항이 다릅니다. + 로컬 클러스터는 Outpost 랙만 지원합니다. 단일 로컬 클러스터는 단일 논리적 Outpost를 구성하는 여러 물리적 Outpost 랙에서 실행할 수 있습니다. 단일 로컬 클러스터는 여러 논리적 Outposts에서 실행할 수 없습니다. 각 논리적 Outpost에는 단일 Outpost ARN이 있습니다. + 로컬 클러스터는 Outpost의 계정에서 Kubernetes 컨트롤 플레인을 실행하고 관리합니다. Kubernetes 컨트롤 플레인 인스턴스에 대한 워크로드를 실행하거나 Kubernetes 컨트롤 플레인 구성 요소를 수정할 수 없습니다. 이러한 노드는 Amazon EKS 서비스에서 관리합니다. Kubernetes 컨트롤 플레인에 대한 변경 사항은 패치와 같은 자동 Amazon EKS 관리 작업 시 유지되지 않습니다. + 로컬 클러스터는 자체 관리형 추가 기능 및 자체 관리형 Amazon Linux 노드 그룹을 지원합니다. [Kubernetes용 Amazon VPC CNI 플러그인](managing-vpc-cni.md), [kube-proxy](managing-kube-proxy.md) 및 [CoreDNS](managing-coredns.md) 추가 기능은 로컬 클러스터에 자동으로 설치됩니다. + 로컬 클러스터는 Outposts에서 Amazon EBS를 사용해야 합니다. Outpost에는 Kubernetes 컨트롤 플레인 스토리지에 사용할 수 있는 Amazon EBS가 있어야 합니다. Outposts는 Amazon EBS `gp2` 볼륨만 지원합니다. + Amazon EBS 지원 Kubernetes `PersistentVolumes`는 Amazon EBS CSI 드라이버를 사용하여 지원됩니다. + 로컬 클러스터의 컨트롤 플레인 인스턴스는 [가용성이 높은 스택 토폴로지](https://kubernetes.io/docs/setup/production-environment/tools/kubeadm/ha-topology/)로 설정됩니다. 쿼럼을 유지하려면 컨트롤 플레인 인스턴스 3개 중 2개가 항상 정상 상태여야 합니다. 쿼럼이 손실된 경우 새 관리형 인스턴스를 활성화하려면 일부 서비스 측 작업이 필요하므로 AWS 지원팀에 문의하세요. **사전 조건** + [Outposts 배포 옵션](eks-outposts.md#outposts-overview-comparing-deployment-options), [용량 고려 사항에 따라 AWS Outposts에서 Amazon EKS 클러스터의 인스턴스 유형 및 배치 그룹 선택하기](eks-outposts-capacity-considerations.md), [VPC 요구 사항 및 고려 사항](eks-outposts-vpc-subnet-requirements.md)을 숙지하세요. + 기존 Outpost. 자세한 내용은 [AWS Outposts이란 무엇입니까?](https://docs.aws.amazon.com/outposts/latest/userguide/what-is-outposts.html) 섹션을 참조하세요. + 컴퓨터 또는 AWS CloudShell에 설치된 `kubectl` 명령줄 도구. 버전은 클러스터의 Kubernetes 버전과 동일하거나 최대 하나 이전 또는 이후의 마이너 버전일 수 있습니다. 예를 들어, 클러스터 버전이 `1.29`인 경우 `kubectl` 버전 `1.28`, `1.29` 또는 `1.30`를 함께 사용할 수 있습니다. `kubectl`을 설치하거나 업그레이드하려면 [`kubectl` 및 `eksctl` 설정](install-kubectl.md) 부분을 참조하세요. + 장치에 설치 및 구성된 AWS 명령줄 인터페이스(AWS CLI)의 버전 `2.12.3` 이상 또는 버전 `1.27.160` 이상 또는 AWS CloudShell. 현재 버전을 확인하려면 `aws --version | cut -d / -f2 | cut -d ' ' -f1`을 사용합니다. `yum`, `apt-get` 또는 macOS용 Homebrew와 같은 패키지 관리자는 최신 버전의 AWS CLI 이전에 나온 버전이 몇 가지 있을 때도 있습니다. 최신 버전을 설치하려면 * AWS 명령줄 인터페이스 사용 설명서*에서 [설치](https://docs.aws.amazon.com/cli/latest/userguide/cli-chap-install.html) 및 [aws config를 사용하여 빠른 구성](https://docs.aws.amazon.com/cli/latest/userguide/cli-configure-quickstart.html#cli-configure-quickstart-config)을 참조하세요. AWS CloudShell에 설치된 AWS CLI 버전도 최신 버전보다 여러 버전 이전일 수도 있습니다. 업데이트하려면 * AWS CloudShell 사용 설명서*의 [홈 디렉터리에 AWS CLI 설치하기](https://docs.aws.amazon.com/cloudshell/latest/userguide/vm-specs.html#install-cli-software)를 참조하세요. + Amazon EKS 클러스터에 대한 `create` 및 `describe` 작업을 수행할 수 있는 권한이 있는 IAM 보안 주체(사용자 또는 역할). 자세한 내용은 [Outpost에서 로컬 Kubernetes 클러스터 생성](security-iam-id-based-policy-examples.md#policy-create-local-cluster) 및 [모든 클러스터 나열 또는 설명](security-iam-id-based-policy-examples.md#policy-example2) 섹션을 참조하세요. 로컬 Amazon EKS 클러스터가 생성될 때 클러스터를 생성하는 [IAM 보안 주체](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles.html#iam-term-principal)가 영구적으로 추가됩니다. 위탁자는 특히 Kubernetes RBAC 권한 부여 표에 관리자로 추가됩니다. 이 엔터티에는 `system:masters` 권한이 있습니다. 이 엔터티의 ID는 클러스터 구성에 표시되지 않습니다. 따라서 클러스터를 생성한 엔터티를 기록하고 절대로 삭제하지 않도록 하는 것이 중요합니다. 처음에는 서버를 생성한 위탁자만 `kubectl`을 사용하여 Kubernetes API 서버를 직접적으로 직접 호출할 수 있습니다. 콘솔을 사용하여 클러스터를 생성하는 경우 클러스터에서 `kubectl` 명령을 실행할 때 동일한 IAM 보안 인증 정보가 AWS SDK 보안 인증 정보 체인에 있어야 합니다. 클러스터가 생성되면 클러스터에 대한 액세스 권한을 다른 IAM 보안 주체에 부여할 수 있습니다. ## Amazon EKS 로컬 클러스터 생성 이 페이지에 설명된 다음 도구를 사용하여 로컬 클러스터를 생성할 수 있습니다. + [`eksctl`](#eksctl_create_cluster_outpost) + [AWS Management Console](#console_create_cluster_outpost) [AWS CLI](https://docs.aws.amazon.com/cli/latest/reference/eks/create-cluster.html), [Amazon EKS API](https://docs.aws.amazon.com/eks/latest/APIReference/API_CreateCluster.html), [AWS SDK](https://aws.amazon.com/developer/tools/), [AWS CloudFormation](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/aws-properties-eks-cluster-outpostconfig.html) 또는 [Terraform](https://registry.terraform.io/modules/terraform-aws-modules/eks/aws/latest)을 사용하여 Outposts에서 클러스터를 생성할 수도 있습니다. ### `eksctl` **`eksctl`를 사용하여 클러스터를 생성하려면** 1. 장치 또는 AWS CloudShell에 `eksctl` 명령줄 도구의 버전 `0.215.0` 이상을 설치합니다. `eksctl`을 설치 또는 업그레이드하려면 `eksctl` 설명서에서 [설치](https://eksctl.io/installation)를 참조하세요. 1. 다음 콘텐츠를 디바이스에 복사합니다. 다음 값을 바꾼 다음 수정된 명령을 실행하여 `outpost-control-plane.yaml` 파일을 생성합니다. + *region-code*를 클러스터를 만들려는 [지원되는 AWS 리전](eks-outposts-local-cluster-overview.md#outposts-control-plane-supported-regions)으로 바꿉니다. + *my-cluster*를 클러스터의 이름으로 바꿉니다. 이름에는 영숫자(대소문자 구분)와 하이픈만 사용할 수 있습니다. 영숫자로 시작해야 하며 100자 이하여야 합니다. 이름은 클러스터를 생성하는 AWS 리전과 AWS 계정 내에서 고유해야 합니다. 이름은 클러스터를 생성하는 AWS 리전과 AWS 계정 내에서 고유해야 합니다. + *vpc-ExampleID1*과 *subnet-ExampleID1*을 기존 VPC 및 서브넷의 ID로 바꿉니다. VPC 및 서브넷은 [AWS Outposts에서 Amazon EKS 클러스터에 대한 VPC 및 서브넷 생성](eks-outposts-vpc-subnet-requirements.md)의 요구 사항을 충족해야 합니다. + *uniqueid*를 Outpost의 ID로 바꿉니다. + *m5.large*를 Outpost에서 사용 가능한 인스턴스 유형으로 바꿉니다. 인스턴스 유형을 선택하기 전에 [용량 고려 사항에 따라 AWS Outposts의 Amazon EKS 클러스터에 대한 인스턴스 유형 및 배치 그룹 선택](eks-outposts-capacity-considerations.md) 섹션을 참조하세요. 3개의 컨트롤 플레인 인스턴스가 배포됩니다. 이 수는 변경할 수 없습니다. ``` cat >outpost-control-plane.yaml < **AWS Management Console를 사용하여 클러스터를 생성하려면** 1. Amazon EKS 요구 사항을 충족하는 기존 VPC와 서브넷이 필요합니다. 자세한 내용은 [AWS 출력에서 Amazon EKS 클러스터를 위한 VPC 및 서브넷 생성](eks-outposts-vpc-subnet-requirements.md) 섹션을 참조하세요. 1. 이미 로컬 클러스터 IAM 역할이 있거나 `eksctl`을 사용하여 클러스터를 생성하려는 경우 이 단계를 건너뛸 수 있습니다. 기본적으로 `eksctl`은 사용자를 위한 역할을 생성합니다. 1. 다음 명령을 실행하여 IAM 신뢰 정책 JSON 파일을 생성합니다. ``` { "Version":"2012-10-17", "Statement": [ { "Effect": "Allow", "Principal": { "Service": "ec2.amazonaws.com" }, "Action": "sts:AssumeRole" } ] } ``` 1. Amazon EKS 클러스터 IAM 역할을 생성합니다. [IAM 보안 주체](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles.html#iam-term-principal)를 생성하려면 역할을 생성하는 IAM 보안 주체에 `iam:CreateRole` 작업(권한)을 할당해야 합니다. ``` aws iam create-role --role-name myAmazonEKSLocalClusterRole --assume-role-policy-document file://"eks-local-cluster-role-trust-policy.json" ``` 1. [AmazonEKSLocalOutpostClusterPolicy](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/AmazonEKSLocalOutpostClusterPolicy.html) Amazon EKS 관리형 정책을 역할에 연결합니다. IAM 정책을 [IAM 보안 주체](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles.html#iam-term-principal)에 연결하려면 정책을 연결하는 보안 주체에 `iam:AttachUserPolicy` 또는 `iam:AttachRolePolicy`의 IAM 작업(권한) 중 하나를 할당해야 합니다. ``` aws iam attach-role-policy --policy-arn arn:aws:iam::aws:policy/AmazonEKSLocalOutpostClusterPolicy --role-name myAmazonEKSLocalClusterRole ``` 1. [Amazon EKS 콘솔](https://console.aws.amazon.com/eks/home#/clusters)을 엽니다. 1. 콘솔 화면 상단에서 [지원되는 AWS 리전](eks-outposts-local-cluster-overview.md#outposts-control-plane-supported-regions)을 선택했는지 확인합니다. 1. **클러스터 추가**를 선택하고 **생성**을 선택합니다. 1. **클러스터 구성** 페이지에서 다음 필드의 값을 입력하거나 선택합니다. + **Kubernetes 컨트롤 플레인 위치** – AWS Outposts를 선택합니다. + **Outpost ID** - 컨트롤 플레인을 생성할 Outpost의 ID를 선택합니다. + **인스턴스 유형** - 인스턴스 유형을 선택합니다. Outpost에서 사용 가능한 인스턴스 유형만 표시됩니다. 드롭다운 목록에서 각 인스턴스 유형은 인스턴스 유형이 권장되는 노드 수를 설명합니다. 인스턴스 유형을 선택하기 전에 [용량 고려 사항에 따라 AWS Outposts의 Amazon EKS 클러스터에 대한 인스턴스 유형 및 배치 그룹 선택](eks-outposts-capacity-considerations.md) 부분을 참조하세요. 모든 복제본은 동일한 인스턴스 유형을 사용하여 배포됩니다. 클러스터가 생성된 후에는 인스턴스 유형을 변경할 수 없습니다. 3개의 컨트롤 플레인 인스턴스가 배포됩니다. 이 수는 변경할 수 없습니다. + **이름** - 클러스터의 이름 AWS 계정에서 고유해야 합니다. 이름에는 영숫자(대소문자 구분)와 하이픈만 사용할 수 있습니다. 영숫자로 시작해야 하며 100자 이하여야 합니다. 이름은 클러스터를 생성하는 AWS 리전과 AWS 계정 내에서 고유해야 합니다. 이름은 클러스터를 생성하는 AWS 리전과 AWS 계정 내에서 고유해야 합니다. + **Kubernetes 버전** – 클러스터에 사용하려는 Kubernetes 버전을 선택합니다. 이전 버전이 필요한 경우가 아니면 최신 버전을 선택하는 것이 좋습니다. + **클러스터 서비스 역할** - 이전 단계에서 생성한 Amazon EKS 클러스터 IAM 역할을 선택하여 Kubernetes 컨트롤 플레인에서 AWS 리소스를 관리하게 할 수 있습니다. + **Kubernetes 클러스터 관리자 액세스** – Kubernetes 클러스터를 생성하는 IAM 위탁자(역할 또는 사용자)가 클러스터의 Kubernetes 객체에 대한 관리자 액세스 권한을 갖도록 하려면 기본값(허용)을 그대로 수락합니다. Amazon EKS는 IAM 보안 주체에 대한 액세스 항목을 생성하고 클러스터 관리자에게 액세스 항목에 대한 권한을 부여합니다. 액세스 항목에 대한 자세한 내용은 [EKS 액세스 항목을 사용한 IAM 사용자에게 Kubernetes에 대한 액세스 권한 부여](access-entries.md) 섹션을 참조하세요. 클러스터를 생성하는 주체가 아닌 다른 IAM 위탁자가 Kubernetes 클러스터 객체에 대한 관리자 액세스 권한을 갖도록 하려면 거부 옵션을 선택합니다. 클러스터를 생성한 후 액세스 항목을 생성할 수 있는 IAM 권한이 있는 IAM 위탁자는 Kubernetes 클러스터 객체에 액세스해야 하는 모든 IAM 위탁자에 대한 액세스 항목을 추가할 수 있습니다. 필수 IAM 권한에 대한 자세한 내용은 서비스 권한 부여 참조에서 [Actions defined by Amazon Elastic Kubernetes Service](https://docs.aws.amazon.com/service-authorization/latest/reference/list_amazonelastickubernetesservice.html#amazonelastickubernetesservice-actions-as-permissions)를 참조하세요. 거부 옵션을 선택하고 액세스 항목을 생성하지 않으면 어떤 IAM 위탁자도 클러스터의 Kubernetes 객체에 액세스할 수 없습니다. + **태그**-(선택사항) 클러스터에 태그를 추가합니다. 자세한 내용은 [태그를 사용하여 Amazon EKS 리소스 구성](eks-using-tags.md) 섹션을 참조하세요. 이 페이지를 모두 완료하면 **다음**을 선택합니다. 1. **네트워킹 지정** 페이지에서 다음 필드의 값을 선택합니다. + **VPC** – 기존 VPC를 선택합니다. VPC에는 생성하려는 클러스터, 노드 및 기타 Kubernetes 리소스에 사용 가능한 IP 주소가 충분해야 합니다. VPC는 [VPC 요구 사항 및 고려 사항의 요구 사항](eks-outposts-vpc-subnet-requirements.md#outposts-vpc-requirements)을 충족해야 합니다. + **서브넷** - 기본적으로 이전 필드에서 지정한 VPC에서 사용 가능한 모든 서브넷이 사전 선택됩니다. 선택한 서브넷은 [서브넷 요구 사항 및 고려 사항](eks-outposts-vpc-subnet-requirements.md#outposts-subnet-requirements)의 요구 사항을 충족해야 합니다. + **보안 그룹** – (선택사항) 생성하는 네트워크 인터페이스에 Amazon EKS가 연결하려는 보안 그룹을 하나 이상 지정합니다. Amazon EKS에서는 클러스터와 VPC 간 통신을 활성화하는 보안 그룹을 자동으로 생성합니다. Amazon EKS는 이 보안 그룹과 사용자가 선택한 보안 그룹을 생성하는 네트워크 인터페이스에 연결합니다. Amazon EKS에서 생성하는 클러스터 보안 그룹에 대한 자세한 내용을 알아보려면 [클러스터에 대한 Amazon EKS 보안 그룹 요구 사항 보기](sec-group-reqs.md) 부분을 참조하세요. Amazon EKS가 생성하는 클러스터 보안 그룹에서 규칙을 수정할 수 있습니다. 자체 보안 그룹을 추가하도록 선택한 경우 클러스터 생성 후 선택한 보안 그룹은 변경할 수 없습니다. 온프레미스 호스트가 클러스터 엔드포인트와 통신하려면 클러스터 보안 그룹의 인바운드 트래픽을 허용해야 합니다. 수신 및 송신 인터넷 연결이 없는 클러스터(프라이빗 클러스터라고도 함)의 경우, 다음 중 하나를 수행해야 합니다. + 필수 VPC 엔드포인트와 연결된 보안 그룹을 추가합니다. 필요한 엔드포인트에 대한 자세한 내용은 [AWS 서비스에 대한 서브넷 액세스](eks-outposts-vpc-subnet-requirements.md#subnet-access-to-services)의 [인터페이스 VPC 종단점 사용](eks-outposts-vpc-subnet-requirements.md#vpc-subnet-requirements-vpc-endpoints) 섹션을 참조하세요. + VPC 엔드포인트와 연결된 보안 그룹의 트래픽을 허용하려면 Amazon EKS에서 생성한 보안 그룹을 수정합니다. 이 페이지를 모두 완료하면 **다음**을 선택합니다. 1. **관찰성 구성** 페이지에서 설정할 **지표** 및 **컨트롤 플레인 로깅** 옵션을 선택할 수 있습니다. 기본적으로 각 로그 유형은 해제되어 있습니다. + Prometheus 지표 옵션에 자세한 내용은 [1단계: Prometheus 지표 켜기](prometheus.md#turn-on-prometheus-metrics) 섹션을 참조하세요. + **컨트롤 플레인 로깅** 옵션에 대한 자세한 내용은 [CloudWatch Logs에 컨트롤 플레인 로그 전송](control-plane-logs.md) 섹션을 참조하세요. 이 페이지를 모두 완료하면 **다음**을 선택합니다. 1. **검토 및 생성** 페이지에서 이전 페이지에서 입력하거나 선택한 정보를 검토합니다. 변경해야 하는 경우 **편집**을 선택합니다 만족하는 경우 **생성**을 선택합니다. 클러스터가 프로비저닝되는 동안 **상태** 필드에는 **생성 중**이 표시됩니다. 클러스터 프로비저닝에는 몇 분 정도 걸립니다. ## Amazon EKS 로컬 클러스터 보기 1. 클러스터가 생성된 후 생성된 Amazon EC2 컨트롤 플레인 인스턴스를 볼 수 있습니다. ``` aws ec2 describe-instances --query 'Reservations[*].Instances[*].{Name:Tags[?Key==`Name`]|[0].Value}' | grep my-cluster-control-plane ``` 예제 출력은 다음과 같습니다. ``` "Name": "my-cluster-control-plane-id1" "Name": "my-cluster-control-plane-id2" "Name": "my-cluster-control-plane-id3" ``` 컨트롤 플레인 인스턴스에서 워크로드가 예약되지 않도록 각 인스턴스는 `node-role.eks-local.amazonaws.com/control-plane`으로 테인트됩니다. 테인트에 대한 자세한 내용은 쿠버네티스 문서의 [테인트(Taints)와 톨러레이션(Tolerations)](https://kubernetes.io/docs/concepts/scheduling-eviction/taint-and-toleration/)을 참조하세요. Amazon EKS는 로컬 클러스터의 상태를 지속적으로 모니터링합니다. 보안 패치 및 비정상 인스턴스 복구와 같은 자동 관리 작업을 수행합니다. 로컬 클러스터가 클라우드에서 연결 해제되면 재연결 시 클러스터가 정상 상태로 복구되도록 조치를 완료합니다. 1. `eksctl`을 사용하여 클러스터를 생성한 경우 이 단계를 건너뛸 수 있습니다. `eksctl`에서 자동으로 이 단계를 완료합니다. `kubectl` `config` 파일에 새 컨텍스트를 추가하여 `kubectl`이 클러스터와 통신하도록 사용 설정합니다. 파일 생성 설치 및 업데이트 방법에 대한 지침은 [Kubeconfig 파일을 생성하여 kubectl을 EKS 클러스터에 연결](create-kubeconfig.md) 부분을 참조하세요. ``` aws eks update-kubeconfig --region region-code --name my-cluster ``` 예제 출력은 다음과 같습니다. ``` Added new context arn:aws:eks:region-code:111122223333:cluster/my-cluster to /home/username/.kube/config ``` 1. 로컬 클러스터의 Kubernetes API 서버에 연결하려면 서브넷의 로컬 게이트웨이에 액세스하거나 VPC 내에서 연결해야 합니다. Outpost 랙을 온프레미스 네트워크에 연결하는 방법을 자세히 알아보려면 AWS Outposts 사용 설명서의 [랙용 로컬 게이트웨이 작동 방식](https://docs.aws.amazon.com/outposts/latest/userguide/how-racks-work.html)을 참조하세요. Direct VPC Routing을 사용하며 Outpost 서브넷에 로컬 게이트웨이에 대한 경로가 있으면 Kubernetes 컨트롤 플레인 인스턴스의 프라이빗 IP 주소가 로컬 네트워크를 통해 자동으로 브로드캐스트됩니다. 로컬 클러스터의 Kubernetes API 서버 엔드포인트는 Amazon Route 53(Route 53)에서 호스팅됩니다. API 서비스 엔드포인트는 퍼블릭 DNS 서버에서 Kubernetes API 서버의 프라이빗 IP 주소로 확인할 수 있습니다. 로컬 클러스터의 Kubernetes 컨트롤 플레인 인스턴스는 클러스터 수명 주기 동안 변경되지 않는 고정 프라이빗 IP 주소를 사용하여 정적 탄력적 네트워크 인터페이스로 구성됩니다. Kubernetes API 서버와 상호 작용하는 머신은 네트워크 연결이 해제된 동안 Route 53에 연결되지 않을 수도 있습니다. 이 경우 계속되는 작업을 위해 고정 프라이빗 IP 주소로 `/etc/hosts`를 구성하는 것이 좋습니다. 또한 로컬 DNS 서버를 설정하고 Outpost에 연결하는 것이 좋습니다. 자세한 내용은 [AWS Outposts 문서](https://docs.aws.amazon.com/outposts/latest/userguide/how-outposts-works.html#dns)를 참조하세요. 다음 명령을 실행하여 클러스터와 설정된 통신을 확인합니다. ``` kubectl get svc ``` 예제 출력은 다음과 같습니다. ``` NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE kubernetes ClusterIP 10.100.0.1 443/TCP 28h ``` 1. (선택사항) 로컬 클러스터가 AWS 클라우드에서 연결 해제된 상태일 때 인증을 테스트합니다. 지침은 [네트워크 연결 해제에 대비하여 AWS Outposts에 로컬 Amazon EKS 클러스터 준비](eks-outposts-network-disconnects.md) 섹션을 참조하세요. ### 내부 리소스 Amazon EKS는 클러스터에 다음 리소스를 생성합니다. 리소스는 Amazon EKS 내부용입니다. 클러스터가 제대로 작동하려면 이러한 리소스를 편집하거나 수정하지 않습니다. + 다음 [미러 포드](https://kubernetes.io/docs/reference/glossary/?all=true#term-mirror-pod): + `aws-iam-authenticator-node-hostname ` + `eks-certificates-controller-node-hostname ` + `etcd-node-hostname ` + `kube-apiserver-node-hostname ` + `kube-controller-manager-node-hostname ` + `kube-scheduler-node-hostname ` + 다음 자체 관리형 추가 기능: + `kube-system/coredns` + `kube-system/` `kube-proxy`(첫 번째 노드를 추가할 때까지 생성되지 않음) + `kube-system/aws-node`(첫 번째 노드를 추가할 때까지 생성되지 않음). 로컬 클러스터는 클러스터 네트워킹에 Kubernetes용 Amazon VPC CNI 플러그인을 사용합니다. 컨트롤 플레인 인스턴스(`aws-node-controlplane-*`라는 포드)의 구성을 변경하지 않습니다. 플러그인에서 새 네트워크 인터페이스를 생성할 때 기본값 변경에 사용할 수 있는 구성 변수가 있습니다. 자세한 내용을 알아보려면 GitHub의 [설명서](https://github.com/aws/amazon-vpc-cni-k8s/blob/master/README.md)를 참조하세요. + 다음 서비스: + `default/kubernetes` + `kube-system/kube-dns` + 이름이 `eks.system`인 `PodSecurityPolicy` + 이름이 `eks:system:podsecuritypolicy`인 `ClusterRole` + 이름이 `eks:system`인 `ClusterRoleBinding` + [클러스터 보안 그룹](sec-group-reqs.md) 외에도 Amazon EKS에서는 AWS 계정에 이름이 `eks-local-internal-do-not-use-or-edit-cluster-name-uniqueid `인 보안 그룹을 생성합니다. 이 보안 그룹을 사용하면 컨트롤 플레인 인스턴스에서 실행되는 Kubernetes 구성 요소 간에 트래픽이 자유롭게 흐를 수 있습니다. 권장되는 다음 단계: + [클러스터를 생성한 IAM 보안 주체에 AWS Management Console에서 Kubernetes 리소스를 볼 수 있는 필요한 권한 부여](view-kubernetes-resources.md#view-kubernetes-resources-permissions) + [클러스터에 IAM 엔터티에 액세스 권한 부여](grant-k8s-access.md) 엔터티가 Amazon EKS 콘솔에서 Kubernetes 리소스를 보도록 하려면 엔터티에 [필수 권한](view-kubernetes-resources.md#view-kubernetes-resources-permissions)을 부여합니다. + [클러스터에 대한 로깅 구성](control-plane-logs.md) + [네트워크 연결 해제](eks-outposts-network-disconnects.md) 중 어떤 일이 발생하는지 숙지합니다. + [클러스터에 노드 추가](eks-outposts-self-managed-nodes.md) + `etcd`에 대한 백업 계획 설정을 고려합니다. Amazon EKS는 로컬 클러스터에 대한 `etcd`의 자동 백업 및 복원을 지원하지 않습니다. 자세한 내용은 Kubernetes Documentation의 [Backing up an etcd cluster](https://kubernetes.io/docs/tasks/administer-cluster/configure-upgrade-etcd/#backing-up-an-etcd-cluster)를 참조하세요. 두 가지 주요 옵션은 `etcdctl`을 사용하여 스냅샷 생성 또는 Amazon EBS 스토리지 볼륨 백업 사용을 자동화합니다. # Kubernetes 및 AWS Outposts에 대한 Amazon EKS 플랫폼 버전 알아보기 로컬 클러스터 플랫폼 버전은 AWS Outposts에 있는 Amazon EKS 클러스터의 기능을 나타냅니다. 버전에는 Kubernetes API 서버 플래그가 활성화된 Kubernetes 컨트롤 플레인에서 실행되는 구성 요소가 포함됩니다. 현재 Kubernetes 패치 버전도 포함됩니다. 각 Kubernetes 마이너 버전에는 하나 이상의 연결된 플랫폼 버전이 있습니다. 서로 다른 Kubernetes 마이너 버전에 대한 플랫폼 버전은 독립적입니다. 클라우드의 로컬 클러스터와 Amazon EKS 클러스터의 플랫폼 버전은 독립적입니다. `1.31`과 같은 로컬 클러스터에 새 Kubernetes 마이너 버전을 사용할 수 있는 경우 해당 Kubernetes 마이너 버전의 초기 플랫폼 버전은 `eks-local-outposts.1`에서 시작합니다. 그러나 Amazon EKS에서는 새 Kubernetes 제어 영역 설정을 활성화하고 보안 수정 사항을 제공하기 위해 새 플랫폼 버전을 주기적으로 릴리스합니다. 마이너 버전에 대해 새 로컬 클러스터 플랫폼 버전을 사용할 수 있게 된 경우 다음과 같은 사항이 발생합니다. + 플랫폼 버전 번호가 증가합니다(`eks-local-outposts.n+1`). + Amazon EKS에서 기존의 모든 로컬 클러스터를 해당하는 Kubernetes 마이너 버전에 대한 최신 플랫폼 버전으로 자동으로 업데이트합니다. 기존 플랫폼 버전의 자동 업데이트는 증분 방식으로 롤아웃됩니다. 롤아웃 프로세스는 3개의 인스턴스가 모두 새 인스턴스로 교체될 때까지 Outpost에서 실행되는 관리형 Kubernetes 컨트롤 플레인 인스턴스를 한 번에 하나씩 교체합니다. + 서비스 중단 위험이 있으면 Kubernetes 컨트롤 플레인 인스턴스 교체 프로세스 진행이 중지됩니다. Amazon EKS는 다른 2개의 Kubernetes 컨트롤 플레인 인스턴스가 정상이고 클러스터 노드로서 모든 준비 조건을 통과하는 경우에만 인스턴스 교체를 시도합니다. + 플랫폼 버전 롤아웃을 완료하는 데 일반적으로 30분 미만이 소요됩니다. 클러스터가 장기간 `UPDATING` 상태를 유지하는 경우 [AWS Outposts의 로컬 Amazon EKS 클러스터 문제 해결](eks-outposts-troubleshooting.md) 섹션을 참조하고 AWS Support에 도움을 요청하세요. AWS Support의 지시가 없는 한 Kubernetes 컨트롤 플레인 인스턴스를 수동으로 종료하지 마세요. + Amazon EKS에서는 해당 패치 버전으로 새 AMI를 게시할 수 있습니다. 모든 패치 버전은 단일 Kubernetes 마이너 버전에 대한 노드 AMI와 Kubernetes 컨트롤 플레인 간에 호환됩니다. 새 플랫폼 버전은 주요 변경 사항을 도입하거나 서비스 중단을 초래하지 않습니다. 로컬 클러스터는 항상 지정된 Kubernetes 버전에 사용 가능한 최신 플랫폼 버전(`eks-local-outposts.n`)으로 생성됩니다. 현재 및 최근 플랫폼 버전은 다음 표에 설명되어 있습니다. 이 특정 설명서 페이지의 모든 소스 파일 변경 사항에 대한 알림을 받으려면 RSS 리더를 사용하여 다음 URL을 구독하세요. ``` https://github.com/awsdocs/amazon-eks-user-guide/commits/mainline/latest/ug/outposts/eks-outposts-platform-versions.adoc.atom ``` ## Kubernetes 버전 `1.31` 다음 승인 컨트롤러는 모든 `1.31` 플랫폼 버전(`CertificateApproval`, `CertificateSigning`, `CertificateSubjectRestriction`, `ClusterTrustBundleAttest`, `DefaultIngressClass`, `DefaultStorageClass`, `DefaultTolerationSeconds`, `ExtendedResourceToleration`, `LimitRanger`, `MutatingAdmissionWebhook`, `NamespaceLifecycle`, `NodeRestriction`, `PersistentVolumeClaimResize`, `PodSecurity`, `Priority`, `ResourceQuota`, `RuntimeClass`, `ServiceAccount`, `StorageObjectInUseProtection`, `TaintNodesByCondition`, `ValidatingAdmissionPolicy`, `ValidatingAdmissionWebhook`)에 대해 활성화됩니다. | Kubernetes 버전 | Amazon EKS 플랫폼 버전 | 릴리스 노트 | 릴리스 날짜 | | --- | --- | --- | --- | | `1.31.14` | `eks-local-outposts.8` | 보안 수정 및 개선 사항이 적용된 새로운 플랫폼 버전입니다. kube-proxy는 `v1.31.14`으로 업데이트되었습니다. AWS IAM Authenticator가 `v0.7.8`로 업데이트되었습니다. Kubernetes용 Amazon VPC CNI 플러그인은 `v1.20.4`(으)로 업데이트되었습니다. Bottlerocket 버전이 `v1.52.0`으로 업데이트되었습니다. | 2025년 12월 23일 | | `1.31.12` | `eks-local-outposts.5` | 보안 수정 및 개선 사항이 적용된 새로운 플랫폼 버전입니다. kube-proxy는 `v1.31.10`으로 업데이트되었습니다. AWS IAM Authenticator가 `v0.7.4`로 업데이트되었습니다. Kubernetes용 Amazon VPC CNI 플러그인은 `v1.20.2`(으)로 업데이트되었습니다. Bottlerocket 버전이 `v1.47.0`으로 업데이트되었습니다. | 2025년 10월 3일 | | `1.31.9` | `eks-local-outposts.4` | 보안 수정 및 개선 사항이 적용된 새로운 플랫폼 버전입니다. kube-proxy는 `v1.31.9`으로 업데이트되었습니다. AWS IAM Authenticator가 `v0.7.2`로 업데이트되었습니다. Kubernetes에 대한 Amazon VPC CNI 플러그인에서 `v1.20.0` Bottlerocket 버전이 `v1.43.0`으로 업데이트되었습니다. | 2025년 8월 9일 | | `1.31.7` | `eks-local-outposts.3` | 보안 수정 및 개선 사항이 적용된 새로운 플랫폼 버전입니다. kube-proxy는 `v1.31.9`으로 업데이트되었습니다. AWS IAM Authenticator가 `v0.7.1`로 업데이트되었습니다. Kubernetes용 Amazon VPC CNI 플러그인은 `v1.19.5`(으)로 업데이트되었습니다. Bottlerocket 버전이 `v1.40.0`으로 업데이트되었습니다. | 2025년 6월 19일 | | `1.31.6` | `eks-local-outposts.2` | 보안 수정 및 개선 사항이 적용된 새로운 플랫폼 버전. Bottlerocket 버전이 `v1.36.0`으로 업데이트되었습니다. | 2025년 4월 24일 | | `1.31.6` | `eks-local-outposts.1` | Outposts의 로컬 Amazon EKS 클러스터용 Kubernetes 버전 `v1.31`의 최초 릴리스입니다. | 2025년 4월 9일 | ## Kubernetes 버전 `1.30` 다음 승인 컨트롤러는 모든 `1.30` 플랫폼 버전(`CertificateApproval`, `CertificateSigning`, `CertificateSubjectRestriction`, `ClusterTrustBundleAttest`, `DefaultIngressClass`, `DefaultStorageClass`, `DefaultTolerationSeconds`, `ExtendedResourceToleration`, `LimitRanger`, `MutatingAdmissionWebhook`, `NamespaceLifecycle`, `NodeRestriction`, `PersistentVolumeClaimResize`, `PodSecurity`, `Priority`, `ResourceQuota`, `RuntimeClass`, `ServiceAccount`, `StorageObjectInUseProtection`, `TaintNodesByCondition`, `ValidatingAdmissionPolicy`, `ValidatingAdmissionWebhook`)에 대해 활성화됩니다. | Kubernetes 버전 | Amazon EKS 플랫폼 버전 | 릴리스 노트 | 릴리스 날짜 | | --- | --- | --- | --- | | `1.30.14` | `eks-local-outposts.10` | 보안 수정 및 개선 사항이 적용된 새로운 플랫폼 버전. AWS IAM Authenticator가 `v0.7.8`로 업데이트되었습니다. Kubernetes용 Amazon VPC CNI 플러그인은 `v1.20.4`(으)로 업데이트되었습니다. Bottlerocket 버전이 `v1.52.0`으로 업데이트되었습니다. | 2025년 12월 23일 | | `1.30.14` | `eks-local-outposts.7` | 보안 수정 및 개선 사항이 적용된 새로운 플랫폼 버전입니다. kube-proxy는 `v1.30.14`으로 업데이트되었습니다. AWS IAM Authenticator가 `v0.7.4`로 업데이트되었습니다. Kubernetes용 Amazon VPC CNI 플러그인은 `v1.20.2`(으)로 업데이트되었습니다. Bottlerocket 버전이 `v1.47.0`으로 업데이트되었습니다. | 2025년 10월 3일 | | `1.30.13` | `eks-local-outposts.6` | 보안 수정 및 개선 사항이 적용된 새로운 플랫폼 버전입니다. kube-proxy는 `v1.30.13`으로 업데이트되었습니다. AWS IAM Authenticator가 `v0.7.2`로 업데이트되었습니다. Kubernetes용 Amazon VPC CNI 플러그인은 `v1.20.0`(으)로 업데이트되었습니다. Bottlerocket 버전이 `v1.43.0`으로 업데이트되었습니다. | 2025년 8월 9일 | | `1.30.11` | `eks-local-outposts.5` | 보안 수정 및 개선 사항이 적용된 새로운 플랫폼 버전입니다. kube-proxy는 `v1.30.11`으로 업데이트되었습니다. AWS IAM Authenticator가 `v0.7.1`로 업데이트되었습니다. Kubernetes에 대한 Amazon VPC CNI 플러그인에서 `v1.19.5` Bottlerocket 버전이 `v1.40.0`으로 업데이트되었습니다. | 2025년 6월 19일 | | `1.30.10` | `eks-local-outposts.4` | 보안 수정 및 개선 사항이 적용된 새로운 플랫폼 버전. Bottlerocket 버전이 `v1.36.0`으로 업데이트되었습니다. | 2025년 4월 24일 | | `1.30.10` | `eks-local-outposts.3` | 보안 수정 및 개선 사항이 적용된 새로운 플랫폼 버전입니다. kube-proxy는 `v1.30.10`으로 업데이트되었습니다. AWS IAM Authenticator가 `v0.6.29`로 업데이트되었습니다. Kubernetes용 Amazon VPC CNI 플러그인은 `v1.19.2`(으)로 업데이트되었습니다. CoreDNS가 `v1.11.4`로 업데이트되었습니다. AWS Cloud Controller Manager가 `v1.30.8`로 업데이트되었습니다. Bottlerocket 버전이 `v1.34.0`으로 업데이트되었습니다. | 2025년 3월 27일 | | `1.30.7` | `eks-local-outposts.2` | 보안 수정 및 개선 사항이 적용된 새로운 플랫폼 버전입니다. kube-proxy는 `v1.30.7`으로 업데이트되었습니다. AWS IAM Authenticator가 `v0.6.28`로 업데이트되었습니다. Kubernetes용 Amazon VPC CNI 플러그인은 `v1.19.0`(으)로 업데이트되었습니다. Bottlerocket 버전을 `v1.29.0`으로 업데이트했습니다. | 2025년 1월 10일 | | `1.30.5` | `eks-local-outposts.1` | Outposts의 로컬 Amazon EKS 클러스터용 Kubernetes 버전 `v1.30`의 최초 릴리스입니다. | 2024년 11월 13일 | ## Kubernetes 버전 `1.29` 다음 승인 컨트롤러는 모든 `1.29` 플랫폼 버전(`CertificateApproval`, `CertificateSigning`, `CertificateSubjectRestriction`, `ClusterTrustBundleAttest`, `DefaultIngressClass`, `DefaultStorageClass`, `DefaultTolerationSeconds`, `ExtendedResourceToleration`, `LimitRanger`, `MutatingAdmissionWebhook`, `NamespaceLifecycle`, `NodeRestriction`, `PersistentVolumeClaimResize`, `PodSecurity`, `Priority`, `ResourceQuota`, `RuntimeClass`, `ServiceAccount`, `StorageObjectInUseProtection`, `TaintNodesByCondition`, `ValidatingAdmissionPolicy`, `ValidatingAdmissionWebhook`)에 대해 활성화됩니다. | Kubernetes 버전 | Amazon EKS 플랫폼 버전 | 릴리스 노트 | 릴리스 날짜 | | --- | --- | --- | --- | | `1.29.15` | `eks-local-outposts.13` | 보안 수정 및 개선 사항이 적용된 새로운 플랫폼 버전. AWS IAM Authenticator가 `v0.7.8`로 업데이트되었습니다. Kubernetes용 Amazon VPC CNI 플러그인은 `v1.20.4`(으)로 업데이트되었습니다. Bottlerocket 버전이 `v1.52.0`으로 업데이트되었습니다. | 2025년 12월 23일 | | `v1.29.15` | `eks-local-outposts.10` | 보안 수정 및 개선 사항이 적용된 새로운 플랫폼 버전. AWS IAM Authenticator가 `v0.7.4`로 업데이트되었습니다. Kubernetes용 Amazon VPC CNI 플러그인은 `v1.20.2`(으)로 업데이트되었습니다. Bottlerocket 버전이 `v1.47.0`으로 업데이트되었습니다. | 2025년 10월 3일 | | `v1.29.15` | `eks-local-outposts.9` | 보안 수정 및 개선 사항이 적용된 새로운 플랫폼 버전. AWS IAM Authenticator가 `v0.7.2`로 업데이트되었습니다. Kubernetes용 Amazon VPC CNI 플러그인은 `v1.20.0`(으)로 업데이트되었습니다. Bottlerocket 버전이 `v1.43.0`으로 업데이트되었습니다. | 2025년 8월 9일 | | `v1.29.15` | `eks-local-outposts.8` | 보안 수정 및 개선 사항이 적용된 새로운 플랫폼 버전입니다. kube-proxy는 `v1.29.15`으로 업데이트되었습니다. AWS IAM Authenticator가 `v0.7.1`로 업데이트되었습니다. Kubernetes용 Amazon VPC CNI 플러그인은 `v1.19.5`(으)로 업데이트되었습니다. Bottlerocket 버전이 `v1.40.0`으로 업데이트되었습니다. | 2025년 6월 19일 | | `v1.29.14` | `eks-local-outposts.7` | 보안 수정 및 개선 사항이 적용된 새로운 플랫폼 버전. Bottlerocket 버전이 `v1.36.0`으로 업데이트되었습니다. | 2025년 3월 24일 | | `v1.29.14` | `eks-local-outposts.6` | 보안 수정 및 개선 사항이 적용된 새로운 플랫폼 버전입니다. kube-proxy는 `v1.29.14`로 업데이트되었습니다. Kubernetes용 Amazon VPC CNI 플러그인은 `v1.19.2`(으)로 업데이트되었습니다. CoreDNS가 `v1.11.4`로 업데이트되었습니다. AWS Cloud Controller Manager가 `v1.29.8`로 업데이트되었습니다. Bottlerocket 버전이 `v1.34.0`으로 업데이트되었습니다. | 2025년 3월 27일 | | `v1.29.11` | `eks-local-outposts.5` | 보안 수정 및 개선 사항이 적용된 새로운 플랫폼 버전입니다. kube-proxy는 `v1.29.11`로 업데이트되었습니다. Kubernetes용 Amazon VPC CNI 플러그인은 `v1.19.0`(으)로 업데이트되었습니다. CoreDNS 이미지가 `v1.11.3` 버전으로 업데이트되었습니다. Bottlerocket 버전을 `v1.29.0`으로 업데이트했습니다. | 2025년 1월 10일 | | `1.29.9` | `eks-local-outposts.4` | 보안 수정 및 개선 사항이 적용된 새로운 플랫폼 버전입니다. kube-proxy는 `v1.29.9`으로 업데이트되었습니다. AWS IAM Authenticator가 `v0.6.26`로 업데이트되었습니다. Bottlerocket 버전을 `v1.26.0`으로 업데이트했습니다. | 2024년 11월 8일 | | `1.29.6` | `eks-local-outposts.3` | 보안 수정 및 개선 사항이 적용된 새로운 플랫폼 버전. Bottlerocket 버전을 `v1.22.0`으로 업데이트했습니다. | 2024년 10월 22일 | | `1.29.6` | `eks-local-outposts.2` | 보안 수정 및 개선 사항이 적용된 새로운 플랫폼 버전. Bottlerocket 버전을 `v1.21.0`으로 업데이트했습니다. | 2024년 8월 27일 | | `1.29.6` | `eks-local-outposts.1` | Outposts의 로컬 Amazon EKS 클러스터용 Kubernetes 버전 `v1.29`의 최초 릴리스입니다. | 2024년 8월 20일 | # AWS 출력에서 Amazon EKS 클러스터를 위한 VPC 및 서브넷 생성 로컬 클러스터를 생성할 때 Outposts에서 실행되는 하나 이상의 프라이빗 서브넷과 VPC를 지정합니다. 이 주제에서는 로컬 클러스터에 대한 VPC 및 서브넷 요구 사항 및 고려 사항을 간략하게 살펴봅니다. ## VPC 요구 사항 및 고려 사항 로컬 클러스터를 생성하는 경우 지정하는 VPC는 다음 요구 사항 및 고려 사항을 충족해야 합니다. + 생성하려는 로컬 클러스터, 노드 및 기타 Kubernetes 리소스에 대한 충분한 IP 주소가 VPC에 있는지 확인합니다. 사용하려는 VPC에 충분한 IP 주소가 없는 경우 사용 가능한 IP 주소를 증량합니다. 이 작업은 해당 VPC를 통해 [추가 CIDR(Classless Inter-Domain Routing) 블록을 연결](https://docs.aws.amazon.com/vpc/latest/userguide/working-with-vpcs.html#add-ipv4-cidr)하여 수행할 수 있습니다. 클러스터를 생성하기 전이나 후에 프라이빗(RFC 1918) 및 퍼블릭(비RFC 1918) CIDR 블록을 VPC에 연결할 수 있습니다. 클러스터가 VPC와 연결된 CIDR 블록을 인식하는 데 최대 5시간이 걸릴 수 있습니다. + VPC에는 할당된 IP 접두사 또는 IPv6 CIDR 블록이 있을 수 없습니다. 이러한 제약으로 인해 [접두사를 사용하여 Amazon EKS 노드에 더 많은 IP 주소 할당](cni-increase-ip-addresses.md) 및 [클러스터, 포드 및 서비스에 대한 IPv6 주소에 대해 알아보기](cni-ipv6.md)에서 다루는 정보는 VPC에 적용되지 않습니다. + 활성화된 DNS 호스트 이름과 DNS 확인이 VPC에 있습니다. 이러한 기능이 없으면 로컬 클러스터 생성에 실패하므로 기능을 활성화하고 클러스터를 다시 생성해야 합니다. 자세한 내용을 알아보려면 Amazon VPC 사용 설명서의 [VPC에 대한 DNS 속성](https://docs.aws.amazon.com/vpc/latest/userguide/vpc-dns.html)을 참조하세요. + 로컬 네트워크를 통해 로컬 클러스터에 액세스하려면 VPC가 Outpost의 로컬 게이트웨이 라우팅 테이블과 연결되어 있어야 합니다. 자세한 내용을 알아보려면 AWS Outposts 사용 설명서의 [VPC 연결](https://docs.aws.amazon.com/outposts/latest/userguide/outposts-local-gateways.html#vpc-associations)을 참조하세요. ## 서브넷 요구 사항 및 고려 사항 클러스터를 생성할 때 하나 이상의 프라이빗 서브넷을 지정합니다. 서브넷을 여러 개 지정하면 Kubernetes 컨트롤 플레인 인스턴스가 서브넷 전체에 고르게 분산됩니다. 2개 이상의 서브넷이 지정된 경우 서브넷이 동일한 Outpost에 있어야 합니다. 아울러 서로 통신하는 적절한 경로와 보안 그룹 권한도 서브넷에 있어야 합니다. 로컬 클러스터를 생성할 때 지정하는 서브넷에서 다음과 같은 요구 사항을 충족해야 합니다. + 서브넷이 모두 동일한 논리적 Outpost에 있습니다. + 서브넷에 전체적으로 Kubernetes 컨트롤 플레인 인스턴스에 대해 사용 가능한 IP 주소가 3개 이상 있어야 합니다. 3개의 서브넷이 지정된 경우 각 서브넷에 사용 가능한 IP 주소가 1개 이상 있어야 합니다. 2개의 서브넷이 지정된 경우 각 서브넷에 사용 가능한 IP 주소가 2개 이상 있어야 합니다. 1개의 서브넷이 지정된 경우 서브넷에 사용 가능한 IP 주소가 3개 이상 있어야 합니다. + 로컬 네트워크를 통해 Kubernetes API 서버에 액세스하기 위한 Outpost 랙의 [로컬 게이트웨이](https://docs.aws.amazon.com/outposts/latest/userguide/outposts-local-gateways.html)에 대한 경로가 서브넷에 있어야 합니다. 서브넷에 Outpost 랙의 로컬 게이트웨이에 대한 경로가 없는 경우 VPC 내에서 Kubernetes API 서버와 통신해야 합니다. + 서브넷에서는 IP 주소 기반 이름 지정을 사용해야 합니다. Amazon EC2 [리소스 기반 이름 지정](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ec2-instance-naming.html#instance-naming-rbn)은 Amazon EKS에서 지원되지 않습니다. ## AWS 서비스에 대한 서브넷 액세스 Outposts에 있는 로컬 클러스터의 사설 서브넷은 리전 AWS 서비스와 통신할 수 있어야 합니다. 아웃바운드 인터넷 액세스를 위해 [NAT 게이트웨이를](https://docs.aws.amazon.com/vpc/latest/userguide/vpc-nat-gateway.html) 사용하거나, VPC 내에서 모든 트래픽을 비공개로 유지하려는 경우 [인터페이스 VPC 엔드포인트를](https://docs.aws.amazon.com/vpc/latest/privatelink/create-interface-endpoint.html) 사용하여 이를 달성할 수 있습니다. ### NAT 게이트웨이 태깅 Outpost의 상위 가용 영역에 있는 퍼블릭 서브넷에서 실행되는 NAT 게이트웨이에 대한 경로가 있는 연결된 라우팅 테이블이 서브넷에 있습니다. 퍼블릭 서브넷에 [인터넷 게이트웨이](https://docs.aws.amazon.com/vpc/latest/userguide/VPC_Internet_Gateway.html)에 대한 경로가 있어야 합니다. 이 경로는 아웃바운드 인터넷 액세스를 활성화하고 인터넷에서 Outpost의 인스턴스로의 원치 않는 인바운드 연결을 방지합니다. ### 인터페이스 VPC 종단점 사용 Outst에 있는 로컬 클러스터의 사설 서브넷에 송신 인터넷 연결이 없는 경우에는, 또는 송신 인터넷 연결이 없는 경우에는 클러스터를 생성하기 전에 다음과 같은 인터페이스 VPC [엔드포인트와 게이트웨이 엔드포인트를](https://docs.aws.amazon.com/vpc/latest/privatelink/gateway-endpoints.html) 생성해야 합니다. | 엔드포인트 | 엔드포인트 유형 | | --- | --- | | `com.amazonaws.region-code.ssm` | 인터페이스 | | `com.amazonaws.region-code.ssmmessages` | 인터페이스 | | `com.amazonaws.region-code.ec2messages` | 인터페이스 | | `com.amazonaws.region-code.ec2` | 인터페이스 | | `com.amazonaws.region-code.secretsmanager` | 인터페이스 | | `com.amazonaws.region-code.logs` | 인터페이스 | | `com.amazonaws.region-code.sts` | 인터페이스 | | `com.amazonaws.region-code.ecr.api` | 인터페이스 | | `com.amazonaws.region-code.ecr.dkr` | 인터페이스 | | `com.amazonaws.region-code.s3` | 게이트웨이 | 이름은 다음 요구 사항을 충족해야 합니다. + Outpost의 상위 가용 영역에 있는 프라이빗 서브넷에서 생성됨 + 프라이빗 DNS 이름 활성화 + 사설 송신 서브넷의 CIDR 범위에서 오는 인바운드 HTTPS 트래픽을 허용하는 연결된 보안 그룹이 있습니다. 엔드포인트를 생성하면 요금이 부과됩니다. 자세한 내용은 [AWS PrivateLinK 요금](https://aws.amazon.com/privatelink/pricing/)을 참조하세요. 기타 AWS 서비스에 대한 액세스 권한이 포드에 필요한 경우에는 추가 엔드포인트를 생성해야 합니다. 엔드포인트의 전체 목록은 [AWS PrivateLink와 통합되는 AWS 서비스](https://docs.aws.amazon.com/vpc/latest/privatelink/aws-services-privatelink-support.html)를 참조하세요. ## VPC 생성 다음과 같은 AWS CloudFormation 템플릿 중 하나를 사용하여 이전 요구 사항을 충족하는 VPC를 생성할 수 있습니다. + ** [템플릿 1](https://s3.us-west-2.amazonaws.com/amazon-eks/cloudformation/2022-09-20/amazon-eks-local-outposts-vpc-subnet.yaml) ** - 이 템플릿에서는 Outpost의 프라이빗 서브넷 1개와 AWS 리전의 퍼블릭 서브넷 1개로 VPC를 생성합니다. 프라이빗 서브넷에는 AWS 리전의 퍼블릭 서브넷에 상주하는 NAT 게이트웨이를 통해 인터넷에 연결되는 경로가 있습니다. 이 템플릿은 송신 인터넷 액세스 권한이 있는 서브넷에 로컬 클러스터를 생성하는 데 사용할 수 있습니다. + ** [템플릿 2](https://s3.us-west-2.amazonaws.com/amazon-eks/cloudformation/2023-03-20/amazon-eks-local-outposts-fully-private-vpc-subnet.yaml) ** - 이 템플릿에서는 Outpost의 프라이빗 서브넷 1개와 수신 또는 송신 인터넷 액세스 권한이 없는 서브넷에 로컬 클러스터(프라이빗 서브넷이라고도 함)를 생성하는 데 필요한 최소 VPC 엔드포인트 집합이 있는 VPC를 생성합니다. # 네트워크 연결 해제에 대비하여 AWS Outposts에 로컬 Amazon EKS 클러스터 준비 로컬 네트워크와 AWS 클라우드의 연결이 끊어진 경우 Outpost에서 로컬 Amazon EKS 클러스터를 계속 사용할 수 있습니다. 이 주제에서는 로컬 클러스터에서 네트워크 연결 해제에 대비하는 방법과 관련 고려 사항을 설명합니다. + 로컬 클러스터를 사용하면 계획되지 않은 임시 네트워크 연결 해제 중에 안정성과 지속적인 작업을 수행할 수 있습니다. AWS Outposts는 데이터 센터에서 AWS 클라우드의 확장 역할을 하는 완전 연결형 제품으로 남아 있습니다. Outpost와 AWS 클라우드 간 네트워크 연결이 해제된 경우 연결 복원을 시도하는 것이 좋습니다. 지침은 * AWS Outposts 사용 설명서*의 [AWS Outposts 랙 네트워크 문제 해결 체크리스트](https://docs.aws.amazon.com/outposts/latest/userguide/network-troubleshoot.html)를 참조하세요. 로컬 클러스터 문제를 해결하는 방법에 대한 자세한 내용은 [AWS Outposts의 로컬 Amazon EKS 클러스터 문제 해결](eks-outposts-troubleshooting.md) 섹션을 참조하세요. + Outposts는 Outpost의 연결 상태를 모니터링하는 데 사용할 수 있는 `ConnectedStatus` 지표를 내보냅니다. 자세한 내용을 알아보려면 * AWS Outposts 사용 설명서*에서 [Outposts 지표](https://docs.aws.amazon.com/outposts/latest/userguide/outposts-cloudwatch-metrics.html#outposts-metrics)를 참조하세요. + 로컬 클러스터는 [Kubernetes용 AWS ID 및 액세스 관리 인증자를 사용하여 IAM을 기본 인증 메커니즘](https://github.com/kubernetes-sigs/aws-iam-authenticator)으로 사용합니다. 네트워크 연결 해제 중에는 IAM을 사용할 수 없습니다. 따라서 로컬 클러스터에서는 네트워크 연결 해제 중 클러스터에 연결하는 데 사용할 수 있는 `x.509` 인증서를 사용하는 대체 인증 메커니즘을 지원합니다. 클러스터에 대한 `x.509` 인증서를 받고 사용하는 방법에 대한 내용은 [네트워크 연결 해제 중 로컬 클러스터에 인증](#outposts-network-disconnects-authentication) 섹션을 참조하세요. + 네트워크 연결 해제 중 Route 53에 액세스할 수 없는 경우 온프레미스 환경에서 로컬 DNS 서버를 사용하는 것이 좋습니다. Kubernetes 컨트롤 플레인 인스턴스는 고정 IP 주소를 사용합니다. 로컬 DNS 서버를 사용하는 대신 엔드포인트 호스트 이름과 IP 주소를 사용하여 클러스터에 연결하는 데 사용하는 호스트를 구성할 수 있습니다. 자세한 내용은 *AWS Outposts 사용 설명서*에서 [DNS](https://docs.aws.amazon.com/outposts/latest/userguide/how-outposts-works.html#dns)를 참조하세요. + 네트워크 연결 해제 중 애플리케이션 트래픽이 증가할 것으로 예상되는 경우 클라우드에 연결될 때 클러스터에 여분의 컴퓨팅 용량을 프로비저닝할 수 있습니다. Amazon EC2 인스턴스는 AWS Outposts의 가격에 포함됩니다. 따라서 여분의 인스턴스를 실행해도 AWS 사용 비용에 영향을 미치지 않습니다. + 네트워크 연결 해제 중 워크로드에 대한 생성, 업데이트 및 조정 작업을 활성화하려면 로컬 네트워크를 통해 애플리케이션의 컨테이너 이미지에 액세스할 수 있어야 하고 클러스터에 충분한 용량이 있어야 합니다. 로컬 클러스터는 컨테이너 레지스트리를 호스팅하지 않습니다. 포드가 이전에 해당 노드에서 실행된 경우 컨테이너 이미지가 노드에서 캐시됩니다. 일반적으로 클라우드의 Amazon ECR에서 애플리케이션의 컨테이너 이미지를 가져오는 경우 로컬 캐시 또는 레지스트리를 실행해 보세요. 네트워크 연결 해제 중 워크로드 리소스에 대한 생성, 업데이트 또는 조정 작업이 필요한 경우 로컬 캐시 또는 레지스트리가 도움이 됩니다. + 로컬 클러스터는 Amazon EBS를 영구 볼륨의 기본 스토리지 클래스로 사용하고 Amazon EBS CSI 드라이버를 사용하여 Amazon EBS 영구 볼륨의 수명 주기를 관리합니다. 네트워크 연결 해제 중 Amazon EBS에서 지원하는 포드는 생성, 업데이트 또는 조정할 수 없습니다. 이러한 작업에는 클라우드의 Amazon EBS API에 대한 호출이 필요하기 때문입니다. 로컬 클러스터에 상태 저장 워크로드를 배포하고 네트워크 연결 해제 중 생성, 업데이트 또는 조정 작업이 필요한 경우 대체 스토리지 메커니즘을 사용하는 것이 좋습니다. + AWS Outposts 에서 관련 AWS 리전 내 API(예: Amazon EBS 또는 Amazon S3용 API)에 액세스할 수 없는 경우, Amazon EBS 스냅샷을 생성하거나 삭제할 수 없습니다. + ALB(수신)를 AWS 인증 관리(ACM)와 통합하면 인증서가 푸시되어 AWS Outposts ALB Compute 인스턴스의 메모리에 저장됩니다. AWS 리전에서 연결이 해제되는 경우 현재 TLS 종료는 계속 작동합니다. 이 컨텍스트에서는 변형 작업(예: 새 수신 정의, 새 ACM 기반 인증서 API 작업, ALB 컴퓨팅 크기 조정 또는 인증서 교체)에 실패합니다. 자세한 내용은 * AWS 사용 설명서*의 [관리형 인증서 갱신 문제 해결](https://docs.aws.amazon.com/acm/latest/userguide/troubleshooting-renewal.html)을 참조하세요. + Amazon EKS 컨트롤 플레인 로그는 네트워크 연결 해제 중 Kubernetes 컨트롤 플레인 인스턴스에서 로컬로 캐시됩니다. 다시 연결되면 로그가 상위 AWS 리전의 CloudWatch Logs로 전송됩니다. [Prometheus](https://prometheus.io/), [Grafana](https://grafana.com/) 또는 Amazon EKS 파트너 솔루션을 사용하여 Kubernetes API 서버의 지표 엔드포인트를 사용하거나 로그에 Fluent Bit를 사용하여 로컬로 클러스터를 모니터링할 수 있습니다. + 애플리케이션 트래픽을 위해 Outposts에서 AWS Load Balancer Controller를 사용하는 경우 AWS Load Balancer Controller 뒤에 있는 기존 포드는 네트워크 연결 해제 중 트래픽을 계속 수신합니다. 네트워크 연결 해제 중 생성된 새 포드는 Outpost가 AWS 클라우드에 다시 연결될 때까지 트래픽을 수신하지 않습니다. 네트워크 연결 해제 중 조정 요구 사항을 수용할 수 있도록 AWS 클라우드에 연결되어 있는 동안 애플리케이션의 복제본 수를 설정하는 것이 좋습니다. + Kubernetes용 Amazon VPC CNI 플러그인은 기본적으로 [보조 IP 모드](https://aws.github.io/aws-eks-best-practices/networking/vpc-cni/#overview)로 설정됩니다. `WARM_ENI_TARGET`=`1`로 구성되어 플러그인이 사용 가능한 IP 주소의 '전체 탄력적 네트워크 인터페이스'를 사용 가능한 상태로 유지할 수 있습니다. 연결 해제된 상태에서 조정 요구 사항에 따라 `WARM_ENI_TARGET`, `WARM_IP_TARGET` 및 `MINIMUM_IP_TARGET` 값을 변경하는 것을 고려하세요. 자세한 내용을 알아보려면 GitHub에서 플러그인의 [readme](https://github.com/aws/amazon-vpc-cni-k8s/blob/master/README.md) 파일을 참조하세요. 각 인스턴스 유형별로 지원되는 최대 포드 수 목록은 GitHub의 [eni-max-pods.txt](https://github.com/aws/amazon-vpc-cni-k8s/blob/master/misc/eni-max-pods.txt) 파일을 참조하세요. ## 네트워크 연결 해제 중 로컬 클러스터에 인증 네트워크 연결 해제 중에는 AWS ID 및 액세스 관리(IAM)를 사용할 수 없습니다. 연결이 해제된 동안에는 IAM 자격 증명을 사용하여 로컬 클러스터에 인증할 수 없습니다. 그러나 연결이 해제되면 `x509` 인증서를 사용하여 로컬 네트워크를 통해 클러스터에 연결할 수 있습니다. 연결 해제 중 사용할 클라이언트 `X509` 인증서를 다운로드하여 저장해야 합니다. 이 주제에서는 연결 해제된 상태일 때 클러스터에 인증하기 위해 인증서를 생성하고 사용하는 방법을 알아봅니다. 1. 인증서 서명 요청을 생성합니다. 1. 인증서 서명 요청을 생성합니다. ``` openssl req -new -newkey rsa:4096 -nodes -days 365 \ -keyout admin.key -out admin.csr -subj "/CN=admin" ``` 1. Kubernetes에서 인증서 서명 요청을 생성합니다. ``` BASE64_CSR=$(cat admin.csr | base64 -w 0) cat << EOF > admin-csr.yaml apiVersion: certificates.k8s.io/v1 kind: CertificateSigningRequest metadata: name: admin-csr spec: signerName: kubernetes.io/kube-apiserver-client request: ${BASE64_CSR} usages: - client auth EOF ``` 1. `kubectl`을 사용하여 인증서 서명 요청을 생성합니다. ``` kubectl create -f admin-csr.yaml ``` 1. 인증서 서명 요청의 상태를 확인합니다. ``` kubectl get csr admin-csr ``` 예제 출력은 다음과 같습니다. ``` NAME AGE REQUESTOR CONDITION admin-csr 11m kubernetes-admin Pending ``` Kubernetes에서 인증서 서명 요청을 생성했습니다. 1. 인증서 서명 요청을 승인합니다. ``` kubectl certificate approve admin-csr ``` 1. 인증서 서명 요청의 승인 상태를 다시 확인합니다. ``` kubectl get csr admin-csr ``` 예제 출력은 다음과 같습니다. ``` NAME AGE REQUESTOR CONDITION admin-csr 11m kubernetes-admin Approved ``` 1. 인증서를 검색하고 확인합니다. 1. 인증서를 검색합니다. ``` kubectl get csr admin-csr -o jsonpath='{.status.certificate}' | base64 --decode > admin.crt ``` 1. 인증서를 확인합니다. ``` cat admin.crt ``` 1. `admin` 사용자에 대한 클러스터 역할 바인딩을 생성합니다. ``` kubectl create clusterrolebinding admin --clusterrole=cluster-admin \ --user=admin --group=system:masters ``` 1. 연결 해제된 상태에 대한 사용자 범위 kubeconfig를 생성합니다. 다운로드한 `admin` 인증서를 사용하여 `kubeconfig` 파일을 생성할 수 있습니다. 다음 명령에서 *my-cluster*와 *apiserver-endpoint*를 바꿉니다. ``` aws eks describe-cluster --name my-cluster \ --query "cluster.certificateAuthority" \ --output text | base64 --decode > ca.crt ``` ``` kubectl config --kubeconfig admin.kubeconfig set-cluster my-cluster \ --certificate-authority=ca.crt --server apiserver-endpoint --embed-certs ``` ``` kubectl config --kubeconfig admin.kubeconfig set-credentials admin \ --client-certificate=admin.crt --client-key=admin.key --embed-certs ``` ``` kubectl config --kubeconfig admin.kubeconfig set-context admin@my-cluster \ --cluster my-cluster --user admin ``` ``` kubectl config --kubeconfig admin.kubeconfig use-context admin@my-cluster ``` 1. `kubeconfig` 파일을 봅니다. ``` kubectl get nodes --kubeconfig admin.kubeconfig ``` 1. Outpost에서 서비스가 이미 프로덕션에 있는 경우 이 단계를 건너뜁니다. Amazon EKS가 Outpost에서 실행되는 유일한 서비스이고 Outpost가 현재 프로덕션에 없는 경우 네트워크 연결 해제를 시뮬레이션할 수 있습니다. 로컬 클러스터를 사용하여 프로덕션에 들어가기 전에 연결 해제를 시뮬레이션하여 연결 해제된 상태에서도 클러스터에 계속 액세스할 수 있는지 확인해야 합니다. 1. Outpost를 AWS 리전에 연결하는 네트워킹 디바이스에 방화벽 규칙을 적용합니다. 그러면 Outpost의 서비스 링크 연결이 해제됩니다. 새 인스턴스를 생성할 수 없습니다. 현재 실행 중인 인스턴스는 AWS 리전 및 인터넷 연결이 끊어집니다. 1. `x509` 인증서를 사용하여 연결이 해제된 동안 로컬 클러스터 연결을 테스트할 수 있습니다. `kubeconfig`를 이전 단계에서 생성한 `admin.kubeconfig`로 변경해야 합니다. *my-cluster*를 로컬 클러스터의 이름으로 바꿉니다. ``` kubectl config use-context admin@my-cluster --kubeconfig admin.kubeconfig ``` 연결 해제된 상태에서 로컬 클러스터에 문제가 있는 경우 지원 티켓을 여는 것이 좋습니다. # 용량 고려 사항에 따라 AWS Outposts의 Amazon EKS 클러스터에 대한 인스턴스 유형 및 배치 그룹 선택 이 주제에서는 Kubernetes 컨트롤 플레인 인스턴스 유형 선택 및 Outpost의 로컬 Amazon EKS 클러스터에 대한 고가용성 요구 사항을 충족하기 위한 배치 그룹 사용(선택 사항)에 대한 지침을 제공합니다. Outposts에서 로컬 클러스터의 Kubernetes 컨트롤 플레인에 사용할 인스턴스 유형(예: `m5`, `c5` 또는 `r5`)을 선택하기 전에 Outpost 구성에서 사용 가능한 인스턴스 유형을 확인합니다. 사용 가능한 인스턴스 유형 식별 후 워크로드에 필요한 노드 수에 따라 인스턴스 크기(예: `large`, `xlarge` 또는 `2xlarge`)를 선택합니다. 다음 표에는 인스턴스 크기 선택에 대한 권장 사항이 나와 있습니다. **참고** 인스턴스 크기는 Outposts에 배정되어 있어야 합니다. 로컬 클러스터의 수명 동안 Outposts에서 사용할 수 있는 크기의 인스턴스 3개에 대한 용량이 충분한지 확인합니다. 사용 가능한 Amazon EC2 인스턴스 유형 목록은 [AWS Outposts 랙 기능](https://aws.amazon.com/outposts/rack/features/)의 컴퓨팅 및 스토리지 섹션을 참조하세요. | 노드 수 | Kubernetes 컨트롤 플레인 인스턴스 크기 | | --- | --- | | 1\$120 | `large` | | 21\$1100 | `xlarge` | | 101\$1250 | `2xlarge` | | 251\$1500 | `4xlarge` | Kubernetes 컨트롤 플레인용 스토리지에는 `etcd`의 필수 IOPS를 충족하기 위해 로컬 클러스터마다 246GB의 Amazon EBS 스토리지가 필요합니다. 로컬 클러스터가 생성될 때 Amazon EBS 볼륨이 자동으로 프로비저닝됩니다. ## 컨트롤 플레인 배치 `OutpostConfig.ControlPlanePlacement.GroupName` 속성으로 배치 그룹을 지정하지 않으면 Kubernetes 컨트롤 플레인용으로 프로비저닝된 Amazon EC2 인스턴스에는 Outpost에서 사용할 수 있는 기본 용량에 대한 특정 하드웨어 배치가 적용되지 않습니다. 배치 그룹을 사용하여 Outpost의 로컬 Amazon EKS 클러스터에 대한 고가용성 요구 사항을 충족할 수 있습니다. 클러스터 생성 중에 배치 그룹을 지정하면 Kubernetes 컨트롤 플레인 인스턴스의 배치에 영향을 줍니다. 인스턴스가 독립적인 기본 하드웨어(랙 또는 호스트) 전체에 분산되어 하드웨어 장애 발생 시 상관 관계가 있는 인스턴스 영향을 최소화합니다. 구성할 수 있는 분산 유형은 배포되어 있는 Outpost 랙의 수에 따라 다릅니다. + **하나의 논리적 Outpost에 1개 또는 2개의 물리적 랙이 있는 배포** – Kubernetes 컨트롤 플레인 인스턴스에 대해 선택하는 인스턴스 유형으로 구성되는 호스트가 3개 이상 있어야 합니다. *호스트 수준 스프레드*를 사용하는 *스프레드* 배치 그룹은 모든 Kubernetes 컨트롤 플레인 인스턴스가 Outpost 배포에서 사용할 수 있는 기본 랙 내의 개별 호스트에서 실행되도록 합니다. + **하나의 논리적 Outpost에 3개 이상의 물리적 랙이 있는 배포** – Kubernetes 컨트롤 플레인 인스턴스에 대해 선택하는 인스턴스 유형으로 구성된 호스트가 3개 이상 있어야 합니다. *랙 수준 스프레드*를 사용하는 *스프레드* 배치 그룹은 모든 Kubernetes 컨트롤 플레인 인스턴스가 Outpost 배포의 개별 랙에서 실행되도록 합니다. 이전 옵션에서 설명한 대로 *호스트 수준 분산* 배치 그룹을 사용할 수도 있습니다. 원하는 배치 그룹을 생성하는 것은 본인 책임입니다. `CreateCluster` API를 호출할 때 배치 그룹을 지정합니다. 배치 그룹과 생성 방법에 대한 자세한 내용은 Amazon EC2 사용 설명서의 [배치 그룹](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/placement-groups.html)을 참조하세요. + 배치 그룹을 지정할 때 로컬 Amazon EKS 클러스터를 생성하려면 Outpost에 사용 가능한 배정된 용량이 있어야 합니다. 용량은 호스트 유형을 사용하는지 아니면 랙 분산 유형을 사용하는지에 따라 달라집니다. 용량이 부족하면 클러스터가 `Creating` 상태로 유지됩니다. [DescribeCluster](https://docs.aws.amazon.com/eks/latest/APIReference/API_DescribeCluster.html) API 응답의 상태 필드에서 `Insufficient Capacity Error`를 확인할 수 있습니다. 생성 프로세스를 진행하려면 용량을 확보해야 합니다. + Amazon EKS 로컬 클러스터 플랫폼 및 버전 업데이트 중에는 클러스터의 Kubernetes 컨트롤 플레인 인스턴스가 롤링 업데이트 전략을 통해 새 인스턴스로 바뀝니다. 이 대체 프로세스 중에 각 컨트롤 플레인 인스턴스가 종료되어 해당 슬롯이 비워집니다. 업데이트한 새 인스턴스가 대신에 프로비저닝됩니다. 업데이트한 인스턴스는 릴리스된 슬롯에 배치될 수도 있습니다. 관련 없는 다른 인스턴스에서 슬롯을 사용하고 필요한 분산 토폴로지 요구 사항을 충족하는 용량이 더는 남아 있지 않으면 클러스터가 `Updating` 상태로 유지됩니다. [DescribeCluster](https://docs.aws.amazon.com/eks/latest/APIReference/API_DescribeCluster.html) API 응답의 상태 필드에서 각 `Insufficient Capacity Error`를 확인할 수 있습니다. 업데이트 프로세스를 진행하고 이전의 고가용성 수준을 다시 설정할 수 있도록 용량을 확보해야 합니다. + 각 AWS 리전에서 계정당 최대 500개의 배치 그룹을 생성할 수 있습니다. 자세한 내용은 Amazon EC2 사용 설명서의 [일반 규칙 및 제한 사항](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/placement-groups.html#placement-groups-limitations-general)을 참조하세요. # AWS Outposts의 로컬 Amazon EKS 클러스터 문제 해결 이 주제에서는 로컬 클러스터를 사용하는 동안 발생할 수 있는 몇 가지 일반적 오류와 문제를 해결하는 방법을 설명합니다. 로컬 클러스터는 클라우드의 Amazon EKS 클러스터와 유사하지만, Amazon EKS 서비스에서 관리하는 방식에는 몇 가지 차이점이 있습니다. **중요** AWS Support에서 명시적으로 지시하지 않는 한 Outpost에서 실행되는 관리형 EKS 로컬 클러스터 `Kubernetes` 컨트롤 플레인 인스턴스를 종료하지 마십시오. 이러한 인스턴스를 종료하면 여러 인스턴스가 동시에 종료되는 경우 로컬 클러스터가 손실되는 등 로컬 클러스터 서비스 가용성이 위험해질 수 있습니다. EKS 로컬 클러스터 `Kubernetes` 컨트롤 플레인 인스턴스는 EC2 인스턴스 콘솔에서 `eks-local:controlplane-name` 태그로 식별됩니다. ## API 동작 로컬 클러스터는 Amazon EKS API를 통해 생성되지만, 비동기 방식으로 실행됩니다. 즉, Amazon EKS API에 대한 요청이 로컬 클러스터에 즉시 반환됩니다. 그러나 이러한 요청은 성공하거나, 입력 검증 오류로 인해 빠르게 실패하거나, 실패하고 설명이 포함된 검증 오류가 있을 수 있습니다. 이 동작은 Kubernetes API와 유사합니다. 로컬 클러스터는 `FAILED` 상태로 전환되지 않습니다. Amazon EKS에서는 클러스터 상태를 사용자가 요청한 원하는 상태와 지속적으로 조정하려고 시도합니다. 따라서 로컬 클러스터가 근본적인 문제가 해결될 때까지 장기간 `CREATING` 상태로 유지될 수도 있습니다. ## 클러스터 상태 필드 설명 로컬 클러스터 문제는 [describe-cluster](https://docs.aws.amazon.com/cli/latest/reference/eks/describe-cluster.html) Amazon EKS AWS CLI 명령을 사용하여 검색할 수 있습니다. 로컬 클러스터 문제는 `describe-cluster` 명령 응답의 `cluster.health` 필드에 표시됩니다. 이 필드에 포함된 메시지에는 오류 코드, 설명이 포함된 메시지 및 관련 리소스 ID가 포함됩니다. 이 정보는 Amazon EKS API와 AWS CLI를 통해서만 제공됩니다. 다음 예제에서 *my-cluster*를 로컬 클러스터의 이름으로 바꿉니다. ``` aws eks describe-cluster --name my-cluster --query 'cluster.health' ``` 예제 출력은 다음과 같습니다. ``` { "issues": [ { "code": "ConfigurationConflict", "message": "The instance type 'm5.large' is not supported in Outpost 'my-outpost-arn'.", "resourceIds": [ "my-cluster-arn" ] } ] } ``` 문제를 복구할 수 없는 경우 로컬 클러스터를 삭제하고 새 클러스터를 생성해야 할 수 있습니다. 예를 들어, Outpost에서 사용할 수 없는 인스턴스 유형으로 클러스터를 프로비저닝하려고 합니다. 다음 표에는 일반적인 상태 관련 오류가 포함되어 있습니다. | 오류 시나리오 | 코드 | 메시지 | ResourceIds | | --- | --- | --- | --- | | 제공된 서브넷을 찾을 수 없습니다. | `ResourceNotFound` | `The subnet ID subnet-id does not exist` | 제공된 모든 서브넷 ID | | 제공된 서브넷이 동일한 VPC에 속하지 않습니다. | `ConfigurationConflict` | `Subnets specified must belong to the same VPC` | 제공된 모든 서브넷 ID | | 제공된 일부 서브넷이 지정된 Outpost에 속하지 않습니다. | `ConfigurationConflict` | `Subnet subnet-id expected to be in outpost-arn, but is in other-outpost-arn ` | 문제가 있는 서브넷 ID | | 제공된 일부 서브넷이 어느 Outpost에도 속하지 않습니다. | `ConfigurationConflict` | `Subnet subnet-id is not part of any Outpost` | 문제가 있는 서브넷 ID | | 제공된 일부 서브넷에 컨트롤 플레인 인스턴스용 탄력적 네트워크 인터페이스를 생성하기에 충분한 여유 주소가 없습니다. | `ResourceLimitExceeded` | `The specified subnet does not have enough free addresses to satisfy the request.` | 문제가 있는 서브넷 ID | | 지정된 컨트롤 플레인 인스턴스 유형이 Outpost에서 지원되지 않습니다. | `ConfigurationConflict` | `The instance type type is not supported in Outpost outpost-arn ` | 클러스터 ARN | | 컨트롤 플레인 Amazon EC2 인스턴스를 종료했거나 `run-instance`에 성공했지만, 관찰된 상태가 `Terminated`로 변경됩니다. 이는 Outpost가 다시 연결되고 Amazon EBS 내부 오류로 인해 Amazon EC2 내부 워크플로가 실패한 후 일정 기간 동안 발생할 수 있습니다. | `InternalFailure` | `EC2 instance state "Terminated" is unexpected` | 클러스터 ARN | | Outpost의 용량이 부족합니다. 이는 Outpost가 AWS 리전에서 연결 해제된 경우 클러스터를 생성 중일 때 발생할 수도 있습니다. | `ResourceLimitExceeded` | `There is not enough capacity on the Outpost to launch or start the instance.` | 클러스터 ARN | | 계정에서 보안 그룹 할당량을 초과했습니다. | `ResourceLimitExceeded` | Amazon EC2 API에서 반환된 오류 메시지 | 대상 VPC ID | | 계정에서 탄력적 네트워크 인터페이스 할당량을 초과했습니다. | `ResourceLimitExceeded` | Amazon EC2 API에서 반환된 오류 메시지 | 대상 서브넷 ID | | 컨트롤 플레인 인스턴스는 AWS 시스템 관리자를 통해 연결할 수 없습니다. 해결 방법은 [컨트롤 플레인 인스턴스는 AWS 시스템 관리자를 통해 연결할 수 없습니다.](#outposts-troubleshooting-control-plane-instances-ssm) 섹션을 참조하세요. | `ClusterUnreachable` | Amazon EKS control plane instances are not reachable through SSM. Please verify your SSM and network configuration, and reference the EKS on Outposts troubleshooting documentation.(Amazon EKS 컨트롤 플레인 인스턴스는 SSM을 통해 연결할 수 없습니다. SSM 및 네트워크 구성을 확인하고 Outposts의 EKS 문제 해결 문서를 참조하세요.) | Amazon EC2 인스턴스 ID | | 관리형 보안 그룹 또는 탄력적 네트워크 인터페이스에 대한 세부 정보를 가져오는 동안 오류가 발생했습니다. | Amazon EC2 클라이언트 오류 코드 기준 | Amazon EC2 API에서 반환된 오류 메시지 | 모든 관리형 보안 그룹 ID | | 보안 그룹 수신 규칙을 승인하거나 취소하는 동안 오류가 발생했습니다. 이는 클러스터 및 컨트롤 플레인 보안 그룹 모두에 적용됩니다. | Amazon EC2 클라이언트 오류 코드 기준 | Amazon EC2 API에서 반환된 오류 메시지 | 문제가 있는 보안 그룹 ID | | 컨트롤 플레인 인스턴스에 대한 탄력적 네트워크 인터페이스를 삭제하는 동안 오류가 발생했습니다. | Amazon EC2 클라이언트 오류 코드 기준 | Amazon EC2 API에서 반환된 오류 메시지 | 문제가 있는 탄력적 네트워크 인터페이스 ID | 다음 표에는 `describe-cluster` 응답의 상태 필드에 표시되는 다른 AWS 서비스의 오류가 나열되어 있습니다. | Amazon EC2 오류 코드 | 클러스터 상태 문제 코드 | 설명 | | --- | --- | --- | | `AuthFailure` | `AccessDenied` | 이 오류는 여러 가지 이유로 발생할 수 있습니다. 가장 일반적인 이유는 서비스 연결 역할 정책의 범위를 좁히기 위해 서비스에서 사용하는 태그를 컨트롤 플레인에서 실수로 제거했기 때문입니다. 이렇게 되면 Amazon EKS에서 더는 이러한AWS 리소스를 관리하고 모니터링할 수 없습니다. | | `UnauthorizedOperation` | `AccessDenied` | 이 오류는 여러 가지 이유로 발생할 수 있습니다. 가장 일반적인 이유는 서비스 연결 역할 정책의 범위를 좁히기 위해 서비스에서 사용하는 태그를 컨트롤 플레인에서 실수로 제거했기 때문입니다. 이렇게 되면 Amazon EKS에서 더는 이러한AWS 리소스를 관리하고 모니터링할 수 없습니다. | | `InvalidSubnetID.NotFound` | `ResourceNotFound` | 이 오류는 보안 그룹의 수신 규칙에 대한 서브넷 ID를 찾을 수 없을 때 발생합니다. | | `InvalidPermission.NotFound` | `ResourceNotFound` | 이 오류는 보안 그룹의 수신 규칙에 대한 권한이 올바르지 않을 때 발생합니다. | | `InvalidGroup.NotFound` | `ResourceNotFound` | 이 오류는 보안 그룹의 수신 규칙 그룹을 찾을 수 없을 때 발생합니다. | | `InvalidNetworkInterfaceID.NotFound` | `ResourceNotFound` | 이 오류는 보안 그룹의 수신 규칙에 대한 네트워크 인터페이스 ID를 찾을 수 없을 때 발생합니다. | | `InsufficientFreeAddressesInSubnet` | `ResourceLimitExceeded` | 이 오류는 서브넷 리소스 할당량을 초과했을 때 발생합니다. | | `InsufficientCapacityOnOutpost` | `ResourceLimitExceeded` | 이 오류는 출력 용량 할당량을 초과했을 때 발생합니다. | | `NetworkInterfaceLimitExceeded` | `ResourceLimitExceeded` | 이 오류는 탄력적 네트워크 인터페이스 할당량을 초과했을 때 발생합니다. | | `SecurityGroupLimitExceeded` | `ResourceLimitExceeded` | 이 오류는 보안 그룹 할당량을 초과했을 때 발생합니다. | | `VcpuLimitExceeded` | `ResourceLimitExceeded` | 이는 새 계정에서 Amazon EC2 인스턴스를 생성할 때 관찰됩니다. 오류는 다음과 비슷할 수 있습니다. "`You have requested more vCPU capacity than your current vCPU limit of 32 allows for the instance bucket that the specified instance type belongs to. Please visit http://aws.amazon.com/contact-us/ec2-request to request an adjustment to this limit."` | | `InvalidParameterValue` | `ConfigurationConflict` | 지정된 인스턴스 유형이 Outpost에서 지원되지 않는 경우 Amazon EC2가 이 오류 코드를 반환합니다. | | 기타 모든 오류 | `InternalFailure` | 없음 | ## 클러스터를 생성하거나 수정할 수 없음 클라우드에서 호스팅되는 Amazon EKS 클러스터와 다른 권한과 정책이 로컬 클러스터에 필요합니다. 클러스터가 생성되지 않고 `InvalidPermissions` 오류가 발생하면 사용 중인 클러스터 역할에 [AmazonEKSLocalOutpostClusterPolicy](security-iam-awsmanpol.md#security-iam-awsmanpol-amazonekslocaloutpostclusterpolicy) 관리형 정책이 연결되어 있는지 다시 확인합니다. 다른 모든 API 직접 호출에는 클라우드의 Amazon EKS 클러스터와 동일한 권한 집합이 필요합니다. ## 클러스터가 `CREATING` 상태에서 멈춤 로컬 클러스터 생성에 걸리는 시간은 여러 가지 요인에 따라 다릅니다. 네트워크 구성, Outpost 구성 및 클러스터의 구성이 이러한 요인에 포함됩니다. 일반적으로 15\$120분 이내에 로컬 클러스터가 생성되고 `ACTIVE` 상태로 변경됩니다. 로컬 클러스터가 `CREATING` 상태로 유지되는 경우 `cluster.health` 출력 필드에서 원인에 대한 정보의 `describe-cluster`를 직접 호출할 수 있습니다. 가장 일반적인 문제는 다음과 같습니다. + 클러스터에서 Systems Manager가 있는 AWS 리전의 컨트롤 플레인 인스턴스에 연결할 수 없습니다. 리전 내 Bastion Host에서 `aws ssm start-session --target instance-id `를 직접 호출하여 이를 확인할 수 있습니다. 명령이 작동하지 않으면 Systems Manager가 컨트롤 플레인 인스턴스에서 실행 중인지 확인합니다. 클러스터를 삭제한 다음에 다시 생성하여 해결하는 방법도 있습니다. + EBS 볼륨에 대한 KMS 키 권한으로 인해 컨트롤 플레인 인스턴스가 생성되지 않습니다. 암호화된 EBS 볼륨에 사용자 관리형 KMS 키를 사용하면 키에 액세스할 수 없는 경우 컨트롤 플레인 인스턴스가 종료됩니다. 인스턴스가 종료되면 AWS 관리형 KMS 키로 전환하거나 사용자 관리형 키 정책이 클러스터 역할에 필요한 권한을 부여하는지 확인하세요. + Systems Manager 컨트롤 플레인 인스턴스에 인터넷 액세스 권한이 없을 수도 있습니다. 클러스터를 생성할 때 제공한 서브넷에 NAT 게이트웨이와 VPC(인터넷 게이트웨이 포함)가 있는지 확인합니다. VPC 연결성 분석기를 사용하여 컨트롤 플레인 인스턴스가 인터넷 게이트웨이에 연결할 수 있는지 확인합니다. 자세한 내용을 알아보려면 [Getting started with VPC Reachability Analyzer](https://docs.aws.amazon.com/vpc/latest/reachability/getting-started.html)(VPC Reachability Analyzer 시작하기)를 참조하세요. + 제공한 역할 ARN에 정책이 없습니다. [AWS 관리형 정책: AmazonEKSLocalOutpostClusterPolicy](security-iam-awsmanpol.md#security-iam-awsmanpol-amazonekslocaloutpostclusterpolicy)가 역할에서 제거되었는지 확인합니다. AWS CloudFormation 스택이 잘못 구성된 경우에도 이 문제가 발생할 수 있습니다. + 제공된 모든 서브넷이 동일한 Outpost와 연결되어야 하며 서로 연결되어야 합니다. 클러스터가 생성될 때 여러 서브넷이 지정되면 Amazon EKS에서는 컨트롤 플레인 인스턴스를 여러 서브넷에 분산하려고 시도합니다. + Amazon EKS 관리형 보안 그룹은 탄력적 네트워크 인터페이스에 적용됩니다. 그러나 NACL 방화벽 규칙과 같은 기타 구성 요소가 탄력적 네트워크 인터페이스의 규칙과 충돌할 수도 있습니다. **VPC 및 서브넷 DNS 구성이 잘못 구성되었거나 누락됨** [AWS Outposts에서 Amazon EKS 클러스터를 위한 VPC 및 서브넷 생성](eks-outposts-vpc-subnet-requirements.md) 검토 ## 클러스터가 `UPDATING` 상태에서 멈춤 Amazon EKS에서 기존의 모든 로컬 클러스터를 해당하는 Kubernetes 마이너 버전에 대한 최신 플랫폼 버전으로 자동으로 업데이트합니다. 플랫폼 버전에 대한 자세한 내용은 [Kubernetes 및 AWS Outposts에 대한 Amazon EKS 플랫폼 버전 알아보기](eks-outposts-platform-versions.md) 섹션을 참조하세요. 자동 플랫폼 버전 롤아웃 중에 클러스터 상태가 `UPDATING`으로 변경됩니다. 업데이트 프로세스는 모든 Kubernetes 컨트롤 플레인 인스턴스를 해당 Kubernetes 마이너 버전에 대해 릴리스된 최신 보안 경로 및 버그 수정이 포함된 새 인스턴스로 대체하는 것으로 구성됩니다. 일반적으로 로컬 클러스터 플랫폼 업데이트 프로세스는 30분 내에 완료되며 클러스터는 `ACTIVE` 상태로 다시 변경됩니다. 로컬 클러스터가 장기가 `UPDATING` 상태로 유지되는 경우 `describe-cluster`를 직접적으로 직접 호출하여 `cluster.health` 출력 필드에서 원인에 대한 정보를 확인할 수 있습니다. Amazon EKS는 로컬 클러스터 가용성을 유지하고 서비스 중단을 방지하기 위해 Kubernetes 컨트롤 플레인 인스턴스 3개 중 최소 2개가 정상이고 작동하는 클러스터 노드인지 확인합니다. 로컬 클러스터가 `UPDATING` 상태에서 멈춘 경우 이는 대개 프로세스가 계속 진행되더라도 두 인스턴스의 최소 가용성을 보장할 수 없는 인프라나 구성 문제가 있기 때문입니다. 따라서 로컬 클러스터 서비스 중단을 방지하기 위해 업데이트 프로세스 진행이 중지됩니다. `UPDATING` 상태에 멈춘 로컬 클러스터의 문제를 해결하고 근본 원인을 해결하여 업데이트 프로세스를 완료하고 3개의 Kubernetes 컨트롤 플레인 인스턴스의 고가용성을 통해 로컬 클러스터를 다시 `ACTIVE`로 복원하는 것이 중요합니다. AWS Support에서 명시적으로 지시하지 않는 한 Outposts에서 관리형 EKS 로컬 클러스터 `Kubernetes` 인스턴스를 종료하지 마세요. 이는 특히 `UPDATING` 상태에 멈춰 있는 로컬 클러스터의 경우 특히 중요합니다. 다른 컨트롤 플레인 노드가 완전 정상이 아닐 가능성이 높고 잘못된 인스턴스를 종료하면 서비스가 중단되고 로컬 클러스터 데이터가 손실될 위험이 있기 때문입니다. 가장 일반적인 문제는 다음과 같습니다. + 로컬 클러스터가 처음 생성된 이후 네트워킹 구성이 변경되어 하나 이상의 컨트롤 플레인 인스턴스가 System Manager에 연결할 수 없습니다. 리전 내 Bastion Host에서 `aws ssm start-session --target instance-id `를 직접 호출하여 이를 확인할 수 있습니다. 명령이 작동하지 않으면 Systems Manager가 컨트롤 플레인 인스턴스에서 실행 중인지 확인합니다. + EBS 볼륨에 대한 KMS 키 권한으로 인해 새 컨트롤 플레인 인스턴스를 생성하지 못했습니다. 암호화된 EBS 볼륨에 사용자 관리형 KMS 키를 사용하면 키에 액세스할 수 없는 경우 컨트롤 플레인 인스턴스가 종료됩니다. 인스턴스가 종료되면 AWS 관리형 KMS 키로 전환하거나 사용자 관리형 키 정책이 클러스터 역할에 필요한 권한을 부여하는지 확인합니다. + Systems Manager 컨트롤 플레인 인스턴스가 인터넷 액세스 권한을 잃었을 수 있습니다. 클러스터를 생성할 때 제공된 서브넷에 NAT 게이트웨이와 VPC(인터넷 게이트웨이 포함)가 있는지 확인합니다. VPC 연결성 분석기를 사용하여 컨트롤 플레인 인스턴스가 인터넷 게이트웨이에 연결할 수 있는지 확인합니다. 자세한 내용을 알아보려면 [Getting started with VPC Reachability Analyzer](https://docs.aws.amazon.com/vpc/latest/reachability/getting-started.html)(VPC Reachability Analyzer 시작하기)를 참조하세요. 프라이빗 네트워크에 아웃바운드 인터넷 연결이 없는 경우 클러스터의 리전 서브넷에 필요한 모든 VPC 엔드포인트와 게이트웨이 엔드포인트가 여전히 존재하는지 확인합니다([AWS 서비스에 대한 서브넷 액세스](eks-outposts-vpc-subnet-requirements.md#subnet-access-to-services) 참조). + 제공한 역할 ARN에 정책이 없습니다. [AWS 관리형 정책: AmazonEKSLocalOutpostClusterPolicy](security-iam-awsmanpol.md#security-iam-awsmanpol-amazonekslocaloutpostclusterpolicy)가 역할에서 제거되지 않았는지 확인합니다. + 새 Kubernetes 컨트롤 플레인 인스턴스 중 하나에서 예기치 않은 부트스트래핑 실패가 발생했을 수 있습니다. 이 예외적인 경우 문제 해결 및 로그 수집에 대한 추가 지침은 [AWS Support 센터](https://console.aws.amazon.com/support/home)에 티켓을 제출하세요. ## 클러스터에 노드를 조인할 수 없음 + AMI 문제: + 호환되지 않는 AMI를 사용하고 있습니다. Amazon EKS 최적화 Amazon Linux 2 AMI만 지원됩니다(`amazon-linux-2`, `amazon-linux-2-gpu`, `amazon-linux-2-arm64`). AL2023 노드를 AWS Outposts의 EKS LocalClusters에 조인하려고 하면 노드가 클러스터에 조인하지 못합니다. 자세한 내용은 [AWS Outposts에서 Amazon Linux 노드 생성](eks-outposts-self-managed-nodes.md)을 참조하세요. + AWS CloudFormation 템플릿을 사용하여 노드를 생성한 경우 지원되지 않는 AMI를 사용하고 있지 않은지 확인합니다. + AWS IAM Authenticator `ConfigMap` 누락 – 누락된 경우 생성해야 합니다. 자세한 정보는 [클러스터에 `aws-auth` `ConfigMap` 적용](auth-configmap.md#aws-auth-configmap)을 참조하세요. + 잘못된 보안 그룹 사용 - 워커 노드의 보안 그룹에 `eks-cluster-sg-cluster-name-uniqueid `를 사용해야 합니다. 선택한 보안 그룹은 스택이 사용될 때마다 새 보안 그룹을 허용하도록 AWS CloudFormation에 의해 변경됩니다. + 예상치 못한 프라이빗 링크 VPC 단계 수행 – 잘못된 CA 데이터(`--b64-cluster-ca`) 또는 API 엔드포인트(`--apiserver-endpoint`)가 전달됩니다. ## 로그 수집 Outpost가 연결된 AWS 리전에서 연결 해제되면 Kubernetes 클러스터는 정상적으로 계속 작동할 수 있습니다. 그러나 클러스터가 제대로 작동하지 않는 경우 [네트워크 연결 해제를 위해 AWS Outposts에서 로컬 Amazon EKS 클러스터 준비](eks-outposts-network-disconnects.md)의 문제 해결 단계를 따릅니다. 다른 문제가 발생하면 AWS Support에 문의하세요. AWS 지원은 로그 수집 도구를 다운로드하고 실행하는 방법을 안내할 수 있습니다. 그렇게 하면 Kubernetes 클러스터 컨트롤 플레인 인스턴스에서 로그를 수집하여 추가 조사를 위해 AWS Support 지원에 보낼 수 있습니다. ## 컨트롤 플레인 인스턴스는 AWS 시스템 관리자를 통해 연결할 수 없습니다. AWS 시스템 관리자(Systems Manager)를 통해 Amazon EKS 컨트롤 플레인 인스턴스에 연결할 수 없는 경우, Amazon EKS는 클러스터에 대해 다음 오류를 표시합니다. ``` Amazon EKS control plane instances are not reachable through SSM. Please verify your SSM and network configuration, and reference the EKS on Outposts troubleshooting documentation. ``` 이 문제를 해결하려면 VPC 및 서브넷이 [AWS Outposts에서 Amazon EKS 클러스터를 위한 VPC 및 서브넷 생성](eks-outposts-vpc-subnet-requirements.md)의 요구 사항을 충족하는지 확인하고 AWS 시스템 관리자 사용 설명서의 [세션 관리자 설정](https://docs.aws.amazon.com/systems-manager/latest/userguide/session-manager-getting-started.html)의 단계를 완료했는지 확인하세요. # AWS Outposts에 Amazon Linux 노드 생성 **중요** Outposts의 Amazon EKS 로컬 클러스터는 다음과 같은 Amazon EKS 최적화 Amazon Linux 2023 AMI에서 생성된 노드만 지원합니다. 표준 Amazon Linux 2023(`amazon-linux-2023/x86_64/standard`) Accelerated Nvidia Amazon Linux 2023(`amazon-linux-2023/x86_64/nvidia`) Accelerated Neuron Amazon Linux 2023(`amazon-linux-2023/x86_64/neuron`) AWS는 AL2 최적화 및 AL2 가속 AMI에 대한 지원을 2025년 11월 26일부로 종료했습니다. 지원 종료(EOS) 날짜(2025년 11월 26일) 이후에도 EKS AL2 AMI를 계속 사용할 수 있지만 EKS는 이 날짜 이후에 마이너 릴리스, 패치 및 버그 수정을 포함하여 AL2 AMI에 대한 새로운 Kubernetes 버전 또는 업데이트를 더 이상 릴리스하지 않습니다. AL2 사용 중단에 대한 자세한 내용은 [여기](https://docs.aws.amazon.com/eks/latest/userguide/eks-ami-deprecation-faqs.html)를 참조하세요. 이 주제에서는 Amazon EKS 클러스터에 등록하는 Outpost에서 Amazon Linux 노드의 Auto Scaling을 시작하는 방법을 설명합니다. 클러스터는 AWS 클라우드 또는 Outpost에 있을 수 있습니다. + 기존 Outpost. 자세한 내용은 [AWS Outposts이란 무엇입니까?](https://docs.aws.amazon.com/outposts/latest/userguide/what-is-outposts.html) 섹션을 참조하세요. + 기존 Amazon EKS 클러스터. AWS 클라우드에 클러스터를 배포하려면 [Amazon EKS 클러스터 생성](create-cluster.md) 부분을 참조하세요. Outpost에 클러스터를 배포하려면 [고가용성을 위해 AWS Outposts에서 로컬 Amazon EKS 클러스터 생성](eks-outposts-local-cluster-overview.md) 부분을 참조하세요. + AWS 클라우드의 클러스터에서 노드를 생성 중이며 활성화된 AWS Outposts, AWS Wavelength 또는 AWS 로컬 영역이 있는 AWS 리전에 서브넷이 있다고 가정합니다. 그러면 클러스터를 생성할 때 해당 서브넷이 전달되지 않았어야 합니다. Outpost의 클러스터에 노드를 생성하는 경우 클러스터 생성 시 Outpost 서브넷을 전달해야 합니다. + (AWS 클라우드의 클러스터에 권장됨) 필요한 IAM 정책이 연결된 자체 IAM 역할로 구성된 Kubernetes용 Amazon VPC CNI 플러그인 추가 기능입니다. 자세한 내용은 [IRSA를 사용하도록 Amazon VPC CNI 플러그인 구성](cni-iam-role.md) 섹션을 참조하세요. 로컬 클러스터는 서비스 계정에 대한 IAM 역할을 지원하지 않습니다. `eksctl` 또는 AWS Management Console(AWS CloudFormation 템플릿 사용)을 사용하여 자체 관리형 Amazon Linux 노드 그룹을 생성할 수 있습니다. Terraform도 사용할 수 있습니다. 이 페이지에 설명된 다음 도구를 사용하여 로컬 클러스터의 자체 관리형 노드 그룹을 생성할 수 있습니다. + [`eksctl`](#eksctl_create_nodes_outpost) + [AWS Management Console](#console_create_nodes_outpost) **중요** 자체 관리형 노드 그룹은 사용자 계정에 Amazon EC2 인스턴스를 포함합니다. 이러한 인스턴스는 사용자 또는 Amazon EKS가 컨트롤 플레인 버전을 업데이트할 때 자동으로 업그레이드되지 않습니다. 자체 관리형 노드 그룹에는 콘솔에 업데이트가 필요하다는 표시가 없습니다. 클러스터의 **개요** 탭에 있는 **노드** 목록에서 노드를 선택하여 노드에 설치된 `kubelet` 버전을 확인하면 업데이트가 필요한 노드를 확인할 수 있습니다. 노드를 수동으로 업데이트해야 합니다. 자세한 내용은 [클러스터의 자체 관리형 노드 업데이트](update-workers.md) 섹션을 참조하세요. 자체 관리형 노드에서 kubelet이 사용하는 인증서는 1년 만료로 발급됩니다. 기본적으로 인증서 교체는 활성화되지 **않습니다**(https://kubernetes.io/docs/reference/config-api/kubelet-config.v1beta1/\$1kubelet-config-k8s-io-v1beta1-KubeletConfiguration 참조). 따라서 1년 이상 실행 중인 자체 관리형 노드가 있는 경우 이제 Kubernetes API에 인증할 수 없게 됩니다. 모범 사례에 따라 고객은 자체 관리형 노드 그룹을 정기적으로 업데이트하여 최신 Amazon EKS 최적화 AMI에서 CVE 및 보안 패치를 받는 것이 좋습니다. 자체 관리형 노드 그룹에서 사용되는 AMI를 업데이트하면 노드가 다시 생성되고 만료된 kubelet 인증서로 인해 문제가 발생하지 않습니다. 또는 자체 관리형 노드 그룹을 생성할 때 클라이언트 인증서 교체(https://kubernetes.io/docs/tasks/tls/certificate-rotation/ 참조)를 활성화하여 현재 인증서의 만료가 다가오면 kubelet 인증서가 갱신되도록 할 수도 있습니다. ## `eksctl` **`eksctl`을 사용하여 자체 관리형 Linux 노드 시작 ** 1. 장치에 설치된 `eksctl` 명령줄 도구의 버전 `0.215.0` 이상 또는 AWS CloudShell이 필요합니다. `eksctl`을 설치 또는 업그레이드하려면 `eksctl` 설명서에서 [설치](https://eksctl.io/installation)를 참조하세요. 1. 클러스터가 AWS 클라우드에 있고 **AmazonEKS\$1CNI\$1Policy** 관리형 IAM 정책이 [Amazon EKS 노드 IAM 역할](create-node-role.md)에 연결된 경우 대신 Kubernetes `aws-node` 서비스 계정에 연결하는 IAM 역할에 할당하는 것이 좋습니다. 자세한 내용은 [IRSA를 사용하도록 Amazon VPC CNI 플러그인 구성](cni-iam-role.md) 섹션을 참조하세요. 클러스터가 Outpost에 있는 경우 정책이 노드 역할에 연결되어야 합니다. 1. 다음 명령은 기존 클러스터의 노드 그룹을 생성합니다. `eksctl`을 사용하여 클러스터가 생성되었어야 합니다. *al-nodes*를 노드 그룹의 이름으로 바꿉니다. 노드 그룹 이름은 63자를 초과할 수 없습니다. 문자나 숫자로 시작하되, 나머지 문자의 경우 하이픈과 밑줄을 포함할 수 있습니다. *my-cluster*를 해당 클러스터의 이름으로 바꿉니다. 이름에는 영숫자(대소문자 구분)와 하이픈만 사용할 수 있습니다. 영숫자로 시작해야 하며 100자 이하여야 합니다. 이름은 클러스터를 생성하는 AWS 리전과 AWS 계정 내에서 고유해야 합니다. 클러스터가 Outpost에 있는 경우 *id*를 Outpost 서브넷의 ID로 바꿉니다. 클러스터가 AWS 클라우드에 있는 경우 *id*를 클러스터를 생성할 때 지정하지 않은 서브넷의 ID로 바꿉니다. 나머지 예제 값을 자신의 값으로 바꿉니다. 노드는 기본적으로 제어 영역과 동일한 Kubernetes 버전으로 작성됩니다. *instance-type*을 Outpost에서 사용 가능한 인스턴스 유형으로 바꿉니다. *my-key*를 Amazon EC2 키 페어 또는 퍼블릭 키 이름으로 바꿉니다. 이 키는 노드를 시작한 후 SSH로 연결하는 데 사용됩니다. Amazon EC2 키 페어가 아직 없는 경우 AWS Management Console에서 새로 생성할 수 있습니다. 자세한 내용을 알아보려면 *Amazon EC2 key pairs*의 [Amazon EC2 키 페어](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ec2-key-pairs.html)를 참조하세요. 다음 명령을 사용하여 노드 그룹을 생성합니다. ``` eksctl create nodegroup --cluster my-cluster --name al-nodes --node-type instance-type \ --nodes 3 --nodes-min 1 --nodes-max 4 --managed=false \ --node-volume-type gp2 --subnet-ids subnet-id \ --node-ami-family AmazonLinux2023 ``` AWS 클라우드에 클러스터가 배포된 경우: + 배포하는 노드 그룹에서 인스턴스의 블록과 다른 CIDR 블록의 포드에 `IPv4` 주소를 할당할 수 있습니다. 자세한 내용은 [사용자 지정 네트워킹을 통해 대체 서브넷에 포드 배포](cni-custom-network.md) 섹션을 참조하세요. + 배포하는 노드 그룹에는 아웃바운드 인터넷 액세스 권한이 필요하지 않습니다. 자세한 내용은 [인터넷 액세스가 제한된 프라이빗 클러스터 배포](private-clusters.md) 섹션을 참조하세요. 사용 가능한 모든 옵션과 기본값의 전체 목록은 `eksctl` 설명서의 [AWS Outposts 지원](https://eksctl.io/usage/outposts/)을 참조하세요. + 노드가 클러스터에 참여하지 못하면 [Amazon EKS 클러스터 및 노드 문제 해결](troubleshooting.md)의 [노드가 클러스터 조인에 실패](troubleshooting.md#worker-node-fail)와 [AWS 전초 기지에서 로컬 Amazon EKS 클러스터 문제 해결](eks-outposts-troubleshooting.md)의 [클러스터에 노드를 조인할 수 없음](eks-outposts-troubleshooting.md#outposts-troubleshooting-unable-to-join-nodes-to-a-cluster)를 참조하세요. + 예제 출력은 다음과 같습니다. 노드가 생성되는 동안 여러 줄이 출력됩니다. 출력의 마지막 줄 중 하나는 다음 예제 줄과 유사합니다. ``` [✔] created 1 nodegroup(s) in cluster "my-cluster" ``` 1. (선택 사항) [샘플 애플리케이션](sample-deployment.md)을 배포하여 클러스터 및 Linux 노드를 테스트합니다. ## AWS Management Console **1단계: AWS Management Console을 사용하여 자체 관리형 Linux 노드 시작 ** 1. AWS CloudFormation 템플릿의 최신 버전 다운로드 ``` curl -O https://s3.us-west-2.amazonaws.com/amazon-eks/cloudformation/2025-11-24/amazon-eks-outpost-nodegroup.yaml ``` 1. [AWS CloudFormation 콘솔](https://console.aws.amazon.com/cloudformation/)을 엽니다. 1. **스택 생성**을 선택한 다음 **새 리소스 사용(표준)**을 선택합니다. 1. **템플릿 지정**에서 **템플릿 파일 업로드**를 선택한 다음 **파일 선택**을 선택합니다. 이전 단계에서 다운로드한 `amazon-eks-nodegroup.yaml` 파일을 선택한 후 **다음**을 선택합니다. 1. **스택 세부 정보 지정** 페이지에서 이에 따라 다음 파라미터를 입력한 후 **다음**을 선택합니다. + **스택 이름**: AWS CloudFormation 스택에 대한 스택 이름을 선택합니다. 예를 들어, *al-nodes*라고 할 수 있습니다. 이름에는 영숫자(대소문자 구분)와 하이픈만 사용할 수 있습니다. 영숫자로 시작해야 하며 100자 이하여야 합니다. 이름은 클러스터를 생성하는 AWS 리전과 AWS 계정 내에서 고유해야 합니다. + **ApiServerEndpoint**: EKS 콘솔 또는 DescribeCluster API를 통해 볼 수 있는 Kubernetes API Server 엔드포인트를 입력합니다. + **ClusterName**: 클러스터의 이름을 입력합니다. 이 이름이 클러스터 이름과 일치하지 않으면 노드가 클러스터에 조인할 수 없습니다. + **ClusterId**: EKS 서비스에서 클러스터에 할당한 ID를 입력합니다. DescribeCluster API를 통해 확인할 수 있습니다. 이 ID가 클러스터 ID와 일치하지 않으면 노드가 클러스터에 조인할 수 없습니다. + **CertificateAuthority**: Kubernetes 인증 기관의 base64로 인코딩된 문자열을 입력합니다. EKS 콘솔 또는 DescribeCluster API를 통해 확인할 수 있습니다. + **ServiceCidr**: Kubernetes 서비스 CIDR을 입력합니다. EKS 콘솔 또는 DescribeCluster API를 통해 확인할 수 있습니다. + **ClusterControlPlaneSecurityGroup**: [VPC](creating-a-vpc.md)를 생성할 때 생성한 AWS CloudFormation 출력에서 **SecurityGroups**값을 선택합니다. 다음 단계에서는 해당 그룹을 검색하는 한 가지 작업을 보여줍니다. 1. [Amazon EKS 콘솔](https://console.aws.amazon.com/eks/home#/clusters)을 엽니다. 1. 클러스터의 이름을 선택합니다. 1. **네트워킹** 탭을 선택합니다. 1. **ClusterControlPlaneSecurityGroup** 드롭다운 목록에서 선택할 때 **추가 보안 그룹** 값을 참조로 사용하세요. + **NodeGroupName**: 노드 그룹의 이름을 입력합니다. 이 이름은 나중에 노드에 대해 생성된 Auto Scaling 노드 그룹을 식별하는 데 사용할 수 있습니다. + **NodeAutoScalingGroupMinSize**: Auto Scaling 그룹이 축소할 수 있는 노드의 최소 노드 수를 입력합니다. + **NodeAutoScalingGroupDesiredCapacity**: 스택을 생성할 때 조정할 원하는 노드 수를 입력합니다. + **NodeAutoScalingGroupMaxSize**: Auto Scaling 그룹이 확장할 수 있는 노드의 최대 노드 수를 입력합니다. + **NodeInstanceType**: 노드에 대한 인스턴스 유형을 선택합니다. 클러스터가 AWS 클라우드에서 실행 중인 경우 자세한 내용을 알아보려면 [최적의 Amazon EC2 노드 인스턴스 유형 선택](choosing-instance-type.md) 부분을 참조하세요. 클러스터가 Outpost에서 실행 중인 경우 Outpost에서 사용할 수 있는 인스턴스 유형만 선택할 수 있습니다. + **NodeImageIdSSMParam**: 가변 Kubernetes 버전용 최신 Amazon EKS 최적화 AMI의 Amazon EC2 Systems Manager 파라미터로 미리 채워집니다. Amazon EKS에서 지원되는 다른 Kubernetes 마이너 버전을 사용하려면 *1.XX*를 다른 [지원되는 버전](https://docs.aws.amazon.com/eks/latest/userguide/kubernetes-versions.html)으로 바꿉니다. 클러스터와 동일한 Kubernetes 버전을 지정하는 것이 좋습니다. Amazon EKS 최적화 가속 AMI를 사용하려면 *NodeImageIdSSMParam* 값을 원하는 SSM 파라미터로 업데이트합니다. SSM에서 EKS AMI ID를 검색하는 방법은 [여기](https://docs.aws.amazon.com/eks/latest/userguide/retrieve-ami-id.html)를 참조하세요. **참고** Amazon EKS 노드 AMI는 Amazon Linux를 기반으로 합니다. 원하는 버전에 대한 탭을 선택하여 [Amazon Linux 보안 센터](https://alas.aws.amazon.com/)에서 Amazon Linux의 보안 또는 개인정보 보호 이벤트를 추적할 수 있습니다. 해당 RSS 피드를 구독할 수도 있습니다. 보안 및 프라이버시 이벤트에는 문제의 개요, 영향을 받는 패키지 및 인스턴스를 업데이트하여 문제를 해결하는 방법이 포함됩니다. + **NodeImageId**: (선택사항) Amazon EKS 최적화 AMI 대신 사용자 정의 AMI를 사용 중인 경우, 해당 AWS 리전에 노드 AMI ID를 입력합니다. 여기에서 값을 지정하면 **NodeImageIdSSMParam** 필드에 있는 모든 값이 재정의됩니다. + **NodeVolumeSize**: 노드에 대해 루트 볼륨 크기를 GiB 단위로 지정합니다. + **NodeVolumeType**: 노드의 루트 볼륨 유형을 지정합니다. + **KeyName**: 시작 이후 SSH를 사용하여 노드에 연결하는 데 사용할 수 있는 Amazon EC2 SSH 키 페어 이름을 입력합니다. Amazon EC2 키 페어가 아직 없는 경우 AWS Management Console에서 새로 생성할 수 있습니다. 자세한 내용을 알아보려면 *Amazon EC2 key pairs*의 [Amazon EC2 키 페어](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ec2-key-pairs.html)를 참조하세요. **참고** 여기에 키 페어를 입력하지 않으면 AWS CloudFormation 스택이 생성되지 않습니다. + **DisableIMDSv1**: 기본적으로 각 노드는 인스턴스 메타데이터 서비스 버전 1(IMDSv1) 및 IMDSv2를 지원합니다. IMDSv1을 사용 중지할 수 있습니다. 향후 노드 그룹의 노드와 포드가 IMDSv1을 사용하지 못하게 하려면 **DisableIMDSv1**을 **true**로 설정합니다. IMDS에 대한 자세한 내용은 [인스턴스 메타데이터 서비스 구성](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/configuring-instance-metadata-service.html)을 참조하세요. 노드의 IMDS 액세스 제한에 대한 자세한 내용은 [작업자 노드에 할당된 인스턴스 프로필에 대한 액세스 제한](https://aws.github.io/aws-eks-best-practices/security/docs/iam/#restrict-access-to-the-instance-profile-assigned-to-the-worker-node)을 참조하세요. + **VpcId**: 생성한 [VPC](creating-a-vpc.md)에 대한 ID를 입력합니다. VPC를 선택하기 전에 [VPC 요구 사항과 고려 사항](eks-outposts-vpc-subnet-requirements.md#outposts-vpc-requirements)을 검토하세요. + **서브넷**: 클러스터가 Outpost에 있는 경우 VPC에서 프라이빗 서브넷을 하나 이상 선택합니다. 서브넷을 선택하기 전에 [을 검토하세요](eks-outposts-vpc-subnet-requirements.md#outposts-subnet-requirements). 클러스터의 **Networking**에서 각 서브넷 링크를 열면 어떤 서브넷이 프라이빗인지 확인할 수 있습니다. 1. **스택 옵션 구성** 페이지에서 원하는 선택 항목을 선택한 후 **다음**을 선택합니다. 1. **AWS CloudFormation에서 IAM 리소스를 생성할 수 있음을 인정합니다**의 왼쪽에 있는 확인란을 선택한 다음 **스택 생성**을 선택합니다. 1. 스택이 생성된 후 콘솔에서 이를 선택하고 **출력**을 선택합니다. 1. 생성된 노드 그룹에 대해 **NodeInstanceRole**을 기록합니다. Amazon EKS 노드를 구성할 때 필요합니다. **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: username: system:node:{{EC2PrivateDNSName}} groups: - system:bootstrappers - system:nodes [...] ``` 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.yaml ``` 1. `aws-auth-cm.yaml` 파일에서 `rolearn`을 이전 절차에서 기록한 **NodeInstanceRole** 값으로 설정합니다. 이 작업은 텍스트 편집기를 사용하거나 *my-node-instance-role*을 대체하고 다음 명령을 실행하여 수행할 수 있습니다. ``` sed -i.bak -e 's||my-node-instance-role|' aws-auth-cm.yaml ``` 1. 구성을 적용합니다. 이 명령을 완료하는 데 몇 분이 걸릴 수 있습니다. ``` kubectl apply -f aws-auth-cm.yaml ``` 1. 노드의 상태를 확인하고 `Ready` 상태가 될 때까지 대기합니다. ``` kubectl get nodes --watch ``` `Ctrl`\$1`C`를 입력하여 쉘 프롬프트로 돌아갑니다. **참고** 권한 부여 또는 리소스 유형 오류가 표시되는 경우 문제 해결 주제의 [권한이 없거나 액세스가 거부됨(`kubectl`)](troubleshooting.md#unauthorized) 부분을 참조하세요. 노드가 클러스터에 참여하지 못하면 [Amazon EKS 클러스터 및 노드 문제 해결](troubleshooting.md)의 [노드가 클러스터 조인에 실패](troubleshooting.md#worker-node-fail)와 [AWS 전초 기지에서 로컬 Amazon EKS 클러스터 문제 해결](eks-outposts-troubleshooting.md)의 [클러스터에 노드를 조인할 수 없음](eks-outposts-troubleshooting.md#outposts-troubleshooting-unable-to-join-nodes-to-a-cluster)를 참조하세요. 1. Amazon EBS CSI 드라이버를 설치합니다. 자세한 내용을 알아보려면 GitHub에서 [설치](https://github.com/kubernetes-sigs/aws-ebs-csi-driver/blob/master/docs/install.md)를 참조하세요. **드라이버 권한 설정** 섹션에서 **IAM 인스턴스 프로필 사용** 옵션에 대한 지침을 따릅니다. `gp2` 스토리지 클래스를 사용해야 합니다. `gp3` 스토리지 클래스는 지원되지 않습니다. 클러스터에 `gp2` 스토리지 클래스를 생성하려면 다음 단계를 수행합니다. 1. 다음 명령을 실행해 `gp2-storage-class.yaml` 파일을 생성합니다. ``` cat >gp2-storage-class.yaml <