kubernetes 컨트롤 플레인 또는 노드를 제공하는 AWS의 관리형 Kubernetes 서비스
다수의 AWS 가용 영역에 Kubernetes Control Plane 실행 -> Control Plane의 컴포넌트인 API 서버, 스케쥴러, Controller Management, etcd가 가용영역 별로 구성된다는 의미이다.
다양한 AWS 서비스와 통합하여 확장성과 보안성 제공
컨테이너 이미지 저장소 -> Amazon ECR
부하 분산 -> Amazon ELB
보안 주체 및 액세스 사용 -> IAM
노드 격리 -> Amazon VPC
Kubernetes 최신 버전을 사용하여 Amazon EKS로 손쉬운 마이그레이션이 가능 - X(Major).YY(Minor).Z(Petch)
관리 콘솔
AWS 관리 콘솔에 접근하여 EKS 클러스터 생성. 인터페이스 가시성은 좋지만, 설정을 위해 일일히 작업을 해줘야하는 불편함이 있다.
eksctl
EKS 클러스터를 생성하고 관리하는 명령어 기반의 CLI 도구이다. eksctl 명령어를 입력하면 EKS 클러스터를 생성하거나 삭제하고 관리할 수 있다.
IaC(Inprastructure as Code) - ex. AWS CDK, AWS CloudFormation, Terraform
코드 기반으로 인프라를 정의해 EKS 클러스터 생성.
Kubernetes를 제어하기 위한 컨트롤 플레인 컴포넌트(API 서버, 컨트롤러, 스케줄러, ETCD)가 AWS 관리형으로 동작한다.
출처: 인프런, Ongja_CloudNet@, ⌜CloudNet@와 함께하는 Amazon EKS 기본 강의⌟
etcd는 클러스터의 중앙 데이터 저장소 역할을 한다. Kubernetes의 모든 상태 정보, 구성 정보, 클러스터의 메타데이터가 etcd에 저장된다. 이는 Kubernetes의 핵심 구성 요소 중 하나로, 클러스터의 상태와 구성 정보를 일관되게 관리하고 저장하는 역할을 담당한다.
Auto Scailing Group을 통해 지정된 수량의 자원을 유지·확장·축소할 수 있어 서비스 연속성을 지닌다.
가용 영역별로 자원이 다수로 구성됨에 따라 ELB를 배치해 트래픽을 분산한다. -> 효율적 통신과 고가용성 보장
Kubernetes 클러스터의 노드를 구성하기 위해 Data Plane 컴포넌트(컨테이너 런타임, Kubelet, kube-proxy)가 동작한다.
출처: 인프런, Ongja_CloudNet@, ⌜CloudNet@와 함께하는 Amazon EKS 기본 강의⌟
EKS owned ENI
ENI(Elastic Network Interface)는 EC2 인스턴스를 네트워크에 연결하는 가상 네트워크 인터페이스이다. EC2 인스턴스는 ENI를 통해 VPC 내 서브넷과 연결되고, IP 주소와 보안 그룹이 할당된다.
좌: x, 우: o
출처: https://jibinary.tistory.com/133
ENI는 EC2의 일종의 가상의 랜카드(LAN Card)로, 하나 이상의 IP 주소, 보안 그룹, MAC 주소를 가질 수 있다.
ENI에 할당된 IP 주소로 EC2 인스턴스에 접근하며, 이를 통해 네트워크 트래픽을 처리한다.
Control Plane과는 다르게 사용자 VPC에서 생성된다. -> 사용자가 직접 운용 및 관리 가능
Control Plane에서 Data Plane을 제어하기 때문에 관리용 VPC도 아키텍처에 같이 표현되어 있다. 이 중 Data Plane과 연계되는 API 서버만 표현됐다.
위 아키텍처는 노드 구성 방식이 관리형 노드 그룹 방식임을 가정한다.
Control Plane 영역과 Data Plane 영역은 EKS owned ENI라는 네트워크 인터페이스로 연결되어 있고, 이를 활용하여 통신한다.
Amazon EKS 클러스터에 데이터 플레인 노드를 구성하는 방식은 3가지로 분류된다.
관리형 노드 그룹(Managed Node Groups)
Managed Node Groups는 AWS에서 관리하는 방식이다. 해당 방식은 AWS가 노드의 수명 주기를 관리하며, 사용자는 노드를 손쉽게 추가하거나 제거할 수 있다.
EKS에 최적화된 AMI를 사용한다.
사용자는 노드 그룹에 사용할 다양한 EC2 인스턴스 유형을 선택할 수 있다.
유지 관리 및 버전 관리를 AWS에서 지원한다.
노드 그룹에 대해 자동 확장을 설정할 수 있다.
자체 관리형 노드(Self-Managed Node Groups)
Self-Managed Node Groups는 사용자가 직접 관리하는 방식dl다. 해당 방식은 더 큰 유연성을 제공하지만, 사용자에게 더 많은 관리 책임이 존재한다.
사용자 정의 AMI를 사용한다.
특정 요구 사항에 맞게 노드 구성 및 네트워킹 설정을 완전히 제어할 수 있다.
유지 관리 및 버전 관리를 직접 수행한다.
사용자가 직접 EC2 인스턴스를 관리하므로 비용 최적화에 더 많은 유연성이 있다.
AWS Fargate
서버리스 방식으로, EC2 인스턴스를 사용하지 않고도 컨테이너를 실행할 수 있는 방식이다. 인프라 관리를 전혀 할 필요가 없으며, Fargate가 필요한 리소스를 자동으로 할당하고 관리한다.
사용자가 직접 관리 없이 서버리스 환경에서 동작한다.
AWS Fargate 환경에서 제공하는 Micro VM 형태로 할당하여 관리한다. -> Firecracker라는 서버리스 컴퓨팅을 위한 오픈 소스 경량 가상화 기술을 통해 가상머신의 단점을 보완한다.
Control Plane 뿐만 아니라 워커 노드도 AWS 관리형으로 동작한다.
쿠버네티스 클러스터의 API Server로 접근을 위해 퍼블릭 엔드포인트(EKS 클러스터의 Control Plane에 접근할 수 있는 API 서버의 URL)를 정의할 수 있다. 하지만 EKS 클러스터 엔드포인트를 퍼블릭으로 구성하면 자유로운 접근이 가능하지만 보안적인 측면과 효율성 측면에서 떨어지는 통신이 된다. 일반적인 비즈니스 환경에서는 권장되지 않는 방식이다.
출처: 인프런, Ongja_CloudNet@, ⌜CloudNet@와 함께하는 Amazon EKS 기본 강의⌟
엔드포인트의 도메인 주소는 NLB Public IP로 매핑한다.
API 서버 -> kubelet
EKS owned ENI를 통해 워커 노드의 kubelet으로 전달한다.
kubelet -> API 서버
엔드포인트가 퍼블릭 IP 주소이므로 인터넷 게이트웨이로 빠져나가 인터넷 구간을 통해 관리형 VPC로 진입하고 API 서버로 전달한다.
해당 방식의 통신은 외부 인터넷 구간으로 트래픽이 노출되어 보안적인 측면으로도 좋지 않고, 비효율적인 통신이다.
사용자 kubectl -> API 서버
외부 인터넷 구간에서 관리형 VPC로 진입하고 API 서버가 전달받는다. 퍼블릭 환경이므로 사용자는 외부 구간에서 인터넷을 통해 자유롭게 접근이 가능하지만 사용자가 아닌 사람도 접근할 수 있는 여지가 존재한다.
비즈니스 환경에 따라 EKS 클러스터 엔드포인트 방식을 퍼블릭과 프라이빗을 혼용해서 사용할 수 있다.
출처: 인프런, Ongja_CloudNet@, ⌜CloudNet@와 함께하는 Amazon EKS 기본 강의⌟
엔드포인트의 도메인 주소는 NLB Public IP로 매핑한다.
워커 노드를 위한 주소는 별도의 프라이빗 호스팅 존을 구성해 대상을 EKS owned ENI로 매핑한다.
API 서버 -> kubelet
엔드포인트와 별개로 EKS owned ENI를 통해 통신이 된다.
kubelet -> API 서버
AWS 내부 프라이빗 호스팅 존에게 DNS 질의한 후 대상을 EKS owned ENI로 전달하고 이를 통해 API 서버가 전달받는다.
외부 인터넷 구간의 노출 없이 보안성이 있는 통신이 가능하다.
외부 인터넷 구간의 노출 없이 AWS 내부로 동작하여 보안성 있는 통신과 효율적인 통신이 가능하다. 일반적인 비즈니스 환경에 적합하다.
출처: 인프런, Ongja_CloudNet@, ⌜CloudNet@와 함께하는 Amazon EKS 기본 강의⌟
엔드포인트 도메인 주소는 AWS 내부의 프라이빗 호스트존에서만 관리한다.
프라이빗 호스팅 존(Private Hosted Zone)을 사용하여 EKS API 서버 엔드포인트를 EKS owned ENI와 매핑하는 것은 주로 Amazon Route 53에서 이루어진다.
사용자는 Custom VPC 내에 있는 EC2 인스턴스에 접속 후 kubectl 명령을 하던가, VPC 피어링 또는 Direct Connect를 통한 접근 같이 Custom VPC 위치에서 명령을 수행해야 한다.
API 서버 -> kubelet
API 서버는 EKS owned ENI를 통해 kublet으로 통신한다.
kubelet -> API 서버
kublet은 프라이빗 호스팅 존에 의해 EKS owned ENI를 통해 API 서버로 통신한다.
사용자 kubectl -> API 서버
프라이빗 호스팅 존에 의해 EKS owned ENI를 통해 API 서버로 통신한다.