📗Longhorn 개요

Longhorn은 Kubernetes 환경에서 클라우드 네이티브 분산 블록 스토리지를 제공하는 오픈소스 프로젝트이다. Kubernetes 클러스터에서 사용할 수 있는 가볍고, 고가용성의 블록 스토리지 시스템으로 영구적인 저장 공간(Persistent Volume)을 제공하여 Pod 재시작, 노드 장애 시에도 데이터가 유지되게 해준다.

주요 특징

기능	설명
분산 복제	기본적으로 2~3개의 복제본을 생성하여 데이터 유실 방지
UI 제공	웹 기반 대시보드 제공 (볼륨 상태, 복제, 백업 관리)
스냅샷/백업	볼륨 스냅샷 및 백업 기능 내장 (S3/NFS 백업 지원)
CSI 지원	Kubernetes CSI (Container Storage Interface) 연동
오토리커버리	노드 장애 시 복제본 자동 재배치
경량화	다른 분산 스토리지에 비해 설치 및 운영이 단순

🏳️‍🌈 [궁금한점]

• hostpath 를 사용하는 것과 CSI 를 사용하는 것의 차이점은 무엇일까
• CSI 를 사용하면 여러 볼륨의 짜투리 용량을 합쳐서 서비스가 가능할까
• 볼륨을 구성하여 오브젝트 스토리지 저장소로 사용가능할까

---

🔗[목차]

• 아키텍처 컴포넌트
  • Longhorn Manager (longhorn-manager)
  • Longhorn Engine (longhorn-engine)
  • Longhorn Replica (longhorn-replica)
  • Longhorn UI
  • Instance Manager
  • CSI Driver
• Longhorn 활용
  • CSI 드라이버별 디스크 합침 가능 여부
  • hostPath vs CSI 드라이버 비교
    • 언제 hostPath를 써야 하나?
    • 언제 CSI(Local PV, Longhorn 등)를 써야 하나?
  • MinIO + Longhorn 조합
    • MinIO Pod의 PVC를 Longhorn으로 제공
    • Longhorn 기반 MinIO 구성 장점
    • Longhorn 기반 MinIO 구성 시 고려사항
• Longhorn 설치 / 삭제
• longhorn 테스트
  • PVC 생성
  • 볼륨 생성
  • 퍼시스턴스 테스트
• 오브젝트 스토리지와 파일 시스템에 대한 이해

아키텍처 컴포넌트

Longhorn Manager (longhorn-manager)

• 각 노드에서 실행되는 데몬.
• Longhorn 리소스(CR)을 감시하고, 볼륨, 복제본, 엔진 등의 상태 관리 및 제어를 수행.
• Pod 형태로 실행되며, Kubernetes API Server와 상호작용.

Longhorn Engine (longhorn-engine)

• 각 볼륨마다 하나씩 존재하는 컨트롤러.
• 복제본들과 통신하여 데이터 I/O 처리.
• Read/Write 트래픽을 클라이언트로부터 받아서 각 복제본에 전달하고, 상태를 감시.

Longhorn Replica (longhorn-replica)

• 각 노드에 있는 복제본 Pod.
• 실제 데이터가 저장되는 볼륨이며, 여러 개의 복제본이 하나의 볼륨을 구성.
• Replica는 디스크에 파일 형태로 데이터 저장.

Longhorn UI

• 웹 대시보드 제공.
• 볼륨, 백업, 스냅샷, 노드 상태 등을 시각적으로 관리 가능.

Instance Manager

• 하나의 Pod에서 여러 Engine 및 Replica를 실행하기 위한 경량 런타임.
• 볼륨당 Pod이 많아지는 것을 방지하기 위해 도입.

CSI Driver

• Kubernetes의 PersistentVolumeClaim(PVC) 요청을 처리하는 드라이버.
• Longhorn 볼륨을 Kubernetes Pod에 자동으로 마운트 및 언마운트.

Longhorn 활용

