[Kubernetes] Helm 3 vs Helm 4 무엇이 달라졌을까? 3-Way Merge와 Server-Side Apply

Helm 3 vs Helm 4 차이 쉽게 이해하기

Kubernetes에서 여러 YAML 파일을 관리하다 보면 자연스럽게 Helm을 접하게 됩니다.

Helm은 흔히 Kubernetes의 패키지 관리자라고 부릅니다.

Linux        Kubernetes

apt     →    Helm
.deb    →    Helm Chart

Deployment, Service, ConfigMap 등의 Kubernetes 리소스를 하나의 Chart로 묶어 관리하고, 이를 설치하거나 업그레이드할 수 있습니다.

그런데 현재 Helm에는 Helm 3와 Helm 4가 존재합니다.

Helm 4에서 무엇이 달라졌는지, 특히 리소스를 업데이트하는 방식의 차이를 중심으로 쉽게 정리해보겠습니다.

---

1. 먼저 Helm, Chart, Release 차이

Helm을 이해하려면 세 가지 용어부터 구분해야 합니다.

Helm

Kubernetes 패키지를 관리하는 CLI 프로그램입니다.

helm install
helm upgrade
helm rollback

같은 명령을 제공합니다.

Helm Chart

Helm으로 설치할 패키지입니다.

예를 들어 nginx Chart 내부에는 다음과 같은 파일이 들어갈 수 있습니다.

nginx-chart/
├── Chart.yaml
├── values.yaml
└── templates/
    ├── deployment.yaml
    └── service.yaml

Release

Chart를 실제 Kubernetes 클러스터에 설치한 결과입니다.

Chart
  │
  │ helm install
  ▼
Release

하나의 Chart를 이용해서 여러 Release를 만들 수도 있습니다.

helm install dev-nginx ./nginx-chart
helm install prod-nginx ./nginx-chart

---

2. Helm 3의 핵심: 3-Way Merge

Helm 3에서 리소스를 업데이트할 때 중요한 개념 중 하나가 3-Way Strategic Merge Patch입니다.

왜 이름이 3-Way일까요?

Helm이 세 가지 상태를 비교하기 때문입니다.

1. 이전에 Helm이 배포한 상태 (OLD)

2. 현재 Kubernetes의 실제 상태 (LIVE)

3. 새롭게 Helm이 배포하려는 상태 (NEW)

예를 들어 처음 Helm으로 다음 Deployment를 설치했다고 가정해보겠습니다.

replicas: 3

그런데 운영 중 관리자가 직접 다음 명령을 실행했습니다.

kubectl scale deployment web --replicas=5

그러면 상태는 다음과 같습니다.

이전 Helm       : 3
현재 Kubernetes : 5

이후 새로운 Helm Chart에서 replicas를 10으로 변경했습니다.

replicas: 10

Helm 3가 바라보는 상태는 다음과 같습니다.

OLD   = 3
LIVE  = 5
NEW   = 10

Helm은 OLD와 NEW를 비교해서

3 → 10

이라는 변경이 Helm에 의해 발생했다는 것을 파악합니다.

따라서 최종적으로 replicas는 10으로 변경됩니다.

OLD 3
 ├── 관리자가 직접 변경 → LIVE 5
 │
 └── Helm에서 변경 → NEW 10

최종 → 10

즉 Helm 3는 단순히 새로운 YAML을 덮어쓰는 것이 아니라 이전 상태, 현재 상태, 새로운 상태를 비교하여 Patch를 생성합니다.

---

3. 그런데 왜 이것보다 더 발전된 방식이 필요할까?

Kubernetes에서는 하나의 리소스를 Helm만 관리한다고 보장할 수 없습니다.

예를 들어 하나의 Deployment에 대해

Helm
HPA
Operator
kubectl
Argo CD

등 여러 주체가 동시에 리소스를 변경할 수 있습니다.

그렇다면 이런 문제가 생깁니다.

"이 필드는 도대체 누가 관리하는 거지?"

Helm이 관리하는 필드인지, HPA가 관리하는 필드인지, 다른 Controller가 관리하는 필드인지 구분할 필요가 있습니다.

여기서 등장하는 것이 Server-Side Apply, SSA입니다.

---

4. Helm 4의 핵심 변화: Server-Side Apply

Helm 4에서는 Kubernetes의 Server-Side Apply(SSA)를 활용할 수 있으며, 새로운 Release에서는 SSA가 기본 적용 방식입니다.

기존 Helm 3 방식에서는 Helm이 직접 상태를 비교하여 Patch를 계산하는 역할을 많이 담당했습니다.

Helm

OLD
LIVE
NEW
 ↓
비교
 ↓
Patch 생성
 ↓
API Server

SSA에서는 이 역할의 상당 부분을 Kubernetes API Server가 담당합니다.

Helm
 │
 │ 원하는 상태 전달
 ▼
Kubernetes API Server
 │
 ├── 현재 상태 확인
 ├── Field Ownership 확인
 ├── 변경 사항 병합
 └── Conflict 확인

여기서 중요한 개념이 Field Ownership입니다.

---

5. Field Ownership이란?

쉽게 말하면 Kubernetes가

"이 필드는 누가 관리하고 있는가?"

를 기억하는 것입니다.

예를 들어 Deployment가 다음과 같다고 가정해보겠습니다.

