블로그 릴레이 - 콘솔에서 EKS 클러스터와 노드 그룹을 생성할 때 나오는 요소들에 대해

안녕하세요! 클래스메소드의 이수재입니다.

본 블로그는 당사의 한국어 블로그 릴레이의 2025년 27번째 블로그입니다.
이번 블로그의 주제는「콘솔에서 EKS 클러스터와 노드 그룹을 생성할 때 나오는 요소들에 대해」입니다.

k8s 스터디를 하며 EKS 에서 클러스터와 노드를 생성하고 포드를 배치하는 작업이 있었습니다.
콘솔에서 작업을 진행하면서 나오는 요소들에 대해 정리했던 내용을 블로그로도 작성해보겠습니다.

클러스터 구성 단계

클러스터 생성은 콘솔, eksctl, aws-cli(API)로 생성할 수 있습니다.
이 글에서는 콘솔로 생성하는 것을 전제로 합니다.

클러스터는 빠른 구성 혹은 사용자 지정 구성으로 생성할 수 있습니다.^[1]

이 글에서는 아래 이미지에서 검은색 박스가 되어 있는 부분에 대해 설명합니다.

EKS 자율 모드(auto mode)

자율 모드는 EKS의 컴퓨팅 리소스를 AWS가 자동으로 관리해주는 기능입니다.
클러스터를 AWS가 관리해주며 단순히 노드와 인스턴스의 관리 뿐만이 아닌 사용하는 AMI, 인스턴스의 패치, 인스턴스 유형 등을 모두 AWS가 조절하게 됩니다.

정확히는 다음과 같은 기능을 AWS에서 관리하게 됩니다.

• 애플리케이션 로드 밸런싱
• 블록 스토리지
• 컴퓨팅 Auto Scaling
• GPU 지원
• 클러스터 DNS
• 포드 및 서비스 네트워킹

자율 모드에 대한 상세한 내용은 아래 글을 참고해주세요.

• EKS Auto Mode에 대해
• EKS Auto Mode는 무엇이고 왜 출시되었을까?
• EKS 자율 모드 설정 구성
• Amazon EKS 자율 모드 관리형 인스턴스에 대해 알아보기

자율 모드를 사용할지는 제어 권한과 운용 부담 경감의 트레이드 오프라고 생각합니다.
도입하게 되면 운용 부담이 매우 낮아지기 때문에 서비스의 배포만 신경쓰면 됩니다.
하지만 세세한 부분은 제어할 수 없게 됩니다.

따라서 배포할 워크로드가 복잡한 설정이 불필요하거나 EKS는 잘 모르지만 k8s의 도입을 검토해보는 단계라면 도입해보는 것을 검토해볼 수 있다고 생각합니다.

클러스터 IAM 역할

권장 역할로 생성하는 경우 AWS 관리형 정책인 AmazonEKSClusterPolicy 가 설정된 IAM 역할이 생성됩니다.

Kubernetes 버전 설정

EKS 는 k8s에서 어떠한 버전이 출시되면 14개월 동안은 무료로 지원해줍니다.
정책 업그레이드를 표준으로 사용하는 경우 14개월이 지나면 자동으로 다음 버전으로 업데이트 됩니다.
확장됨(Extended)를 선택하면 최대 26개월 까지 해당 버전을 사용할 수 있습니다.
단, 15개월 째 부터 비용이 발생합니다.
26개월이 지나면 자동으로 업데이트 됩니다.

빈번한 업데이트를 피하고 싶은 경우 확장을 검토해볼 수 있습니다.
다만 가능한 최신 버전을 이용하는 것을 권장하고 있습니다. ^[2]

클러스터 액세스

