스터디/K8S 스터디

[k8s 스터디] #17 ArgoCD 적용하기 + 강의 후기

박수빈98 2025. 6. 5. 16:02

이제까지 했던 걸 정리해 보면

  1. 각 빌드를 따로따로 해줌(완)
  2. Jenkinsfile로 파이프라인 만들어 자동화(완)
  3. 배포 환경에 따라 달리 리소스를 만들면 너무 많은 yaml 파일이 생김 → 동적으로 유지할 수 있는 Helm, Kustomize로 패키지화해서 재사용 가능(완)
  4. ArgoCD 활용

Git에 선언된 상태를 기준으로 Kubernetes 클러스터를 자동으로 동기화하고 배포할 수 있는 Argo CD를 알아보고 실습하겠다.

 

ArgoCD

Argo CD란?

  • GitOps 기반의 CD 도구로, Kubernetes 배포를 자동화한다.
  • 다양한 배포 전략(Canary, Blue/Green 등)을 지원한다.
  • 배포 상태는 항상 Git에 정의된 매니페스트(YAML)를 기준으로 판단한다.

배포가 필요한 대표적인 2가지 상황

  1. 소스코드가 변경된 경우
    • 새로운 이미지가 빌드된다.
    • Jenkins 등 CI 도구를 통해 자동으로 Docker 이미지가 생성되고 푸시된다.
  2. 리소스 정의(YAML)가 변경된 경우
    • 매니페스트 파일(Deployment, ConfigMap 등)을 직접 수정해야 한다.
    • 이 변경을 Git에 반영해야 배포가 가능하다.

자동화 흐름

1번 (소스코드 변경 → 이미지 변경)

  • CI 도구(Jenkins 등)가 이미지 빌드 및 푸시 수행
  • Argo CD는 Git 변경이 없으면 아무것도 하지 않음
  • → 이때 Argo Image Updater를 사용하면,
    • 레지스트리에서 최신 이미지 태그를 감지해
    • Git의 values.yaml 등에 자동으로 PR 또는 커밋을 생성
    • Argo CD는 Git 변경을 감지하여 자동 배포를 수행

2번 (매니페스트 변경)

  • 관리자가 직접 Git의 YAML 파일을 수정
  • Argo CD는 Git 상태 변경을 감지
  • 변경된 리소스를 Kubernetes에 자동으로 적용 (kubectl apply처럼 동작)

정리

  • CI 도구는 소스코드 변경 → 이미지 빌드/푸시까지만 담당
  • Argo CD는 Git에 정의된 YAML 변경 → Kubernetes 배포를 자동화
  • Image Updater를 활용하면 소스코드 수정만으로도 완전한 CI/CD 파이프라인 구축 가능

Argo 생태계 구성요

Image Updater

DockerHub에서 이미지 태그 변경을 감지해서 Git 레포에 자동 PR 생성해 줌

  • Jenkins에서 이미지를 빌드하고 v1.0.1을 푸시함
  • ArgoCD는 Git에만 반응하므로 배포 안 됨

→ 여기서 인프라 관리자가 Git에서 태그를 변경하는 수작업이 요구됨

이걸 자동으로 감지 후 Git에 내용을 변경해 줌(수작업 한 단계 삭)

이후 ArgoCD는 Git에 변경을 감지할 수 있음

Rollouts

Canary, Blue/Green, Progressive Delivery 등 고급 배포 전략을 Kubernetes에서 안전하게 수행하기 위한 도구

Canary: 전체 트래픽 중 일부만 신규 버전으로 보내면서 점진 배포함

→ 콜드 스타트 방지 및 새로운 파드 성능 테스트 가능

Blue/Green: 기존 버전과 신규 버전을 동시에 준비 후 전환

Progressive: 자동 모니터링 후 문제없을 때 다음 단계로 넘어감

Events