spec:
  replicas: 3
  template:
    spec:
      containers:
        - name: web
          image: nginx:1.0

개념적으로 Kubernetes는 다음과 같은 관리 관계를 추적할 수 있습니다.

replicas
└── manager A

image
└── Helm

이 정보는 Kubernetes 리소스의 managedFields를 통해 확인할 수 있습니다.

kubectl get deployment web -o yaml

출력에서 다음 항목을 확인할 수 있습니다.

metadata:
  managedFields:

즉 SSA에서는 단순히 현재 YAML의 값만 보는 것이 아니라 어떤 주체가 어떤 필드를 관리하고 있는지도 추적합니다.

---

6. Ownership Conflict가 발생하면?

SSA의 중요한 장점 중 하나입니다.

예를 들어 어떤 manager가 특정 필드를 관리하고 있다고 가정해보겠습니다.

replicas: 5

owner → manager A

그런데 Helm이 같은 필드를 자신이 관리하면서 다음과 같이 변경하려고 합니다.

replicas: 10

owner → Helm로 변경 시도

동일한 필드에 대한 관리 권한이 충돌하면 API Server는 Conflict를 발생시킬 수 있습니다.

manager A
    │
    │ replicas 관리
    ▼
replicas
    ▲
    │ replicas 관리 시도
    │
   Helm

    ↓

Conflict

기본적으로 충돌이 발생하면 Apply가 실패합니다.

즉 Kubernetes가 임의로

"Helm이 새로 왔으니까 Helm 값으로 덮어써야겠다."

라고 처리하지 않습니다.

관리자가 충돌을 해결하거나, 필요한 경우 기존 ownership을 강제로 가져오는 방식으로 처리해야 합니다.

---

7. Helm 3와 Helm 4를 비교하면

핵심적인 차이를 단순화하면 다음과 같습니다.

구분	Helm 3	Helm 4
주요 Apply 방식	Client-side 3-way merge	Server-Side Apply 지원 및 신규 Release 기본
변경 계산의 중심	Helm Client	Kubernetes API Server
비교/관리 방식	OLD + LIVE + NEW	Field Ownership 기반 SSA
필드 관리자 추적 활용	제한적	적극 활용
충돌 처리	Helm의 Patch 계산 중심	API Server가 ownership conflict 감지
여러 Controller와 협업	상대적으로 복잡	더 명확한 관리 가능

구조적으로 보면 더욱 쉽게 이해할 수 있습니다.

Helm 3

OLD ─┐
     │
LIVE ├──→ Helm이 비교 → Patch → API Server
     │
NEW ─┘

Helm 4 + SSA

Helm
 │
 │ Desired State
 ▼
API Server
 │
 ├── 현재 상태
 ├── Field Ownership
 ├── 변경 사항
 └── Conflict
 │
 ▼
최종 상태 결정

---

8. Helm 3 Release를 Helm 4로 Upgrade하면?

여기서 주의해야 할 점이 있습니다.

Helm 4를 설치했다고 해서 기존 Helm 3 Release가 무조건 즉시 SSA 방식으로 변경되는 것은 아닙니다.

기존 Release를 Helm 4에서 계속 관리하는 경우에는 기존 동작 방식과의 호환성이 고려됩니다.

반면 Helm 4에서 새롭게 생성하는 Release는 SSA를 기본 Apply 방식으로 사용합니다.

따라서 단순하게

Helm 4 설치
=
모든 기존 Release 즉시 SSA 전환

이라고 이해하면 안 됩니다.

---

9. Helm 버전별 핵심 변화

Helm의 흐름을 아주 간단하게 정리하면 다음과 같습니다.

Helm 2
│
├── Tiller 사용
├── 클러스터 내부에 Helm 서버 컴포넌트 존재
└── 2-Way Merge 중심
        ↓
Helm 3
│
├── Tiller 제거
├── Helm CLI → Kubernetes API 직접 통신
└── 3-Way Merge 도입
        ↓
Helm 4
│
├── Helm 3의 구조 발전
├── Server-Side Apply 도입
└── Field Ownership 기반 관리 강화

Helm 2에서 Helm 3로 넘어갈 때는 Tiller 제거가 매우 큰 변화였다면,

Helm 3에서 Helm 4로 넘어가면서 이해해야 할 중요한 변화 중 하나는 Server-Side Apply입니다.

---

10. 한 줄 정리

Helm 3와 Helm 4의 Apply 방식을 아주 단순하게 기억하면 다음과 같습니다.

Helm 3
"내가 OLD + LIVE + NEW를 비교해서
 어떤 Patch를 보낼지 계산할게."


Helm 4 + SSA
"내가 원하는 상태를 API Server에 전달할게.
 필드 소유권과 충돌은 Kubernetes와 함께 관리하자."

즉,

Helm 3는 3-Way Merge를 통해 현재 상태까지 비교하는 방식으로 발전했고, Helm 4는 Kubernetes의 Server-Side Apply를 적극 활용하면서 Field Ownership 기반의 리소스 관리로 발전했습니다.

Kubernetes에서 Helm뿐만 아니라 HPA, Operator, GitOps Controller 등 여러 주체가 하나의 리소스를 관리할 수 있다는 점을 생각하면 SSA가 왜 중요한 변화인지 이해하기 쉽습니다.