[Amazon EKS STUDY] #1주차 (이론) Amazon EKS의 개념 및 구성 요소

출처: https://leehosu.tistory.com/entry/AEWS-1-1-Amazon-EKS%EB%9E%80

1. Amazon EKS란?

출처: https://catalog.us-east-1.prod.workshops.aws/workshops/9c0aa9ab-90a9-44a6-abe1-8dff360ae428/ko-KR/30-setting/300-kubectl

• 자체 Kubernetes 컨트롤 플레인을 실행하고 노드를 설치, 관리하는 관리형 서비스
  (사용자는 컨트롤 플레인 접근 불가)
• 컨트롤 플레인은 제어 영역의 인스턴스 크기를 자동 조정하고 비정상 제어 영역 인스턴스 감지하고 교체하며, 자동화된 버전 업데이트 및 패치 제공

 

1. 2 관련 Tool 설치

1.2.1 kubectl

• 쿠버네티스 클러스터에 명령을 내리는 CLI
• 쿠버네티스는 오브젝트 생성, 수정 혹은 삭제와 관련한 동작을 수행하기 위해 쿠버네티스 API를 사용
  이때, kubectl CLI를 사용하면 해당 명령어가 쿠버네티스 API를 호출해 관련 동작을 수행

sudo curl -o /usr/local/bin/kubectl  \
   https://s3.us-west-2.amazonaws.com/amazon-eks/1.27.4/2023-08-16/bin/linux/amd64/kubectl
   
sudo chmod +x /usr/local/bin/kubectl

kubectl version --client=true --short=true

# 출력되는 결과 값
Client Version: v1.27.4-eks-8ccc7ba
Kustomize Version: v5.0.1

 

1.2.2 jq 설치하기

jq는 JSON 형식의 데이터를 쉽게 다룰 수 있게 해주는 커맨드라인 툴. JSON 데이터를 필터링, 추출, 변경, 정렬 가능

# jq 설치
sudo yum install -y jq

 

1.2.3 Git 설치하기

https://git-scm.com/downloads

 

 

1.2.4 eksctl 설치하기

eksctl은 EKS 클러스터를 쉽게 생성 및 관리하는 CLI 툴. Go 언어로 쓰여 있으며 내부적으로 CloudFormation 스택으로 배포됨

curl --silent --location "https://github.com/weaveworks/eksctl/releases/latest/download/eksctl_$(uname -s)_amd64.tar.gz" | tar xz -C /tmp

sudo mv -v /tmp/eksctl /usr/local/bin

eksctl version

 

 

1.3 Amazon EKS 쿠버네티스 지원 버전 

• 보통 5~6개의 마이너 버전 지원되며 평균 3개월마다 새 버전 제공됩니다. (현재 1.29~1.32)
• 각 버전은 표준 지원 기간 동안 보안 업데이트와 버그 수정을 받으며, 이후에는 추가 지원 기간이 제공됩니다
• 클러스터 버전 업데이트 주기가 잦으므로 버전 업을 위해 확인 필수

 

1.4 EKS 구성 요소

EKS의 구성요소는 크게 ContorlPlane과 Data plane으로 구성

 

 

Control Plane

• 클러스터 내 실행되는 애플리케이션과 서비스를 관리하고 클러스터 상태 모니터링 수행
• kube-apiserver, kube-controller, kube-scheduler, etcd

ControlPlane 구성요소
kube-apiserver
- 클러스터와 모든 통신을 처리하는 엔드포인트
- 외부로부터 들어온 트래픽 또는 클러스터 내부 구성 요소 간 통신을 맡음

kube-controller-manager
- 클러스터 상태를 원하는 상태로 유지
- ex) 스케줄러에 의해 파드가 실제로 해당 노드에서 실행되는지, 필요한 수의 파드 복제본이 유지되는지 관리

kube-scheduler
- 새로 생성된 컨테이너(파드)를 클러스터 내 노드에 할당하는 역할
- 리소스 요구사항 등 제약 조건에 따라 최적의 노드를 선정하여 배포

etcd
- 클러스터의 모든 상태 정보를 저장하는 분산 key-value 저장소
ex) 어떤 애플리케이션이 어디 배포되어 있는지, 사용 가능한 리소스는 얼마나 되는지 등

 

Data Plane

