스터디(Study)/CI·CD Study

예제로 배우는 Argo CD 3장: Argo CD 운영

Chann._.y 2025. 11. 8.

728x90

고가용성과 실전 운영 전략

1·2장에서 GitOps의 개념과 Argo CD의 기본 원리를 다뤘다면, 이번 장에서는 실제 운영 환경에서 Argo CD를 안정적이고 효율적으로 운용하는 방법을 살펴본다.
운영 환경에서는 단일 인스턴스로는 충분하지 않으며, 고가용성(HA) 구성, 모니터링, 자동 동기화 제어, 재해 복구(Disaster Recovery) 전략이 필수적이다.

1. 고가용성(HA) 구성의 필요성

Argo CD는 단일 Pod로도 실행 가능하지만, 프로덕션 환경에서는 장애 복원력 확보가 필수다.
특히 Application Controller와 Repo Server는 지속적으로 Git과 클러스터를 비교하기 때문에, 단일 장애로도 배포 전체가 중단될 수 있다.

HA 모드의 핵심 개념

Controller / Repo-server / API Server 모두 다중 복제로 구성해야 한다.
Redis 캐시를 활용하며, Redis Sentinel 구조로 장애 감지와 자동 페일오버를 지원한다.
PostgreSQL 또는 외부 DB를 연결해 영속 데이터를 관리한다.

2. HA 모드 클러스터 구성 예시

테스트 환경에서는 kind를 활용해 1개의 컨트롤 플레인과 3개의 워커 노드를 구성할 수 있다.

kind create cluster --name myk8s --image kindest/node:v1.32.8 --config - <<EOF
kind: Cluster
apiVersion: kind.x-k8s.io/v1alpha4
nodes:
- role: control-plane
  extraPortMappings:
  - containerPort: 30000
    hostPort: 30000
  - containerPort: 30001
    hostPort: 30001
  - containerPort: 30002
    hostPort: 30002
  - containerPort: 30003
    hostPort: 30003
- role: worker
- role: worker
- role: worker
EOF

구성 확인용 시각화 도구

운영 중 노드 상태를 시각적으로 모니터링하기 위해 kube-ops-view를 설치한다.

helm repo add geek-cookbook https://geek-cookbook.github.io/charts/
helm install kube-ops-view geek-cookbook/kube-ops-view \
  --version 1.2.2 \
  --set service.main.type=NodePort,service.main.ports.http.nodePort=30001 \
  --set env.TZ="Asia/Seoul" \
  --namespace kube-system

브라우저 접속:

http://127.0.0.1:30001/#scale=2

3. Argo CD HA 구성 방식

3.1 핵심 구성 요소

구성요소 역할 HA 구성 방법

API Server	사용자 요청 및 인증 처리	Deployment → Replica 2 이상
Repository Server	깃 리포지터리 캐싱	Deployment → Replica 2 이상
Application Controller	클러스터 상태 감시 및 동기화	StatefulSet → Leader Election 사용
Redis	캐시/세션 관리	Redis Sentinel 구성
Database (PostgreSQL)	상태 저장	외부 Managed DB 또는 StatefulSet 구성

3.2 주의 사항

Repo Server는 CPU를 많이 사용하므로 HPA 설정 고려
Controller는 “동기화 루프”의 핵심이므로 Leader Election이 필요
Redis HA는 Sentinel이 감시하며, 마스터 장애 시 자동 승격

자세한 내용: Argo CD 공식 HA 가이드

4. 모니터링 및 관찰성

4.1 kube-ops-view

간단한 시각화용 Helm 차트. Pod와 Node의 상태를 웹으로 확인할 수 있다.

4.2 Prometheus & Grafana

Argo CD는 /metrics 엔드포인트를 통해 Prometheus 메트릭을 노출한다.
이를 통해 다음을 관찰할 수 있다.

애플리케이션 동기화 상태 (argocd_app_sync_total)
실패율 (argocd_app_sync_failed_total)
컨트롤러 이벤트 지연 시간 (argocd_reconcile_duration_seconds)
동기화 대기열 길이

Grafana에서는 Argo용 대시보드를 가져와 시각화할 수 있다.

5. 동기화 Hooks와 Waves

Argo CD의 동기화(Sync) 과정은 단순한 kubectl apply 이상의 단계를 거친다.
세부적인 단계는 다음과 같다.

5.1 Hook 단계

단계 설명

PreSync	리소스 적용 전 실행 (예: Config 준비, 백업 등)
Sync	매니페스트를 적용하는 단계
PostSync	리소스 적용 후 실행 (예: 알림, 검증, 테스트 등)

Hook은 쿠버네티스 Job, Pod, Script 등으로 정의 가능하다.

예시:

apiVersion: batch/v1
kind: Job
metadata:
  name: backup-before-sync
  annotations:
    argocd.argoproj.io/hook: PreSync
spec:
  template:
    spec:
      containers:
      - name: backup
        image: alpine
        command: ["/bin/sh", "-c", "echo Backing up before sync..."]
      restartPolicy: Never

5.2 Sync Waves

Hook이나 리소스가 동시에 실행되지 않도록 Wave 번호를 지정할 수 있다.

metadata:
  annotations:
    argocd.argoproj.io/sync-wave: "1"

Wave 0 → Wave 1 → Wave 2 순서대로 순차 실행된다.
이는 “App of Apps”나 다중 서비스 배포 시 종속 순서를 제어할 때 유용하다.

참고 예시: Argo CD Sync Waves Example

6. 재해 복구(Disaster Recovery)

운영 환경에서는 GitOps의 장점 중 하나가 DR(Disaster Recovery) 구조다.
Git 리포지터리 자체가 상태 정의를 보존하므로, 복구 시 단순히 새 클러스터에 Argo CD를 배포하고 리포지터리를 연결하면 된다.

복구 절차 개요

기존 클러스터 장애 감지
새 클러스터 생성
Argo CD 재설치 (Helm 또는 Autopilot)
동일한 Git 리포지터리 연결
자동 동기화 → 기존 상태 복원

이 과정을 통해 인프라를 코드로 복원할 수 있다.
이는 전통적인 백업/복구 접근과는 달리, 선언적 복원의 장점을 제공한다.

7. 정리

항목 내용

HA 구성 목적	장애 복원력, 운영 안정성
주요 구성 요소	API Server, Repo Server, Controller, Redis, DB
관찰성 도구	kube-ops-view, Prometheus, Grafana
동기화 확장 기능	Hook, Sync Waves
복구 전략	Git 리포지터리 기반 선언적 복원

개인적인 인사이트

Argo CD의 Application Controller는 GitOps 철학을 실제로 실행하는 두뇌 역할을 한다.
고가용성 구조는 단순히 안정성 확보가 아니라 운영의 지속성을 보장한다.
재해 복구의 핵심은 백업이 아니라 “코드화된 선언적 상태”다.
GitOps의 진정한 힘은 운영 중단 이후에도 동일한 상태를 자동 복원할 수 있다는 점이다.