[AEWS] Wk1-1. EKS에 대해서

안녕하세요!

gasida님이 운영하시는 AEWS 스터디 1기에 참가하게 되었습니다.

앞으로 스터디 기간 동안 EKS에 대해서 학습하는 내용을 기록하고 공유할 예정입니다.

 

AWS EKS는 AWS의 관리형 Kubernetes 서비스로, Elastic Kubernetes Service의 줄임말입니다.

애플리케이션의 배포, 확장, 관리를 자동화할 수 있는 오픈 소스 시스템입니다.

 

1. EKS 특징

 

1. 고가용성

2. 컨트롤 플레인 인스턴스 크기를 자동 조정, 비정상 인스턴스 감지 및 교체, 자동화된 버전 업데이트 및 패치 제공

3. AWS 내의 여러 서비스들과의 통합을 제공합니다.

- ECR, ELB, IAM, VPC 등

 

2. EKS 아키텍처

 

Kubernetes Cluster

쿠버네티스를 통해서 클러스터(노드의 집합)를 배포하게 됩니다.

그리고, 그 클러스터는 크게 다시 컨트롤 플레인(Master Node) / 데이터 플레인(Worker Node)으로 구성됩니다.

 

EKS를 통해서 쿠버네티스 애플리케이션을 배포할 경우,

컨트롤 플레인의 영역은 신경 쓰지 않아도 됩니다.

 

1) 컨트롤 플레인

컨트롤 플레인의 리소스들을 정리해보면,

• API 서버 - 클러스터의 rest 진입점, api를 사용할 수 있도록 하는 컨트롤 플레인의 컴포넌트입니다.
  (컨트롤 플레인의 수뇌부라고 생각하시면 이해가 편합니다.)
  gRPC 프로토콜을 통해서 etcd에 연결하는 클라이언트입니다.
• 스케줄러 - 워커 노드에 파드를 스케줄링해 주는 리소스입니다.
• 컨트롤러 매니저 - 컨트롤러 프로세스를 동작시키는 컨트롤 플레인 컴포넌트로,
  노드, 파드, 클라우드 서비스의 생성 및 삭제를 담당합니다.
• 또한, etcd라고 하여 쿠버네티스의 모든 상태 정보를 key-value 저장소를 사용하여 정보를 저장합니다.

2) 데이터 플레인

데이터 플레인의 경우, 워커 노드들과 내부에 kubelet, kube-proxy로 구성이 됩니다.

• kubelet은 마스터 노드의 API 서버와 노드 간 연결해 주는 역할을 수행하고,
• kube-proxy는 IP 변환 및 라우팅 관리 역할을 수행합니다.

EKS 클러스터는 Managed Node Groups / Self Managed Nodes / AWS Fargate와 같은 3가지 노드 유형을 갖습니다.

 

데이터 플레인 별 책임 모델

각 워크로드에 대해서 도식부터 살펴보면 다음과 같습니다.

 

Self Managed Nodes

 

2-2-2. 데이터 플레인 

1) Self Managed Nodes

 

먼저 Self Managed Nodes부터 살펴보면, 최적화된 AMI 버전을 실행하는 계정에 EC2 Auto Scaling Group을 직접 설정하고, 클러스터에 데이터플레인으로 사용할 클러스터를 직접 등록합니다.

AWS는 컨트롤 플레인의 프로비저닝과 관리를 담당합니다.

EC2 Auto Scaling Group에 등록되어야 하는 인스턴스 타입은 동일한 유형으로 등록해야 하지만, 대한 요구 사항에 따라서 여러 노드 그룹을 생성 가능합니다.

 

• 장점 : 데이터 플레인의 제어 가능, 노드 그룹 내 EC2 인스턴스 유형 선택 가능, ASG를 생성하고 메트릭 확장 가능
• 단점 : 새로운 버전의 EKS 최적화 AMI가 출시될 경우, 노드의 수동 드레인이 필요. 아닐 경우 AMI를 새로운 노드 그룹으로 생성하여 이전 버전의 AMI로 교체 후 워크로드를 새 노드 그룹으로 마이그레이션

Managed Node Groups

2) Managed Node Groups

 

관리형 노드 그룹의 프로비저닝은 노드 그룹의 Auto Scaling Group에 직접 등록하고 프로비저닝 할 필요가 없습니다.

eksctl을 통한 cli 명령으로 노드 그룹의 프로비저닝 / 업데이트 / 삭제만 실행하면 됩니다.

작업 수행에 aws 콘솔 혹은 IaC 역시 사용 가능하며, 원하는 대로 워커 노드를 az 및 서브넷에 배포할 수 있습니다.

EC2 Auto Scaling Group은 AWS 계정 내에서 프로비저닝 되지만, 컨트롤 플레인은 AWS에서 관리합니다.

 

• 장점 : 노드 그룹의 쉬운 프로비저닝, 관리, 삭제.
  노드 드레이닝을 직접 수행할 필요가 없음
