DevOps - ArgoCD APP of APPS

25.03.19

 

뭔데?

ArgoCD application을 모아서 관리하는 패턴을 app of apps패턴

app of app패턴으로 구성된 application을 sync하면 여러 argoCD application을 생성

생성된 application은 바라보는 git에 저장된 쿠버네티스 리소스를 배포하게 됨

 

https://blog.stackademic.com/simplifying-multi-application-management-with-argocds-app-of-apps-pattern-9e184a4973b5

 

왜?

Application의 배포는 Git으로 관리되지 않음

GitOps는 Argo CD를 움직이게 하는 핵심 개념으로, Argo CD가 관리하는 쿠버네티스의 배포에 관한 모든 사항이 Git에 기록된다는 것이 핵심

 

그런데 단순히 Application을 생성하고 삭제하게되면, 이에 관련된 기록은 어디에도 남지 않게 됨

GitOps기반의 배포를 했으나

정작 Application의 배포는 GitOps로 관리할 수 없다는 의미

 

이로 인해 발생될 수 있는 문제
• Application의 생성/삭제 등의 기록이 없음
• 누가, 어떤 클러스터에 무슨 Application을 생성했는지 알 수 없음
• Application이 삭제되면, Application 생성시 사용한 설정(Sync Policy, Source, Destination 등)도 함께 삭제됨

물론, 이게 모든 상황에서 문제점이라고는 할 수 없을 것
규모가 적은 쿠버네티스 클러스터를 운영 중이라면 기본적인 것만으로도 충분

 

배포(App)가 많아지고, 배포자가 여러명이되면서, 많은 리소스가 하나의 App에 관리되기 시작하면서 위에 언급한 문제들이 실제로 다가왔고, 이를 개선하기 위한 방법

 

하나의 Application 안에 많은 쿠버네티스 리소스가 있는 것을 볼 수 있고, 상단을 보면 Git commit message로 저자는 알 수 있지만 누가 이 Application을 만들고, Application의 설정을 바꿨을지는 도저히 알 방법이 없음

 

언제?

여러 application을 관리할 때 사용
대표적인 예가 공식문서에서 소개하는 cluster bootstrapping

새롭게 구축한 쿠버네티스 클러스터에

필요한 쿠버네티스 리소스를 빠르게 배포하는 것

을 cluster bootstrapping이라고 부름

https://argo-cd.readthedocs.io/en/latest/operator-manual/cluster-bootstrapping/

 

필요한 쿠버네티스 리소스를 application으로 정의하고

여러 application을 app of apps패턴으로 관리하면

쉽고 빠르게 쿠버네티스 리소스를 새로운 쿠버네티스 배포

 

장점은 동일한 app of apps패턴을 여러 클러스터에 배포하면 동일한 쿠버네티스 인프라가 구축됩니다.

 

단점?

첫 번째, 배포에 관련된 많은 사항이 Argo CD에 의존성이 강함
두 번째, 개발자가 Web UI 대신 Application CRD를 yaml로 직접 작성해야하기 때문에 부담
세 번째, Auto-Sync를 사용하지 않으면 사실상 Sync는 기존과 동일하게 각각 수행해줘야하기 때문에 처음 생성 외에는 다른 점이 없음 (운영환경에서는 Auto-Sync를 enable하는 것이 쉽지 않습니다.)

그럼에도 Cluster Bootstrapping 및 많은 Application 배포를 한 번에 할 수 있다는 점, Application의 생성/삭제까지 Git으로 관리할 수 있다는 점에서 App of apps 패턴은 Argo CD를 사용하는 좋은 방법이라고 생각

https://www.operate-first.cloud/blog/is-app-of-apps-the-right-pattern-for-you

 

---

ArgoCD Application Option

1. Cascading deletion

상위 Application  이 삭제될 때 하위 Application  과 해당 리소스가 모두 삭제되도록 하려면 Application 에 적절한 finalizer (종료자)  를 추가

이 finalizer 로 응용 프로그램을 삭제할 때 ArgoCD application-controller 는 Application Resource 의 계단식 삭제를 수행

 

finalizers:

• - resources-finalizer.argocd.argoproj.io 는 ArgoCD Application  의 종료(Finalization) 과정에서 수행되어야 하는 리소스 정리 작업을 정의
• Kubernetes에서는 리소스를 삭제할 때 해당 리소스와 관련된 종속 리소스들이 제거되는 과정이 있는데, 이때 종속 리소스들의 삭제 작업이 완료된 후에 리소스의 종료 작업이 진행되어야 한다. 이를 위해 finalizer를 사용
• 즉, resources-finalizer.argocd.argoproj.io 는 ArgoCD Application 의 삭제와 관련된 종료 작업을 수행하기 위해 필요 한 finalizer를 나타냄
  
  
  

 

 

2. Sync Phases and Waves

https://redhat-scholars.github.io/argocd-tutorial/argocd-tutorial/04-syncwaves-hooks.html

https://argo-cd.readthedocs.io/en/stable/user-guide/sync-waves/

 

각 Application 마다 argocd.argoproj.io/sync-wave 라는 annotation 설정을 통해 설치 순서를 제어할 수 있는 기능으로, 기본값은 0으로 설정되어 있으나, 이 값을 조절하여 원하는대로 설치 순서를 조절

 

Argo CD가 동기화를 시작하면 다음 우선순위에 따라 리소스를 정렬

• 단계 ( phase)
• 그들이 속한 웨이브(낮은 값부터)
• By kind  (예: 네임스페이스를 먼저 지정한 다음 기타 Kubernetes 리소스, 사용자 지정 리소스 순 )
• By name

It then determines the number of the next wave to apply.
This is the first number where any resource is out-of-sync or unhealthy.
It applies resources in that wave.
It repeats this process until all phases and waves are in-sync and healthy.
Because an application can have resources that are unhealthy in the first wave, it may be that the app can never get to healthy.
Note that there's currently a delay between each sync wave in order give other controllers a chance to react to the spec change that we just applied.
This also prevent Argo CD from assessing resource health too quickly (against the stale object), causing hooks to fire prematurely.
The current delay between each sync wave is 2 seconds and can be configured via environment variable ARGOCD_SYNC_WAVE_DELAY.

그런 다음 적용할 다음 웨이브의 수를 결정

이는 리소스가 동기화되지 않거나 비정상인 첫 번째 숫자

해당 웨이브에 리소스를 적용

모든 위상과 웨이브가 동기화되고 정상 상태가 될 때까지 이 프로세스를 반복

https://kubernetes.io/docs/concepts/architecture/garbage-collection/#foreground-deletion