[cicd] cloudeNet Study 4주차 - ArgoCD

진웅·2025년 11월 8일

CI/CD

목록 보기

3/7

주요 정리 내용

gitOps Operator 실습

ArgoCD 와 operator 비교

ArgoCD 핵심 구성 요소

ArgoCD 실습 & 도전과제 (진행중)

ArgoCD 이전에 간단 go 를 이용한 gitOps operator 실습해보자

git source

코드: https://github.com/PacktPublishing/ArgoCD-in-Practice
실행 예시

riverjin@gangjin-ung-ui-Macmini basic-gitops-operator % go run main.go
go: downloading github.com/go-git/go-git/v5 v5.4.2
go: downloading github.com/go-git/go-billy/v5 v5.3.1
go: downloading github.com/ProtonMail/go-crypto v0.0.0-20210428141323-04723f9f07d7
go: downloading github.com/sergi/go-diff v1.1.0
go: downloading github.com/imdario/mergo v0.3.12
go: downloading github.com/emirpasic/gods v1.12.0
go: downloading github.com/jbenet/go-context v0.0.0-20150711004518-d14ea06fba99
go: downloading github.com/mitchellh/go-homedir v1.1.0
go: downloading golang.org/x/sys v0.0.0-20210616094352-59db8d763f22
go: downloading github.com/kevinburke/ssh_config v0.0.0-20201106050909-4977a11b4351
go: downloading github.com/xanzy/ssh-agent v0.3.0
go: downloading golang.org/x/crypto v0.0.0-20210421170649-83a5a9bb288b
go: downloading golang.org/x/net v0.0.0-20210520170846-37e1c6afe023
go: downloading github.com/go-git/gcfg v1.5.0
go: downloading gopkg.in/warnings.v0 v0.1.2
start repo sync
Enumerating objects: 1261, done.
start repo sync
Enumerating objects: 1261, done.
Counting objects: 100% (125/125), done.
Compressing objects: 100% (32/32), done.
Total 1261 (delta 99), reused 97 (delta 93), pack-reused 1136 (from 1)
start manifests apply
namespace/nginx created
Error from server (NotFound): error when creating "/Users/riverjin/cicd-study/ArgoCD-in-Practice/ch01/basic-gitops-operator/tmp/ch01/basic-gitops-operator-config/deployment.yaml": namespaces "nginx" not found
manifests apply error: exit status 1
 next sync in 5s 
start repo sync
start manifests apply
deployment.apps/nginx created
namespace/nginx unchanged

 next sync in 5s 
start repo sync
start manifests apply
deployment.apps/nginx unchanged
namespace/nginx unchanged

 next sync in 5s 
start repo sync
start manifests apply
deployment.apps/nginx unchanged
namespace/nginx unchanged

테스트 내용 :

기본적인 GitOps 운영자(Operator)의 동작 원리와 선언적 인프라 관리(Declarative Infrastructure Management) 의 핵심 개념을 실습
GitOps의 핵심 = 코드로 정의된 상태와 실제 인프라의 지속적 동기화"**

1. 테스트의 전체 흐름

2. 각 단계별 의미 해석

(1) Go 기반 GitOps Operator 실행

go run main.go

의미:
사용자가 직접 구현한 간단한 GitOps 운영자를 실행합니다.
- main.go는 Git 저장소(또는 로컬 매니페스트)를 주기적으로 동기화(sync)하고,
- 변경 사항을 Kubernetes 클러스터에 적용(apply)하는 역할을 합니다.

출력 분석:

start repo sync         # Git 저장소 동기화 시작
start manifests apply   # 매니페스트 적용 시작
deployment.apps/nginx unchanged  # 변경 없음 (이미 존재)
namespace/nginx unchanged        # 변경 없음 (이미 존재)
next sync in 5s        # 5초 후 재동기화 예약

"unchanged": 클러스터 상태가 이미 매니페스트와 일치하므로 추가 작업 불필요.
5초 주기 반복: 지속적인 상태 감시 및 동기화 (GitOps의 핵심).

