90DaysOfDevOps (Day 31)

고태규·2025년 10월 28일

DevOps

목록 보기

30/51

해당 스터디는 90DaysOfDevOps
https://github.com/MichaelCade/90DaysOfDevOps
를 기반으로 진행한 내용입니다.

Day 31 - GitOps on AKS

많은 개발자가 Git 리포지토리에 코드를 저장하고 CI/CD 파이프라인 (ex. kubectl apply 스크립트 실행)을 통해 클러스터에 배포하는 것을 깃옵스 (GitOps)라고 오해하지만, 이는 깃옵스의 핵심이 아니다.

이는 Push 방식이다.

진정한 GitOps는 Pull 방식의 선언형 (Declarative) 모델이다.

선언형(Declarative): "이렇게 만들어라" (명령형)가 아니라, "이 상태여야 한다" (선언형)으로 Git 리포지토리에 원하는 상태를 정의한다.
Pull vs. Push: CI 파이프라인이 클러스터에 명령을 'Push'하는 것이 아니다. 대신, 클러스터 내부에 설치된 에이전트 (Agent)가 Git 리포지토리를 'Pull (가져오기)'한다.
상태 유지 및 조정 (Reconciliation): 깃옵스의 가장 핵심적인 부분으로, 에이전트는 Git 리포지토리의 '원하는 상태(desired state)'와 클러스터의 '현재 상태(current state)'를 지속적으로 비교한다. 만약 두 상태가 일치하지 않으면, 에이전트가 클러스터의 상태를 Git 리포지토리의 상태와 일치하도록 자동으로 '조정'한다.

'Open GitOps' 이니셔티브는 GitOps를 선언적(Declarative), 버전 관리(Versioned) 및 불변성(Immutable), 자동으로 Pull되며, 지속적으로 조정(Continuously Reconciled)되는 4가지 원칙으로 정의한다.

Azure Kubernetes Service(AKS)는 깃옵스를 쉽게 구현할 수 있도록 Flux v2 애드온을 제공한다. 해당 데모는 이 애드온을 활성화하여 Git 리포지토리에 정의된 Nginx 애플리케이션을 배포하는 과정을 보여준다.

(참고: 데모는 포털을 통해 클릭하는 'ClickOps'로 진행되었으나, 실제 운영 환경에서는 Bicep, Terraform 등 IaC(Infrastructure as Code)를 통해 이 설정을 자동화해야 한다.)

리포지토리: Nginx 배포 (app.yml)와 서비스 (service.yml) 정의 파일이 /yaml 경로에 저장된 공개 GitHub 리포지토리
도구: AKS 클러스터 및 Flux v2 GitOps 애드온

GitOps 구성 생성: AKS 클러스터의 'GitOps' 메뉴에서 새 구성을 생성한다.
범위(Scope) 설정: 네임스페이스 or 클러스터 전체로 범위를 정할 수 있다. Ingress Controller 등 클러스터 전반의 구성요소를 bootstrapping하기 위해 'Cluster-wide'를 선택할 수 있다.
리포지토리 연결: Nginx 설정 파일이 있는 GitHub 리포지토리 주소와 브랜치 (main)를 지정한다.
Kustomization 설정: Flux Kustomization을 정의하여 리포지토리 내의 특정 경로 (/yaml)를 동기화하도록 지정한다.

Sync Interval (동기화 간격): 에이전트가 Git 리포지토리의 변경 사항을 확인하는 주기와, 클러스터 상태를 Git 상태와 맞추는 주기(Reconcile)를 설정한다. (데모에서는 1분으로 설정)
Prune (가지치기): 해당 값을 true로 설정하면, Git 리포지토리에서 YAML 파일이 삭제되었을 때 깃옵스 에이전트가 이를 감지하고 클러스터에서도 해당 리소스를 자동으로 삭제한다. 이는 Terraform의 상태 관리와 유사하다.
Force (강제 적용): 클러스터 리소스의 특정 필드가 불변(immutable) 속성이라 변경이 거부될 때, 이 옵션은 해당 리소스를 강제로 재생성하여 변경 사항을 적용한다. 사용 시 주의가 필요하다.

설정이 완료되자마자 AKS 클러스터 내에 flux-system 네임스페이스가 생성되고 Flux 컨트롤러 파드들이 실행된다.
Flux 컨트롤러가 지정된 리포지토리의 /yaml 경로를 읽어와, Nginx 배포와 서비스를 자동으로 생성했다.
데모에서 prune 옵션을 테스트하기 위해 생성했던 GitOps 구성을 삭제하자, Flux가 클러스터에 배포했던 Nginx 관련 리소스 (파드, 서비스 등)도 모두 자동으로 정리되었다.

깃옵스는 단일 클러스터 관리를 넘어 멀티 클러스터 관리 환경에서 강력한 이점을 제공한다.

표준화: 20개의 클러스터가 있더라도, 모든 클러스터가 동일한 Git 리포지토리를 바라보게 하여 동일한 인그레스 컨트롤러, 모니터링 에이전트 등의 표준화된 구성을 유지할 수 있음.
환경 분리: Git 리포지토리의 브랜치 (ex. prod, dev)나 경로 (ex. /clusters/prod, /clusters/dev)를 분리하여, 여러 클러스터가 각자의 환경에 맞는 구성을 선택적으로 'Pull'하도록 설정할 수 있음.

이러한 고급 패턴과 Flux 또는 Argo CD를 사용한 멀티 클러스터 구축 예제를 학습하기 위한 최고의 자료로 Microsoft의 'Calypso' GitHub 리포지토리를 강력히 권장한다.