부트스트랩 클러스터 관리자 액세스는 해당 클러스터를 만드는 IAM 주체가 k8s 내부의 관리자 역할도 겸하는지 확인하는 설정입니다.
이 설정은 클러스터 생성시에 설정할 수 있으며 이후 변경이 불가능합니다.
기본 값으로 EKS 클러스터를 생성하면 클러스터를 생성하는 페더레이션 사용자와 같은 IAM 엔터티 사용자 또는 역할에 클러스터의 RBAC 구성에 대한 system:masters 권한이 자동으로 부여됩니다.
이 액세스는 제거할 수 없으며 aws-auth ConfigMap을 통해 관리되지 않습니다. ^[3]

• 참고 : AWS EKS에서 Kubernetes 클러스터에 사용자 추가하기

만약 클러스터를 생성한 IAM 엔티티를 클러스터 관리자로 사용하고 싶지 않은 경우 "액세스 허용 안함" 을 선택해야합니다.
액세스와 관련해서 EKS의 보안 권장 사항이 있으므로 참고하는 것이 좋습니다.

• 공식 문서 : ID 및 액세스 관리 - Amazon EKS

인증 모드

클러스터가 보안 주체에 사용할 소스를 선택하는 옵션으로 API 또는 API_AND_CONFIG_MAP 이 있습니다.

설정의 변경은 단방향입니다.
API_AND_CONFIG_MAP에서 API로 변경할 수 있지만 API로 변환한 후에는 CONFIG_MAP 또는 API_AND_CONFIG_MAP으로 돌아갈 수 없습니다.
마찬가지로 API_AND_CONFIG_MAP에서 CONFIG_MAP으로 변경할 수 없습니다 ^[4]

• 참고 : [AEKS2] 6주차 - EKS Security: EKS API 인증 모드

봉투 암호화

k8s 1.28 이후 부터 API 데이터를 봉투 암호화하기 시작하였습니다.
봉투암호화라는 암호화 기법 자체는 아래 글이 이해가 잘 되었습니다.

• [암호화 기법] 봉투 암호화 (Envelope encryption)

기본 값은 aws 관리형 키를 사용하는 것입니다.
필요에 따라 사용자 관리형 키를 사용할 수 있습니다.

ARC 영역(Amazon Application Recovery Controller) 전환

여러 가용 영역에서 EKS 클러스터를 실행하는 경우 ARC를 활성화하는 것으로 손상된 가용 영역에서 정상 동일한 리전의 정상 가용 영역으로 트래픽을 보낼 수 있습니다.

ARC를 활성화하면 가용성의 확보, 운용 절차의 자동화(=복구 작업 발생 시의 자동화) 등을 구현할 수 있지만 사전 환경의 준비, 운용 레벨의 상승 등을 고려해야합니다.

• 공식 문서 : Amazon EKS에서 Amazon 애플리케이션 복구 컨트롤러(ARC)의 구역 이동에 대해 알아보기
  • 도입 전에 이 문서의 내용들에 대해 검토해보는 것을 권장합니다.

네트워킹 지정 단계

아래 항목들에 대하여 보충한 내용입니다.

네트워킹

권장 사항으로는 프라이빗 서브넷만을 사용하는 것을 권장하고 있습니다.
컨트롤 플레인이 ENI를 배치할 서브넷을 선택하는 것으로 클러스터 엔드포인트와는 상관없이 프라이빗 서브넷에만 구성해도 문제 없습니다.

Kubernetes 서비스 IP 주소 블록 구성

기본적으로는 자동 할당된 IP 범위를 이용해도 문제 없습니다.
단, 다른 VPC와 피어링, 다른 클러스터와 통신 등 클러스터 뿐만 아닌 다른 네트워크와도 통신하는 경우 CIDR가 중복되면 통신이 실패할 가능성이 있으므로 필요에 따라 사전에 검토하는 것을 권장합니다.

하이브리드 노드를 활성화하도록 원격 네트워크 구성