• 가벼운 분산 스토리지가 필요한 클러스터
• 로컬 디스크를 최대한 활용하고 싶은 환경
• Rook/Ceph 같은 복잡한 스토리지가 부담스러운 경우
• NFS보다 강력한 스토리지를 원하지만 관리가 쉬운 것을 원할 때
• 고성능 워크로드에는 Ceph보다 부족할 수 있음
• 동일 볼륨의 ReadWriteMany(RWX) 는 기본적으로 지원하지 않음 (단, NFS나 shared RWX 지원 모드 설정 가능)
• 디스크 장애보다 노드 장애 복구가 상대적으로 빠름

CSI 드라이버별 디스크 합침 가능 여부

두 디스크에 각각 5GB 남아 있는 경우, CSI가 이를 합쳐서 10GB 볼륨을 만들 수 있는지는 해당 CSI 드라이버와 백엔드 스토리지의 능력에 따라 다르다.

CSI 드라이버	디스크 합침 가능 여부	설명
Longhorn	가능	여러 노드 디스크를 묶어 볼륨 구성
Ceph RBD	가능	백엔드에 OSD 여러 개 → 풀 구성
LVM-CSI	가능	Physical Volume 묶어서 Logical Volume 생성
Local Path CSI	불가	단일 노드, 단일 경로에서만 할당
HostPath	불가	테스트 전용, 디스크 합침 기능 없음

hostPath vs CSI 드라이버 비교

MinIO처럼 디스크 I/O가 많은 S3 워크로드에는 hostPath 성능이 좋긴 하지만, 운영 복잡도와 장애 내구성을 고려해 Longhorn 같은 CSI 방식을 많이 쓴다.

언제 hostPath를 써야 하나?

• Dev/PoC 환경
• 고성능이 필요하고, 노드/디스크 장애 허용 가능한 경우
• 인프라가 단순하고 수동 설정이 괜찮은 경우
• 노드에 디스크를 직접 붙여 쓰는 로컬 고속 스토리지 목적

volumeMounts:
- name: data
  mountPath: /data
volumes:
- name: data
  hostPath:
    path: /mnt/minio1

언제 CSI(Local PV, Longhorn 등)를 써야 하나?

• 운영 환경에서 스토리지 관리 자동화, 백업, 복구, 확장성 필요할 때
• 장애 복구, HA, 유연한 Pod 이동성이 중요할 때
• Kubernetes 네이티브 방식으로 스토리지 관리하고 싶을 때

항목	hostPath 사용	CSI 드라이버 (예: Longhorn, local-static-provisioner)
개념	Pod에서 노드 디렉토리를 직접 마운트	쿠버네티스 표준 스토리지 인터페이스를 통해 디스크 사용
스토리지 클래스 사용 가능 여부	불가	가능 (storageClassName 지정 가능)
동적 프로비저닝	불가능 (수동 YAML 필요)	가능 (Longhorn 등은 동적 PVC 생성 지원)
데이터 가용성	디스크가 붙은 노드에만 존재 (노드 장애 시 손실 가능)	Replica, Snapshot, Self-healing 등으로 내구성↑
Pod 이동 가능성	해당 노드에만 실행 가능 (AntiAffinity 필수)	Replica 기반이거나 volumeAttachment로 스케줄 유연성↑
백업/복원 기능	없음 (직접 관리해야 함)	대부분 CSI는 자체 백업/스냅샷 API 제공 (Longhorn UI 포함)
운영 관리 UI	없음	있음 (Longhorn, OpenEBS 등은 대시보드 제공)
성능	가장 빠름 (디스크 직접 연결)	약간 느릴 수 있음 (네트워크 복제 overhead)

MinIO + Longhorn 조합

역할	설명
MinIO	고성능 분산 오브젝트 저장소 (S3 compatible)
Longhorn	쿠버네티스 네이티브 분산 블록 스토리지 솔루션

MinIO Pod의 PVC를 Longhorn으로 제공

volumeClaimTemplates:
  - metadata:
      name: data
    spec:
      storageClassName: longhorn
      accessModes: ["ReadWriteOnce"]
      resources:
        requests:
          storage: 100Gi

이렇게 하면 Longhorn이 자동으로 볼륨을 생성하고, MinIO가 그 위에 데이터를 저장하게 된다.

Longhorn 기반 MinIO 구성 장점

• 스토리지 고가용성

