View a markdown version of this page

EC2 인스턴스 저장소로 구성된 AWS Outposts에서 Amazon EKS 로컬 클러스터의 인스턴스 유형 및 배치 선택 - Amazon EKS
컨트롤 플레인 아키텍처인스턴스 유형 선택컨트롤 플레인 및 etcd 배치용량 계획배치 문제 해결

이 페이지 개선에 도움 주기

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

EC2 인스턴스 저장소로 구성된 AWS Outposts에서 Amazon EKS 로컬 클러스터의 인스턴스 유형 및 배치 선택

이 주제에서는 EC2 인스턴스 저장소로 구성된 AWS Outpost에서 로컬 Amazon EKS 클러스터의 고가용성 요구 사항을 충족하기 위해 Kubernetes 컨트롤 플레인 인스턴스를 선택하고 배치를 구성하기 위한 지침을 제공합니다.

참고

Outpost가 EC2 인스턴스 저장소 대신 Amazon EBS로 구성된 경우 이 주제에 설명된 아키텍처는 Outpost에 사용할 수 없습니다. EBS로 구성된 Outpost는 기존 로컬 클러스터 구현을 계속 사용합니다. 자세한 내용은 용량 고려 사항에 따라 AWS Outposts의 Amazon EKS 클러스터에 대한 인스턴스 유형 및 배치 그룹 선택 섹션을 참조하세요.

업데이트된 로컬 클러스터 아키텍처를 사용하여 EBS 지원 Outpost에서 로컬 클러스터를 생성하려면 AWS 계정 팀에 문의하세요.

컨트롤 플레인 아키텍처

로컬 클러스터 Kubernetes 컨트롤 플레인은 Outpost의 EC2 인스턴스 6개에서 실행됩니다.

  • 컨트롤 플레인 인스턴스 3개 - Kubernetes API 서버, 스케줄러, 컨트롤러 관리자를 포함하여 Kubernetes 컨트롤 플레인 구성 요소를 호스팅합니다.

  • etcd 인스턴스 3개 - 외부 etcd 토폴로지에 Kubernetes 클러스터 상태를 저장합니다.

이러한 인스턴스는 Outpost의 AWS 관리형 서비스 계정에서 실행됩니다. 이러한 인스턴스는 AWS 계정 또는 Amazon EC2 콘솔에 EC2 인스턴스로 표시되지 않습니다. 컨트롤 플레인이 사용하는 용량은 AWS Outposts 콘솔에서 볼 수 있습니다.

컨트롤 플레인은 로드 시 수평적으로 스케일링되지 않습니다. 다른 컨트롤 플레인 인스턴스 크기가 필요한 경우 새 클러스터를 생성해야 합니다.

인스턴스 유형 선택

AWS Outposts의 Amazon EKS 로컬 클러스터의 업데이트된 아키텍처에서는 Kubernetes 컨트롤 플레인이 전용 etcd 토폴로지를 사용합니다. 즉 API 서버와 etcd가 별도의 인스턴스에서 실행됩니다. 클러스터를 생성할 때 API 서버에 사용할 controlPlaneInstanceType과 etcd에 사용할 etcdInstanceType 등 두 가지 인스턴스 유형을 지정합니다.

선택한 인스턴스 유형은 Outpost에서 사용할 수 있어야 합니다. 사용 가능한 인스턴스 패밀리는 Outpost 세대와 SKU에 따라 달라지며, 서로 다른 인스턴스 패밀리는 동일한 인스턴스 크기에서 서로 다른 vCPU 및 메모리 구성을 가질 수 있습니다.

API 서버controlPlaneInstanceType()

예상 워커 노드 vCPU Memory

1~20

2

8GiB

21~100

4

16GiB

101~250

8

32GiB

251~500

16

64GiB

etcd (etcdInstanceType)

예상 워커 노드 vCPU Memory

1~50

2

8GiB

51~250

4

16GiB

251~500

8

32GiB
중요

로컬 클러스터 수명 동안 controlPlaneInstanceType 인스턴스 3개와 etcdInstanceType 인스턴스 3개를 위한 용량이 Outpost에 있어야 합니다.

이러한 표를 엄격한 요구 사항이 아닌 지침으로 사용하세요. 클러스터 생성 후에는 controlPlaneInstanceType과 etcdInstanceType을 변경할 수 없으므로 예상되는 증가를 감당할 수 있는 인스턴스 패밀리와 크기를 선택하는 것이 좋습니다. 둘 중 하나라도 변경하려면 새 클러스터를 생성해야 합니다.

컨트롤 플레인 및 etcd 배치

고가용성을 위해 컨트롤 플레인과 etcd 인스턴스를 여러 하드웨어 장애 도메인에 분산하는 것이 좋습니다. outpostConfig의 controlPlanePlacement 및 etcdPlacement에서 spreadLevel 속성을 사용하여 이 분산을 제어할 수 있습니다. spreadLevel을 설정하면 Amazon EKS는 분산 전략을 사용하여 EC2 배치 그룹을 생성합니다. 배치 그룹을 미리 생성할 필요는 없습니다.

참고

controlPlanePlacement의 groupName 파라미터는 인스턴스 저장소 기반 EC2 인스턴스를 실행하는 Outpost에는 사용되지 않습니다. 이전에 로컬 클러스터와 함께 배치 그룹을 사용한 경우 이제 spreadLevel을 대신 사용합니다.

분산 수준

spreadLevel 속성은 다음 두 값을 허용합니다.

  • host - 컨트롤 플레인 인스턴스를 다양한 물리적 호스트에 분산합니다. 선택한 인스턴스 유형으로 구성된 호스트가 3개 이상 필요합니다.

  • rack - 컨트롤 플레인 인스턴스를 다양한 물리적 Outpost 랙에 분산합니다. 선택한 인스턴스 유형으로 구성된 호스트가 있는 랙이 3개 이상 필요합니다.

용량 계획

로컬 클러스터의 Outpost 용량을 계획할 때 다음 사항을 고려하세요.

  • 컨트롤 플레인 및 etcd 인스턴스: 클러스터당 인스턴스 6개(controlPlaneInstanceType 3개 및 etcdInstanceType 3개).

  • 워커 노드: 자체 관리형 노드 그룹의 EC2 인스턴스.

  • 가상화된 호스트: 컨트롤 플레인은 가상화된 호스트에서 실행되어야 합니다. Outpost에는 용량이 충분한 가상화된 호스트가 있어야 합니다.

배치 문제 해결

분산 수준을 지정한 후 클러스터가 장기간 CREATING 또는 UPDATING 상태로 유지되는 경우 분산 토폴로지를 충족하기에 충분한 선택한 인스턴스 유형의 호스트 또는 랙이 Outpost에 있는지 확인합니다.

로컬 클러스터 문제 해결에 대한 자세한 내용은 EC2 인스턴스 저장소로 구성된 AWS Outposts의 Amazon EKS 로컬 클러스터 문제 해결 섹션을 참조하세요.