GitOps 기반 EKS 클러스터 운영
📅 작성일: 2025-02-09 | 수정일: 2026-02-18 | ⏱️ 읽는 시간: 약 6분
📌 기준 버전: ArgoCD v2.13+ / v3 (프리릴리즈), EKS Capability for Argo CD (GA), Kubernetes 1.32
개요
대규모 EKS 클러스터를 안정적이고 확장 가능하게 운영하기 위해서는 GitOps 원칙을 따른 자동화된 배포 및 관리 전략이 필수입니다. 이 문서는 ArgoCD, KRO/ACK, 그리고 Infrastructure as Code 패턴을 활용하여 프로덕션급 클러스터 운영 환경을 구축하는 방법을 설명합 니다.
문제 해결
전통적인 EKS 클러스터 운영에서는 다음의 문제들이 있었습니다:
- 수동 설정으로 인한 환경 간 불일치
- 인프라 변경 이력 추적 어려움
- 대규모 멀티클러스터 관리의 복잡성
- 배포 검증 및 롤백 프로세스의 부재
- 정책 준수 자동화 부족
이 아키텍처는 이러한 문제들을 해결하기 위해 설계되었습니다.
기술적 고려사항 및 아키텍처 요약
핵심 제안 사항
1. GitOps 플랫폼 선택
- ArgoCD ApplicationSets를 활용한 멀티 클러스터 관리
- Progressive Delivery를 위한 Flagger 통합
ArgoCD는 EKS Capability로 제공됩니다. 기존 EKS Add-on과 달리, EKS Capability는 워커 노드 외부의 AWS 관리 계정에서 실행되며, 설치·업그레이드·스케일링·HA를 AWS가 완전 관리합니다. EKS 콘솔의 Capabilities 탭에서 활성화하거나 AWS CLI/API로 생성할 수 있습니다.
# EKS Capability로 ArgoCD 생성
aws eks create-capability \
--cluster-name my-cluster \
--capability-type ARGOCD \
--role-arn arn:aws:iam::123456789012:role/eks-argocd-capability-role
주요 차이점 (Add-on vs Capability):
- Add-on: 클러스터 내부에서 실행, 사용자가 리소스 관리
- Capability: AWS 관리 계정에서 실행, 제로 운영 오버헤드
- AWS Identity Center 통합 SSO, Secrets Manager·ECR·CodeConnections 네이티브 연동
2. Infrastructure as Code 전략
- ACK/KRO (Kubernetes Resource Orchestrator) 채택 권장
- 기존 Terraform 상태와의 점진적 마이그레이션 가능
- Kubernetes 네이티브 접근 방식으로 운영 일관성 확보
- Helm 대비 더 유연한 리소스 오케스트레이션
3. 자동화 핵심 요소
- Blue/Green 방식의 EKS 업그레이드 자동화
- Addon 버전 관리를 위한 자동화된 테스트 파이프라인
- Policy as Code (OPA/Gatekeeper) 기반 거버넌스
4. 보안 및 규정 준수
- External Secrets Operator + AWS Secrets Manager 조합
- Git 서명 및 RBAC 기반 승인 워크플로우
- 실시간 규정 준수 모니터링 대시보드
예상 ROI
| 효과 | 개선 |
|---|---|
| 운영 부담 | 수동 작업 자동화로 감소 |
| 업그레이드 빈도 | 연 1회 → 분기별 가능 |
| 장애 복구 | 자동 롤백으로 시간 개선 |
아키텍처 개요
GitOps 기반 EKS 클러스터 운영은 Git을 단일 진실 공급원으로 삼고, 선언적 구성 관리를 통해 클러스터 상태를 자동으로 동기화합니다.
GitOps 워크플로우
멀티클러스터 관리 전략
ApplicationSets 기반 클러스터 관리
ArgoCD ApplicationSets는 멀티클러스터 환경에서 일관된 배포를 관리하는 핵심 도구입니다.
핵심 전략:
1. Cluster Generator
- 클러스터 레지스트리 기반 동적 애플리케이션 생성
- 레이 블 기반 클러스터 그룹핑 (환경, 리전, 목적별)
2. Git Directory Generator
- 환경별 구성 관리 (dev/staging/prod)
- 클러스터별 오버라이드 설정
3. Matrix Generator
- 클러스터 × 애플리케이션 조합 관리
- 조건부 배포 규칙 적용
멀티클러스터 자동화
EKS 클러스터 업그레이드 자동화
Blue/Green 배포 패턴을 사용하여 무중단 클러스터 업그레이드를 구현합니다.
준비 단계
- 새 클러스터 프로비저닝 (KRO)
- Addon 호환성 검증
- 보안 정책 동기화
마이그레이션 단계
- 워크로드 점진적 이동
- 트래픽 가중치 조정 (0% → 100%)
- 실시간 모니터링
검증 및 완료
- 자동화된 smoke test
- 성능 메트릭 비교
- 구 클러스터 제거
보안 및 거버넌스
Git Repository 구조 설계
효과적인 GitOps 구현을 위해서는 적절한 저장소 구조가 필수입니다.
Monorepo vs Polyrepo 권장사항:
| 대상 | 권장 방식 | 이유 |
|---|---|---|
| 애플리케이션 코드 | Polyrepo | 팀별 독립성 보장 |
| 인프라 구성 | Monorepo | 중앙 관리 및 일관성 확보 |
| 정책 정의 | Monorepo | 전사 표준화 강제 |
Secret 관리 아키텍처
주요 특징:
- 중앙집중식 Secret 저장소
- 자동 로테이션 지원
- 세밀한 접근 제어 (IRSA)
- 암호화된 Git 저장 불필요
AWS Secrets Manager와 함께 사용하면 조직의 보안 정책을 효과적으로 구현할 수 있습니다.
Terraform에서 KRO로의 마이그레이션 전략
기존 Terraform 환경에서 KRO로 점진적으로 전환합니다. 이 접근 방식은 위험을 최소화하면서 가치를 지속적으로 제공합니다.
Phase 1: 파일럿 (2개월)
- Dev 환경 1개 클러스터 대상
- 기본 리소스만 마이그레이션 (VPC, Subnets, Security Groups)
- Terraform 상태 임포트 및 검증
Phase 2: 확대 적용 (3개월)
- Staging 환경 포함
- EKS 클러스터 및 Addon 관리 추가
- 자동화 파이프라인 구축
Phase 3: 전체 마이그레이션 (4개월)
- Production 환경 순차 적용
- 모든 AWS 리소스 KRO 관리
- Terraform 완전 제거
KRO 리소스 정의 예시
다음은 KRO를 사용한 EKS 클러스터 및 노드 그룹 정의의 예시입니다.
apiVersion: kro.run/v1alpha1
kind: ResourceGroup
metadata:
name: eks-cluster-us-east-1-prod
spec:
schema:
apiVersion: v1alpha1
kind: EKSClusterStack
spec:
clusterName: string
region: string | default="us-east-1"
version: string | default="1.32"
resources:
# EKS 클러스터 정의 (ACK EKS Controller)
- id: cluster
template:
apiVersion: eks.services.k8s.aws/v1alpha1
kind: Cluster
metadata:
name: ${schema.spec.clusterName}
spec:
name: ${schema.spec.clusterName}
version: ${schema.spec.version}
roleARN: arn:aws:iam::123456789012:role/eks-cluster-role
resourcesVPCConfig:
subnetIDs:
- subnet-0a1b2c3d4e5f00001
- subnet-0a1b2c3d4e5f00002
endpointPrivateAccess: true
endpointPublicAccess: false
# 노드 그룹 정의 (ACK EKS Controller)
- id: nodegroup
template:
apiVersion: eks.services.k8s.aws/v1alpha1
kind: Nodegroup
metadata:
name: ${schema.spec.clusterName}-nodegroup
spec:
clusterName: ${schema.spec.clusterName}
nodegroupName: ${schema.spec.clusterName}-ng-01
instanceTypes:
- c7i.8xlarge
scalingConfig:
minSize: 3
maxSize: 50
desiredSize: 10
amiType: AL2023_x86_64_STANDARD