쿠버네티스 영구 스토리지, 왜 이렇게 어렵냐고요

쿠버네티스(Kubernetes)로 처음 스테이트풀(Stateful) 애플리케이션을 올려본 분들이라면 공감하실 텐데요. 컨테이너는 죽었다 살아나는 게 당연한 세계인데, 데이터는 절대 사라지면 안 되잖아요. 데이터베이스, 메시지 큐, 로그 수집기… 이런 것들을 올리려면 결국 쿠버네티스 영구 스토리지(Persistent Storage) 문제를 해결해야 합니다.

저도 처음 홈랩에서 쿠버네티스 클러스터를 구성할 때 이 부분에서 꽤 오래 고민했거든요. NFS 마운트로 버티다가 결국 제대로 된 분산 스토리지를 써야겠다 싶어서 Longhorn이랑 Rook Ceph를 둘 다 실제로 구성해봤습니다. 오늘은 그 경험을 바탕으로 두 솔루션을 비교하고, 어떤 상황에서 뭘 선택해야 하는지 정리해 드릴게요.

▲ 쿠버네티스 영구 스토리지의 전체 구조 — PVC(Persistent Volume Claim)가 어떻게 실제 스토리지 백엔드와 연결되는지 보여주는 아키텍처 다이어그램

먼저 개념부터: PV, PVC, CSI가 뭔가요?

비교 얘기 전에 기본 개념을 짚고 넘어가겠습니다. 저도 처음엔 이 용어들이 다 비슷비슷해 보여서 헷갈렸거든요 ㅎㅎ

• PV (Persistent Volume, 영구 볼륨): 클러스터 관리자가 프로비저닝한 실제 스토리지 리소스입니다. 쉽게 말해 “실제 저장 공간”이에요.
• PVC (Persistent Volume Claim, 영구 볼륨 클레임): 개발자(또는 파드)가 스토리지를 요청하는 오브젝트입니다. “나 10GB짜리 저장 공간 필요해요”라고 요청하는 거죠.
• StorageClass (스토리지 클래스): 스토리지의 종류와 프로비저닝 방식을 정의합니다. PVC가 요청하면 자동으로 PV를 만들어주는 동적 프로비저닝(Dynamic Provisioning)을 가능하게 해줘요.
• CSI (Container Storage Interface, 컨테이너 스토리지 인터페이스): 쿠버네티스가 다양한 스토리지 벤더와 통신하기 위한 표준 인터페이스입니다. Longhorn도, Rook Ceph도 이 CSI 드라이버를 통해 쿠버네티스와 연동돼요.

💡 핵심 포인트: 개발자는 PVC만 선언하면 되고, 실제 스토리지가 어디에 있는지는 신경 안 써도 됩니다. 그 복잡한 연결을 StorageClass와 CSI 드라이버가 처리해주거든요.

Longhorn 소개: CNCF가 인정한 경량 분산 스토리지

Longhorn은 Rancher(현재 SUSE 산하)에서 개발한 쿠버네티스 전용 분산 블록 스토리지입니다. CNCF(Cloud Native Computing Foundation) 졸업 프로젝트로 등록되어 있고, 오픈소스이면서 완전히 쿠버네티스 네이티브하게 설계됐어요.

Longhorn의 주요 특징

• 쿠버네티스 위에서 동작하는 컨트롤러 기반 아키텍처
• 볼륨 복제본(Replica)을 여러 노드에 자동 분산
• 내장 UI 대시보드 — 볼륨 상태를 시각적으로 확인 가능
• 스냅샷(Snapshot) 및 백업 기능 내장 (S3, NFS 등으로 백업 가능)
• 볼륨 확장(Volume Expansion) 지원
• RWO(ReadWriteOnce) 지원, RWX(ReadWriteMany)는 NFS 게이트웨이를 통해 제한적으로 지원

Longhorn 설치 — Helm으로 빠르게

실제로 설치해보겠습니다. 저는 k3s 기반 3노드 클러스터에서 테스트했어요.

# 사전 요구사항 확인 (iscsi 패키지 필요)
sudo apt-get install -y open-iscsi
sudo systemctl enable --now iscsid

# Helm 저장소 추가
helm repo add longhorn https://charts.longhorn.io
helm repo update

# longhorn 네임스페이스 생성 및 설치
helm install longhorn longhorn/longhorn \
  --namespace longhorn-system \
  --create-namespace \
  --set defaultSettings.defaultReplicaCount=3

