클러스터 부트스트래핑
클러스터 부트스트래핑 (Cluster Bootstrapping)
이 가이드는 Argo CD를 이미 설치했고, 새 클러스터가 생겼을 때 그 클러스터에 많은 앱을 설치하려는 운영자를 위한 내용이에요. 새 클러스터에 앱들을 반복 배포하는 패턴을 알려준답니다.
출처: 문서
본문
이 문제를 해결하는 특별한 단일 패턴은 없어요. 예를 들어 앱을 만드는 스크립트를 작성하거나 수동으로 만들 수도 있어요.
저희의 권장 사항은 ApplicationSets와, 특히 대부분의 일반적인 시나리오를 처리할 수 있는 클러스터 생성기 (cluster generator)를 살펴보는 것이에요.
Application Sets와 클러스터 라벨 (권장, Application Sets and cluster labels)
선언적 설정 가이드를 따라 클러스터를 만들고 여러 라벨을 할당할 수 있어요.
예시:
apiVersion: v1
data:
[...snip..]
kind: Secret
metadata:
annotations:
managed-by: argocd.argoproj.io
labels:
argocd.argoproj.io/secret-type: cluster
cloud: gcp
department: billing
env: qa
region: eu
type: workload
name: cluster-qa-eu-example
namespace: argocd
그런 다음 클러스터를 Argo CD에 추가하면, 이 라벨을 사용하는 애플리케이션 셋이 각각의 애플리케이션을 배포해요.
apiVersion: argoproj.io/v1alpha1
kind: ApplicationSet
metadata:
name: eu-only-appset
namespace: argocd
spec:
goTemplate: true
goTemplateOptions: ["missingkey=error"]
generators:
- matrix:
generators:
- git:
repoURL: <a git repo>
revision: HEAD
directories:
- path: my-eu-apps/*
- clusters:
selector:
matchLabels:
type: "workload"
region: "eu"
template:
metadata:
name: 'eu-only-{{index .path.segments 1}}-{{.name}}'
spec:
project: default
source:
repoURL: <a git repo>
targetRevision: HEAD
path: '{{.path.path}}'
destination:
server: '{{.server}}'
namespace: 'eu-only-{{index .path.segments 1}}'
syncPolicy:
syncOptions:
- CreateNamespace=true
automated:
prune: true
selfHeal: true
Application Sets를 사용하면 모든 GoTemplate 함수와 Sprig 메서드에도 접근할 수 있어요. 그래서 Helm 템플릿은 필요하지 않아요.
자세한 내용은 템플릿화 (Templating)를 참고하세요.
App Of Apps 패턴 (대안, App Of Apps Pattern)
앱 오브 앱스(app of apps) 패턴을 사용할 수도 있어요.
[!WARNING] App of Apps는 관리자 전용 도구예요
임의의 프로젝트에 Application을 만들 수 있는 능력은 관리자 수준의 기능이에요. 부모 Application의 소스 리포지토리에 push 접근 권한이 있는 사람은 관리자뿐이어야 해요. 관리자는 그 리포지토리로 오는 pull request를 검토해야 하며, 각 Application의
project필드에 특히 주의를 기울여야 해요. Argo CD가 설치된 네임스페이스에 접근할 수 있는 프로젝트는 사실상 관리자 수준의 권한을 갖게 돼요.
선언적으로 다른 앱만으로 구성된 하나의 Argo CD 앱을 지정하세요.
Helm 예시 (Helm Example)
이 예시는 Helm을 사용해 이를 달성하는 방법을 보여줘요. 물론 원한다면 다른 도구를 사용해도 돼요. 대부분의 Helm 함수는 Application Sets에서도 사용할 수 있다는 점을 참고하세요.
이를 위한 Git 리포지토리의 일반적인 레이아웃은 다음과 같아요:
├── Chart.yaml
├── templates
│ ├── guestbook.yaml
│ ├── helm-dependency.yaml
│ ├── helm-guestbook.yaml
│ └── kustomize-guestbook.yaml
└── values.yaml
Chart.yaml은 상용구(boiler-plate)예요.
templates는 각 자식 앱마다 파일 하나씩을 포함하며, 대략 다음과 같아요:
apiVersion: argoproj.io/v1alpha1
kind: Application
metadata:
name: guestbook
namespace: argocd
finalizers:
- resources-finalizer.argocd.argoproj.io
spec:
destination:
namespace: argocd
server: {{ .Values.spec.destination.server }}
project: default
source:
path: guestbook
repoURL: https://github.com/argoproj/argocd-example-apps
targetRevision: HEAD
syncPolicy:
automated:
prune: true
이 예시는 자동화(automated) 동기화 정책을 prune 활성화와 함께 설정하므로, 부모 앱의 매니페스트가 변경되면 자식 앱이 자동으로 생성·동기화·삭제돼요. 변경 적용 시점을 더 세밀하게 제어하려면 자동 동기화를 비활성화할 수도 있어요. finalizer는 삭제 시 자식 앱 리소스가 제대로 정리되도록 보장해요.
자식 앱 리포지토리가 변경되더라도 부모 앱이 해당 리비전을 변경할 때만 앱이 변경되도록, 리비전을 특정 Git commit SHA로 고정하세요. 또는 HEAD나 브랜치 이름으로 설정할 수도 있어요.
클러스터 서버를 덮어쓰고 싶을 가능성이 크므로, 이 값은 템플릿화된 값이에요.
values.yaml은 기본값을 포함해요:
spec:
destination:
server: https://kubernetes.default.svc
다음으로 부모 앱을 생성하고 동기화해야 해요(예: CLI 사용):
argocd app create apps \
--dest-namespace argocd \
--dest-server https://kubernetes.default.svc \
--repo https://github.com/argoproj/argocd-example-apps.git \
--path apps
argocd app sync apps
부모 앱은 in-sync로 나타나지만 자식 앱은 out of sync가 될 거예요:
[!NOTE] 클러스터를 물결(waves)처럼 부트스트래핑하도록 이 동작을 수정하고 싶을 수 있어요. 변경 방법은 애플리케이션의 헬스 평가를 참고하세요.
UI로 동기화할 수도 있는데, 먼저 올바른 라벨로 필터링하세요:
그런 다음 "out of sync" 앱을 선택하고 동기화하세요:
또는 CLI로:
argocd app sync -l app.kubernetes.io/instance=apps
GitHub의 예시를 확인하세요.
종속 삭제 (Cascading deletion)
부모 앱이 삭제될 때 자식 앱과 그 모든 리소스가 삭제되도록 하려면 Application 정의에 적절한 finalizer를 추가하세요.
apiVersion: argoproj.io/v1alpha1
kind: Application
metadata:
name: guestbook
namespace: argocd
finalizers:
- resources-finalizer.argocd.argoproj.io
spec:
...
자식 애플리케이션 삭제 (Deleting child applications)
App of Apps 패턴으로 작업할 때 개별 자식 애플리케이션을 삭제해야 할 수 있어요. 3.2부터 Argo CD는 Applications List에서 삭제하든 부모 애플리케이션의 Resource Tree에서 삭제하든 일관된 삭제 동작을 제공해요.
삭제 옵션과 동작에 대한 자세한 내용은 다음을 포함해 UI에서 애플리케이션 삭제를 참고하세요:
- UI 뷰 간 일관된 삭제
- 관리 리소스를 보존하는 비종속(orphan) 삭제
- 자식 애플리케이션 감지 및 개선된 대화상자 메시지
- 베스트 프랙티스와 예시 시나리오
자식 애플리케이션의 차이 무시 (Ignoring differences in child applications)
자식 앱의 변경이 out-of-sync 상태를 유발하지 않도록 하거나, 디버깅 목적의 수정을 허용하려면 app of apps 패턴은 diff 커스터마이즈와 함께 동작해요. 아래 예시는 syncPolicy와 다른 공통 값의 변경을 무시하는 방법을 보여줘요:
spec:
...
syncPolicy:
...
syncOptions:
- RespectIgnoreDifferences=true
...
ignoreDifferences:
- group: "*"
kind: "Application"
jsonPointers:
# Allow manually disabling auto sync for apps, useful for debugging.
- /spec/syncPolicy/automated
# These are automatically updated on a regular basis. Not ignoring last applied configuration since it's used for computing diffs after normalization.
- /metadata/annotations/argocd.argoproj.io~1refresh
- /operation
...