ApplicationSet, Kustomize로 다중 환경/다중 클러스터 GitOps 운영하기 - ArgoCD 도입기 1편

들어가며

• 서비스 : 쿠버네티스의 Service 리소스가 아닌 마이크로서비스에 해당하는 워크로드를 지칭하는 의미로 사용하였습니다.

• Application : 일반적인 워크로드가 아닌 ArgoCD의 Application CRD를 지칭하는 의미로 사용하였습니다.

2023년, 점점 어려워지는 클러스터 관리

1. 아무도 알 수 없는 서비스 배포 이력
왜? - 로컬 터미널 환경에서 서비스 레포리토리 내에 포함되어 있는 리소스 정의 폴더로 이동한 뒤 Helm이나 kubectl로 리소스를 배포하다보니, 서비스 소스코드의 변경 이력은 Git에 남더라도 배포 이력은 추적되지 못했습니다. (지금 배포되어 있는 버전이 최신일까..? 아니면 지난주꺼..?)

2. 환경 별 변경 사항 전파 시 잦은 실수 발생
왜? - 서비스를 구성하는 리소스 폴더를 배포 환경 개수(운영 환경, 개발 환경.. 최소 2개)만큼 복사하여 사용하다 보니 개발 환경 yaml에 작성한 수정 사항을 운영 환경 yaml에도 손수 적용해줬어야 했으며 이 과정에서 모든 변경 사항이 반영되지 않는 경우가 종종 발생했습니다. (배포 새로 됐는데 왜 수정이 안됐지?)

3. 각 클러스터 별 운영 서비스 파악의 어려움
왜? - 수십 개의 서비스 소스코드 레포지토리에 리소스 폴더가 분산되어 있어서 서비스 담당자는 편하지만 인프라 담당자에게는 죽을 맛입니다. 다행히 Rancher 웹 대쉬보드를 활용하여 운영 중인 워크로드 및 리소스 파악이 가능했지만, 어떤 서비스에 의해 각 리소스가 정의된 것인지는 찾기가 힘든 구조였습니다. (이 Deployment는 누가 만든 걸까요?)

4. 리소스 yaml 파일에 무분별하게 주입되는 크레덴셜
왜? - 환경 별로 매번 Secret 리소스를 생성하는 것도 번거롭고.. 값 수정이나 학인은 더 번거롭고.. 에잇! 난 몰라!! 일단 yaml에 묻고 더블로 가..!
부록) 크레덴셜 관리 종합선물세트 - 절망편
1. (바쁘다~) 소스코드에 크레덴셜 박고 깃에 올려버리기
2. (소스코드에 하드코딩은 너무 양심 없지..! Private 레포는 안전하니까!!) yaml 파일에 환경 변수로 박고 깃에 올려버리기
3. (깃에 올리는건 진짜 말도 안되는거지!!) 컨테이너 빌드할 때 환경 변수로 주입해서 이미지 말아버리기
4. (XX님~ 이거 실행하니까 크레덴셜 필요한데요?) .gitignore 추가돼 있으니까 슬랙 DM으로 보내드린거 저장하시면 돼요!

ArgoCD, 왜 써야하죠?

GitOps의 등장

ArgoCD가 희망

써보면서 좋았던 기능들

• 맥락이 있는 가시성 : ArgoCD에 의해 관리되는 Application들은 GUI를 통해서 배포된 각각의 리소스의 연결관계(특정 Pod는 어떤 Deployment에 의해 생성된 것인지)와 리소스 별 Health 상태를 한눈에 보여줌으로써 인프라에 대한 폭 넓은 가시성을 제공해 줍니다. 이러한 GUI는 단순히 클러스터에 띄워져 있는 리소스를 나열만 하는 Rancher나 Lens의 GUI에 비해 훨씬 직관적으로 느껴졌습니다.

• 노드 별 리소스 요약 기능 : 여러 보기 옵션 중, 아래 스크린샷과 같이 격자 모양으로된 아이콘을 클릭하면 실제 노드의 자원을 소모하는 Pod들이 어떤 노드들에 할당되어 있는지 확인하기에 용이합니다. 해당 뷰는 이중 배포가 구성되어 있는 서비스가 한 쪽 노드에 치우쳐 할당되지 않고, 의도한대로 두 개 이상의 노드에 골고루 배분되어 있는지 빠르게 확인하는데 편리했습니다.

