Helm Chart와 StorageClass, PVC

Helm Chart는 쿠버네티스 리소스를 한 번에 설치하기 위한 템플릿 묶음이다.
MySQL Chart 안에는 보통 StatefulSet과 PVC 템플릿이 같이 들어있다.

이때 values.yaml에 persistence.storageClass만 지정해두면, 설치 과정에서 다음 흐름이 자동으로 일어나

  • Helm이 템플릿에 값을 주입한다
  • StatefulSet이 생성된다
  • StatefulSet의 volumeClaimTemplates가 동작한다
  • PVC가 자동 생성된다
  • PVC가 StorageClass를 보고 PV를 동적 프로비저닝한다
  • PV가 실제 스토리지를 준비한다
  • Pod가 그 PV를 마운트하고 MySQL 데이터 디렉터리를 거기에 쓴다

즉, Helm은 직접 PV를 만드는 게 아니라 PVC가 만들어지게끔 YAML을 찍어주는 역할이다. 실제 PV 생성은 StorageClass와 프로비저너가 하게 된다.

bitnami/mariadb 차트

cf. 원래는 bitnami/mysql 차트를 설치하려 했으나, bitnami/mysql 차트는 arm 아키텍처를 미지원하여 bitnami/mariadb 차트를 설치하였다.

helm search repo mariadb로 차트를 찾고, helm pull bitnami/mariadb로 내려받아 압축을 푼다. 그리고 values.yaml을 편집해서 설치 옵션을 변경해준다.

repo에서 바로 helm install bitnami/mysql --set ...도 가능하지만, 옵션이 많아지면 --set은 관리하기가 힘들어진다.

 

따라서, values.yaml을 복사해서 my-values.yaml로 만들고 필요한 부분만 수정한다.

helm search repo mariadb
helm pull bitnami/mariadb
tar xvzf mariadb-24.0.3.tgz
mv mariadb mariadb-24.0.3
cd mariadb-24.0.3/
cp values.yaml my-values.yaml
vi my-values.yaml
architecture: replication

auth:
  rootPassword: "rootpass123"
  replicationPassword: "replpass123"

primary:
  persistence:
    enabled: true
    storageClass: "openebs-hostpath"
    size: 10Gi

secondary:
  replicaCount: 1
  persistence:
    enabled: true
    storageClass: "openebs-hostpath"
    size: 10Gi

[architecture: replication]

MariaDB를 단일 Pod가 아니라 복제 구조로 만든다.

  • mariadb-primary-0 (쓰기 담당)
  • mariadb-secondary-0 (복제 읽기)

즉, StatefulSet이 2개 Pod를 만든다.

 

[persistence.storageClass]

primary Pod가 PVC를 만들 때, openebs-hostpath StorageClass로 PV를 만든다는 의미이다.

secondary도 동일하다. 그래서 PVC가 2개 생성된다.

Helm Chart 설치

먼저 mysql 리소스가 위치 할 네임스페이스를 생성해준다.

kubectl create ns mariadb
kubectl ns mariadb

다음 명령어를 통해 helm을 설치해준다.

helm install mysql -f my-values.yaml .

다음 명령어를 통해 차트가 정상적으로 설치되었는지 확인한다.

helm list

또한 리소들이 정상적으로 생성됐는지 확인한다.

kubectl get all -o wide
kubectl get pvc

위와 같이 정상적으로 리소스들이 생성된 것을 확인할 수 있다.

Helm 차트 삭제

이제 테스트가 끝나, helm delete mariadb을 하면 Pod는 사라지는데 PVC는 그대로 남게된다.

이건 데이터 보호를 위해 의도적으로 그렇게 설계되는 경

  • 애플리케이션을 지운다고 데이터까지 자동 삭제되면 운영에서 사고가 난다
  • 업그레이드, 재설치, 롤백을 해도 데이터는 유지되어야 한다

그래서 차트 설계상 PVC는 기본적으로 남겨두는 패턴이 흔하다.
그래서 helm delete 후에 kubectl get pvc를 하면 Bound인 PVC가 그대로 보인다.

PVC를 없애려면 쿠버네티스 리소스를 직접 삭제해야 한다.

  • kubectl delete pvc <이름>
  • 또는 kubectl delete pvc --all -n mysql을 사용한다.

 OpenEBS 장점

OpenEBS hostpath는 이름 그대로 노드 로컬 디렉터리를 PV로 잡아주는 방식이다.

따라서 다음과 같은 장점이 존재한다.

  • 네트워크 스토리지를 안 타서 지연이 적다
  • 구성 방식이 단순하다
  • 로컬 디스크 IOPS가 잘 나오면 성능이 매우 좋다

OpenEBS 제약

hostpath는 데이터가 특정 노드에 저장된다.

즉, PVC가 어떤 노드의 디렉터리를 가리키는 구조가 된다.

 

그래서 다음 문제가 발생할 수 있어서 주의해야 한다.

  • Pod가 다른 노드로 옮겨가면 기존 데이터 위치에 접근을 못 한다
  • 그 결과 Pod가 뜨지 못하고 Pending에 머무를 수 있다
  • Stateful 앱은 서비스 장애가 된다

정리

  • Helm에서 StorageClass를 지정하면 PVC 생성이 자동화된다
  • OpenEBS hostpath를 StorageClass로 쓰면 성능과 단순성은 좋다
  • 하지만 노드 고정이라는 제약 때문에 장애/유지보수 시 문제가 커진다
  • 그래서 운영 환경에서는 데이터베이스 자체의 복제 구조를 더 강하게 하거나, Ceph 같은 분산 스토리지로 해결하는 선택을 한다

Reference

 

 

티스토리툴바