• • Longhorn은 자체적으로 replica, self-healing, snapshot, backup 기능 제공
• • 예: 노드가 죽어도 다른 노드의 replica가 데이터를 유지

• PVC 관리 간편

• • Longhorn은 쿠버네티스에서 완전히 통합되어 PVC만 만들면 사용 가능
• • MinIO는 별도 스토리지 시스템 없이 Longhorn만으로 고가용 운영 가능

• 스토리지 UI 및 백업

• • Longhorn UI에서 실시간 볼륨 상태 확인, 스냅샷/백업도 간단함

Longhorn 기반 MinIO 구성 시 고려사항

항목	설명
성능	Longhorn은 분산 스토리지이므로 디스크 + 네트워크 I/O가 결합됨. 고성능 MinIO 구성에선 로컬 디스크가 더 빠름
레이턴시	S3 워크로드에서 대규모 병렬 요청이 많으면, Longhorn latency가 영향 줄 수 있음
중복 관리	MinIO 자체가 erasure coding/replica를 하므로, Longhorn과 중복된 내구성 관리 가능성 존재 (주의해서 설정 필요)

Longhorn 설치 / 삭제

helm repo add longhorn https://charts.longhorn.io
helm repo update
kubectl create namespace longhorn-system

helm install longhorn longhorn/longhorn \
  --namespace longhorn-system \
  --set defaultSettings.defaultReplicaCount=2 \
  --set defaultSettings.recreateFailedPod=true

• 삭제

kubectl -n longhorn-system patch -p '{"value": "true"}' --type=merge lhs deleting-confirmation-flag
helm uninstall longhorn -n longhorn-system
kubectl delete namespace longhorn-system

• (참고) Longhorn 설치 후 생성되는 리소스
  replica를 2로 줄여도 많은 리소스가 사용된다.

vagrant@master:~$ k get po -n longhorn-system -w
NAME                                                READY   STATUS    RESTARTS   AGE
csi-attacher-647d7767b9-6kf65                       1/1     Running   0          26s
csi-attacher-647d7767b9-7xxdb                       1/1     Running   0          26s
csi-attacher-647d7767b9-hbjz5                       1/1     Running   0          26s
csi-provisioner-76bc4b5886-4pkvl                    1/1     Running   0          26s
csi-provisioner-76bc4b5886-jrccb                    1/1     Running   0          26s
csi-provisioner-76bc4b5886-rzc9z                    1/1     Running   0          26s
csi-resizer-78cd7545b7-5bplx                        1/1     Running   0          25s
csi-resizer-78cd7545b7-m6mt2                        1/1     Running   0          25s
csi-resizer-78cd7545b7-md299                        1/1     Running   0          25s
csi-snapshotter-7b7db78f9-j4q7f                     1/1     Running   0          25s
csi-snapshotter-7b7db78f9-pdr92                     1/1     Running   0          25s
csi-snapshotter-7b7db78f9-t8cc6                     1/1     Running   0          25s
engine-image-ei-db6c2b6f-2krkx                      1/1     Running   0          74s
engine-image-ei-db6c2b6f-7lmcc                      1/1     Running   0          74s
engine-image-ei-db6c2b6f-gb725                      1/1     Running   0          74s
instance-manager-3ea5b7589af1189d2443a9741d58a959   1/1     Running   0          40s
instance-manager-4fbef9fc9af28ebef2cc1437097b6d51   1/1     Running   0          43s
instance-manager-d883d45a264cebf998825ad3072d756e   1/1     Running   0          44s
longhorn-csi-plugin-q72pw                           3/3     Running   0          25s
longhorn-csi-plugin-qffqz                           3/3     Running   0          25s
longhorn-csi-plugin-w5d65                           3/3     Running   0          25s
longhorn-driver-deployer-85c5f4ff6f-wf62g           1/1     Running   0          82s
longhorn-manager-8d4cm                              2/2     Running   0          82s
longhorn-manager-cl8s4                              2/2     Running   0          82s
longhorn-manager-thxqs                              2/2     Running   0          83s
longhorn-ui-5984465c7b-jx8vt                        1/1     Running   0          83s
longhorn-ui-5984465c7b-wcpdt                        1/1     Running   0          82s

