AWS Outposts에서 Amazon EKS를 온프레미스에 배포하기
AWS Outposts에서 Amazon EKS를 온프레미스에 배포하기
Amazon EKS를 사용해 AWS Outposts에서 온프레미스 Kubernetes 애플리케이션을 실행할 수 있어요. Amazon EKS를 Outposts에 배포하는 방법은 다음과 같습니다.
- 확장 클러스터(Extended clusters) — Kubernetes 제어 플레인을 AWS 리전에서 실행하고 노드는 Outpost에서 실행합니다.
- 로컬 클러스터(Local clusters) — Kubernetes 제어 플레인과 노드를 모두 Outpost에서 실행합니다.
두 배포 옵션 모두 Kubernetes 제어 플레인은 AWS가 완전 관리합니다. 클라우드에서 사용하는 것과 동일한 Amazon EKS API, 도구, 콘솔을 사용해 Amazon EKS를 Outposts에 생성하고 실행할 수 있어요.
출처: 문서
본문
각 배포 옵션을 사용해야 하는 경우
로컬 클러스터와 확장 클러스터는 모두 범용 배포 옵션으로 다양한 애플리케이션에 사용할 수 있어요.
확장 클러스터를 사용하면 Kubernetes 제어 플레인이 상위 AWS 리전에서 실행되므로 Outpost의 용량을 절약할 수 있어요. 이 옵션은 Outpost에서 AWS 리전까지 안정적인 네트워크 연결이 있을 때 적합합니다. 애플리케이션을 AWS 리전과의 네트워크 단절에도 정적으로 안정적으로 동작하도록 설계하는 것이 좋습니다. Kubernetes가 제어 플레인과 노드 간의 네트워크 단절을 처리하는 방식으로 인해 애플리케이션 가동 중단이 발생할 수 있어요. Kubernetes의 동작에 대한 자세한 내용은 Kubernetes 설명서의 스케줄링, 선점(preemption), 축출(eviction)을 참고하세요.
로컬 클러스터를 사용하면 전체 Amazon EKS 클러스터를 Outposts에서 로컬로 실행할 수 있어요. 이 옵션은 클라우드와의 일시적인 네트워크 단절로 인해 발생할 수 있는 애플리케이션 가동 중단의 위험을 완화합니다. 이러한 네트워크 단절은 광케이블 절단이나 기상 이벤트로 인해 발생할 수 있어요. 전체 Amazon EKS 클러스터가 Outposts에서 로컬로 실행되므로 애플리케이션은 계속 사용 가능합니다. 클라우드와의 네트워크 단절 중에도 클러스터 작업을 수행할 수 있어요. 네트워크 단절 중에도 Kubernetes 운영을 계속해야 하거나 데이터 상주(data residency) 요구 사항으로 인해 필요하다면 로컬 클러스터를 선택하세요.
두 가지 로컬 클러스터 구현
Amazon EKS는 Outposts 랙에서 두 가지 로컬 클러스터 구현을 지원합니다. Outpost는 그 위에서 실행되는 EC2 인스턴스의 루트 볼륨 유형으로 Amazon EBS 또는 Amazon EC2 인스턴스 스토어를 사용하도록 구성됩니다. 로컬 클러스터 제어 플레인에 Amazon EKS가 사용하는 구현은 이 구성에 따라 달라져요.
-
Amazon EBS로 구성된 AWS Outposts. Kubernetes 제어 플레인은 Amazon EBS가 지원하는 3개의 Amazon EC2 인스턴스에
etcd를 스택(stacked)으로 쌓아 AWS 계정의 Outpost에서 실행됩니다. 자세한 내용은 고가용성을 위한 AWS Outposts 로컬 Amazon EKS 클러스터 생성을 참고하세요. -
EC2 인스턴스 스토어로 구성된 AWS Outposts. Amazon EKS는 업데이트된 로컬 클러스터 아키텍처를 배포합니다. Kubernetes 제어 플레인은 Outpost의 AWS 관리형 서비스 계정에서 6개의 Amazon EC2 인스턴스(3개는
etcd전용, 3개는 기타 제어 플레인 구성 요소)에서 실행됩니다. 이 구현은 클라우드의 Amazon EKS와 더 큰 동등성을 가지며, Amazon EKS Kubernetes 버전 수명 주기를 따르고, Amazon EKS 애드온과 Bottlerocket 기반 워커 노드(AL2023 외에도) 같은 추가 기능을 지원합니다. AWS Outposts를 사용할 수 있는 모든 표준 AWS 리전에서 사용할 수 있어요. 자세한 내용은 EC2 인스턴스 스토어로 구성된 AWS Outposts의 로컬 Amazon EKS 클러스터 개요를 참고하세요.
각 구현에서 사용할 수 있는 기능은 다음 표에 요약되어 있습니다.
배포 옵션 비교
다음 표는 확장 클러스터와 두 가지 로컬 클러스터 구현의 차이점을 비교합니다.
| 기능 | 확장 클러스터 | EBS가 있는 Outposts의 로컬 클러스터 | EC2 인스턴스 스토어가 있는 Outposts의 로컬 클러스터 |
|---|---|---|---|
| Kubernetes 제어 플레인 위치 | AWS 리전 | Outpost | Outpost |
| Kubernetes 제어 플레인 계정 | AWS 계정 | 사용자의 AWS 계정 | AWS 관리형 계정 |
| Kubernetes 제어 플레인 토폴로지 | 클라우드 관리형 | Amazon EC2 인스턴스 3개, stacked etcd |
Amazon EC2 인스턴스 6개(etcd 3개 + API 서버 3개) |
| 제어 플레인 스토리지 | 클라우드 관리형 | Amazon EBS | Amazon EC2 인스턴스 스토어 |
| 리전별 가용성 | 서비스 엔드포인트 참조 | US East (Ohio), US East (N. Virginia), US West (N. California), US West (Oregon), Asia Pacific (Seoul), Asia Pacific (Singapore), Asia Pacific (Sydney), Asia Pacific (Tokyo), Canada (Central), Europe (Frankfurt), Europe (Ireland), Europe (London), Middle East (Bahrain), South America (São Paulo) | AWS Outposts를 사용할 수 있는 모든 상용 AWS 리전 |
| Kubernetes 마이너 버전 | 지원되는 Amazon EKS 버전 | AWS Outposts용 Kubernetes 및 Amazon EKS 플랫폼 버전 참조 | 지원되는 Amazon EKS 버전 |
| 플랫폼 버전 | Amazon EKS 플랫폼 버전 참조 | AWS Outposts용 Kubernetes 및 Amazon EKS 플랫폼 버전 참조 | Amazon EKS 플랫폼 버전 참조 |
| Outpost 폼 팩터 | 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 |
AWS Management Console, AWS CLI, Amazon EKS API, AWS CloudFormation |
| 관리형 정책 | AmazonEKSClusterPolicy 및 AWS 관리형 정책: AmazonEKSServiceRolePolicy |
AmazonEKSLocalOutpostClusterPolicy 및 AWS 관리형 정책: AmazonEKSLocalOutpostServiceRolePolicy |
AmazonEKSClusterPolicy 및 AWS 관리형 정책: AmazonEKSServiceRolePolicy |
| 클러스터 VPC 및 서브넷 | VPC 및 서브넷용 Amazon EKS 네트워킹 요구 사항 참조 | AWS Outposts의 Amazon EKS 클러스터용 VPC 및 서브넷 생성 참조 | EC2 인스턴스 스토어로 구성된 AWS Outposts의 로컬 Amazon EKS 클러스터용 VPC 및 서브넷 생성 참조 |
| 클러스터 엔드포인트 액세스 | 공개 또는 프라이빗 또는 둘 다 | 프라이빗만 | 프라이빗 또는 공개 및 프라이빗 |
| Kubernetes API 서버 인증 | AWS Identity and Access Management(IAM), OIDC, 액세스 항목 | IAM 및 x.509 인증서 |
IAM, OIDC, 액세스 항목, aws-auth ConfigMap, x.509 인증서(네트워크 단절 시) |
| 노드 유형 | 자체 관리형만 | 자체 관리형만 | 자체 관리형만 |
| 노드 컴퓨팅 유형 | Amazon EC2 온디맨드 | Amazon EC2 온디맨드 | Amazon EC2 온디맨드 |
| 노드 스토리지 유형 | Amazon EBS gp2 및 로컬 NVMe SSD |
Amazon EBS gp2 및 로컬 NVMe SSD |
로컬 NVMe SSD |
| Amazon EKS 최적화 AMI | Amazon Linux, Windows, Bottlerocket | Amazon Linux | Amazon Linux 및 Bottlerocket |
| IP 버전 | IPv4만 |
IPv4만 |
IPv4만 |
| 애드온 | Amazon EKS 애드온 또는 자체 관리형 애드온 | 자체 관리형 애드온 | Amazon EKS 애드온(검증된 목록) 또는 자체 관리형 애드온 |
| 기본 컨테이너 네트워크 인터페이스 | Kubernetes용 Amazon VPC CNI 플러그인 | Kubernetes용 Amazon VPC CNI 플러그인 | Kubernetes용 Amazon VPC CNI 플러그인 |
| Kubernetes 제어 플레인 로그 | Amazon CloudWatch Logs | Amazon CloudWatch Logs | Amazon CloudWatch Logs |
etcd 백업 |
클라우드 관리형 | 고객 관리형(etcdctl 또는 Amazon EBS 볼륨 백업) |
Amazon EKS가 관리 |
| 로드 밸런싱 | AWS Load Balancer Controller를 사용해 Application Load Balancer만 프로비저닝(Network Load Balancer 없음) | AWS Load Balancer Controller를 사용해 Application Load Balancer만 프로비저닝(Network Load Balancer 없음) | AWS Load Balancer Controller를 사용해 Application Load Balancer만 프로비저닝(Network Load Balancer 없음) |
| 시크릿 봉투 암호화 | 지원됨, 기존 클러스터에서 KMS로 Kubernetes 시크릿 암호화 참조 | 지원되지 않음 | 지원되지 않음 |
| 서비스 계정용 IAM 역할(IRSA) | 지원됨, 서비스 계정용 IAM 역할 참조 | 지원되지 않음 | 지원됨(AWS 리전 연결 필요, 네트워크 단절 중에는 사용 불가) |
| EKS Pod Identity | 지원됨, EKS Pod Identity가 Pod에 AWS 서비스 액세스 권한을 부여하는 방법 참조 | 지원되지 않음 | 지원됨(AWS 리전 연결 필요, 네트워크 단절 중에는 사용 불가) |
| 문제 해결 | Amazon EKS 클러스터 및 노드 문제 해결 참조 | AWS Outposts의 로컬 Amazon EKS 클러스터 문제 해결 참조 | EC2 인스턴스 스토어로 구성된 AWS Outposts의 로컬 Amazon EKS 클러스터 문제 해결 참조 |
중요: RAM 공유 Outpost에 로컬 클러스터를 생성하면 클러스터의 제어 플레인이 Outpost 소유자의 물리적 액세스 아래에 놓이게 됩니다.
EC2 인스턴스 스토어 Outposts에서 IRSA와 EKS Pod Identity는 AWS 리전의 AWS STS에 의존합니다. 네트워크 단절 중에는 IRSA 또는 Pod Identity를 사용하는 워크로드가 새 자격 증명을 얻을 수 없어요. 자세한 내용은 네트워크 단절을 위한 EC2 인스턴스 스토어로 구성된 AWS Outposts 로컬 Amazon EKS 클러스터 준비를 참고하세요.