(2) 배포 상태 확인

kubectl get deploy,pod -n nginx

의미:
GitOps Operator가 적용한 매니페스트가 실제 클러스터에 정상적으로 배포되었는지 검증합니다.

결과 해석:

NAME                    READY   UP-TO-DATE   AVAILABLE   AGE
deployment.apps/nginx   1/1     1            1           63s  # 배포 성공

NAME                         READY   STATUS    RESTARTS   AGE
pod/nginx-5869d7778c-229mz   1/1     Running   0          63s  # 파드 실행 중

READY 1/1: 배포된 파드가 정상 상태임을 의미.
GitOps 목표 달성: 코드(매니페스트) → 클러스터 상태 일치.

(3) 강제 리소스 삭제 및 복구 테스트

kubectl delete deploy -n nginx nginx

의미:
수동으로 리소스를 삭제하여 GitOps의 자동 복구(Self-Healing) 기능을 검증합니다.
예상 동작:
1. 사용자가 nginx 배포를 삭제.
2. GitOps Operator가 5초 후 다음 동기화를 실행.
3. 매니페스트와 실제 상태 불일치 감지.
4. 삭제된 리소스를 자동으로 재생성.

검증 방법:

# 삭제 후 5초 이내에 다시 확인
kubectl get deploy -n nginx
# 출력: deployment.apps/nginx가 다시 생성됨

3. 테스트의 핵심 의미

(1) GitOps의 기본 원리 실현

선언적 관리:
basic-gitops-operator-config 디렉터리의 YAML 파일이 "원하는 상태(Desired State)" 를 정의합니다.
자동 동기화:
Go 프로그램이 주기적으로 상태를 비교하고, 불일치 시 자동으로 복구합니다.
단일 진실 공급원(Single Source of Truth):
Git 저장소(또는 로컬 매니페스트)가 인프라의 유일한 기준이 됩니다.

(2) GitOps 도구의 간소화 버전

Argo CD/Flux와의 유사성:
이 테스트는 상용 GitOps 도구(Argo CD, Flux)의 최소 기능 버전을 구현합니다.
- Argo CD의 Auto-Sync 모드와 동일한 동작.
- Flux의 GitRepository + Kustomization 리소스와 유사한 역할.

(3) 운영 효율성 검증

자동 복구(Self-Healing):
수작업으로 삭제된 리소스가 자동으로 복구되는 것을 확인함으로써:
- 인적 실수로 인한 장애 감소.
- 상태 일치성 보장.
주기적 감시:
5초마다 상태를 확인하므로 실시간에 가까운 복구가 가능합니다.

4. 실제 환경에서의 활용 시나리오

이 테스트는 다음과 같은 실제 사례에 적용될 수 있습니다:
1. CI/CD 파이프라인 통합:

코드 배포 시 Git 저장소에 매니페스트를 푸시하면, GitOps Operator가 자동으로 클러스터를 업데이트.

멀티 클러스터 관리:
- 여러 Kubernetes 클러스터에 동일한 구성을 일괄 적용.
드리프트(Drift) 방지:
- 클러스터 상태가 Git 정의와 달라지는 경우 즉시 복구 (보안 정책 준수 등).

5. 한계 및 개선 방향

한계점	개선 방안
로컬 매니페스트만 사용	Git 저장소 연동 (e.g., `git clone` 추가)
고정된 5초 주기	이벤트 기반 트리거 (e.g., Kubernetes Watch API)
단순 상태 비교	헬스 체크(Health Check) 및 롤백 기능 추가
에러 핸들링 부재	로깅 및 알림 시스템 연동

결론

이 테스트는 "GitOps의 핵심 = 코드로 정의된 상태와 실제 인프라의 지속적 동기화" 를 경험하게 합니다.

성공 기준:
수동으로 삭제한 리소스가 자동으로 복구되는 것을 확인함으로써 GitOps의 자기 치유(Self-Healing) 능력을 검증합니다.
교육적 가치:
복잡한 GitOps 도구 없이도 Go의 간단한 코드로 핵심 개념을 구현해보며, 선언적 인프라 관리의 원리를 체득할 수 있습니다.

