ArgoCD로 GitOps 구축 완벽 가이드

Git 저장소를 단일 진실 공급원으로 삼아 쿠버네티스 배포를 자동화하는 GitOps 패러다임과 ArgoCD의 핵심 기능을 다룹니다. 선언적 배포, 자동 동기화, 롤백까지 실무에 필요한 모든 것을 배웁니다.

---

목차

1. GitOps_개념과_장점
2. ArgoCD_설치_및_설정
3. Application_리소스_생성
4. 자동_동기화_설정
5. 롤백과_히스토리_관리
6. 멀티_클러스터_배포

---

1. GitOps 개념과 장점

김개발 씨는 매일 아침 출근하면 같은 고민에 빠집니다. "어제 배포한 버전이 뭐였지?

누가 언제 어떤 설정을 바꿨지?" 배포 히스토리를 추적하느라 시간을 허비하던 어느 날, 선배 박시니어 씨가 다가와 말했습니다. "GitOps를 도입하면 그런 고민이 사라져요."

GitOps는 Git 저장소를 인프라와 애플리케이션의 단일 진실 공급원으로 삼는 운영 방식입니다. 마치 레시피 책을 보고 요리하는 것처럼, Git에 저장된 선언적 설정 파일대로 시스템이 자동으로 상태를 맞춥니다.

누가, 언제, 무엇을 변경했는지 Git 히스토리만 보면 모든 것이 명확해집니다.

다음 코드를 살펴봅시다.

# GitOps의 핵심: Git 저장소가 원하는 상태를 정의합니다
# kubernetes/deployment.yaml
apiVersion: apps/v1
kind: Deployment
metadata:
  name: my-app
  namespace: production
spec:
  replicas: 3  # Git에서 이 값을 변경하면
  selector:
    matchLabels:
      app: my-app
  template:
    spec:
      containers:
      - name: my-app
        image: myapp:v1.2.3  # 자동으로 클러스터에 반영됩니다

김개발 씨는 입사 6개월 차 데브옵스 엔지니어입니다. 회사에서는 쿠버네티스를 사용해 서비스를 운영하고 있었는데, 배포할 때마다 혼란이 생겼습니다.

kubectl 명령어로 직접 배포하다 보니 누가 언제 무엇을 변경했는지 알 수 없었습니다. 어느 날 장애가 발생했습니다.

프로덕션 환경의 설정이 개발 환경과 달랐던 것입니다. 누군가 직접 kubectl로 수정했는데, 그 기록이 어디에도 남아있지 않았습니다.

선배 박시니어 씨가 해결책을 제시했습니다. "GitOps를 도입하면 이런 문제가 사라져요.

모든 변경은 반드시 Git을 통해서만 이루어지니까요." GitOps란 정확히 무엇일까요? 쉽게 비유하자면, GitOps는 마치 건축 설계도와 같습니다.

건물을 지을 때 설계도 없이 즉흥적으로 짓지 않듯이, 인프라도 Git에 저장된 설계도대로만 구축합니다. 설계도가 바뀌면 건물도 그에 맞게 변경됩니다.

GitOps가 없던 시절에는 어땠을까요? 개발자들은 서버에 직접 접속해서 설정을 변경했습니다.

문서화도 제각각이었고, 누가 무엇을 변경했는지 추적하기 어려웠습니다. "어제 잘 되던 게 왜 오늘은 안 되지?"라는 말이 일상이었습니다.

더 큰 문제는 환경 불일치였습니다. 개발 환경, 스테이징 환경, 프로덕션 환경이 서로 달랐습니다.

"제 컴퓨터에서는 잘 되는데요"라는 말이 매일 오갔습니다. GitOps의 핵심 원칙은 네 가지입니다.

첫째, 선언적 정의입니다. 시스템의 원하는 상태를 코드로 선언합니다.

둘째, 버전 관리입니다. 모든 설정이 Git에 저장되어 변경 이력이 남습니다.

