ArgoCD 기반 쿠버네티스 선언적 배포 아키텍처 및 동기화 전략

운영 환경(Production)의 클러스터 상태가 버전 관리 시스템(Git)의 정의와 일치하지 않는 '구성 표류(Configuration Drift)' 현상은 시스템 장애의 주된 원인 중 하나입니다. 개발자가 로컬에서 kubectl apply로 임의 변경하거나, 긴급 핫픽스 후 코드를 커밋하지 않는 경우, 인프라의 가시성은 즉시 상실됩니다. GitOps는 Git을 유일한 진실 공급원(Single Source of Truth)으로 격상시키며, ArgoCD는 이를 쿠버네티스 네이티브 방식으로 구현하는 핵심 도구입니다. 본 문서에서는 기존 Push 기반 CI/CD 파이프라인의 보안 및 일관성 문제를 분석하고, ArgoCD를 이용한 Pull 기반 아키텍처의 기술적 구현 상세를 다룹니다.

Push 모델의 한계와 Pull 모델(GitOps)로의 전환

전통적인 CI/CD 파이프라인(Jenkins, GitLab CI 등)은 빌드 서버가 클러스터의 API 서버에 직접 접근하여 명령을 실행하는 'Push 모델'을 따릅니다. 이 방식은 클러스터의 admin 자격 증명을 외부 CI 시스템에 노출해야 하므로 보안 경계(Security Boundary)가 모호해지는 구조적 결함을 가집니다.

보안 리스크: CI 도구가 해킹당할 경우, 연결된 모든 프로덕션 클러스터의 제어권이 탈취될 수 있습니다. 또한, 파이프라인 외부에서 발생한 kubectl 변경 사항을 CI 도구가 감지하거나 되돌릴 수 없습니다.

반면, ArgoCD와 같은 'Pull 모델' 에이전트는 클러스터 내부에서 동작합니다. 외부에서의 접근을 허용하지 않고 오직 Git 저장소의 변경 사항(Manifest)을 주기적으로 폴링(Polling)하여 현재 상태를 목표 상태(Desired State)와 일치시킵니다. 이는 네트워크 인바운드 포트를 열 필요가 없으며, 자격 증명 관리가 클러스터 내부로 국한됨을 의미합니다.

특성 Push 모델 (Jenkins/GitLab CI) Pull 모델 (ArgoCD/Flux)
배포 주체 외부 CI 서버가 클러스터로 전송 클러스터 내부 컨트롤러가 Git을 가져옴
보안 자격 증명 CI 서버에 Kubeconfig 저장 (위험) 클러스터 내부 ServiceAccount 사용 (안전)
Drift 감지 불가능 (배포 시점에만 확인) 실시간 감지 및 자동 복구 (Self-Healing)
가시성 파이프라인 로그에 의존 현재 클러스터 상태와 Git의 차이 시각화

ArgoCD Application CRD와 동기화 메커니즘

ArgoCD의 핵심은 Application이라는 커스텀 리소스 정의(CRD)입니다. 이 리소스는 '어떤 소스(Git)'를 '어떤 목적지(Cluster/Namespace)'에 배포할지 정의합니다. 단순한 배포를 넘어, 자동 동기화(Auto-Sync)와 가지치기(Pruning), 그리고 자가 치유(Self-Healing) 정책을 명시적으로 선언해야 합니다.

다음은 프로덕션 레벨에서 권장되는 고가용성 설정을 포함한 Application 매니페스트 예시입니다.

apiVersion: argoproj.io/v1alpha1
kind: Application
metadata:
  name: payment-service-prod
  namespace: argocd
  finalizers:
    # 애플리케이션 삭제 시 관리하던 리소스도 함께 삭제 (Cascading Deletion)
    - resources-finalizer.argocd.argoproj.io
spec:
  project: production-core
  source:
    repoURL: 'https://github.com/my-org/infra-manifests.git'
    targetRevision: HEAD
    path: k8s/overlays/prod
    # Helm 또는 Kustomize 자동 감지, 여기서는 디렉토리 재귀 탐색 예시
    directory:
      recurse: true
  destination:
    server: 'https://kubernetes.default.svc'
    namespace: payment-prod
  
  # 동기화 정책 (핵심 구성)
  syncPolicy:
    automated:
      # Git 변경 시 자동 배포 여부
      prune: true      # Git에 없는 리소스는 클러스터에서 삭제
      selfHeal: true   # 수동 변경(Drift) 발생 시 강제로 Git 상태로 복구
    
    syncOptions:
      - CreateNamespace=true  # 네임스페이스가 없으면 생성
      - PrunePropagationPolicy=foreground # 종속 리소스 삭제 순서 보장
      - ServerSideApply=true  # 대규모 리소스 처리를 위한 SSA 활성화 (Kubernetes 1.18+)
      
    # 재시도 전략: 네트워크 일시 장애 등에 대응
    retry:
      limit: 5
      backoff:
        duration: 5s
        factor: 2
        maxDuration: 3m