GitHub, Kafka, S3, Cron 등 외부 이벤트를 감지해서 Kubernetes 리소스를 트리거하는 이벤트 처리 프레임워크

  • Sensor: 이벤트 수신 후 실행할 워크플로우 지정
  • EventSource: 이벤트 소스 정의
  • Trigger: 어떤 Kubernetes 리소스를 실행할지 정의(Workflow, Rollout 등)

Workflow

복잡한 워크플로우(batch job, 데이터 처리, 머신러닝 학습 등)를 kubernetes 위에서 실행할 수 있도록 지원

  • 각 작업을 container 기반의 단계로 나누고, 조건/순서 제어 가능
  • Directed Acyclic Graph(DAG) 기반으로 분기, 병렬 실행, 조건 실행 모두 가능

ArgoCD 설치

kubectl apply -f <https://raw.githubusercontent.com/argoproj>
/argo-cd/stable/manifests/install.yaml

이 명령한 줄로 Argo CD의 모든 핵심 컴포넌트들이 Kubernetes에 배포됨 (Pod의 형태로)

각 파드들이 뭔지 알아보자

구성요소

1. argocd-server(API Server + Web UI)

핵심 게이트웨이

기능

  • Web UI, REST API, CLI를 처리
  • 사용자의 인증/인가, 요청 라우팅, UI 제공
  • 외부 서비스와 통신 포인트

2. argocd-dex-server(SSO, OAuth2, OIDC 등)

인증 처리

기능

  • 외부 인증 Provider와 Argo CD 간 중계자
  • OIDC, LDAP, GitHub SSO, Keycloak 등 연동 가능

실제 구조

  • 독립된 Pod로 동작
  • 로그인 화면에서 계정 입력 시 여기로 리디렉션 됨

3. argocd-repo-server

Git 분석 & 매니페스트 렌더링 담당

 

기능

  • Git 리포에서 코드를 clone
  • Helm Chart나 Kustomize를 렌더링 해서 순수 YAML 생성
  • 이 YAML을 Controller에 전달

→ Helm이나 Kustomize의 YAML은 아직 완성형이 아님 values.yaml 등을 적용해 원래 쿠버네티스가 쓰는

형태의 YAML로 만들어야 함 이걸 하는 것이 repo-server

4. argocd-application-controller

배포를 실행하는 핵심 두뇌 역할임

Git과 K8S 상태 비교 + 직접 Kube API 호출해서 Sync 해주는 역

기능

  • Git 상태에 현재 Kubernetes 리소스 상태를 비교
  • 차이가 있다면 → kubectl apply처럼 직접 배포 실행
  • Sync, Rollback, Self-heal 수행

5. argocd-applicationset-controller

기능

  • ApplicationSet CRD(Custom Resource) 기반
  • 여러 환경, 여러 클러스터에 앱을 자동 배포할 수 있도록 반복 생
generators:
  - list:
      elements:
        - cluster: dev
        - cluster: prod

6. argocd-redis

캐시 & 성능 최적화

기능

  • Git 요청결과, 렌더링 결과, Application 상태 등을 캐시함
  • 성능 개선 + Git 요청/렌더링 최소화

7. argocd-notifications(별도 설치 시)

기능

  • Slack, Discord, Email 등으로 배포 상태 알림
  • ArgoCD 내부 상태를 감지해서 메시지 전송

Argo CD의 Desired Manifest vs Live Manifest 개념 정리

Desired Manifest(원하는 상태)

  • Argo CD가 Git에서 가져온 YAML 파일을 렌더링 한 결과물(by argocd-repo-server)
  • “시스템인 이 상태였으면 좋겠어”

특징

  • Git 리포지토리에서 버전 관리됨
  • Helm, Kustomize 등 다양한 방식으로 정의 가능
  • Argo CD는 이 Desired 상태를 기준(Reference)으로 삼아 클러스터 상태를 판단함

Live Manifest(실제 상태)

정의

  • 현재 Kubernetes 클러스터에 존재하는 리소스 상태
  • API Server를 통해 실시간으로 조회되는 정보

