메뉴

이 페이지에는 기계 번역이 사용되었습니다. 일부 콘텐츠는 완벽하지 않을 수 있습니다. 개선할 수 있는 방법을 알려주십시오.

피드백 공유

AWS EKS 아키텍처: 클러스터, 노드 및 네트워크

목차

이 페이지 공유하기

Yifat Perry
Yifat Perry

AWS EKS란 무엇입니까?

Amazon Elastic Kubernetes Service(Amazon EKS)는 컨테이너화된 애플리케이션을 확장, 관리, 배포하는 관리형 AWS Kubernetes 서비스입니다. 일반적으로 Amazon 퍼블릭 클라우드에서 실행되지만 온프레미스에도 배포할 수 있습니다. Amazon EKS의 Kubernetes 관리 인프라는 여러 가용 영역(AZ)에 걸쳐 실행됩니다. AWS EKS는 쿠버네티스 준수 인증을 받았으며, 이는 기존 도구와 EKS를 통합할 수 있다는 뜻입니다.

이 문서에서는 다음 내용을 학습합니다:

Amazon EKS는 어떻게 작동합니까?

EKS 클러스터는 컨트롤 플레인과 워커 노드라는 두 가지 주요 구성 요소로 이루어져 있습니다. 각 클러스터는 자체적으로 완벽하게 관리되는 Virtual Private Cloud(VPC)에서 실행됩니다.

컨트롤 플레인은 세 개의 마스터 노드로 구성되며, 각 노드는 AWS 고가용성을 보장하기 위해 서로 다른 AZ에서 실행됩니다. Kubernetes API로 향하는 수신 트래픽은 AWS 네트워크 로드 밸런서(NLB)를 통과합니다.

워커 노드는 AWS가 관리하지 않는 VPC에 위치한 Amazon EC2 인스턴스에서 실행됩니다. 워커 노드에 할당된 VPC를 제어하고 구성할 수 있습니다. 기존 자동화에 접근권을 부여하거나 워커 노드를 프로비저닝하는 데 SSH를 사용할 수 있습니다.

주요 배치 방법은 두 가지가 있습니다. 환경 또는 애플리케이션별로 하나의 클러스터를 배포할 수 있습니다. 또는 IAM 보안 정책과 Kubernetes 네임스페이스를 정의하여 하나의 클러스터를 여러 애플리케이션에 배포할 수도 있습니다.

EKS는 컨트롤 플레인과 클러스터 간의 트래픽을 제한하기 위해 Amazon VPC 네트워크 정책을 제공합니다. Kubernetes 역할 기반 액세스 제어(RBAC)에 의해 정의된 승인된 클러스터 및 계정만 컨트롤 플레인 구성 요소를 보거나 통신할 수 있습니다.

다음 다이어그램은 EKS에 클러스터를 배포하는 프로세스를 보여줍니다. EKS에 클러스터 프로비저닝을 지시하면 클라우드 리소스가 백그라운드에서 프로비저닝되고, 그 후 Kubernetes 클러스터에 연결하여 워크로드를 실행할 수 있습니다.

이미지 출처: AWS

AWS EKS 구성 요소

AWS EKS 아키텍처는 클러스터, 노드 및 네트워킹이라는 주요 구성 요소로 구성됩니다.

Amazon EKS 클러스터

클러스터는 컨트롤 플레인과 EKS 노드로 구성됩니다.


EKS 컨트롤 플레인

컨트롤 플레인은 Amazon에서 관리하는 AWS 계정의 전용 EC2 인스턴스 세트에서 실행되며 애플리케이션에서 액세스할 수 있는 API 엔드포인트를 제공합니다. 단일 테넌트 모드로 실행되며 API Server 및 etcd와 같은 Kubernetes 마스터 노드를 제어하는 역할을 합니다.

etcd의 데이터는 Amazon Key Management(KMS)를 사용하여 암호화됩니다. Kubernetes 마스터 노드는 여러 AWS 가용 영역(AZ)에 분산되어 있으며, 트래픽은 Elastic Load Balancer(ELB)에서 관리합니다.


EKS 노드

Kubernetes 워커 노드는 조직의 AWS 계정 내 EC2 인스턴스에서 실행됩니다. 워커 노드는 인증서 파일을 통해 API 엔드포인트를 사용하여 제어 플레인에 연결합니다. 각 클러스터마다 고유한 인증서가 사용됩니다.

관련 콘텐츠: AWS Kubernetes Cluster: EC2 및 EKS를 사용한 빠른 설정

Amazon EKS 노드

Amazon EKS 클러스터는 세 가지 주요 방법을 사용하여 포드를 예약할 수 있습니다.


자체 관리 노드

EKS에서 '노드'란 Kubernetes 포드를 스케줄링할 수 있는 Amazon EC2 인스턴스입니다. Pod는 EKS 클러스터의 API 엔드포인트에 연결됩니다. 노드는 노드 그룹으로 구성됩니다. 노드 그룹 내 모든 EC2 인스턴스는 다음과 같은 조건을 가져야 합니다:

  • Amazon 인스턴스 유형
  • Amazon Machine Image(IAM)
  • IAM 역할

