[AWS] Amazon EKS란? 쉽게 정리 (Elastic Kubernetes Service)

◇  공부 기록용으로 작성하였으니 틀린점, 피드백 주시면 감사하겠습니다 ◇

 

EKS

 

Amazon EKS (Elastic Kubernetes Service)

Amazon EKS는 AWS에서 제공하는 Kubernetes 관리형 서비스이다.

 

Kubernetes에 관한 설명 → https://jibinary.tistory.com/82

[Kubernetes] 쿠버네티스란? 기본 특징 쉽게 정리 (파드, 클러스터, 노드)

 

Kubernetes는 오픈소스 컨테이너 오케스트레이션 플랫폼이다.

 

[ECS와의 유사점]

Amazon ECS와 마찬가지로 컨테이너의 실행과 관리를 수행할 수 있다.

→ 실행 환경으로는 EC2 or Fargate를 선택할 수 있으며, ECR의 컨테이너 이미지를 사용하는 것도 가능하다.

 

[EKS와 ECS 차이점]

ECS가 AWS만의 컨테이너 오케스트레이션 서비스인 반면, EKS는 오픈소스 Kubernetes를 AWS 상에서 운영하기 위한 서비스이다.

 

Amazon EKS를 사용하면, Kubernetes 자체의 설정 및 운영의 복잡성을 줄일 수 있다.

또한, 이미 Kubernetes를 사용하고 있는 사용자라면 기존의 도구나 지식을 그대로 활용할 수 있다.

 

 

 

EKS의 주요 요소

EKS의 주요 요소에는 "클러스터(Cluster)", "노드(Node)", "포드(Pod)"가 있다.

 

1. 클러스터 (Cluster)

하나 이상의 노드를 포함하는 논리 그룹이다.

클러스터 내부는 "컨트롤 플레인"과 "데이터 플레인" 두 가지로 나뉜다.

 

- 컨트롤 플레인(Control Plane): 클러스터의 전반적인 관리 및 제어, 노드 관리를 수행한다.

- 데이터 플레인(Data Plane): 노드가 배치되는 영역입니다.

 

 

2. 노드 (Node)

컨테이너의 실행 환경이다. EC2 인스턴스 또는 AWS Fargate를 선택할 수 있다.

작업자 노드(Worker Node)라고도 불린다.

 

 

3. 포드 (Pod)

EKS에서 관리되는 컨테이너의 실행 단위로, 앞서 설명한 노드 위에서 포드가 실행된다.

포드는 하나 이상의 관련된 컨테이너를 효율적으로 실행 및 관리하기 위한 구조를 제공한다.

 

 

 

 

컨트롤 플레인에 대한 접근 설정

EKS에서는 컨트롤 플레인 내의 Kubernetes API 서버가 데이터 플레인 내의 노드나 관리 도구(kubectl)로부터 통신을 받아들여, 클러스터 전체의 관리와 제어를 수행한다.

 

이 API 서버와의 통신은 EKS 클러스터 구성 시 자동으로 생성되는 클러스터 엔드포인트를 통해 이루어진다.

이 엔드포인트는 기본적으로 인터넷에서 접근할 수 있는 상태이다.

 

컨트롤 플레인과의 통신을 VPC 내의 사설 통신으로 제한하고, 인터넷을 통한 통신(퍼블릭 액세스)을 제한함으로써 보안을 강화할 수 있다.

EKS 관리 콘솔에서는 아래의 3가지 설정 중에서 선택할 수 있으며, 변경도 수시로 가능하다.

1. 퍼블릭(기본값): 엔드포인트에 VPC 외부(인터넷 경유)에서 접근 가능하며, 노드로부터의 통신도 VPC 외부를 통과한다
2. 퍼블릭 및 프라이빗: 엔드포인트에 VPC 외부(인터넷 경유)에서 접근 가능하며, 노드로부터의 통신은 VPC 내의 private 접근으로 이루어진다.
3. 프라이빗: 엔드포인트에는 private 접근만 허용되며, 노드로부터의 통신도 VPC 내의 사설 접근으로 이루어집니다.

👩‍🏫 프라이빗만으로 설정된 환경에서 노드가 컨트롤 플레인에 사설 네트워크를 통해 통신하려면, AWS PrivateLink(인터페이스 유형의 VPC 엔드포인트)가 필요하다

 

 

 

EKS에서의 Auto Scaling

EKS에는 실행 중인 애플리케이션의 부하 상황에 따라 리소스(포드나 노드)를 자동으로 스케일링하는 기능이 있다.

애플리케이션에 대한 요청이 집중되어 부하가 증가한 경우에는 스케일 아웃(리소스 증가)하고, 부하가 낮아진 경우에는 스케일 인(리소스 감소)함으로써 성능 유지와 비용 최적화를 실현할 수 있다.

 

EKS의 스케일링 기능

EKS에서 스케일 아웃/인을 실현하기 위해서는 다음 기능들을 사용한다.

1. Horizontal Pod Autoscaler (HPA) + "Metrics Server" : 포드 수 증감

CPU 사용률이나 메모리 사용량과 같은 메트릭스를 기반으로 포드(Pod) 수를 자동으로 증감시키는 수평적 스케일링 기능이다.

HPA를 작동시키기 위해서는 이러한 메트릭스 데이터를 수집하기 위한 별도의 "Metrics Server"라는 컴포넌트를 도입해야 한다.

 

2.Cluster Autoscaler: 노드 수 증감

노드 수를 자동으로 증감시키는 스케일링 기능이다.

HPA에 의해 포드의 스케일 아웃이 발생했을 때, 추가되는 포드를 실행할 리소스가 기존 노드에 부족하면, 추가 포드는 대기 상태(Pending)로 남게 된다.

이와 같은 경우에, Cluster Autoscaler는 새로운 포드가 필요로 하는 리소스에 따라 새로운 노드를 추가하고, 반대로 불필요한 노드가 있다면 그 노드를 종료한다.

 

 

 

 

---

🤔 문제

한 회사가 Amazon EKS 상의 컨테이너 애플리케이션으로 고객을 위한 정보 검색 서비스를 공개하고 있습니다. 최근, 이 서비스가 고부하 시에 응답 속도가 저하되는 것이 확인되었습니다. 이 회사의 운영 담당자는 부하에 따라 자동으로 리소스가 스케일 인, 스케일 아웃되는 방식을 요구하고 있습니다. 운영상의 오버헤드를 최소화하면서 이러한 요구를 충족시킬 수 있는 솔루션은 무엇입니까?

1. Horizontal Pod Autoscaler를 사용하여, 지정된 메트릭스의 임계값에 따라 포드 수를 자동으로 증감시키고, Cluster Autoscaler를 사용하여 노드 수를 자동으로 증감시킨다.
2. Amazon CloudFront를 사용하여, 애플리케이션으로의 트래픽을 분산시킴으로써 EKS 클러스터로 가는 부하를 경감한다.
3. EKS 포드 수를 증감시키는 AWS Lambda 함수를 작성하고, Amazon EventBridge를 사용하여 일정에 따라 실행한다.
4. EKS 클러스터 내의 노드를 수동으로 스케일링하기 위한 스크립트를 작성하고, AWS Lambda를 사용하여 정기적으로 실행한다.

정답

정답. 1번