ArgoCD와 비교해보자

ArgoCD와 간단한 GitOps 운영자 비교

아래 테스트에서 구현한 간단한 GitOps 운영자와 ArgoCD의 핵심 차이점을 기능, 아키텍처, 사용 사례 중심으로 비교합니다.

1. 아키텍처 비교

구분	간단한 GitOps 운영자 (테스트용)	ArgoCD
구성 요소	단일 Go 바이너리 (`main.go`)	마이크로서비스 아키텍처 (API Server, Repo Server, Application Controller, Redis)
상태 저장소	로컬 파일 시스템 (`basic-gitops-operator-config`)	Kubernetes CRD (Custom Resource Definition)
동기화 방식	고정된 주기 폴링 (5초 간격)	폴링 (기본 3분) + 웹훅 기반 실시간 트리거
Git 연동	로컬 매니페스트만 지원	Git/S3/Helm Chart/Kustomize 등 다양한 소스 지원
확장성	단일 클러스터, 단순 배포용	멀티 클러스터, 복잡한 배포 파이프라인 지원

2. 기능 비교

기능	간단한 GitOps 운영자	ArgoCD
자동 복구(Self-Healing)	✅ (기본 구현)	✅ (고급 설정 가능: `selfHeal` 옵션)
UI/대시보드	❌ (CLI 전용)	✅ (풍부한 웹 UI: 애플리케이션 상태, 동기화 이력)
상태 비교	단순 리소스 존재 여부 확인	드리프트(Drift) 감지: 상세한 상태 차이 분석
롤백	수동으로 Git 되돌림 필요	✅ (UI/CLI로 한 클릭 롤백)
알림	❌	✅ (Slack, Email 등 다양한 알림 채널)
RBAC	❌	✅ (세분화된 역할 기반 접근 제어)
Helm/Kustomize 지원	❌ (순수 YAML)	✅ (Helm, Kustomize, Jsonnet 등 템플릿 지원)
멀티 테넌시	❌	✅ (프로젝트 단위 격리)

3. 사용 사례 비교

시나리오	간단한 GitOps 운영자	ArgoCD
학습용/프로토타입	✅ (간단한 구현으로 개념 이해)	⚠️ (설치 및 설정 복잡)
프로덕션 환경	❌ (보안/모니터링 부재)	✅ (CNCF 졸업 프로젝트, 엔터프라이즈급 안정성)
복잡한 배포	❌ (단순 YAML만 지원)	✅ (Helm 차트, Kustomize 오버레이 등)
멀티 클러스터 관리	❌	✅ (하나의 ArgoCD로 여러 클러스터 관리)
팀 협업	❌	✅ (UI 기반 협업, 감사 로그)

4. 핵심 차이점 요약

(1) 단순성 vs. 확장성

간단한 운영자:
- 장점: GitOps의 핵심 개념(자동 복구, 선언적 관리)을 최소 코드로 구현 가능.
- 단점: 프로덕션 사용 불가 (모니터링, 보안, 확장성 부재).
ArgoCD:
- 장점: 엔터프라이즈 환경에 필요한 모든 기능 제공 (UI, RBAC, 알림 등).
- 단점: 초기 학습 곡선이 존재.

(2) 동기화 방식

특징	간단한 운영자	ArgoCD
트리거	고정된 주기 폴링 (5초)	폴링 + 웹훅 기반 실시간 동기화
효율성	불필요한 리소스 소모 (주기적 실행)	이벤트 기반으로 리소스 효율적

(3) 상태 관리

간단한 운영자:
- kubectl apply를 통해 단순히 리소스 존재 여부만 확인.
- 드리프트(Drift) 감지 불가 (예: 수동으로 Pod 이미지 변경 시 감지 못 함).
ArgoCD:
- 상태 비교 알고리즘으로 세부적인 드리프트 감지 (예: 이미지 태그, 레플리카 수 변경).
- argocd app diff 명령으로 변경 사항 시각화.