기존 온프레미스 환경에서 k8s를 사용하고 있고 EKS로 확장하는 경우 하이브리드 노드를 도입할 수 있습니다.
장점으로는 컨트롤 플레인의 관리를 EKS에 맡기고 워커 노드만 온프레미스/클라우드 환경에서 운용하여 온프레미스 환경의 리소스를 그대로 활용할 수 있다는 점입니다.
단점으로는 레이턴시, 구성, 하이브리드에 최적화 된 스케일링 등 사전에 검토해야하는 내용들이 있다는 점입니다.

하이브리드 구성의 경우 이전에는 EKS on AWS Outposts 및 EKS Anywhere 등이 많이 사용되어 왔습니다.
서비스 비교는 아래 글을 참고해주세요.

• 🧑‍💻 Amazon EKS Hybrid Nodes: EKS 하이브리드 노드를 리뷰합니다

클러스터 엔드포인트 액세스(클러스터 API 서버 엔드포인트)

EKS의 API 서버는 사용자가 관리하지 않고, AWS 관리형 VPC에 API 서버가 배치됩니다.

이 클러스터의 API 서버 엔드포인트를 어떻게 구성할지 선택하는 항목입니다.

퍼블릭
API 서버에 공개된 IP 를 부여하고 사용자는 이 IP를 통하여 API 서버를 조작할 수 있습니다.
API 서버가 공개되어있기 때문에 보안 리스크가 있습니다.

API 서버에서 워커 노드로 명령을 전달할 때는 클러스터 내부의 EKS owned ENI 를 통해 워커 노드의 kubectl에 전송됩니다.
이후 API 서버의 명령을 워커 노드에서 처리한 후 결과를 전송할 때 네트워크 내부에서 처리하는 것이 아닌 인터넷 게이트웨이나 NAT 게이트웨이를 통해 네트워크 외부에서 전송하게 됩니다.
즉, API 서버의 명령을 받을 때도 워커 노드의 처리 결과를 보낼 때도 외부를 통하게 됩니다.

퍼블릭 및 프라이빗
퍼블릭과 거의 동일하지만 API 서버의 명령을 처리한 후 워커 노드에서 결과를 전송할 때 외부 네트워크가 아닌 Private Host Zone을 이용하여 내부 EKS owned ENI로 결과를 전송합니다.

프라이빗
API 서버에 요청을 하기 위해서는 사용자의 VPC에서 접근이 필요합니다.
따라서 외부 인터넷에서 접근하는 것은 불가능해집니다.

표로 비교하자면 다음과 같습니다.

참고 자료 : [EKS] AWS EKS의 클러스터 엔트포인트란? Public, Private, Private + Public

관찰성 구성 단계

지표

Prometheus
시계열 지표를 수집하고 집계하기 위한 오픈 소스 모니터링 툴킷(=모니터링 툴)입니다.
다만 EKS에서 설정하는 프로메테우스는 일반적으로 사용하는 프로메테우스와는 조금 다릅니다.
CNCF Prometheus 프로젝트를 기반으로 하며 서버리스로 운영되기 때문에 유저가 별도로 관리할 필요가 없습니다.
그리고 지표의 볼륨에 따라서 자동으로 확장되므로 운영 난이도가 낮아진다는 장점이 있습니다.

참고

• Prometheus란?. 오픈소스 모니터링 툴 Prometheus에 대해서 알아보자. | by ShinChul Bang | finda 기술 블로그
• Amazon Managed Service for Prometheus FAQs
• Amazon Managed Service for Prometheus란?

CloudWatch
EKS의 애플리케이션/인프라 지표를 CloudWatch나 Container Insight에서 확인하려면 활성화 해야합니다.(이후 변경 가능)

컨트롤 플레인 로그
k8s의 컨트롤 플레인의 각 요소에 관한 로그를 CloudWatch로 전송하고 싶은 경우 활성화하면 됩니다.

• API 서버
  • 클러스터에 대한 API 요청과 관련된 로그입니다.
• 감사
  • Kubernetes API를 통한 클러스터 액세스와 관련된 로그입니다.
• Authenticator
  • 클러스터에 대한 인증 요청과 관련된 로그입니다.
