[Kubernetes] ArgoCD 사용해보기 (1) - ArgoCD 설치 및 기본 배포

Argo CD란??

Argo CD란 Git을 기반으로 사용하는 Kubernetes의 addon으로써 배포를 도와주는 오픈소스입니다.
사용하기 편한 UI를 가지고 있으며 Application별 생성한 Pod의 상태를 파악하는데에도 도움이 됩니다.

 

Argo에는 다양한 도구 존재하는데 이는 필요시 찾아보면서 사용해보시면 되겠습니다.

CD

Kubernetes 전용 배포 툴로써 소스코드를 감지하여 변경사항을 모니터링하고 변경된 것이 있으면 자동으로 감지하여 배포해주는 역할을 합니다.

Image Updater

CD의 추가기능으로써 Image Updater는 허브에 있는 이미지의 변경을 감지하여 배포해주는 역할을 합니다.
CD와 별개로 사용할수도 있지만 보통 같이 사용합니다.

 

감지 방법에는 세가지가 있습니다.

1. 태그 기반 감지
   • :lastest 태그가 새로운 버전으로 교체될 경우
   • :v1.2 -> v1.3 처럼 특정 패턴의 태그가 교체된 경우
   • :v1.2.x -> v1.3.x 처럼 SemVer(버전 규칙)의 패턴 감지
2. 다이제스트(Digest)기반 감지
   • 이미지의 SHA-256 다이제스트 값이 변경되었을 경우
   • ex) sha256:abcd1234... -> sha256:efgh5678...
3. 레지스트리 웹훅(Webhook) 연동
   • 도커 허브(ECR, GCR 등)에서 새로운 이미지가 푸쉬되면, Argo Cd Image Updater가 이를 바로 감지

Argo Rollouts란?

배포시 사용하는 배포전략 선택에 사용하는 툴입니다.
Kubernetes의 Rolling Update기반으로 동작하며 Canary, Blud-Green, Experiment배포가 주요 기능입니다.

기능	Kubernetes Deployment	Argo Rollouts
기본 배포 방식	Rolling Update	Canary, Blue-Green, Experiment
트래픽 조절	불가능	가능
A/B 테스트	지원 안 함	지원
자동 롤백	일부 가능	강력한 지원 (Metric 기반)

Argo Events란?

특정 이벤트 발생시 자동으로 워크플로우를 실행해주는 툴입니다.

 

주요 기능으로는 두가지가 있습니다.

1. 이벤트 감지 및 트리거
   • Webhook, Kafka, S3 파일업로드, CronJob 등 다양한 이벤트를 감지
   • 감지된 이벤트를 기반으로 Argo Workflows실행
2. 자동화 파이프라인 구축
   • 특정 조건에서만 배포 수행(ex. 특정 브랜치 merge 후 배포)
   • CI/CD 파이프라인을 더 정밀하게 제어

기능	Tekton	Jenkins	Argo Events
이벤트 기반 실행	제한적	가능	매우 강력
쿠버네티스 네이티브	O	X	O
확장성	높음	낮음	매우 높음
사용목적	CI/CD	CI/CD	이벤트중심 자동화

Argo Workflows란?

Kubernetes에서 실행되는 워크플로우 관리 툴입니다.
여러 개의 작업(Job)을 연결하여 순차적 or 병렬로 실행할 수 있도록 자동화하는 도구라고 생각하면 됩니다.

예를 한번 들어볼까요??
AI 모델을 학습을 자동화 한다고 가정해 봅시다.

1. 데이터를 다운로드
2. 데이터를 전처리
3. 학습을 수행
4. 결과를 저장

이렇게 단계적으로 여러개의 작업을 요구합니다. 이럴 경우 사용하는 것으로써 워크플로우!!
우리가 입력한 순서대로 작업이 완료되고 실행하게 하는 것!
즉, 작업을 수행할 순서를 정해 줄 수 있는 것이죠.

기능	Apache Airflow	Tekton	Argo Workflows
주요 용도	데이터 파이프라인 자동화	CI/CD	O
쿠버네티스 네이티브	X	O	O
DAG 지원	O	제한적	O
병렬 처리	가능	제한적	매우 강력
GipOps 연동	제한적	가능	최적화

