[cicd] cloudeNet Study 2주차 -Helm

진웅·2025년 10월 25일

CI/CD

목록 보기
2/7

Helm Chart 개요

Helm은 Kubernetes 환경에서 애플리케이션을 보다 쉽게 배포하고 관리하기 위한 패키지 관리 도구.
여러 개의 매니페스트 파일을 하나의 패키지 형태로 묶어 효율적인 배포와 버전 관리를 가능하게 한다.


Chart란 ?

Kubernetes 애플리케이션을 설치하기 위한 패키지
즉, 여러 개의 Kubernetes 리소스 파일(Deployment, Service, ConfigMap 등)을 하나의 버전 관리 가능한 묶음으로 만든 것.

Helm Chart 사용 이유

  1. 배포 단순화

    • Deployment, Service, Ingress 등 여러 리소스를 하나의 Chart로 묶어 간단한 명령으로 배포할 수 있다.
    • 예시:
      helm install my-app ./my-chart
  2. 환경별 설정 관리

    • values.yaml 파일을 통해 개발, 스테이징, 운영 환경별 설정을 쉽게 분리할 수 있다.
      helm install my-app ./my-chart -f values-prod.yaml
  3. 버전 관리 및 롤백

    • Helm은 각 배포를 버전으로 관리하기 때문에, 문제가 생기면 이전 버전으로 손쉽게 되돌릴 수 있다.
      helm rollback my-app 1
  4. 재사용과 표준화

    • 동일한 Chart 템플릿을 여러 서비스나 환경에서 재활용할 수 있고, 배포 구조를 조직 내 표준으로 통일할 수 있다.

Helm의 장단점

장점

구분설명
배포 효율성여러 리소스를 한 번에 설치하거나 업데이트 가능하다
유지보수 용이버전 관리와 롤백 기능 내장되어 있다
재사용성공통 Chart를 여러 서비스에서 재활용 가능하다
환경별 설정 용이values.yaml 파일로 손쉽게 환경별 설정 변경 가능하다
CI/CD 연동성ArgoCD, Jenkins, GitOps 등과 자연스럽게 통합 가능하다

단점

구분설명
템플릿 복잡도Go 템플릿 문법이 복잡해질 경우 유지보수가 어려움
디버깅 어려움렌더링된 결과를 보기 전까지 오류를 파악하기 힘듦
버전 충돌 가능성여러 팀이 같은 Chart를 공유할 경우 관리 부담 증가한다.
보안 주의 필요외부 Chart Repository 사용 시 신뢰성 검증이 중요하다

Helm 기본 사용 가이드

Helm 설치

macOS

brew install helm

Linux

curl https://raw.githubusercontent.com/helm/helm/main/scripts/get-helm-3 | bash

Windows (Chocolatey)

choco install kubernetes-helm

설치 후 버전 확인:

helm version

Chart 기본 구조

my-chart/
 ├── Chart.yaml          # Chart 메타데이터 (이름, 버전 등)
 ├── values.yaml         # 기본 설정 값
 ├── templates/          # Kubernetes 매니페스트 템플릿
 │    ├── deployment.yaml
 │    ├── service.yaml
 │    └── _helpers.tpl
 └── README.md

Chart 생성

helm create my-chart

이 명령으로 my-chart 디렉토리가 생성되며, 기본 Deployment/Service 템플릿이 포함되어 있다.


Chart package

  • helm package는 Helm Chart 디렉토리를 .tgz 패키지 파일로 묶는 명령어이다.
    즉, Helm Chart를 배포 가능한 단일 파일 형태로 만드는 명령어이다.
helm package ./mychart

./mychart: Chart 디렉토리 경로

실행 결과: mychart-<버전>.tgz 파일 생성 (Chart.yaml의 version 참조)

Chart 배포 (설치)

만들어진 Chart를 실제 Kubernetes 클러스터에 배포하려면:

helm install my-app ./my-chart

my-app은 Release 이름이며, Helm은 이 이름을 기준으로 배포 이력을 관리한다.

배포 후 상태 확인:

helm status my-app

현재 클러스터 내 설치된 Helm Release 목록 보기:

helm list

설정 변경 및 업데이트

환경별 설정 값을 수정하려면 values.yaml을 수정하거나,
별도의 파일을 만들어 옵션으로 지정할 수 있다.

예시:

helm upgrade my-app ./my-chart -f values-prod.yaml

또는 명령어 인라인(--set) 방식으로도 변경 가능:

helm upgrade my-app ./my-chart --set image.tag=v2.0.0

