🚀 요약
SUMMARY
쿠버네티스 환경의 배포 도구로 두 가지 솔루션을 목적에 따라 선정했다.
- 플랫폼 컴포넌트 배포:
Helmfile을 사용하여 Helm 차트의 한계를 보완하고 복잡한 설치/삭제 라이프사이클을 자동화했다.- 자사 솔루션(애플리케이션) 배포:
Argo CD를 도입하여 GitOps 워크플로우를 구축하고, 개발자의 배포 편의성과 운영 안정성을 높였다.
💡 개요
쿠버네티스 클러스터에서 애플리케이션과 각종 컴포넌트를 배포하는 방식은 다양하다. 다양한 선택지가 있다는 것은 장점이기도 하지만 서로 다른 포맷을 관리해야한다는 점에서 복잡성으로 다가오기도 했다. 따라서 일관성 있는 배포 전략을 수립하는 것이 매우 중요하다고 판단했다.
이 문서에서는 플랫폼 컴포넌트(인프라성 애드온)와 자사 솔루션(비즈니스 애플리케이션)이라는 두 가지 컨셉에 맞춰 배포 도구를 선정했던 과정을 기록했다.
📋 선정 배경
배포 도구를 선정하게 된 배경에는 두 가지 명확한 과제가 있었다.
-
플랫폼 컴포넌트의 복잡한 라이프사이클 관리
cilium,prometheus,cert-manager와 같은 쿠버네티스 생태계의 주요 컴포넌트들은 단순한helm install만으로 설치가 끝나지 않는 경우가 많았다.- 예를 들어, CRD(Custom Resource Definition)를 먼저 생성해야 하거나, 차트 배포 후 CR(Custom Resource)을 추가로 배포해야하는 경우가 발생했다. 또한,
ConfigMap변경 시 관련Deployment를 수동으로 재시작해야 하는 등 helm 차트 배포만으로 끝나지 않고 추가적인 스텝이 필요했다.
-
개발팀을 위한 쉽고 안정적인 애플리케이션 배포
- 솔루션은 개발 단계에서 수시로 배포가 이루어진다.
- 따라서 인프라에 익숙하지 않은 개발자도 자신의 코드가 어떻게 배포되고 운영되는지 쉽게 파악하고, 필요시 직접 배포를 트리거할 수 있는 환경이 필요했다.
- 배포의 일관성을 유지하고, 모든 변경 사항이 추적 가능하며, 장애 발생 시 신속하게 롤백할 수 있는 GitOps 기반의 워크플로우 도입이 시급하다고 보았다.
📊 비교
이러한 배경을 바탕으로 각 요구사항에 맞는 도구들을 비교했다.
플랫폼 컴포넌트 관리
| 도구 | 장점 | 단점 |
|---|---|---|
| Helm | - 쿠버네티스 패키지 관리의 사실상 표준 - 방대한 공개 차트 생태계 | - 복잡한 설치/삭제 로직 처리의 한계 - 여러 차트의 의존성 및 설정 관리 복잡 |
| Helmfile | - helm의 모든 기능 포함- Hook을 통한 사전/사후 작업 자동화- 여러 Helm 릴리스를 코드로 선언 및 관리 | - helm에 대한 추가적인 학습 곡선 존재 |
애플리케이션 배포 워크플로우
| 워크플로우 | 장점 | 단점 |
|---|---|---|
| 수동 배포 (kubectl) | - 간단하고 직관적 - 높은 유연성 | - 휴먼 에러 발생 가능성 - 배포 이력 및 상태 추적의 어려움 - 표준화 및 확장성 부족 |
| GitOps (Argo CD) | - Git을 통한 선언적 상태 관리 (Single Source of Truth) - 배포 자동화 및 일관성 확보 - 명확한 감사 추적 및 롤백 기능 - 개발자 친화적인 Web UI 제공 | - 초기 설정 및 GitOps 워크플로우에 대한 이해 필요 |
✅ 선정 사유
비교 분석을 통해 각 용도에 맞는 최종 도구를 다음과 같이 선정했다.
1. 플랫폼 컴포넌트 배포 - Helmfile
IMPORTANT
Helm 차트만으로는 관리하기 어려운 복잡한 의존성과 라이프사이클 문제를
Helmfile의Hook기능으로 해결할 수 있다고 판단했다.
- 문제 해결:
helm install전 CRD를 먼저 적용하거나,helm uninstall후에도 남아있는 PVC, Namespace 등 잔여 리소스를Hook스크립트로 완벽하게 정리할 수 있었다. 또한,ConfigMap이나Secret변경 후Hook을 통해 관련 Pod를 자동으로 재시작(Rolling Update)하도록 구성하여 운영 부담을 크게 줄일 수 있다고 보았다. - 선언적 관리: 여러 Helm 차트와 그 설정들을 하나의
helmfile.yaml파일에 코드로 명시하므로, 클러스터 컴포넌트 전체를 선언적으로 관리하고 재현성을 보장할 수 있었다.
2. 자사 솔루션 배포 - Argo CD
NOTE
오픈소스 GitOps 도구 중 가장 커뮤니티가 활발하고 기능적으로 성숙하다고 알려진
Argo CD를 선택했다.
- 개발 편의성: 이를 통해 개발자는 더 이상
kubectl명령어에 의존할 필요 없이, 코드 변경을 Git에 푸시하는 것만으로 배포를 수행할 수 있게 되었다.Argo CD의 Web UI는 현재 배포 상태, 리소스 동기화 여부, 애플리케이션 상태 등을 직관적으로 보여주어 인프라 가시성을 크게 향상시켰다. - 운영 안정성: Git을 단일 진실 공급원(Single Source of Truth)으로 삼아 클러스터의 상태를 항상 Git에 명시된 상태와 일치시킨다. 그 결과, 드리프트(Drift) 현상을 방지하고, 문제 발생 시 특정 Git 커밋으로 롤백하여 빠르고 안정적인 장애 대응을 가능하게 만들었다.