본문 바로가기
AWS Cloud School 8기/쿠버네티스

[쿠버네티스] 헬름(Helm)

by YUNZEE 2025. 4. 23.
728x90

🎯 Helm이란?

- apt가 우분투 리눅스 패키지 관리자라며 helm은 쿠버네티스 매니페스트 패키지 관리자

- 패키지(레포지토리) 매니저 역할을 하는 Helm

- 쿠버네티스에서 애플리케이션을 쉽게 배포하고 관리할 수 있게 해주는 패키지 관리자임

-> 마치 리눅스에서 apt, yum, brew로 패키지 설치하는 것처럼 helm로 복잡한 쿠버네티스 리소스를 할 번에 배포할 수 있음

📦 Helm을 왜 사용하는가?

- 쿠버네티스에서는 보통 yaml파일을 여러 개 만들고 실행했음

  • deployment.yml
  • service.yml
  • configmap.yml
  • ingress.yml
  • ...

- 이걸 다 Helm은 이런 걸 하나로 묶어서, 버전 관리, 템플릿화, 업데이트/ 삭제/ 롤백까지 가능

- 헬름차트도 결국 매니페스트의 묶음을 잘 정의해 두고 그 차트로 여러 개의 앱을 변수 조절만 살짝 해서 여러 개 찍어낼 수 있음

 

처음 시작 트러블슈팅

더보기

kubectl delete pod --all

# 모든 pod 삭제

kubectl run test1 --image=public.ecr.aws/docker/library/nginx:alpine

kubectl run test2 --image=public.ecr.aws/docker/library/nginx:alpine

kubectl create deploy test --replicas=2 --image=public.ecr.aws/docker/library/nginx:alpine

 - 연결 확인하기

 실습 시작

더보기

https://artifacthub.io/packages/search?ts_query_web=nginx&sort=relevance&page=1

- 레포지토리의 주소

- 엔지넥스가 bitnami이라는 레포지토리에 있다는 걸 확인했음

- 가장 중요함

- 수정할 수 있는 내용을 볼 수 있음

 

values 스키마: 헬름을 다룰 때 제일 많이 봐야 하는 곳.

- 헬름제작자의 의도가 담겨있음.

- 보통은 매니페스트의 형식을 따라가긴 하지만, 

- 위와 같이 기존의 매니페스트 형식(replicas: 2)을 따르지 않을 수도 있음

root@master:~/mani/selector# cd ..

root@master:~/mani# mkdir helm

root@master:~/mani# cd helm/

root@master:~/mani/helm#

curl -fsSL -o get_helm.sh https://raw.githubusercontent.com/helm/helm/main/scripts/get-helm-3

- 레포를 추가한 적이 없기 때문에 없음

 - 내가 설치하고 싶은 차트를 검색해서, 해당 차트를 포함하는 레포를 추가

helm repo add bitnami https://charts.bitnami.com/bitnami

- 해당 경로의 레포지토리를 bitnami라는 이름으로 내 레포지토리 목록에 추가.

- 레포 추가 후에는 되도록이면 helm repo update를 통해 차트 목록을 업데이트

helm search repo nginx

- 차트검색. nginx라는 문구가 포함된 차트가 있는지, 내 레포지토리 리스트에서 확인.

root@master:~/mani/helm# helm install mynginx bitnami/ngin

root@master:~/mani/helm# helm install mynginx <릴리스 이름> bitnami/nginx <레포/차트>

- 차트에 있는 template(매니페스트들)을 apply 했다고 보면 좋음

- 릴리스의 이름으로 생성된 리소스들

helm inspect values bitnami/nginx

- values : 헬름의 변수를 모아놓은 파일.

- 디폴값은 이미 정의되어 있음

- 우리가 필요한 값을 명시하면 명시한 값이 먼저 반영된다.

helm inspect values bitnami/nginx > nginx-values.yml

- 밸류값을 nginx-values.yml 이름으로 추출.

- Helm을 사용할 때 굉장히 자주 쓰는 "차트 설정값 확인 + 저장" 명령어

 

root@master:~/mani/helm# helm uninstall mynginx
release "mynginx" uninstalled

- 릴리스 삭제


root@master:~/mani/helm# vi my-values.yml

- 나는 현재 서비스타입을 로드밸런서가 아니라, 노드포트로 변경하고 싶음

- 필요한 부분만 벨류파일로 만들면 됨

- 딱 두 줄만 추가해 보자.

 

NodePort와 LoadBalancer의 차이

NodePort: 노드 IP + 지정된 포트로 접근

-> 클러스터의 각 노드에 외부 포트(예: 30080)를 열어놓고, NodeIP: Port 형식으로 접근하는 방식

LoadBalancer: 외부 클라우드 IP 따로 할당

-> 클라우드에서 제공하는 외부 IP를 가진 로드밸런서를 자동으로 붙여주는 방식

 

+ Ingress: 다수의 서비스 라우팅

- 도메인 또는 경로 기반 접근