Argo CD 아키텍처

Argo CD를 설치하면 아래와 같은 관련 Pod들이 설치가 되는데요. 각각 어떤 역할을 하는지 설명해 보겠습니다.

 

우선 port중에 30002번 포트는 브라우저에서 사용하는 UI가 있는 대쉬보드 같은 역할을하기 위한 포트입니다.

 

아래로 접속하면 해당 Argo CD홈페이지가 나오는 것을 확인 할 수 있을 겁니다.

${Master Node Ip}:30002

 

그리고 argocd라는 cli 명령어를 설치해서 직접 커멘드를 날려 사용 할 수도 있습니다.

argocd --help

Server

Kubernetes의 keube-apiserver와 같이 다른 Argo Pod들 간 네트워킹을 연결해주는 역할을 합니다.

Dex

Dex의 경우에는 외부에서 로그인시에 인증관리 역할을 시행합니다.

Notification

이벤트 트리거로써 우리가 사용하는 Slack이나 다른 툴에서 이벤트가 발생하면 어떤 이벤트가 발생했는지 알림이 오죠?? 그러한 역할을 담당하게 됩니다.

Repo Server

Argo CD에서 사용하는 레파지토리 서버입니다.
Git과의 연결을 담당하고 배포할 .yaml 미니패스트를 생성하는 역할을 합니다.

Redis

오픈소스중에 Redis를 알고 계시나요??
이 Redis의 경우에는 Memory DB로써의 역할은 같습니다.
하지만 사용목적은 Argo CD 한정으로 사용 할 뿐인 것이죠.
주요 역할은 Argo CD의 캐싱 및 상태를 저장하고 Kube API와 Git요청 등 무분별한 통신을 막아주기 위해 데이터를 캐싱하는 역할을 합니다.

ApplicationSet Controller

멀티 클러스터를 위한 App패키징 관리를 하며 하나의 Argo CD로 개발, 검증, 운영 모두를 담당 할 수수 있게 1:N으로도 구축을 하지만 개별적으로 1:1로도 구축하기도 합니다.

Application Controller

Kubernetes 리소스를 모니터링하고 Git과 비교하는 역할을 합니다.

 

밑에서 알아보겠지만 diff를 이용해 변경감지를 할 수도 있는 것이죠.

Kube API

당연하게도 Kubernetes에서 배포를 실행하기 위해서는 kube-apiserver와 통신을 해야겠죠??
이 역할을 해주는게 Kube API입니다.

---

Argo Apps 설치

시작전 참고사항

저의 경우에는 따로 다운받고 실행해보았지만, 편하게 해보고싶으신분들은 아래 내용을 따라해 보시기 바랍니다.

 

하지만, 개인적으로는 한번 쓰윽 읽고 직접 다운받아서 개인 레파지토리로 해보는 것을 추천하고 싶네요. 아무래도 고생을 해봐야... 오래 남지않겠습니까?? ㅎㅎ

 

그럼 시작합니다.

사전에 작업해 놓은 내용

# helm이 설치돼 있는 서버에서 작업
# helm 레포지토리(argo-cd) 설정 및 다운로드
helm repo add argo https://argoproj.github.io/argo-helm
helm pull argo/argo-cd --version 5.52.1
helm pull argo/argocd-image-updater --version 0.9.2
helm pull argo/argo-rollouts --version 2.34.1
# 압축 해제
tar -xf argo-cd-5.52.1.tgz
tar -xf argocd-image-updater-0.9.2.tgz
tar -xf argo-rollouts-2.34.1.tgz
# 내용 확인
ls argo*
------
argo-cd-5.52.1.tgz argocd-image-updater-0.9.2.tgz argo-rollouts-2.34.1.tgz

argo-cd:
Chart.lock charts Chart.yaml README.md templates values.yaml

argocd-image-updater:
Chart.yaml README.md templates values.yaml

argo-rollouts:
Chart.yaml README.md templates values.yaml
# helm package를 Github로 업로드
https://github.com/k8s-1pro/install/tree/main/ground/cicd-server/argo/helm/argo-cd
https://github.com/k8s-1pro/install/tree/main/ground/cicd-server/argo/helm/argocd-image-updater
https://github.com/k8s-1pro/install/tree/main/ground/cicd-server/argo/helm/argocd-rollouts

