EKS 기본 아키텍처

EKS

AWS EKS(Elastic Kubernetes Service)는 Kubernetes 컨트롤 플레인(Control Plane)과 노드를 제공하는 AWS의 관리형 쿠버네티스 서비스다. '관리형 서비스'라고 하는 것은 기본적으로 쿠버네티스의 컨트롤 플레인 영역을 AWS에서 직접 운영하고 관리해주는 것을 의미한다.

EKS는  IAM(Identity and Access Management)과 쿠버네티스 사용자를 연결하여 IAM을 기반으로 권한을 관리할 수 있는 기능이나 파드 네트워크와 AWS VPC의 서브넷이 직접 연결되어 가상 머신에서 컨테이너로 직접 통신할 수 있는 네트워크 구성이 가능하다. 일반적으로 AWS가 제공하는 AMI(Amazon Machine Image)에서 생성한 EC2 인스턴스를 쿠버네티스 노드로 사용한다.

 

Kubernetes

쿠버네티스는 컨테이너화된 애플리케이션의 배포, 확장 등을 관리하는 것을 자동화하기 위한 플랫폼(컨테이너 오케스트레이션 엔진)이다. 컨테이너 런타임 중 하나인 도커를 동시에 여러 호스트로 구성하여 중앙에서 통합, 관리할 수 있다. 컨테이너 오케스트레이션 엔진에는 도커 스웜, 아파치 메소스(Apache Mesos) 등이 있지만, 최근 서비스 환경에서 가장 많이 사용되고 있는 것은 쿠버네티스이며 컨테이너 오케스트레이션을 위한 사실상의 표준이 되어가고 있다.

 

쿠버네티스 장점

컨테이너 오케스트레이션 엔진인 쿠버네티스는 다음 특징이 있다.

• 선언적 코드를 사용한 관리(IaC)
  • YAML 형식이나 JSON 형식으로 작성한 선언적 코드(매니페스트)를 통해 배포하는 컨테이너로 주변 리소스를 관리할 수 있어 IaC(Infrastructure as Code)를 구현할 수 있다.
• 스케일링/오토 스케일링
  • 컨테이너 클러스터(쿠버네티스 클러스터)를 구성하여 컨테이너 이미지 기반 애플리케이션을 파드 단위로 배포하면 부하 분산 및 다중화 구조를 만들 수 있다.
  • 부하에 따라서 컨테이너 레플리카 수를 자동으로 늘리거나 줄일 수 있다.
• 스케줄링
  • 어피니티(Affinity)와 안티어피니티(Anti-Affinity) 기능을 사용하여 쿠버네티스 노드에 배포할 때 어느 노드에 배포할 것인지를 결정하는 스케줄링 기능을 지원한다.
  • 예를 들어, 디스크 I/O가 많은 컨테이너를 디스크가 SSD인 노드에 배치하는 제어가 가능하다.
• 리소스 관리
  • 컨테이너 배치를 위한 지정이 특별히 없는 경우 노드의 CPU나 메모리의 여유 리소스 상태에 따라 스케줄링되기 때문에 사용자는 배치에 신경쓸 필요가 없다.
• 자동화된 복구
  • 자동화된 복구 기능(self-healing)을 지우너하여 컨테이너 프로세스를 모니터링하고 정지를 감지하면 컨테이너 스케줄링을 실행하여 컨테이너를 자동으로 재배포한다.
• 로드 밸런싱
  • 로드 밸런서 기능(Service 또는 Ingress)을 제공하여 사전에 정의한 조건과 일치하는 컨테이너 그룹에 라우팅하는 엔드포인트를 할당할 수 있다.
• 데이터 관리
  • 백엔드 데이터 스토어로 etcd를 채용하여 컨테이너가 사용하는 설정 파일이나 인증 정보 등의 데이터를 저장한다.
  • 모니터링하는 Prometheus, 컨테이너 로그 전송하는 Fluentd 등의 미들웨어를 사용하여 기능을 확장할 수 있다.

 