설치가 완료되면 longhorn-system 네임스페이스에 여러 파드가 뜨는 걸 확인할 수 있어요.

kubectl get pods -n longhorn-system
# NAME                                        READY   STATUS    RESTARTS
# longhorn-manager-xxxxx                      1/1     Running   0
# longhorn-driver-deployer-xxxxx              1/1     Running   0
# longhorn-ui-xxxxx                           1/1     Running   0
# engine-image-ei-xxxxx-xxxxx                 1/1     Running   0

Longhorn UI에 접근하려면 포트 포워딩이나 인그레스(Ingress, 외부 트래픽 진입점)를 설정해야 합니다.

kubectl port-forward -n longhorn-system svc/longhorn-frontend 8080:80

브라우저에서 http://localhost:8080으로 접속하면 볼륨 상태, 노드 디스크 현황을 한눈에 볼 수 있는 대시보드가 나옵니다. 이거 처음 봤을 때 진짜 편하다 싶었어요.

Longhorn StorageClass 및 PVC 생성 예시

apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
  name: longhorn
provisioner: driver.longhorn.io
allowVolumeExpansion: true
parameters:
  numberOfReplicas: "3"
  staleReplicaTimeout: "2880"
  fromBackup: ""
  fsType: "ext4"
---
apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: my-longhorn-pvc
spec:
  accessModes:
    - ReadWriteOnce
  storageClassName: longhorn
  resources:
    requests:
      storage: 10Gi

Rook Ceph 소개: 엔터프라이즈급 분산 스토리지

Rook은 Ceph를 쿠버네티스에서 오퍼레이터(Operator) 패턴으로 운영할 수 있게 해주는 프레임워크입니다. Ceph 자체는 수십 년의 역사를 가진 검증된 분산 스토리지 시스템이고, Rook은 그 복잡한 Ceph를 쿠버네티스 위에서 쉽게(?) 운영하게 해주죠.

솔직히 말하면 “쉽게”라는 말에 따옴표를 붙인 이유가 있어요. 처음 Rook Ceph 설치할 때 삽질을 꽤 했거든요 ㅎㅎ

Rook Ceph의 주요 특징

• 블록 스토리지(RBD), 파일시스템(CephFS), 오브젝트 스토리지(S3 호환 RGW) 모두 지원
• CephFS를 통한 RWX(ReadWriteMany) 네이티브 지원 — 여러 파드가 동시에 같은 볼륨 마운트 가능
• PG(Placement Group), CRUSH Map 등 고급 튜닝 옵션
• 대규모 클러스터에서 검증된 안정성
• Ceph Dashboard 내장
• 최소 3개 OSD(Object Storage Daemon) 노드 권장

Rook Ceph 설치 — 조금 더 복잡합니다

# Rook 오퍼레이터 설치
git clone --single-branch --branch v1.13.0 https://github.com/rook/rook.git
cd rook/deploy/examples

# CRD 및 공통 리소스 먼저 설치
kubectl create -f crds.yaml
kubectl create -f common.yaml

# 오퍼레이터 배포
kubectl create -f operator.yaml

# 오퍼레이터 파드 확인
kubectl get pods -n rook-ceph
# NAME                                  READY   STATUS    RESTARTS
# rook-ceph-operator-xxxxx              1/1     Running   0

오퍼레이터가 Running 상태가 되면 Ceph 클러스터를 생성합니다. 아래는 기본 클러스터 설정이에요.

apiVersion: ceph.rook.io/v1
kind: CephCluster
metadata:
  name: rook-ceph
  namespace: rook-ceph
spec:
  cephVersion:
    image: quay.io/ceph/ceph:v18.2.0
  dataDirHostPath: /var/lib/rook
  mon:
    count: 3
    allowMultiplePerNode: false
  mgr:
    count: 2
  dashboard:
    enabled: true
    ssl: true
  storage:
    useAllNodes: true
    useAllDevices: false
    deviceFilter: "^sd[b-z]"
  resources:
    mgr:
      requests:
        cpu: "500m"
        memory: "512Mi"

⚠️ 주의사항: deviceFilter 설정이 중요합니다. 잘못 설정하면 OS 디스크까지 Ceph OSD로 사용하려고 할 수 있어요. 저도 이 부분에서 한 번 아찔한 경험을 했습니다. 반드시 데이터 디스크만 지정하세요.