클러스터에는 여러 노드 그룹이 있을 수 있으며, 각 그룹은 서로 다른 유형의 인스턴스 또는 서로 다른 역할을 가진 인스턴스를 나타냅니다.


관리형 노드 그룹

Amazon EKS는 자동화된 라이프사이클 관리를 포함한 관리형 노드 그룹을 제공합니다. 이를 통해 한 번의 작업으로 노드를 자동으로 생성, 업데이트 또는 종료할 수 있습니다. EKS는 EKS 사용에 최적화된 Amazon의 최신 Linux AMI를 사용합니다. 노드를 종료하면 EKS는 서비스 중단 없이 노드를 안전하게 드레인합니다. 관리 목적으로 전체 노드 그룹에 Kubernetes 레이블을 쉽게 적용할 수 있습니다.

관리되는 노드는 Amazon EKS 서비스가 관리하는 EC2 자동 확장 그룹을 사용하여 운영됩니다. 그룹이 실행될 가용 영역을 정의할 수 있습니다. 관리형 노드 그룹을 실행하는 방법은 EKS 콘솔, eksctl, Amazon CLI, Amazon API, 또는 CloudFormation을 포함한 Amazon 자동화 도구 등이 포함됩니다.


Amazon Fargate

서버 없는 컨테이너 서비스인 Amazon Fargate를 사용해 서버 인프라를 관리하지 않고도 워커 노드를 실행할 수 있습니다. Fargate는 실제로 사용한 vCPU와 메모리에 대해서만 비용을 청구합니다. 클러스터 노드가 실제로 필요로 하는 컴퓨팅 자원에 따라 더 많은 컴퓨팅 자원을 할당합니다.

Amazon EKS 네트워킹

다음 다이어그램은 EKS 클러스터의 네트워크 아키텍처를 보여줍니다.

이미지 출처: AWS

Amazon EKS 클러스터는 Amazon 데이터 센터 내의 안전한 사설 네트워크인 Virtual Private Cloud(VPC)에서 운영됩니다. EKS는 사용자가 선택한 하나의 Amazon 리전 내 VPC에 있는 기존 서브넷에 모든 리소스를 배포합니다.

EKS 제어 평면에서 사용하는 네트워크 인터페이스

EKS 제어 플레인은 아마존이 관리하는 VPC에서 실행됩니다. 사용자가 생성하는 각 EKS 클러스터와 관련된 계정의 네트워크 인터페이스를 생성하고 관리합니다. EC2와 Fargate 인스턴스는 이러한 네트워크 인터페이스를 사용하여 EKS 제어 평면에 연결합니다.

기본적으로 EKS는 공개 엔드포인트를 노출합니다. 클러스터 보안을 강화하려면 프라이빗 엔드포인트를 활성화하거나 특정 IP 주소로 액세스를 제한할 수 있습니다. 온프레미스 네트워크나 다른 VPC와 EKS 클러스터에서 사용하는 VPC 간의 연결을 구성할 수 있습니다.


EKS 노드용 네트워킹

EKS 클러스터에서 사용하는 각 EC2 인스턴스는 하나의 서브넷에 존재합니다. 네트워킹을 정의하는 방법에는 두 가지 옵션이 있습니다.

  • AWS CloudFormation 템플릿을 사용하여 서브넷을 생성합니다. 이 경우 퍼블릭 서브넷의 노드에는 퍼블릭 IP가 할당되고, 서브넷에서 사용하는 CIDR 블록에서 가져온 프라이빗 IP도 할당됩니다.
  • Container Networking Interface(CNI)를 통해 사용자 지정 네트워킹 사용—EC2 인스턴스가 서브넷의 일부가 아닌 경우에도 모든 서브넷에서 Pod에 IP 주소를 할당할 수 있습니다. 노드를 시작할 때 사용자 지정 네트워킹을 활성화해야 합니다.

Cloud Volumes ONTAP를 사용한 AWS EKS 스토리지

NetApp Cloud Volumes ONTAP은 업계 최고의 엔터프라이즈급 스토리지 관리 솔루션으로, AWS, Azure, Google Cloud에서 안전하고 검증된 스토리지 관리 서비스를 제공합니다. Cloud Volumes ONTAP은 최대 368TB 용량을 지원하며, 고가용성, 데이터 보호, 스토리지 효율성, Kubernetes 통합 등 강력한 기능 세트를 바탕으로 파일 서비스, 데이터베이스, DevOps 또는 기타 기업 워크로드와 같은 다양한 사용 사례를 지원합니다.

특히 Cloud Volumes ONTAP은 컨테이너화된 워크로드의 Kubernetes 영구 볼륨 프로비저닝 및 관리 요구사항을 지원합니다.

Drift chat loading