[EKS] AWS EKS 소개 및 배포, Control Plane과 Data Plan 그리고 Cluster Endpoint Access

01. EKS 소개 및 클러스터 배포 방법

이번 시간에는 EKS를 소개하고, EKS를 어떻게 배포할 수 있는지 살펴본다. 이어서 EKS를 구성하는 주요 요소인 Master Node와 Worker Node를 정리하고, 마지막으로 EKS 클러스터의 Control Plane에 위치한 Kubernetes API Server의 엔드포인트 접근 방식과 통신 흐름을 알아본다.

01-1. Amazon EKS 특징

Amazon EKS는 컨트롤 플레인(Control Plane)과 데이터 플레인(Data Plane)을 제공해주는 완전 관리형 쿠버네티스(k8s) 서비스이다. 여기서 말하는 완전 관리형이란 말은, k8s에서 제공되는 마스터 노드(Master Node)의 관리를 사용자가 직접 하는 것이 아닌, AWS에서 유지 및 운영하는 것을 의미한다. 또한, 워커 노드의 경우는 선택에 따라 완전 관리형이 될 수 도 있고, 그렇지 않을 수도 있다.

1. 다수의 AWS AZ에 k8s Control Plane 실행 및 관리

EKS의 Control Plane은 AWS가 관리하는 전용 VPC 내 여러 가용 영역(AZ)에 분산 배치되어 운영된다. Control Plane은 API Server, Controller Manager, Scheduler, etcd로 구성되며, 이러한 다중 AZ 구성으로 고가용성과 안정적인 클러스터 운영을 보장한다.

2. EKS는 다양한 AWS 서비스와 통합 가능

EKS는 AWS의 다양한 서비스와 연계를 지원한다. 예를 들면 ECR을 통해 이미지 저장소를 활용할 수 있고, ELB를 활용하여 트래픽을 부하분산 처리 하는 것도 가능하다. 또한, IAM 연계를 통해 보안을 제어할 수 있으며, VPC를 통해 Control Plane과 노드를 격리할 수 있다고 하는데, 애초에 Control Plane은 AWS가 관리하는 VPC에, Data Plane은 사용자 VPC에 위치하기에 격리 되고 있는 그림이다.

3. Kubernetes 최신 버전 지원

EKS는 최신 k8s 버전을 사용하기에, k8s에서 제공해주는 최신 플러그인이나 도구를 자유롭게 사용할수 있다. 또한, k8s와 어느정도 호환이 되기 때문에, 기존 환경에서 EKS로 마이그레이션 하는 것도 손쉽게 가능하다고 한다.

01-2. EKS 클러스터 배포 방법 3가지

EKS를 배포하면 Control Plane과 Data Plane이 함께 구성이 된다. EKS의 배포 방식으로 총 3가지가 존재하는데, 1번째는 콘솔에서 EKS를 배포하는 것이고 2번째는 eksctl을 사용하는 것이며, 3번째는 IaC(CloudFormation, Terraform)을 활용하는 방법이 존재한다.

02. EKS Control Plane vs Data Plane

02-1. 마스터 노드(Control Plane)

EKS를 생성하면 EKS Control Plane을 배치하기 위한 AWS 관리형 VPC(Managed VPC)가 생성이 된다. 참고로 이 VPC는 사용자의 AWS 계정(account)가 아닌, AWS에서 관리하는 VPC에 Control Plane이 배치되는 구조다. 즉, 사용자는 Control Plane의 VPC와 네트워크 설정에 대한 모든 부분을 컨트롤 할 수 없다.

 

또한, 위 이미지와 같이 다수의 가용영역(AZ)에 걸쳐 자원이 배치된다. 각 가용영역(AZ)에는 Control Plane을 구성할 인스턴스가 생성이 되고, 해당 인스턴스들에 Control Plane의 컴포넌트들이 배치된다. etcd의 경우 중앙 DB 저장소 역할을 하는 특수한 컴포넌트로 다른 컴포넌트와 분리되어 별도의 인스턴스에 구성된다.

 