셋째, 자동 적용입니다. Git의 변경 사항이 자동으로 시스템에 반영됩니다.

넷째, 지속적 조정입니다. 시스템이 원하는 상태와 다르면 자동으로 수정합니다.

실제 현업에서는 어떤 이점이 있을까요? 예를 들어 야간에 장애가 발생했다고 가정해봅시다.

GitOps 환경에서는 최근 커밋 히스토리만 확인하면 됩니다. "아, 어제 저녁 7시에 이 설정이 바뀌었구나.

이것 때문이겠네." 원인 파악이 빨라지고, 롤백도 git revert 한 번이면 됩니다. 주의할 점도 있습니다.

GitOps를 도입한다고 해서 kubectl 명령어를 완전히 금지할 필요는 없습니다. 긴급 상황에서는 직접 조치가 필요할 수 있습니다.

다만, 긴급 조치 후에는 반드시 Git에도 반영해야 합니다. 다시 김개발 씨의 이야기로 돌아가 봅시다.

GitOps를 도입한 후, 팀의 배포 문화가 완전히 바뀌었습니다. 모든 변경은 Pull Request를 통해 리뷰를 받고, 승인된 후에만 자동으로 적용됩니다.

"누가 바꿨어?"라는 질문 대신 "어떤 PR이었어?"라고 묻게 되었습니다.

실전 팁

💡 - Git 브랜치 전략을 명확히 정의하세요. main 브랜치는 프로덕션, develop은 스테이징 환경과 연결하는 것이 일반적입니다.

• 민감한 정보는 Git에 직접 저장하지 말고 Sealed Secrets나 External Secrets를 활용하세요.

---

2. ArgoCD 설치 및 설정

김개발 씨는 GitOps 개념에 감명받았습니다. 하지만 이론과 실제는 다릅니다.

"그래서 어떻게 구현하죠?" 박시니어 씨가 웃으며 대답했습니다. "ArgoCD라는 도구가 있어요.

설치부터 해볼까요?"

ArgoCD는 쿠버네티스를 위한 선언적 GitOps 지속적 배포 도구입니다. Git 저장소의 매니페스트를 지속적으로 모니터링하고, 클러스터의 실제 상태와 비교하여 차이가 있으면 자동으로 동기화합니다.

직관적인 웹 UI와 강력한 CLI를 제공하여 배포 상태를 한눈에 파악할 수 있습니다.

다음 코드를 살펴봅시다.

# ArgoCD 네임스페이스 생성 및 설치
kubectl create namespace argocd
kubectl apply -n argocd -f https://raw.githubusercontent.com/argoproj/argo-cd/stable/manifests/install.yaml

# ArgoCD CLI 설치 (Linux 기준)
curl -sSL -o argocd-linux-amd64 https://github.com/argoproj/argo-cd/releases/latest/download/argocd-linux-amd64
sudo install -m 555 argocd-linux-amd64 /usr/local/bin/argocd

# 초기 관리자 비밀번호 확인
kubectl -n argocd get secret argocd-initial-admin-secret -o jsonpath="{.data.password}" | base64 -d

# ArgoCD 서버 접속 (포트 포워딩)
kubectl port-forward svc/argocd-server -n argocd 8080:443

김개발 씨는 ArgoCD 공식 문서를 펼쳤습니다. 생각보다 설치가 간단해 보였습니다.

쿠버네티스 클러스터만 있으면 몇 분 안에 설치가 완료된다고 합니다. 설치 과정을 하나씩 살펴보겠습니다.

먼저 argocd라는 네임스페이스를 생성합니다. ArgoCD의 모든 구성 요소가 이 네임스페이스 안에서 동작합니다.

네임스페이스로 격리함으로써 다른 애플리케이션과 충돌할 걱정이 없어집니다. 다음으로 공식 매니페스트를 적용합니다.

이 한 줄의 명령어가 실행되면 여러 구성 요소가 설치됩니다. argocd-server는 API 서버이자 웹 UI를 제공합니다.

