day-log

ArgoCD ApplicationSet Progressive Sync 실무 가이드멀티 클러스터로 ArgoCD를 굴리다 보면 한 번은 겪는 상황이 있다. 앱 매니페스트를 하나 바꿨는데 그게 20개 클러스터에 동시에 동기화되면서, 하필 그 변경이 문제였을 때 20개가 같이 뻗어버리는 케이스. 우리 팀도 지난 분기에 한 번 크게 데었고, 그 이후로 ApplicationSet Progressive Sync를 프로덕션에 도입했다.이 글은 도입하면서 정리한 내용이다. 문서만 보고 따라 하면 놓치기 쉬운 부분 위주로 적었다. Progressive Sync 자체는 2026년 현재 Beta로 승격됐는데, 여전히 experimental 플래그로 활성화해야 한다는 점을 먼저 짚어둔다.Progressive Sync가 뭘 하는..

지난달 우리 팀에서 ArgoCD ApplicationSet의 Progressive Sync를 처음 붙여봤다. 클러스터 6대에 걸쳐 있는 인프라 성격의 앱들을 한 번에 롤아웃할 때 폭발 반경을 줄여보자는 목적이었는데, 결론부터 말하면 절반은 살렸고 절반은 원래 하던 대로 되돌렸다. 그 과정에서 배운 걸 좀 정리해둔다.왜 갑자기 Progressive Sync였나우리는 ApplicationSet의 cluster generator로 6개 EKS 클러스터에 fluent-bit, node-exporter, cert-manager, ExternalDNS 같은 인프라 워크로드를 뿌리고 있다. 문제는 이게 진짜로 6대에 동시에 나가버린다는 거였다. 지난 분기에 fluent-bit config를 잘못 바꿔서 6대 전부에서..

멀티 클러스터 20개를 한꺼번에 sync 걸어놓고 잠들었던 적이 있다. 다음 날 아침 슬랙이 폭발해 있었다. 카나리 배포한다고 flag까지 걸어뒀는데도 20개 클러스터가 동시에 다 뒤집혀버린 상황. 그때 알았다. ApplicationSet 자체는 "언제 sync할지"에 대해 아무 개념이 없다는 걸.ArgoCD 2.9에서 Progressive Sync가 stable로 승격된 지도 꽤 됐고, 2026년 들어서는 pause/resume 애노테이션 같은 기능도 얹혀서 실전 쓸만해졌다. 그런데 이게 정확히 뭘 하는 놈인지, RollingSync strategy가 내부적으로 어떤 순서로 Application을 다루는지 이해 못한 채 쓰는 사람이 꽤 있는 것 같아서 정리해본다. 사실 나도 최근에 다시 파봐서야 명확해..

ArgoCD ApplicationSet으로 멀티 환경 배포 자동화하기ArgoCD를 처음 도입했을 때는 환경마다 Application 리소스를 따로 만들어 썼다. dev, staging, prod 세 환경에 마이크로서비스 12개. 단순 계산으로 36개. 여기에 신규 환경이라도 하나 늘면 또 12개를 복사 붙여넣기. 처음엔 견딜만 했는데, 팀이 커지면서 이 반복 작업이 진짜 골치 아파졌다.ApplicationSet은 이 문제를 푸는 도구다. 한 번 정의해두면 generator가 알아서 N개의 Application을 만들어준다. 이번 글에서는 우리 팀이 실제 운영하면서 정착시킨 패턴을 정리해본다. 참고로 최근 ArgoCD 3.3에서 ApplicationSet의 shallow clone 옵션이 추가돼서 큰 모노..

PR 올릴 때마다 QA 환경 하나씩 띄우는 거, 다들 어떻게 하시나요. 우리 팀도 한참 동안은 PR 댓글에 /deploy preview 같은 슬래시 커맨드를 달고 Jenkins job을 트리거하는 방식을 썼는데, 결국에는 항상 누군가 환경을 안 지워서 노드가 터져 있곤 했다. 그래서 작년 말부터 ArgoCD ApplicationSet의 Pull Request generator로 전환했다. 지금까지 6개월 정도 돌려보니 만족도가 꽤 높아서, 셋업 가이드를 정리해둔다.이 글은 GitHub + ArgoCD 2.x 환경 기준이다. GitLab/Gitea도 거의 비슷하다.어떻게 동작하나핵심은 단순하다. ApplicationSet이 GitHub API를 폴링해서 열려 있는 PR 목록을 가져오고, 각 PR마다 App..