5. ArgoCD로 동일한 시나리오 구현 예시

(1) ArgoCD 설치

kubectl create namespace argocd
kubectl apply -n argocd -f https://raw.githubusercontent.com/argoproj/argo-cd/stable/manifests/install.yaml

(2) 애플리케이션 생성 (`nginx-app.yaml`)

apiVersion: argoproj.io/v1alpha1
kind: Application
metadata:
  name: nginx-app
  namespace: argocd
spec:
  project: default
  source:
    repoURL: 'https://github.com/your-repo/basic-gitops-operator-config.git'  # Git 저장소
    targetRevision: HEAD
    path: .  # 매니페스트 경로
  destination:
    server: 'https://kubernetes.default.svc'
    namespace: nginx
  syncPolicy:
    automated:
      prune: true    # 불필요한 리소스 자동 삭제
      selfHeal: true # 드리프트 자동 복구

(3) 애플리케이션 적용

kubectl apply -f nginx-app.yaml

(4) 상태 확인

argocd app get nginx-app  # 동기화 상태 확인

(5) 수동 삭제 및 자동 복구 테스트

kubectl delete deploy -n nginx nginx

→ ArgoCD가 selfHeal 설정에 따라 3분 내 자동 복구 (웹훅 사용 시 즉시 복구).

6. 결론: 테스트의 의미와 ArgoCD의 가치

테스트의 의미

GitOps의 핵심 원리 체험:
"코드로 정의된 상태"와 "실제 인프라"의 지속적 동기화 및 자기 치유(Self-Healing) 개념을 이해.
단순화된 모델:
복잡한 도구 없이도 GitOps의 본질을 구현해봄으로써 학습 효과 극대화.

ArgoCD의 가치

프로덕션 준비 솔루션:
- 보안: RBAC, 감사 로그, SSO 통합.
- 안정성: 드리프트 감지, 롤백, 헬스 체크.
- 확장성: 멀티 클러스터, 템플릿 엔진 지원.
에코시스템 통합:
CI/CD 파이프라인 (GitHub Actions, Jenkins), 모니터링 (Prometheus), 알림 (Slack)과 연동 가능.

ArgoCD: "GitOps를 실제 환경에 적용하는 엔터프라이즈 도구" 입니다.

구성 드리프트(Configuration Drift)란?

구성 드리프트(Configuration Drift)란?

"시간이 지남에 따라 인프라 자원들이 원래 의도한 상태(코드로 정의된 상태)와 달라지는 현상"
즉, Git 저장소에 정의된 선언적 구성(Desired State)과 실제 운영 환경의 현재 상태(Current State) 사이에 불일치가 발생하는 문제입니다.

운영 상태에서 일어나면 안될 상황이지만, 만약 개발자가 긴급한 상황에 서버 권한 혹은 admin 권한이 있다면 언제든지 일어날 수 있는 상황이라 사료됩니다.

왜 발생하는가? (주요 원인)

1. 수동 변경 (Manual Changes)

예시:
개발자가 긴급 장애 대응으로 kubectl edit deployment를 통해 직접 파드 이미지를 변경하거나,
운영팀이 콘솔에서 클라우드 리소스 설정을 수정하는 경우.
문제:
변경 사항이 Git에 반영되지 않아 코드와 실제 환경이 분리됩니다.

2. 자동화되지 않은 프로세스

예시:
CI/CD 파이프라인이 일부 리소스만 배포하고, 나머지는 수동으로 적용하는 경우.
문제:
부분적 배포로 인해 일부 자원만 최신 상태가 됩니다.

3. 팀 간 소통 부재

예시:
DevOps 팀은 Git 매니페스트를 업데이트했지만, 보안팀이 수동으로 방화벽 규칙을 추가한 경우.
문제:
팀별로 독립적인 변경이 발생해 전체 시스템의 일관성이 깨집니다.

4. 환경별 차이