argocd-repo-server는 Git 저장소를 관리합니다. argocd-application-controller는 실제 동기화 작업을 수행합니다.

ArgoCD는 마치 부지런한 경비원과 같습니다. 24시간 Git 저장소와 클러스터를 감시하면서, 둘 사이에 차이가 생기면 즉시 알려주고 필요하면 자동으로 맞춰줍니다.

CLI 도구도 설치하면 편리합니다. 터미널에서 argocd 명령어로 애플리케이션을 관리할 수 있습니다.

스크립트 자동화나 CI/CD 파이프라인 연동에 유용합니다. 초기 비밀번호는 쿠버네티스 시크릿에 저장되어 있습니다.

base64로 인코딩되어 있으니 디코딩해서 확인해야 합니다. 첫 로그인 후에는 반드시 비밀번호를 변경하세요.

보안의 기본입니다. 웹 UI에 접속하려면 포트 포워딩을 사용합니다.

브라우저에서 https://localhost:8080으로 접속하면 로그인 화면이 나타납니다. 사용자명은 admin, 비밀번호는 방금 확인한 값을 입력합니다.

처음 웹 UI를 본 김개발 씨는 감탄했습니다. 애플리케이션 목록, 동기화 상태, 리소스 트리가 한눈에 보였습니다.

클릭 몇 번으로 배포 상태를 파악하고 롤백까지 할 수 있었습니다. 프로덕션 환경에서는 포트 포워딩 대신 Ingress나 LoadBalancer를 설정하는 것이 좋습니다.

또한 SSO 연동으로 회사 계정으로 로그인할 수 있게 설정하면 더욱 편리합니다. 박시니어 씨가 조언했습니다.

"처음에는 기본 설치로 충분해요. 나중에 필요하면 HA 구성도 할 수 있고, Redis 클러스터도 연결할 수 있어요.

점진적으로 발전시켜 나가면 됩니다."

실전 팁

💡 - 프로덕션에서는 반드시 초기 비밀번호를 변경하고, 가능하면 SSO를 연동하세요.

• argocd-server에 Ingress를 설정할 때는 SSL 인증서를 함께 구성하세요.
• 고가용성이 필요하면 HA 매니페스트를 사용하세요.

---

3. Application 리소스 생성

ArgoCD가 설치되었습니다. 이제 실제로 애플리케이션을 배포해볼 차례입니다.

김개발 씨가 물었습니다. "Git 저장소와 클러스터를 어떻게 연결하죠?" 박시니어 씨가 대답했습니다.

"Application이라는 커스텀 리소스를 만들면 돼요."

Application은 ArgoCD의 핵심 리소스입니다. Git 저장소의 어떤 경로를, 어떤 클러스터의 어떤 네임스페이스에 배포할지 정의합니다.

하나의 Application이 하나의 배포 단위가 됩니다. YAML 파일로 선언적으로 정의하거나 웹 UI에서 클릭으로 생성할 수 있습니다.

다음 코드를 살펴봅시다.

# argocd-application.yaml
apiVersion: argoproj.io/v1alpha1
kind: Application
metadata:
  name: my-web-app
  namespace: argocd  # Application은 항상 argocd 네임스페이스에 생성
spec:
  project: default
  source:
    repoURL: https://github.com/mycompany/k8s-manifests.git
    targetRevision: main  # 브랜치, 태그, 또는 커밋 해시
    path: apps/my-web-app  # 매니페스트가 있는 디렉토리
  destination:
    server: https://kubernetes.default.svc  # 현재 클러스터
    namespace: production  # 배포할 네임스페이스
  syncPolicy:
    automated:
      prune: true  # Git에서 삭제된 리소스도 삭제
      selfHeal: true  # 수동 변경 시 자동 복구

김개발 씨는 첫 번째 Application을 만들기로 했습니다. 팀에서 운영 중인 웹 애플리케이션을 ArgoCD로 관리해보기로 한 것입니다.

