안녕하세요, DevOps엔지니어링 업무를 맡고 있는 함승우입니다.

KT Azure 환경에서 컨테이너, k8s 배포를 위해서는 ArgoCD를 표준으로 사용해야하는데요, 개별 구독 전용 ArgoCD와 통합 AKS에서 사용되는 통합 ArgoCD를 비교하는 시간을 가져보려고 합니다!

ArgoCD란?

ArgoCD는 Kubernetes 환경에서 애플리케이션을 선언적으로 배포 및 관리할 수 있는 GitOps 기반 CD(Continuous Delivery) 도구에요.

ArgoCD는 GitOps 원칙을 기반으로 애플리케이션의 선언적 배포 및 수명주기 관리를 자동화하는 Kubernetes 특화 CD(Continuous Delivery) 도구에요.

Git 저장소에 정의된 상태를 기준으로, 쿠버네티스 클러스터의 실제 상태를 지속적으로 감시하며, 변경사항 발생 시 안정적으로 자동 배포를 지원하고, 변경이 필요한 경우 자동 또는 수동으로 동기화할 수 있어요.

다양한 배포 전략(Blue-Green, Canary 등)과 멀티 클러스터 관리, 직관적인 대시보드 및 RBAC, SSO 연동 등 엔터프라이즈 환경에 필요한 확장성과 보안성도 갖추고 있는 뛰어난 오픈소스랍니다.

참고자료 >

주요 레퍼런스 : Argo CD - Declarative GitOps CD for Kubernetes
데모 프로젝트 : https://cd.apps.argoproj.io

그렇다면 저희 팀에서는 이 ArgoCD를 KT Azure 환경에서 사용할 수 있게 어떻게 준비해 두었을까요?

개별 구독 전용 ArgoCD (이하 “서비스 ArgoCD” 또는 “서비스”)
통합 AKS 배포용 ArgoCD (이하 “통합 ArgoCD” 또는 “통합”)

서비스팀마다 사용하는 전용 서비스 ArgoCD, 그리고 하나의 클러스터에 namespace로 구분된, 통합 AKS에서 사용하는 공통, 통합 ArgoCD가 있어요.

서비스 ArgoCD 구성하기

1. helm

ArgoCD는 Helm Chart를 직접 지원하며, Helm 저장소를 연동하고 원하는 차트를 선택해 애플리케이션을 배포할 수 있어요.

배포 전 차트와 버전, 목적지 클러스터/네임스페이스를 지정하면 최초 동기화 후 클러스터에 리소스가 생성돼요.

저희 팀에서는 bitnami argocd를 활용해 KT Azure 랜딩존 표준에 맞게 values.yaml 파일을 커스텀해 설치지원하고 있어요.

2. Github SSO (w/ DevOps엔지니어 오지훈)

ArgoCD는 OIDC, OAuth2, LDAP, SAML, GitHub, GitLab 등 주요 SSO 프로토콜을 기본 지원해요.

SSO 설정은 argocd-cm ConfigMap에 Dex 등 인증 중개자를 활용해 연동하며, 조직별/그룹별 로그인 제어가 가능해요.

Github SSO를 적용하기 위해서는, 아래 구성이 필수에요.

a. ArgoCD dex 활성화

TypeScript
    JavaScript
   
    TypeScript
   
    Python
   
    Java
   
    C
   
    C++
   
    C#
   
    Go
   
    PHP
   
    Ruby
   
    Swift
   
    Kotlin
   
    Rust
   
    Scala
   
    SQL
   
    Bash
   
    Shell
   
    HTML
   
    CSS
   
    JSON
   
    XML

dex:
  enabled: true
  image:
    registry: "<KT DevOps ACR>"
    repository: bitnami/dex
    tag: 2.41.1-debian-12-r1
    debug: true1234567

b. Github OAuth App 생성

c. ArgoCD configmap 적용

TypeScript
     JavaScript
    
     TypeScript
    
     Python
    
     Java
    
     C
    
     C++
    
     C#
    
     Go
    
     PHP
    
     Ruby
    
     Swift
    
     Kotlin
    
     Rust
    
     Scala
    
     SQL
    
     Bash
    
     Shell
    
     HTML
    
     CSS
    
     JSON
    
     XML

apiVersion: v1
kind: ConfigMap
metadata:
  name: argocd-cm
  namespace: argocd
data:
  application.instanceLabelKey: argocd.argoproj.io/instance
  dex.config: |
    connectors:
    - type: github
      id: github
      name: KT-Github
      config:
        clientID: ${GitHub OAuth 앱의 클라이언트 ID}
        clientSecret: ${GitHub OAuth 앱의 클라이언트 시크릿}
        redirectURI: ${Github OAuth 앱에 설정한 ArgoCD app의 call back url}
        orgs:
        - name: ${Github Org 이름}
  url: ${Github OAuth 앱에 설정한 ArgoCD app의 homepage url}12345678910111213141516171819

