정의
Helm이란 Chart라는 패키지 형식을 사용해 Kubernetes의 패키지 관리를 도와준다.
여기서 Chart는 Kubenernetes 리소스의 집합을 설명하는 Yaml 파일 모음이라고 생각하면 된다.
흔히 패키지 관리를 도와주는 npm과 pip와 같은 역할을 하는데 Helm의 경우 Pod를 구성하기 위해 필요한 모든 리소스들을(예: 서비스, 디플로이먼트, 파드 등) 패키지화 한 것이라고 생각하면 된다.
Helm Chart를 검색하는 방법은 구글에서 원하는 것 + helm chart라고 검색하면 Github 링크가 나올 것이다. 유명한 툴들은 보통 공식 github에 helm chart가 다 구성되어 있으니 이렇게 찾으면 된다.
그게 아니어도 https://artifacthub.io/ 라는 좋은 사이트에서 공식 Chart를 검색할 수 있다. 사용자들이 구성 해놓은 비공식적인 chart도 구성되어 있다.
Helm 아키텍쳐
Helm은 클라이언트-서버 아키텍처를 따른다고 한다. (v2 기준)
- Helm 클라이언트 : 사용자가 차트를 관리하기 위해 상호 작용하는 명령줄 인터페이스
- Helm 서버 (Tiller 라고도 함) : Helm 서버는 Kubernetes 클러스터에서 차트를 배포하고 관리하는 서버측 구성요소이다. Helm v3에서 부터 보안적인 문제, 구조 단순화 등의 이유로 인해 Deprecated 되었다고 한다. v3 부터는 Tiller를 통해 API Server와 통신하지 않고 Helm Client와 API Server가 직접 통신이 도입되어 추가 서버 측 구성 요소가 필요 없어졌다. 결국 v3 이후 부터는 Helm 서버는 없는 걸로 생각하면 된다.
Helm의 3가지 주요 개념
Chart
Chart는 앞서 말했듯이 하나의 특정 애플리케이션을 배포하기 위해서 Service, Deployment, Pod, Secret 등으로 사전 구성된 Kubernetes 패키지이다.
Repository
Repository는 Helm 차트를 저장하고 공유하는 저장소이다. Helm은 Public 저장소와 Private 저장소를 모두 지원한다.
Release
Release는 K8s Cluster에서 구동되는 차트 인스턴스이다. 각 Release 에는 고유한 이름이 있으며 독립적으로 업그레이드하거나 롤백할 수 있다. 일반적으로 동일한 Chart를 여러 번 설치할 수 있고 이는 새로운 Release로 관리되게 된다. Release될 때 패키지된 차트와 Config가 결합되어 정상 실행되게 된다. 예를 들어, 서로 다른 릴리스 이름으로 헬름 설치를 세 번 실행하여 세 개의 PostgreSQL 데이터베이스를 설치할 수 있다.
왜 사용하는가?
- 간소화된 배포 : Helm은 구성 가능한 매개변수가 있는 Chart에 애플리케이션 구성 요소를 캡슐화하여 복잡한 Kubernetes 배포를 단순화 한다.
- 버전 관리 및 롤백 : 차트 버전 관리(Release)를 지원하여 애플리케이션을 특정 버전으로 쉽게 롤백하거나 업그레이드할 수 있다.
- 커뮤니티 및 생태계 : Helm은 Artifact Hub 와 같은 대규모 커뮤니티와 풍부한 차트 생태계를 보유하고 있다.
Helm Chart 구조
wordpress/
Chart.yaml # A YAML file containing information about the chart
LICENSE # OPTIONAL: A plain text file containing the license for the chart
README.md # OPTIONAL: A human-readable README file
values.yaml # The default configuration values for this chart
values.schema.json # OPTIONAL: A JSON Schema for imposing a structure on the values.yaml file
charts/ # A directory containing any charts upon which this chart depends.
crds/ # Custom Resource Definitions
templates/ # A directory of templates that, when combined with values,
# will generate valid Kubernetes manifest files.
templates/NOTES.txt # OPTIONAL: A plain text file containing short usage notes
위는 wordpress 의 Helm Chart이다. 구조를 설명하기 위해 예시로 적어 놓았다.
- chart.yaml
- 이 파일은 Chart 에 대한 기본적인 정보가 있는 파일이다. Chart 명, Chart 버전, Chart 설명 등등 Chart에 대한 설명 즉, 메타데이터가 담겨 있다고 생각하면 된다.
- values.yaml
- 이 파일은 Chart에서 사용할 수 있는 매개 변수를 관리하는 파일이다. key:value 기반으로 작성된 value들은 templates 디렉토리 안에 있는 yaml 파일들의 특정 변수 값을 치환하고 싶을 때 사용하는 값을 선언해놓는 파일이다.
- charts/
- 이 디렉토리는 의존성을 관리한다. 예를 들어 DB를 사용하는 웹 애플리케이션 Chart를 만들 때 DB가 미리 구성되어야 한다면 charts/ 디렉토리에 DB에 대한 chart를 넣거나 링크를 기술하면 DB를 구성한 뒤 웹 애플리케이션을 구성하는 식의 의존성을 관리하게 된다.
- templates/
- 이 폴더가 가장 핵심적인 개념이다. 이 디렉토리 안에 애플리케이션을 구성하기 위한 Manifest 파일들이 ( Service, Deployment 등등) 위치하게 된다.
- crds/
- Custom Resource Definitions의 약자이며 CRD를 사용하면 사용자는 도메인별 개체와 해당 컨트롤러를 정의하여 동일한 Kubernetes 도구 세트와 인프라를 사용하여 이러한 리소스를 관리할 수 있습니다.
- 정확하게는 이해가 가지 않으나 기존 Chart에서 제공해주는 리소스 외에 사용자 정의 리소스를 Chart안에 포함시켜 리소스를 같이 배포할 수 있게 해주는 기능인 것 같다.
charts.yaml 예시
apiVersion: The chart API version (required)
name: The name of the chart (required)
version: A SemVer 2 version (required)
kubeVersion: A SemVer range of compatible Kubernetes versions (optional)
description: A single-sentence description of this project (optional)
type: The type of the chart (optional)
keywords:
- A list of keywords about this project (optional)
home: The URL of this projects home page (optional)
sources:
- A list of URLs to source code for this project (optional)
dependencies: # A list of the chart requirements (optional)
- name: The name of the chart (nginx)
version: The version of the chart ("1.2.3")
repository: (optional) The repository URL ("https://example.com/charts") or alias ("@repo-name")
condition: (optional) A yaml path that resolves to a boolean, used for enabling/disabling charts (e.g. subchart1.enabled )
tags: # (optional)
- Tags can be used to group charts for enabling/disabling together
import-values: # (optional)
- ImportValues holds the mapping of source values to parent key to be imported. Each item can be a string or pair of child/parent sublist items.
alias: (optional) Alias to be used for the chart. Useful when you have to add the same chart multiple times
maintainers: # (optional)
- name: The maintainers name (required for each maintainer)
email: The maintainers email (optional for each maintainer)
url: A URL for the maintainer (optional for each maintainer)
icon: A URL to an SVG or PNG image to be used as an icon (optional).
appVersion: The version of the app that this contains (optional). Needn't be SemVer. Quotes recommended.
deprecated: Whether this chart is deprecated (optional, boolean)
annotations:
example: A list of annotations keyed by name (optional).
- Chart에 대한 여러가지 정보들을 담고 있는 것을 알 수 있다.
templates/ 예시
apiVersion: apps/v1
kind: Deployment
metadata:
name: {{ .Chart.Name }}
spec:
replicas: {{ .Values.replicaCount }}
selector:
matchLabels:
app: {{ .Chart.Name }}
template:
metadata:
labels:
app: {{ .Chart.Name }}
spec:
containers:
- name: {{ .Chart.Name }}
image: "{{ .Values.image.repository }}:{{ .Values.image.tag }}"
imagePullPolicy: {{ .Values.image.pullPolicy }}
ports:
- name: http
containerPort: 80
- 보면 알겠지만 중괄호 두개로 묶여져 있는 부분이 template 파일 외 다른 파일에서 값을 불러올 때 사용하는 문법이다.
values.yaml 예시
# parentchart/values.yaml
subchart1:
enabled: true
tags:
front-end: false
back-end: true
# 또 다른 values.yaml
namespace: tks
service:
type: LoadBalancer
port: 9110
Kustomize vs Helm
Kustomize는 Kubernetes 매니페스트를 맞춤설정하기 위한 도구입니다. 이를 통해 사용자는 YAML 구성 파일을 사용하여 Kubernetes 리소스를 정의하고 관리할 수 있습니다. Kustomize는 직접적인 작업 없이 다양한 환경이나 목적에 맞게 매니페스트의 변형을 생성하는 프로세스를 단순화합니다.
Kustomize는 Kubernetes v1.14부터 기본적으로 지원되는 Kubernetes 매니페스트를 사용자 정의하기 위한 또 다른 도구이다. kustomize는 Helm과 다르게 "patch" 접근 방식을 따르므로 템플릿을 사용하는 대신 기존 매니페스트를 선언적으로 수정할 수 있다.
아래는 Helm과 Kustomize를 간략히 비교한 것이다.
- 기존 매니페스트를 선언적으로 수정하기 때문에 기존 쿠버네티스와 통합이 가능하다.
- Helm 보다 사용에 훨씬 용이하다.
- Helm은 Template 기반으로 접근하나 kustomize는 Overlay 기반으로 접근하게 됨
- 여기서 Overlay란 기존에 존재하는 기본 구성을 수정하지 않고도 매니페스트를 사용자 정의하거나 확장하는 방법을 제공하는 것을 의미함. 오버레이는 별도의 디렉토리로 구성되게 되며, 공통 기반에서 다양한 환경 (dev, staging, prod)의 여러 구성을 생성할 수 있다고 함
- Overlay에 대한 개념은 조금 더 확인이 필요함!
- Helm은 패키징화 하여 패키지만 사용해 설정을 구성하나 Kustomize는 기존의 매니페스트에 patch 하는 개념이라 기존 매니페스트가 필수적으로 필요함
- Helm은 Release라는 개념을 이용해 버전 관리 및 롤백이 손쉬우나 kustomize는 어려움
- 구체적인 내용은 https://wookiist.dev/159 링크에서 확인 가능하다. 해당 글의 필자는 kustomize를 왜 쓰는지는 알겠으나, Helm을 사용하는 것을 더 추천했다.
3줄 요약
- Helm은 Chart라는 패키지 형식을 통해 쿠버네티스의 패키지 관리를 도와준다. 여기서 패키지 관리라 함은 미리 정의된 매니페스트 파일과 매개 변수 등의 파일들로 하나의 애플리케이션을 배포하고 버전 관리를 Helm이라는 도구를 이용하면 손쉽게 할 수 있다는 뜻
- Helm은 Chart, Repository, Release 라는 구성요소를 갖고 있으며, Chart는 chart.yaml, values.yaml, templates/, charts/ 를 이용해 리소스를 구성한다.
- kustomize는 helm과 다르게 선언적으로 리소스를 patch 하는 형태로 수정함.
내 생각
생각보다 어려워서 배우고 사용하는 데 러닝 커브가 있을 것 같다. Chart를 그대로 사용할 때에는 문제가 없을 것 같은데 내 환경에 맞게끔 수정해서 사용하려고 한다면 조금 골치아프지 않을까 생각한다.. 아직 쿠버네티스도 잘 알지 못해서 쿠버네티스에 대한 공부를 하면서 Helm도 같이 공부하다보면 이해도가 높아질 것 같다. 다음엔 helm을 직접 사용해보면서 설치방법 또는 명령어도 정리해보고자 한다.
[참조] :
https://www.logicmonitor.com/blog/what-is-helm-in-kubernetes
https://medium.com/@sushantkapare1717/helm-vs-kustomize-in-kubernetes-cc063bbb4b0e
https://spacelift.io/blog/kustomize-vs-helm
https://devocean.sk.com/blog/techBoardDetail.do?ID=163262
https://blog.naver.com/alice_k106/221579974362
'Containers > Kubernetes' 카테고리의 다른 글
Karpenter란? (0) | 2024.05.23 |
---|