• 빠른 리소스 상태 체크 : GUI를 통해서 Application 내의 리소스를 클릭하면 최신 yaml 상태값, 제한적이지만 로그 등과 같은 세부 정보를 바로 체크할 수 있어서 장애 발생 시에 어디서부터 손봐야 할지 빠르게 감을 잡을 수 있었습니다.

• 타임머신 기능 : History AND Rollback 기능을 이용하면 가장 마지막 커밋 대신 특정 시점의 커밋으로 클러스터에 재배포하는 것이 가능합니다. 덕분에 신규 버전 배포 과정에서 장애 발생 시 일단 빠르게 전 버전으로 되돌려 임시 복구(매우 중요)하고, 오류가 수정된 커밋을 푸쉬 후 다시 Sync하면 장애에도 손쉽게 대응이 가능합니다.

수 많은 Yaml 파일들, 어떻게 정리하면 좋을까?

1) 단일 환경, 단일 서비스 - 리소스 정리 방식

서비스 소스코드와 인프라 설정 : 같은 레포지토리 vs 분리된 레포지토리

ArgoCD CLI로 단일 서비스 등록하기

.
└── first-application
    └── base
        ├── deployment.yaml
        ├── ingress.yaml
        └── service.yaml

argocd app create guestbook \
--repo https://github.com/argoproj/argocd-example-apps.git \
--path first-application/base \
--dest-server https://kubernetes.default.svc \
--dest-namespace first-namespace

Application CRD로 ArgoCD CLI 탈피하기

apiVersion: argoproj.io/v1alpha1
kind: Application
metadata:
  name: first-application
  namespace: argocd
spec:
  project: default
  source:
    repoURL: https://github.com/argoproj/argocd-example-apps.git
    targetRevision: HEAD
    path: first-application/base
  destination:
    server: https://kubernetes.default.svc
    namespace: first-namespace
  syncPolicy:
      automated:
          prune: true
          selfHeal: true
      syncOptions:
          - CreateNamespace=true

Application CRD와 서비스 리소스는 어떻게 모을까?

.
├── applications
│   └── first-application.yaml
└── first-application
    └── base
        ├── deployment.yaml
        ├── ingress.yaml
        └── service.yaml

.
└── first-application
    ├── application.yaml
    └── base
        ├── deployment.yaml
        ├── ingress.yaml
        └── service.yaml

2) 다중 배포 환경 - Kustomize, ApplicationSet으로 관리하기

.
└── first-application
    ├── dev
    │   ├── deployment.yaml
    │   ├── ingress.yaml
    │   └── service.yaml
    ├── dev-first-application.yaml
    ├── prod
    │   ├── deployment.yaml
    │   ├── ingress.yaml
    │   └── service.yaml
    └── prod-first-application.yaml

브랜치를 활용하면 어떨까요?

Kustomize의 도입

.
└── first-application
    ├── dev
    │   ├── deployment.yaml
    │   ├── ingress.yaml
    │   └── service.yaml
    ├── dev-first-application.yaml
    ├── prod
    │   ├── deployment.yaml
    │   ├── ingress.yaml
    │   └── service.yaml
    └── prod-first-application.yaml

.
└── first-application
    ├── base
    │   ├── deployment.yaml
    │   ├── ingress.yaml
    │   ├── kustomization.yaml
    │   └── service.yaml
    ├── overlays
    │   ├── dev
    │   │   ├── ingress.yaml
    │   │   └── kustomization.yaml
    │   └── prod
    │       ├── ingress.yaml
    │       └── kustomization.yaml
    ├── dev-first-application.yaml
    └── prod-first-application.yaml

---
apiVersion: kustomize.config.k8s.io/v1beta1
kind: Kustomization
resources:
- deployment.yaml
- ingress.yaml
- service.yaml

---
apiVersion: kustomize.config.k8s.io/v1beta1
kind: Kustomization
namePrefix: dev-
bases:
    - ../../base
patchesStrategicMerge:
    - ingress.yaml

apiVersion: argoproj.io/v1alpha1
kind: Application
metadata:
  name: first-application
  namespace: argocd