d. Github SSO 로그인


Github SSO가 적용된 ArgoCD	Github SSO	Entra ID 화면

이렇게 Github을 활용해 보다 안전한 ArgoCD를 사용하실 수 있도록 DevOps엔지니어링 담당 부서에서 가이드하고 있어요.

통합 ArgoCD 구성하기

서비스별 독립적으로 사용할 수 있는 서비스 ArgoCD와 다르게, 여러 프로젝트가 공용으로 사용하는 AKS에 배포하는 통합 ArgoCD도 구축/운영하고 있어요.

통합 ArgoCD을 구성하기 위해 어떤 고민을 했는지 소개드릴게요.

1. 서비스 안정성을 위해 고민해야 할 것

a. 클러스터 구분

- 클러스터 수가 늘어나면 리소스 관리, 인증정보 분리, 장애 복구 등의 안정성 이슈가 중요해요.

- ArgoCD는 여러 클러스터를 관리할 수 있어요. 각 클러스터는 Secret 객체로 등록되어, ApplicationSet의 cluster generator 등으로 클러스터별 배포를 자동화할 수도 있답니다.

b. 고가용성

- ArgoCD는 기본적으로 stateless 구조이며, HA(High Availability) 모드를 지원해요. 여러 노드에 컨트롤러와 Redis 인스턴스를 분산 배치해 장애와 부하 분산에 대처할 수 있어요.

2. 프로젝트끼리 어떻게 구분되나요? - RBAC 관리를 위한 GitOps 적용

Project는 애플리케이션의 논리적 그룹화 대상이며, 팀이나 환경별로 생성해 소스/목적지 레포, 클러스터, 리소스 종류, RBAC 정책을 세분화 할 수 있어요.

기본 프로젝트(default)는 모든 권한을 허용하지만, 실제 운영에서는 별도의 프로젝트 정의가 필요해요.

a. RBAC

- ArgoCD의 RBAC는 argocd-rbac-cm ConfigMap에서 정책을 선언적으로 적용해요.

사용자와 그룹별로 애플리케이션 생성, 동기화, 삭제 등 세부 권한을 부여할 수 있으며, SSO 그룹과 연계해 프로젝트/리포지토리/클러스터별로 엄격하게 통제할 수 있어요.

만약 프로젝트 A(project A)에게 통합 ArgoCD를 사용할 RBAC을 적용한다면, 아래와 같이 권한을 부여해요.

TypeScript
     JavaScript
    
     TypeScript
    
     Python
    
     Java
    
     C
    
     C++
    
     C#
    
     Go
    
     PHP
    
     Ruby
    
     Swift
    
     Kotlin
    
     Rust
    
     Scala
    
     SQL
    
     Bash
    
     Shell
    
     HTML
    
     CSS
    
     JSON
    
     XML