Data Plane (Worker Node, NodeGroup)

• 클러스터 내에서 실제 애플리케이션과 워크로드가 실행되는 부분
• 각 노드는 컨테이너화된 애플리케이션(파드)를 실행

DataPlane 구성요소
Pod
- K8S에서 애플리케이션 컨테이너를 실행하는 가장 작은 배포 단위

kubelet
- 모든 k8s 노드에서 실행되는 agent로, 각 노드에서 컨테이너가 파드로 실행되고 있는지 관리
- 특히 kube-apiserver로부터 Pod 생성, 수정, 삭제 명령을 받고
컨테이너 런타임을 사용하여 컨테이너의 생명주기를 관리하며
노드의 상태, 파드의 상태 정보를 주기적으로 kube-apiserver로 전달

kube-proxy
- Kubernetes 클러스터의 각 노드에서 실행되는 네트워크 프록시
- service의 IP 주소와 port를 사용하여 클러스터 내외부에서 서비스에 접근 가능

 

 

노드 그룹 유형

1. Managed node groups (커스텀 불가)

• 최신 EKS Optimized AMI를 사용 - 링크, AWS에서 AMI 관리, Capacity(On-Demand, Spot)

 

2. Self-managed nodes (커스텀 가능)

• Custom AMI를 사용, ASG 직접 관리, OS 기본구성/패치를 고객이 직접 관리

 

3. AWS Fargate (서버리스)

• 고객은 별도의 EC2관리할 필요 없이, AWS Fargate 환경에서 제공하는 Micro VM을 이용하여 Pod 별 VM 할당

 

♣ ETCD는 무엇일까요?
ETCD는 분산 시스템에서 중요한 상태 정보를 저장하는 분산형 데이터베이스입니다.

♣ API 부하분산을 ALB가 아닌 NLB를 사용하는 이유는?
NLB: 4계층(TCP/UDP)에서 작동
초고성능, 낮은 지연 시간, 정적 IP 주소 할당, TCP/UDP 트래픽 처리, 탄력적 IP 주소 사용 가능

ALB: 7 계층 (HTTP/HTTPS)에서 작동.
자동 스티키 세션, HTTP/2 및 WebSocket 지원

 

 

 

EKS의 2가지 VPC

EKS에는 2가지 VPC가 존재합니다.

 

1. Control Plane을 AWS에서 관리하는 AWS VPC

2. Data Plane을 사용자가 직접 관리하는 Custom VPC

 

이에 따라 AWS에서는 사용자가 Control Plane을 관리하지 않고, 실질적으로 애플리케이션만 운영, 관리하도록 Data Plane만 관리하게 하여 Custom VPC에만 집중할 수 있습니다.

 

 

EKS Cluster Endpoint

출처: https://velog.io/@rockwellvinca/EKS-AWS-EKS%EC%9D%98-%ED%81%B4%EB%9F%AC%EC%8A%A4%ED%84%B0-%EC%97%94%ED%8A%B8%ED%8F%AC%EC%9D%B8%ED%8A%B8%EB%9E%80

• Kubernetes API 서버에 접근하기 위한 URL
• 클러스터를 생성할 때 고유한 endpoint를 자동으로 생성
• 이 엔드포인트를 통해 kubectl과 같은 도구나 CI/CD 파이프라인, 관리 콘솔 등에서 클러스터에 명령어 가능

쿠버네티스의 엔드포인트 액세스란 쿠버네티스 API 서버에 접근 방식이다.

사용자가 kubectl 명령어를 통해 쿠버네티스 API 서버에 명령을 내릴 때, 어떤 방식으로 클러스터와 통신(상호작용)하는 지 정의한다.

 

EKS Cluster Endpoint - Public

Public 유형의 EKS Cluster Endpoint는 IGW를 통해 Cluster Endpoint에 접근할 수 있습니다.

Endpoint로 접근하는 도메인의 주소는 AWS NLB의 Public IP 주소입니다.

 

NLB의 퍼블릭 IP 주소 사용 이유
고 가용성을 위해 EKS에서 여러 API 서버가 구성(기본적으로 3개)되므로 이에 대해서 각 API 서버에 고르게 부하분산하기 위해서 앞단에 NLB가 위치하는 것입니다.

 

 

