pulumi aws eks로 EKS 클러스터 구축하기

pulumi aws eks를 함께 쓰면 EKS 클러스터의 네트워크, IAM, 노드 그룹을 코드로 선언하고 스택 단위로 재현할 수 있어요. 다만 Pulumi EKS 컴포넌트가 만들어 주는 기본값을 이해하지 않으면 운영 중 예상하지 못한 리소스가 생길 수 있어요. 이 글은 공식 문서에서 확인한 범위를 기준으로 구성 절차와 선택 기준을 정리해요.

한눈에 보기

Pulumi는 TypeScript, Python, Go 같은 범용 언어로 클라우드 리소스를 선언하는 도구예요. AWS provider는 VPC, 서브넷, IAM 역할, EKS 클러스터 같은 리소스를 낮은 수준에서 다루고, EKS 패키지는 클러스터와 노드 그룹을 더 편하게 만들도록 기본값과 컴포넌트를 제공해요.

EKS 자체는 관리형 Kubernetes 제어 플레인을 제공하지만, 워커 노드와 네트워크, 권한, 애드온은 사용자가 준비해야 해요. 따라서 Pulumi EKS를 쓸 때는 “클러스터만 만드는가”가 아니라 “VPC와 IAM, 노드 그룹까지 어디까지 컴포넌트에 맡길 것인가”를 먼저 정하는 편이 좋아요.

Pulumi와 EKS를 함께 쓰는 이유

EKS를 콘솔에서 만들면 절차를 빠르게 익힐 수 있지만, 같은 구성을 다른 계정이나 다른 리전에 반복하기는 어려워요. Pulumi로 선언하면 클러스터 구성이 코드로 남고, pulumi preview로 변경 범위를 미리 확인할 수 있어요.

EKS 패키지의 클러스터 컴포넌트는 EKS 클러스터와 관련 IAM 역할, 노드 그룹을 묶어서 다루는 흐름을 제공해요. 기존 VPC와 서브넷을 재사용할 수도 있고, 기본값에 따라 네트워크와 노드 그룹을 함께 만드는 구성도 가능해요. 다만 기본값이 항상 운영 환경에 맞는 것은 아니므로 생성되는 리소스를 반드시 확인해야 해요.

Pulumi의 장점은 애플리케이션 코드와 인프라 코드를 같은 언어로 관리할 수 있다는 점이에요. 반면 인프라 상태와 배포 순서를 Pulumi가 관리하므로, 스택 백엔드와 권한 설계를 소홀히 하면 운영 사고로 이어질 수 있어요.

비교 표: 어떤 방식으로 구성할까

항목	Pulumi EKS 컴포넌트	AWS 리소스 직접 선언	관리 콘솔 수동 구성
추상화 수준	클러스터와 노드 그룹, IAM 기본값을 묶어 제공	VPC, 서브넷, IAM, EKS를 하나씩 선언	화면에서 단계별로 설정
재현성	코드와 스택 설정으로 재현하기 쉬움	세밀하지만 코드량이 늘어남	수동 절차가 남기 쉬움
네트워크 제어	기존 VPC를 넘기거나 기본값 사용	서브넷과 라우팅을 직접 제어	콘솔 입력에 의존
변경 리뷰	`pulumi preview`로 차이 확인	리소스 단위로 차이 확인	리뷰가 어려움
적합한 상황	빠른 구성과 팀 표준화	세밀한 제어와 기존 자산 재사용	일회성 실습

단계별 구성 방법

사전 준비

AWS 자격 증명과 Pulumi CLI, 사용할 언어의 런타임을 준비해요. Pulumi 상태를 어디에 저장할지도 먼저 정해야 해요. Pulumi Cloud를 쓸지, 직접 관리하는 백엔드를 쓸지에 따라 접근 제어와 백업 방식이 달라져요.

작업할 AWS 계정과 리전을 고정하고, EKS 클러스터를 만들 권한이 있는지 확인해요. 운영 계정과 개발 계정을 분리한다면 스택도 환경별로 나누는 편이 안전해요.

프로젝트와 스택 초기화

pulumi new aws-typescript 같은 템플릿으로 프로젝트를 만들고, EKS 패키지를 설치해요. 언어는 팀이 유지하기 쉬운 것을 고르면 되고, TypeScript가 아니어도 Pulumi EKS를 사용할 수 있어요.

스택 구성에는 리전과 클러스터 이름 같은 공통 값을 넣어요. 스택을 환경별로 나누면 같은 코드로 개발 환경과 운영 환경의 차이를 관리하기 쉬워요.

클러스터 선언

eks.Cluster 컴포넌트를 사용하면 EKS 클러스터와 관련 IAM, 노드 그룹을 묶어 선언할 수 있어요. 기존 VPC를 쓰려면 vpcId와 subnetIds를 넘기고, 기본 네트워크를 쓰려면 컴포넌트가 만드는 VPC와 서브넷 구성을 먼저 확인해요.

클러스터 이름과 태그는 운영 추적에 중요해요. 비용 추적이나 장애 대응을 위해 리소스 태그를 일관되게 붙이는 편이 좋아요.

노드 그룹과 애드온

노드 그룹은 관리형과 자체 관리형 중에서 운영 방식에 맞게 선택해요. 관리형 노드 그룹은 AWS가 노드 생명주기를 관리해 주고, 자체 관리형은 직접 제어할 부분이 많아요.