예시:
개발/스테이징/프로덕션 환경에서 서로 다른 버전의 라이브러리를 사용하는 경우.
문제:
"개발 환경에서는 작동하던 기능이 프로덕션에서 실패"하는 현상 발생.

구체적인 예시로 이해하기

시나리오: Kubernetes 환경에서의 구성 드리프트

(1) 초기 상태 (Git에 정의된 Desired State)

# deployment.yaml (Git 저장소)
apiVersion: apps/v1
kind: Deployment
metadata:
  name: nginx
spec:
  replicas: 3
  template:
    spec:
      containers:
      - name: nginx
        image: nginx:1.21  # 고정된 버전

(2) 드리프트 발생 (수동 변경)

긴급 장애 대응:
운영자가 kubectl edit deployment nginx를 실행해 수동으로 이미지 버전을 변경:
```
image: nginx:1.22  # 임시로 최신 버전으로 변경
```
결과:
Git에는 nginx:1.21로 기록되어 있지만, 실제 클러스터에는 nginx:1.22가 실행 중.

(3) 문제 발생

예측 불가능한 동작:
- 개발자가 nginx:1.21에 의존하는 코드를 배포 → 호환성 오류 발생.
롤백 실패:
- Git으로 롤백 시 nginx:1.21로 복구되지만, 의존성 문제로 애플리케이션 충돌.
보안 취약점:
- nginx:1.22에 알려진 취약점이 존재하지만, Git에는 반영되지 않아 감지 불가.

구성 드리프트가 발생하는 주요 영역

영역	드리프트 예시
Kubernetes	- 파드 이미지 버전 불일치 - 레플리카 수 수동 변경 - ConfigMap/Secret 값 변경
클라우드 인프라	- AWS 보안 그룹 규칙 수동 추가 - Azure VM 사이즈 변경 - GCP 디스크 타입 수정
네트워크	- 로드 밸런서 설정 변경 - DNS 레코드 수동 수정 - 방화벽 포트 개방
데이터베이스	- 스키마 변경 미반영 - 사용자 권한 수동 부여 - 백업 설정 변경

구성 드리프트의 심각한 문제점

1. 예측 불가능한 장애

사례:
프로덕션 환경에서만 replicas: 1로 수동 변경된 상태에서 트래픽 증가 → 서비스 다운.
원인:
Git에는 replicas: 3으로 기록되어 있어 모니터링 시스템이 정상으로 판단.

2. 보안 및 규정 준수 위반

사례:
보안팀이 "모든 파드는 readOnlyRootFilesystem: true여야 한다"는 정책을 수립했지만,
개발자가 긴급 수정을 위해 수동으로 false로 변경 → 감사 실패.
원인:
Git에 정책이 반영되지 않아 자동 검증 불가.

3. 복잡성 증가 및 유지보수 어려움

사례:
6개월간 수동 변경이 누적된 후, "현재 환경이 Git과 어떻게 다른지" 파악 불가 → 재구축 필요.
원인:
드리프트가 누적될수록 원인 분석이 불가능해짐.

해결 방안: GitOps의 역할

(1) 지속적 동기화 (Continuous Sync)

ArgoCD/Flux:
Git 저장소를 단일 진실 공급원(Single Source of Truth) 으로 설정하고,
주기적으로 실제 상태와 비교해 드리프트를 감지하고 자동 복구.

동작 원리:

graph LR
  A[Git 저장소] -->|Desired State| B(ArgoCD)
  B -->|상태 비교| C[클러스터]
  C -->|Drift 감지| B
  B -->|자동 복구| C

(2) 변경 금지 정책 (Immutable Infrastructure)

예시:
Kubernetes의 Admission Controller를 사용해 kubectl edit 같은 수동 변경을 차단.

ArgoCD 설정:

syncPolicy:
  automated:
    selfHeal: true  # 드리프트 자동 복구
    prune: true     # 불필요한 리소스 자동 삭제

(3) 드리프트 감지 도구 활용

