Helm - Helm 2 vs Helm 3

차트(Chart)나 블로그를 보다 보면 Helm 2 기준으로 설명된 자료가 여전히 많습니다. 하지만 Helm 3(2019년 11월 릴리스) 이후로 구조가 크게 바뀌었고, 특히 보안 모델과 업그레이드/롤백 동작 방식에서 체감 차이가 큽니다. 이 글에서는 강의 스크립트 흐름을 유지하면서, 실무 관점에서 “왜 Helm 3가 더 단순하고 안전하고 똑똑해졌는지”를 정리합니다.

1) Helm 간단 연혁

Helm 1.0: 2016년 2월
Helm 2.0: 2016년 11월
Helm 3.0: 2019년 11월

Helm 자체도 성숙해졌지만, Kubernetes가 RBAC, CRD 등 “운영에 필요한 기반 기능”을 갖추면서 Helm이 Kubernetes 기능을 더 직접적으로 활용할 수 있게 된 점이 Helm 3 설계 변화에 영향을 줬습니다.

2) 가장 큰 변화 1: Tiller(틸러) 삭제

Helm 2 구조: “Helm Client → Tiller → Kubernetes API”

Helm 2 시절에는 클러스터 내부에 Tiller라는 서버 컴포넌트를 설치했습니다.

사용자는 로컬에 설치된 helm CLI로 명령 실행
helm CLI가 클러스터 안의 Tiller에게 요청
Tiller가 Kubernetes API와 통신해서 리소스 생성/업데이트/삭제 수행

즉, Tiller가 중간자(middleman) 역할을 했습니다.

Helm 2의 문제점: 복잡도 + 보안(“God mode”)

Tiller를 추가로 운영해야 하니 구조가 복잡해지고, 더 큰 문제는 보안이었습니다.

기본 설정에서 Tiller가 클러스터 전반에 강한 권한(사실상 cluster-admin 수준) 으로 동작하는 구성이 많았고
“Tiller에 접근 가능한 사용자”는 사실상 클러스터에서 뭘이든 할 수 있게 되는 위험이 있었습니다.

강의에서 말한 “God mode”가 이 지점을 의미합니다.

Helm 3 구조: “Helm Client → Kubernetes API”

Helm 3에서는 Tiller가 완전히 제거되었습니다.

Helm CLI가 kubeconfig를 통해 직접 Kubernetes API에 요청
권한은 “helm이 특별히 더 갖는 것”이 아니라, 명령을 실행하는 사용자/서비스어카운트의 RBAC 권한 그대로 적용

즉 Kubernetes 입장에서는:

사용자가 kubectl로 변경 요청하든,
helm으로 변경 요청하든,

동일한 RBAC 정책이 적용됩니다.

3) Helm 3에서 RBAC가 체감상 좋아지는 이유

Helm 3는 “클러스터 안에 특권 서버(Tiller)를 두는 방식”이 아니라, 요청 주체(사용자 또는 ServiceAccount) 에 RBAC를 걸면 됩니다.

예를 들어, 특정 네임스페이스에서만 릴리즈 설치/업데이트가 가능하도록 제한하고 싶다면, 아래처럼 Role/RoleBinding으로 제어하는 식입니다.

apiVersion: v1
kind: ServiceAccount
metadata:
  name: helm-deployer
  namespace: blog
---
apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
  name: helm-release-manager
  namespace: blog
rules:
  - api: ["", "apps", "batch", "networking.k8s.io"]
    resources: ["deployments", "services", "secrets", "configmaps", "jobs", "cronjobs", "ingresses", "pods"]
    verbs: ["get", "list", "watch", "create", "update", "patch", "delete"]
---
apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
  name: helm-release-manager-binding
  namespace: blog
subjects:
  - kind: ServiceAccount
    name: helm-deployer
    namespace: blog
roleRef:
  kind: Role
  name: helm-release-manager
  apiGroup: rbac.authorization.k8s.io

이 ServiceAccount로 kubeconfig를 만들거나, CI/CD에서 이 SA 토큰을 사용하면 Helm 작업 범위를 “blog 네임스페이스”로 제한할 수 있습니다.

4) 가장 큰 변화 2: 3-way Strategic Merge Patch (업그레이드/롤백이 더 “똑똑”해짐)

이름은 어렵지만, 핵심은 간단합니다.

Helm 2는 변경/롤백 판단을 할 때 “이전 차트 vs 현재 차트” 비교에 주로 의존
Helm 3는 여기에 더해 “클러스터의 실제 라이브 상태(live state)” 까지 같이 본다

그래서 “사용자가 kubectl로 수동 변경한 것” 같은 상황에서 Helm 3가 더 일관되게 동작할 가능성이 커집니다.

5) Revision(리비전) = 릴리즈 스냅샷 개념 다시 정리

Helm은 릴리즈에 대해 변경 이력을 revision으로 관리합니다.

최초 설치: revision 1
upgrade 수행: revision 2
rollback 수행: revision 3 (롤백 자체도 “새 리비전”으로 기록)

자주 쓰는 확인 명령:

helm history my-wp -n blog
helm status my-wp -n blog

롤백:

helm rollback my-wp 1 -n blog

6) Helm 2에서 문제가 되는 대표 시나리오: “kubectl로 수동 변경 후 rollback”

시나리오

Helm으로 WordPress 설치 → revision 1 생성
사용자가 Helm이 아니라 kubectl set image로 이미지를 바꿔버림
Helm rollback 수행

예시:

helm install my-wp bitnami/wordpress -n blog