• 단점 : 노드 그룹 생성은 직접 수행해야 함

 

Fargate

3) Fargate

 

Fargate는 노드 그룹 혹은 워커 노드를 실제로 프로비저닝 하지 않고도 컨테이너를 실행하기 위한 서버리스 플랫폼입니다.

EKS 컨트롤 플레인은 Fargate에서 파드를 실행하기 위해서 Fargate 컨트롤러를 실행하며,

내부에 Fargate Profile을 생성하여 생성하여 워크로드를 실행합니다.

 

• 장점 : 생성 및 관리 노드 그룹이 없으며, 데이터 플레인은 AWS Fargate를 통해서 관리함
  데이터 플레인의 파드 축소 및 확장 역시 자동적으로 관리
• 단점 : 데이터 플레인을 위한 fine-grained control (세밀한 조정)이 불가능함
  Upstream 쿠버네티스 기능 지원 불가 (NodePort 등)

 

3. EKS의 클러스터 엔드포인트 액세스

 

1) 퍼블릭 엔드포인트

EKS를 프로비저닝 할 경우, EKS 클러스터는 기본적으로 퍼블릭 엔드포인트로 구성됩니다.

VPC 내에서 발생하는 Kubernetes API 요청은 Amazon 네트워크가 아니라 VPC 외부로 나가게 됩니다.

노드가 컨트롤 플레인에 연결하려면, Public IP 주소와 인터넷 게이트웨이에 대한 경로 혹은 NAT 게이트웨이의 Public IP를 사용할 수 있는 경로 역시 설정되어 있어야 합니다.

 

• 구성되는 모든 서브넷은 mapPublicIpOnLaunch 옵션이 True로 설정되어야 하며, 인터넷 게이트웨이에 대한 경로가 있어야 합니다.
• Node에 AssociatePublicIpAddress에 대한 값이 별도로 필요가 없습니다.

Public Endpoint로 구성

 

2) 퍼블릭 + 프라이빗 엔드포인트

 

• 퍼블릭 엔드포인트 및 프라이빗 엔드포인트가 모두 활성화된다면, Kubernetes API 요청이 VPC 내 EKS 관리 ENI를 통해서 컨트롤 플레인과 통신하게 됩니다.
• mapPublicIpOnLaunch 퍼블릭 서브넷에서 노드를 시작하지 않기 때문에 퍼블릭 서브넷에 대해 설정할 필요가 없습니다.
• mapPublicIpOnLaunch를 FALSE로 설정해야 합니다.
• AssociatePublicIpAddress (CFN 템플릿 또는 API 호출에 이 값을 포함하지 않으므로)에 대한 설정이 불필요함.

Public / Private Endpoint로 구성

 

3) 프라이빗 엔드포인트

프라이빗 엔드포인트만 활성화될 경우, 인터넷에서 쿠버네티스 내부의 API 서버에 대한 공개 액세스가 없기 때문에,

kubectl 명령은 연결된 네트워크를 통해서만 가능합니다. VPN 혹은 AWS DirectConnect를 통해서 구성됩니다.

 

• mapPublicIpOnLaunch FALSE로 설정해야 합니다.
• AssociatePublicIpAddress (CFN 템플릿 또는 API 호출에 이 값을 포함하지 않으므로)에 대한 설정이 불필요함.
• 개인 클러스터 엔드포인트만 활성화해야 합니다. 클러스터 엔드포인트에 액세스 하려면 VPN 연결이 필요합니다.
• EC2와 모든 Amazon ECR 및 S3 리포지토리에 대해 AWS PrivateLink를 활성화합니다.
• Kubernetes 애플리케이션이 다른 AWS 서비스에 연결할 수 있으려면 PrivateLink 인터페이스 및/또는 게이트웨이 엔드포인트를 설정해야 합니다.

 

Private Endpoint로 구성

 

내용이 도움이 되시길 바랍니다.

그럼 즐거운 하루 보내세요~!

다음 포스팅에 클러스터 배포 내용을 다루겠습니다.

 

참조 링크 : 

https://repost.aws/questions/QU3 b7 kgBtFSCGtWW88 a3 fiMQ/difference-between-eks-managed-node-group-and-self-managed-node-group

Difference between EKS managed node group and self-managed node group | AWS re:Post

https://awskrug.github.io/eks-workshop/introduction/architecture/cluster_setup_options/

EKS Workshop | EKS Workshop

https://sweetysnail1011.tistory.com/80

[AWS EKS] 57. EKS 개념설명

https://www.cloudthread.io/blog/introduction-to-aws-eks-and-a-comparison-of-fargate-vs-node-groups-pricing

Intro to AWS EKS with Fargate vs Node groups pricing

https://aws.amazon.com/ko/blogs/containers/de-mystifying-cluster-networking-for-amazon-eks-worker-nodes/