스테이트풀셋 on Kubernetes

가시다(서종호) 님 KANs 중간 과제로 스테이트풀셋을 쿠버네티스에 사용한 사례를 공유합니다.

 

https://gasidaseo.notion.site/c9cd413265ea4ea1b1ae38eb36dfda94 

쿠버네티스 네트워킹 스터디 [모집 마감]

 

Stateless 한 웹/App 서버 등은 쿠버네티스에 많이 사용하는 것 같은데 일부는 아직 Stateful(데이터를 가지는)한 데이터베이스 등은 아직 쿠버네티스를 사용하지 않는 것 같다. 필자는 20년 1월 외부 프로젝트 경험으로 MariaDB 갈레라 클러스터를 쿠버네티스를 성공적으로 마이그레이션하고 이 후 전체 Stateful 애플리케이션을 쿠버네티스에서 잘 사용하고 있다. Redis, 카프카, MQTT, Elastic, RabbitMQ 등 데이터를 가지는 다양한 애플리케이션을 올렸고 현재까지 무장애이다.

 

크게 하드웨어, 애플리케이션, 스토리지, 네트워크 설정으로 나누어서 설정 내역을 공유한다.

 

하드웨어 구성

• 물리 노드 구성은 서비스 중요도에 따라 베어메털 4대, 또는  VM 3~4대 등으로 구성하였다. 메모리는 128~512G 등 비교적 넉넉하게 주었고 Disk 역시 중요도에 따라 SSD or NVMe로 나누고, 네트워크는 노드 간 데이터 복제를 고려하여 10G 환경이다.

애플리케이션 설정

• 전체 Helm 차트를 사용 중이다.
  최초 MariaDB 10.1.x 버전은 공식 헬름 차트와 해당 버전의 컨테이너 이미지가 동료가 기본 CentOS 이미지부터 수동으로 DB 설치하고 갈레라 관련 스크립트를 작성하는 고생을 하였다. (정말 고생이 심했다.) 하지만 이제 (아마도) 전체 애플리케이션은 이미지는 물론 벤더 또는 커뮤니티, Bitnami 사에서 관련 헬름 차트를 제공한다. 이미 공개된 헬름 차트를 로컬에 다운(helm pull)받고 템플릿 변수 파일 copy(cp values.yaml my-values.yam)해서 필요한 설정을 변경 후 애플리케이션을  실행하면 큰 어려움없이 애플리케이션 정상적으로 작동된다. 엄청 편리하다. 컨테이너의 가장 큰 장점인 이식성이 빛을 발하는 순간이다.
  
  
• 헬름 차트 베스트 프랙티스
  헬름 차트는 베스트 프랙티스 기반이라 보안, 안정성 등에서 이미 검증된 설정을 제공한다. 공식 가이드에 따라 템플릿 변수 파일만 각 환경에 맞게 수정한다. 각 설정의 특성을 잘 이해해서 잘 변경하는 것이 실력이다. 애플리케이션 담당자와 함께 적절한 수정을 한다. 필자는 StorageClass를 openebs-hostpath로 변경해서 사용 중이다.

스토리지 설정 

• 아마도 다른 사용자와 다르게 특이하면 특이한게 로컬 디스크를 사용하는 OpenEBS-hostpath를 이용하고 있는 것일 것이다. STS 볼륨으로 노드의 로컬 디스크를 사용 중이다. 

from: https://openebs.io/docs/#what-does-openebs-do 

 

OpenEBS 사이트에서 권고한대로 애플리케이션 단에서 볼륨 복제 구성을 지원하는 환경이라 로컬 디스크를 서비스에 사용 중이다.

OpenEBS hostpath 관련 설명
Local Volumes are accessible only from a single node in the cluster. Pods using Local Volume have to be scheduled on the node where volume is provisioned. Local Volumes are typically preferred for distributed workloads like Cassandra, MongoDB, Elastic, etc that are distributed in nature and have high availability built into them.

단점으로 노드가 다운되면 해당 서비스가 다운되므로 많은 사람들이 서비스 안정성 때문에 사용하지 않는다고 한다. 하지만 애플리케이션 레벨에서 데이터는 분산된다. 예를 들어 마리아DB 갈레라 클러스터는 3 Copy 구성되어 단일 노드가 다운되어도 전체 서비스는 문제가 없다. 특정 노드가 다운되면 1) 해당 노드가 리부팅되어 멤버로 다시 조인하거나 2) 새로운 노드가 기존 노드의 데이터와 데이터 sync 작업을 하므로 다시 HA 구성이 가능하다.

• 장점은 로컬 디스크를 사용하므로 외부 스토리지 사용에 따른 네트워크 및 분산 파일 시스템 구성에 따른 오버헤드가 없어 성능이 월등하다. (셰프 대비 약 5배 이상 IOPS 차이났다. 4k read 기준) 단순한 구성이라 장애 포인트도 줄어들며 추가 스토리지 비용이 없어 당연히 경제적이다.
  
  
• 외부 NAS 스토리지는 저렴한 걸로 구성해서(이것도 rook-nfs 사용하면 되지만) 백업 용도로만 사용했다. 백업은 별도의 파드를 실행하고 kubectl exec -it - mysqldump 명령어로 원격 나스 스토리지에 크론잡으로 백업을 내리는 방법으로 실행하고 있다.

네트워크 설정

• 별다른 설정없이 노드 간 데이터 복제가 필요해서 10G(single or 2 port teaming) 구성했다. CNI는 기본 칼리코 & IPIP 모드 설정이다. 일부는 디아만티(쿠버네티스 어플라이언스)도 사용 중인데 디아만티는 SR-IOV 구성이 가능하여 성능이 뛰어나고 전용 스토리지 네트워크(nvme-over-ethernet) 사용이 강점이다.

 

쿠버네티스 환경에 스테이트풀셋한 애플리케이션을 사용하려는 분들에게 작은 도움이 되었으면 한다.

 

추가로 로키, 프로메테우스 등 단일 디스크 구성은 노드 간 데이터 복제를 지원하는 openebs-maya stor 등을 사용하는지 로컬 디스크를 raid-6 n-2 redundant 구성을 하는 것도 고려하고 있다.