# Ceph 블록 스토리지 풀 및 StorageClass 생성
kubectl create -f csi/rbd/storageclass.yaml

# CephFS (RWX 지원) StorageClass 생성
kubectl create -f filesystem.yaml
kubectl create -f csi/cephfs/storageclass.yaml

▲ Rook Ceph 아키텍처 — MON(모니터), MGR(매니저), OSD(오브젝트 스토리지 데몬)의 구성과 CSI 드라이버를 통한 쿠버네티스 연동 구조

Longhorn vs Rook Ceph: 직접 써본 비교

두 솔루션을 실제로 운영해보면서 느낀 점들을 솔직하게 비교해 드릴게요.

실제로 겪은 트러블슈팅 사례들

Longhorn에서 겪은 문제: 노드 한 대를 재부팅했더니 해당 노드의 복제본이 degraded 상태가 됐어요. 근데 이건 Longhorn이 자동으로 다른 노드에 복제본을 재빌드해주더라고요. 시간이 좀 걸리긴 했지만 데이터 손실은 없었습니다. ✅

Rook Ceph에서 겪은 문제: OSD 디스크 하나에 파티션이 남아있었는데, Rook이 해당 디스크를 인식 못 하는 문제가 있었어요. 이게 처음엔 왜 안 되는지 몰라서 꽤 삽질했습니다.

# OSD 디스크 초기화 — 기존 파티션 제거
sgdisk --zap-all /dev/sdb
dd if=/dev/zero of=/dev/sdb bs=1M count=100 oflag=direct
blkdiscard /dev/sdb

# 파티션 확인
lsblk /dev/sdb

⚠️ 경고: 위 명령어는 해당 디스크의 모든 데이터를 완전히 삭제합니다. 반드시 올바른 디스크를 지정했는지 확인하고 실행하세요.

또 Ceph 클러스터 상태가 HEALTH_WARN으로 뜰 때 원인 파악하는 방법도 알아두면 좋아요.

# Ceph 상태 확인
kubectl exec -n rook-ceph -it deploy/rook-ceph-tools -- ceph status
kubectl exec -n rook-ceph -it deploy/rook-ceph-tools -- ceph health detail

# OSD 상태 확인
kubectl exec -n rook-ceph -it deploy/rook-ceph-tools -- ceph osd status

▲ Longhorn 대시보드 — 볼륨 상태, 노드별 복제본 분산 현황, 백업 상태를 한눈에 모니터링하는 화면

어떤 상황에서 뭘 선택해야 할까요?

이게 결국 핵심 질문이잖아요. 저는 이렇게 기준을 잡아드리고 싶어요.

Longhorn을 선택하세요, 만약…

• ✅ 홈랩이나 소규모 클러스터(노드 3~5개 이하)를 운영한다면
• ✅ 쿠버네티스 스토리지를 처음 도입하는 팀이라면
• ✅ 운영 인력이 부족하고 관리 부담을 최소화하고 싶다면
• ✅ 블록 스토리지(RWO) 위주로만 사용한다면
• ✅ 백업/복구 기능을 간편하게 쓰고 싶다면
• ✅ 빠르게 구성해서 바로 써야 하는 상황이라면

Rook Ceph를 선택하세요, 만약…

• ✅ 중대형 클러스터(노드 5개 이상)를 운영한다면
• ✅ RWX(ReadWriteMany) 볼륨이 반드시 필요하다면
• ✅ S3 호환 오브젝트 스토리지도 함께 필요하다면
• ✅ 전담 인프라 운영 인력이 있다면
• ✅ 엔터프라이즈 환경에서 검증된 기술 스택이 필요하다면
• ✅ 고가용성과 세밀한 스토리지 정책 제어가 필요하다면

둘 다 쓰는 경우도 있어요

실제로 일부 팀에서는 일반적인 파드 스토리지는 Longhorn으로, RWX가 필요한 공유 파일시스템이나 오브젝트 스토리지는 Rook Ceph로 나눠서 운영하기도 합니다. 복잡해지긴 하지만 각각의 장점을 활용할 수 있는 방법이기도 해요.

결과 검증: 실제로 제대로 동작하는지 확인하기

설치만 하면 끝이 아니죠. 실제로 데이터가 잘 보존되는지 확인해봐야 합니다. 아래는 간단한 테스트 시나리오예요.

# 테스트용 파드 생성
apiVersion: v1
kind: Pod
metadata:
  name: storage-test
