72 lines
3.2 KiB
Markdown
72 lines
3.2 KiB
Markdown
# 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 <application-name> \
|
|
-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 <application-name>
|
|
```
|
|
|
|
삭제 후 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과 별도 승인 없이는
|
|
사용하지 않습니다.
|