AWS Outposts, 로컬 EKS 클러스터 배포 기능 출시
Amazon Elastic Kubernetes Service(Amazon EKS)를 AWS Outposts에 로컬에서 사용가능합니다. 오늘부터 Amazon EKS 클러스터를 Outposts(Kubernetes 컨트롤 플레인 및 노드 모두)에 완전히 배포할 수 있습니다.
Amazon EKS는 AWS 및 온프레미스에서 Kubernetes를 쉽게 실행할 수 있도록 지원하는 관리형 Kubernetes 서비스입니다. AWS Outposts는 진정으로 일관된 하이브리드 경험을 위해 거의 모든 온프레미스 또는 엣지 로케이션에 AWS 인프라 및 서비스를 제공하는 완전 관리형 솔루션 제품군입니다.
Outposts에서 Amazon EKS용 로컬 클러스터의 이점을 완전히 이해하려면 우선 약간의 배경 지식을 공유해야 합니다.
일부 고객은 Outposts를 사용하여 Kubernetes 클러스터 노드 및 포드를 보유한 나머지 온프레미스 인프라와 인접한 지점에 배포합니다. 이를 통해 애플리케이션은 클라우드 기반 클러스터와 동일한 AWS API, CLI 또는 AWS Console을 사용하여 클러스터와 노드 수명 주기를 관리하는 동시에 온프레미스 서비스 및 데이터에 대한 액세스 지연 시간이 짧다는 이점을 누릴 수 있습니다.
지금까지 Outposts에 Kubernetes 애플리케이션을 배포할 때는 보통 AWS 클라우드에서 Amazon EKS 클러스터를 생성하는 것으로 시작했습니다. 그런 다음 Outposts 컴퓨터에 클러스터 노드를 배포했습니다. 이 하이브리드 클러스터 시나리오에서는 Kubernetes 컨트롤 플레인을 Outposts의 상위 리전에서 실행하며, 노드는 온프레미스 Outposts에서 실행합니다. Amazon EKS 서비스는 네트워크를 통해 Outposts 머신에서 실행 중인 노드와 통신합니다.
그러나 모든 것은 항상 실패한다는 점을 기억하십시오. 고객들은 이 시나리오에서 직면하는 주요 과제는 사이트 연결 끊김 관리라고 밝혔습니다. 특히 네트워크 연결 상태가 좋지 않거나 간헐적인 중단되는 영역에 전초 기지를 배치할 때 이를 제어할 수 없습니다. 온프레미스 시설의 인터넷 연결이 일시적으로 끊어지면 클라우드에서 실행하는 Amazon EKS 컨트롤 플레인은 노드 및 포드와 통신할 수 없습니다. 노드와 포드가 완벽하게 작동하고 온프레미스 로컬 네트워크에서 애플리케이션을 계속 제공하기는 하지만, Kubernetes는 이를 비정상으로 간주하여 연결 재설정 시 교체하도록 예약할 수 있습니다(Kubernetes 설명서의 포드 제거 참조). 이로 인해 연결 복원 시 애플리케이션 대기 시간이 발생할 수 있습니다.
이 블로그 게시물을 준비하면서 저희 Kubernetes 제품 매니저이자 전문가인 Chris와 이야기를 나누었습니다. 그는 컨트롤 플레인을 해당 노드에 다시 연결하는 방법을 구성할 수 있는 최소 7가지 별개의 옵션이 존재한다고 말했습니다. 이 모든 옵션을 마스터하지 않으면 재연결 시 시스템 상태를 예측할 수 없습니다.
이를 간소화하기 위해 당사는 전체 Amazon EKS 클러스터를 Outposts에서 호스팅할 수 있는 기능을 제공합니다. 이 구성에서는 Kubernetes 컨트롤 플레인과 사용자의 워커 노드 모두 Outposts 머신의 온프레미스에서 로컬로 실행됩니다. 이런 경우 서비스 링크 연결이 일시적으로 끊어져도 클러스터가 계속 작동합니다. 사용자는 클라우드와의 네트워크 연결이 끊어진 동안에도 애플리케이션 생성, 업데이트 및 확장과 같은 클러스터 작업을 수행할 수 있습니다.
실제 작동 모습 살펴보기
이 새로운 기능을 어떻게 사용할 수 있는지 살펴보겠습니다. 이 데모에서는 Outposts 랙의 온프레미스에서 실행 중인 Amazon Elastic Compute Cloud(Amazon EC2) 인스턴스에 Kubernetes 컨트롤 플레인을 배포하겠습니다.
이미 구성된 Outposts 랙을 사용하고 있습니다. Outposts 시작 방법을 알아보려면 AWS Outposts 시작하기 페이지의 단계를 참조하십시오.
이 데모는 두 부분으로 구성되어 있습니다. 먼저 클러스터를 생성합니다. 두 번째로 클러스터에 연결하여 노드를 생성합니다.
클러스터 생성
Amazon EKS 로컬 클러스터를 Outposts에 배포하기 전에 IAM 클러스터 역할을 생성하고 AmazonEKSLocalOutpostClusterPolicy 관리형 정책을 연결했는지 확인합니다. 이 IAM 클러스터 역할은 클러스터 생성에 사용됩니다.
그런 다음 Amazon EKS 대시보드로 전환하고 클러스터 추가를 선택한 다음 생성을 선택합니다.
다음 페이지에서 Kubernetes 컨트롤 플레인의 위치를 선택했습니다. 바로 AWS 클라우드 또는 AWS Outposts입니다. AWS Outposts를 선택하고 Outposts ID를 지정합니다.
Outposts의 Kubernetes 컨트롤 플레인은 고가용성을 위해 3개의 EC2 인스턴스에 배포됩니다. 따라서 세 개의 복제본이 보입니다. 그런 다음 워크로드에 필요한 워커 노드 수에 따라 인스턴스 유형을 선택합니다. 예를 들어 0~20개의 워커 노드를 처리하려면 m5d.large EC2 인스턴스를 사용하는 것이 좋습니다.
동일한 페이지에서 Kubernetes 클러스터의 구성 값 (예: 이름, Kubernetes 버전 및 이전에 생성한 클러스터 서비스 역할)을 지정합니다.
다음 페이지에서 네트워킹 옵션을 구성합니다. Outposts는 AWS 리전의 확장이므로 Outposts에서 사용하는 VPC 및 서브넷을 사용하여 Kubernetes 컨트롤 플레인과 워커 노드 간의 통신을 활성화해야 합니다. 보안 그룹의 경우 Amazon EKS는 클러스터와 VPC 간의 통신을 지원하는 로컬 클러스터용 보안 그룹을 생성합니다. 애플리케이션 요구 사항에 따라 추가적인 보안 그룹을 정의할 수도 있습니다.
Outposts 내에서 Kubernetes 컨트롤 플레인을 실행하므로 클러스터 엔드포인트 액세스는 비공개로만 액세스할 수 있습니다. 즉, 동일한 VPC에 배포되었거나, Direct VPC 라우팅을 사용하는 Outposts 로컬 게이트웨이를 통해 로컬 네트워크 전반에 배포된 머신을 통해서만 Kubernetes 클러스터에 액세스할 수 있습니다.
다음 페이지에서는 로깅을 정의합니다. 로깅은 기본적으로 비활성화되어 있으며 필요에 따라 활성화할 수 있습니다. 로깅에 대한 자세한 내용은 Amazon EKS 컨트롤 플레인 로깅 설명서를 참조하십시오.
마지막 화면에서 모든 구성 옵션을 검토할 수 있습니다. 구성에 만족하면 생성을 선택하여 클러스터를 생성합니다.
클러스터 생성에는 몇 분 정도 소요됩니다. 클러스터 생성 상태를 확인하기 위해 다음 명령과 함께 콘솔이나 터미널을 사용할 수 있습니다.
$ aws eks describe-cluster
--region <REGION_CODE>
--name <CLUSTER_NAME>
--query "cluster.status"상태 섹션은 클러스터가 생성 및 활성화되는 시기를 알려줍니다.
AWS Management Console을 사용하는 방법 외에 AWS CLI를 사용하여 로컬 클러스터를 생성할 수도 있습니다. 다음은 AWS CLI를 사용하여 로컬 클러스터를 생성하는 명령 스니펫입니다.
$ aws eks create-cluster
--region <REGION_CODE>
--name <CLUSTER_NAME>
--resources-vpc-config subnetIds=<SUBNET_ID>
--role-arn <ARN_CLUSTER_ROLE>
--outpost-config controlPlaneInstanceType=<INSTANCE_TYPE>
--outpostArns=<ARN_OUTPOST>콘솔에 연결
로컬 클러스터의 엔드포인트 액세스는 비공개이므로 Direct VPC 라우팅을 사용하는 로컬 게이트웨이 또는 동일한 VPC에 있는 시스템에서 액세스할 수 있습니다. Outposts에서 로컬 게이트웨이를 사용하는 방법을 알아보려면 로컬 게이트웨이 작업 페이지의 정보를 참조하십시오. 이 데모에서는 EC2 인스턴스를 Bastion 호스트로 사용하고 kubectl 명령을 사용하여 Kubernetes 클러스터를 관리합니다.
가장 먼저 할 일은 보안 그룹을 편집하여 Bastion 호스트에서 트래픽 액세스를 여는 것입니다. Kubernetes 클러스터의 세부 정보 페이지로 이동하여 네트워킹 탭을 선택합니다. 그런 다음 클러스터 보안 그룹에서 링크를 선택합니다.
그런 다음 인바운드 규칙을 추가하고 IP 주소를 지정하여 Bastion 호스트에 대한 액세스를 제공합니다.
액세스를 허용하고 나면 다음 명령을 실행하여 Bastion 호스트에서 kubeconfig를 생성합니다.
$ aws eks update-kubeconfig --region <REGION_CODE> --name <CLUSTER_NAME>마지막으로, 평소처럼 kubectl을 사용하여 Kubernetes API 서버와 상호 작용합니다.
$ kubectl get nodes -o wide
NAME STATUS ROLES AGE VERSION INTERNAL-IP EXTERNAL-IP OS-IMAGE KERNEL-VERSION CONTAINER-RUNTIME
ip-10-X-Y-Z.us-west-2.compute.internal NotReady control-plane,master 10h v1.21.13 10.X.Y.Z <none> Bottlerocket OS 1.8.0 (aws-k8s-1.21) 5.10.118 containerd://1.6.6+bottlerocket
ip-10-X-Y-Z.us-west-2.compute.internal NotReady control-plane,master 10h v1.21.13 10.X.Y.Z <none> Bottlerocket OS 1.8.0 (aws-k8s-1.21) 5.10.118 containerd://1.6.6+bottlerocket
ip-10-X-Y-Z.us-west-2.compute.internal NotReady control-plane,master 9h v1.21.13 10.X.Y.Z <none> Bottlerocket OS 1.8.0 (aws-k8s-1.21) 5.10.118 containerd://1.6.6+bottlerocketAWS Outposts에서 실행 중인 Kubernetes 로컬 클러스터는 3개의 EC2 인스턴스에서 실행됩니다. 위의 출력에서 워커 노드 3개의 상태가 NotReady임을 확인할 수 있습니다. 왜냐면 이것이 컨트롤 플레인에서만 사용되며 포드 일정을 수립할 때는 사용할 수 없기 때문입니다.
이 단계부터 Amazon EKS 로컬 클러스터를 사용하여 자체 관리형 노드 그룹을 배포할 수 있습니다.
요금 및 가용성
Amazon EKS 로컬 클러스터에는 기존 EKS 클러스터와 동일한 요금이 부과됩니다. 시간당 0.10USD부터 시작합니다. Kubernetes 컨트롤 플레인과 노드를 아웃포스트에 배포하는 데 필요한 EC2 인스턴스는 Outposts 요금에 포함되어 있습니다. 평소처럼 세부 정보는 요금 페이지에서 확인할 수 있습니다.
Amazon EKS 로컬 클러스터는 Outposts를 사용할 수 있는 모든 AWS 리전에서 사용할 수 있습니다.
오늘 바로 첫 EKS 로컬 클러스터를 구축하고 생성하세요!
— seb과 Donnie.
Source: AWS Outposts, 로컬 EKS 클러스터 배포 기능 출시