ArgoCD 설치하기

우선 설치는 Jenkins에 접속해서 작업할 겁니다.

 

+ 버튼을 눌러서 새 보기 만들기

조회명 : add-on
Type : List View

item name 입력 및 Pipeline 선택

Enter an item name에 deploy-argo 입력하고 Pipeline을 선택한 후에 OK 버튼 클릭해주세요.

Configure > General > GitHub project > Project url

Project url : https://github.com/k8s-1pro/install/

Configure > Pipeline

Helm과 Kustomize 비교하며 사용하기에서 Jenkins에서 Credential이 사전에 설정되어 있어야 아래 빌드가 정상 동작합니다.

설정을 완료했으면 저장 후 파라미터와 함께 빌드를 클릭해줍니다.

Definition : Pipeline script from SCM
Definition > SCM : Git
Definition > SCM > Repositories > Repository URL : https://github.com/k8s-1pro/install.git
Definition > SCM > Branches to build > Branch Specifier : */main
Definition > SCM > Branches to build > Additional Behaviours > Sparse Checkout paths > Path : ground/cicd-server/argo
Definition > Script Path : ground/cicd-server/argo/Jenkinsfile

# Mac 유저분께서는 [****Script Path] 부분을 아래와 같이 해주세요.

Definition > Script Path : ground/cicd-server/argo/Jenkinsfile-mac

Namespace 생성

Argo CD 배포

Argocd Image Updater 배포

Argo Rollouts 배포

ArgoCD 접속

다음 주소에 접속해봅시다.

https://${Master Node IP}:30002/login

ArgoCD 관리자 비밀번호 확인 (CI/CD or Mastser server)

초기 비밀번호를 확인해야합니다.
확인 커멘드는 아래에 적어두었으니 확인해보세요.

kubectl get -n argo secret argocd-initial-admin-secret -o jsonpath='{.data.password}' | base64 -d L5DwRCgwiHD7CXDb

ArgoCD 로그인

▶ Username : admin
▶ Password : 위 명령어의 결과값

로그인 이후 [User Info] > [UPDATE PASSOWRD] 에서 변경 가능

App 배포하기 (kubectl)

App 생성 하기

좌측 네비바에서 Applications를 클릭하고 '+ NEW APP' 클릭하여 App을 생성하도록 합니다.
그리고 일반속성에서 체크박스를 체크해주어 Namespace가 자동으로 생성되도록 설정해줍니다.

▶ GENERAL

Application Name : api-tester-2231
Project Name : default
SYNC POLICY : Manual

• AUTO-CREATE-NAMESPACE

▶ SYNC OPTIONS

• SKIP SCHEMA VALIDATION :
  • 매니패스트에 대한 yaml 스키마 유효성 검사를 건너뛰고 배포 (kubectl apply --validate=false)
• PRUNE LAST :
  • 동기화 작업이 끝난 이후에 Prune(git에 없는 리소스를 제거하는 작업)를 동작시킴
• RESPECT IGNORE DIFFERENCES :
  • 동기화 상태에서 특정 상태의 필드를 무시하도록 함
• AUTO-CREATE NAMESPACE :
  • 클러스터에 네임스페이스가 없을 시 argocd에 입력한 이름으로 자동 생성
• APPLY OUT OF SYNC ONLY :
  • 현재 동기화 상태가 아닌 리소스만 배포
• SERVER-SIDE APPLY :
  • 쿠버네티스 서버에서 제공하는 Server-side Apply API 기능 활성화 (레퍼런스 참조)

​

▶ PRUNE PROPAGATION POLICY ​(레퍼런스 참조)

• foreground :
  • 부모(소유자, ex. deployment) 자원을 먼저 삭제함
• background :
  • 자식(종속자, ex. pod) 자원을 먼저 삭제함
• orphan :
  • 고아(소유자는 삭제됐지만, 종속자가 삭제되지 않은 경우) 자원을 삭제함

▶ 참고자료

