EKS CI/CD와 GitOps로 구현하는 SaaS 플랫폼 엔지니어링
- 플랫폼 엔지니어링은 개발자가 인프라 세부 구현을 직접 다루지 않도록 추상화를 제공하는 접근 방식
- AWS 콘솔, Kubernetes 설정, IAM 권한, CI/CD 파이프라인을 하나하나 몰라도, 정해진 템플릿과 셀프서비스 방식으로 안전하게 배포할 수 있게 만드는 구조
- DevOps → GitOps → 플랫폼 엔지니어링으로 진화하며 복잡도 관리와 생산성 향상 목적
- EKS 기반 SaaS 플랫폼에서는 CI/CD, GitOps, IaC, 멀티테넌시, 배포 전략을 함께 설계하는 구조
- ArgoCD와 FluxCD는 EKS 환경에서 사용할 수 있는 대표 GitOps 도구
- ArgoCD는 UI, 운영 가시성, 멀티클러스터 관리에 강점
- FluxCD는 Kubernetes 네이티브 구조, 자동화, 멀티테넌시 구조에 강점
EKS GitOps CI/CD 전체 흐름
| 단계 | 설명 |
|---|
| 1 | 개발자가 애플리케이션 코드 변경 |
| 2 | CI 파이프라인에서 테스트와 이미지 빌드 |
| 3 | 컨테이너 이미지를 Amazon ECR에 Push |
| 4 | GitOps 저장소의 Helm values 또는 Kustomize manifest 변경 |
| 5 | ArgoCD 또는 FluxCD가 Git 변경 감지 |
| 6 | EKS 클러스터에 선언된 상태 반영 |
| 7 | IRSA, SQS, DynamoDB 같은 AWS 리소스와 연결 |
핵심 포인트
- CI는 빌드와 검증 중심
- CD는 GitOps Controller 중심
- 클러스터 접근 권한은 CI가 아니라 ArgoCD 또는 FluxCD에 집중
- 배포 기준은 실행 명령어가 아니라 Git에 선언된 상태
- 운영 환경 변경 이력은 Pull Request와 Git commit 기준
EKS CI/CD에서 GitOps가 필요한 이유
기존 CI/CD의 한계
- CI 파이프라인이 직접 Kubernetes 클러스터에 접근하는 구조
- 배포 권한이 CI 시스템에 집중되는 문제
- 운영 환경 변경 이력 추적의 어려움
- 수동
kubectl apply, Helm 배포, 콘솔 작업의 혼재
- 테넌트 증가 시 동일 작업 반복 증가
- 클러스터 상태와 Git 상태 불일치 가능성
GitOps 기반 개선 방향
- Git 저장소를 배포 기준점으로 사용
- CI는 이미지 빌드와 테스트까지만 담당
- CD는 ArgoCD 또는 FluxCD가 담당
- 운영자는 Git 변경 이력으로 배포 상태 추적
- 클러스터는 선언된 상태와 실제 상태를 지속적으로 비교
- Drift 발생 시 자동 복구 또는 알림 처리
CI와 CD 책임 분리
| 구분 | CI | CD |
|---|
| 주요 책임 | 빌드, 테스트, 이미지 생성 | 배포, 동기화, 상태 복구 |
| 주요 도구 | GitHub Actions, GitLab CI, Jenkins, CodeBuild | ArgoCD, FluxCD |
| 결과물 | 컨테이너 이미지, 태그 | Kubernetes 리소스 반영 |
| 클러스터 접근 | 최소화 | GitOps Controller만 접근 |
| 변경 기준 | 소스 코드 | 배포 선언 파일 |
GitOps 핵심 원칙
기본 원칙
- Declarative: 원하는 상태 정의
- Versioned: Git 기반 버전 관리
- Auto Sync: 자동 배포
- Reconciliation: 상태 불일치 자동 복구
핵심 메커니즘
- Git = Single Source of Truth
- Drift 발생 시 자동 복구
- 모든 변경은 Pull Request 기준
- 운영 환경 직접 수정 최소화
- 배포 상태와 변경 이력을 Git에서 확인
GitOps 운영 흐름
개발자가 코드 변경
↓
CI 파이프라인 실행
↓
컨테이너 이미지 빌드
↓
ECR에 이미지 Push
↓
배포 Git 저장소의 이미지 태그 또는 Helm values 변경
↓
ArgoCD 또는 FluxCD가 Git 변경 감지
↓
EKS 클러스터에 변경 사항 반영
↓
클러스터 상태와 Git 상태 지속 비교
EKS 기반 GitOps 도구 비교
주요 도구
| 도구 | 특징 | 적합 환경 |
|---|
| Argo CD | UI 중심, 멀티클러스터 | 운영 가시성 |
| Flux v2 | Kubernetes 네이티브 | 멀티테넌시 SaaS |
| Weave GitOps | Flux + UI | 운영 편의 |
| Rancher Fleet | 대규모 클러스터 | 대량 운영 |
ArgoCD vs FluxCD
| 항목 | ArgoCD | FluxCD |
|---|
| UI | 강함 | 약함 |
| 설정 | 쉬움 | 복잡 |
| 멀티클러스터 | 강함 | 보통 |
| 멀티테넌시 | 보통 | 강함 |
| 확장성 | 제한적 | 높음 |
| 운영 방식 | Application 중심 | Controller 중심 |
| 사용 경험 | 사람이 보기 쉬움 | 자동화에 유리 |
| 학습 곡선 | 상대적으로 낮음 | 상대적으로 높음 |
| 배포 단위 | Application, ApplicationSet | Kustomization, HelmRelease |
| 이미지 자동화 | Argo Image Updater | Image Reflector, Image Automation Controller |
| 알림 | ArgoCD Notifications | Notification Controller |
SaaS에서 GitOps 필요성
요구사항
- 빈번한 배포
- 테넌트 일관성
- 자동 온보딩
- 테넌트별 리소스 격리
- 표준화된 권한 관리
- 배포 이력 추적 -> 내가 느꼈던 가장 중요한 옵션 1위
- 장애 발생 시 빠른 복구 -> 내가 느꼈던 가장 중요한 옵션 2위
SaaS 모델
| 모델 | 특징 | 비용 | 격리 |
|---|
| Silo | 전용 인프라 | 높음 | 높음 |
| Pool | 공유 인프라 | 낮음 | 낮음 |
| Hybrid | 혼합 | 중간 | 중간 |
SaaS 모델별 GitOps 적용 방식
| 모델 | GitOps 적용 방식 | 고려 사항 |
|---|
| Silo | 테넌트별 클러스터 또는 계정 분리 | 비용 증가, 격리 우수 |
| Pool | Namespace 기반 분리 | 비용 효율, 정책 관리 중요 |
| Hybrid | 중요 테넌트만 전용 인프라 | 운영 복잡도 증가 |
| Cell 기반 | 여러 테넌트를 Cell 단위로 분산 | 장애 격리와 확장성 균형 |
EKS SaaS 아키텍처 구성
구성 요소
- Terraform: 인프라 구성
- Helm: Kubernetes 패키징
- Flux v2: GitOps 배포
- Kubernetes Controller: 상태 관리
- ArgoCD: 애플리케이션 배포 관리
- Argo Rollouts: 고급 배포 전략
- Argo Image Updater: 이미지 태그 자동 갱신
- Tofu Controller: Kubernetes 내부 Terraform 실행
특징
- Git 기반 단일 진실 소스
- 테넌트별 동일한 배포 구조
- 자동화된 프로비저닝
- AWS 리소스와 Kubernetes 리소스의 선언형 관리
- CI와 CD의 책임 분리
- 운영 환경 직접 접근 최소화
기준 아키텍처
Developer
↓
Git Repository
↓
CI Pipeline
↓
Container Image Build
↓
Amazon ECR
↓
Manifest Update
↓
GitOps Repository
↓
ArgoCD / FluxCD
↓
Amazon EKS
↓
Service / Pod / Namespace / IRSA
↓
AWS Resource
패키징 전략
- Terraform → DB, SQS 등 인프라 구성
- Helm → 애플리케이션 + K8s 리소스
- Flux → 배포 및 상태 유지
- Tofu Controller → Terraform 통합
- Kustomize → 환경별 매니페스트 오버레이 관리
- ArgoCD Application → 서비스 단위 배포 관리
- ApplicationSet → 멀티클러스터 또는 멀티환경 배포 자동 생성
패키징 기준
| 대상 | 적합 도구 | 이유 |
|---|
| EKS 클러스터 | Terraform | AWS 인프라 생성에 적합 |
| VPC, IAM, RDS, SQS, DynamoDB | Terraform | 상태 관리와 모듈화에 적합 |
| Kubernetes 리소스 | Helm, Kustomize | 환경별 차이 관리에 적합 |
| 애플리케이션 배포 | ArgoCD, FluxCD | GitOps 동기화에 적합 |
| 테넌트 인프라 | Terraform Module, Tofu Controller | 반복 생성에 적합 |
| 점진적 배포 | Argo Rollouts | Canary, Blue-Green 제어에 적합 |
개발자 주도형 인프라와 인프라 자동화
핵심 개념
- 애플리케이션 개발팀이 필요한 인프라를 매번 인프라팀에 요청하는 방식은 조직 규모가 커질수록 병목 구조로 전환
- 이를 해결하기 위한 접근이 개발자 주도형 인프라
- 개발자가 직접 모든 권한을 갖는 방식이 아니라, 플랫폼팀이 미리 정의한 보안·거버넌스·표준 모듈 안에서 필요한 리소스를 선언적으로 생성하는 구조
기존 방식과 개선 방식
| 구분 | 기존 방식 | 개선 방식 |
|---|
| 인프라 생성 | 인프라팀에 요청 | 선언 파일 기반 자동 생성 |
| 처리 속도 | 요청 대기 발생 | Git 변경 후 자동 반영 |
| 표준화 | 담당자별 차이 가능성 | Terraform 모듈 기반 일관성 |
| 확장성 | 테넌트 증가 시 병목 | 테넌트별 반복 생성 자동화 |
| 운영 방식 | 수동 처리 중심 | GitOps 기반 선언형 운영 |
전체 구조
핵심 구조
Terraform으로 인프라를 모듈화하고, Flux와 Tofu Controller를 통해 Kubernetes 안에서 자동 실행하는 구조
- AWS 콘솔에서 직접 SQS, DynamoDB, IAM Role을 만드는 방식이 아니라 Git 저장소에 정의된 선언 파일을 기준으로 인프라와 애플리케이션 상태를 맞추는 방식
- Terraform 실행도 로컬 명령어가 아니라 Kubernetes 리소스 선언과 Controller reconciliation 흐름에 편입
- 테넌트별 인프라 생성 요청은 Git PR로 처리
- 승인된 변경만 클러스터와 AWS 리소스에 반영
단계
| 단계 | 구성 요소 | 역할 |
|---|
| 1 | Terraform Module | 테넌트 인프라 정의 |
| 2 | Git Repository | 선언 파일 저장 |
| 3 | Flux | Git 변경 감지 |
| 4 | Tofu Controller | Terraform CRD 감지 및 실행 |
| 5 | tf-runner Pod | Terraform plan/apply 수행 |
| 6 | AWS Resource | SQS, DynamoDB, IRSA 등 생성 |
| 7 | Kubernetes Secret | 실행 결과 및 출력값 저장 |
자동화 흐름
Git 저장소에 Terraform CRD 추가
↓
Flux가 변경 사항 감지
↓
Tofu Controller가 Terraform 리소스 확인
↓
tf-runner Pod 생성
↓
Terraform 모듈 실행
↓
AWS 인프라 생성
↓
결과값을 Kubernetes Secret으로 저장
tenant-apps 모듈은 테넌트 애플리케이션에 필요한 인프라를 하나의 단위로 묶은 구조- 개별 리소스를 따로 생성하는 것이 아니라, 입력 변수만 바꿔 필요한 리소스 조합을 제어하는 방식
생성 대상 리소스
| 리소스 | 목적 |
|---|
| SQS Queue | 서비스 간 메시지 전달 |
| DynamoDB Table | 테넌트별 데이터 저장 |
| IAM Policy | 서비스별 AWS 접근 권한 정의 |
| IRSA Role | Kubernetes ServiceAccount와 IAM Role 연결 |
| SSM Parameter | 생성된 리소스 정보 저장 |
| Random Suffix | 리소스 이름 충돌 방지 |
변수 기반 제어
| 변수 | 의미 |
|---|
tenant_id | 테넌트 식별자 |
enable_producer | Producer 관련 리소스 생성 여부 |
enable_consumer | Consumer 관련 리소스 생성 여부 |
예시 흐름
enable_producer = true일 때는 Producer 관련 IAM Role과 Policy까지 포함된 리소스 생성enable_producer = false로 변경하면 Producer 전용 리소스 일부가 제외되며 생성 계획 감소- 이를 통해 배운 핵심은 모듈 하나로 여러 인프라 구성을 재사용하고, 변수로 배포 범위를 제어할 수 있다는 점
이 방식의 장점
| 장점 | 설명 |
|---|
| 재사용성 | 테넌트마다 같은 모듈 사용 |
| 표준화 | 권한, 네이밍, 태그 규칙 일관성 유지 |
| 속도 | PR 승인 후 자동 생성 |
| 감사 | Git 이력으로 변경 추적 |
| 안정성 | 수동 콘솔 작업 감소 |
주의할 점
| 항목 | 주의 사항 |
|---|
| Terraform State | S3 backend, DynamoDB lock 같은 상태 관리 필요 |
| 권한 | tf-runner Pod 권한 최소화 필요 |
| 삭제 | 리소스 삭제 정책 명확화 필요 |
| Secret | 출력값 Secret 저장 시 접근 제어 필요 |
| 비용 | 테넌트 증가에 따른 리소스 비용 추적 필요 |
Flux와 Tofu Controller의 역할
- Flux는 Git 저장소의 변경 사항을 감시하고 Kubernetes 클러스터 상태를 선언된 상태와 일치시키는 GitOps 엔진
- Tofu Controller는 Kubernetes CRD 형태로 정의된 Terraform 리소스를 감지하고 Terraform 실행을 담당하는 컨트롤러
역할 분리
| 구성 요소 | 책임 |
|---|
| Flux | Git 변경 감지 및 Kubernetes 리소스 반영 |
| GitRepository | Terraform 모듈이 있는 저장소 참조 |
| Kustomization | YAML 리소스 적용 범위 정의 |
| Terraform CRD | 실행할 Terraform 모듈과 변수 선언 |
| Tofu Controller | Terraform 실행 제어 |
| tf-runner Pod | 실제 Terraform init, plan, apply 수행 |
FluxCD 구성 요소
| 구성 요소 | 역할 |
|---|
| source-controller | GitRepository, HelmRepository, OCIRepository 같은 외부 소스 수집 |
| kustomize-controller | Kustomization 리소스 기준으로 매니페스트 적용 |
| helm-controller | HelmRelease 리소스 기준으로 Helm chart 배포 |
| notification-controller | 이벤트, 알림, Webhook 처리 |
| image-reflector-controller | 컨테이너 이미지 태그 조회 |
| image-automation-controller | 이미지 태그 변경을 Git에 반영 |
FluxCD가 SaaS에 잘 맞는 이유
- Kubernetes CRD 중심 구조
- Namespace 단위 권한 분리와 조합 가능
- GitRepository, Kustomization, HelmRelease로 배포 단위 세분화 가능
- 컨트롤러별 역할 분리
- 대규모 자동화에 적합
- UI 의존도가 낮고 Git 중심 운영에 적합
Terraform CRD는 Kubernetes 리소스처럼 Terraform 실행 대상을 선언하는 파일
여기에는 어떤 모듈을 실행할지, 어떤 GitRepository를 참조할지, 어떤 변수를 넘길지, 결과를 어디에 저장할지가 포함
주요 필드
| 필드 | 의미 |
|---|
path | 실행할 Terraform 모듈 경로 |
interval | 재조정 주기 |
approvePlan | plan 승인 방식 |
sourceRef | Terraform 코드가 있는 GitRepository |
vars | 모듈에 전달할 변수 |
writeOutputsToSecret | 출력값 저장 대상 Secret |
이 구조를 통해 Terraform 실행이 로컬 명령어 중심에서 Kubernetes 선언형 리소스 중심으로 이동
예시 구조
apiVersion: infra.contrib.fluxcd.io/v1alpha2
kind: Terraform
metadata:
name: tenant-a-infra
namespace: flux-system
spec:
interval: 1m
path: ./modules/tenant-apps
approvePlan: auto
sourceRef:
kind: GitRepository
name: tenant-infra
namespace: flux-system
vars:
- name: tenant_id
value: tenant-a
- name: enable_producer
value: "true"
- name: enable_consumer
value: "true"
writeOutputsToSecret:
name: tenant-a-infra-output
해석
| 항목 | 의미 |
|---|
kind: Terraform | Terraform 실행 대상을 Kubernetes 리소스로 선언 |
path | 실행할 모듈 위치 |
sourceRef | Terraform 코드가 있는 GitRepository 참조 |
vars | 테넌트별 입력값 |
approvePlan | plan 승인 방식 |
writeOutputsToSecret | 실행 결과 저장 위치 |
GitOps 방식의 장점
- Git 기반 변경 이력 관리
- 선언 파일 기반 반복 가능성 확보
- 테넌트 온보딩 자동화 기반 마련
- 인프라 생성 방식 표준화
- 수동 명령어 의존도 감소
- 운영자 개입 최소화
운영 관점 장점
| 장점 | 설명 |
|---|
| 변경 추적 | 누가, 언제, 무엇을 바꿨는지 확인 가능 |
| 롤백 | Git revert 기반 복구 가능 |
| 보안 | 클러스터 접근 권한 최소화 가능 |
| 표준화 | 모듈과 템플릿 기반 운영 가능 |
| 확장성 | 테넌트 증가 시 반복 작업 자동화 가능 |
| 복구 | Drift 감지와 재동기화 가능 |
GitOps 주요 도구 분류
영역별 구성
| 영역 | 도구 | 역할 |
|---|
| GitOps | Argo CD, Flux | 선언적 배포 |
| 패키징 | Helm | Kubernetes 리소스 관리 |
| IaC | Terraform | 인프라 정의 |
| 배포 전략 | Argo Rollouts | 점진적 배포 |
| 자동화 | Argo Image Updater | 이미지 업데이트 |
| 확장 패턴 | App of Apps | 대규모 배포 관리 |
| 플랫폼 | GitOps Bridge | 전체 흐름 통합 |
ArgoCD 기반 GitOps
핵심 기능
- Git 기반 배포 자동화
- 상태 동기화 및 Drift 복구
- UI 기반 운영
- Application 단위 배포 관리
- 멀티클러스터 배포 관리
- RBAC 기반 접근 제어
- Helm, Kustomize, Jsonnet, plain YAML 지원
- Sync Policy를 통한 자동 또는 수동 배포 제어
ArgoCD가 잘 맞는 환경
| 환경 | 이유 |
|---|
| 운영자가 직접 배포 상태를 봐야 하는 환경 | UI 가시성 우수 |
| 여러 팀이 애플리케이션 상태를 확인해야 하는 환경 | Application 단위 관리 쉬움 |
| 멀티클러스터 운영 환경 | 클러스터별 배포 상태 확인 가능 |
| 장애 대응이 중요한 운영 환경 | OutOfSync, Health 상태 확인 쉬움 |
| 배포 승인 프로세스가 있는 조직 | 수동 Sync와 RBAC 조합 가능 |
주요 패턴
App of Apps
- Root Application → Child Application 구조
- 대규모 서비스 묶음 배포
- 클러스터 부트스트랩에 활용
구조 예시
root-app
├── platform-addons
│ ├── aws-load-balancer-controller
│ ├── external-dns
│ └── metrics-server
├── team-a-apps
│ ├── api
│ └── worker
└── team-b-apps
├── frontend
└── batch
특징
- 선언적 관리
- 멀티 애플리케이션 관리
- 배포 구조 표준화
- 클러스터 초기 구성 자동화
- 환경별 리소스 그룹화 가능
ArgoCD 생태계
- 단순 배포 도구가 아니라 배포 운영 플랫폼으로 확장 가능
- UI 기반 운영과 GitOps 자동화의 균형
- 배포 전략, 이미지 업데이트, 알림, 워크플로우까지 연결 가능
- 플랫폼팀이 표준 배포 체계를 만들기 쉬운 구조
구성 요소
| 구성 요소 | 역할 |
|---|
| ArgoCD | Kubernetes GitOps CD |
| Argo Rollouts | Canary, Blue-Green, Progressive Delivery |
| Argo Workflows | Kubernetes-native workflow engine |
| Argo Events | 이벤트 기반 자동화 |
| Argo Image Updater | 이미지 태그 변경 자동 반영 |
| ApplicationSet | 여러 Application 자동 생성 |
| ArgoCD Notifications | Slack, Webhook, Email 등 알림 연동 |
| AppProject | 팀, 네임스페이스, 리포지토리 권한 경계 |
| Sync Waves / Hooks | 배포 순서와 라이프사이클 제어 |
구성 요소 용도
| 상황 | 적합 도구 |
|---|
| Git 기준 애플리케이션 배포 | ArgoCD |
| 여러 클러스터와 환경에 같은 앱 배포 | ApplicationSet |
| Canary 또는 Blue-Green 배포 | Argo Rollouts |
| 이미지 태그 자동 갱신 | Argo Image Updater |
| 배포 성공/실패 알림 | ArgoCD Notifications |
| 배포 전후 Job 실행 | Sync Hooks |
| 배포 순서 제어 | Sync Waves |
| 배치성 워크플로우 실행 | Argo Workflows |
| 이벤트 기반 자동화 | Argo Events |
ApplicationSet
목적
- 여러 ArgoCD Application을 자동 생성하는 컨트롤러
- 클러스터, Git 디렉터리, 리스트, Pull Request 기준으로 Application 생성 가능
- 멀티클러스터와 멀티테넌트 환경에서 유용
사용 예시
| Generator | 사용 사례 |
|---|
| List Generator | 정해진 테넌트 목록 기준 배포 |
| Git Generator | Git 디렉터리 구조 기준 배포 |
| Cluster Generator | 등록된 클러스터 기준 배포 |
| Matrix Generator | 환경과 클러스터 조합 배포 |
| Pull Request Generator | PR 기반 프리뷰 환경 생성 |
SaaS 예시
tenants/
├── tenant-a/values.yaml
├── tenant-b/values.yaml
└── tenant-c/values.yaml
- 각 테넌트 디렉터리를 기준으로 Application 자동 생성
- 신규 테넌트 온보딩 시 디렉터리 추가만으로 배포 가능
- 운영자가 Application을 수동으로 만들 필요 감소
자동화 도구
Argo Image Updater
- 컨테이너 이미지 변경 감지
- Git 업데이트 자동 반영
- CI 없이 CD 자동화
- ArgoCD Application이 사용하는 이미지 태그를 추적
- 새 이미지 발견 시 Git 저장소 또는 ArgoCD 파라미터 업데이트
특징
- 이미지 태그 기반 배포
- Git 변경 트리거
- 지속적 배포 자동화
- SemVer, latest, digest 등 이미지 업데이트 전략 사용 가능
- GitOps 원칙을 지키려면 Git write-back 방식 권장
일반 흐름
CI Pipeline
↓
새 이미지 빌드
↓
ECR Push
↓
Argo Image Updater가 이미지 태그 확인
↓
GitOps Repo의 image tag 변경
↓
ArgoCD가 변경 감지
↓
EKS 배포
주의할 점
| 항목 | 설명 |
|---|
| latest 태그 | 운영 환경에서는 추적성 약함 |
| Git write-back | GitOps 원칙에 더 적합 |
| 권한 | Git 저장소 쓰기 권한 필요 |
| 승인 | 자동 배포 전 PR 기반 승인 고려 필요 |
| 롤백 | 이미지 태그와 Git 이력 기준 정리 필요 |
배포 전략
Argo Rollouts
- Kubernetes 고급 배포 컨트롤러
- 기본 RollingUpdate 한계 보완
- 트래픽 제어와 분석 기반 배포 가능
- Canary, Blue-Green, Progressive Delivery 지원
지원 전략
- Blue-Green 배포
- Canary 배포
- Progressive Delivery
핵심 기능
- 트래픽 비율 제어
- 자동 롤백
- 메트릭 기반 배포 판단
- Ingress / Service Mesh 연동
RollingUpdate와 Argo Rollouts 비교
| 항목 | Kubernetes RollingUpdate | Argo Rollouts |
|---|
| 배포 방식 | Pod 순차 교체 | Canary, Blue-Green |
| 트래픽 제어 | 제한적 | 비율 기반 제어 |
| 검증 | 수동 확인 중심 | 메트릭 기반 자동 판단 |
| 롤백 | 기본 ReplicaSet 롤백 | 분석 실패 시 자동 롤백 |
| 적합 환경 | 단순 서비스 | 운영 중요 서비스 |
EKS에서의 사용 예시
| 구성 | 역할 |
|---|
| Argo Rollouts | Rollout 리소스 관리 |
| AWS Load Balancer Controller | ALB 기반 트래픽 라우팅 |
| NGINX Ingress Controller | Ingress 기반 트래픽 분산 |
| Istio / App Mesh | Service Mesh 기반 트래픽 제어 |
| Prometheus | 메트릭 수집 |
| AnalysisTemplate | 배포 성공 여부 판단 기준 |
GitOps 확장 패턴
GitOps Bridge
- 클러스터 생성부터 GitOps 연결
- 인프라 + 애플리케이션 통합 관리
- Terraform으로 클러스터를 만든 뒤 GitOps 도구가 클러스터 설정과 애드온을 이어받는 구조
- 클러스터 부트스트랩 자동화에 적합
구조
- Control Plane Repo
- Environment 분리
- Cluster 단위 정의
- Team 온보딩 구조
특징
- 플랫폼 표준화
- 멀티 클러스터 관리
- 셀프서비스 기반 온보딩
- 클러스터 생성 이후 운영 설정 자동 반영
- Add-on과 Application 배포 흐름 통합
예시 흐름
Terraform
↓
EKS Cluster 생성
↓
ArgoCD 또는 FluxCD 설치
↓
GitOps Repo 연결
↓
Cluster Add-ons 배포
↓
Team Namespace 생성
↓
Application 배포
도구 비교 핵심
| 항목 | Argo CD | Flux | Argo Rollouts |
|---|
| 역할 | 배포 관리 | 배포 엔진 | 배포 전략 |
| UI | 강함 | 약함 | 보조 |
| 확장성 | 보통 | 높음 | 높음 |
| 특징 | App 관리 | Git 중심 | 트래픽 제어 |
더 현실적인 비교
| 항목 | ArgoCD | FluxCD |
|---|
| 운영자 경험 | 좋음 | 상대적으로 낮음 |
| UI | 강함 | 기본 UI 없음 |
| GitOps 순수성 | 강함 | 강함 |
| Controller 구조 | Application 중심 | Toolkit Controller 중심 |
| 멀티테넌시 | AppProject, RBAC로 구성 | Namespace, CRD, RBAC 조합에 유리 |
| 이미지 자동화 | Argo Image Updater | Image Automation Controller |
| Helm 배포 | Application에서 Helm source 사용 | HelmRelease 리소스 사용 |
| Kustomize 배포 | Application에서 Kustomize source 사용 | Kustomization 리소스 사용 |
| 학습 난이도 | 낮은 편 | 높은 편 |
| 디버깅 | UI로 쉬움 | kubectl과 이벤트 확인 중심 |
| SaaS 자동화 | 가능 | 더 자연스러운 편 |
| 운영 가시성 | 강함 | 별도 도구 필요 |
ArgoCD와 FluxCD 선택 기준
ArgoCD
- 운영자가 배포 상태를 UI로 확인해야 하는 경우
- 서비스 수는 많지만 사람이 직접 상태를 봐야 하는 경우
- 멀티클러스터 운영 가시성이 중요한 경우
- 수동 승인과 자동 동기화를 혼합해야 하는 경우
- 팀별 Application 권한 분리가 필요한 경우
- Argo Rollouts, Image Updater, Notifications 등 Argo 생태계를 함께 쓰려는 경우
FluxCD
- Git 중심 자동화를 강하게 가져가려는 경우
- Kubernetes CRD 중심 구조를 선호하는 경우
- 멀티테넌시 SaaS 환경에서 Namespace 단위 자동화가 중요한 경우
- HelmRelease, Kustomization, GitRepository를 세밀하게 분리하고 싶은 경우
- UI보다 Controller 기반 운영이 더 적합한 경우
- Terraform CRD, Tofu Controller 같은 인프라 자동화와 결합하려는 경우
둘 다!
| 구성 | 설명 |
|---|
| ArgoCD | 애플리케이션 배포 가시성 담당 |
| FluxCD | 클러스터 Add-on, 인프라 CRD, 테넌트 자동화 담당 |
| 주의점 | 책임 경계 명확화 필요 |
- 둘을 같이 쓸 수는 있지만 무조건 좋은 선택은 아님
- 가장 큰 문제는 동일 리소스를 두 도구가 동시에 관리하는 상황
- 이 경우 reconciliation 충돌, 소유권 불명확, 운영 혼선 발생 가능성
EKS CI/CD 구상해보기
기본 구조
Source Repo
↓
CI Pipeline
↓
Unit Test / Build
↓
Docker Build
↓
ECR Push
↓
Manifest Repo Update
↓
ArgoCD / FluxCD Sync
↓
EKS Deploy
Git 저장소 분리 방식 (회사마다 부서의 역할에 따라 달라질것 같음)
| 저장소 | 내용 |
|---|
| app-repo | 애플리케이션 소스 코드 |
| infra-repo | Terraform, EKS, VPC, IAM |
| gitops-repo | Helm values, Kustomize, ArgoCD Application, Flux Kustomization |
| platform-repo | 공통 모듈, 템플릿, 정책 |
브랜치 전략 예시
| 브랜치 | 환경 |
|---|
| dev | 개발 환경 |
| stg | 검증 환경 |
| prd | 운영 환경 |
테넌트 온보딩 구조
목표
- 신규 테넌트 생성 시 반복 작업 최소화
- 동일한 인프라와 애플리케이션 구조 제공
- 테넌트별 설정값만 분리
- 운영자 승인 흐름 유지
- 생성 이력 Git에 보존
온보딩 흐름
신규 테넌트 요청
↓
tenant_id 발급
↓
GitOps Repo에 tenant 디렉터리 추가
↓
Terraform CRD 추가
↓
Helm values 추가
↓
Pull Request 생성
↓
리뷰 및 승인
↓
Flux 또는 ArgoCD 동기화
↓
AWS 리소스 및 Kubernetes 리소스 생성
생성 대상
| 영역 | 리소스 |
|---|
| Kubernetes | Namespace, ServiceAccount, Role, RoleBinding, Secret |
| AWS | SQS, DynamoDB, IAM Policy, IRSA Role, SSM Parameter |
| GitOps | Kustomization, HelmRelease, Application |
| Observability | Dashboard, Alert Rule, Log Query |
| Network | Ingress, Security Group, NetworkPolicy |
보안과 거버넌스
TODO : AWS 컨피그, 컨트롤 타워등을 사용할 수 있는 방안?
핵심 원칙
- 최소 권한
- Git 기반 승인
- 운영 환경 직접 접근 제한
- Secret 평문 저장 금지
- 테넌트별 권한 경계 분리
- 배포 권한과 인프라 생성 권한 분리
주요 보안 요소
| 영역 | 적용 방식 |
|---|
| AWS 권한 | IRSA 사용 |
| Kubernetes 권한 | RBAC, Namespace 분리 |
| Secret | External Secrets, SOPS, Sealed Secrets |
| Policy | Kyverno, OPA Gatekeeper |
| 이미지 보안 | ECR Scan, Trivy, Grype |
| 네트워크 | NetworkPolicy, Security Group |
| 감사 | Git 로그, CloudTrail, Kubernetes Audit Log |
IRSA 복습
- Pod가 AWS 리소스에 접근할 때 노드 IAM Role을 공유하지 않는 구조
- ServiceAccount와 IAM Role을 연결하여 권한 범위 축소
- 테넌트별 AWS 접근 권한 분리에 유리
- SQS, DynamoDB, S3 접근 권한을 서비스 단위로 제어 가능
정리
- GitOps는 배포 자동화의 기본 구조
- Argo CD는 배포 관리 중심
- Flux는 Kubernetes 네이티브 접근
- Argo Rollouts는 배포 전략 고도화
- Image Updater는 CD 자동화 보완
- GitOps Bridge는 전체 플랫폼 구성
- 역할별 도구 조합이 핵심
- EKS 기반 SaaS에서는 GitOps, Terraform, Helm, IRSA, 멀티테넌시 설계를 함께 봐야 하는 구조
- ArgoCD는 운영 가시성과 생태계 확장에 강점
- FluxCD는 자동화와 멀티테넌시 구조에 강점
- Terraform과 Tofu Controller는 인프라 생성까지 GitOps 흐름에 넣는 방식
- 중요한 것은 도구 선택보다 책임 경계, Git 구조, 권한 모델, 운영 기준
- 플랫폼 엔지니어링은 추상화를 통한 생산성 확보 전략
- GitOps는 이를 구현하는 핵심 메커니즘
- EKS + Flux 기반 구조는 멀티테넌트 SaaS에 최적화된 패턴
- ArgoCD는 운영자가 배포 상태를 명확히 보고 제어해야 하는 환경에 적합
- FluxCD는 선언형 자동화와 테넌트 단위 반복 생성에 적합
- Argo Rollouts, Argo Image Updater, ApplicationSet을 함께 사용하면 ArgoCD 생태계 기반의 배포 플랫폼 구성 가능
- 핵심은 자동화, 일관성, 확장성 확보
- 단순히 도구를 붙이는 것이 아니라 Git 저장소 구조, 권한, 테넌트 경계, 운영 프로세스를 함께 설계하는 것이 핵심
