훅은 릴리스 바깥에 산다

한 줄 요약

훅 리소스는 릴리스가 관리하지 않는다. 그래서 롤백해도 사라지지 않고, 삭제 정책을 안 걸면 클러스터에 쌓인다.

왜 이게 필요했나

DB 마이그레이션을 배포에 넣는 가장 흔한 방법이 pre-upgrade 훅 Job 이다. 그런데 이 Job 은 릴리스의 일부가 아니다. Helm 은 훅을 적용하고, 완료를 기다리고, 그다음 본 매니페스트를 적용한다. 훅으로 만든 Job 오브젝트는 릴리스 시크릿에 들어가지 않는다.

결과는 둘이다.

• 롤백해도 훅이 한 일은 남는다. 마이그레이션이 바꾼 스키마는 그대로다.
• Job 오브젝트가 계속 쌓인다. helm.sh/hook-delete-policy 를 안 걸면 배포할 때마다 하나씩 늘어난다.

어떻게 동작하나

metadata:  annotations:    "helm.sh/hook": pre-upgrade,pre-install    "helm.sh/hook-weight": "-5"          # 작을수록 먼저    "helm.sh/hook-delete-policy": before-hook-creation,hook-succeeded

hook-delete-policy 값 세 가지의 뜻이 다르다.

| 값 | 언제 지우나 |
|---|---|
| before-hook-creation | 다음 배포에서 같은 훅을 만들기 직전 (실패한 Job 을 남겨 조사 가능) |
| hook-succeeded | 성공하면 즉시 |
| hook-failed | 실패하면 즉시 (로그가 사라진다 — 대개 나쁜 선택) |

실무 기본형은 before-hook-creation,hook-succeeded 다. 성공한 건 치우고, 실패한 건 다음 배포까지 남겨 로그를 볼 수 있게 한다.

흔한 착각

훅이 실패하면 롤백된다는 착각. pre-upgrade 훅이 실패하면 업그레이드가 중단되고 릴리스는 failed 로 남는다. --atomic 이 있으면 롤백이 걸리지만, 이미 실행된 마이그레이션은 되돌아오지 않는다.

실무에서 진짜 중요한 것

되돌릴 수 없는 마이그레이션은 배포와 분리한다. 컬럼을 지우는 변경은 세 번에 나눠 배포한다 — ① 새 컬럼 추가(옛 코드도 동작) ② 새 코드 배포 ③ 옛 컬럼 삭제. 이렇게 하면 어느 단계에서 롤백해도 앞뒤 버전이 모두 견딘다. 이걸 확장-수축(expand-contract) 패턴이라 부른다.