https://kubernetes.io/docs/reference/using-api/server-side-apply/

Server-Side Apply

FEATURE STATE: Kubernetes v1.22 [stable] Kubernetes supports multiple appliers collaborating to manage the fields of a single object. Server-Side Apply provides an optional mechanism for your cluster's control plane to track changes to an object's fields. At the level of a specific resource, Server-...

kubernetes.io

https://kubernetes.io/ko/docs/concepts/architecture/garbage-collection/

 

가비지(Garbage) 수집

쿠버네티스가 클러스터 자원을 정리하기 위해 사용하는 다양한 방법을 종합한 용어이다. 다음과 같은 리소스를 정리한다: 종료된 잡 소유자 참조가 없는 오브젝트 사용되지 않는 컨테이너와 컨테이너 이미지 반환 정책이 삭제인 스토리지클래스에 의해 동적으로 생성된 퍼시스턴트볼륨 Stale 또는 만료된 CertificateSigningRequests (CSRs) 노드 는 다음과 같은 상황에서 삭제된다: 클러스터가 클라우드 컨트롤러 매니저를 사용하는 클라우드 클러스터가 클라우드 컨트롤러 매니저와 유사한 애드온을 사용하는 온프레미스 노드 리스(Le...

kubernetes.io

https://kubernetes.io/ko/docs/tasks/administer-cluster/use-cascading-deletion/#set-orphan-deletion-policy

 

클러스터에서 캐스케이딩 삭제 사용

이 페이지에서는 가비지 수집 중 클러스터에서 사용할 캐스케이딩 삭제 타입을 지정하는 방법을 보여준다. 시작하기 전에 쿠버네티스 클러스터가 필요하고, kubectl 커맨드-라인 툴이 클러스터와 통신할 수 있도록 설정되어 있어야 한다. 이 튜토리얼은 컨트롤 플레인 호스트가 아닌 노드가 적어도 2개 포함된 클러스터에서 실행하는 것을 추천한다. 만약, 아직 클러스터를 가지고 있지 않다면, minikube를 사용해서 생성하거나 다음 쿠버네티스 플레이그라운드 중 하나를 사용할 수 있다. Killercoda Play with Kubernetes...

kubernetes.io

▶ SOURCE

Repository URL : https://github.com/k8s-1pro/kubernetes-anotherclass-sprint2.git Revision : main Path : 2231/deploy/k8s

▶ DESTINATION

Cluster URL : https://kubernetes.default.svc
Namespace : anotherclass-223

• Directory

▶ 화면 상단 CREATE 클릭

배포하기

상단 네비바에서 SYNC 클릭하고 우측에 나오는 팝업창에서 SYNCHRONIZE를 클릭하면 배포가 시작됩니다.

• PRUNE :
  • GIt에서 자원 삭제 후 배포시 K8S에서는 삭제되지 않으나, 해당 옵션을 선택하면 삭제시킴
• FORCE :
  • --force 옵션으로 리소스 삭제
• APPLY ONLY :
  • ArgoCD의 Pre/Post Hook은 사용 안함 (리소스만 배포)
• DRY RUN :
  • 테스트 배포 (배포에 에러가 있는지 한번 확인해 볼때 사용)

배포 확인

App 배포하기 (helm)

App 생성 하기

좌측 네비바에서 Applications를 클릭하고 '+ NEW APP' 클릭하여 App을 생성하도록 합니다.
그리고 일반속성에서 체크박스를 체크해주어 Namespace가 자동으로 생성되도록 설정해줍니다.

▶ GENERAL

Application Name : api-tester-2232
Project Name : default
SYNC POLICY : Manual

▶ SOURCE

Repository URL : https://github.com/k8s-1pro/kubernetes-anotherclass-sprint2.git Revision : main Path : 2232/deploy/helm/api-tester

▶ DESTINATION

Cluster URL : https://kubernetes.default.svc
Namespace : anotherclass-223

▶ HELM 선택 후 Values files 지정

VALUES FILES : values-dev.yaml

▶ 화면 상단 CREATE 클릭

배포하기

상단 네비바에서 SYNC 클릭하고 우측에 나오는 팝업창에서 SYNCHRONIZE를 클릭하면 배포가 시작됩니다.

배포 확인

---

그 외 참고사항

변경사항 바로 적용

Refresh

상단 네비바에 존재하는 버튼입니다.

 

Argo CD는 약 3분마다 소스코드의 변경을 감지하여 배포를 새로 시작하는데요.
기다리기 싫고 바로 변경사항을 적용하기 위해서는 Refresh버튼을 클릭해주면 됩니다.

변경사항에 대한 내용을 알려주는 diff

Argo CD에서는 diff로 변경사항을 감지할 수 있는데 주의해야할 점이 있습니다.

 

ConfigMap으로 설명해 드리겠습니다.
우선 ConfigMap을 클릭하여 화면을 열어주도록 합니다.

 

그러면 이러한 화면이 보이실 건데요.
DIFF를 기준으로 LIVE MAINFEST와 DESIRED MANIFEST가 보일 겁니다.

LIVE MAINFEST

현재 Kubernetes에서 동작중인 .yaml에 대한 내용이 보이는 항목입니다.

DESIRED MAINFEST

Git에 올라가 있는 .yaml파일에 대한 내용입니다.

LIVE MAINFEST 수정

직접 수정을 할 수 있는데요.
이렇게 수정을 하면 Kubernetes에 바로 반영이 됩니다.

EDIT를 눌러서 다음을 추가해 줍시다.

data:
  argo: changed

 

그럼 바로 반영이 되는지 한번 확인해 볼까요??
Kubernetes의 대쉬보드로 가서 한번 확인해보죠.

 

 

수정되어 있는게 보이시나요???
그럼 반대로 Kubernetes에서 수정해보고 Agro CD에도 반영이 되는지 확인해보시죠.

 

 

다음과 같이 k8s속성을 추가하고 업데이트 이후에 Agro CD에서 확인해 봅시다.

 

자! 적용되어 있는게 보이시죠??

이렇게 실시간으로 변경된 사항을 확인하고 적용시킬 수 있습니다.

 

 

이제야 DIFF에 대한 내용인데요?!!?!

 

제가 LIVE MAINFEST와 DESIRED MAINFEST에 대해 설명해드렸죠?
그러면 우리가 여기에서 DIFF를 클릭하면 예상으로는 k8s와 argo부분이 다르다는 것이 나와야 한다고 생각할 겁니다.

 

한번 보시죠.

 

 

에??

 

하지만, 보이지 않죠??

 

이 부분이 주의해야 하는 부분입니다.
DIFF가 가운데에 있어 두 MAINFEST의 비교점을 비교해주는 것 처럼 보이지만 실상은 그게 아닙니다.

 

DIFF에서 내용이 안나오는 이유는 DESIRED MAINFEST를 SYNC를 해도 LIVE MAINFEST에 추가하거나 삭제할 내용이 없기 때문에 DIFF한 내용이 없다고 판단하는 것입니다.

 

이해가 되시나요??

 

이해가 안되신다면 이렇게 생각해보시죠.

LIVE MAINFEST에 DESIRED MAINFEST를 병합하는 과정에서 DIFF한게 없다!!

 

라고요...

 

그러면 Kubernetes에도있고 Git에도 있는 데이터를 수정하면??
그럴 경우에는 SYNC시에 변경할게 있기 때문에 DIFF가 생겨야 겠죠?? 한번 봅시다.

 

 

보이시나요?? 이렇게 DIFF부분이 나옵니다.

 

이 상황에서 SYNC를 하게 되면 Git에 있는 내용으로 업데이트가 되기 때문에 data.data속성의 값은 'content'로 변경이 될것입니다. 한번 해볼까요??

 

 

변경이 되었죠??

 

Git에서 data.git속성에 'changed'라고 값을 추가하고 커밋을 하면 똑같이 DIFF에 나오게 되는 것이죠.

 

 

이해가 되셨나요??

 

DIFF는 MAINFEST의 값의 비교를 하는 것이 아닌 Git을 기반으로 동작한다는 점을 이해해야 합니다.

이 점을 반드시 주의해 주세요!

 

이 글은 인프런의 일프로님 강의를 재정리한 내용입니다.