Amazon EKS란?
ChatGPT가 알려주는 Amazon EKS.
AWS EKS(Elastic Kubernetes Service)는 Amazon Web Services가 제공하는 관리형 컨테이너 서비스로, 사용자가 Kubernetes 애플리케이션을 쉽게 배포, 관리, 확장할 수 있게 해 줍니다. Kubernetes는 오픈소스 컨테이너 오케스트레이션 플랫폼으로, 컨테이너화된 애플리케이션의 배포, 스케일링 및 관리를 자동화합니다.
AWS EKS는 AWS 클라우드 인프라에서 Kubernetes 애플리케이션을 실행하기 위한 완전 관리형 서비스를 제공합니다. 이를 통해 개발자는 인프라 관리에 덜 신경 쓰고 애플리케이션 개발에 더 집중할 수 있습니다. EKS는 고가용성을 지원하며, AWS의 다양한 서비스와 통합되어 보안, 스케일링, 모니터링 등의 기능을 제공합니다.
즉, 다시 정리하자면 Amazon EKS란
- 자체 Kubernetes 컨트롤 플레인 또는 노드를 설치, 운영 및 유지 관리할 필요 없이 Kubernetes 실행에 사용할 수 있는 관리형 서비스입니다.
- 여러 AWS 가용 영역에 걸쳐 Kubernetes 컨트롤 플레인을 실행하고 크기를 조정하여 높은 가용성을 보장합니다.
- 컨트롤 플레인은 제어 영역 인스턴스의 크기를 자동으로 조정하고, 비정상 제어 영역 인스턴스를 감지하고 교체하며, 자동화된 버전 업데이트 및 패치를 제공합니다.
- 여러 AWS 서비스와 통합 (컨테이너 이미지 저장소 Amazon ECR, 로드 분산을 위한 ELB, 인증 IAM, 격리를 위한 Amazon VPC)
- 오픈 소스 Kubernetes 소프트웨어의 최신 버전을 실행하므로 Kubernetes 커뮤니티에서 모든 기존 플러그 인과 도구를 사용할 수 있습니다. 필요한 코드를 수정하지 않고 표준 Kubernetes 애플리케이션을 Amazon EKS로 쉽게 마이그레이션 할 수 있습니다.
Amazon EKS 쿠버네티스 지원 버전 안내
보통 5~6개의 마이너 버전 지원(현재 1.25~1.29)되며 평균 3개월마다 새 버전 제공됩니다. 또한, 업스트림 쿠버네티스가 EKS에서 사용 가능한 버전을 더 이상 지원하지 않는 경우에도 EKS에서의 쿠버네티스 버전은 Amazon EKS에서 사용 가능한 이후 14개월 동안 완전히 지원됩니다.
Amazon EKS Architecture
EKS의 구성요소를 크게 ContorlPlane과 Data plane으로 나눠서 보겠습니다.
인프라 운영 측면에서의 역할은 Control Plane이 담당하며 kube-apiserver, kube-controller, kube-scheduler, etcd가 구성됩니다. 이 Control Plane은 고객(사용자)가 관여하지 않아도 되는 것이 EKS의 특징입니다.
서비스 배포 측면에서의 역할은 Data Plane이 담당합니다. Data Plane은 WokerNode라고도 불리며, Pod, kube-proxy, kubelet으로 구성됩니다.
Amazon EKS Control Plane
쉽게 말해, Contrl Plane은 Kubernetes 클러스터의 '두뇌' 역할을 합니다.
여기에는 클러스터 내에서 실행되는 애플리케이션과 서비스를 관리하고, 클러스터의 상태를 모니터링하며, 아래의 구성요소가 포함됩니다.
ChatGPT가 알려주는 Control Plane 구성요소
kube-apiserver : 클러스터와의 모든 통신을 처리하는 엔드포인트입니다. 사용자, 외부 서비스, 클러스터 내부의 다른 구성 요소들이 API 서버를 통해 서로 통신합니다.
etcd: 클러스터의 모든 상태 정보를 저장하는 분산 key-value 저장소입니다. 예를 들어, 어떤 애플리케이션이 어디에 배포되어 있는지, 사용 가능한 리소스는 얼마나 되는지 등의 정보가 여기에 저장됩니다.
kube-scheduler : 새로 생성된 컨테이너(파드)를 클러스터 내의 적절한 노드에 할당하는 역할을 합니다. 리소스 요구사항, 하드웨어/소프트웨어/정책 제약 조건 등을 고려하여 최적의 노드를 선택합니다.
kube-controller-manager : 클러스터의 상태를 원하는 상태로 유지하는 역할을 합니다. 예를 들어, 스케줄러에 의해 할당된 파드가 실제로 해당 노드에서 실행되고 있는지, 필요한 수의 파드 복사본이 유지되고 있는지 등을 관리합니다.
ChatGPT가 알려주는 API 부하분산을 ALB가 아닌 NLB를 사용하는 이유
컨트롤 플레인의 영역은 동적으로 스케일링되며, 이 과정에서 부하 분산이 가장 중요한 부분입니다. 그렇기에 NLB(Network Load Balancer)의 특징 중 확장성, 낮은 지연 시간 때문에 컨트롤 플레인이 효율적으로 스케일링되고, 클러스터의 상태와 요구 사항에 따라 동적으로 조정될 수 있도록 NLB를 사용합니다.
ALB (Application Load Balancer)란?
- 계층 : 7 계층(HTTP/HTTPS)에서 작동
- 기능 : 고급 요청 라우팅(경로, 호스트, HTTP 헤더 기반 라우팅), 웹 애플리케이션 방화벽(WAF) 통합, 자동 스티키 세션, HTTP/2 및 WebSocket 지원 등.
- 사례 : 복잡한 라우팅이 필요한 웹 애플리케이션 및 마이크로서비스 아키텍처.
NLB (Network Load Balancer)란?
- 계층 : 4 계층(TCP/UDP)에서 작동
- 기능 : 초고성능, 낮은 지연 시간, 정적 IP 주소 할당, 확장성, TCP/UDP 트래픽 처리, 탄력적 IP 주소(EIP) 사용 가능.
- 사례 : 단순한 라우팅이 필요하거나, 초고성능 및 낮은 지연 시간이 요구되는 애플리케이션, TCP 또는 UDP 트래픽을 처리해야 하는 경우.
여담
Amazon EKS Data Plane
DataPlane은 클러스터 내에서 실제로 애플리케이션과 워크로드가 실행되는 부분으로 여러 개의 노드로 구성되며, 각 노드는 Kubernetes 클러스터의 일부로서 컨테이너화된 애플리케이션(pod)을 실행합니다.
ChatGPT가 알려주는 Data Plane의 구성요소
- Pod : Pod는 Kubernetes에서 애플리케이션 컨테이너를 실행하는 가장 작은 배포 단위입니다.
- kubelet : 모든 Kubernetes 노드에서 실행되는 에이전트로 각 노드에서 컨테이너가 파드로 정의된 대로 실행되고 있는지를 관리합니다. 특히, kube-apiserver로부터 pod를 생성, 수정, 삭제하는 명령을 받고, 컨테이너 런타임을 사용하여 컨테이너의 생명주기를 관리하며 노드의 상태, 파드의 상태 정보를 주기적으로 kube-apiserver로 전달합니다.
- kube-proxy : Kubernetes 클러스터의 각 노드에서 실행되는 네트워크 프록시로써 service의 IP 주소와 port를 사용하여 클러스터 내외부에서 서비스에 접근할 수 있도록 합니다.
Amazon EKS Data Plane 배포 옵션
Self-Managed Node Group
custom AMI를 이용하며 AutoScailingGroup을 직접 관리합니다.
-> OS에 대한 기본 구성, 패치에 대한 책임은 사용자 책임 영역입니다.
Managed Node Group
최신의 EKS optimized AMI를 사용하여 새로운 AMI에 대한 배포 및 구버전 AMI 제거 등을 모두 자동화하여 AWS에서 처리합니다.
AWS Fargate
별도로 관리하는 EC2 인스턴스 없이 Fargate 환경에서 제공하는 Micro VM을 활용하여 Pod별 VM 할당합니다.
Cloud 환경에서 Amazon EKS 클러스터를 실행할 수 있는 옵션
Amazon EKS와 Amazon EC2를 활용한 배포 방법과 Amazon EKS와 AWS Fargate를 활용한 배포 방법이 존재합니다.
이번 스터디에서는 Amazon EKS와 Amazon EC2로 배포하는 방법에 대해 다룹니다.
EKS Cluster Endpoint
EKS Cluster Endpoint를 설명하기 전, EKS에는 2가지의 VPC가 존재한다는 것을 알아야 합니다.
- Control Plane을 AWS에서 관리하는 AWS VPC
- Data Plane을사용자가 직접 관리하는 Customer VPC
이에 따라 AWS에서는 사용자(고객)가 Control Plane을 관리하지 않고, 실질적으로 애플리케이션만 운영, 관리할 수 있게 Data Plane만 관리하게 하여 Customer VPC에만 집중할 수 있습니다.
EKS Cluster Endpoint는 Kubernetes API 서버에 접근하기 위한 URL으로, 클러스터를 생성할 때 고유한 endpoint를 자동으로 생성합니다. 이 엔드포인트를 통해 kubectl과 같은 도구나 CI/CD 파이프라인, 관리 콘솔 등에서 클러스터에 명령을 할 수 있습니다.
ChatGPT가 알려주는 EKS Cluster Endpoint의 주요 특징
- 보안: EKS 클러스터 엔드포인트는 HTTPS를 통해 암호화된 통신을 사용합니다.
- 접근 제어: 사용자는 AWS Identity and Access Management(IAM) 정책, Kubernetes RBAC(Role-Based Access Control)을 통해 엔드포인트에 대한 접근 권한 제어가 가능합니다.
- public 및 private 접근: EKS는 클러스터 엔드포인트에 대한 public 접근, private 접근, public과 private 접근 둘 다를 설정할 수 있는 옵션을 제공하며 클러스터의 보안 요구 사항에 맞게 엔드포인트 접근성을 조정할 수 있습니다.
ChatGPT가 알려주는 CustomerVPC내의 EKS owned ENI란?
AWS가 관리하는 EKS 클러스터의 ControlPlane이 사용자의 VPC(Virtual Private Cloud) 내에서 생성하고 관리하는 네트워크 인터페이스입니다. EKS owned ENI(Elastic Network Interface)는 아래와 같은 기능을 제공합니다.
1. ContolPlane과 DataPlane 간의 네트워크 통신
2. Kubernetes API 서버에 접근
3. 네트워크 보안 및 격리
Only Public endpoint
public endpoint는 기본 설정으로 요청자의 VPC에 상관없이 Cluster Endpoint에 접근할 수 있습니다. 또한 Endpoint로 접근하는 도메인 주소는 NLB의 public IP주소가 됩니다.
사용자가 명령어를 통해 cluster 접근 시 흐름
사용자의 kubectl 명령어 → 퍼블릭 도메인 → Control Plane(kube-apiserver)
Control Plane(kube-apiserver) → EKS owned ENI → 워커노드의 Kubelet
워커노드의 Kubelet → 퍼블릭 도메인 → Control Plane(kube-apiserver)
: kubelet은 작업을 수행하고 워커노드의 상태를 다시 control Plane의 kube-apiserver로 보고합니다. 이때, Endpoint가 현재 NLB의 public IP 주소로 되어 있어 해당 요청은 외부로 빠져나가 다시 Control Plane의 kube-apiserver로 전송됩니다.
Public + Private endpoint
endpoint는 NLB의 public IP주소가 사용되며, Worker Node를 위한 주소가 별도의 Private hosted zone으로 구성되어 EKS owned ENI로 매핑합니다.
사용자가 명령어를 통해 cluster 접근 시 흐름
사용자의 kubectl 명령어 → 퍼블릭 도메인 → Control Plane(kube-apiserver)
Control Plane(kube-apiserver) → EKS owned ENI → 워커노드의 Kubelet
워커노드의 Kubelet → Privat Hosted Zone → EKS owned ENI → Control Plane
: kubelet은 작업을 수행하고 워커노드의 상태를 다시 control Plane의 kube-apiserver로 보고합니다. 이때, AWS 내부의 private hosted zone을 통해서 EKS owned ENI를 통과해 Control Plane으로 전송됩니다.
Only Private endpoint
Custom VPC 내부에서 사용자 접근하기 때문에 더 이상 NLB의 public ip가 없습니다.
사용자가 명령어를 통해 cluster 접근 시 흐름
사용자의 kubectl 명령어 → Privat Hosted Zone → EKS owned ENI → Control Plane(kube-apiserver)
: 명령을 하는 사용자가 Custom VPC 내부에 있기 때문에 privated Hosted Zone을 거쳐 EKS owned ENI를 통해 Control Plane의 kube-apiserver로 요청을 보냅니다.
( 즉, private endpoint 방법은 명령을 하는 사용자가 Customer VPC 내에서 Cluster에 접근해야 합니다. )
Control Plane(kube-apiserver) → EKS owned ENI → 워커노드의 Kubelet
워커노드의 Kubelet → Privat Hosted Zone → EKS owned ENI → Control Plane
: kubelet은 작업을 수행하고 워커노드의 상태를 다시 control Plane의 kube-apiserver로 보고합니다. 이때, AWS 내부의 private hosted zone을 통해서 EKS owned ENI를 통과해 Control Plane으로 전송됩니다.
Reference
- ChatGPT
- https://www.youtube.com/watch?v=xIc6sB77Zqs
- https://docs.aws.amazon.com/eks/latest/userguide/clusters.html
- https://docs.aws.amazon.com/eks/latest/userguide/managed-node-groups.html
'스터디 이야기 > AWS EKS' 카테고리의 다른 글
| [AEWS] 2-1. Amazon EKS Networking - CNI (0) | 2024.03.12 |
|---|---|
| [AEWS] 1-3. terraform으로 EKS Cluster 배포하기 (2) | 2024.03.07 |
| [AEWS] 1-2. Amazon EKS Cluster 배포 (0) | 2024.03.05 |
| [AEKS] 00. 스터디 신청과 시작 (0) | 2024.03.04 |