컨트롤 플레인(Control Plane)

컨트롤 플레인은 쿠버네티스 마스터로 API 엔드포인트 제공, 컨테이너 스케줄링, 컨테이너 스케일링 등을 담당한다. 쿠버네티스 마스터에 매니페스트 파일을 사용하여 API에 요청을 보내어 '리소스'를 등록한다. 이 리소스는 주로 Pod, Service, Deployment, ConfigMap 등이며, 컨트롤 플레인은 해당 정보를 바탕으로 상태를 지속적으로 감시하고 조장한다.

사용자가 컨트롤 플레인으로 API 요청을 하면 다음 과정을 통해 자동화된 인프라 관리 환경을 제공한다.

1. API 서버를 통해 리소스를 등록한다.
2. 스케줄러가 적절한 노드에 Pod를 배치한다.
3. 컨트롤러 매니저가 지속적으로 상태를 감시하고 수정한다.

컨트롤 플레인의 구성 요소를 다음과 같다.

• kube-apiserver: 모든 요청의 진입점으로 etcd와 직접 통신하여 클러스터 상태 조회 및 변경
• kube-controller-manager: ReplicaSet, Node, Service 등 다양한 컨트롤러를 포함하여 실제 상태와 원하는 상태 간의 차이를 감지하고 조정
• kube-scheduler: 새로 생성할 Pod를 자원 요구사항, 제약 사항 등을 고려하여 가장 적합한 Node에 배치
• etcd: 모든 리소스의 상태 저장(Pod, Node, Config 등)하고, api server가 접근 가능

 

EKS 컨트롤 플레인 아키텍처

Amazon EKS 컨트롤 플레인은 쿠버네티스 클러스터의 노드를 제어하기 위한 핵심 컴포넌트들을 AWS 환경에 구성하고 관리해 주는 영역이다. 즉, 쿠버네티서 API 서버, 컨트롤러, 스케줄러, etcd 같은 컴포넌트들이 AWS 환경에서 구성된다.

위 그림에서 확인할 수 있듯이 Amazon EKS 클러스터를 생성하면 컨트롤 플레인을 배치하기 위한 용도로 사용자의 계정이 아닌 AWS 관리용 VPC가 생성된다. 그 안에 여러 가용 영역에 걸쳐 API 서버, 스케줄러, 컨트롤러, etcd 등의 컴포넌트들이 배치되고, AutoScaling Group으로 묶어 지속적이고 안정적인 상태를 유지할 수 있도록 설정되어 있다. 또한, 여러 가용 영역에 자원이 분산되어 있는 만큼, LNB(Network Load Balancer)를 활용해 트래픽을 효율적으로 분산시킨다.

이 모든 컨트롤 플레인의 구성과 운영을 AWS에서 대신 수행하고 관리해 주기 때문에 AWS 관리형 쿠버네티스 서비스라고 하는 것이다. 그리고 컨테이너 이미지 저장소인 Amazon ECR, 부하 분산을 담당하는 Amazon ELB, 보안 주체 및 액세스 사용하는 서비스인 AWS IAM, 노드 격리인 Amazon VPC 등 다양한 AWS 서비스와 통합하여 확장성과 보안성을 제공한다.

 

 

데이터 플레인(Data Plane)

데이터 플레인은 쿠버네티스 워커 노드를 구성하는 영역으로 컨테이너화된 애플리케이션(Pod)이 실제로 동작하고, 네트워크 트래픽을 처리하는 영역이다. 주로 노드(worker node), kubelet, 컨테이너 런타임, CNI 플러그인이 데이터 플레인 구성 요소에 포함된다. 데이터 플레인 구성 요소 설명은 다음과 같다.

