[2-7] ArgoCD 빠르게 레벨업 하기

📚 ArgoCD의 여러 역할

ArgoCD

• k8s 전용 배포 툴이고 릴리즈 파일 저장소로 Git을 반드시 필요로 함

Image Updater

• 컨테이너 이미지에 대한 변경을 감지해서 배포를 할 수 있는 파이프라인 생성 가능

Rollouts

• 고급 배포 지원

Events

• 카프카와 같은 역할을 하는 솔루션
• 이벤트 버스 구조의 아키텍처 도구

Workflow

• Airflow나 Cubeflow와 같은 역할하는 Workflow Management 도구

 

배포 아키텍처

 

 

 

 

-> 시스템들 간의 이벤트를 주고받는 메인 통로 역할

 

-> 이벤트의 내부 값에 따라서 어떤 작업을 실행하라는 순서도

-> 실행도중 배포하라는 작업이 있다면 CD로 이동

 

 

 

 

-> 특정 배포 전략으로 쿠버네티스의 자원을 생성

 

 

 

 

 

 

---

 

🔎 클러스터 내부에서 아키텍처

Server

• API 서버와 대시보드 역할을 동시에 함
• 이로 인해 노드포트로 ArgoCD UI에 접속을 할 수가 있음
• kubectl처럼 argocd라는 툴을 설치해서 CLI를 날릴 수 있음

Repo Server

• Git에 연결을 해서 Yaml 파일들을 가져옴
• Kubernetes에 배포할 매니페스트를 만들어 놓는 역할을

Application Controller

• Kubernetes의 리소스를 모니터링
• Git에서 받은 내용과 다른 게 있는지 비교
• 내용이 다르면 Git에 있는 내용으로 배포가 진행

Kube API

• Kubernetes로 리소스 생성 명령을 날려주는 역할

Notification

• ArgoCD에서 발생하는 이벤트를 외부로 트리거해주는 역할

Dex

• 외부 인증 관리를 하는 역할
• Kubernetes를 하다 보면 Grafana나 이외의 다른 대시보드들을 많이 쓰게 됨
• 근데 관리자 입장에서 그 UI마다 ID 패스워드를 만들고 관리하는 게 번거롭다...
• 그래서 IAM 솔루션을 많이 사용
• 그럼 사용자가 여기에다가만 로그인을 하면 이 IAM 솔루션이랑 연결된 시스템에는 별도로 로그인을 안 해도 자동 로그인이 됨
• 흔히 Single Sign-On 이라 하고, Kubernetes에서는 대표적으로 KeyCloak이 있음

Redis

• 메모리 DB로 시스템에서 캐시 역할을 많이 함
• Git 허브와 연동되는 구간이랑 Kube API 서버랑 연동되는 구간에 캐시로 쓰여서 불필요한 통신을 줄여주는 역할

ApplicationSetController

• 멀티 클러스터를 위한 앱 패키징 관리 역할
• ArgoCD는 클러스터마다 설치를 할 수도 있지만 이렇게 하나만 설치를 해서 여러 클러스터로 앱을 배포할 수도 있다..
• -> 이렇게 쓰는 상태일 때 배포 환경마다 ArgoCD에서 배포 구성을 만들어 줘야 함
• -> 또 중복되는 구성들이 생기기 때문에 Application Set Controller가
• -> 환경별로 다른 부분만 세팅을 해서 사용할 수 있는 템플릿을 제공(like 헬름이랑 커스터마이즈)

 

---

 

 

💻 Argo Apps 설치 및 배포

• Artifact HUB에서 Helm 패키지로 설치
• Jenkins로 Argo Apps를 설치하는 job 하나 생성
• -> 실행하면 패키지를 다운받은 다음 k8s 클러스터에 설치

 

(1) Github 관리

1. App 소스 코드 전용

 

2. App 릴리즈 전용

• 앱을 배포하기 위해 만든 릴리즈 전용 repository

3. Addon 설치 전용

• k8s에 ArgoCD와 같은 Addon 설치하기 위한 repository

이와 같이 repository를 분리하자!!
각 repository 별로 사용하는 담당자나 연동을 해야 되는 시스템이 다르기 때문
접근 유저별 권한관리
불필요한 코드 다운 방지
[EX]
앱 소스 - 개발자
앱 릴리즈 전용 - DevOps 엔지니어
-> 프로젝트 상황에 따라 정답은 없기에 개발자가 본인 앱에 대한 배포를 담당하기도 함
-> DevOps엔지니어는 관리자 역할, 개발자는 사용자 역할을 할 수도 있음

 

 

(2) 클러스터 내부에서 ArgoCD는 뭐함?

• 깃에서 릴리즈 파일을 받아서 k8s에 배포를 하는게 최종 목적
• 하나의 app을 배포하는 단위가 Application
• -> 여러개가 만들어질 수 있고 default라는 Project에 소속이 됨
• Project는 Application들을 그룹핑하는 용도

 

Source

• 연동할 Git에 대한 정보를 입력
• ArgoCD를 깃에 연결해 놓으면 자동으로 변경 사항이 감지되지만 3분정도 체크 인터벌이 있음
• Refresh 버튼을 누르면 바로 견경사항 체크를 해줌

Destination

• 배포할 k8s의 클러스터 정보를 입력
• Synchronize 버튼을 누르면 k8s에 배포를 실행

General

• 기본 정보나 배포 시에 줄 옵션들이 들어감
• Sync Policy - 리소스 변경 사항 감지시 수동 배포와 자동 배포 중 선택(자동으로 할 경우 3분 이내에 배포)
• Sync Option - 배포 상세 옵션, EX) 배포할 때 네임스페이스를 자동 생성할 건지와 같은 배포 시 부가 기능
• Prune Policy - 리스소 삭제 정책