spec:
  project: default
  source:
    repoURL: https://github.com/argoproj/argocd-example-apps.git
    targetRevision: HEAD
    path: first-application/overlays/dev
  destination:
    server: https://kubernetes.default.svc
    namespace: dev-first-namespace
  syncPolicy:
      automated:
          prune: false
          selfHeal: true
      syncOptions:
          - CreateNamespace=true

• kustomize CLI를 로컬환경에 설치하면 kustomize build overlays/dev 명령어를 통해 yaml 렌더링을 미리볼 수 있습니다. (의도한대로 Override되었는지 확인하는 용도로 활용합니다)

• 종종 특정 컨테이너의 이미지 이름 혹은 태그만 변경하고 싶은 경우가 있습니다. 이럴 때는 아래의 예시처럼 kustomization.yaml의 images 필드를 이용하여 nginx 라는 이름을 갖는 컨테이너를 my.image.registry/nginx:1.4.0 으로 손쉽게 변경할 수 있습니다.

apiVersion: apps/v1
kind: Deployment
metadata:
  name: my-nginx
spec:
  selector:
    matchLabels:
      run: my-nginx
  replicas: 2
  template:
    metadata:
      labels:
        run: my-nginx
    spec:
      containers:
      - name: my-nginx
        image: nginx
        ports:
        - containerPort: 80

kind: Application
resources:
- deployment.yaml
images:
- name: nginx
  newName: my.image.registry/nginx
  newTag: 1.4.0

$ kubectl kustomize ./
apiVersion: apps/v1
kind: Deployment
metadata:
  name: my-nginx
spec:
  replicas: 2
  selector:
    matchLabels:
      run: my-nginx
  template:
    metadata:
      labels:
        run: my-nginx
    spec:
      containers:
      - name: my-nginx
        image: my.image.registry/nginx:1.4.0
        ports:
        - containerPort: 80

ApplicationSet으로 배포 환경 템플릿팅하기

---
apiVersion: argoproj.io/v1alpha1
kind: ApplicationSet
metadata:
    name: first-application
spec:
    generators:
        - list:
              elements:
                  - env: prod
                  - env: dev
    template:
        metadata:
            name: '{{env}}-first-application'
        spec:
            project: default
            source:
                repoURL: https://github.com/argoproj/argocd-example-apps.git
                targetRevision: HEAD
                path: first-application/overlays/{{env}}
            destination:
                server: https://kubernetes.default.svc
                namespace: '{{env}}-first-application'
            syncPolicy:
                automated:
                    prune: true
                    selfHeal: true
                syncOptions:
                    - CreateNamespace=true

.
└── first-application
    ├── base
    │   ├── deployment.yaml
    │   ├── ingress.yaml
    │   ├── kustomization.yaml
    │   └── service.yaml
    ├── overlays
    │   ├── dev
    │   │   ├── ingress.yaml
    │   │   └── kustomization.yaml
    │   └── prod
    │       ├── ingress.yaml
    │       └── kustomization.yaml
    ├── dev-first-application.yaml
    └── prod-first-application.yaml

.
└── first-application
    ├── base
    │   ├── deployment.yaml
    │   ├── ingress.yaml
    │   ├── kustomization.yaml
    │   └── service.yaml
    ├── overlays
    │   ├── dev
    │   │   ├── ingress.yaml
    │   │   └── kustomization.yaml
    │   └── prod
    │       ├── ingress.yaml
    │       └── kustomization.yaml
    └── first-applicationset.yaml

3) 다중 클러스터 - 중앙 레포지토리로 모두 모으기

다중 ArgoCD vs 중앙 ArgoCD

1. one to one (1 ArgoCD - 1 Cluster) : 모든 쿠버네티스 클러스터마다 개별적으로 ArgoCD를 설치하는 방법입니다. 이는 ArgoCD가 설치되어 있는 로컬 클러스터만 관리하기 때문에 타 클러스터에 장애가 생겨도 확산되는 것을 방지할 수 있습니다. 그러나 여러 개의 ArgoCD를 설치하고 유지보수하기 위한 관리 비용이 증가한다는 단점이 있습니다.

2. one to many (1 ArgoCD - Many Clusters) : 중앙화된 하나의 ArgoCD로 여러 개의 클러스터 배포를 관장하는 방법입니다. ArgoCD가 설치되어 있는 로컬 클러스터에 장애가 발생했을 때 전체 워크로드의 관리가 깨질 수 있다는 리스크가 있지만 관리 비용이 적다는 장점이 있습니다.

