[GitOps] GitOps 개념 및 ArgoCD

Git을 활용한 쿠버네티스 배포 컨셉

GitOps는 2017년 OpenGitOps 단체에서 발표한 개념으로 Git을 통해 k8s Manifest 파일을 관리하여 seamless 하게 Time to market을 목표로 운영하자는 개념이다. k8s는 yaml 같이 Pod, Deployment 등 모든 리소스를 Manifest 기반의 '선언적 코드'를 명시해 배포한다는 특징이 있다. 또한 git은 파일들에 대해 형상관리를 해준다는 측면에서 Manifest 파일들에 대한 버전을 관리할 수 있다. 즉, k8s 오브젝트들은 모두 Manifest로 관리된다는 특징을 기반으로 Manifest 파일에 대한 생성, 삭제, 변경 등에 대한 형상 관리를 git과 함께 함으로써 변경이력을 관리하자는 컨셉이다.

 

 

 

https://developers.redhat.com/articles/2022/12/20/gitops-cookbook-kubernetes-automation-practice#devops_and_agility

 

 

 

 

 

GitOps의 대표적인 4가지 원칙

1) Desired State(원하는 상태) 원칙

- 사용자와 플랫폼(k8s)이 읽을 수 있는 선언적  코드로 원하는 상태(Desired State)를 정할 수 있어야 한다.

- 즉, 코드 자체가 운영상의 TO-BE가 된다.

 

2) 불변의 원하는 상태 버전 원칙

- Desired State는 버전 관리 및 버전의 불변성을 지원해야 한다.

- 즉, 특정 코드는 특정 버전에 해당(매핑)되어야 한다.

- 버전 기록을 유지함으로써 형상을 관리한다.

 

3) 지속적인 상태 조정 원칙

- 배포된 상태(Current State, Observable State)를 원하는 상태(Desired State)와 지속해서 자동으로 비교되어야 한다.

- 배포된 상태와 원하는 상태가 달라질 경우 이를 일치시키기 위한 자동화가 적용되어야 한다.

- 예를 들어 애플리케이션의 에러로 Pod에 장애 발생 또는 시스템 자원 부족으로 인한 Pod Pending 상태 반복 등으로 인해 배포된 상태가 변경된다면 원하는 상태와 일치시키기 위한 자동화가 진행되어야 한다. 또한 Git에 변경이력이 발생하여 원하는 상태가 변경되더라도 이를 일치시키기 위한 자동화 작업이 수행되어야 한다.

 

4) 선언을 통한 작동 원칙

- 선언적 코드를 기반으로 상태 값을 지정하고 관리됨으로써 플랫폼이 작동해야 한다.

 

 

 

cf. GitOps를 위한 Git Repository 구성

1) GitOps Repository

- Platform, Management, Service Repository 관리를 위한 레포지토리

 

2) Platform Repository

- 플랫폼 및 쿠버네티스 프로비저닝을 위한 IaC 관리(terraform 등)

 

3) Management Repository

- 쿠버네티스 관리를 위한 설정, 플러그인 등의 코드 관리

- 쿠버네티스 yaml, helm 등

 

4) Service Repository

- 애플리케이션 소스코드 (컨테이너 기반)

 

 

 

---

 

 

ArgoCD란

GitOps와 연동되는 CD툴이다. 배포만 하고 끝나는 것이 아니라 상태체크 및 상태를 자동으로 유지해 주는 등의 기능이 제공된다. 수동으로 트리거하여 배포할 수도 있지만 자동 sync를 통해 자동으로 desire state를 맞춰가며 배포되도록 할 수도 있다.

 

 

대표적인 특징

- 수동 및 자동으로 desire state를 맞춰준다.

- CLI 및 UI 툴이 제공된다.

- Jenkins와 같은 다른 CI/CD 오픈소스들과도 연동된다. 이때 gRPC 또는 REST 기반으로 통신된다.