배포 툴

• Directory
• Helm
• Kustomize
• ArgoCD가 릴리즈 파일들을 다운받으면 자동으로 어떤 포맷인지 인식

Desired Manifest

• Git에 있는 Yaml파일을 다운받은 Manifest

 

Live Manifest

• k8s에 있는 리소스를 조회한 Manifest

 

Manifest 작동방식

• 깃에 Configmap이 있을 때, 3분안에 ArgoCD가 Desired로 받아옴
• -> Sync 버튼을 누르면 k8s에 배포가 되면서 Live가 만들어짐
• Live Manifest는 k8s의 실제 리소스를 그대로 조회하고 있는 것
• -> k8s에서 자원을 직접 수정하게 되면 이곳에 바로 반영
• -> k8s에 자원을 직접 수정해도 이곳에 반영됨
• -> ArgoCD에서 Live를 수정하게되면 k8s에 반영이 됨
• 즉, 서로 변경 상태를 반영하는 구조!!

BUT!!

• Desired Manifest는 ArgoCD가 수정 불가...
• -> 깃에서 수정하고 Refresh해야 변경이 됨
• -> 이 상태에서 diff 버튼이 활성화됨

diff 버튼은 어디다 씀?
desired와 live의 비교라고 생각하기 쉽지만 아니다..
**깃에 변경 사항이 반영될 live와 현재 live의 비교**

 

 

---

 

 

📋 ArgoCD Image Updater를 이용한 이미지 자동 배포

(1) 배포를 해야 되는 상황

1. 리소스 스펙 변경해야 할때

• Deployment에서 배포 전략을 바꾼다든지 수동으로 스케일 업 해야 될때
• DevOps 엔지니어는 Yaml 파일을 수정해서 깃에 커밋을 하고 배포 실행하면 k8s에 반영
• 수작업 필요

 

2. 앱 버전이 업그레이드 돼서 컨테이너 이미지 변경

• 이미지 태그를 수정하고 커밋하는 과정은 Helm을 쓰면 배포 명령에 동적으로 태그 값을 줄 수 있음
• 따라서 Yaml 파일을 별도로 수정할 필요가 없이 배포를 할 수 있음
• 자동화 가능

사용해야하는 이유??

• ArgoCD에서 릴리즈 파일에 대한 변경 감지를 해주기 때문에 자동으로 배포가 됨
• 하지만 컨테이너 빌드가 끝난 이후에 자동 배포를 하는 게 힘들어짐

 

Image Updater는 뭐함??

• ArgoCD와 CI/CD 서버 사이에 Image Updater 존재
• 도커 허브의 이미지 업데이트를 감지하면 ArgoCD에 배포 명령을 보냄(배포 패키지를 Helm, Kustomize를 사용해야함)
• ArgoCD와 dockerHub 연결 정보를 Image Updater에 입력해야함

 

 

---

 

 

⭐️ Argo Rollouts를 이용한 배포

• ArgoCD 없어도 Rollouts 사용가능
• Rollouts 자체적으로 대시보드가 있는 독립적인 솔루션

(1) Blue/Green 배포

• 운영 환경에서만 테스트가 가능한 상황
• 배포시 롤백이 빠름
• 배포 중 V1과 V2간의 동시 호출 없음
• 스크립트를 통해 자동 배포 가능
• V2에 과도한 트래픽 유입시 문제 발생

Deployment 사용시

• V2 deployment를 먼저 만들고 서비스를 붙여서 QA 담당자가 테스트를 한 후
• 기존의 서비스 셀렉터를 V2로 바꿔서 트래픽을 변경
• 이후에 문제가 없으면 V1 deployment 삭제

 

Rollouts 사용시

• Rollout이라는 컨트롤러 생성 가능
• CRD: 사용자가 정의한 사용자 정의 리소스를 Kubernetes 클러스터에 추가하는 방법을 정의
• CRD를 만든 이후에 GO언어로 리소스가 어떻게 동작을 하라는 로직을 개발 해야됨
• 이때 만든 컨트롤러를 통해서 레프리카 셋이나 파드의 동작을 변형시킬 수 있음
• 이 모든 것을 Rollouts이 했다

 

Rollouts 핵심 설정

• 서비스 2개를 지정

1. 실제 서비스 사용자가 들어오는 액티브 서비스

2. 업그레이드 중에 V2 버전으로만 들어가 볼 수 있는 프리뷰 서비스

• 두 서비스 모두 처음에는 V1 버전의 파드로 트래픽을 전달
• SYNC or 자원 직접 수정 시 V2 버전 레플리카셋 생성
• 액티브 서비스는 그대로 V1
• 프리뷰 서비스는 V2 파드로 연결 변경
• 즉, Rollout이 파드들의 레이블을 달고, 서비스 셀렉터에 레이블 내용을 달아서 자동으로 연결
• QA 담당자는 프리뷰 서비스를 통해서 테스트를 진행
• 테스트를 마치고 Promote 명령어를 날리면 트래픽이 변경되고 V1 파드들은 삭제

 

(2) Canary 배포

• 특정 헤더 값에 한해서만 V2로 트래픽 유입
• 트래픽 배분을 조절하면서 콜드 스타트 방지
• 두 버전을 비교하기 위한 A-B 테스트 용도로 사용

 

Deployment 사용시

 

 

Rollouts 사용시

• Rollout 배포 전략으로 Canary를 선택한 후
• 상세 속성으로 Steps 설정
• setWeight는 전체 파드에서 Canary가 차지하는 파드의 비율
• pause에 적혀있는 만큼 Promote 명령이 올때까지 대기(비어있다면 무한정 대기!!)

 

 

---

출처

[인프런] 쿠버네티스 어나더 클래스 (지상편) - Sprint 1, 2

저자 : 일프로