Application 리소스를 이해하는 가장 좋은 비유는 택배 배송입니다. 보내는 주소(source)와 받는 주소(destination)를 적으면, 택배 기사(ArgoCD)가 알아서 물건을 배달해줍니다.

우리는 주소만 정확히 적으면 됩니다. source 섹션을 살펴보겠습니다.

repoURL은 Git 저장소 주소입니다. GitHub, GitLab, Bitbucket 어디든 상관없습니다.

targetRevision은 어떤 브랜치나 태그를 사용할지 지정합니다. main 브랜치를 지정하면 main에 푸시될 때마다 배포가 트리거됩니다.

path는 매니페스트 파일들이 있는 디렉토리입니다. destination 섹션은 배포할 목적지입니다.

server는 쿠버네티스 클러스터의 API 서버 주소입니다. https://kubernetes.default.svc는 ArgoCD가 설치된 현재 클러스터를 의미합니다.

namespace는 리소스가 배포될 네임스페이스입니다. project는 Application들을 그룹화하는 논리적 단위입니다.

기본값인 default를 사용해도 되지만, 팀이나 환경별로 프로젝트를 분리하면 권한 관리가 편해집니다. syncPolicy는 동기화 정책입니다.

automated를 설정하면 Git 변경 시 자동으로 동기화됩니다. prune: true는 Git에서 삭제된 리소스를 클러스터에서도 삭제합니다.

selfHeal: true는 누군가 kubectl로 직접 수정해도 Git 상태로 자동 복구합니다. 김개발 씨가 YAML 파일을 작성하고 적용했습니다.

kubectl apply -f argocd-application.yaml 명령어 한 줄이면 됩니다. 웹 UI를 새로고침하니 새로운 애플리케이션이 나타났습니다.

처음에는 OutOfSync 상태였습니다. Git의 원하는 상태와 클러스터의 현재 상태가 다르다는 의미입니다.

Sync 버튼을 누르자 ArgoCD가 동기화를 시작했습니다. 잠시 후 Healthy, Synced 상태로 바뀌었습니다.

박시니어 씨가 팁을 알려줬습니다. "Application 자체도 Git으로 관리하세요.

그러면 App of Apps 패턴을 사용할 수 있어요. 하나의 Application이 다른 Application들을 관리하는 구조죠."

실전 팁

💡 - 프라이빗 Git 저장소는 먼저 Repository 설정에서 인증 정보를 등록해야 합니다.

• path에 Helm 차트나 Kustomize 디렉토리를 지정할 수도 있습니다.
• 여러 환경을 관리할 때는 ApplicationSet을 고려해보세요.

---

4. 자동 동기화 설정

Application을 생성했지만, 매번 Sync 버튼을 눌러야 하는 것이 번거로웠습니다. 김개발 씨가 물었습니다.

"Git에 푸시하면 자동으로 배포되게 할 수 없나요?" 박시니어 씨가 고개를 끄덕였습니다. "자동 동기화 설정을 하면 됩니다."

**자동 동기화(Automated Sync)**는 Git 저장소의 변경을 감지하면 자동으로 클러스터에 적용하는 기능입니다. 수동 개입 없이 Git Push만으로 배포가 완료됩니다.

prune과 selfHeal 옵션을 함께 사용하면 Git 저장소가 완전한 진실 공급원이 됩니다.

다음 코드를 살펴봅시다.

# 자동 동기화가 설정된 Application
apiVersion: argoproj.io/v1alpha1
kind: Application
metadata:
  name: auto-sync-app
  namespace: argocd
spec:
  project: default
  source:
    repoURL: https://github.com/mycompany/k8s-manifests.git
    targetRevision: main
    path: apps/production
  destination:
    server: https://kubernetes.default.svc
    namespace: production
  syncPolicy:
    automated:
      prune: true       # Git에서 삭제하면 클러스터에서도 삭제
      selfHeal: true    # 수동 변경 시 3분 내 자동 복구
      allowEmpty: false # 빈 디렉토리 동기화 방지
    syncOptions:
      - CreateNamespace=true  # 네임스페이스 자동 생성
      - PrunePropagationPolicy=foreground
    retry:
      limit: 5  # 실패 시 최대 5회 재시도