동기화 웨이브(Sync Waves)와 훅(Hooks)을 이용한 배포 순서 제어

마이크로서비스 아키텍처에서는 서비스 간의 의존성이나 데이터베이스 마이그레이션 순서가 중요합니다. 쿠버네티스의 기본 배포는 병렬적이지만, ArgoCD는 argocd.argoproj.io/sync-wave 주석(Annotation)을 통해 배포 순서를 제어할 수 있는 기능을 제공합니다.

  • Sync Wave: 정수 값으로 정의되며, 낮은 숫자에서 높은 숫자로 순차 배포됩니다. ArgoCD는 현재 웨이브의 리소스가 Healthy 상태가 될 때까지 다음 웨이브 진행을 차단(Block)합니다.
  • Resource Hooks: PreSync, Sync, PostSync 등의 단계를 정의하여, DB 스키마 마이그레이션이나 슬랙 알림 전송 등을 배포 수명주기 내에 통합할 수 있습니다.

설계 팁: 일반적으로 Namespace나 RBAC 설정은 Wave -1, ConfigMap/Secret은 Wave 0, Deployment는 Wave 1, Ingress는 Wave 2로 설정하여, 애플리케이션이 뜨기 전에 환경 설정이 완벽히 준비되도록 보장합니다.

GitOps의 난제: Secret 관리 전략

GitOps의 가장 큰 딜레마는 "보안이 필요한 Secret을 공개된 Git에 어떻게 저장할 것인가"입니다. Plain Text로 저장하는 것은 보안 규정 위반입니다. 이를 해결하기 위해 엔터프라이즈 환경에서는 주로 두 가지 접근 방식을 사용합니다.

  1. Sealed Secrets (Bitnami): 비대칭 암호화를 사용합니다. 개발자는 로컬에서 공개키로 Secret을 암호화하여 Git에 커밋하고, 클러스터 내부의 컨트롤러만이 개인키를 사용하여 이를 복호화합니다.
  2. External Secrets Operator (ESO): Git에는 Secret을 저장하지 않고, AWS Secrets Manager나 HashiCorp Vault 같은 외부 비밀 관리 시스템을 참조하는 ExternalSecret CRD만 저장합니다. 실제 값은 런타임에 주입됩니다.

대규모 프로덕션 환경에서는 중앙 집중식 감사와 로테이션이 용이한 External Secrets Operator 방식이 선호되는 추세입니다.

멀티 클러스터 확장: ApplicationSet

수십, 수백 개의 마이크로서비스를 여러 클러스터(Dev, Staging, Prod-KR, Prod-US)에 배포해야 할 때, 개별 Application 리소스를 하나씩 관리하는 것은 비효율적입니다. ArgoCD의 ApplicationSet 컨트롤러는 템플릿과 생성기(Generator)를 사용하여 이러한 반복 작업을 자동화합니다.

예를 들어, 'Git 디렉토리 구조'나 '클러스터 라벨'을 기반으로 동적으로 Application 리소스를 생성할 수 있습니다. 이는 "새로운 클러스터가 등록되면 자동으로 모니터링 에이전트와 보안 정책을 배포한다"는 인프라 수준의 자동화를 가능하게 합니다.

아키텍처 권장사항: ArgoCD 자체를 관리하는 'App of Apps' 패턴이나 ApplicationSet을 활용하여, ArgoCD 설정 자체도 GitOps로 관리해야 합니다. 이를 통해 재해 복구(DR) 시 새로운 클러스터에 ArgoCD만 설치하면 전체 인프라가 자동으로 복원되는 체계를 구축할 수 있습니다.

결론적으로 ArgoCD를 활용한 GitOps는 단순한 도구의 도입이 아니라, 운영 프로세스의 패러다임 전환입니다. 명령형(Imperative) 작업에서 선언형(Declarative) 상태 관리로의 이동은 휴먼 에러를 제거하고, 배포 속도와 시스템 안정성 사이의 트레이드오프를 해결하는 가장 강력한 아키텍처 패턴입니다. 조직은 자동 동기화 정책, Secret 관리, 그리고 멀티 클러스터 전략을 수립하여 진정한 의미의 지속적 배포(CD)를 실현해야 합니다.

Related Posts

Loading…

Post a Comment