• 컨트롤러 관리자
  • 클러스터 컨트롤러 상태와 관련된 로그입니다.
• 스케줄러
  • 예약 결정과 관련된 로그입니다.

상세한 내용은 공식 문서를 참고해주세요.

추가 기능 선택 단계

EKS 운영을 위해 필요한 애드온을 클러스터를 생성하는 타이밍에 같이 설정할 수 있습니다.

AWS 에서 제공하는 애드온, 커뮤니티의 애드온, 마켓플레이스의 애드온으로 나뉘어져 있습니다.

AWS 애드온

AWS 에서 제공하는 애드온은 AWS 에서 보안 패치나 업데이트를 관리하고 있습니다.

AWS 제공 애드온에서 아래의 애드온은 기본으로 선택되어 있습니다.

• CoreDNS
  • Kubernetes 클러스터 내부의 DNS 서비스를 제공
  • 클러스터의 모든 Pod와 서비스 간 이름 해석(Name Resolution)을 담당
• kube-proxy
  • Amazon EC2 노드의 네트워크 규칙을 유지하고 포드와의 네트워크 통신을 활성화
  • Kubernetes 클러스터 내 서비스의 네트워크 라우팅을 처리
  • 참고 : [k8s network] kube-proxy 란? kube-proxy 역할
• Amazon VPC CNI
  • Amazon VPC와 통합되어 k8s Pod가 VPC의 네트워크 인터페이스를 직접 사용하도록 지원.
  • AWS ENI를 생성하여 Amazon EC2 노드에 연결함
  • 포드에서 VPC 네트워크에서와 마찬가지로 포드 내 동일한 IP 주소를 보유하게 됨
• 노드 모니터링 에이전트
  • 노드의 로그를 읽어 문제를 탐지하기 위해 사용
• EKS Pod Identity Agent
  • 포드에 IAM 권한을 부여해야하는 경우 사용
  • EC2에 인스턴스 프로파일을 지정할
  • 참고 : EKS Pod Identity가 포드에 AWS 서비스에 대한 액세스 권한을 부여하는 방법 알아보기

이외에 다른 애드온은 필요에 따라 설정하면 됩니다.(EBS, EFS, S3 MountPoint 등)

다른 애드온에 대해서는 아래 글들을 참고해주세요.

• [AWS] EKS Add-on
• Amazon EKS 추가 기능
• Amazon EKS 클러스터에 대한 네트워킹 추가 기능 관리

추가 기능 구성 설정 구성
애드온에 따라 IAM 역할이 필요한 경우도 있습니다.
AWS 관리 애드온이라면 권장 역할을 생성할 수 있지만 다른 방식의 애드온인 경우 확인이 필요합니다.

여기까지 설정 후 설정한 값을 확인하고 문제가 없다면 클러스터를 생성합니다.

kubeconfig 업데이트

eksctl로 클러스터를 생성한 경우에는 건너뛸 수 있지만 이외의 방법으로 생성한 경우 kubeconfig 파일을 수정하여 사용할 클러스터가 무엇인지 지정하는 내용의 업데이트가 필요합니다.

공식 문서에서 안내하는 방법으로는 아래 커맨드를 실행하는 방법입니다.

$ aws eks update-kubeconfig --region {리전} --name {클러스터 이름}
Added new context arn:aws:eks:ap-northeast-1:565120480879:cluster/test_policy to /Users/lee.sujae/.kube/config

위의 명령어는 $HOME/.kube 에 위치한 config 파일에서 context(컨텍스트) 를 수정하는 커맨드입니다.
컨텍스트란 사용할 접속 매개변수를 지정하는 요소로 명렁어를 어느 클러스터에서 누가 실행할지를 지정하는 매개변수라고 보면 됩니다.

명령어를 실행하고 $HOME/.kube/config 의 내용을 보면 현재 사용중인 컨텍스트가 클러스터의 arn으로 지정되어 있는것을 확인할 수 있습니다.