Helm은 이전 배포 이력을 자동으로 관리하므로, 문제가 생기면 손쉽게 롤백할 수 있다.

helm rollback my-app 1

Chart 삭제

더 이상 필요 없는 배포는 아래 명령으로 제거할 수 있다.

helm uninstall my-app

삭제 후에도 이력은 남기지 않으므로, 완전히 제거된다.


Helm Template 미리보기 (렌더링 결과 확인)

템플릿이 실제로 어떤 YAML로 생성되는지 보고 싶다면:

helm template ./my-chart

이 명령은 Chart를 실제로 배포하지 않고, Kubernetes 리소스 매니페스트를 콘솔에 출력한다.
디버깅 시 유용하다.


외부 Chart Repository 사용

Helm은 공식 및 커뮤니티 Chart Repository를 통해
Nginx, MySQL, Redis 등 이미 만들어진 Chart를 바로 설치할 수 있다.
bitnami는 이제 미지원이라고 보면 된다.
예시:

helm repo add bitnami https://charts.bitnami.com/bitnami
helm repo update
helm install my-mysql bitnami/mysql

Repository 목록 확인:

helm repo list

요약

항목명령어설명
Chart 생성helm create my-chart새 Chart 기본 구조 생성
Chart 설치helm install my-app ./my-chart클러스터에 배포
설정 변경helm upgrade my-app ./my-chart -f values.yaml환경별 설정 적용
롤백helm rollback my-app 1이전 버전으로 되돌리기
삭제helm uninstall my-appRelease 제거
템플릿 확인helm template ./my-chart렌더링 결과 미리보기

동일 패턴의 여러 사이트 운영 예시

여러 개의 유사한 사이트를 운영해야 하는 경우, Helm이 유용하다.
Helm + Git 브랜치 관리 가이드**를 실제 예시

동일 패턴의 여러 사이트 운영 시 Helm 활용 가이드


시나리오 개요

  • 공통 구성: Cilium CNI를 사용하는 Kubernetes 클러스터
  • 공통 Chart: networking-chart
  • 차이점: Cilium 버전 및 설정(values 파일로 분리)
  • 배포 환경: customer-a, customer-b, customer-c

Helm Chart 구조


networking-chart/
├── Chart.yaml
├── values.yaml
├── templates/
│    ├── daemonset.yaml
│    ├── configmap.yaml
│    └── _helpers.tpl
├── values-customer-a.yaml
├── values-customer-b.yaml
├── values-customer-c.yaml
└── README.md

Chart.yaml

apiVersion: v2
name: networking-chart
description: Helm chart for deploying Cilium CNI
version: 1.2.0
appVersion: "1.16.0"

values.yaml (기본 설정)

cilium:
  image: quay.io/cilium/cilium
  version: v1.15.6
  enableHubble: false
  clusterName: default
resources:
  requests:
    cpu: 100m
    memory: 128Mi

설정 파일

values-customer-a.yaml

cilium:
  version: v1.14.8
  enableHubble: true
  clusterName: customer-a-cluster
resources:
  requests:
    cpu: 250m
    memory: 256Mi

values-customer-b.yaml

cilium:
  version: v1.15.6
  enableHubble: false
  clusterName: customer-b-cluster
resources:
  requests:
    cpu: 150m
    memory: 200Mi

values-customer-c.yaml

cilium:
  version: v1.16.0
  enableHubble: true
  clusterName: customer-c-cluster
resources:
  requests:
    cpu: 300m
    memory: 512Mi

배포

각 환경(고객사)별로 Helm 명령을 아래처럼 실행한다.:

# Customer A
helm install cilium-a ./networking-chart -f values-customer-a.yaml

# Customer B
helm install cilium-b ./networking-chart -f values-customer-b.yaml

# Customer C
helm install cilium-c ./networking-chart -f values-customer-c.yaml

필요시 Helm CLI를 이용해 직접 --set 옵션으로 일부 설정을 덮어쓸 수 있다.(최우선순위 적용):

helm upgrade cilium-a ./networking-chart \
  --set cilium.version=v1.16.1 \
  --set cilium.enableHubble=true

차이점

환경Cilium 버전HubbleCPUMemoryCluster Name
customer-av1.14.8250m256Micustomer-a-cluster
customer-bv1.15.6x150m200Micustomer-b-cluster
customer-cv1.16.0300m512Micustomer-c-cluster

Git 브랜치 적용

여러 환경을 운영을 위해 Git 브랜치 전략으로 Chart와 설정을 분리 관리하는 것이 좋다.

