[AEWS3기] 1주차 - Amazon EKS 설치 및 기본 사용 (2)

* AWS에서 제공하는 Kubernetes 서비스 ? 

 

Amazon Elastic Kubernetes Servics는 AWS에서 제공하는 Kubernets 서비스로 컨트롤 플레인 또는 노드를 관리형 서비스로 제공받을 수 있습니다.

  - 여러 가용 영역에서 kubernetes 컨트롤 플레인 인스턴스 실행 가능, 고가용성 보장

  - 비정상 컨트롤 플레인 인스턴스를 감지하고 자동으로 교체 및 버전 업그레이드 제공

  - AWS 서비스와 연동 가능 (ECR, ELB, IAM, VPC)

  - kubernetes 커뮤니티에서 사용되는 플러그인과 툴과 호환 가능 

 

* AWS EKS 아키텍처

AWS EKS 클러스터에는 두 가지 기본 구성 요소가 있습니다.

1) Amazon EKS 제어 영역 > Control Plane을 AWS가 관리하는 AWS Managed VPC

2) 제어 영역에 등록된 Amzon EKS 노드 > Data Plane을 사용자가 관리하는 Customer VPC 

 

Amazon EKS 컨트롤 플레인에는 etcd, Kubernetes API 서버와 같은 Kubernetes 소프트웨어를 실행하는 컨트롤 플레인 노드가 포함되어 있습니다. 컨트롤 플레인은 AWS에서 관리하는 영역에서 실행되며, Kubernetes API는 클러스터와 연결된 Amazon EKS 엔드포인트를 통해 노출됩니다. 

 

 

[Control Plane]

AWS에서 관리하는 영역 > 3개의 가용 영역, API NLB, ectd ELB로 구성

 

- 분산 구성 요소 : 컨트롤 플레인은 AWS 리전 내 AWS 가용성 영역 3개에 걸쳐 최소 2개의 API 서버 인스턴스와 3개의 etcd 인스턴스를 배치합니다.

- 최적의 성능 / 뛰어난 복원성 / 일관적인 가동 시간 준수

 

[Data Plane]

AWS에서 관리하는 영역 > Pod, Kubelet

사용자가 관리하는 영역 > kube-proxy

 

- EKS Data Plane의 노드 유형

1. 자체 관리 노드(Self-Managed Nodes)

EC2 인스턴스를 워커 노드(worker node)로 사용하는 방식으로 자체 관리 노드의 경우 사용자가 직접 인스턴스 프로비저닝, OS 업데이트, 보안 패치, 클러스터와의 연동 등을 관리합니다. 

 

2. 관리형 노드 그룹(Managed Node Groups):

관리형 노드 그룹은 EKS에서 제공하는 기능으로, 노드 그룹 생성, 자동 스케일링, 업데이트 등을 보다 쉽게 관리할 수 있도록 지원합니다.

3. AWS Fargate 
Fargate는 서버리스 컨테이너 실행 환경을 제공하여, 사용자가 EC2 인스턴스와 같은 인프라를 직접 프로비저닝하거나 관리할 필요 없이 컨테이너를 실행할 수 있게 합니다.
EKS와 연동하여 Fargate 프로파일을 구성하면, 특정 네임스페이스나 라벨에 따라 파드가 자동으로 Fargate에서 실행됩니다.

 

4. Karpenter
AWS에서 오픈소스로 공개한 Karpenter는 클러스터의 워크로드 요구에 따라 필요한 노드를 신속하게 프로비저닝(생성)하거나, 사용되지 않는 노드를 종료합니다.

5. AWS Hybrid Nodes
EC2 기반 노드와 Fargate 노드(또는 온디맨드와 스팟 인스턴스 등 서로 다른 특성을 가진 노드)를 함께 운영하는 환경을 의미합니다.

 

6. EKS Auto Mode

컨트롤 플레인을 넘어 데이터 영역을 포함하도록 AWS 관리를 확장하여 클러스터 인프라 관리를 자동화합니다. 

 

 