VPC CNI, CoreDNS, kube-proxy 같은 애드온은 클러스터 생성 후 별도 리소스로 관리할 수 있어요. 애드온 변경은 pulumi preview로 교체 범위를 먼저 확인하고, 운영 클러스터에 바로 적용하지 않는 편이 안전해요.

배포와 확인

pulumi preview로 생성, 변경, 삭제될 리소스를 확인한 뒤 pulumi up을 실행해요. 처음 만드는 클러스터라면 삭제될 리소스가 없는지, 예상하지 않은 네트워크 리소스가 생기지 않는지 특히 주의해요.

스택 출력의 kubeconfig를 사용해 kubectl 컨텍스트를 설정해요. kubectl get nodes와 kubectl get pods -A로 노드와 시스템 파드가 정상인지 확인해요.

상황별 선택 기준

빠르게 검증할 때는 EKS 컴포넌트의 기본값을 사용하되, 생성되는 VPC와 노드 그룹을 반드시 확인해요. 기본값은 편리하지만 운영 환경의 네트워크 정책과 맞지 않을 수 있어요.

기존 VPC와 서브넷, IAM 역할을 재사용해야 한다면 컴포넌트 입력으로 넘기고 서브넷 태그와 신뢰 정책을 점검해요. EKS는 로드 밸런서 프로비저닝을 위해 서브넷 태그를 참조하므로 태그가 빠지면 배포가 막힐 수 있어요.

네트워크와 권한을 세밀하게 제어해야 한다면 AWS provider로 리소스를 직접 선언하는 편이 명확해요. 반대로 팀에서 반복되는 EKS 구성을 표준화하려면 EKS 컴포넌트를 얇게 감싼 내부 모듈을 만드는 방식이 잘 맞아요.

Terraform과 Pulumi를 병행한다면 같은 리소스를 양쪽 도구가 동시에 관리하지 않도록 소유권을 정해요. 기존 리소스를 Pulumi로 가져와야 할 때는 import 절차를 사용하고, 상태 충돌이 없는지 먼저 확인해요.

주의할 점

Pulumi 상태에는 민감한 값이 들어갈 수 있어 스택 백엔드 접근 제어를 먼저 설정해요. 상태 저장소에 접근할 수 있는 사람이 곧 인프라를 바꿀 수 있는 사람이 되지 않도록 권한을 분리하는 편이 좋아요.

pulumi destroy는 클러스터와 연결된 리소스를 함께 삭제할 수 있어요. 운영 스택에는 보호 옵션을 검토하고, 삭제 순서와 데이터 보존 여부를 먼저 확인해요.

EKS 서브넷 태그가 없으면 로드 밸런서 프로비저닝이 실패할 수 있어요. VPC와 서브넷을 직접 만들었다면 퍼블릭·프라이빗 서브넷의 태그와 라우팅을 함께 점검해요.

IRSA를 사용할 때는 OIDC 공급자와 IAM 신뢰 정책을 함께 관리해야 해요. 서비스 계정에 연결한 역할이 의도한 권한만 갖는지도 배포 후 확인해요.

컨트롤 플레인과 워커 노드 비용은 AWS 청구서에서 확인해야 해요. Pulumi는 인프라를 선언하고 변경을 적용하는 도구이지, 비용을 대신 계산해 주는 도구가 아니에요.

애드온과 Kubernetes 버전은 운영 클러스터에서 바로 올리지 말고 테스트 스택에서 먼저 검증해요. 노드 그룹 교체가 필요한 변경인지, 롤링 업데이트로 처리되는 변경인지도 preview 단계에서 확인해요.

자주 묻는 질문

Pulumi로 EKS를 만들면 kubectl 설정도 자동으로 되나요?

클러스터 컴포넌트가 kubeconfig를 스택 출력으로 제공하지만, 로컬 kubectl 컨텍스트에 바로 등록되는 것은 아니에요. 출력값을 파일로 저장하고 KUBECONFIG 환경 변수나 컨텍스트 명령으로 연결해야 해요.

기존 VPC와 IAM 역할을 재사용할 수 있나요?

네, 클러스터 컴포넌트에 vpcId, subnetIds, instanceRoles 같은 입력을 넘겨 기존 자산을 재사용할 수 있어요. 다만 서브넷 태그, 라우팅, IAM 신뢰 정책이 EKS 요구 사항과 맞는지 먼저 확인해야 해요.

Terraform과 Pulumi를 같은 AWS 계정에서 함께 써도 되나요?

가능하지만 같은 리소스를 양쪽 도구가 동시에 관리하면 상태가 어긋날 수 있어요. 리소스 소유권을 도구별로 나누고, 기존 리소스를 Pulumi로 가져와야 할 때는 import 절차를 사용해요.

EKS 비용은 Pulumi에서 확인할 수 있나요?

Pulumi는 인프라를 선언하고 변경을 적용하는 도구이며, AWS 청구 금액을 직접 보여 주지는 않아요. 비용은 AWS Cost Explorer나 예산 알림에서 확인하고, 클러스터와 노드 그룹 구성이 청구에 어떤 영향을 주는지 따로 추적해요.

출처

EKS를 배포한 뒤에는 노드 그룹 교체, 애드온 업데이트, 롤링 배포 점검을 운영 절차로 정리해 두는 편이 좋아요. 관련 운영 글도 함께 확인해 보세요: EKS 운영 점검 항목.