통신 프로세스 정리
1. 외부 통신: 사용자 (kubectl) → IGW(public) → Control Plane의 API 서버
2. 내부 통신: Control Plane의 API 서버 → Kubelet 통신
3. 외부 통신: Kubelet → API 서버

 

• 사용자 (kubectl) → 인터넷(IGW) → Control Plane의 API 서버
  사용자가 kubectl 명령어를 외부 인터넷을 통해 AWS Managed VPC 내 API 서버에게 요청을 보냄
• Control Plane의 API 서버 → Kubelet 통신
  

 

• 사용자 명령을 받은 API 서버는 EKS owned ENI를 통해 Workernode의 kubelet에 명령을 내림
  단순한 내부 통신

 

 

• Kubelet → API 서버

명령을 받은 kubelet은 작업을 수행하고 워커노드의 상태를 다시 API 서버에 보고합니다.
여기서 보고할 때 API 엔드포인트가 NLB의 Public IP주소이므로 이 요청은 IGW를 통해 외부로 빠져나가 API 서버에 전송

 

 

EKS Cluster Endpoint - Public Private

Public Private 혼용된 방식으로 EKS Cluster Endpoint는 IGW를 통해 Cluster Endpoint에 접근할 수 있습니다.

Endpoint로 접근하는 도메인의 주소는 AWS NLB의 Public IP 주소입니다.

 

이 때 중요한 점은 Worker Node를 위한 주소가 별도의 프라이빗 호스팅 존으로 구성되어

 

통신 프로세스 정리
1. 외부 통신: 사용자 (kubectl) → IGW → Control Plane의 API 서버
2. 내부 통신: Control Plane의 API 서버 → Kubelet 통신
3. 내부 통신: Kubelet → API 서버

 

• 사용자 (kubectl) → 인터넷(IGW) → Control Plane의 API 서버

사용자가 kubectl 명령어를 외부 인터넷을 통해 AWS Managed VPC 내 API 서버에게 요청을 보냄

 

• Control Plane의 API 서버 → Kubelet 통신

사용자 명령을 받은 API 서버는 EKS owned ENI를 통해 Workernode의 kubelet에 명령을 내림
단순한 내부 통신

 

• Kubelet → API 서버

 

명령을 받은 kubelet은 작업을 수행하고 워커노드의 상태를 다시 API 서버에 보고. 

이 과정에서 AWS 프라이빗 호스팅 존을 통해서 EKS owned ENI를 통과해 나가게 됩니다.

 

AWS 프라이빗 호스팅 존
123abc.eks.amazonaws.com = EKS owned ENI 등록됨

 

 

 

EKS Cluster Endpoint - Private

 

Private 방식으로 EKS Cluster Endpoint는 VPC 내부에서 사용자가 접근하므로 NLB의 Public IP로 접속 불가합니다.

 

통신 프로세스 정리
1. 내부 통신: 사용자 (kubectl) → Control Plane의 API 서버
2. 내부 통신: Control Plane의 API 서버 → Kubelet 통신
3. 내부 통신: Kubelet → API 서버

 

• 사용자 (kubectl) → Control Plane의 API 서버

 

사용자는 VPC 내부에 있는 서버에서 kubectl 명령어를 보내면 EKS owned ENI를 통해 API 서버로 요청이 갑니다.

 

 

• Control Plane의 API 서버 → Kubelet 통신

 

 

• Kubelet → API 서버

사용자 명령을 받은 API 서버는 EKS owned ENI를 통해 Workernode의 kubelet에 명령을 내림
이 과정에서 AWS 프라이빗 호스팅 존을 통해서 EKS owned ENI를 통과해 나가게 됩니다.

 

 

---

[심화 내용]

카타 컨테이너 (Kata Container)

• 컨테이너 처럼 느껴지게 작동하는 경량 VM으로 HW 를 통한 강력한 workload 격리로 안전한 컨테이너를 제공
• 특징 : 보안(개별적인 전용 kernel), 분리된 (Network I/O Memory) 제공 → 하드웨어 강제격리 제공, VM처럼 성능의 소모 없이 분리된 환경을 제공
• 지원하는 하이퍼바이저 : qemu, cloud-hypervisor, firecracker, ACRN

 

카타 컨테이너 환경 vs 일반 컨테이너 환경