ArgoCD ApplicationSet은 보통 "여러 클러스터에 같은 앱을 자동으로 배포해주는 도구" 정도로 설명된다. 우리 팀도 처음엔 그렇게 썼다. List generator로 환경 별 파라미터 넘기고, 템플릿에 변수 박아 넣고. 잘 돌아갔다. 문제가 터지기 전까지는.작년 가을, 멀티 리전에 깔린 60개 가까운 Application이 사일런트하게 drift나기 시작했다. ApplicationSet 매니페스트는 그대로인데 일부 Application만 sync 상태가 이상했다. 그때 처음으로 ApplicationSet 컨트롤러 코드를 직접 까봤다. 그러고 보니 이 컨트롤러, 생각보다 단순하지 않다.reconcile 루프의 4단계ApplicationSet 컨트롤러를 한 줄로 요약하면 "Application..

ArgoCD ApplicationSet으로 12개 클러스터 한 번에 날린 이야기지난 금요일 저녁이었다. 정확히는 금요일 저녁 8시 47분. 슬랙이 한 번에 12번 울렸다. PagerDuty도 같이 울렸다. 12개 리전 prod 클러스터의 핵심 워크로드가 동시에 CrashLoopBackOff에 빠진 거였다.원인은 단순했다. ArgoCD ApplicationSet의 matrix generator에 새 컨테이너 이미지 tag를 commit했고, 그게 모든 클러스터에 동시에 sync된 거다. 캐너리도 없고, 단계적 롤아웃도 없었다. 그냥 한 방에 전부.이 글은 그날 밤 11시 40분까지 이어진 복구 과정과, 그 후에 progressive sync를 도입하면서 배운 것들에 대한 회고다.우리가 어쩌다 12개를 한 ..

PR 올라올 때마다 리뷰어한테 "로컬에서 띄워서 봐줘"라고 말하는 게 한두 번이지, 매번 그러기 좀 그렇다. 우리 팀은 PR 하나당 stage 환경에 임시로 배포해서 QA가 직접 클릭해보고 댓글 다는 흐름을 원했는데, 그래서 결국 ArgoCD ApplicationSet의 Pull Request generator를 붙였다.처음엔 "그냥 GitHub Actions로 helm install 돌리면 되는 거 아냐?"라고 생각했는데, 막상 정리되고 나니 GitOps의 일관성이라는 게 꽤 크게 다가왔다. PR 닫으면 알아서 지워주고, 상태도 ArgoCD UI에 그대로 보이고. 이번 글에서는 셋업 과정과 실제로 굴려보면서 부딪힌 몇 가지를 정리한다.PR Generator가 하는 일ApplicationSet은 한 번에..

클러스터가 늘어나고 환경이 늘어나면 어느 시점에 Application YAML이 폭발한다. 우리 팀도 그랬다. 클러스터 6개에 환경(dev/stg/prod) 3개, 거기에 공통으로 들어가는 플랫폼 컴포넌트 8개를 곱하니 144개의 Application 리소스가 git에 쌓였다. 사람이 손으로 관리할 수 있는 규모를 넘은 지 오래였다.이걸 ApplicationSet의 matrix generator로 정리한 과정을 적어둔다. Argo CD 공식 문서에는 패턴이 짧게만 소개돼 있고 실전에서 부딪히는 디테일은 잘 안 보여서, 우리 팀이 정착시킨 구성을 그대로 옮긴다. Argo CD 3.0 기준이지만 2.10 이상이면 거의 동일하게 동작한다.왜 matrix generator인가ApplicationSet에는 Lis..

클러스터가 3개를 넘어가면서 ArgoCD Application 매니페스트를 하나하나 만들어 관리하는 게 현실적으로 불가능해진 경험이 있을 것이다. dev, staging, production에 각각 마이크로서비스 10개만 배포해도 Application YAML이 30개다. 여기에 리전별 클러스터까지 추가되면 관리 포인트가 기하급수적으로 늘어난다.ArgoCD ApplicationSet Controller는 이 문제를 정면으로 해결한다. 템플릿 하나로 여러 클러스터, 여러 환경에 Application을 자동 생성하고 라이프사이클까지 관리할 수 있다. 이 글에서는 실무에서 바로 적용할 수 있는 ApplicationSet 패턴들을 다룬다.ApplicationSet이 필요한 이유기존 방식에서는 새 클러스터를 추가..