• kubelet: 컨트롤 플레인의 API 서버와 통신하며, 노드 내 리소스를 관리
• 컨테이너 런타임(containerd): 실제 컨테이너를 생성, 실행, 삭제 등 수행
• kube-proxy:  Service 객체를 위한 트래픽 라우팅을 담당하여 각 Pod으로 네트워크 트래픽을 전달
• CNI 플러그인: 네트워크 인터페이스를 생성하고 Pod 간 통신을 설정
• 스토리지 드라이버(CSI): 외부 볼륨과 연결하여 Pod가 데이터를 읽고 쓰도록 지원

 

EKS 데이터 플레인 아키텍처

 컨트롤 플레인과 달리 사용자 VPC에 생성되며, 관리형 노드 그룹(Managed Node Group) 내 각 인스턴스에 kubelet, kube-proxy, 컨테이너 런타임, 파드와 같은 컴포넌트가 배치된다.

워커 노드에 위치한 kubelet이 컨트롤 플레인의 API 서버와 통신하기 위해 EKS owned ENI를 사용하여 양쪽에서 안정적으로 통신할 수 있다. 이 ENI는 소유자와 연결 대상이 서로 다른 AWS 계정에 속해 있기 때문에 Cross Account ENI라고 부르기도 한다.

 

Amazon VPC CNI

쿠버네티스 클러스터를 생성하면 각 노드에 파드(Pod)가 배포될 수 있도록 내부 네트워크가 자동으로 설정된다. 이 네트워크 구성은 CNI(Container Network Interface)라는 플러그형 모듈 구현에 의해 정의되며, 노드 간 통신이 기본적으로 가능하도록 구성된다.

CNI는 컨테이너 간의 네트워크 연결을 표준화하기 위한 CNCF(Cloud Native Computing Foundation)의 공식 프로젝트로, 다양한 컨테이너 런타임(Docker, containerd 등)과 오케스트레이션 도구(Kubernetes 등) 사이의 네트워크 계층을 추상화하고 연결해주는 역할을 한다.

즉, CNI를 통해 파드는 각기 다른 노드에 배치되더라도 IP 기반의 일관된 통신 환경을 유지할 수 있으며, 이는 클러스터 내에서의 서비스 간 연결성과 확장성을 보장하는 핵심적인 요소이다. Amazon EKS는 Amazon VPC CNI 플러그인을 통해 클러스터 네트워킹 환경을 구성하여 다음 특징이 있다.

• Amazon VPC와 통합된 네트워킹 환경을 구성할 수 있다.
• VPC Flow Logs, 라우팅 정책, 보안 그룸 등 다양한 VPC 서비스와 통합하여 사용할 수 있다.
• 파드와 노드는 동일한 IP 대역을 할당할 수 있다.
• Amazon VPC CNI는 오픈 소스로 개발되며, Github에서 활발하게 유지 및 관리되고 있다.

 

Amazon VPC CNI 플러그인 동작 과정

출처: https://docs.aws.amazon.com/eks/latest/best-practices/vpc-cni.html

Amazon VPC CNI는 EKS 환경에서 파드에 직접 VPC의 ENI와 IP를 할당해 네트워크 성능과 관리 

 

 

Amazon EKS 환경에서 Amazon VPC CNI 플러그인은 파드에 직접 ENI를 연결하여, 파드 간 통신을 VPC 수준에서 처리할 수 있도록 설계된 네트워크 구성 모듈이다. Amazon VPC CNI 플러그인을 설치하면, 노드마다 "aws-node"라는 이름의 데몬셋(DaemonSet)이 생성된다. aws-node 데몬셋은 L-IPAM(Local IP Address Manager)과 CNI 플러그인 두 구성으로 나뉘어 gRPC 프로토콜을 통해 통신해서 주로 IP 주소를 추가하거나 삭제하는 역할을 한다. 즉, L-IPAM의 Warm Pool에서 IP를 가져와 ENI의 Secondary IP를 파드에 할당하고, VPC의 IP 대역을 그대로 사용하기 때문에 노드와 파드 모두 동일한 IP 대역에 존재한다.