- IP 1개로 여러 서비스 사용 가능

 

root@master:~/mani/helm# helm install node-nginx bitnami/nginx -f my-values.yml 

- node-nginx라는 릴리스를 설치할 건데, 이번에는 밸류 파일을 디폴트가 아니라, 내가 만든 파일을 지정하겠음

kubectl delete ns ingress-nginx

--force --grace-period=0

- 강제로 지우는 옵션. --force=강제, --grace-period=0 기다리지 않겠다.\

 

kubectl delete ns ingress-nginx --force --grace-period=0

 

kubectl create ns ingress

- 네임스페이스 생성

helm install ingress-controller bitnami/nginx-ingress-controller -n ingress

- 네임스페이스 지정해서 릴리스 생성

오류/ 해결 방안-1

더보기

- 기존에 존재하는 잉그리스클래스 때문에 설치가 안된 거였음

- 그래서 삭제해 주고 다시 명령어를 실행시켜 주면

 - 오류가 안 생기고 잘 생성되는 걸 확인할 수 있음

- 모든 네임스페이스의 '릴리스' 확인

다시 이어서 시작

helm uninstall node-nginx

- 릴리스 삭제

실습 2) 

bitnami/apache

이 차트로 myhttpd라는 릴리스를 구성하되 apache-values.yml 파일로 밸류 파일을 생성하고, 이 밸류 파일을 수정하여 서비스의 타입을 로드밸런서로 생성해 보세요.

더보기

root@master:~/mani/helm# helm install myhttpd bitnami/apache

- 차트를 Helm으로 설치했고

root@master:~/mani/helm# helm inspect values bitnami/apache

 

root@master:~/mani/helm# helm inspect values bitnami/apache > apache-values.yml

# 이미지를 수정

vi apache-values.yml

helm install apa bitnami/apache -f apache-values.yml

helm upgrade apa bitnami/apache -f apache-values.yml

- 변경사항 반영

helm pull bitnami/apache

- 차트 다운로드

tar -xvf apache-11.3.5.tgz

- 압축해제

 

helm install mynginx bitnami/nginx --set=service.type=NodePort

- value 파일을 구성하는 대신 --set 옵션으로는 릴리스를 띄울 수 있음

 

실습 3)

values 파일을 통해

 

dev-values.yml

에는 61.254.18.30:5000/bitnami/apache:latest 앱을 ClusterIP로 배포.

stg-values.yml

에는 61.254.18.30:5000/bitnami/apache:latest 앱을 ingress를 통해 /apache 경로에 배포.

더보기

root@master:~/mani/helm# vi dev-values.yml

service:
  type: ClusterIP
# 외부에 배포할 필요가 없다.
global:
  security:
    allowInsecureImages: true
image: 
  registry: 61.254.18.30:5000
  tag: latest  
# 변경사항이 생긴부분만 수정


root@master:~/mani/helm# vi stg-values.yml

service:
  type: LoadBalancer
# 외부에 배포할 필요가 없다

global:
  security:
    allowInsecureImages: true
image: 
  registry: 61.254.18.30:5000
  tag: latest  
# 변경사항이 생긴부분만 수정

 

helm install dev-nginx bitnami/apache -f dev-values.yml

실습 4) 

bitnami/wordpress 차트를 분석해서 mywp라는 릴리스를 생성하여 접속되게 만들어보세요. wordpress와 mysql로 구성된 차트일 듯.

<다이나믹 프로비저너가 설치되어있어야 함>

1. values.yaml파일을 inspect 해서 하거나,

2. 차트를 다운로드해서 분석해도 괜찮고

3. --set 옵션을 써도 무방.

더보기

root@master:~/mani/helm# vi wp-values.yaml 

global:
  defaultStorageClass: "sc-fast" # 본인의sc에 맞게.
  imageRegistry: "61.254.18.30:5000"
  security:
    allowInsecureImages: true

- 필요한 부분만 수정

 

sc-fast 부분 

kubectl get storageclass

- 전에 실습에서 만들었기 때문에 있었음

kubectl delete pv,pvc --all

- 혹시 모르니 기존의 pv, pvc를 삭제.

- 기존의 찌꺼기에 볼륨구성이 되면 그것 때문에 안될 수도 있음.

 

*Provisioning이슈로 안된 경우가 많았음

-> 먼저 쿠버네티스에서 Storage(PersistentVolume)를 자동 혹은 수동으로 생성하는 과정을 의미함

- pv란 자동 혹은 수동으로 생성하는 과정임

- helm으로 wp 같은 앱을 설치할 때

- 내부적으로 PVC(PersistentVolumeClaim)를 만들게 되는데- 이걸 처리하려면 실제 PV(스토리지 볼륨)가 자동으로 프로비저닝 됨

 

- PVC가 삭제되면 PV와 실제 데이터도 자동 삭제됨

root@master:~/mani/helm# helm install mywp bitnami/wordpress -f wp-values.yaml 

 

 

728x90