vagrant@master:~$ k get svc -n longhorn-system
NAME                          TYPE        CLUSTER-IP      EXTERNAL-IP   PORT(S)    AGE
longhorn-admission-webhook    ClusterIP   10.233.8.248    <none>        9502/TCP   4m37s
longhorn-backend              ClusterIP   10.233.28.119   <none>        9500/TCP   4m37s
longhorn-conversion-webhook   ClusterIP   10.233.62.195   <none>        9501/TCP   4m37s
longhorn-frontend             ClusterIP   10.233.11.227   <none>        80/TCP     4m37s
longhorn-recovery-backend     ClusterIP   10.233.59.91    <none>        9503/TCP   4m37s

vagrant@master:~$ k get sc
NAME                 PROVISIONER          RECLAIMPOLICY   VOLUMEBINDINGMODE   ALLOWVOLUMEEXPANSION   AGE
longhorn (default)   driver.longhorn.io   Delete          Immediate           true                   5m50s
longhorn-static      driver.longhorn.io   Delete          Immediate           true                   14m

longhorn 테스트

PVC 생성

apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: longhorn-pvc
spec:
  accessModes:
    - ReadWriteOnce
  storageClassName: longhorn
  resources:
    requests:
      storage: 5Gi

볼륨 생성

apiVersion: v1
kind: Pod
metadata:
  name: mypod
spec:
  containers:
  - name: mypod
    image: busybox
    command: ["/bin/sh"]
    args: ["-c", "sleep 3600"]
    volumeMounts:
    - mountPath: "/data"
      name: myvol
  volumes:
  - name: myvol
    persistentVolumeClaim:
      claimName: longhorn-pvc

퍼시스턴스 테스트

/data 에 볼륨이 마운트 되어 있다. mypod 컨테이너의 /data 에 hi.txt 파일을 생성한 후 mypod를 삭제 한다. 새로운 pod 를 생성하여 /data 에 접근하면 좀 전에 생성한 hi.txt 파일이 남아 있다.

vagrant@master:~$ k exec -it mypod -- sh
/ # cd /data
/data # echo "hi" > hi.txt
/data # cat hi.txt
hi
/data # exit


vagrant@master:~$ k delete po mypod
pod "mypod" deleted
vagrant@master:~$ k apply -f mypod.yml
pod/mypod created
vagrant@master:~$ k exec -it mypod -- sh
/ # ls /data
hi.txt      lost+found

오브젝트 스토리지와 파일 시스템에 대한 이해

오브젝트 스토리지(Object Storage) 는 파일시스템을 직접 포맷하거나 변경하는 게 아니고, MinIO 같은 애플리케이션(소프트웨어) 이 기존 디스크 위에서 오브젝트 저장 방식을 구현하는 개념이다.

• 파일 대신 "오브젝트" 단위로 저장
• 각 오브젝트에는 메타데이터 + 고유 ID가 붙음
• 디렉토리 구조가 필요 없음 (하지만 가상으로 흉내 낼 수 있음)
• REST API(S3)로 접근
• 오브젝트 스토리지는 소프트웨어적 개념
• MinIO만 설치하면 구현 가능, 디스크 포맷은 기존 파일시스템이면 충분
• 실제 디스크에 저장은 파일 단위지만, 외부에서는 오브젝트처럼 동작

항목	설명
파일시스템 포맷 필요 여부	불가. 일반적인 ext4, xfs 같은 파일시스템 위에서 작동
MinIO 설치만으로 가능 여부	가능. MinIO가 오브젝트 스토리지를 소프트웨어적으로 제공
OS 인식 방식	OS는 단순히 "디렉토리+파일"로 보지만, MinIO는 그것을 오브젝트처럼 관리
하드웨어와의 관계	로컬 디스크, SAN, 혹은 PVC(쿠버네티스) 등 어떤 저장소든 위에서 실행 가능

MinIO 예시

• 디스크를 ext4로 포맷하고 /mnt/data1에 마운트
• MinIO 설치하고 /mnt/data1을 데이터 디렉토리로 지정
• MinIO는 /mnt/data1에 실제 파일을 저장하지만, 클라이언트에는 S3 API를 통해 오브젝트처럼 보임