Repository 구조 예시

git-repo/
 ├── charts/
 │    └── networking-chart/       # 공통 Helm Chart
 ├── values/
 │    ├── customer-a/values.yaml
 │    ├── customer-b/values.yaml
 │    ├── customer-c/values.yaml
 ├── environments/
 │    ├── customer-a/             # GitOps 툴 (ArgoCD 등) 참조 경로
 │    ├── customer-b/
 │    ├── customer-c/
 └── README.md

브랜치 전략 예시

브랜치역할
main공통 Chart 및 안정화된 버전 유지
feature/update-cilium-v1.16Cilium 버전 업그레이드 테스트
customer-aCustomer A 전용 설정 관리 (values 차별화)
customer-bCustomer B 전용 설정 관리
customer-cCustomer C 전용 설정 관리

Git Workflow 예시

# 새로운 버전 테스트 브랜치 생성
git checkout -b feature/update-cilium-v1.16

# Chart.yaml 및 values.yaml 수정
vi charts/networking-chart/Chart.yaml
vi charts/networking-chart/values.yaml

# 변경 내용 커밋
git add .
git commit -m "Update Cilium to v1.16.0"

# main 브랜치로 Pull Request 생성 후 검토
git push origin feature/update-cilium-v1.16

배포 환경별로는 GitOps(예: ArgoCD, FluxCD)에서 브랜치를 추적하게 하여 자동 배포를 관리한다..


ArgoCD 연동 예시

예를 들어 ArgoCD에서 각 고객사별로 다른 values 파일을 참조하도록 설정할 수 있습니다.

apiVersion: argoproj.io/v1alpha1
kind: Application
metadata:
  name: customer-a-cilium
spec:
  project: default
  source:
    repoURL: https://github.com/org/k8s-networking.git
    path: charts/networking-chart
    targetRevision: customer-a
    helm:
      valueFiles:
        - values/customer-a/values.yaml
  destination:
    server: https://kubernetes.default.svc
    namespace: kube-system

요약

항목설명
공통 Chart 유지Cilium 기반 네트워킹 Chart를 하나만 관리
환경별 설정 분리values-*.yaml 또는 브랜치별 관리
Git 관리 방식main에서 공통 Chart 유지, 고객/환경별 브랜치 운영
GitOps 연동ArgoCD/FluxCD로 자동 배포 구성 가능
장점설정 표준화, 버전 일관성, 빠른 업데이트 및 롤백 가능

Helm Index

Helm Chart 리포지토리의 목차 역할을 하는 YAML 파일이다.
즉, 리포지토리에 어떤 Chart가 있고, 각각의 버전이 어디서 다운로드되는지, 언제 생성됐는지 같은 정보를 모두 기록한 파일이다.
Helm에서 말하는 index 파일(index.yaml)은 Helm Chart 리포지토리의 목차 역할을 하는 YAML 파일이다.

즉, 리포지토리에 어떤 Chart가 있고, 각각의 버전이 어디서 다운로드되는지, 언제 생성됐는지 같은 정보를 모두 기록한 파일이다.


기본 구조

apiVersion: v1
entries:
  mychart:
    - version: 0.2.0
      urls:
        - https://example.com/charts/mychart-0.2.0.tgz
      created: "2025-10-26T12:00:00Z"
    - version: 0.1.0
      urls:
        - https://example.com/charts/mychart-0.1.0.tgz
      created: "2025-10-20T12:00:00Z"
generated: "2025-10-26T12:01:00Z"
  • entries: Chart 이름별로 버전 리스트
  • urls: 해당 Chart 패키지(.tgz) 다운로드 경로
  • created: 해당 Chart 버전이 생성된 날짜
  • generated: index.yaml이 생성된 날짜

역할

  1. Helm 클라이언트가 Chart 목록을 조회할 수 있게 함

    • helm search repo 명령 시 index.yaml을 참고
  2. Chart 버전 관리

    • 어떤 버전이 존재하고, 어디서 가져와야 하는지 알려줌
  3. 리포지토리 자동 갱신 지원

    • 새 Chart를 추가할 때 기존 index와 병합 가능 (--merge 옵션)

##Helm Package 명령 상세

helm package는 Helm Chart 디렉토리를 배포 가능한 .tgz 패키지 파일로 압축하는 명령어이다.
패키지로 만든 Chart는 Helm 리포지토리에 업로드하거나 다른 환경에서 설치할 수 있다.

1. 기본 사용법