[EKS Cluster Endpoint Access]

쿠버네티스 API 서버에 대한 접근 방식으로 사용자가 쿠버네티스 API 서버에 요청을 할 때 어떤 방식으로 클러스터와 상호 작용하는 지를 정의합니다.

 

1) Public Endpoint Access

- 외부 시스템 > API 서버 : Public

- 내부 시스템 > API 서버 : Public 

 

kubectl이 외부에 위치한다면 API 서버에 연결되어 있는 NLB을 통해 누구나 어디에서 접근이 가능합니다. (EKS의 고가용성을 위해 여러 API 서버가 제공되며 NLB로 분산)

API 서버에서 kubelet으로 접근 시에 EKS owned ENI를 통해 워커 노드 내의 kubelet 명령을 내립니다. (내부 통신으로 해당 구간은 Public, Private, Public Private 모두 동일합니다.) 

명령을 받은 kubelet은 작업을 수행하고 워커노드의 상태를 API 서버로 보고합니다. 이때 API 서버의 endpoint가 NLB이므로 트래픽은 IGW를 통해 외부를 거쳐 API 서버로 전송됩니다.

 

- 적용 사례 : 퍼블릭 네트워크 상의 클라이언트에서 EKS 클러스터와 상호작용해야 하는 경우, 초기 개발 및 테스트 환경

- 장점 : 설정이 간단하고 별도의 프라이빗 네트워크 구성 없이 접근 가능, 인터넷 연결만 있으면 어디에서나 클러스터 접근 가능

- 단점 : 엔드포인트를 퍼블릭 환경에 노출하기 때문에 보안 리스크 증가, 접근 대상의 White List를 관리하는 작업 필요

 

2) Private Endpoint Access 

- 외부 > API 서버 : Private

- 내부 > API 서버 : Private

 

kubectl이 VPC 내부에 위치할 경우, 즉 노드와 API 서버 간의 모든 통신이 VPC 내에 유지되도록하는 구성입니다. Private Endpoint Access를 활성화하면 EKS는 Route 53 Priavate 호스팅 영역(EKS owned ENI)을 생성하고 클러스터의 VPC에 연결합니다. 이 프라이빗 호스팅 영역은 EKS에서 관리하며 사용자 계정의 Route53 리소스에는 표시되지 않습니다.

 

- 적용 사례 : 프로덕션 환경과 같이 보안이 중요한 환경, 온프레미스 또는 Direct Connect/VPN을 통해 VPC에 접근 가능한 경우
- 장점 : 엔드포인트를 퍼블릭 환경에 노출하지 않기 때문에 보안 강화, VPC 내에서만 접근 가능하므로 외부 인터넷 트래픽이 제한
- 단점 : VPC 외부에서 EKS Cluster 접근에 어려움, 프라이빗 네트워크 접근 위한 VPN이나 Bastion 구성이 필요

 

3) Public + Private Endpoint Access 

- 외부 > API 서버 : Public

- 내부 > API 서버 : Private

 

Public과 Private 방식이 혼합된 방식으로 API 서버의 Endpoint 도메인 주소는 동일하게 NLB의 Public IP가 사용됩니다. 

다만, Public과 다른 점은 워커노드를 위한 별도의 Private 호스팅 영역에 주소가 생성되어 API 서버로의 통신 시 외부로 나가는 것이 아닌 EKS owned ENI를 통하여 전송됩니다. 

 

- 적용 사례 : 퍼블릭 및 프라이빗 접근이 모두 필요한 경우, 클러스터 관리자는 프라이빗 접근을 하고, 외부 시스템은 퍼블릭 접근하는 경우
- 장점 : 퍼블릭과 프라이빗 접근 요구 사항을 모두 만족
- 단점 : 엔드포인트를 퍼블릭 환경에 노출하기 때문에 보안 리스크 증가, 설정 및 관리가 복잡한 편