훅이 릴리스 바깥에 산다는 것을 확인한다

목표

훅 리소스가 릴리스 바깥에 산다는 사실을 손으로 확인합니다. 애너테이션 세 개를
붙이고, 삭제 정책 둘을 나란히 놓고, 실행 순서를 계산하고, 롤백해도 훅이 남긴 것이
그대로인 것까지 봅니다.

왜 중요한가

DB 마이그레이션을 배포에 넣는 가장 흔한 방법이 pre-upgrade 훅입니다. 그런데 훅으로
만든 오브젝트는 릴리스 시크릿에 들어가지 않습니다. 결과가 둘입니다. 롤백해도 훅이
한 일은 남고, 삭제 정책을 안 걸면 오브젝트가 계속 쌓입니다.

여기서 실무 규칙이 따라 나옵니다. 성공한 훅은 치우고 실패한 훅은 다음 배포까지
남겨 로그를 볼 수 있게 한다는 것, 되돌릴 수 없는 스키마 변경은 배포와 분리해 여러
번에 나눈다는 것, 그리고 Job 훅에는 helm 의 타임아웃보다 짧은 자기 상한을 걸어
둔다는 것입니다. 마지막 것은 helm 이 기다리기를 그만두어도 Job 은 계속 돌기
때문입니다.

환경

이 파드는 kwok 으로 진짜 kube-apiserver 를 띄우지만 **컨테이너는 실제로 실행되지
않습니다.** 그래서 Job 훅은 끝나지 않고 릴리스를 갇히게 만듭니다. 앞의 여섯 단계는
즉시 준비 완료로 판정되는 ConfigMap 으로 훅을 다루고, Job 은 7단계에서 값 하나로
꺼 둔 채 렌더 결과만 봅니다. 작업 디렉터리는 /root/hs-hook 이고 산출물은
/root/hs-hook/out 아래에 둡니다.

단계

1. 차트를 만들고 hook-migrate.yaml 에 훅 애너테이션 세 개를 붙입니다.
2. hook-lab 에 pay 로 설치하고 클러스터와 매니페스트 양쪽을 봅니다.
3. hook-scratch.yaml 을 더해 삭제 정책 두 가지를 비교합니다.
4. hook-early.yaml 을 더하고 실행 순서를 /root/hs-hook/out/order.txt 에 적습니다.
5. tests/smoke.yaml 에 test 훅을 만들고 배포 때 돌지 않는 것을 확인합니다.
6. --no-hooks 렌더를 /root/hs-hook/out/nohooks.yaml 에 저장합니다.
7. hook-migrate-job.yaml 에 안전장치를 갖춘 Job 훅을 만들되 기본값은 꺼 둡니다.
8. 업그레이드하고 롤백한 뒤 /root/hs-hook/out/residue.txt 에 네 줄로 정리합니다.

참고

애너테이션 값은 문자열입니다. hook-weight 를 따옴표 없이 적으면

숫자로 렌더되어 훅으로 인식되지 않습니다.

7단계에서 migrationJob.enabled 를 켠 채 업그레이드하지 마세요. Job 이 끝나지

않아 릴리스가 pending-upgrade 에 갇힙니다.

흔한 실수는 삭제 정책에 hook-failed 를 넣는 것입니다. 실패한 순간 오브젝트가

지워져 원인을 볼 로그가 사라집니다.

단계 8개

훅 애너테이션 세 개를 붙인다
훅은 클러스터에 있는데 매니페스트에는 없다
삭제 정책 둘을 나란히 놓고 차이를 본다
weight 로 실행 순서를 정한다
test 훅은 배포 때 돌지 않는다
--no-hooks 가 무엇을 빼는지 본다
마이그레이션 Job 에 안전장치를 건다
롤백해도 훅이 한 일은 남는다