Lifecycle management with Helm

✅ Helm의 Lifecycle Management 요약

🔹 1. Release의 개념 다시 보기

• helm install을 수행하면 Release가 생성됨.

• Release = Kubernetes 오브젝트들의 집합 + Helm이 추적할 수 있는 메타데이터

• Helm은 이 Release를 기준으로:

  • 업그레이드 (upgrade)
  • 롤백 (rollback)
  • 삭제 (uninstall)
    등 다양한 Lifecycle 작업을 관리함.

---

🔹 2. Helm Upgrade (버전 업데이트)

helm upgrade <release-name> <chart-name> --version <new-version>

• Helm은 현재 상태 → 새로운 버전 상태로 전환
• 기존 오브젝트 제거 → 새로운 버전 생성
• 예시: nginx를 1.19.2에서 1.21.4로 업그레이드

---

🔹 3. Helm History (수정 이력 조회)

helm history <release-name>

• 해당 Release의 설치/업그레이드/롤백 내역 추적
• 각 Revision 번호, 버전 정보, 명령 종류, 타임스탬프 등 제공
• 팀에서 누가 무엇을 했는지 추적 가능

---

🔹 4. Helm Rollback (이전 상태로 복원)

helm rollback <release-name> <revision-number>

• 예: helm rollback nginx 1

• 주의: 리비전을 단순히 이전 것으로 덮는 것이 아니라,
  → 새로운 Revision 번호 (예: 3) 로 되돌리는 구조

• Helm이 저장하는 것은 오브젝트의 선언 (manifest)이며,
  PersistentVolume의 실제 데이터는 복원되지 않음

---

💡 Helm이 관리하는 것 vs 못하는 것

Helm이 관리함	Helm이 관리 못함
Deployment, Service, ConfigMap, Secret 등 Kubernetes 오브젝트 선언	PVC 데이터, DB 내부 데이터, 파일시스템 내 실제 파일
Chart 버전 및 값 변경 내용	외부 시스템의 상태 (예: 외부 DB, 외부 API 등)
Revision 히스토리, 롤백 이력	Pod 내 로그나 ephemeral data

🧠 즉, Helm은 **"오브젝트 선언 수준의 상태 스냅샷"**을 관리하는 도구야.
데이터를 백업하려면 별도의 툴 필요 (예: Velero, chart hook, cronjob 등)

---

📌 실전 팁

✅ Rollback은 테스트 환경에서도 자주 사용됨

• 신버전 배포 → 이상 발생 → 즉시 복구 가능
• 단, DB 상태와 동기화되지 않으면 애플리케이션이 오작동할 수도 있음

✅ helm history와 helm list는 매일 점검해도 좋은 명령

helm list -A     # 모든 namespace의 release 목록 보기
helm history myapp -n dev

✅ Upgrade 시 오류 발생 시 대처

• WordPress 등 민감한 패키지의 경우, DB 연결 정보 등 누락 시 에러 발생
• --set 옵션 또는 --values 파일로 관리자 정보 제공 필요

---

🔍 명령어 정리

기능	명령어
릴리스 업그레이드	helm upgrade myapp chart-name
이전 버전으로 롤백	helm rollback myapp 1
릴리스 상태 조회	helm list
특정 릴리스 이력 조회	helm history myapp
설치된 pod 확인	kubectl get pods + kubectl describe pod <name>

---

🎯 총정리: Helm Lifecycle의 핵심

Helm은 애플리케이션의 배포, 업그레이드, 복원 과정을 버전 관리되는 선언적 방식으로 수행한다.
모든 변화는 revision으로 추적 가능하고, 언제든 복구할 수 있지만, 데이터 복원은 포함되지 않는다.