kubectl 명령어를 실행할 때 KUBECONFIG 환경 변수가 있으면 환경 변수에 등록된 컨텍스트를 우선으로 사용합니다.
환경 변수가 없다면 config 파일에 지정되어있는 컨텍스트를 사용합니다.

혹은 k8s를 운영하는 경우 kubectx와 같은 툴을 이용하는 것도 좋습니다.

• kubectx, kubens (Kubernetes 유용한 도구)[Secuof Blog:티스토리]

파일을 업데이트한 후 되었다면 클러스터와 통신을 확인합니다.

kubectl get svc

컨텍스트를 변경하고 싶다면 아래 명령어 실행하면 됩니다.

kubectl config use-context {컨텍스트 이름}
Switched to context "rancher-desktop"

컨텍스트를 삭제하고 싶은 경우에는 아래 커맨드를 실행합니다.

kubectl config delete-context {컨텍스트 이름}

컨텍스트 설정까지 완료하였다면 문제없이 k8s의 명령어 등을 실행할 수 있습니다.

참고

• kubeconfig에 대한 자세한 내용
  • kubeconfig 파일을 사용하여 클러스터 접근 구성하기 | Kubernetes
• eks와 kubeconfig
  • Kubeconfig 파일을 생성하여 kubectl을 EKS 클러스터에 연결

노드 그룹 생성

클러스터만 있으면 포드가 생성되지 않습니다.
노드 없이 포드만 생성하면 계속 pending 상태로 있게 됩니다.

따라서 워커 노드를 생성하고 이를 그룹화 할 필요가 있습니다.

노드 그룹 생성 단계

클러스터의 패널의 컴퓨팅 탭에서 노드 그룹 생성 가능합니다.

EC2 인스턴스와 Fargate 중 선택할 수 있으며 두 유형 모두 인스턴스 프로파일이 필요합니다.

권장 역할로 생성하면 다음 AWS 관리형 정책이 포함됩니다.

시작 템플릿(Launch Template)
EC2의 시작 템플릿을 이용하여 생성하는 것도 가능합니다.
다만 시작 템플릿을 사용하는 경우 다음과 같은 주의점이 있습니다.

모범 사례로는 노드의 일관성있는 관리를 위해 시작 템플릿을 사용하여 노드 그룹을 생성하는 것을 권장하고 있습니다.

이 외에도 금지 사항 등 주의할 점이 많으므로 공식 문서를 참고하는 것을 권장합니다.

• 시작 템플릿을 사용한 관리형 노드 사용자 지정 - Amazon EKS

노드 레이블, 노드 테인트, 태그
노드 레이블은 k8s의 레이블입니다.
노드 테인트는 파드를 해당 노드에 스케줄링 하지 않도록 지정하는 변수입니다.

• 참고
  • 쿠버네티스 테인트(Taints)와 톨러레이션(Tolerations) 개념과 설정(zero.log)
  • 테인트(Taints)와 톨러레이션(Tolerations)(k8s 공식 문서)

태그는 AWS 상에서 해당 노드 그룹을 관리하기 위해 붙이는 태그입니다.

컴퓨팅 및 조정 구성 설정

컴퓨팅 및 조정 구성 설정
노드 그룹의 컴퓨팅 스펙에 대한 설정입니다.
시작 템플릿이 지정되어 있다면 일부 설정 값은 지정하지 못하게 되어 있습니다.

선택할 수 있는 AMI 는 이미 EKS 최적화가 되어 있는 AMI 입니다.
권장 사항으로는 Amazon Linux 사용입니다.
k8s 조작에 필요한 플러그인이나 패키지 등은 설치되어 있습니다.

인스턴스 유형
콘솔에서 선택하는 인스턴스 유형은 “많이 사용하는 유형” 들만 선택 가능합니다.
콘솔에 표시되지 않는 유형의 경우 cli로 설정하여 노드 그룹을 생성할 필요가 있습니다.