helm package ./mychart
  • ./mychart: 패키징할 Chart 디렉토리 경로

  • 실행 결과: mychart-<버전>.tgz 파일 생성

    • 버전은 Chart.yamlversion 참조

예시:

$ helm package ./mychart
Successfully packaged chart and saved it to: /home/user/mychart-0.1.0.tgz

2. 주요 옵션

옵션설명
--destination패키지 저장 경로 지정
--versionChart 버전을 override
--app-versionChart 안의 appVersion을 override
--sign패키지 서명
--key서명 키 지정
--keyring서명 키링 파일 지정

예시:

helm package ./mychart --version 0.2.0 --destination ./dist
  • 출력: ./dist/mychart-0.2.0.tgz

3. 패키징 후 활용

  1. Helm 리포지토리에 업로드
helm repo index ./dist --url https://example.com/charts --merge ./dist/index.yaml
  1. 다른 환경에서 설치
helm install mychart ./dist/mychart-0.2.0.tgz

Helm Dependency

Helm Dependency는 하나의 Chart가 다른 Chart를 내부 의존성으로 포함하도록 관리하는 기능이다.


1. 기본 개념

  • requirements.yaml (Helm 2) 또는 Chart.yaml > dependencies (Helm 3)
    • 하위 Chart 이름, 버전, 리포지토리 URL을 정의
  • 하위 Chart는 subchart로 포함되어 상위 Chart 배포 시 자동 적용

예시 (Helm 3 Chart.yaml):

apiVersion: v2
name: webapp
version: 1.0.0
dependencies:
  - name: redis
    version: 16.0.0
    repository: "https://charts.bitnami.com/bitnami"
  - name: postgres
    version: 15.2.0
    repository: "https://charts.bitnami.com/bitnami"

2. 의존성 설치 및 업데이트

helm dependency update ./webapp
  • charts/ 디렉토리에 하위 Chart .tgz 다운로드
  • 의존성 버전이 바뀌면 Chart.lock 파일 갱신

##ConfigMap 변경 시 자동 Rolling Update 트리거링

ConfigMap이 변경될 때, Deployment의 Rolling Update가 자동으로 시작되도록 설정하는 방법이다.


1. 개요

  • ConfigMap 객체가 변경되면 Deployment가 자동으로 롤링 업데이트되도록 구성 필요
  • Helm 템플릿에서 sha256sum 함수를 사용해 Deployment에 변경 내역을 주입하는 방식으로 구현

2. 주요 내용

  • 커스텀마이즈(Kustomize)에서는 ConfigMap이 변경되면 메타데이터 이름에 해시 값을 붙여 Deployment가 이를 참조하도록 ConfigMapGenerator를 사용해 문제 해결 가능
  • Helm은 직접 메타데이터를 수정하는 대신, 모든 파일의 SHA-256 해시를 계산해 템플릿 함수로 결과를 포함하는 방식을 제공
  • sha256sum 함수를 사용하여 configmap.yaml 파일 내용의 SHA-256 값을 계산하고, 이를 Pod의 annotation에 넣어 ConfigMap이 바뀔 때마다 자동으로 롤링 업데이트가 발생하도록 설정

3. 구현 예시 (deployment.yaml)

spec:
  replicas: {{ .Values.replicaCount }}
  selector:
    matchLabels:
      app.kubernetes.io/name: {{ .Chart.Name }}
  template:
    metadata:
      labels:
        app.kubernetes.io/name: {{ .Chart.Name }}
      annotations:
        checksum/config: {{ include (print $.Template.BasePath "/configmap.yaml") . | sha256sum }}
  • checksum/config annotation에 ConfigMap 내용의 SHA-256 해시를 주입
  • ConfigMap이 변경되면 해시 값이 바뀌고, Pod 정의가 변경되어 롤링 업데이트가 자동으로 트리거됨

4. 검증 및 주의점

  • ConfigMap 변경 후 helm upgrade를 수행하면 Deployment의 Pod가 롤링 업데이트 되는지 확인
  • ConfigMap을 환경 변수로 사용하는 경우, 해시 기반 annotation 설정이 필수임
  • Helm 템플릿 함수 sha256sum 활용으로 자동화 및 변경 추적이 용이

5. 요약

항목설명
문제ConfigMap 변경 시 Deployment 자동 롤링 업데이트 미발생
해결책ConfigMap 내용 SHA-256 해시를 Deployment annotation에 삽입
방법Helm 템플릿 함수 sha256suminclude 사용
결과ConfigMap 변경 시 Pod 정의 변경 → 자동 롤링 업데이트

`

profile
bytebliss

0개의 댓글