Helm - Lifecycle Management(Upgrade/Rollback)

“Lifecycle Management”는 거창하게 들리지만 Helm에서는 아주 실용적인 의미입니다.
한 번 설치한 릴리즈(Release)를 몇 달~몇 년 동안 운영하면서, 보안 패치나 기능 변경을 위해 업그레이드/다운그레이드/롤백/삭제 같은 작업을 안정적으로 반복하는 전 과정을 말합니다.

Helm의 강점은 단순합니다.

• 릴리즈가 어떤 Kubernetes 오브젝트(Deployment/Service/Secret 등)로 구성되는지 Helm이 알고 있고
• 그래서 upgrade/rollback/uninstall 시 해당 릴리즈에 속한 리소스만 정확히 건드립니다.
• 같은 차트를 기반으로 여러 릴리즈가 있어도(예: nginx-prod, nginx-dev) 서로 독립적으로 관리됩니다.

---

1) Release는 “차트로 설치된 앱 인스턴스(오브젝트 묶음)”

차트를 설치하면 릴리즈가 생깁니다.

helm install nginx-release bitnami/nginx --version <chart-version>

 

 

여기서 핵심은:

• Chart: 설치 설계도(템플릿+기본값)
• Release: 차트를 특정 이름으로 설치한 “설치본”
• Revision: 릴리즈 상태의 스냅샷(이력)

또한 강의에서 강조한 포인트:

• --version 옵션은 “차트 버전(chart version)” 을 고정해서 설치하는 기능입니다.
• “오래된 차트 버전”으로 설치하면 결과적으로 “오래된 앱 버전(appVersion)”이 함께 설치될 수 있습니다(차트가 어떤 앱 버전을 참조하도록 만들었느냐에 따라).

---

2) 시간이 지나면 업그레이드가 필요해진다(보안 패치/기능 변경)

두 달만 지나도(웹 서비스에선 긴 시간) 취약점/패치가 쏟아집니다. Nginx처럼 단순한 앱도 업그레이드 시:

• Pod 이미지 버전이 바뀌고
• 경우에 따라 새로운 env var, secret, config 등이 필요해지면서
• 여러 Kubernetes 오브젝트를 함께 조정해야 할 수 있습니다.

수동으로 하면 “뭐를 어디까지 바꿔야 하지?”가 어렵지만, Helm은 릴리즈 단위로 묶어서 관리하므로:

• 한 번의 helm upgrade로 필요한 변경을 일괄 수행합니다.

---

3) 현재 어떤 버전의 Nginx가 돌고 있는지 확인하기(kubectl로 관찰)

강의 흐름대로 “업그레이드 전 상태 확인”은 이렇게 진행합니다.

1. Pod 이름 확인

kubectl get pods

예시 결과:

NAME                                  READY   STATUS    RESTARTS   AGE
nginx-release-nginx-6f6b8c6cc8-8wq2d   1/1     Running   0          1m

2. 이미지 버전 확인

kubectl describe pod nginx-release-nginx-6f6b8c6cc8-8wq2d

예시 결과(핵심 라인만 발췌):

Containers:
  nginx:
    Image:  docker.io/bitnami/nginx:1.19.2-debian-10-r0
    Ports:  8080/TCP
...

예시로 강의에서는 Nginx 이미지가 1.19.2처럼 오래된 버전임을 확인합니다.

실무에서는 kubectl get pod -o=jsonpath=...로 뽑기도 하지만, 강의처럼 describe로 보는 게 학습에 직관적입니다.

---

4) Helm upgrade: 릴리즈를 “미래 상태”로 이동시키기

업그레이드는 릴리즈 이름과 차트를 지정합니다.

helm upgrade nginx-release bitnami/nginx

 

 

업그레이드 결과로 핵심적으로 일어나는 일:

