본문
EKS와 Terraform의 역할 분리
클라우드 네이티브 인프라 구축의 표준으로 자리 잡은 EKS(Elastic Kubernetes Service) 환경에서 가장 빈번하게 논의되는 주제 중 하나는 바로 "관리의 효율성"입니다.
일반적인 쿠버네티스 환경에서도 인프라와 애플리케이션의 분리는 중요한 원칙이지만, 특히 AWS EKS 환경에서는 관리 포인트가 복잡하기 때문에 이를 어떻게 나누고 자동화할지가 운영의 성패를 결정짓습니다.
실무에서 가장 권장되는 패턴은 Terraform과 Kubernetes 리소스의 생명주기를 철저하게 분리하여 관리하는 것입니다. Terraform은 튼튼한 '운동장(인프라)'을 만드는 데 집중하고, 애플리케이션이라는 '선수'들이 뛰는 것은 전용 도구에 맡기는 방식이죠.
이번 포스팅에서는 왜 이러한 역할 분리가 업계 표준으로 자리 잡았는지, 그리고 구체적으로 어떤 영역을 나누어 관리해야 하는지 살펴보겠습니다.
1. 업계 표준 패턴: "철저한 역할 분리"
이 패턴에서는 Terraform을 "클러스터를 사용할 수 있는 상태로 만들어주는 도구"까지만 사용하고, 그 위에서 돌아가는 워크로드는 K8s 생태계 도구(ArgoCD, Flux 등)에 온전히 맡깁니다.
A. Terraform의 관리 영역 (인프라 및 클러스터 기반)
Terraform은 AWS 리소스와 EKS 클러스터의 "뼈대"를 구성합니다.
- 네트워크 & 보안: VPC, Subnet, Security Group, NAT Gateway 등
- EKS 클러스터 본체: EKS Control Plane, Managed Node Groups, Fargate Profiles
- 권한 및 IAM: EKS 클러스터용 IAM Role, IRSA(IAM Roles for Service Accounts) 또는 EKS Pod Identity (K8s Pod가 AWS 리소스에 접근하기 위한 권한)
- 필수 애드온(Add-ons): VPC CNI, CoreDNS, kube-proxy, EBS CSI Driver 등 클러스터 구동에 필수적인 AWS 관리형 애드온
(최근에는 AWS Load Balancer Controller나 Karpenter 같은 기반 시스템의 초기 설치까지도 Terraform으로 하는 경우가 많다)
B. K8s/GitOps의 관리 영역 (애플리케이션 및 서비스)
클러스터가 준비되면, 내부 리소스는 Terraform이 개입하지 않고 GitOps 도구가 담당합니다.
- 워크로드: 실제 서비스하는 애플리케이션의 Deployment, Pod, StatefulSet 등
- 네트워킹 설정: Service, Ingress 리소스 설정
- 설정 및 비밀번호: ConfigMap, Secret
2. 왜 EKS에서는 모든 것을 Terraform으로 관리(All-in-Terraform)하지 않을까?
이론적으로는 Terraform의 'kubernetes' provider와 'helm' provider를 사용해 EKS 안의 Pod나 Deployment까지 100% 코드로 관리할 수 있습니다. 하지만 실무에서는 안티 패턴(Anti-pattern)으로 간주합니다. 그 이유는 다음과 같습니다.
- State 파일의 비대화와 종속성: Terraform은 모든 리소스의 상태를 '.tfstate' 파일에 기록합니다. K8s 내부의 수많은 리소스가 추가되면 이 파일이 너무 커지고, 클러스터와 통신하는 과정에서 'terraform plan' 속도가 심각하게 느려집니다.
- K8s의 자가 치유(Self-healing)와 Terraform의 충돌: K8s는 Pod가 죽으면 스스로 다시 띄우고(ReplicaSet), 트래픽이 몰리면 자동으로 늘립니다(HPA). Terraform은 이런 "동적인 변화"를 "Drift(상태 불일치)"로 인식하여 원래대로 되돌리려고 충돌을 일으킬 수 있습니다.
- 배포 파이프라인의 병목: 개발자가 애플리케이션 버전을 하나 올리려고 할 때마다 무겁고 위험한 인프라 코드(Terraform) 전체를 실행해야 하므로, 민첩한 CI/CD가 불가능해집니다.
3. 생명주기(Lifecycle) 관리 흐름
두 영역을 분리했기 때문에, 변경 사항이 발생했을 때의 생명주기 파이프라인도 두 개로 나뉩니다.
A. 인프라(Terraform)의 생명주기
- 상황: 워커 노드(EC2)의 인스턴스 타입을 변경하거나, 새로운 IAM 권한이 필요할 때
- 흐름:
- 인프라 엔지니어가 Terraform 코드를 수정
- PR(Pull Request) 리뷰
- CI 파이프라인에서 'terraform plan' 확인
- 승인 후 CD에서 'terraform apply' 실행
- 특징: 인프라 변경은 위험도가 높으므로 사람의 개입과 승인(Approval) 과정을 거치는 것이 일반적입니다.
B. 애플리케이션(EKS/K8s)의 생명주기
- 상황: 개발자가 새로운 기능이 추가된 v2.0 앱을 배포할 때
- 흐름:
- 개발자가 코드를 커밋
- CI 파이프라인이 컨테이너 이미지를 빌드하고 ECR에 푸시
- CI가 K8s Manifest(또는 Helm values)의 이미지 태그를 v2.0으로 업데이트하여 Git에 커밋
- EKS 내부의 ArgoCD가 이를 감지하고 자동으로 K8s에 배포
- 특징: 빠르고 자동화되어 있으며, 문제가 생기면 Git 커밋을 되돌리는 것만으로 즉시 롤백이 가능합니다.
요약
| 구분 | 관리 도구 | 관리 대상 | 변경 빈도 |
| AWS 인프라 & EKS 클러스터 | Terraform | VPC, EKS Cluster, Node Group, IAM, 기반 애드온 | 낮음 |
| K8s 애플리케이션 | ArgoCD, Flux 등 (GitOps) | Deployment, Service, Ingress, 앱 관련 Helm Chart | 높음 |
결론적으로, EKS 환경을 구축할 때는 Terraform으로 "EKS 클러스터라는 튼튼한 운동장"을 만들고,
그 위에서 "선수들(컨테이너)이 뛰는 것"은 Kubernetes 전용 도구(GitOps)에 맡기는 하이브리드 패턴을 구성하시는 것을 권장합니다.
* AWS에서 공식적으로 밀고 있는 'EKS Blueprints for Terraform' 프로젝트 역시 정확히 이 철학(인프라와 애드온까지만 TF로 관리)을 따르고 있습니다.
댓글