# (안티패턴 예시) Helm을 우회해서 수동 변경
kubectl -n blog set image deploy/my-wp-wordpress wordpress=wordpress:5.8

Helm 2의 한계(강의 설명 흐름)

Helm 2는 “리비전 간 차이”를 주로 차트 기준으로 판단합니다. 그런데 방금 변경은 Helm으로 한 게 아니라서 새 revision이 생기지 않습니다.

Helm이 보기에는 “revision 1만 존재”
rollback 시 “현재 차트 vs 이전 차트”를 비교해도 큰 변화가 없다고 판단할 수 있음
결과적으로 수동 변경을 되돌리지 못하는 상황이 생길 수 있습니다(강의가 말하는 포인트)

7) Helm 3의 접근: “이전/목표/라이브 상태를 같이 비교” (3-way)

Helm 3는 다음 3가지를 함께 고려해서 패치를 만든다고 이해하면 됩니다.

이전에 Helm이 적용했던 상태(이전 revision의 매니페스트)
이번에 적용하려는 목표 상태(롤백 대상 revision 혹은 업그레이드 대상 차트)
현재 클러스터의 실제 상태(live state)

그래서 위 시나리오에서:

live state 이미지가 5.8
되돌리려는 revision 1의 이미지가 4.8

이라면, “차트 리비전 비교만”으로는 놓칠 수 있던 변경을 live state를 보고 감지해서 원래 상태(4.8)로 되돌리는 방향의 변경을 적용할 수 있습니다.

강의에서 말하는 “Helm 3가 더 intelligent 하다”의 핵심이 여기입니다.

8) 업그레이드에서도 이 차이가 중요해진다: “수동 추가 설정 보존”

또 다른 흔한 상황:

Helm으로 설치
운영 중에 사용자가 리소스에 annotation, sidecar, env 등을 수동으로 추가(권장되진 않지만 현실에서 발생)
Helm upgrade 수행

Helm 2는 업그레이드 시 “구 차트 vs 새 차트”만 보고 적용하는 성향이 강해, 수동 변경분이 차트에 없으면 덮어써서 사라지는 일이 생길 수 있습니다.

Helm 3는 live state도 참고하는 방향이라, 일부 케이스에서 사용자가 추가한 변경을 보존하며 업그레이드할 여지가 커집니다(강의 설명).

다만 실무 팁:

“Helm이 보존해줄 거야”에 기대는 운영은 위험합니다.
원칙적으로는 수동 변경은 values.yaml/템플릿으로 흡수해서 “Helm이 관리하는 상태”로 가져오는 게 가장 안전합니다.

9) 운영 관점에서 권장 패턴(추가 정리)

(1) Helm으로 설치한 리소스는 Helm으로 변경한다

kubectl edit, kubectl set image 같은 수동 변경은 “긴급조치”로만 쓰고,
이후 반드시 차트(values/템플릿)에 반영해서 형상과 실제를 일치시키는 게 안정적입니다.

(2) 변경 이력과 드리프트(Drift) 확인

릴리즈가 실제로 어떤 매니페스트를 적용했는지 확인:

helm get manifest my-wp -n blog
helm get values my-wp -n blog

(선호한다면 helm diff 플러그인으로 upgrade 전후 차이를 보는 방식도 실무에서 많이 씁니다.)

10) 결론: Helm 3가 “단순 + 안전 + 예측 가능”해진 이유

Tiller 제거로 구조 단순화
Kubernetes의 RBAC 모델을 그대로 활용 → 권한 통제가 명확해짐
3-way Strategic Merge Patch로 롤백/업그레이드가 라이브 상태까지 고려 → 수동 변경이 섞인 환경에서 더 일관된 동작 기대

결국 Helm 3는 Kubernetes 앱을 “오브젝트 묶음”이 아니라 릴리즈 단위 애플리케이션으로 다루는 경험을 더 안전하게 만들어줍니다.

'CKA' 카테고리의 다른 글

Helm - Charts (0)	2026.01.07
Helm - Components (0)	2026.01.07
Helm (0)	2026.01.07
Deploy k8s - kubeadm으로 배포하기 (0)	2026.01.06
Deploy k8s (0)	2026.01.06

1) Helm 간단 연혁

2) 가장 큰 변화 1: Tiller(틸러) 삭제

Helm 2 구조: “Helm Client → Tiller → Kubernetes API”

Helm 2의 문제점: 복잡도 + 보안(“God mode”)

Helm 3 구조: “Helm Client → Kubernetes API”

3) Helm 3에서 RBAC가 체감상 좋아지는 이유

4) 가장 큰 변화 2: 3-way Strategic Merge Patch (업그레이드/롤백이 더 “똑똑”해짐)

5) Revision(리비전) = 릴리즈 스냅샷 개념 다시 정리

6) Helm 2에서 문제가 되는 대표 시나리오: “kubectl로 수동 변경 후 rollback”

시나리오

Helm 2의 한계(강의 설명 흐름)

7) Helm 3의 접근: “이전/목표/라이브 상태를 같이 비교” (3-way)

8) 업그레이드에서도 이 차이가 중요해진다: “수동 추가 설정 보존”

9) 운영 관점에서 권장 패턴(추가 정리)

(1) Helm으로 설치한 리소스는 Helm으로 변경한다

(2) 변경 이력과 드리프트(Drift) 확인

10) 결론: Helm 3가 “단순 + 안전 + 예측 가능”해진 이유

'CKA' 카테고리의 다른 글

티스토리툴바