위 그림에서 확인할 수 있듯이 전체 흐름은 다음과 같다.

1. API Server로부터 파드 생성 요청 수신(kubelet이 감지)
2. kubelet은 VPC CNI에게 IP 요청 전달
3. VPC CNI는 gRPC 프로토콜을 통해 L-IPAM에게 IP 요청 전송
4. ENI에 할당된 Secondary IP를 관리하는 L-IPAM은 Warm Pool 내에서 사용 가능한 Secondary IP를 선택해 반환
5. VPC CNI는 해당 IP로 네트워크 네임스페이스(NS) 및 iptables 설정
6. IP 설정이 완료되면, 파드에 IP를 할당한 후 kubelet에게 결과 전달
7. 파드는 ENI를 통해 직접 VPC 네트워크에 참여

 

위 과정 중에 새로운 파드를 생성해야 하는데, 현재 연결된 ENI의 Secondary IP가 모두 사용 중이라면 추가적인 ENI를 노드에 연결하고, 그 ENI의 Slot에 IP를 매핑해서 파드에 IP 주소를 할당할 수 있다. 인스턴스 유형별로 ENI의 최대 개수도 제한되어 있기 때문에 결국 할당 가능한 파드 수에도 한계가 생길 수 있다.

 

K8S 실습

 

EKS 기본 클러스터 및 노드 그룹 아키텍처 확인

EKS 클러스터 아키텍처

EKS 클러스터를 생성하면, 컨트롤 플레인 자원이 AWS 관리용 VPC에 구성되기 때문에 AWS 자원들을 생성하기 위해 IAM 역할을 생성하고 연결한다. 클러스터 엔드포인트 액세스를 퍼블릭으로 구성하여 인터넷 구간에서 접근이 가능하도록 설정한다.

각 가용 영역에는 컨트롤 플레인의 핵심 자원인 API 서버, 컨트롤러, 스케줄러, etcd가 생성된다. 트래픽 부하를 분산하기 위해 ELB 및 ASG(AutoScaling Group)도 함께 생성된다. 이처럼 Amazon EKS는 AWS가 컨트롤 플레인을 직접 관리해주는 관리형 Kubernetes 서비스라고 할 수 있다.

 

EKS 노드 그룹 아키텍처

노드 그룹이 생성되면, 노드 인스턴스가 사용자 VPC에 생성이 된다. 생성된 노드는 오토스케일링 그룹을 통해 자동으로 구성되고, 필요 시 자동으로 확장되거나 축소되며 유지된다. 그리고 데이터 플레인 구성 요소인 pod, kubelet, kube-proxy 등이 노드별로 구성이 된다. 또한, API 서버와 노드 간의 통신을 위해 eks-owned ENI라는 네트워크 인터페이스가 자동으로 연결된다.

 

 

IAM 역할 생성

 

EKS 클러스터 IAM 역할 생성

EKS 클러스터 생성 전에 IAM 역할이 필요하다. 먼저, EKS 클러스터 IAM 역할을 생성 후 다음 작업을 진행해야 한다. 사용 사례에서 Auto Scaling, EC2, ELB 등을 제어할 수 있는 권한이 포함된 [EKS - Cluster]를 선택한 후 AmazonEKSClusterPolicy를 확인한 후 역할 이름을 지정하여 역할을 생성한다.

 

EKS 노드 IAM 역할 생성

클러스터를 생성하고 난 후 Amazon EKS 노드 생성 전에 IAM 역할이 필요하다. 먼저, EKS 노드 IAM 역할을 생성한 후 다음 작업을 진행할 수 있다. 위 사진처럼 EKS 노드 관련 권한을 포함한 eksNodeRole 역할을 생성한다.

 

클러스터 생성

 

1단계: 클러스터 구성