도구	기능
ArgoCD	UI에서 드리프트 시각화, `argocd app diff`로 상세 비교
Checkov	IaC(Infrastructure as Code) 보안 및 구성 검사
Opa/Gatekeeper	Kubernetes 정책 엔진으로 구성 준수 여부 실시간 검증

결론: 구성 드리프트는 "암묵적 기술 부채"

핵심 문제:
"코드로 정의된 상태 ≠ 실제 운영 환경" 이 되면서 발생하는 예측 불가능성과 보안 리스크.
해결의 핵심:
GitOps는 코드를 유일한 진실 공급원으로 삼고, 자동화된 동기화로 드리프트를 원천 차단합니다.
→ "수동 변경을 금지하고, 모든 변경은 Git을 통해" 라는 원칙이 필수적입니다.

💡 간단한 GitOps 운영자의 한계:
이전 테스트의 간단한 운영자는 리소스 존재 여부만 확인하지만, 세부적인 드리프트(이미지 버전, 환경 변수 등)는 감지하지 못합니다.
ArgoCD는 상태 비교 알고리즘으로 이를 해결하며, 프로덕션 환경에서의 구성 드리프트를 방지합니다.

Argo CD 핵심 구성 요소

1. API 서버 (API Server)

역할: Argo CD의 중앙 제어 탑으로 모든 외부 시스템과의 통합을 담당

주요 기능

기능	설명
애플리케이션 관리	애플리케이션 생성/수정/삭제 및 상태 보고
인증/인가	RBAC, SSO(SAML, OIDC, LDAP) 지원
CI/CD 통합	외부 시스템과의 API 상호작용
트리거 관리	수동/자동 동기화 작업 트리거
웹 UI 제공	대시보드 및 관리 인터페이스

상호작용 시스템

2. 리포지터리 서버 (Repository Server)

역할: Git 저장소의 로컬 캐시를 유지하며 매니페스트 제공

핵심 기능

Git 리포지터리 캐싱
- 모든 Git 저장소의 로컬 미러 유지
- 네트워크 부하 감소 및 빠른 접근 지원
매니페스트 렌더링
- Kustomize, Helm, Jsonnet 등 다양한 템플릿 엔진 지원
- 매개변수 기반의 동적 매니페스트 생성

요청 파라미터

3. 애플리케이션 컨트롤러 (Application Controller)

역할: 실제 상태 동기화 및 자기 치유(Self-Healing) 담당

주요 작업 흐름

상태 모니터링
- 3분 주기로 Git 저장소 변경 확인
- 클러스터 리소스 상태 지속적 감시
드리프트 감지
- Git 의도한 상태 ↔ 클러스터 현재 상태 비교
- 세부적인 차이점 분석 (이미지 버전, 레플리카 수 등)
자동 복구
- 불일치 리소스 자동 수정
- 훅(Hook) 기반의 생명주기 관리

상태 동기화 프로세스

동기화 메커니즘

1. 기본 폴링 방식

주기: 기본 3분 간격 Git 저장소 확인
장점: 간단한 설정, 추가 인프라 불필요
단점: 지연 발생 (최대 3분)

2. 수동 동기화

(1) 웹 UI를 통한 동기화

Argo CD 대시보드에서 "Sync" 버튼 클릭
실시간 상태 확인 및 진행 모니터링

(2) CLI를 통한 동기화

# 특정 애플리케이션 동기화
argocd app sync myapp

# 전체 애플리케이션 동기화
argocd app sync --all

3. 웹훅 기반 실시간 동기화

작동 원리:
1. Git 저장소에 웹훅 설정
2. 코드 푸시 시 Argo CD API 서버로 이벤트 전송
3. 즉시 동기화 프로세스 트리거

지원 플랫폼

GitHub
GitLab
Bitbucket
Gogs

웹훅 설정 예시 (GitHub)

전체 아키텍처 다이어그램

핵심 설계 원칙

1. 선언적 구성 (Declarative Configuration)

모든 설정은 Kubernetes CRD(Custom Resource Definition)로 관리
Git 저장소가 단일 진실 공급원(Single Source of Truth)