다중 클러스터 리소스 정리하기

.
└── clusters
    ├── eks-kafka
    │   └── first-application
    │       ├── base
    │       │   ├── deployment.yaml
    │       │   ├── ingress.yaml
    │       │   ├── kustomization.yaml
    │       │   └── service.yaml
    │       ├── overlays
    │       │   ├── dev
    │       │   │   ├── ingress.yaml
    │       │   │   └── kustomization.yaml
    │       │   └── prod
    │       │       ├── ingress.yaml
    │       │       └── kustomization.yaml
    │       └── first-applicationset.yaml
    └── rke2-on-premise
        └── second-application
            ├── base
            │   ├── deployment.yaml
            │   ├── ingress.yaml
            │   ├── kustomization.yaml
            │   └── service.yaml
            ├── overlays
            │   ├── dev
            │   │   ├── ingress.yaml
            │   │   └── kustomization.yaml
            │   └── prod
            │       ├── ingress.yaml
            │       └── kustomization.yaml
            └── second-apllicationset.yaml

ApplicationSet으로 배포 클러스터도 템플릿팅하기

---
apiVersion: argoproj.io/v1alpha1
kind: ApplicationSet
metadata:
    name: first-application
spec:
    generators:
        - list:
              elements:
                  - env: prod
                  - env: dev
    template:
        metadata:
            name: '{{env}}-first-application'
        spec:
            project: default
            source:
                repoURL: https://github.com/argoproj/argocd-example-apps.git
                targetRevision: HEAD
                path: first-application/overlays/{{env}}
            destination:
                server: https://kubernetes.default.svc
                namespace: '{{env}}-first-application'
            syncPolicy:
                automated:
                    prune: true
                    selfHeal: true
                syncOptions:
                    - CreateNamespace=true

---
apiVersion: argoproj.io/v1alpha1
kind: ApplicationSet
metadata:
    name: first-application
spec:
    generators:
        - list:
              elements:
                  - env: dev
                    url: https://<dev-cluster-url>
                  - env: prod
                    url: https://<prod-cluster-url>
    template:
        metadata:
            name: '{{env}}-first-application'
        spec:
            project: default
            source:
                repoURL: https://github.com/argoproj/argocd-example-apps.git
                targetRevision: HEAD
                path: clusters/eks-kafka/first-application/overlays/{{env}}
                directory:
                    recurse: true
            destination:
                server: '{{url}}'
                namespace: '{{env}}-first-application'
            syncPolicy:
                automated:
                    prune: true
                    selfHeal: true
                syncOptions:
                    - CreateNamespace=true

신규 인프라 변경 사항은 어떻게 전파할까?

1. 우선 dev 환경 폴더 내에 Extra Setting 을 먼저 적용하여 배포합니다.

2. dev 환경 내에서 정상 반영된 것을 확인하면 prod 환경 폴더 내에 중복으로 Extra Setting 을 선언하여 배포합니다.

3. 두 환경 내에서 모두 정상 반영된 것이 확인된 후에 dev 와 prod 에서 Extra Setting 을 걷어내고 base 폴더 내로 이전합니다.

마치며

Reference

1. 데브옵스의 확장 모델 – 깃옵스(GitOps) 이해하기, 삼성SDS (https://www.samsungsds.com/kr/insights/gitops.html)

2. Best Practices, ArgoCD (https://argo-cd.readthedocs.io/en/stable/user-guide/best_practices/#separating-config-vs-source-code-repositories)

3. Stop Using Branches for Deploying to Different GitOps Environments, codefresh (https://codefresh.io/blog/stop-using-branches-deploying-different-gitops-environments/)

4. Kustomize (https://kustomize.io/)

5. Kustomize로 K8S 리소스 관리하기, pullee (https://velog.io/@pullee/Kustomize로-K8S-리소스-관리하기)

6. Generators, ArgoCD (https://argocd-applicationset.readthedocs.io/en/stable/Generators/)

7. ArgoCD Cluster, ArgoCD (https://argo-cd.readthedocs.io/en/stable/user-guide/commands/argocd_cluster/)

8. How to Model Your GitOps Environments and Promote Releases between Them, CodeFresh (https://codefresh.io/blog/how-to-model-your-gitops-environments-and-promote-releases-between-them/)