예제로 배우는 Argo CD 1장: 깃옵스와 쿠버네티스

 

선언적 운영의 시작

쿠버네티스 환경에서 배포 자동화를 구축하려면 단순한 스크립트 실행 이상의 접근이 필요하다.
GitOps는 그런 문제를 해결하기 위해 등장한, 선언적 구성 관리와 자동 동기화를 기반으로 하는 새로운 운영 방식이다.

이번 장에서는 깃옵스의 개념, 쿠버네티스가 이를 자연스럽게 받아들일 수 있었던 이유, 그리고 kind 클러스터를 활용한 기본 실습까지 살펴본다.

---

1. 깃옵스란 무엇인가?

1.1 개념

GitOps는 Git + Operations의 합성어로,
모든 인프라와 애플리케이션 배포 상태를 Git 리포지터리에 선언적으로 저장하고,
그 리포지터리를 “단일 진리의 원천(Source of Truth)”으로 삼아 시스템을 운영하는 접근 방식이다.

2017년 Weaveworks의 Flux 개발팀이 처음 제시했으며, 이후 다양한 도구(Flux, Argo CD 등)가 발전하면서 사실상의 표준으로 자리 잡았다.

1.2 다양한 정의

GitOps는 단일한 정의보다 철학에 가까운 개념이다.

• 깃을 기반으로 한 풀 리퀘스트(Pull Request) 기반 운영 프로세스
• 버전 관리, 협업, CI/CD의 개발 관행을 인프라 자동화 영역으로 확장한 방식
• 그리고 CNCF GitOps Working Group이 제시한 원칙 기반 정의

이 중 가장 널리 받아들여지는 정의는 CNCF 산하의 Application Delivery TAG 그룹이 제시한 원칙이다.

“GitOps는 쿠버네티스와 같은 선언적 시스템을 위해 설계된, 깃 기반의 운영 방법론이다.”
— CNCF OpenGitOps Working Group

공식 사이트: https://opengitops.dev

---

2. GitOps의 4가지 핵심 원칙

CNCF GitOps Working Group은 다음 네 가지 원칙을 제시한다.

원칙 설명

1. 선언적 구성 (Declarative Configuration)	시스템의 원하는 상태를 정의만 하면, 그에 맞게 자동으로 유지된다.
2. 버전 관리되는 불변 저장소 (Versioned & Immutable Storage)	Git 리포지터리에 모든 변경 이력이 저장되고, 언제든 되돌릴 수 있다.
3. 자동 동기화 (Pulled Automatically)	깃에 변경이 생기면 자동으로 동기화된다.
4. 지속적 조정 (Continuously Reconciled)	실제 시스템 상태가 선언된 상태와 일치하도록 주기적으로 비교 및 수정한다.

이 네 가지는 결국 운영의 자동화와 신뢰성 향상을 동시에 달성하기 위한 기반이 된다.

---

3. 쿠버네티스가 깃옵스와 잘 맞는 이유

GitOps가 쿠버네티스와 자연스럽게 결합할 수 있었던 이유는
쿠버네티스 자체가 “선언적(Declarative)” 구조로 설계되어 있기 때문이다.

쿠버네티스에서는 사용자가 “의도한 상태(Desired State)”를 정의하면,
컨트롤러(Controller) 가 실제 상태를 지속적으로 감시하고 이를 일치시킨다.

즉, GitOps의 철학인 “깃의 선언된 상태 = 실제 시스템 상태”는
쿠버네티스의 “YAML 선언 = 런타임 리소스 상태” 모델과 완벽히 대응된다.

---

4. 선언적 API와 명령형 API의 차이

구분 명령형(Imperative) 선언형(Declarative)

방식	사용자가 직접 명령을 실행	원하는 상태를 선언
예시	kubectl create	kubectl apply -f
특징	실행 순서 중요, 상태 추적 어려움	시스템이 상태를 보장, 변경 이력 추적 용이

예를 들어, 다음 두 방식의 차이를 보자.

명령형 접근

kubectl create namespace test
kubectl run nginx --image=nginx

선언적 접근

apiVersion: v1
kind: Namespace
metadata:
  name: test
---
apiVersion: apps/v1
kind: Deployment
metadata:
  name: nginx
spec:
  replicas: 2
  selector:
    matchLabels:
      app: nginx
  template:
    metadata:
      labels:
        app: nginx
    spec:
      containers:
      - name: nginx
        image: nginx

kubectl apply -f nginx-deployment.yaml

GitOps는 이러한 선언적 관리 방식을 깃 리포지터리 수준으로 확장한다.
즉, “kubectl apply 대신 Git 커밋으로 상태를 정의하고 유지하는 방식”이다.

---

5. 실습 – kind 클러스터 생성 및 시각화

GitOps 개념을 실습하기 전, 쿠버네티스의 기본 구조를 시각적으로 이해하기 위한 kind 클러스터 생성 예제다.

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
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

이렇게 생성된 클러스터는 GitOps 실습의 기반이 된다.

---

6. 마무리 정리

항목 핵심 내용

GitOps 개념	깃 리포지터리를 단일 진리의 원천으로 사용하는 운영 방식
CNCF 4원칙	선언적 구성, 버전 관리, 자동 동기화, 지속적 조정
쿠버네티스의 적합성	선언적 API 구조 덕분에 GitOps와 자연스럽게 결합
핵심 철학	“깃의 상태가 곧 시스템의 상태다.”

---

개인적인 인사이트

• GitOps는 단순히 도구의 변화가 아니라, 운영의 패러다임 전환이다.
• 기존의 “운영자 중심 절차형 관리”에서 “개발자 주도 선언형 관리”로 흐름이 이동했다.
• 쿠버네티스는 이러한 변화를 기술적으로 뒷받침하는 가장 강력한 기반이다.