김개발 씨는 자동 동기화의 매력에 빠졌습니다. 코드를 수정하고, PR을 올리고, 리뷰를 받고, 머지하면 끝.

별도의 배포 작업이 필요 없습니다. 자동 동기화는 마치 스마트홈 시스템과 같습니다.

온도를 설정해두면 에어컨이 알아서 켜지고 꺼집니다. 우리가 할 일은 원하는 온도를 설정하는 것뿐입니다.

Git에 원하는 상태를 정의하면 ArgoCD가 알아서 맞춰줍니다. prune 옵션을 자세히 살펴보겠습니다.

이 옵션이 true이면 Git에서 삭제된 리소스가 클러스터에서도 삭제됩니다. 예를 들어 더 이상 필요 없는 ConfigMap을 Git에서 삭제하면, 클러스터에서도 자동으로 사라집니다.

하지만 주의가 필요합니다. 실수로 파일을 삭제하면 프로덕션 리소스도 삭제됩니다.

그래서 중요한 리소스에는 argocd.argoproj.io/sync-options: Prune=false 어노테이션을 추가하는 것이 좋습니다. selfHeal 옵션은 더 강력합니다.

누군가 kubectl로 직접 수정해도 ArgoCD가 3분 이내에 원래 상태로 되돌립니다. Git이 유일한 진실 공급원이 되는 것입니다.

이 기능 덕분에 "누가 프로덕션 설정을 바꿨어?"라는 상황이 사라집니다. 바꿔도 자동으로 원복되니까요.

물론 긴급 상황에서는 자동 동기화를 일시 중지할 수 있습니다. syncOptions도 유용한 옵션을 제공합니다.

CreateNamespace=true를 설정하면 목적지 네임스페이스가 없을 때 자동으로 생성합니다. 새로운 환경을 셋업할 때 편리합니다.

retry 설정은 동기화 실패 시 재시도 횟수를 지정합니다. 네트워크 문제나 일시적 오류로 실패할 경우 자동으로 다시 시도합니다.

limit과 함께 backoff 전략도 설정할 수 있습니다. 김개발 씨는 스테이징 환경에 먼저 자동 동기화를 적용했습니다.

일주일간 모니터링한 결과, 문제없이 잘 동작했습니다. 이제 프로덕션에도 적용할 자신감이 생겼습니다.

박시니어 씨가 마지막 조언을 했습니다. "프로덕션에는 자동 동기화 대신 수동 승인을 유지하는 팀도 많아요.

정책은 팀 상황에 맞게 결정하세요. 중요한 건 Git이 진실 공급원이라는 원칙을 지키는 것입니다."

실전 팁

💡 - 프로덕션에 자동 동기화를 적용할 때는 충분한 테스트 기간을 거치세요.

• Sync Windows를 설정하면 특정 시간대에만 동기화를 허용할 수 있습니다.
• 중요 리소스에는 Prune=false 어노테이션을 추가하세요.

---

5. 롤백과 히스토리 관리

새 버전을 배포했는데 장애가 발생했습니다. 김개발 씨의 심장이 쿵쾅거렸습니다.

"빨리 이전 버전으로 돌려야 해!" 다행히 박시니어 씨가 침착하게 말했습니다. "ArgoCD 히스토리에서 롤백하면 돼요.

1분이면 됩니다."

ArgoCD는 모든 동기화 이력을 저장합니다. 문제가 발생하면 이전 버전으로 롤백할 수 있습니다.

웹 UI에서 클릭 한 번이면 이전 상태로 되돌아갑니다. Git 히스토리와 ArgoCD 히스토리가 함께 동작하여 완벽한 버전 관리를 제공합니다.

다음 코드를 살펴봅시다.

# CLI로 히스토리 확인
argocd app history my-web-app