• EKS 자율 모드 영역에 EKS 자유 모드 사용은 [해제]로 설정한다.
• 클러스터 구성 영역에 이름은 myeks로 입력한다.
• 클러스터 구성 영역에 클러스터 IAM 역할은 위에서 생성한 eksClusterRole을 선택한다.

2단계: 네트워킹 지정

• 네트워킹 영역에 VPC는 기본값으로 선택한다.
• 서브넷은 4개 중 2개만 선택한다.
• 클러스터 엔드포인트 액세서는 퍼블릭으로 설정한다.
• 3, 4, 5단계는 따로 수정하지 않고, 다음을 클릭한 후 클러스터를 생성한다.

 

EKS 노드 생성

 

1단계: 노드 그룹 구성

• 컴퓨팅 탭에서 노드 그룹 영역에서 [노드 그룹 추가] 버튼을 클릭한다.
• 노드 그룹 구성 영역에 이름을 myeks-nodegroup으로 입력한다.
• 노드 그룹 구성 영역에 노드 IAM 역할을 eksNodeRole로 선택한다.

2단계: 컴퓨팅 및 조정 구성 설정

• 노드가 생성될 인스턴스의 AMI는 Amazon Linux 2023이고, 인스턴스 유형은 t3.medium이다.
• 스토리지는 EBS 200GiB이고, 온디맨드 유형으로 구성된다.
• 노드 그룹 조정 구성에서 오토스케일링 그룹 설정(원하는 크기, 최소 크기, 최대 크기)을 확인할 수 있다.

3단계: 네트워킹 지정

• EKS 클러스터에서 설정한 퍼블릭 서브넷 2개가 자동으로 지정된 것을 확인할 수 있다.
• 노드 그룹 네트워크 구성 영역에 노드에 대한 원격 액세스 허용을 체크하고 활성화 버튼을 클릭한다.
• 노드 그룹 네트워크 구성 영역에서 EC2 키 페어는 자신의 키 파일을 선택한다.
• 노드 그룹 네트워크 구성 영역에 보안 그룹은 본인의 보안 그룹을 선택한다.
• 다음 버튼을 클릭하고, 4단계에서 생성 버튼을 클릭한다.

 

클러스터 생성 확인

쿠버네티스 클러스터가 생성되고 쿠버네티스 기본 서비스가 정상적으로 출력된 것을 확인할 수 있다.

 

노드 그룹 생성 확인

노드 그룹 확인

 

노드 그룹 내 인스턴스 확인

노드 그룹에서 생성한 ASG

쿠버네티스 버전은 1.33이고, AMI는 Amazon Linux 2023, 인스턴스 유형은 t3.medium인 인스턴스가 생성된 것을 확인할 수 있다.

 

기본 네트워크 환경 확인

kube-system 네임스페이스는 쿠버네티스 클러스터 내부에서 데이터 플레인 핵심 구성 요소가 실행되는 기본 네임스페이스이다. VPC CNI 플러그인이 설치된 환경에서 노드별로 구성된 DaemonSet 정보를 확인하면 각각의 워커 노드 2대에 "aws-node"와 "kube-proxy"가 데몬셋 형태로 설치된 것을 확인할 수 있다.

오른쪽 사진을 통해 노드의 네트워킹을 담당하는 kube-proxy 설정 정보를 확인하면 mode가 iptables인 것을 확인할 수 있다. kube-proxy는 userspace, ipvs, iptables 세 가지 모드를 지원하고, 모드에 따라 네트워크 동작 방식이 달라진다. Amazon VPC CNI 환경에서는 기본적으로 iptables 모드를 사용하기 때문에 kube-proxy가 방화벽처럼 작동하며, 리눅스 커널에서 패킷의 흐름을 조건에 따라 허용하거나 차단하는 규칙을 설정하는 iptables를 직접 제어한다는 것을 알 수 있다.

 

 

 

 

 

출처

CloudNet@와 함께하는 Amazon EKS 기본 강의

쿠버네티스 완벽 가이드