# 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를 해체하지 않습니다. ## 공통 준비 1. 대상 element의 `autoSync`를 `false`로 바꾸는 PR을 먼저 병합합니다. 2. 비활성 기간에 누적된 live-to-target 전체 diff를 저장합니다. 3. 대상이 stateful이면 application-level backup과 restore test를 완료합니다. 4. List element를 제거하는 별도 PR을 병합합니다. `create-update` 정책 때문에 기존 Application은 의도적으로 남아야 합니다. 5. 남은 Application의 소유 관계와 finalizer를 확인합니다. ```bash kubectl -n argocd get application \ -o json | jq '{ownerReferences: .metadata.ownerReferences, finalizers: (.metadata.finalizers // [])}' ``` 예상하지 못한 finalizer를 강제로 제거하지 않습니다. ## 리소스를 보존하고 관리만 중단 List element를 제거한 뒤 generated Application이 더 이상 재생성되지 않는 것을 확인합니다. Template에 resource finalizer가 없으므로 Application 객체 삭제는 workload를 orphan으로 남깁니다. ```bash kubectl -n argocd delete application ``` 삭제 후 workload가 그대로 존재하고 Argo CD에 다시 나타나지 않는지 확인합니다. 보존된 리소스는 더 이상 drift correction을 받지 않으므로, 다른 소유자에게 즉시 인계하거나 별도 정리 계획을 기록합니다. ## 리소스까지 제거 리소스 삭제는 List element 제거와 같은 PR에 섞지 않습니다. 1. 대상 Application은 inventory에 남기고 `autoSync: "false"` 상태를 유지합니다. 2. 별도 PR에서 component의 desired state를 해체용 빈 구성으로 바꿉니다. 3. Argo CD diff에서 삭제 대상이 정확한지 검토합니다. 4. Namespace, PVC 등 `Prune=confirm,Delete=confirm` 대상의 backup과 reclaim policy를 다시 확인하고 승인된 prune을 수동 실행합니다. 5. 리소스가 제거된 뒤 List element 제거 PR을 병합합니다. 6. 남은 Application 객체를 삭제합니다. 승인 시각 annotation을 자동화하거나 우회하지 않습니다. `kubectl delete applicationset` 및 finalizer 강제 제거는 복구 runbook과 별도 승인 없이는 사용하지 않습니다.