그리고 이렇게 구성된 여러 자원들은 Auto Scaling을 통해 안정적인 상태를 유지하게 설정되어 있다. 또한, 여러 가용영역(AZ)에 자원이 분산되어 있기에 NLB(Network Load Balancer)를 사용하여 트래픽을 효율적으로 분산한다. etcd는 Client‑Side Load Balancing을 사용하며, API Server가 etcd와 직접 통신하는 구조로 바뀌었다. (API Server → Client Side LB → etcd)

02-2. 워커 노드(Data Plane)

Data Plane은 Kubernetes 워커 노드가 배치되는 영역으로, 이곳에 kubelet, kube‑proxy, 컨테이너 런타임, Pod가 위치한다. 또한, Control Plane과 달리 Data Plane은 사용자 VPC에 배치되므로, 사용자가 직접 VPC와 네트워크를 제어할 수 있다. 위 이미지를 보면 AWS 관리형 VPC의 여러 가용 영역(AZ)에 Control Plane이 구성되어 있다. 워커 노드의 kubelet이 Control Plane의 API Server와 통신하려면 양쪽을 연결해야 하며, 이를 위해 EKS Owned ENI가 사용된다. 결론적으로, Control Plane과 Data Plane은 EKS Owned ENI를 통해 안정적으로 연결된다.

02-3. Data Plane 노드 구성 방법

EKS의 Data Plane에 노드를 구성하는 방식은 아래 3가지가 존재

1. 관리형 노드 그룹 (AWS 어느 정도 관리)
2. 자체 관리형 노드 (사용자가 전부 관리)
3. AWS Fargate (AWS 완전 관리)

관리형 노드 그룹 방식

1. 노드의 운영체제, 유지관리, 버전 관리를 AWS에서 일정 부분 지원
2. EKS에 최적화된 최신 AMI를 제공하고, 이 AMI 기준으로 사용자는 손쉽게 노드 구성 가능

자체 관리형 노드

1. 모든 것을 사용자가 직접 구성하고 운영
2. 사용자 정의 AMI 사용 가능하나, 보안 패치, 버전 업그레이드 등 사용자 몫

AWS Fargate

1. 사용자가 직접 관리 없이, 서버리스 환경에서 동작
2. 모든 노드(Control, Data Plane)AWS가 모두 관리

03. Amazon EKS Cluster Endpoint Access 방식

kubelet에서 EKS Owned ENI를 통해 API Server에 바로 요청을 할 수 있을 것 같지만, API Server는 다수의 가용영역(AZ)에 구동되고 있기 때문에, 특정 고정 IP를 지정해서 요청이 불가능하다. 그래서 kubelet에서 API Server로 통신하는 경우는 도메인 기반으로 통신을 해야 한다. 도메인 기반 통신을 통해 NLB를 거쳐 부하 분산이 자동으로 이루어진다. 만약 인터넷을 경유하고 싶지 않다면, 워커 노드를 프라이빗 엔드포인트로 구성하고, AWS 내부 프라이빗 호스팅 존을 구성한 후 도메인 질의를 하면 EKS owned ENI로 바로 연결되어 API Server와 내부 통신이 가능하다.

EKS는 클러스터 엔드포인트에 따라 접근하는 방법이 달라지기에, 이번에는 클러스터 엔드포인트에 대해 알아본다. k8s의 중심 역할을 하는 API Server에 접근하기 위해서는 클러스터 엔드포인트를 정의해야 한다. 그중에서 우선 퍼블릭 엔드포인트 방식에 대해 먼저 알아본다.

03-1. EKS 퍼블릭 엔드포인트 접근

엔드포인트를 퍼블릭으로 구성하면, 접근을 위한 도메인 주소가 퍼블릭 IP로 매핑된다. 그런데 이러한 퍼블릭 IP는 NLB의 퍼블릭 IP로 정의된다. 왜 그럴까? 앞서 설명했듯이 다수의 API 서버로 부하 분산하기 위해 NLB가 앞단에 구성되어 있기 때문이다. 즉, 트래픽이 NLB의 퍼블릭 IP로 인입되면 내부적으로 트래픽이 분산되는 구조다.

