GitOps에서 선언을 되돌리는 일과 이미 삭제된 상태·데이터를 복원하는 일은 서로 다른 경로입니다. 먼저 렌더된 리소스의 identity와 추적 집합을 확정하고, 그다음 저장소 보존 정책과 실제 복원 가능한 백업을 확인한 뒤에야 삭제나 복구의 성공 조건을 말할 수 있습니다.
YAML 복귀와 삭제 볼륨 데이터 복원의 불일치
Git에서 PVC 선언을 제거하고 prune으로 실제 PVC·백엔드 볼륨까지 삭제되었다면 Git revert는 예전 선언만 되살립니다. 새 PVC가 빈 볼륨을 받는 것은 데이터 복원이 아닙니다. 리소스 선언 복귀와 상태·데이터 복원을 구분해야 합니다.
prune은 Application이 추적하는 리소스 집합을 렌더 결과와 비교한 뒤, 원하는 선언에서 빠진 객체를 sync 과정에서 삭제하는 동작입니다. 따라서 클러스터의 모든 객체를 지우는 것은 아니며, Git 파일 하나를 삭제했다고 반드시 객체 하나가 바로 삭제되는 것도 아닙니다. 실제로 무엇이 대상인지 보려면 렌더된 GVK·namespace·name, 리소스 추적 방식, 그리고 resource identity가 파일 경로와 달라지는 경우를 함께 대조합니다.
삭제 계기와 대상 범위
| 변경 | 의미 | 확인할 범위 |
|---|---|---|
| 파일명만 변경 | 렌더된 객체 identity가 같을 수 있음 | GVK·namespace·name |
| metadata.name 변경 | 보통 새 객체와 옛 객체 | 생성·prune 순서·참조 |
| 개별 선언 제거·prune | 추적 리소스 정리 | 보호 옵션·의존 객체 |
| Application cascade 삭제 | finalizer·삭제 옵션에 따른 관리 집합 정리 | 전체 추적 대상·추가 연쇄 |
| Namespace 삭제 | namespace 안 자원 영향 | PVC·Secret·외부 controller |
Application을 삭제할 때 관리 리소스까지 따라 지우는 cascading 범위는 Argo CD finalizer, 리소스 추적 방식, 삭제 옵션에 따라 달라집니다. 이것은 선언에서 빠진 한 리소스를 sync 중 정리하는 개별 prune과 계기와 범위가 같지 않으므로, Application 삭제 전에는 전체 추적 집합을 따로 펼쳐 봅니다. 그 뒤 Kubernetes owner reference와 외부 controller가 추가로 삭제할 수 있는 의존 객체까지 포함해 실제 연쇄를 검토합니다.
데이터 자원의 삭제 전 복원 능력
그림을 글로 읽기
- 실제 참조·보존 요구 확인
- PV·CSI·reclaim 정책 확인
- 필요 백업·snapshot 확보
- 독립 환경 복원 검증
- 정확한 삭제 집합 승인
- 실제 참조·보존 요구 확인 → PV·CSI·reclaim 정책 확인: 대상 정체성 확정
- PV·CSI·reclaim 정책 확인 → 필요 백업·snapshot 확보: 손실 영향 평가
- 필요 백업·snapshot 확보 → 독립 환경 복원 검증: 복구 집합 검증
- 독립 환경 복원 검증 → 정확한 삭제 집합 승인: RPO·RTO와 책임
삭제 전에 PVC를 참조하는 Pod·Job·StatefulSet과 백업·관리 도구를 목록으로 만들고, 데이터 소유자가 요구하는 보존 기간과 복원 지점을 확인합니다. 그런 다음 PV의 reclaimPolicy, 스토리지 provisioner, StatefulSet PVC retention, snapshot deletion policy를 한 계층씩 따라가서 Delete일 때 underlying storage까지 삭제되는 경로가 있는지 봅니다.
Retain이어도 자동 재바인딩이나 복구가 보장되는 것은 아니므로, 남은 PV와 실제 backend ID를 복원 절차로 연결해 시험해야 합니다.
DB snapshot에는 필요한 페이지·WAL·키·설정이 일관된 집합으로 있어야 합니다. 별도 복원 환경에서 마지막 확인된 커밋·핵심 불변식·복구 시간을 검증합니다. 백업 생성 성공을 복구 완료라고 부르지 않습니다.
삭제 보호와 잔존 자원 정리의 동시 설계
중요 리소스에는 수동 승인·prune 보호·작은 sync 범위·적절한 wave를 적용할 수 있습니다. 그러나 삭제를 영원히 막으면 비용·권한·민감 데이터가 계속 남습니다. 누가 어떤 조건에서 보존을 끝내고 정리하는지 명시합니다.
finalizer가 남으면 소유 controller·외부 정리 상태를 먼저 확인합니다. 무조건 강제 제거하면 외부 리소스가 고아로 남고 실제 데이터 정책을 어길 수 있습니다. 이 노트는 보호 우회나 삭제를 실행하지 않으며 운영 삭제에는 대상·백업·영향 범위의 명시적 승인이 필요합니다.
의도하지 않은 prune 뒤 자동 변경과 잔존 상태
의도하지 않은 prune이 진행되었다면 추가 변경을 통제하고 실제 삭제된 객체·남은 PV·backend ID·snapshot을 확인해야 합니다. 같은 이름의 PVC를 급히 재생성하면 빈 새 저장소가 붙어 남아 있는 원본의 정체성을 혼동할 수 있습니다. 원본이 무엇인지 확인한 뒤 복원 경로를 선택합니다.
Git revert·앱 이미지 rollback·DB 복원·외부 자원 복구·키 회수는 각자 다른 행동입니다. 유출 키는 가용성 회복을 위해 다시 살리는 것이 안전하지 않을 수 있습니다. 복구 성공은 Synced 표시가 아니라 필요한 데이터와 자격·서비스 결과가 정책을 만족하는지로 봅니다.
삭제 검토 실습은 데이터 없는 격리 Application에서 파일명 변경, metadata.name 변경, 개별 prune, Application cascade를 각각 별도 실행 계획으로 비교하는 방식으로 제한하십시오. 예상 결과는 파일 경로만 바꾼 경우 identity가 같을 수 있지만 이름 변경은 새 객체와 옛 객체의 생성·prune 문제를 만들 수 있다는 것입니다. 실제 PVC나 외부 backend를 삭제하지 않고도 렌더된 GVK·namespace·name과 추적 집합의 차이를 검증할 수 있습니다.
추적 리소스 집합과 부분 실패 시험
데이터 없는 격리 Application에서 파일명 변경·객체명 변경·개별 prune·cascade 삭제를 나눠 예상 삭제 집합과 실제 결과를 대조합니다. 삭제 중간 실패·finalizer 지연·복원 실패도 확인합니다. 현재 작업에서는 Argo CD 삭제나 PVC 복원을 실행하지 않았으며 본문은 안전한 삭제 검토와 복구 설계입니다.