• 기존 리소스(예: Deployment)가 변경됨
• 변경에 따라 old Pod가 내려가고(new rollout), new Pod가 올라옴
• Helm 릴리즈 Revision이 증가함
  • install이 revision 1이었다면
  • upgrade 후 revision 2가 됨

업그레이드가 실제로 반영됐는지 다시 확인:

kubectl get pods

예시 결과(기존 pod 교체됨):

NAME                                  READY   STATUS    RESTARTS   AGE
nginx-release-nginx-7b9f5b7fdd-pm9xk   1/1     Running   0          20s

kubectl describe pod nginx-release-nginx-7b9f5b7fdd-pm9xk

예시 결과(핵심 라인만 발췌):

Containers:
  nginx:
    Image:  docker.io/bitnami/nginx:1.21.4-debian-11-r0
...

강의 예시처럼 Nginx가 1.21.4 등 더 최신 버전으로 바뀐 것을 볼 수 있습니다.

---

5) Helm이 Lifecycle을 관리한다는 뜻: “상태를 기억하고, 되돌릴 수 있다”

릴리즈는 장기간 살아있고, Helm은 다음을 계속 기록합니다.

• 현재 상태(최신 revision)
• 과거 상태들(이전 revision들)
• 각 revision이 “어떤 action으로 생겼는지”(install/upgrade/rollback)

(1) 현재 릴리즈 목록 보기

helm list

예시 결과:

NAME          NAMESPACE REVISION UPDATED                                 STATUS   CHART         APP VERSION
nginx-release default   2        2026-01-07 10:16:05.123456 +0900 KST     deployed nginx-13.2.1  1.21.4

여기서는 보통:

• 릴리즈 이름
• 네임스페이스
• 현재 revision
• 상태(DEPLOYED 등)

까지만 간단히 보여줍니다.

(2) 특정 릴리즈의 이력 자세히 보기: helm history

팀이 크고 여러 사람이 관리하면 “왜 revision이 2지?” 같은 맥락이 필요합니다. 그걸 주는 게 history입니다.

helm history nginx-release

예시 결과:

REVISION  UPDATED                         STATUS     CHART         APP VERSION  DESCRIPTION
1         Wed Jan  7 10:12:33 2026        deployed   nginx-11.1.0   1.19.2       Install complete
2         Wed Jan  7 10:16:05 2026        deployed   nginx-13.2.1   1.21.4       Upgrade complete

history에서 보통 확인하는 것:

• 각 revision이 사용한 chart version
• 각 revision이 사용한 app version
• revision이 생성된 이유(install/upgrade/rollback)
• timestamp 및 설명

이게 바로 “릴리즈의 생애주기 기록”입니다.

---

6) Helm rollback: 이전 상태로 되돌리기(하지만 revision 번호는 새로 생성)

업그레이드가 마음에 안 들면 롤백합니다.

helm rollback nginx-release 1

예시 결과:

Rollback was a success! Happy Helming!

이후 history를 다시 보면:

helm history nginx-release

예시 결과:

REVISION  UPDATED                         STATUS     CHART         APP VERSION  DESCRIPTION
1         Wed Jan  7 10:12:33 2026        deployed   nginx-11.1.0   1.19.2       Install complete
2         Wed Jan  7 10:16:05 2026        deployed   nginx-13.2.1   1.21.4       Upgrade complete
3         Wed Jan  7 10:18:40 2026        deployed   nginx-11.1.0   1.19.2       Rollback to 1

여기서 가장 중요한 개념(강의 포인트):

• “revision 1로 돌아간다”는 말은 동일한 번호로 되돌아가는 게 아닙니다.
• Helm은 새 revision을 하나 더 만들어서 그 내용을 revision 1 상태와 같게 만듭니다.
  • 예: revision 1(install) → revision 2(upgrade) → rollback 하면 revision 3 생성
  • 그리고 revision 3의 설정이 revision 1과 “동일한 상태”가 됩니다.
• history를 보면 “rollback to 1” 같은 설명이 남습니다.

