[DevOps/Kubernetes] 쿠버네티스 배포 자동화의 표준 : GitOps와 ArgoCD 패턴

Об этом предложении

쿠버네티스(Kubernetes) 환경이 보편화되면서 애플리케이션 빌드 및 테스트를 넘어 "클러스터에 매니페스트(YAML)를 어떻게 안전하고 일관성 있게 반영할 것인가?"가 데브옵스(DevOps)의 핵심 과제로 떠올랐습니다. 과거에는 Jenkins나 GitHub Actions 같은 CI/CD 도구에서 kubectl apply 명령어로 클러스터에 직접 명령을 내리는 Push 방식 을 주로 사용했지만, 이는 보안 및 상태 동기화 측면에서 명확한 한계를 지니고 있었습니다. 이를 극복하기 위해 등장한 개념이 바로 GitOps(깃옵스)이며, 현업에서 가장 널리 쓰이는 실행 주체가 바로 ArgoCD 입니다. 이번 글에서는 기존 Push 기반 CI/CD의 한계점과 GitOps의 Pull 기반 아키텍처, 그리고 ArgoCD의 내부 동작 원리를 완벽하게 파헤쳐 봅니다. 1. 기존 Push 기반 CI/CD의 한계점 전통적인 Push 기반 파이프라인에서는 외부의 CI/CD 러너(Runner)가 쿠버네티스 클러스터의 API Server에 직접 접근합니다. [ Developer ] ──> [ Git Repo ] ──> [ CI Server (Jenkins/GitHub Actions) ] │ ▼ (Push: kubectl apply) [ K8s API Server ] 🔴 문제점 보안 리스크 (클러스터 권한 노출) CI 서버가 kubectl 명령을 실행하려면 쿠버네티스 접근 자격 증명( kubeconfig 또는 ServiceAccount Token)을 갖고 있어야 합니다. 만약 외부 CI 서버가 해킹당하면 쿠버네티스 클러스터 전체가 위험에 노출됩니다. 상태 불일치 (Drift) 감지 불가능 누군가 실수나 긴급 대응으로 kubectl edit 이나 kubectl delete 명령어를 통해 클러스터 리소스를 직접 변경(수동 조작)하더라도, CI 서버는 이를 감지하거나 원상복구(Self-healing)할 수 없습니다. 히스토리 추적 및 롤백의 어려움 현재 클러스터에 실제 배포되어 있는 정확한 YAML 매니페스트 상태가 Git 저장소의 버전과 100% 일치한다고 보장하기 어렵습니다. 2. GitOps 패러다임 : Pull 기반 아키텍처 GitOps 는 "Git을 단 하나의 진실의 원천(Single Source of Truth)으로 삼는다"는 철학입니다. 쿠버네티스 클러스터 내부에 배포 에이전트(ArgoCD)를 띄워두고, 에이전트가 Git 저장소를 감시하며[Git에 선언된 상태(Desired State)]와 [실제 클러스터 상태(Actual State)]를 비교하여 자동으로 동기화(Sync)합니다. [ Developer ] ──> [ App Code Repo ] ──> [ CI (Build & Docker Push) ] │ ▼ (Image Tag Update PR) [ Manifest Git Repo ] <──┐ │ Scrape / Poll (Pull 방식) [ K8s Cluster ] │ └── [ ArgoCD Agent ] ─────┘ ──> [ Sync K8s Resources ] 🟢 GitOps의 4가지 핵심 원칙 전체 시스템의 선언적 명세 : K8s 매니페스트, Helm Chart, Kustomize 등을 이용해 선언적(Declarative) 코드로 관리합니다. Git을 통한 단일 진실의 원천 : 원하는 인프라/앱 상태는 오직 Git 커밋으로만 정의됩니다. 자동화된 변경사항 반영 : Git에 커밋이 생성되면 클러스터 내부 에이전트가 이를 알아서 끌어옵니다(Pull). 지속적인 상태 비교 및 자가 치유(Self-Healing) : 실제 클러스터 상태가 Git과 다르면 알람을 발송하거나 Git 상태로 원복시킵니다. 3. ArgoCD의 구조와 핵심 동작 원리 ArgoCD는 쿠버네티스 전용 오픈소스 declarative GitOps CD 도구입니다. ┌─────────────────────────────────────────────────────────────────┐ │ ArgoCD Architecture │ │ │ │ [ Git / Helm Repo ] <─── (Fetch) ──── [ Repo Server ] │ │ │ │ │ ▼ │ │ [ API Server / UI ] ───────────────> [ Application Controller ]│ │ │ (Sync / Heal) │ │ ▼ │ │ [ K8s API Server ] │ └─────────────────────────────────────────────────────────────────┘ ArgoCD 핵심 컴포넌트 3가지 API Server Web UI, CLI, gRPC 요청을 처리하는 중앙 엔드포인트입니다. 애플리케이션 상태 조회, 배포 요청(Sync) 등을 수신합니다. Repository Server (Repo Server) 외부 Git 저장소나 Helm 저장소와 통신하며, 매니페스트 파일을 로컬에 캐싱하고 Kustomize/Helm 템플릿을 실제 K8s YAML로 렌더링(Build)합니다. Application Controller (핵심 엔진) 주기적으로 K8s 클러스터의 실제 리소스 상태 와 Repo Server나 파싱한 Git의 원하는 상태 를 비교(Diff)하는 컨트롤러 루프를 돕니다. 불일치 발생 시 상태를 OutOfSync 로 표시하고, 설정에 따라 Auto-Sync 및 Self-Healing 을 수행합니다. 4. 실무 패턴 : CI와 CD 저장소의 완벽한 분리 실무에서는 어플리케이션 소스 코드 저장소 와 K8s 배포 매니페스트 저장소 를 반드시 분리합니다. 1. App Repo (Node.js/Spring) ──(Git Tag)──> CI Pipeline (Docker Build & Push) │ 2. Manifest Repo (K8s YAML) <──(Image Tag Update)┘ │ ▼ (Git Commit / PR) 3. ArgoCD ──(Auto Sync)──> K8s Cluster App Repo (CI 영역) 개발자가 코드를 작성하고 Push합니다. CI(GitHub Actions)가 유닛 테스트를 수행하고 Docker 이미지를 빌드해 레지스트리(ECR, DockerHub 등)에 v1.2.0 태그로 푸시합니다. CI 파이프라인의 마지막 단계에서 Manifest Repo의 values.yaml 또는 deployment.yaml 파일의 이미지 태그를 v1.2.0 으로 자동 수정 하는 Git 커밋을 남깁니다. Manifest Repo (CD 영역) 순수하게 K8s YAML / Helm / Kustomizae 파일만 관리되는 저장소입니다. ArgoCD는 오직 이 Manifest Repo만 주시하고 있다가 이미지 태그 커밋이 들어오면 클러스터로 신규 버전을 롤아웃합니다. 5. ArgoCD Application 매니페스트 예시 ArgoCD 자체가 쿠버네티스 Custom Resource Definition(CRD)으로 작동하므로, ArgoCD의 배포 규칙 또한 아래와 같이 YAML로 선언합니다. apiVersion: argoproj.io/v1alpha1 kind: Application metadata: name: my-backend-service namespace: argocd spec: project: default # 1. 소스 (Git 저장소 설정) source: repoURL: 'https://github.com/my-org/k8s-manifests.git' targetRevision: HEAD path: 'envs/production' # Kustomize 또는 Helm 경로 # 2. 타겟 (배포할 K8s 클러스터 설정) destination: server: 'https://kubernetes.default.svc' # 내부 클러스터 namespace: production # 3. 동기화 정책 (Sync Policy) syncPolicy: automated: prune: true # Git에서 삭제된 리소스는 K8s 클러스터에서도 자동 삭제 selfHeal: true # K8s 수동 변경 발생 시 Git 상태로 자동 원복 syncOptions: - CreateNamespace=true # 네임스페이스 없으면 자동 생성 💡 마무리하며 GitOps 패러다임과 ArgoCD의 도입은 단순한 배포 자동화를 넘어, 쿠버네티스 인프라 전체의 가시성과 보안성을 한 차원 끌어올리는 혁신적인 접근법 입니다. CI와 CD의 경계를 명확히 분리하고, 모든 클러스터 변경 이력을 Git의 커밋 히스토리로 관리함으로써, 복잡한 분산 환경에서도 안심하고 스케일 아웃할 수 있는 현대적인 클라우드 네이티브 파이프라인을 구축할 수 있습니다.