[CI/CD] GitOps 환경 구축하기(4) ArgoCD, Kubernetes

우노·2024년 9월 15일
0

Practice & Trouble Shooting

목록 보기
17/20

마지막으로 쿠버네티스 활용에 대한 아쉬움과 함께 ArgoCD를 어떻게 활용했는지를 적어보겠다!

아키텍처

매니페스트 레포를 ArgoCD에 등록하면 Jenkins에서 해당 레포의 애플리케이션 이미지 태그를 바꿀 때마다 상태를 비교하고 CD를 지원할 수 있다.

Kubernetes

구성한 쿠버네티스 클러스터 아키텍처는 다음과 같다.
ingress, argocd, cert-manager, cluster-autoscaler 등은 재배포 시에 업데이트가 필요하지 않아서 매니페스트 레포지토리에는 BE, AI 각각 애플리케이션의 Service, Deployment, HPA 선언 파일을 업로드했고 Deployment의 이미지 태그를 지속적으로 변경했다.

ArgoCD

소개

ArgoCD는 소개부터 Argo CD - Declarative GitOps CD for Kubernetes 라고 되어있을만큼 대표적인 pull type의 GitOps CD 오픈소스 툴이다. 그리고 kustomize applications, helm charts, jsonnet files, Plain directory of YAML/json manifests 등으로 매니페스트 관리 방식을 등록하면 선언된 상태와 현재 상태를 비교하여 CD를 지원한다.

나는 프로젝트에서 매니페스트 YAML을 담은 GitHub 레포지토리 PAPERPLE-CD를 등록했고 ArgoCD는 해당 레포에 있는 YAML 파일을 전부 긁어서 상태 비교에 활용한다.

ArgoCD는 argocd라는 네임스페이스에 설치되지만 RBAC(Role-Based Access Control) 설정과 kube-apiserver를 통해 다른 네임스페이스의 리소스를 확인할 수 있고 이를 상태 비교에 활용한다.

설치 및 활용

ArgoCD는 아래 명령어를 통해서 클러스터에 설치할 수 있다.

kubectl create namespace argocd
kubectl apply -n argocd -f https://raw.githubusercontent.com/argoproj/argo-cd/stable/manifests/install.yaml

CLI를 통한 설정과 UI를 통한 설정을 지원하는데 나는 UI를 사용해서 설정했다. 위의 yaml로 설치한 리소스 중에서 service/argocd-server를 ClusterIP에서 LoadBalancer로 수정해서 생성된 EXTERNAL-IP를 통해 UI에 접근했다. EKS 환경에서는 도메인으로 나와서 해당 도메인을 새로 등록한 도메인의 CNAME 레코드에 등록하여 간편하게 활용했다.

위와 같이 지속적으로 매니페스트 레포지토리에 선언된 상태와 현재 상태를 비교하고 Sync만 누르면 선언된 상태로 만들어준다. 그리고 배포를 기록으로 관리하여 쉽게 롤백이 가능하다.

AutoSync 🤔

ArgoCD는 선언된 상태와 현재 상태를 자동으로 동기화하는 AutoSync를 지원하고 AutoSync를 활성화하면 기타 설정을 지원한다. 처음에는 CI/CD의 완전 자동화를 위해 당연히 AutoSync와 기타 설정 모두를 활성화했다.

하지만.. 나는 기존 리소스의 효율적인 활용을 위해 HPA를 설정하고 트래픽 대비를 위해 cluster-autoscaler를 설정했다. AutoSync를 켜두고 HPA를 설정하면 CPU 사용량이 아무리 높아지고 HPA가 파드를 새로 생성하려고 해도 선언된 레플리카 수를 ArgoCD가 지속적으로 맞추기 때문에 파드가 생성되지 않는다.
[K8s] HPA 설정 트러블슈팅하기 / #1 ArgoCD Auto-Sync 참고
AutoSync 켜둔 걸 까먹고 삽질을 했었고.. 그 이후로는 AutoSync를 끄고 필요할 때 Sync 버튼을 눌러주었다. 하지만 CD에서 자주 빠르게 배포가 필요하다면 딸깍 한 번하고 상태를 지켜보는 이 과정이 생각보다 불편하다. ArgoCD AutoSync와 HPA 둘 사이에서 타협을 해야할 것 같다.

마무리

개선할 점; ArgoCD

애플리케이션에는 ingress를 설정하고 nginx-ingress-controller를 두어 https 설정을 했는데 ArgoCD에는 하지 못해서 UI로 argocd-server에 접근하려면 https 설정도 추가해야할 것 같다.

개선할 점; Kubernetes

쿠버네티스에 개선할 점.. 너무도 많다.

  • 🔥 모니터링
    efk 스택을 구축하여 fluentd를 노드마다 배치해두고 왜 파드의 애플리케이션 로그는 안 뜨지..? 하는 바보같은 생각을 했었다. 다음에 클러스터를 구성하면 사이드카 패턴으로 멀티 컨테이너 파드를 구성하여 로깅 컨테이너부터 파드에 넣을 것이다. 이걸 못해서 개발자가 로그를 요구하는데 직접 kubectl logs ...로 찍어주었다....
  • 🔥 secret 관리
    운영팀이 혼자여서.. 애플리케이션의 ENV 값 관리 트러블슈팅을 할 시간도 없이 그냥 이미지에 넣어서 프라이빗 레포지토리에 업로드했다. ENV 값을 secret으로 관리해서 Vault 등의 서비스와도 연동하고 싶다.
  • 🔥 Zero Downtime
    쿠버네티스의 RollingUpdate 설정을 해두고 무중단배포다~.. 했는데 새로운 컨테이너가 실행되었다고 기존 컨테이너가 내려갔는데 새로운 컨테이너에서 애플리케이션이 실행되기까지의 시간동안 도메인으로 접근해보니 502 페이지를 확인할 수 있었다. 이를 해결해서 애플리케이션 레벨에서 진짜 무중단배포 아키텍처를 구현하고 싶다.
  • 🔥 리소스 관리
    hpa의 동작은 빠른데 clusterautoscaling은 느려서 정작 hpa가 동작해도 파드가 Pending인 경우도 발생하고 파드가 늘어나는 건 순식간인데 줄어드는 시간이 오래 걸리는 점도 확인할 수 있었다. 가진 리소스가 t3.medium 인스턴스 두개로 CPU 4000m, Memory 8192Mi 인 점은 확인했는데.. 해당 리소스를 애플리케이션에 어떻게 배치할지 SLO를 참고해서 고민해보고 싶다.
  • 🔥 직접 kubeadm 설치하기
    EKS를 사용해서 컨트롤플레인을 제공받고 config를 등록하여 api로 클러스터에 요청을 보냈다. CKA를 준비하고 쿠버네티스를 공부하는만큼 직접 클러스터를 구성해보고 싶다!

프로젝트 끝!

프로젝트가 끝나서 시원하기도 하고 AWS 서버비 지원이 끝나서 아주 아쉽지만 짧은 기간 동안 비싼 EKS를 알차게 활용한 것 같다. 짧은 기간동안 직접 사용하면서 CI/CD와 쿠버네티스를 익혔다면 앞으로는 딥다이브를 해보고 싶다! CKA도 화이팅..

부족하거나 잘못된 부분이 있다면 편하게 조언, 지적 부탁드립니다. 🙇🏻‍♀️

profile
기록하는 감자

0개의 댓글