3.2 KiB
ApplicationSet decommission
이 절차는 applicationsSync: create-update를 사용하는 generated
Application을 안전하게 해체하기 위한 runbook입니다. List element를 지우는
것만으로 Application이 삭제되지 않는 것은 오류가 아니라 삭제 보호
동작입니다.
중단 조건
다음 중 하나라도 만족하면 진행하지 않습니다.
- 대상 Application 이름, ApplicationSet, 클러스터가 명확하지 않음
- 최신 backup과 복구 테스트가 없음
- PVC/PV와 StorageClass의 reclaim policy를 확인하지 않음
- Application에 예상하지 못한 finalizer가 있음
- live-to-target diff에 대상 밖 리소스가 포함됨
argocd-cmd-params-cm의 전역 ApplicationSet policy가 저장소의create-update의도를 덮어쓰는지 확인하지 않음
Generated Application template에는 resource finalizer를 두지 않습니다.
preserveResourcesOnDeletion: true도 유지합니다. ApplicationSet 전체를
삭제해서 개별 component를 해체하지 않습니다.
공통 준비
- 대상 element의
autoSync를false로 바꾸는 PR을 먼저 병합합니다. - 비활성 기간에 누적된 live-to-target 전체 diff를 저장합니다.
- 대상이 stateful이면 application-level backup과 restore test를 완료합니다.
- List element를 제거하는 별도 PR을 병합합니다.
create-update정책 때문에 기존 Application은 의도적으로 남아야 합니다. - 남은 Application의 소유 관계와 finalizer를 확인합니다.
kubectl -n argocd get application <application-name> \
-o json |
jq '{ownerReferences: .metadata.ownerReferences, finalizers: (.metadata.finalizers // [])}'
예상하지 못한 finalizer를 강제로 제거하지 않습니다.
리소스를 보존하고 관리만 중단
List element를 제거한 뒤 generated Application이 더 이상 재생성되지 않는 것을 확인합니다. Template에 resource finalizer가 없으므로 Application 객체 삭제는 workload를 orphan으로 남깁니다.
kubectl -n argocd delete application <application-name>
삭제 후 workload가 그대로 존재하고 Argo CD에 다시 나타나지 않는지 확인합니다. 보존된 리소스는 더 이상 drift correction을 받지 않으므로, 다른 소유자에게 즉시 인계하거나 별도 정리 계획을 기록합니다.
리소스까지 제거
리소스 삭제는 List element 제거와 같은 PR에 섞지 않습니다.
- 대상 Application은 inventory에 남기고
autoSync: "false"상태를 유지합니다. - 별도 PR에서 component의 desired state를 해체용 빈 구성으로 바꿉니다.
- Argo CD diff에서 삭제 대상이 정확한지 검토합니다.
- Namespace, PVC 등
Prune=confirm,Delete=confirm대상의 backup과 reclaim policy를 다시 확인하고 승인된 prune을 수동 실행합니다. - 리소스가 제거된 뒤 List element 제거 PR을 병합합니다.
- 남은 Application 객체를 삭제합니다.
승인 시각 annotation을 자동화하거나 우회하지 않습니다. kubectl delete applicationset 및 finalizer 강제 제거는 복구 runbook과 별도 승인 없이는
사용하지 않습니다.