- Slack 등으로 알림 연동이 가능하다.

- Plane YAML, Helm 등의 템플릿 Manifest 지원된다.

- Git 레포지토리에 커밋된 상태를 기준으로 자동 업데이트 및 롤백 지원된다.

- 실시간 동기화 및 헬스체크가 지원된다.

- GitHub, GitLab 등의 WebHook이 지원된다.

 

 

Argo Rollout이란?

https://argoproj.github.io/argo-rollouts/architecture/

 

 

Rollout은 Argo에서 정의한 k8s CRD(Custom Resource Definition) 기반의 컨트롤러로 다양한 배포방식을 제공한다. 예를 들어, k8s에서는 자동화된 Canary 배포가 지원되지 않지만 Rollout 컨트롤러를 사용하면 이를 자동화할 수 있다. 특히 Canary 배포를 사용할 때 버전 별 트래픽 가중치를 설정하여 동작하도록 설정할 수 있다. Rollout이라는 kind로 Manifest를 명시해서 사용한다.

 

- 관련 포스팅: https://jh-labs.tistory.com/672

 

 

 

Argo Rollout 특징

1) Blue-Green 배포 지원

2) Canary 배포 지원

3) 세분화된 가중치를 기반으로 트래픽 라우팅

4) 자동화된 롤백 지원(이슈 발생 시 이전버전으로 자동 롤백)

5) 외부 트래픽을 k8s 클러스터로 유입하는 다양한 Ingress Controller 통합(AWS ALB, Nginx 등)

6) Service Mesh 툴과 통합(Istio, Linkerd 등)

7) 바로 롤링 업데이트하는 것이 아니라 안정성 테스트 등의 검증 과정을 포함시킬 수 있음.

 

cf. Blue/Grean 배포 기법

무중단 배포기법 중 하나로 이전 버전을 blue 환경으로, 새 버전은 green 환경으로 부른다. 프로덕션 트래픽이 blue에서 green으로 완전히 이전되면 blue는 롤백에 대비하여 대기 상태로 두거나 프로덕션에서 가져온 후 업데이트하여 다음 업데이트의 템플릿으로 삼을 수 있다. 두 버전을 로드밸런서에 연결하고 한 번에 새로운 버전으로 변경한다.

1) 장점: 빠른 시간 내에 신규 버전으로 변경 가능 및 롤백 가능

2) 단점: 한 번에 업그레이드 하기 위해 기존버전과 신규버전이 동시에 떠있는 상태가 잠깐 발생하고 이때 시스템 리소스를 많이 사용하게 됨

 

 

 

일반적은 ArgoCD 기반의 CI/CD 파이프라인

https://www.gspann.com/resources/blogs/continuous-delivery-for-kubernetes-with-gitops-and-argo-cd/

 

1) 사용자가 Git에 소스코드를 커밋/푸시

2) Jenkins가 커밋 감지 및 Jenkins Pipeline 실행

    2-1) gradle 등의 빌드 툴로 빌드

    2-2) 컨테이너 이미지 빌드

    2-3) 컨테이너 레지스트리 푸시

    2-4) Git의 Manifest 레포지토리에 Manifest파일 push(보통 컨테이너 이미지 버전 tag 수정)

3) ArgoCD가 Git의 Manifest 레포지토리 변경 감지

4) ArgoCD가 컨테이너 이미지 레지스트리로부터 pull

5) Pod 업데이트 (Argo Rollout 등)

 

 

https://hwannny.tistory.com/113

 

 

 

- ArgoCD 구축 포스팅: https://jh-labs.tistory.com/671

 

 

 

 

 

 

Reference

- , https://developers.redhat.com/articles/2022/12/20/gitops-cookbook-kubernetes-automation-practice#devops_and_agility

- OpenGitOps, https://opengitops.dev/

- Argo Rollout, https://argoproj.github.io/argo-rollouts/architecture/