특징

  • 실제로 Pod가 몇 개 떠 있는지, 어떤 이미지가 쓰이는지 등의 실행 중인 상태
  • kubectl describe, get, logs 등으로 확인 가능
  • kubectl edit, kubectl scale, kubectl patch 등을 하면 이 Live 상태만 바뀌고 Git에는 반영되지 않음

3. Diff

정의

  • Desired 상태(Git) ↔ Live 상태(클러스터)를 비교해서 다른 부분을 식별
  • Argo CD는 이 Diff를 기준으로 Synced, OutOfSync, Unknown 등의 상태를 판단

4. 양방향 접근

Argo CD UI에서 Live 상태를 기준으로 Desired YAML을 만들고 Git에 커밋할 수 있음

즉 내가 배포된 상태에서 여러 변경을 한 후 그 변경을 Git으로 반영할 수 있다는 것이다.

단 항상 권장되는 방식은 Git → 클러스터 방향이다.

 

 

 

 

 

Argo Rollouts 이용한 배포

실습

1. Argo Rollouts 설치

젠킨스로 설치

2. App 생성 (ArgoCD) 후 배포

이번엔 yaml 파일로 만들기

apiVersion: argoproj.io/v1alpha1
kind: Application
metadata:
  name: api-tester-2233
spec:
  destination:
    name: ''
    namespace: anotherclass-223
    server: '<https://kubernetes.default.svc>'
  source:
    path: 2233/deploy/argo-rollouts
    repoURL: '<https://github.com/k8s-1pro/kubernetes-anotherclass-sprint2.git>'
    targetRevision: main
  sources: []
  project: default

3. 트래픽 보내기

 

4. ArgoCD UI에서 Blue/Green 배포 시작하기

4.1 v2 파드가 만들어지는 중

 

4.2 V2가 만들어지고 각 서비스로 가동 중

각 다른 응답을 주고 있음

 

4.3 정상적으로 잘 동작한다면 새로운 버전을 Promote 시켜줌

 

4.4 Active 서비스로 대체되고 기존 Active에 연결된 파드들 삭제됨

 

 

Argo Rollout를 이용한 Carary 배포

1. Master에서 Kubectl로 Rollouts 배포하기

[root@k8s-master ~]#
kubectl apply -f <https://raw.githubusercontent.com/k8s-1pro/kubernetes-anotherclass-sprint2/main/2234/deploy/argo-rollouts/rollout.yaml> -n anotherclass-223
kubectl apply -f <https://raw.githubusercontent.com/k8s-1pro/kubernetes-anotherclass-sprint2/main/2234/deploy/argo-rollouts/configmap.yaml> -n anotherclass-223
kubectl apply -f <https://raw.githubusercontent.com/k8s-1pro/kubernetes-anotherclass-sprint2/main/2234/deploy/argo-rollouts/secret.yaml> -n anotherclass-223
kubectl apply -f <https://raw.githubusercontent.com/k8s-1pro/kubernetes-anotherclass-sprint2/main/2234/deploy/argo-rollouts/service.yaml> -n anotherclass-223

2. 배포 모니터링

// Rollout 조회 하기
kubectl argo rollouts get rollout api-tester-2234 -n anotherclass-223 -w

3. 트래픽 보내기

[root@k8s-master ~]# while true; do curl <http://192.168.56.30:32234/version>; sleep 2; echo '';  done;

 

 

4. 카나리 배포 시작

Step1. Set Weight: 33% : Stable 2 pod, Canary 1 pod 상태로 만듦

v1 파드 2개 66 퍼, v2 파드 1개 33 퍼

 

파드 수에 따라 트래픽 응답도 v1이 더 많음

 

Step2. Pause : Promote 클릭 때까지 멈춤

Promote 클릭

 

 

Step3. Set Weight: 66% : Stable 1 pod, Canary 2 pod 상태로 만듦

V2가 더 많아졌음

