이전 포스팅에서 GitOps를 위한 Argo CD 소개와 설치, 그리고 App of Apps 패턴 사용법을 살펴보았습니다. 이 포스팅에서는 git 리포지토리를 좀 더 활용해보겠습니다. 아래에 보이는 CRD 처럼 Argo CD App에 헬름 차트 리포지토리를 직접 명시할 경우가 있습니다. 이 때 Argo CD는 사용자 대신 원격 저장소로부터 차트를 캐싱하여 대상 쿠버네티스에 배포하게 됩니다. 이럴 경우, 관리가 단순해지는 장점이 있는 대신 두 가지 단점이 있습니다: `1. 차트 템플릿을 커스텀 할 수 없습니다`, `2. 원격 저장소가 다운될 경우에 배포를 갱신할 수 없습니다`. 이 단점을 해결하기 위해 원격 차트도 함께를 관리하는 방법이 있습니다. 이 포스팅에서는 원격 차트를 커스텀 차트와 GitOps로 관리하하는 법을 소개합니다.
예시 CRD 입니다:
# metrics-server.yaml
apiVersion: argoproj.io/v1alpha1
kind: Application
metadata:
name: metrics-server
spec:
project: system
source:
repoURL: https://kubernetes-sigs.github.io/metrics-server # 차트 주소
targetRevision: "3.12.2" # 차트 버전
chart: metrics-server # 차트 이름
helm:
valuesObject:
args:
- --metric-resolution=30s
destination:
server: https://kubernetes.default.svc
namespace: kube-system
syncPolicy:
automated: {}이 포스팅은 k8s, helm, argocd 사용법을 알고 계시다면 읽기 편합니다. 이전 포스팅과 이어진 부분이 많으니 참고해주세요!
✨ 소개: 그래서 커스텀 차트는 왜 사용하나요?
이 블로그에서 정의한 커스텀 차트 배포는 원격 차트를 내 git에 내려받고 그 차트를 배포하는 GitOps 방식입니다. 원격 헬름 차트 배포와 비교하여서 `원격 차트를 가져오는 과정`과 `차트 템플릿을 수정하는 과정`이 추가됩니다.
위 그림에 소개된 프로세스 처럼, 커스텀 차트를 사용하는 이유는 2가지가 있습니다.
- 원격 차트를 수정하여 사용할 필요가 있습니다.
- 필요에 따라 차트 템플릿을 고쳐서 사용해야 합니다.
- 원격 차트에 Pull Request를 보내어 승인을 기다리기에는 시간이 필요합니다.
(물론 오픈소스 기여는 무조건 좋습니다!)
- 원격 차트 리포지토리가 다운되는 경우를 대비해야 합니다.
- 헬름 차트 허브인 artifacthub는 npm, pip 같은 중앙 집중형 저장소가 아닙니다. 개인/기관인 차트 관리자가 직접 차트를 호스팅하고 있고, artifacthub는 이를 중계해주는 역할을 하고 있습니다.
- 따라서 원격 차트의 주소가 바뀌거나, 점검으로 접근할 수 없을 때가 있습니다.
- 이 경우 이미 배포된 템플릿은 지장이 없지만, 신규 시나리오의 배포가 필요할 때 문제가 됩니다.
위 경우를 해결하기 위해, 원격 차트를 바로 사용하는 것이 아닌 git에 보존된 커스텀 차트를 사용하는 방법을 소개합니다.
🔧 GitOps 리포지토리에 차트 추가하기
이전 포스팅과 마찬가지로 k8s 메트릭 서버를 예시로 하겠습니다. GitOps 소스코드는 이 링크를 참조해 주세요. 먼저 리포지토리에 `helm` 폴더를 하나 생성합니다.
mkdir helm
그리고 헬름 차트를 내려받기위해 리포지토리를 등록합니다. 그리고 설치할 차트 버전을 확인합니다.
helm repo add metrics-server https://kubernetes-sigs.github.io/metrics-server
helm search repo metrics-server/metrics-server -l
현재 기준으로 최신 차트버전인 `3.12.2`을 내려(`pull`)받겠습니다. 그 뒤에 차트 버전 관리를 위해 이름을 변경해줍니다.
다음 명령어를 GitOps 리포지토리의 최상위 경로에서 입력합니다.
cd helm
helm pull metrics-server/metrics-server --untar --version 3.12.2
mv metrics-server metrics-server-3.12.2
ls
# 결과: metrics-server-3.12.2
결과로 metrics-server-3.12.2 폴더가 남습니다. 차트 내부구조는 다음과 같습니다.
.
└── metrics-server-3.12.2
├── CHANGELOG.md
├── Chart.yaml
├── README.md
├── RELEASE.md
├── ci
│ └── ci-values.yaml
├── templates
│ ├── NOTES.txt
│ ├── _helpers.tpl
│ ├── apiservice.yaml
│ ├── clusterrole-aggregated-reader.yaml
│ ├── clusterrole-nanny.yaml
│ ├── clusterrole.yaml
│ ├── clusterrolebinding-auth-delegator.yaml
│ ├── clusterrolebinding-nanny.yaml
│ ├── clusterrolebinding.yaml
│ ├── configmaps-nanny.yaml
│ ├── deployment.yaml
│ ├── pdb.yaml
│ ├── psp.yaml
│ ├── role-nanny.yaml
│ ├── rolebinding-nanny.yaml
│ ├── rolebinding.yaml
│ ├── service.yaml
│ ├── serviceaccount.yaml
│ └── servicemonitor.yaml
└── values.yaml
4 directories, 25 files
이 구조까지 확인했다면 원격 차트를 잘 내려받은 것 입니다. 이제 차트의 원격 리포지토리에 문제가 생겨도 동일한 차트 배포를 할 수 있습니다.
차트 커스텀이 필요하다면, `values.yaml` 파일과 `templates` 폴더를 커스텀 하시면 됩니다. 여기서 차트를 커스텀하셨다면, 차트 폴터에 커스텀을 했다는 표시를 해주시는 걸 추천드립니다. 예를 들면 `metrics-server-3.12.2-custom` 입니다. 자, 이제 차트를 확보하였으니 이 차트를 이용한 배포를 해보겠습니다.
🧑💻 App of Apps 패턴으로 커스텀 차트 배포하기
이제 `apps.yaml` 파일을 만들어 App of Apps 패턴의 배포를 해보겠습니다. 다음 YAML 파일을 직접 배포하겠습니다.
# clusters/jyje-step2/apps.yaml
---
apiVersion: argoproj.io/v1alpha1
kind: Application
metadata:
name: apps
namespace: argocd # Argo CD가 설치된 네임스페이스
spec:
project: default # 기본 프로젝트
source:
repoURL: https://github.com/jyje/pilot-gitops-argocd.git
targetRevision: main
path: clusters/jyje-step2/apps
directory:
recurse: true
destination:
server: https://kubernetes.default.svc
namespace: argocd # Argo CD가 설치된 네임스페이스
syncPolicy:
automated: {}
---
# 프로젝트를 별도로 선언할 수 있습니다. 추가 프로젝트를 사용하지 않을 경우 생략합니다.
apiVersion: argoproj.io/v1alpha1
kind: AppProject
metadata:
name: system # 새로 만든 프로젝트 입니다
spec:
clusterResourceWhitelist:
- group: '*'
kind: '*'
destinations:
- namespace: '*'
server: 'https://kubernetes.default.svc'
sourceRepos:
- '*'
이전 포스팅과 비교하여 달라진 부분은 경로입니다. `jyje` 대신, `jyje-step2`인 다른 폴더를 바라보고 있습니다. 위의 `apps.yaml`을 직접 배포하면 `jyje-step2` 폴더에 있는 리소스가 배포됩니다. 이 때 `jyje-step2` 폴더에도 Argo CD Application에 해당하는 YAML 파일을 넣어둔다면, App of Apps 패턴에 의해 앱들이 간접적으로 배포됩니다. 이 내용은 이전 포스팅에 자세히 설명하였습니다. 참고 부탁드려요.
그럼 커스텀 차트는 어떻게 했을까요? Argo CD Application을 수정하였습니다. `clusters/jyje-step2/apps` 폴더에 다음 YAML을 저장해주세요.
폴더명 및 파일명, 차트는 여러분의 환경에 맞게 정하시고 git에 commit하시면 됩니다.
---
apiVersion: argoproj.io/v1alpha1
kind: Application
metadata:
name: metrics-server
spec:
project: system
source:
repoURL: https://github.com/jyje/pilot-gitops-argocd.git # GitOps 리포지토리
targetRevision: main # git 브랜치
path: helm/metrics-server-3.12.2 # 커스텀 차트 경로
helm:
# 우선순위 'parameters > valuesObject > values > valueFiles > helm repository values.yaml'
# https://argo-cd.readthedocs.io/en/stable/user-guide/helm/#helm-value-precedence
valueFiles:
- values.yaml
valuesObject: # 우선 순위에 따라 이 값으로 덮어씌워집니다.
args:
- --metric-resolution=30s
destination:
server: https://kubernetes.default.svc
namespace: kube-system
syncPolicy:
automated: {}
위 YAML에는 헬름 원격 리포지토리의 정보가 없습니다. 따라서 헬름 차트 리포지토리와 상관없이 배포할 수 있습니다.
그럼 실제 배포 결과를 살펴볼까요? 예제는 이 링크를 참고해주세요. 다음 명령어로 Argo CD 앱 `apps`를 배포합니다.
kubectl config current-context
# 위 결과로 올바른 클러스터 컨텍스트를 선택했는지 꼭 확인합니다.
kubectl apply -n argocd -f https://raw.githubusercontent.com/jyje/pilot-gitops-argocd/refs/heads/main/clusters/jyje-step2/apps.yaml
Argo CD 웹 UI에서 확인한 결과를 다음과 같습니다. App of Apps 패턴을 사용하기 전과 후를 비교하겠습니다.
배포 결과는 동일합니다. 차이점은 원격 차트를 참조하는 지 아니면 GitOps를 위해 만든 커스텀 차트를 참조하는 지의 차이입니다.
이 블로그를 통해 커스텀 차트 방식으로 앱을 배포하는 방법을 소개하였습니다. 여기서 다루지 못한 점이있습니다. 커스텀 차트를 만드는 대신, 원격 차트 리포지토리와 동일한 캐시 차트 리포지토리를 만드는 대안도 있습니다. 그럼 App of Apps를 선언하는 '앱' 파트와 모든 차트를 보관하는 '차트' 파트로 GitOps를 세분화 할 수 있습니다. 이 경우, 각 파트를 구분하여 혼선을 줄일 수 있다는 장점이 있지만 관리포인트가 많아지는 단점이 있습니다. 만약 차트를 관리하는 부서와 차트를 사용하는 부서가 다르다면 이 방식도 좋을 것 같습니다.
여러분의 GitOps에 도움이 되길 바라며 이만 마치겠습니다. 감사합니다!
'DevOps' 카테고리의 다른 글
| 🧑💻 Amazon EKS Hybrid Nodes: EKS 하이브리드 노드를 리뷰합니다 (0) | 2024.12.21 |
|---|---|
| 🍩 호머(Homer)#2: 호머로 만든 쿠버네티스 네이티브 대시보드를 소개합니다 (0) | 2024.11.26 |
| 🐙 GitOps#1: Argo CD와 함께 GitOps 시작하기 (1) | 2024.11.21 |
| 📝 k8s+STDIN: 쿠버네티스에서 YAML 파일 없이 리소스 생성하기 (0) | 2024.11.12 |
| 🐶 k9s: 쿠버네티스 클러스터 관리를 위한 커맨드라인 UI 도구를 소개합니다 (1) | 2024.11.10 |
어제보다 오늘 더 공부 잘하는 코딩냥이. 어제보다 오늘 더 일 잘하는 코딩냥이.
포스팅이 좋았다면, 오류를 발견했다면, 더 좋은 아이디어가 있다면 댓글 부탁드립니다!