즉, Helm은 “이력 자체는 계속 앞으로” 쌓으면서, “내용은 과거 상태로” 되돌리는 방식입니다.

롤백이 실제로 반영됐는지 확인:

kubectl get pods
kubectl describe pod <current-pod-name>

예시(이미지 버전이 다시 1.19.2로):

Containers:
  nginx:
    Image:  docker.io/bitnami/nginx:1.19.2-debian-10-r0
...

---

7) 모든 차트가 nginx처럼 단순하게 업그레이드되진 않는다(WordPress 예시)

강의에서 WordPress 업그레이드가 추가 파라미터를 요구하는 상황을 언급합니다. 이유는 보통 이런 유형입니다.

• 차트가 업그레이드 중에
  • DB 마이그레이션
  • 관리자 계정/패스워드 확인
  • 특정 설정 변경
    같은 작업을 하려면 기존의 admin password/DB password 같은 값이 필요합니다.
• 하지만 그 값이 없으면 Helm이 안전하게 업그레이드를 진행할 수 없어 “추가 옵션/값을 제공하라”는 안내가 나옵니다.

예시(실제 현장에서 자주 보는 형태의 오류 메시지 스타일):

Error: UPGRADE FAILED: ... must provide the current passwords ...
Hint: You can retrieve the current password by running:
  kubectl get secret --namespace default <secret-name> -o jsonpath="{.data.password}" | base64 --decode
Then run:
  helm upgrade ... --set <passwordKey>=<currentPassword>

이 케이스는 “문제”라기보다, 상태를 유지해야 하는(stateful) 앱의 업그레이드 특성에 가깝습니다.

실무적으로는:

• 최초 설치 시 password/secret 값을 외부에서 관리하거나(existingSecret)
• values.yaml에 명시적으로 고정해두는 방식으로
• 업그레이드 시 “값을 잃어버려서 진행이 막히는 상황”을 예방합니다.

---

8) Helm rollback은 “매니페스트(선언)”만 되돌린다 — 데이터 복구는 별개다

이건 운영에서 정말 중요한 한계입니다.

• Helm의 rollback은 Kubernetes 오브젝트 선언(Deployment/Service/Secret 등)을 과거로 되돌리는 것
• PV에 들어있는 데이터나 외부 DB의 실제 데이터까지 자동으로 되돌리지 않습니다.

예를 들어 MySQL을 롤백하면:

• MySQL Pod 이미지 버전/설정은 과거로 되돌 수 있지만
• DB 파일(데이터)은 보통 PV에 남아 있고 그대로 유지됩니다.

즉:

• “소프트웨어 버전/구성 롤백” ≠ “데이터 시점 복구”

데이터까지 일관되게 되돌리려면:

• 업그레이드 전에 DB 스냅샷/백업
• 필요 시 복구 작업 수행
  같은 별도 전략이 필요합니다.

강의에서는 이런 작업을 자동화하는 방법으로 Chart Hooks를 예고합니다.

• 업그레이드 전(pre-upgrade) 백업 job 실행
• 업그레이드 후(post-upgrade) 검증
  같은 흐름을 차트 훅으로 구성할 수 있습니다.

---

실습 흐름을 그대로 따라가는 커맨드 시퀀스(강의 재현용)

# 1) 오래된 차트 버전으로 설치(예시)
helm install nginx-release bitnami/nginx --version <old-chart-version>

# 2) 현재 nginx 이미지 버전 확인
kubectl get pods
kubectl describe pod <pod-name>

# 3) 업그레이드
helm upgrade nginx-release bitnami/nginx

# 4) 업그레이드 후 버전 확인
kubectl get pods
kubectl describe pod <new-pod-name>

# 5) 릴리즈와 이력 확인
helm list
helm history nginx-release

# 6) 롤백(예: revision 1로)
helm rollback nginx-release 1
helm history nginx-release