# 특정 버전으로 롤백 (ID는 히스토리에서 확인)
argocd app rollback my-web-app 3

# 또는 Git revert로 롤백 (권장 방식)
git revert HEAD
git push origin main
# ArgoCD가 자동으로 이전 상태로 동기화

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

# 리소스 상세 정보 확인
argocd app resources my-web-app

# 동기화 일시 중지 (긴급 상황에서)
argocd app set my-web-app --sync-policy none

그날 밤 김개발 씨는 큰 교훈을 얻었습니다. 새 기능을 배포했는데, 예상치 못한 버그가 있었습니다.

사용자들의 불만이 쏟아지기 시작했습니다. 예전 같으면 패닉에 빠졌을 것입니다.

이전 버전의 이미지 태그가 뭐였지? 어떤 설정을 바꿔야 하지?

하지만 ArgoCD가 있었습니다. 박시니어 씨가 웹 UI를 열었습니다.

History 탭을 클릭하니 모든 동기화 이력이 보였습니다. 언제, 어떤 커밋이, 어떤 리소스를 변경했는지 한눈에 파악할 수 있었습니다.

"여기서 이전 버전을 선택하고 Rollback 버튼을 누르면 돼요." 박시니어 씨가 클릭했습니다. 30초 후, 애플리케이션이 이전 상태로 돌아갔습니다.

장애가 해결되었습니다. 롤백에는 두 가지 방식이 있습니다.

첫 번째는 ArgoCD UI나 CLI에서 직접 롤백하는 것입니다. 빠르고 간편합니다.

긴급 상황에서 유용합니다. 두 번째는 Git revert를 사용하는 것입니다.

이 방식이 GitOps 철학에 더 부합합니다. Git 히스토리에 롤백 기록이 남기 때문입니다.

누가 왜 롤백했는지 커밋 메시지로 알 수 있습니다. 김개발 씨가 물었습니다.

"둘 다 결과는 같은 거 아닌가요?" 박시니어 씨가 설명했습니다. "ArgoCD 롤백은 임시 조치예요.

자동 동기화가 켜져 있으면 다시 최신 상태로 돌아갈 수 있어요. Git revert는 영구적인 변경이에요." 히스토리 관리도 중요합니다.

ArgoCD는 기본적으로 최근 10개의 동기화 이력을 저장합니다. 이 숫자는 설정으로 조정할 수 있습니다.

컴플라이언스 요구사항이 있는 조직에서는 더 많은 이력을 보관하기도 합니다. 긴급 상황에서는 자동 동기화를 일시 중지할 수 있습니다.

argocd app set 명령어로 sync-policy를 none으로 설정하면 됩니다. 문제를 해결한 후 다시 활성화하면 됩니다.

그날 이후 김개발 씨는 배포 전 체크리스트에 새 항목을 추가했습니다. "롤백 절차 확인".

아무리 자신 있는 배포라도 항상 플랜 B가 있어야 합니다.

실전 팁

💡 - 중요한 배포 전에는 항상 현재 상태의 스냅샷을 확인해두세요.

• Git revert를 통한 롤백이 GitOps 철학에 더 부합합니다.
• 자동 동기화 환경에서 ArgoCD 롤백은 임시 조치임을 기억하세요.

---

6. 멀티 클러스터 배포

회사가 성장하면서 쿠버네티스 클러스터가 늘어났습니다. 개발용, 스테이징용, 프로덕션용, 그리고 해외 리전까지.

김개발 씨가 한숨을 쉬었습니다. "클러스터마다 따로 관리해야 하나요?" 박시니어 씨가 미소 지었습니다.

"ArgoCD 하나로 전부 관리할 수 있어요."

ArgoCD는 멀티 클러스터 환경을 지원합니다. 하나의 ArgoCD 인스턴스에서 여러 클러스터를 중앙 집중식으로 관리할 수 있습니다.

클러스터를 등록하고 Application의 destination만 변경하면 됩니다. ApplicationSet을 사용하면 여러 클러스터에 동시 배포도 가능합니다.