spec:
  containers:
  - name: test
    image: busybox
    command: ["/bin/sh", "-c", "while true; do date >> /data/test.log; sleep 5; done"]
    volumeMounts:
    - mountPath: /data
      name: test-volume
  volumes:
  - name: test-volume
    persistentVolumeClaim:
      claimName: my-longhorn-pvc

# 파드 실행 후 데이터 확인
kubectl exec storage-test -- cat /data/test.log

# 파드를 강제 삭제
kubectl delete pod storage-test

# 새 파드로 다시 마운트해서 데이터가 남아있는지 확인
kubectl apply -f storage-test.yaml
kubectl exec storage-test -- cat /data/test.log
# 이전 로그가 그대로 남아있으면 성공! 🎉

🎉 데이터가 살아있는 걸 확인했을 때의 그 안도감… 처음엔 진짜 설레더라고요. 쿠버네티스에서 영구 스토리지가 제대로 동작한다는 걸 눈으로 확인한 순간이었습니다.

추가로 볼륨 상태도 확인해두면 좋아요.

# PVC 상태 확인
kubectl get pvc
# NAME               STATUS   VOLUME                                     CAPACITY   ACCESS MODES   STORAGECLASS   AGE
# my-longhorn-pvc    Bound    pvc-xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx   10Gi       RWO            longhorn       5m

# PV 상세 정보
kubectl describe pv pvc-xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx

▲ Longhorn vs Rook Ceph 선택 가이드 요약 — 클러스터 규모, 기능 요구사항, 운영 복잡도를 기준으로 한 비교 인포그래픽

자주 묻는 질문 (FAQ)

Q. Longhorn은 프로덕션 환경에서 써도 되나요?

네, CNCF 졸업 프로젝트이고 실제로 많은 기업에서 프로덕션에 사용하고 있습니다. 다만 대규모 클러스터나 높은 I/O가 필요한 환경에서는 Ceph 대비 한계가 있을 수 있어요.

Q. Rook Ceph 최소 사양이 어떻게 되나요?

OSD 노드 최소 3개를 권장합니다. 각 OSD 노드에는 전용 디스크가 필요하고, MON(모니터) 데몬 운영을 위한 CPU와 메모리도 여유 있게 확보해야 해요. 리소스가 빠듯한 환경에서는 Longhorn이 훨씬 현실적입니다.

Q. 기존 NFS 스토리지에서 마이그레이션이 가능한가요?

직접적인 마이그레이션 도구는 없고, 보통 데이터를 백업 후 새 PVC에 복원하는 방식을 사용합니다. Velero(벨레로) 같은 쿠버네티스 백업 도구를 활용하면 좀 더 체계적으로 진행할 수 있어요. 이 내용은 다음 글에서 다룰 예정입니다.

Q. 홈랩에서는 뭘 추천하세요?

저는 홈랩에서 Longhorn을 쓰고 있어요. 설치가 간단하고 UI가 직관적이어서 관리하기 편합니다. 노드 3대 이하 환경이라면 Longhorn이 압도적으로 편해요.

마무리: 결국 “상황에 맞는” 선택이 정답입니다

13년 동안 인프라 일을 하면서 느낀 건데요. 기술 선택에 “절대적인 정답”은 없더라고요. Longhorn이 좋냐, Rook Ceph가 좋냐가 아니라 내 환경에 뭐가 맞냐가 핵심이에요.

소규모 클러스터에서 빠르게 쿠버네티스 영구 스토리지를 도입하고 싶다면 Longhorn으로 시작하세요. 운영하다가 규모가 커지고 RWX나 오브젝트 스토리지가 필요해지면 그때 Rook Ceph로 전환하거나 병행하는 것도 방법이에요.

중요한 건 일단 시작하는 거라고 생각해요. NFS로 버티다가 나중에 대규모 마이그레이션 하는 것보다, 처음부터 제대로 된 CSI 드라이버 기반 스토리지를 도입하는 게 훨씬 낫거든요.

다음 글에서는 Velero를 활용한 쿠버네티스 백업 전략에 대해 다룰 예정입니다. Longhorn 내장 백업과 Velero를 조합하면 꽤 탄탄한 백업 체계를 만들 수 있거든요. 기대해 주세요! 🎉

혹시 설치하다가 막히는 부분이 있으시면 댓글로 남겨주세요. 제가 겪었던 삽질 경험이 도움이 될 수도 있으니까요 ㅎㅎ