이러면서 새로운 파드들이 트래픽을 잘 받나 확인 + 초기 설정등을 미리 할 수 있게 Coldstart 방지까지

Step4. Pause (2m) : 2분 동안 멈춤

 

Step5. : Canary 2 pod 상태로 만듦

기존 V1을 삭제하고 온전히 V2로 트래픽 보내기

 

트래픽이 전부 V2로

 

 

마무리

배포를 더욱 자동화하게 도와주는 게 Argo CD 같다.

Git이 변경을 감지하여 별도의 작업 없이 새로운 클러스터가 만들어지는 것

이미지가 변경되었을 경우(개발 단에서의 변경)도 감지하여 해당 이미지로 클러스터를 만드는 것

이렇게 한 번 선언된 형태 즉 git에 있는 형태 대로 만들어서 관리한다는 점에서 관리자가 할 일이 많이 없어진 것 같다.

 

하지만 이렇게 자동화가 항상 좋은 게 아니니 서비스의 성질에 따라 잘 고민해서 적용해야 할 것 같다.

k8s를 사용하지 않을 수도 있고, 회사 규정이 완전 자동화보다 절차적으로 승인을 기반으로 배포하는 걸 선호할 수도 있기 때문이다.

 

 

강의 후기

이렇게 스터디원들과 같이 듣기 시작한 강의를 완강하게 됐다.

 

쿠버네티스 어나더 클래스 (지상편) - Sprint 1, 2 강의 | 일프로 - 인프런

일프로 | , ✅ 광범위한 쿠버네티스 기술을 A~Z까지 넓고 얇게 훑기보다 하나의 개념을 배우더라도 왜 사용하는지 부터 실무에서 어떻게 사용되는지 까지를 다루는 강의✅ 시작은 초급자지만강

www.inflearn.com

 

사실 이 교육 듣기 전까지는 CI/CD에 대한 기반 지식이 전무했다. 기존에 했던 프로젝트도 로컬환경에서만 진행하고 시연했기 때문이다.

아무것도 모르고 배포해보려고 AWS 만지다가 90만 원이 청구되어 더 겁이 생겼던 것도 있었다.

 

그래도 SA 교육을 시작하면서 팀원들과 강의로 스터디를 진행하게 됐고 이렇게 한 달 안 되는 기간에 이렇게 하나의 강의를 다 볼 수 있었다.

 

나처럼 기반지식이 없는 사람한테는 이 강의가 조금은 불친절하다고 느낄 수 있을 것이다.

실습에 나오는 것들을 모두 이해하고 따라가기가 매우 힘들었다. 

강의가 30분이면 적어도 1시간은 강의에 나온 단어나 개념들을 찾아보느라 사용해야 했다.

그 과정에서 흥미를 느끼면 끝까지 가기 쉽겠지만, 스스로 찾아보는 게 약하거나 힘들다고 느끼면 끝까지 완강하긴 힘들 수 있는 강의 같다.

 

내가 이 강의를 완강했다고 해서 지금 막 k8s와 jenkins를 이용해 배포해 봐라 하면 잘할 수 있을지 의문이다.

이 강의를 통해 내가 얻었다고 자부할 수 있는 건

 

k8s는 왜 도커를 컨테이너 런타임으로 사용을 잘 안 할까

k8s은 어떻게 동작하며 어떤 리소스들이 어떻게 서로 연결되며 컨테이너를 관리하나
왜 jenkins를 쓰는 것인가

Helm, Kustomize를 통해 얻을 수 있는 점 그리고 둘이 뭐가 다른지

Argo CD는 어떻게 구성되어 있고 어떤 점에서 도움을 주길래 사용하는지

 

이 정도의 배포 기술들의 동작흐름 같을 걸 알 수 있었다.

 

이번에 하게 된 프로젝트에서 백엔드 개발하면서 k8s로 배포하는 거까지 한 번 직접 해보면 막연하던 개념들이 조금은 연결되지 않을까 싶다.