첫번째 요청 흐름은 API Server에서 Worker Node의 kubelet으로 요청을 보내는 흐름이다.

1. API Server → kubelet

API Server는 EKS Owned ENI를 통해 요청을 직접 전달한다. 엔드포인트가 퍼블릭으로 설정되어 있지만, 이러한 경우 AWS 내부 통신을 통해 연결되기 때문에, 퍼블릭 IP와는 별개의 흐름으로 요청이 시도된다.

2. kubelet → API Server

반대로 Worker Node의 kubelet이 API Server에 요청을 보낼때는 흐름이 달라진다. 이떄는 API Server의 주소가 퍼블릭 IP이기 때문에 IGW를 통해 외부로 나갔다가, 다시 관리형 VPC로 진입해 트래픽을 전달한다.

3. kubectl → API Server

kubectl을 요청하는 경우 도메인이 아직은 퍼블릭이기에, 퍼블릭 도메인 IP로 바로 접근한다.

03-2. EKS 퍼블릭 + 프라이빗 혼용 엔드포인트 접근

다음으로 EKS 클러스터 엔드포인트의 퍼블릭과 프라이빗이 혼용된 방식을 알아본다. 이 방식에서는 도메인 주소가 2가지 방식으로 매핑 되는데, 사용자가 접근하는 도메인 주소는 퍼블릭 NLB IP로 구성되고, 워커 노드에서 접근하는 도메인 주소는 프라이빗 호스팅 존을 구성해 EKS owned ENI로 매핑된다.

1. API Server → kubelet

API Server는 EKS Owned ENI를 통해 요청을 직접 전달한다. 엔드포인트가 퍼블릭으로 설정되어 있지만, 이러한 경우 AWS 내부 통신을 통해 연결되기 때문에, 퍼블릭 IP와는 별개의 흐름으로 요청이 시도된다.

2. kubelet → API Server

IGW를 통해 외부로 나가지 않고, AWS 내부의 프라이빗 호스팅 존을 통해 DNS 질의가 발생하고, 대상은 EKS owned ENI로 매핑되어 API Server로 전달된다.

3. kubectl → API Server

kubectl을 요청하는 경우 도메인이 아직은 퍼블릭이기에, 퍼블릭 도메인 IP로 바로 접근한다.

03-3. EKS 프라이빗 엔드포인트 접근

외부 인터넷 구간 노출없이 AWS 내부 통신 가능하기에 보안 우수

EKS 프라이빗 엔드포인트는, 접근에 사용되는 도메인 주소는 AWS 프라이빗 호스팅 존을 통해 관리된다. 이때, 요청 대상은 모두 EKS owned ENI로 향하게 되어 있으며, 사용자는 커스텀 VPC 안에서 kubectl을 실행해야 API Server에 접근이 가능하다.

1. API Server → kubelet

API Server는 EKS owned ENI를 통해 kubelet에 요청을 보낸다.

2. kubelet → API Server

kubelet에서 API 서버로 향하는 트래픽은 외부 인터넷 구간으로 나가는 것이 아니라 AWS 내부 프라이빗 호스팅 존에 DNS 질의 후 대상을 EKS owned ENI로 전달하고 API Server로 요청이 전달된다.

3. kubectl → API Server

사용자가 kubectl 요청하면, 프라이빗 호스팅을 통해 EKS owned ENI로 API Server에 연결된다.

99. 참고 자료

eksctl 구성 | K8s

[EKS] AWS EKS란? 특징과 노드 구성 방식 + 배포방식

Docker & Kubernetes Overview | CloudNet@와 함께하는 Amazon EKS 기본 강의

EKS의 Kubernetes 버전 수명 주기 이해 - Amazon EKS