[EKS] AWS EKS의 특징과 Cluster Endpoint 통신 방식

1.  Amazon EKS 란?

• Amazon Elastic Kubernetes Service는 자체 Kubernetes 컨트롤 플레인 또는 노드를 설치, 운영 및 유지 관리할 필요 없이 Kubernetes 실행에 사용할 수 있는 관리형 서비스입니다.

 

1-1) EKS의 특징

• 여러 AWS 가용 영역에 걸쳐 Kubernetes 컨트롤 플레인을 실행하고 크기를 조정하여 높은 가용성을 보장합니다.
• 컨트롤 플레인은 제어 영역 인스턴스의 크기를 자동으로 조정하고, 비정상 제어 영역 인스턴스를 감지하고 교체하며, 자동화된 버전 업데이트 및 패치를 제공합니다.
• 여러 AWS 서비스와 통합할 수 있습니다.
  • 컨테이너 이미지 저장소 Amazon ECR
  • 로드 분산을 위한 ELB
  • 인증 IAM (보안 주체 및 액세스 사용)
  • 노드 격리를 위한 Amazon VPC
• 오픈 소스 Kubernetes 소프트웨어의 최신 버전을 실행하므로 Kubernetes 커뮤니티에서 모든 기존 플러그 인과 도구를 사용가능합니다.
• 필요한 코드를 수정하지 않고 표준 Kubernetes 애플리케이션을 Amazon EKS로 쉽게 마이그레이션가능합니다.
• 지원 버전 : 보통 5~6개의 마이너 버전 지원(현재 1.25~1.29), 평균 3개월마다 새 버전 제공, 처음 14개월 지원, 추가 12개월 연장 지원(비용 추가)

 

1-2) EKS 컨트롤 플레인(Control Plane)

• AWS EKS의 구성요소는 크게 Control Plane과 Data Plane으로 나눠서 볼 수 있습니다.
• 일반 쿠버네티스환경과 비교하면 Master Node, Worker Node라 볼 수 있습니다.
• Control Plane은 AWS에서 관리하는 계정에서 실행되며 Kubernetes API는 클러스터와 연결된 Amazon EKS 엔드포인트를 통해 노출됩니다.
• EKS의 경우 Control Plane은 사용자가 따로 관여하지 않고 운영이 가능하며, kube-apiserver, kube-controller, kube-scheduler, etcd로 구성됩니다.

 

 

 

1-3) EKS 데이터 플레인(Data Plane)

• Data Plane은 사용자가 구성하고 관리할 수 있으며, 여러 배포 방식을 선택해 사용할 수 있습니다.
  • Managed node groups(관리형 노드그룹)
    - 노드의 프로비저닝과 관리를 AWS가 해주는 방식이여서 노드의 업데이트 스케일링 등을 쉽게 가능합니다.
  • Self-managed nodes
    - 사용자가 직접 EC2 인스턴스를 사용하여 노드를 프로비저닝하고 관리하는 방식으로 기업의 거버넌스에 맞게 설정 및 제어가 가능하지만 관리 포인트가 생기게 됩니다.
  • AWS Fargate(서버리스)
    - 서버리스 컴퓨팅 엔진으로 사용자가 서버나 클러스터의 관리 없이 컨테이너를 생행 가능합니다. 사용한 자원에 대해서만 비용을 지불하며, 서버 관리를 따로 신경쓰지 않을 수 있습니다.

 

 

1-4) Control Plane과의 통신 방식

• AWS EKS의 경우 Control Plane은 AWS에서 관리하는 계정에서 실행되며 Data Plane은 사용자의 VPC에서 직접 구성 후 실행됩니다.
• 이처럼 Control Plane과 Data Plane이 서로 다른 VPC에 구성되어 있음에도 통신이 가능한 이유는 EKS Owned ENI라는 네트워크 인터페이스가 존재하며 해당 인터페이스를 통해 Control Plane의 EKS Cluster Enpoint와 통신할 수 있기 때문입니다.

 

• EKS Cluster Endpoint란 Control Plane의 API서버에 접근할 수 있는 제어부로 EKS Cluster를 생성할 때 생성 됩니다.
• EKS Cluster Endpoint는 다음과 같이 3가지 방식으로 생성할 수 있습니다.

 

• Public Enpoint
  
  • 사용자의 kubectl 명령어의 경우 Public IP(NLB)를 통해 Control Plane의 API 서버에 요청 후 EKS owned ENI 를 통해 Data Plane의 kubelet을 사용합니다.
  • kubelet이 작업을 수행하고 Data Plane의 상태를 Control Plane의 API서버로 보고하게 되는데 이 통신을 Public IP(NLB)로 전송합니다.

• Public / Private Enpoint
  • 사용자의 kubectl 명령어의 경우 Public IP(NLB)를 통해 Control Plane의 API 서버에 요청 후 EKS owned ENI 를 통해 Data Plane의 kubelet을 사용합니다.
  • kubelet이 작업을 수행하고 Data Plane의 상태를 Control Plane의 API서버로 보고하게 되는데 이 통신을 AWS 내부의 Private hosted zone을 통해서 EKS owned ENI를 통해 Control Plane으로 전송합니다.

• Private Endpoint
  • 사용자의 kubectl 명령어의 경우 위의 두가지 방식과는 다르게 외부에서 사용하지 못하며, 해당 VPC내에서만 사용이 가능합니다. Private hosted zone을 통해 EKS owned ENI를 걸쳐 Control Plane의 API서버로 요청을 보냅니다.
  • kubelet이 작업을 수행하고 Data Plane의 상태를 Control Plane의 API서버로 보고하게 되는데 이 통신을 AWS 내부의 Private hosted zone을 통해서 EKS owned ENI를 통해 Control Plane으로 전송합니다.

 

 

 

2. EKS 배포 및 Cluster Endpoint 통신 테스트

• EKS 배포 방식은 AWS Console, eksctl, IaC 를 통해 배포가 가능합니다.
• 해당 문서에서는 Terraform을 통한 IaC방식으로 배포합니다. 

 

2-1) EKS 배포

• EKS Cluster 을 Terraform Code로 다음과 같이 작성하였습니다.
• EKS Cluster Endpoint의 경우 Public/Private Enpoint로 생성하여 테스트를 진행합니다.

 

 

• EKS Node는 관리형 노드그룹으로 생성테스트 할 예정이며 다음과 같이 Terraform Code로 작성하였습니다.

 

 

• 배포 후 정상적으로 Cluster Endpoint가 Public/Private Enpoint로 생성되었는지 확인합니다.

 

 

• AWS VPC CNI 사용 확인

 

 

• coredns 및 kube-proxy 확인

 

 

• node 생성 확인

 

 

• EKS owned ENI 확인

    - 관리형 노드 그룹으로 생성하였기 때문에 워커노드의 경우 사용자인 내가 소유자이지만, 연결된 ENI(NIC)의 인스턴스(관리형 노드)는 AWS의 소유인 것을 확인 가능합니다.