인스턴스 타입으로는 여러 개를 선택할 수 있습니다.
우선 순위는 API에 먼저 입력된 순서로 정해집니다.

관리형 노드 그룹은 API에 전달된 인스턴스 유형의 순서를 사용하여 온디맨드 용량을 채울 때 먼저 사용할 인스턴스 유형을 결정합니다.

• 관리형 노드 그룹을 사용한 노드 수명 주기 간소화 - Amazon EKS

주의 사항으로 리소스 크기가 다른 인스턴스를 사용하면 노드 조정에 영향을 줄 수 있습니다.
Kubernetes Cluster Autoscaler는 노드 그룹 내의 모든 노드에 vCPU 및 메모리와 같은 동일한 리소스가 있다고 가정하기 때문입니다.

노드 그룹 업데이트 구성
노드 그룹 업데이트 중 사용할 수 없는 노드 수(혹은 백분률)나 업데이트 전략을 지정할 수 있습니다.

기본 전략(default)은 이전 인스턴스를 종료하기 전에 먼저 새 인스턴스를 시작합니다.
최소 전략(minimal)은 새 인스턴스를 시작하기 전에 이전 인스턴스를 먼저 종료합니다.

노드 자동 복구 구성
비교적 최근에 추가된 기능으로 노드의 상태확인이 실패하는 경우 자동으로 노드를 복구하는 설정입니다.
상태 이상의 기준 등은 내부에서 설정하는 것에 따라서 바꿀 수 있습니다.

기능의 활성화도 노드 그룹 생성 후 편집 가능합니다.

상세 내용은 아래 글을 참고해주세요.

• Amazon EKS의 노드 상태 모니터링 및 자동 복구 발표 - AWS
• 노드 자동 복구 활성화 및 노드 상태 문제 조사 - 노드 상태 문제

네트워킹 지정 단계

노드 그룹 네트워크 구성
클러스터가 배치되어 있는 VPC의 서브넷을 선택 가능합니다.

관리형 EC2 라면 필요에 따라 노드에 직접 연결할 수 있으며 노드에 대한 원격 액세스 허용 기능을 활성화 해야합니다.
노드 그룹 생성 단계에서만 활성화 할 수 있으므로, 그룹 생성 전에 필요성을 검토해야합니다.
보안 그룹이나 키 페어는 일반적인 EC2 생성과 같습니다.

프라이빗 서브넷에 노드 그룹을 생성할 때는 NGW가 연결되어 있거나 엔드포인트가 연결되어 있어야합니다.
연결돼지 않은 경우에는 노드(인스턴스)는 정상적으로 생성되지만 클러스터에 편입되지않으므로 노드 생성 실패로 간주됩니다.

설정 값을 확인한 후 노드 그룹을 생성하면 콘솔에서 노드 그룹 생성 완료를 확인하거나 아래 커맨드를 실행하여 확인 가능합니다.

# --watch 플래그를 지정하여 특정 오브젝트에 대한 업데이트 진행과정을 확인
kubectl get nodes --watch

마무리

이상, 한국어 블로그 릴레이의 2025년 27 번째 블로그「콘솔에서 EKS 클러스터와 노드 그룹을 생성할 때 나오는 요소들에 대해」편이었습니다. 다음 28 번째 블로그 릴레이는 8월 2주에 공개됩니다.

긴 글 읽어주셔서 감사합니다.
오탈자 및 내용 피드백은 must01940 지메일로 보내주시면 감사합니다.

문의 사항은 클래스메소드코리아로!

클래스메소드코리아에서는 다양한 세미나 및 이벤트를 진행하고 있습니다.
진행중인 이벤트에 대해 아래 페이지를 참고해주세요.

https://classmethod.kr/board/library

AWS에 대한 상담 및 클래스메소드 멤버스에 관한 문의사항은 아래 메일로 연락주시면 감사드립니다!
Info@classmethod.kr