g, GITHUB-ORG-PROJECT-A:TEAM-A, role:project-a-role
p, role:project-a-role, applications, *, project-a/*, allow
p, role:project-a-role, repositories, *, project-a/*, allow
p, role:project-a-role, clusters, get, *, allow
p, role:project-a-role, projects, get, *, allow12345

위와 같은 RBAC을 준 이유는 범위별 아래와 같아요.

project A가 공용 AKS에서 자신만의 namespace에 배포할 수 있도록, ArgoCD project에 project-a를 DevOps엔지니어링팀이 admin 권한으로 생성해요. 그리고 이 project-a에는, project-a의 namespace가 1:1로 매칭되어 있어요.

그리고 project-a에 applications와 repositories에 모든 권한(*)을 부여해서 프로젝트A가 GitOps 배포에 문제가 없도록 구성해요.

clusters와 projects에는 ArgoCD에 있는 모든 클러스터와 프로젝트를 리스트업해서, 배포할 자신의 클러스터와 프로젝트를 목록에서 선택할 수 있게 하도록 get 권한만 부여해요.

이렇게 RBAC을 적용하면, 하나의 AKS에 namespace 별로 독립된 공간인 ArgoCD project를 만들어, 논리적 단위로 배포할 수 있게 된답니다!

b. GitOps 적용 (w/ DevOps엔지니어 김주환)

- ArgoCD는 GitOps 원칙에 따라, 모든 배포/구성 변경은 Git 저장소에 커밋된 변경 내용을 기준으로 자동화돼요.

Git repo 변경이 감지되면 클러스터 상태와 동기화하고, 승인 이력과 변경 내역을 추적할 수 있다는 장점이 있어요.

바로 위에서 소개한 RBAC을 적용하기 위해서는 아래와 같은 과정이 필요하고, 그동안 수동으로 처리하고 있었어요.

예를 들어,

1. AKS 커맨드 서버 접속

2. RBAC 적용 (values.yaml)

3. helm upgrade

4. ArgoCD에서 project 생성

5. project ~ namespace 매칭…

이를 운영 관점에서 편리하게 관리하기위해, ArgoCD 자체를 GitOps로 구성하도록 설계했어요!

TypeScript
     JavaScript
    
     TypeScript
    
     Python
    
     Java
    
     C
    
     C++
    
     C#
    
     Go
    
     PHP
    
     Ruby
    
     Swift
    
     Kotlin
    
     Rust
    
     Scala
    
     SQL
    
     Bash
    
     Shell
    
     HTML
    
     CSS
    
     JSON
    
     XML

KT-DevOpsEngTeam/common_argocd_configs
│
└─ dev
    │ argocd-infra.yaml
    │ argocd-project.yaml
    │ argocd-rbac.yaml
    │
    ├─project-chart
    │ │ Chart.yaml
    │ │
    │ ├─files
    │ │ project-A.yaml
    │ │ project-B.yaml
    │ │ project-C.yaml
    │ │
    │ └─templates
    │ appproject.yaml
    │
    └─rbac-chart
        │ Chart.yaml
        │
        ├─files
        │ project-A-rbac.policy.yaml
        │ project-B-rbac.policy.yaml
        │ project-C-rbac.policy.yaml
        │
        └─templates
                rbac-configmap.yaml12345678910111213141516171819202122232425262728

“dev”(line #3) 는 개발 환경에 있는 통합 ArgoCD 내부를 구성하는 yaml 파일이 있어요.

”project-chart” (line #8) 은 논리적 구분단위인 ArgoCD project를 구성하기 위한 파일, “rbac-chart” (line #18) 에는 위 project에 할당할 RBAC 관리 파일로 구성되어 있어요.

각 폴더별로 프로젝트 구성에 필요한 yaml 파일이 배치되어있고, 이 파일 단위로 project와 RBAC을 관리해요. (project ↔︎ RBAC 매칭)

만약 새로운 RBAC 등록 요청이 들어온다면, DevOps엔지니어링 담당 부서에서는 폴더별로 yaml 파일을 만들어 Github repo에 push 하기만하면, RBAC이 등록됩니다.

비교하자면, GitOps 구성과 RBAC 적용으로 모든 구성을 yaml로 관리하며, RBAC 적용 절차가 아래처럼 간소화 되었다는 의미가 있어요!

AS-IS	TO-BE
1. AKS 커맨드 서버 접속 2. RBAC 적용 (values.yaml) 3. helm upgrade 4. ArgoCD에서 project 생성 5. project ~ namespace 매칭…	1. project-chart에 git push 2. rbac-chart에 git push

Argo Rollouts - 다양한 배포 전략 지원

Argo Rollouts 는 ArgoCD에 확장해서 두가지 배포전략을 지원하는 애드온 기능이에요. “Blue/Green”과 “Canary” 배포를 지원하고, Rollouts 전용 대시보드도 구성할 수 있는 기능이 있어요.

Rollouts에 대한 설치 방법이나 기능을 확장해서 사용하고 싶을 경우를 대비해, 가이드라인을 운영하고 있어요.

1. Blue/Green

- ArgoCD는 preSync, sync, postSync hook을 활용해 Blue/Green 배포를 구현할 수 있어요. 새로운 버전의 애플리케이션을 별도 환경에서 검증 후, 기존 서비스 트래픽을 전환해서 신규 버전을 배포해요.

2. Canary

- Canary 배포 역시 sync hook을 통해 점진적으로 트래픽을 새로운 버전으로 이동하며, 단계별 상태 확인을 자동화할 수 있어요. 트래픽 비율, 롤백 정책 등 세부 제어가 가능해요.

3. Rollouts 대시보드

- Rollouts를 배포 타입별로 직관적으로 관리할 수 있는 대시보드에요. Blue-Green, Canary를 적극적으로 사용하신다면, 대시보드 구성도 추천드려요!

앞으로의 계획

a. DevOps엔지니어링 부서에서 일괄 업데이트하기

DevOps엔지니어링 부서에서는 KT Azure 환경에서 사용하실 수 있는 표준 ArgoCD 이미지와 구성을 커스텀해 배포드리고있어요.

bitnami로부터 새로운 차트나 ArgoCD가 릴리즈되거나, 내부 업데이트가 필요한 상황 등 변경이 필요한데, 직원분들이 직접 따라할 수 있는 가이드로는 일관된 배포 환경을 적용하는 것에 한계가 있음을 느끼고 있어요.

이를 극복하기 위해, Github self-hosted runner를 활용해 중앙에서 업데이트 드릴 수 있도록 파이프라인을 구성하고 있어요.

배포 편의성을 위해 노력하는 DevOps엔지니어링 부서의 활약을 기대해주세요!

KT Azure AKS 배포를 위한 서비스, 통합 ArgoCD 구성 비교 분석