2. 자기 치유 (Self-Healing)

드리프트 자동 감지 및 복구
의도하지 않은 변경 방지

3. 확장성 (Scalability)

마이크로서비스 아키텍처 기반
각 컴포넌트 독립적 확장 가능

4. 보안 (Security)

RBAC 기반 접근 제어
SSO 통합 지원
GitOps 패턴으로 직접 클러스터 접근 최소화

💡 Argo CD의 핵심 가치:
"Git 저장소에 정의된 상태를 클러스터의 실제 상태로 자동 동기화함으로써,
인프라 관리의 예측 가능성과 안정성을 극대화하는 GitOps 구현 도구"

진웅

bytebliss

이전 포스트

[cicd] cloudeNet Study 2주차 -Helm

다음 포스트

[cicd] cloudeNet Study 4주차 - ArgoCD

CI/CD

주요 정리 내용

ArgoCD 이전에 간단 go 를 이용한 gitOps operator 실습해보자

git source

테스트 내용 :

1. 테스트의 전체 흐름

2. 각 단계별 의미 해석

(1) Go 기반 GitOps Operator 실행

(2) 배포 상태 확인

(3) 강제 리소스 삭제 및 복구 테스트

3. 테스트의 핵심 의미

(1) GitOps의 기본 원리 실현

(2) GitOps 도구의 간소화 버전

(3) 운영 효율성 검증

4. 실제 환경에서의 활용 시나리오

5. 한계 및 개선 방향

결론

ArgoCD와 비교해보자

ArgoCD와 간단한 GitOps 운영자 비교

1. 아키텍처 비교

2. 기능 비교

3. 사용 사례 비교

4. 핵심 차이점 요약

(1) 단순성 vs. 확장성

(2) 동기화 방식

(3) 상태 관리

5. ArgoCD로 동일한 시나리오 구현 예시

(1) ArgoCD 설치

(2) 애플리케이션 생성 (nginx-app.yaml)

(3) 애플리케이션 적용

(4) 상태 확인

(5) 수동 삭제 및 자동 복구 테스트

6. 결론: 테스트의 의미와 ArgoCD의 가치

테스트의 의미

ArgoCD의 가치

구성 드리프트(Configuration Drift)란?

구성 드리프트(Configuration Drift)란?

왜 발생하는가? (주요 원인)

1. 수동 변경 (Manual Changes)

2. 자동화되지 않은 프로세스

3. 팀 간 소통 부재

4. 환경별 차이

구체적인 예시로 이해하기

시나리오: Kubernetes 환경에서의 구성 드리프트

(1) 초기 상태 (Git에 정의된 Desired State)

(2) 드리프트 발생 (수동 변경)

(3) 문제 발생

구성 드리프트가 발생하는 주요 영역

구성 드리프트의 심각한 문제점

1. 예측 불가능한 장애

2. 보안 및 규정 준수 위반

3. 복잡성 증가 및 유지보수 어려움

해결 방안: GitOps의 역할

(1) 지속적 동기화 (Continuous Sync)

(2) 변경 금지 정책 (Immutable Infrastructure)

(3) 드리프트 감지 도구 활용

결론: 구성 드리프트는 "암묵적 기술 부채"

Argo CD 핵심 구성 요소

1. API 서버 (API Server)

주요 기능

상호작용 시스템

2. 리포지터리 서버 (Repository Server)

핵심 기능

요청 파라미터

3. 애플리케이션 컨트롤러 (Application Controller)

주요 작업 흐름

상태 동기화 프로세스

동기화 메커니즘

1. 기본 폴링 방식

2. 수동 동기화

(1) 웹 UI를 통한 동기화

(2) CLI를 통한 동기화

3. 웹훅 기반 실시간 동기화

지원 플랫폼

웹훅 설정 예시 (GitHub)

전체 아키텍처 다이어그램

핵심 설계 원칙

1. 선언적 구성 (Declarative Configuration)

2. 자기 치유 (Self-Healing)

(2) 애플리케이션 생성 (`nginx-app.yaml`)