다음 코드를 살펴봅시다.

# 새 클러스터 등록
argocd cluster add production-cluster --name production

# 멀티 클러스터용 ApplicationSet
apiVersion: argoproj.io/v1alpha1
kind: ApplicationSet
metadata:
  name: my-app-set
  namespace: argocd
spec:
  generators:
    - list:
        elements:
          - cluster: staging
            url: https://staging.k8s.example.com
          - cluster: production
            url: https://production.k8s.example.com
  template:
    metadata:
      name: 'my-app-{{cluster}}'  # my-app-staging, my-app-production
    spec:
      project: default
      source:
        repoURL: https://github.com/mycompany/k8s-manifests.git
        targetRevision: main
        path: 'apps/{{cluster}}'  # 클러스터별 설정
      destination:
        server: '{{url}}'
        namespace: my-app

김개발 씨의 회사는 빠르게 성장했습니다. 처음에는 클러스터가 하나였는데, 어느새 다섯 개가 되었습니다.

개발, 스테이징, 프로덕션, 그리고 미국과 유럽 리전의 프로덕션 클러스터까지. 각 클러스터마다 ArgoCD를 설치하면 관리 포인트가 늘어납니다.

다행히 ArgoCD는 멀티 클러스터를 기본 지원합니다. 하나의 ArgoCD에서 모든 클러스터를 관리할 수 있습니다.

클러스터 등록은 간단합니다. argocd cluster add 명령어에 kubeconfig 컨텍스트 이름을 전달하면 됩니다.

ArgoCD가 해당 클러스터에 접근할 수 있는 ServiceAccount를 자동으로 생성합니다. 등록된 클러스터는 웹 UI의 Settings에서 확인할 수 있습니다.

각 클러스터의 연결 상태, 버전 정보, 리소스 현황을 한눈에 볼 수 있습니다. 멀티 클러스터 환경에서 진가를 발휘하는 것이 ApplicationSet입니다.

일반 Application은 하나의 소스를 하나의 목적지에 배포합니다. ApplicationSet은 템플릿을 사용해 여러 Application을 자동 생성합니다.

위의 예제를 보겠습니다. generators 섹션에서 클러스터 목록을 정의합니다.

template 섹션에서 Application 템플릿을 정의합니다. 결과적으로 my-app-staging과 my-app-production 두 개의 Application이 자동으로 생성됩니다.

김개발 씨가 감탄했습니다. "새 클러스터가 추가되면 list에 한 줄만 추가하면 되는 거네요!" 맞습니다.

클러스터가 늘어나도 관리 부담이 선형적으로 증가하지 않습니다. 클러스터별 설정도 가능합니다.

path에 {{cluster}} 변수를 사용하면 클러스터마다 다른 매니페스트를 적용할 수 있습니다. 예를 들어 프로덕션은 replicas: 10, 스테이징은 replicas: 2로 설정할 수 있습니다.

보안도 중요합니다. 멀티 클러스터 환경에서는 ArgoCD의 권한이 커집니다.

RBAC을 통해 누가 어떤 클러스터에 배포할 수 있는지 세밀하게 제어해야 합니다. 프로젝트별로 허용 클러스터를 제한할 수도 있습니다.

박시니어 씨가 마지막으로 조언했습니다. "멀티 클러스터 환경에서는 네트워크 설정이 중요해요.

ArgoCD가 모든 클러스터에 접근할 수 있어야 하니까요. VPN이나 프라이빗 링크를 잘 구성하세요."

실전 팁

💡 - 클러스터 등록 시 적절한 권한을 가진 ServiceAccount를 사용하세요.

• ApplicationSet의 generator에는 Git, Cluster, Matrix 등 다양한 옵션이 있습니다.
• 프로젝트 설정으로 팀별 접근 가능한 클러스터를 제한하세요.

---

이상으로 학습을 마칩니다. 위 내용을 직접 코드로 작성해보면서 익혀보세요!