**이 페이지 개선에 도움 주기**
이 사용자 가이드에 기여하려면 모든 페이지의 오른쪽 창에 있는 **GitHub에서 이 페이지 편집** 링크를 선택합니다.
# EC2 인스턴스 저장소로 구성된 AWS Outposts에 Amazon EKS 로컬 클러스터 배포
이 주제에서는 EC2 인스턴스 저장소로 구성된 AWS Outpost에 로컬 Amazon EKS 클러스터를 배포하는 지침을 제공합니다.
**참고**
Outpost가 EC2 인스턴스 저장소 대신 Amazon EBS로 구성된 경우 이 주제에 설명된 아키텍처는 Outpost에 사용할 수 없습니다. EBS로 구성된 Outpost는 기존 로컬 클러스터 구현을 계속 사용합니다. 자세한 내용은 [AWS Outposts에 Amazon EKS 클러스터 배포](eks-outposts-local-cluster-create.md) 섹션을 참조하세요.
업데이트된 로컬 클러스터 아키텍처를 사용하여 EBS 지원 Outpost에서 로컬 클러스터를 생성하려면 AWS 계정 팀에 문의하세요.
**중요**
로컬 클러스터는 Outpost 랙만 지원합니다. 단일 로컬 클러스터는 단일 논리적 Outpost를 구성하는 여러 물리적 Outpost 랙에서 실행할 수 있습니다. 단일 로컬 클러스터는 여러 논리적 Outposts에서 실행할 수 없습니다.
Kubernetes 컨트롤 플레인은 Outpost의 AWS 관리형 서비스 계정에서 실행됩니다. 컨트롤 플레인 인스턴스에 액세스하거나, Amazon EC2 콘솔에서 해당 인스턴스를 보거나, 해당 인스턴스에서 워크로드를 실행할 수 없습니다.
컨트롤 플레인은 [외부 etcd 토폴로지](https://kubernetes.io/docs/setup/production-environment/tools/kubeadm/ha-topology/#external-etcd-topology)의 EC2 인스턴스 6개(`etcd` 3개 \+ API 서버 3개)에서 실행됩니다. 용량 요구 사항은 [EC2 인스턴스 저장소로 구성된 AWS Outposts에서 Amazon EKS 로컬 클러스터의 인스턴스 유형 및 배치 선택](eks-outposts-instance-store-capacity-considerations.md) 섹션을 참조하세요.
[Kubernetes용 Amazon VPC CNI 플러그인](managing-vpc-cni.md), [kube-proxy](managing-kube-proxy.md), [CoreDNS](managing-coredns.md)는 로컬 클러스터에 자동으로 설치됩니다. 검증된 추가 기능의 전체 목록은 [EC2 인스턴스 저장소로 구성된 AWS Outposts의 로컬 클러스터를 위한 Amazon EKS 추가 기능](eks-outposts-instance-store-local-cluster-addons.md) 섹션을 참조하세요.
Amazon EKS는 주기적으로 `etcd`를 백업합니다. `etcd`에서 쿼럼이 손실되면 Amazon EKS는 최신 스냅샷에서 클러스터 상태를 복구합니다.
**사전 조건**
+ 컨트롤 플레인 인스턴스를 위한 충분한 가상화 용량을 갖춘 EC2 인스턴스 저장소로 구성된 기존 Outpost 랙. [EC2 인스턴스 저장소로 구성된 AWS Outposts에서 Amazon EKS 로컬 클러스터의 인스턴스 유형 및 배치 선택](eks-outposts-instance-store-capacity-considerations.md)을(를) 참조하세요.
+ [EC2 인스턴스 저장소로 구성된 AWS Outposts의 Amazon EKS 로컬 클러스터를 위한 VPC 및 서브넷 생성](eks-outposts-instance-store-vpc-subnet-requirements.md)에 설명된 요구 사항을 충족하는 VPC 및 서브넷.
+ 컴퓨터 또는 AWS CloudShell에 설치된 `kubectl` 명령줄 도구. 버전은 클러스터의 Kubernetes 버전과 동일하거나 최대 하나 이전 또는 이후의 마이너 버전일 수 있습니다. `kubectl`을 설치하거나 업그레이드하려면 [`kubectl` 및 `eksctl` 설정](install-kubectl.md) 부분을 참조하세요.
+ 디바이스 또는 AWS CloudShell에 설치 및 구성된 AWS CLI 버전 `2.35.3` 이후 버전. 현재 버전을 확인하려면 `aws --version`을 사용합니다. 설치하거나 업그레이드하려면 [AWS CLI 설치](https://docs.aws.amazon.com/cli/latest/userguide/getting-started-install.html)를 참조하세요.
+ 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) 섹션을 참조하세요.
+ AWS 관리형 정책 [AmazonEKSClusterPolicy](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/AmazonEKSClusterPolicy.html) 및 [AmazonEKSServicePolicy](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/AmazonEKSServicePolicy.html)가 연결된 클러스터의 IAM 역할. 이 역할의 신뢰 정책은 `eks.amazonaws.com` 서비스 보안 주체가 역할을 수임하도록 허용해야 합니다.
**참고**
Amazon EKS 클러스터를 생성할 때 클러스터를 생성하는 [IAM 보안 주체](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles.html#iam-term-principal)가 RBAC 권한 부여 표에 `system:masters` 권한이 있는 관리자로 영구적으로 추가됩니다. 이 보안 주체를 삭제하지 마세요.
## 로컬 클러스터 생성
AWS Management Console, AWS CLI, Amazon EKS API 또는 AWS CloudFormation을 사용하여 로컬 클러스터를 생성할 수 있습니다.
로컬 클러스터를 생성할 때 다음에 유의하세요.
+ Outpost가 호밍되는 가용 영역에서 서브넷을 전달해야 합니다. 여러 가용 영역에서 서브넷을 전달하면 요청이 실패합니다.
+ `endpointPrivateAccess`를 `true`으로 설정해야 합니다. 원하는 경우 `endpointPublicAccess`를 활성화할 수도 있습니다.
+ `outpostArns`, `controlPlaneInstanceType`, `etcdInstanceType`을 포함하여 `outpostConfig` 값을 전달해야 합니다. 원하는 경우 배치 구성을 지정할 수 있습니다. [EC2 인스턴스 저장소로 구성된 AWS Outposts에서 Amazon EKS 로컬 클러스터의 인스턴스 유형 및 배치 선택](eks-outposts-instance-store-capacity-considerations.md)을(를) 참조하세요.
### AWS CLI
```
aws eks create-cluster \
--name my-cluster \
--role-arn arn:aws:iam::111122223333:role/myEKSClusterRole \
--kubernetes-version 1.36 \
--resources-vpc-config subnetIds=subnet-ExampleID1,endpointPrivateAccess=true,endpointPublicAccess=true \
--logging '{"clusterLogging":[{"types":["api","audit","authenticator","controllerManager","scheduler"],"enabled":true}]}' \
--access-config authenticationMode=API_AND_CONFIG_MAP,bootstrapClusterCreatorAdminPermissions=true \
--outpost-config outpostArns=arn:aws:outposts:region-code:111122223333:outpost/op-uniqueid,controlPlaneInstanceType=m5.large,controlPlanePlacement={spreadLevel=host},etcdInstanceType=m5.large,etcdPlacement={spreadLevel=host}
```
### AWS Management Console
1. [Amazon EKS 콘솔](https://console.aws.amazon.com/eks/home#/clusters)을 엽니다.
1. **클러스터 생성**을 선택합니다.
1. **Kubernetes 컨트롤 플레인 위치**에서 ** AWS Outposts**를 선택합니다.
1. 다음을 구성합니다.
+ **이름** - 클러스터의 이름.
+ **Kubernetes 버전** - 사용할 버전.
+ **클러스터 서비스 역할** - [AmazonEKSClusterPolicy](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/AmazonEKSClusterPolicy.html) 및 [AmazonEKSServicePolicy](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/AmazonEKSServicePolicy.html)가 있는 IAM 역할.
+ **Outpost ID** - 배포할 논리적 Outpost.
+ **컨트롤 플레인 인스턴스 유형** - Kubernetes API 서버, 스케줄러, 컨트롤러 관리자의 인스턴스 유형.
+ **etcd 인스턴스 유형** - `etcd`의 인스턴스 유형.
+ **분산 수준** - 컨트롤 플레인 및 `etcd` 배치의 `host` 또는 `rack`.
1. 네트워킹 구성: VPC, 서브넷, 보안 그룹. 프라이빗 엔드포인트 액세스를 활성화합니다.
1. 관찰성 구성: 컨트롤 플레인 로깅.
1. 검토 및 생성.
### `CreateCluster` API
```
{
"name": "my-cluster",
"roleArn": "arn:aws:iam::111122223333:role/myEKSClusterRole",
"version": "1.36",
"resourcesVpcConfig": {
"subnetIds": ["subnet-ExampleID1"],
"endpointPublicAccess": true,
"endpointPrivateAccess": true
},
"logging": {
"clusterLogging": [{
"types": ["api", "audit", "authenticator", "controllerManager", "scheduler"],
"enabled": true
}]
},
"accessConfig": {
"authenticationMode": "API_AND_CONFIG_MAP",
"bootstrapClusterCreatorAdminPermissions": true
},
"outpostConfig": {
"outpostArns": ["arn:aws:outposts:region-code:111122223333:outpost/op-uniqueid"],
"controlPlaneInstanceType": "m5.large",
"controlPlanePlacement": {
"spreadLevel": "host"
},
"etcdInstanceType": "m5.large",
"etcdPlacement": {
"spreadLevel": "host"
}
}
}
```
EC2 인스턴스 저장소로 구성된 Outposts에서 로컬 클러스터를 생성할 때 `controlPlaneInstanceType` 및 `etcdInstanceType` 파라미터는 필수입니다. `controlPlanePlacement` 및 `etcdPlacement` 파라미터는 선택 사항입니다. 파라미터를 지정하지 않으면 배치 분산 전략이 적용되지 않습니다.
**참고**
`outpostConfig`는 생성 전용 속성입니다. 컨트롤 플레인 인스턴스 유형, `etcd` 인스턴스 유형, 배치 또는 Outpost를 변경하려면 새 클러스터를 생성해야 합니다.
## 클러스터에 연결
클러스터와 통신하도록 `kubectl`을 구성합니다.
```
aws eks update-kubeconfig --region region-code --name my-cluster
```
**참고**
AWS CLI 버전 `2.35.3` 이하를 사용하여 클러스터를 생성한 경우 `kubeconfig`를 업데이트하여 `exec` args에 (`--cluster-id` 대신) `--cluster-name`을 지정해야 합니다.
클러스터의 Kubernetes API 서버 엔드포인트는 Amazon Route 53에서 호스팅됩니다. 이 엔드포인트는 Amazon EKS가 서브넷에 생성하는 교차 계정 탄력적 네트워크 인터페이스(ENI)의 프라이빗 IP 주소로 확인됩니다. 이러한 ENI에는 클러스터 수명 주기 동안 변경되지 않는 고정 프라이빗 IP 주소가 있습니다.
클러스터를 생성하는 경우 Amazon EKS에서는 지정한 서브넷에 3개의 탄력적 네트워크 인터페이스를 생성합니다. 이러한 네트워크 인터페이스를 사용하면 클러스터와 VPC 간에 통신할 수 있습니다. 각 네트워크 인터페이스의 설명에는 `Amazon EKS {{cluster-name}} `이 포함되어 있습니다.
## 워커 노드 배포
[자체 관리형 노드 그룹](launch-workers.md)을 사용하여 로컬 클러스터에 워커 노드를 배포합니다.
1. 워커 노드 AWS CloudFormation 템플릿을 배포하거나 Outpost에 개별 EC2 인스턴스를 생성합니다.
```
curl -O https://s3.us-west-2.amazonaws.com/amazon-eks/cloudformation/2025-11-24/amazon-eks-outpost-nodegroup.yaml
```
1. 노드 인스턴스 역할에 클러스터 액세스 권한을 부여합니다. 노드의 IAM 역할을 위한 [액세스 항목](access-entries.md)을 생성합니다.
```
aws eks create-access-entry \
--cluster-name my-cluster \
--principal-arn arn:aws:iam::111122223333:role/myNodeRole \
--type EC2_LINUX
```
또는 인증에 `aws-auth` ConfigMap을 사용하는 경우 ConfigMap에 노드 인스턴스 역할을 추가합니다. [IAM 사용자 및 역할에 Kubernetes API에 대한 액세스 권한 부여](grant-k8s-access.md)을(를) 참조하세요.
1. 노드가 `Ready` 상태인지 확인합니다.
```
kubectl get nodes
```
## 내부 리소스
로컬 클러스터를 생성하면 Amazon EKS는 `kube-system` 네임스페이스에 `coredns`, `kube-proxy`, `aws-node`(VPC CNI) 추가 기능의 자체 관리형 버전을 자동으로 설치합니다. 원하는 경우 Amazon EKS 추가 기능 API를 통해 이러한 추가 기능의 관리형 버전을 설치할 수 있습니다. 자세한 내용은 [EC2 인스턴스 저장소로 구성된 AWS Outposts의 로컬 클러스터를 위한 Amazon EKS 추가 기능](eks-outposts-instance-store-local-cluster-addons.md) 섹션을 참조하세요.
Amazon EKS는 클러스터-VPC 통신을 위해 서브넷에 교차 계정 탄력적 네트워크 인터페이스(ENI)도 생성합니다. 이러한 네트워크 인터페이스를 삭제하지 마세요. 교차 계정 ENI가 삭제되거나 IP 주소가 변경되는 경우 고정 IP 기반 액세스를 사용하는 모든 노드와 모든 관리자를 수동으로 업데이트해야 합니다.