13년차의 서버실

서버, 인프라, 홈랩 기술 블로그

[태그:] Persistent Volume

  • [K8s] Longhorn 1년 운영기: 안정성과 성능 정리

    [K8s] Longhorn 1년 운영기: 안정성과 성능 정리

    [K8s] 프로덕션 Longhorn 1년 운영기: 안정성과 성능 정리

    프로덕션에서 k8s longhorn 운영을 1년 정도 해보면, 처음 기대했던 편의성과 실제 운영 난이도 사이의 간격이 꽤 선명하게 보입니다. 저도 처음엔 ‘쿠버네티스(Kubernetes, 컨테이너 오케스트레이션) 위에서 스토리지까지 한 번에 정리되면 정말 편하겠다’ 싶었거든요. 실제로 써보니까 편한 점도 분명했고, 반대로 방심하면 장애를 키우는 포인트도 있었습니다. 이번 글은 제품 소개보다는 longhorn 사례에 가깝습니다. 무엇이 안정적이었고, 어디서 삽질했는지, 그리고 지금 다시 구성한다면 무엇을 다르게 할지 정리해보겠습니다.

    특히 상태 저장 워크로드(Stateful Workload, 데이터가 남아야 하는 애플리케이션)를 k8s에서 돌리고 계신 분이라면, 스토리지 선택이 결국 운영 스트레스를 좌우한다는 걸 이미 느끼셨을 겁니다. 혹시 PVC(PersistentVolumeClaim, 영구 볼륨 요청)만 붙이면 끝이라고 생각하셨다면, 여기서 중요한 포인트가 있습니다. 스토리지는 선언형만으로 끝나지 않고 운영 습관까지 같이 설계해야 하더라고요.

    프로덕션 클러스터에서 Longhorn이 각 노드 디스크를 묶어 분산 블록 스토리지로 구성되는 전체 흐름을 보여주는 이미지입니다.

    1. 왜 k8s에서 Longhorn을 고민하게 되는가

    쉽게 말해 Longhorn은 쿠버네티스 친화적인 분산 블록 스토리지(Distributed Block Storage)입니다. 각 노드의 디스크를 활용해서 볼륨을 만들고, 복제본(Replica, 데이터 사본)을 여러 노드에 분산해 두는 방식이죠. 관리 포인트가 늘어나는 건 맞는데, 대신 클러스터 안에서 스토리지를 비교적 일관된 방식으로 다룰 수 있습니다.

    제가 Longhorn을 선택했던 이유는 세 가지였습니다.

    • 노드 로컬 디스크를 활용할 수 있다는 점
    • UI 기반 운영 가시성이 괜찮다는 점
    • 백업(Backup)과 스냅샷(Snapshot) 흐름을 잡기 쉬웠다는 점

    반대로 처음부터 알았어야 했던 것도 있습니다. Longhorn은 마법이 아닙니다. underlying disk, 네트워크, 워크로드 I/O 패턴이 좋지 않으면 그대로 티가 납니다. 즉 k8s 스토리지 문제를 Longhorn이 가려주지는 않더라고요. 오히려 더 빨리 드러내 줍니다. 이건 단점 같지만, 운영자 입장에선 장점이기도 합니다.

    2. Longhorn 개념, 쉽게 말해 어떻게 동작하나

    처음엔 이게 뭔가 싶었는데, 구조를 한 번 그림으로 이해하면 꽤 단순합니다.

    1. 파드(Pod, 컨테이너 실행 단위)가 PVC를 요청합니다.
    2. 스토리지클래스(StorageClass, 동적 볼륨 정책)에 따라 Longhorn 볼륨이 생성됩니다.
    3. Longhorn이 여러 노드에 복제본을 배치합니다.
    4. 특정 노드에서 파드가 볼륨을 마운트(Mount, 연결)해서 사용합니다.
    5. 노드 하나가 내려가도 복제본이 남아 있으면 복구 여지가 생깁니다.

    여기서 핵심은 두 가지입니다. 첫째, 복제본 수는 안정성과 비용의 균형입니다. 둘째, 성능은 결국 네트워크와 디스크 특성의 영향을 크게 받습니다. 그래서 Longhorn을 볼 때는 단순히 설치 성공 여부보다, 복제 전략과 워크로드 특성을 먼저 맞춰보는 게 중요합니다.

    항목 Longhorn에서 보는 포인트 운영 시 체감
    안정성 복제본 분산, 노드 장애 대응 단일 노드 장애에는 강한 편
    성능 디스크 IOPS, 네트워크 지연 랜덤 I/O 많은 DB는 민감함
    운영 편의 UI, 볼륨 관리, 스냅샷 초기 러닝커브 이후 꽤 편함
    주의점 디스크 여유 공간, 재빌드 트래픽 장애 후 재동기화 시 부담 큼

    3. 제가 실제로 잡았던 운영 원칙

    longhorn 안정성은 제품 자체보다 운영 원칙에서 많이 갈렸습니다. 제가 1년 돌리면서 끝까지 가져간 기준은 아래와 같았습니다.

    • 컨트롤 플레인(Control Plane, 제어 영역)과 스토리지 부담을 가능한 분리
    • 복제본은 최소한 장애 도메인(Failure Domain, 함께 망가질 수 있는 범위)을 고려해서 배치
    • 디스크 사용률 임계치(Threshold, 경계값)를 보수적으로 설정
    • 스냅샷은 남발하지 않고 백업 정책과 구분
    • DB처럼 I/O 민감한 워크로드는 사전 검증 후 배치

    이 중에서 가장 중요했던 건 디스크 여유 공간입니다. 처음엔 여유가 좀 있으니 괜찮겠지 했었는데, 재빌드(Rebuild, 복제본 재생성)가 걸리는 순간 생각보다 빠르게 압박이 오더라고요. 스토리지 시스템은 평상시보다 장애 직후가 더 무겁습니다. 이건 꼭 기억하셔야 합니다.

    4. 실전 구현: k8s Longhorn 운영 시작할 때 제가 한 순서

    설치는 환경마다 조금씩 다르지만, 흐름은 크게 다르지 않습니다. 아래는 제가 홈랩과 실서비스 검증 환경에서 자주 쓰는 형태입니다.

    1. 노드 디스크 상태와 마운트 경로를 먼저 확인합니다.
    2. Longhorn 시스템용 네임스페이스(namespace)를 분리합니다.
    3. 기본 StorageClass를 만들되, 복제본 수를 환경에 맞게 조정합니다.
    4. 테스트용 PVC와 파드를 붙여 실제 쓰기/읽기를 확인합니다.
    5. 운영 전 스냅샷과 백업 경로를 반드시 따로 검증합니다.
    kubectl create namespace longhorn-system
    kubectl get nodes -o wide
    kubectl get sc
    kubectl get pods -n longhorn-system
    

    스토리지클래스는 아래처럼 시작하면 이해가 쉽습니다. 값 자체는 환경마다 다르게 잡으셔야 합니다.

    apiVersion: storage.k8s.io/v1
    kind: StorageClass
    metadata:
      name: longhorn-replicated
    provisioner: driver.longhorn.io
    allowVolumeExpansion: true
    reclaimPolicy: Delete
    volumeBindingMode: Immediate
    parameters:
      numberOfReplicas: "3"
      staleReplicaTimeout: "30"
      fsType: "ext4"
    

    그리고 바로 PVC를 붙여봅니다.

    apiVersion: v1
    kind: PersistentVolumeClaim
    metadata:
      name: demo-pvc
    spec:
      accessModes:
        - ReadWriteOnce
      storageClassName: longhorn-replicated
      resources:
        requests:
          storage: 20Gi
    ---
    apiVersion: v1
    kind: Pod
    metadata:
      name: demo-writer
    spec:
      containers:
        - name: writer
          image: busybox
          command: ["sh", "-c", "while true; do date >> /data/out.log; sleep 5; done"]
          volumeMounts:
            - name: data
              mountPath: /data
      volumes:
        - name: data
          persistentVolumeClaim:
            claimName: demo-pvc
    

    처음엔 단순한 쓰기 테스트가 무슨 의미가 있나 싶었는데, 여기서 마운트 지연이나 attach 문제를 초기에 꽤 많이 잡았습니다. 운영 들어가고 나서 알면 늦거든요.

    k8s longhorn 운영 설정과 PVC 연결 흐름 이미지

    StorageClass 생성부터 PVC 연결, 파드 마운트까지 이어지는 실제 구성 흐름을 설명하는 이미지입니다.

    5. 운영 중 자주 본 이슈와 트러블슈팅

    이 섹션이 사실 제일 중요합니다. 예쁜 소개보다, 실제로 어디서 무너지는지를 아는 게 훨씬 도움이 되거든요.

    5-1. ⚠️ 복제본 재빌드가 길어지면서 성능이 흔들릴 때

    노드 하나를 점검하느라 내렸다가 다시 올리면, 복제본 재동기화가 시작됩니다. 이때 네트워크와 디스크에 동시에 부담이 옵니다. longhorn 성능이 평소엔 괜찮다가도 이 구간에서 갑자기 느려질 수 있습니다.

    제가 했던 대응은 단순했습니다.

    • 업무 시간 중 대규모 재스케줄링을 피했습니다.
    • 용량이 큰 볼륨은 변경 작업 전에 백업 상태를 먼저 확인했습니다.
    • 재빌드가 오래 걸리는 볼륨은 워크로드 I/O 패턴을 따로 봤습니다.

    5-2. ⚠️ 디스크는 남았는데 스케줄링이 꼬이는 경우

    이건 꽤 헷갈립니다. df로 보면 공간이 남아 있는데, Longhorn 쪽에서는 새 복제본 배치를 보수적으로 판단하는 경우가 있습니다. 저도 처음엔 버그인가 싶었는데, 실제론 예약 공간과 최소 여유 공간 정책을 같이 봐야 하더라고요.

    이럴 때는 아래처럼 확인했습니다.

    kubectl get pvc
    kubectl describe pvc demo-pvc
    kubectl get volumes.longhorn.io -n longhorn-system
    kubectl get replicas.longhorn.io -n longhorn-system
    

    5-3. ⚠️ 스냅샷이 백업을 대체한다고 착각하기

    이건 정말 많이 나오는 실수입니다. 스냅샷(Snapshot, 시점 복사본)은 같은 스토리지 계층 안에 남는 경우가 많아서, 근본적인 백업 전략과는 다릅니다. 저도 초반엔 스냅샷이 있으니 어느 정도 안심했었는데, 사고 시나리오를 따져보면 그걸로는 부족했습니다. 스냅샷은 운영 편의 기능이고, 백업은 재해 복구 전략입니다. 완전히 다릅니다.

    6. 검증 방법: 설치보다 중요한 운영 확인 절차

    프로덕션에선 ‘붙었다’보다 ‘망가졌을 때 어떻게 보이는가’를 확인해야 합니다. 저는 최소한 아래는 반복해서 체크했습니다.

    1. 파드 재시작 후 볼륨 재연결이 정상인지 확인
    2. 노드 drain 이후 워크로드 복구 흐름 확인
    3. 스냅샷 생성 및 삭제 후 공간 회수 패턴 확인
    4. 백업 저장소 접근 실패 시 경고 동작 확인
    5. 복제본 손실 상황에서 재생성 시간이 과하게 길지 않은지 확인

    실제로 써보니까 UI에서 상태가 보여주는 정보가 꽤 유용했습니다. 다만 UI만 믿고 있으면 늦습니다. 이벤트(Event), PVC 상태, 파드 재시작 로그를 같이 봐야 원인이 보입니다.

    longhorn 성능과 안정성 확인용 운영 대시보드 이미지

    복제본 상태, 볼륨 attach 여부, 재빌드 진행 상황을 한눈에 확인하는 운영 관점의 대시보드 이미지입니다.

    7. 1년 운영 후 느낀 안정성과 성능 평가

    결론부터 말하면, Longhorn은 잘 설계된 환경에서는 충분히 실전적인 선택지였습니다. 특히 여러 팀이 PVC를 빠르게 써야 하고, 외부 스토리지 어플라이언스에 강하게 의존하고 싶지 않을 때 장점이 컸습니다. 제가 본 longhorn 사례 기준으로는 다음과 같이 정리할 수 있었습니다.

    구분 좋았던 점 아쉬웠던 점
    안정성 노드 단위 장애 대응이 비교적 명확함 디스크/네트워크 품질이 낮으면 불안정성이 바로 드러남
    성능 일반적인 앱 데이터, 로그성 워크로드는 무난 고성능 DB, 지연 민감 워크로드는 사전 검증 필수
    운영 가시성과 자동화 포인트가 좋음 재빌드와 용량 계획은 생각보다 더 보수적으로 해야 함

    드디어 됐다 싶었던 순간도 많았습니다. 예전엔 스토리지 붙이는 작업 자체가 팀 내 병목이었는데, Longhorn 이후엔 표준화가 쉬워졌거든요. 반대로 ‘이거 진짜 편하더라고요’라고 말할 수 있으려면, 초반 설계와 검증을 꽤 꼼꼼하게 해야 합니다. 그냥 설치만 해놓고 운영에 들어가면 언젠가 비용을 치릅니다.

    8. 정리와 다음 단계: 이런 분께 특히 맞습니다

    k8s longhorn 운영을 1년 해보면서 제가 내린 판단은 이렇습니다.

    • 온프레미스(On-premise, 자체 인프라)나 홈랩에서 쿠버네티스 스토리지를 일관되게 운영하고 싶은 분
    • 외부 스토리지 장비보다 클러스터 내부 표준화를 우선하는 팀
    • 운영자가 디스크, 네트워크, 장애 복구 흐름을 직접 이해하고 관리할 준비가 된 환경

    반대로, 아주 빡빡한 성능 요구가 있는 데이터베이스를 바로 얹을 계획이라면 먼저 작은 범위에서 검증해보시는 걸 권합니다. 저도 처음엔 자신 있게 올렸다가, I/O 패턴 때문에 조정 많이 했습니다. 결국 중요한 건 제품 이름보다 워크로드 적합성입니다.

    다음 글에서는 백업 저장소(Backup Target) 설계나, 스냅샷 정리 정책을 어떻게 가져가면 운영이 덜 꼬이는지 다뤄볼 예정입니다. 이전 글에서 다뤘던 Ingress(인그레스, 외부 트래픽 진입점)와 모니터링 구성과도 연결되는 부분이 많아서, 같이 보시면 흐름이 더 잘 잡히실 겁니다.

    k8s longhorn 운영 장단점 요약 인포그래픽

    안정성, 성능, 운영 난이도, 추천 환경을 한 장으로 요약한 비교형 인포그래픽 이미지입니다.

    9. 자주 묻는 질문 FAQ

    Q1. Longhorn은 모든 워크로드에 무난한가요?

    아닙니다. 일반적인 상태 저장 앱에는 잘 맞을 수 있지만, 초저지연이 중요한 워크로드는 별도 검증이 필요합니다.

    Q2. 복제본 수는 무조건 많을수록 좋은가요?

    그렇지 않습니다. 안정성은 좋아질 수 있지만, 용량과 재빌드 비용도 같이 늘어납니다. 장애 도메인 기준으로 잡는 게 현실적입니다.

    Q3. 스냅샷만 잘 찍어두면 백업은 안 해도 되나요?

    안 됩니다. 스냅샷과 백업은 역할이 다릅니다. 이건 꼭 분리해서 생각하셔야 합니다.

    정리하면, longhorn 안정성은 꽤 인상적이었고, longhorn 성능은 환경과 워크로드 영향을 솔직하게 받았습니다. 그래서 더 좋았습니다. 숨기지 않거든요. 문제를 빨리 보여주는 시스템은, 운영자가 준비만 되어 있으면 꽤 믿을 만합니다. k8s 스토리지 때문에 계속 고민 중이셨다면, 작은 클러스터에서부터 검증해보세요. 그 과정에서 배우는 게 정말 많습니다.

  • [k8s] Kubernetes Longhorn 스토리지: 설치부터 운영까지 완벽 가이드

    [k8s] Kubernetes Longhorn 스토리지: 설치부터 운영까지 완벽 가이드

    안녕하세요, 13년차 서버실 지킴이입니다. 🤓

    오늘은 제가 홈랩에서 Kubernetes(쿠버네티스) 클러스터를 운영하면서 겪었던 스토리지 고민과 그 해결책, 바로 Longhorn(롱혼)에 대해 이야기해보려고 합니다. 쿠버네티스에서 컨테이너 애플리케이션을 운영하다 보면, 데이터 영속성(Persistence) 확보가 정말 중요한데요. 특히 분산 스토리지(Distributed Storage)는 고가용성(High Availability)과 데이터 안정성을 위해 필수적이죠. 처음엔 로컬 스토리지를 PersistentVolume(PV)으로 직접 연결해보기도 하고, NFS(Network File System)를 써보기도 했는데, 이게 또 생각보다 관리하기가 만만치 않더라고요.

    그러다 우연히 Longhorn을 알게 되었고, 직접 설치하고 운영해보니 “아, 이거다!” 싶었습니다. 설치도 비교적 간단하고, 웹 UI로 볼륨 관리도 직관적이라 삽질 좀 덜 수 있었거든요. 오늘은 저의 경험을 바탕으로 Longhorn을 처음 접하시는 분들도 쉽게 따라할 수 있도록 설치부터 운영까지 완벽 가이드를 준비해봤습니다. 함께 시작해볼까요?

    쿠버네티스 클러스터 내 롱혼 분산 스토리지 아키텍처 개요

    이미지 캡션: 쿠버네티스 클러스터 내 롱혼 분산 스토리지 아키텍처 개요. 여러 노드에 걸쳐 데이터가 복제되고 관리되는 모습을 보여줍니다.

    💡 Longhorn, 넌 누구냐? (핵심 개념 설명)

    자, 그럼 먼저 Longhorn이 뭔지부터 알아봐야겠죠? Longhorn은 CNCF(Cloud Native Computing Foundation) 프로젝트 중 하나로, 쿠버네티스를 위한 분산 블록 스토리지 시스템입니다. 쉽게 말해, 쿠버네티스 클러스터 내의 여러 노드에 있는 디스크들을 모아서 하나의 거대한 가상 스토리지 풀을 만들고, 이 풀에서 PersistentVolume(영구 볼륨)을 생성하여 파드(Pod)에 제공해주는 역할을 해요.

    • 분산 스토리지 (Distributed Storage): 여러 노드의 저장 공간을 하나로 묶어 사용하며, 데이터가 여러 노드에 복제되어 저장되기 때문에 특정 노드에 문제가 생겨도 데이터 유실 걱정을 덜 수 있습니다.
    • CSI (Container Storage Interface, 컨테이너 스토리지 인터페이스) 호환: 쿠버네티스의 표준 스토리지 인터페이스인 CSI를 완벽하게 지원하기 때문에, 쿠버네티스에서 제공하는 StorageClass(스토리지 클래스), PersistentVolumeClaim(PVC, 영구 볼륨 클레임) 등의 기능을 문제없이 쓸 수 있습니다.
    • 스냅샷 및 백업/복구: 볼륨의 스냅샷을 찍고, S3와 같은 오브젝트 스토리지(Object Storage)나 NFS로 백업 및 복구를 쉽게 할 수 있어요. 제가 써보니 이 기능이 정말 편하더라고요!

    사실 처음엔 이런 분산 스토리지가 복잡하고 어렵게 느껴졌는데, Longhorn은 웹 UI가 워낙 직관적이라 금방 익숙해질 수 있었습니다. 덕분에 홈랩에서 여러 스테이트풀(Stateful) 애플리케이션들을 안정적으로 운영할 수 있게 되었죠. 예를 들어, 제 홈랩의 Prometheus(프로메테우스)나 Grafana(그라파나) 같은 모니터링 툴의 데이터도 Longhorn 볼륨에 저장해서 쓰고 있거든요.

    🛠️ 실전 구현: Longhorn 설치부터 PersistentVolume 사용까지

    이제 본격적으로 Longhorn을 설치하고 사용하는 방법을 알아볼 차례입니다. 저는 Helm(헬름)을 이용해서 설치하는 방법을 선호합니다. 배포가 간편하고 버전 관리가 용이하거든요. 시작하기 전에 몇 가지 준비물이 필요합니다.

    ✅ 준비물 확인

    1. Kubernetes 클러스터: 최소 3개 이상의 노드(Node)를 권장합니다. 각 노드에 충분한 여유 디스크 공간이 필요합니다.
    2. iSCSI initiator 설치: Longhorn은 iSCSI 프로토콜을 사용합니다. 각 노드에 <code>iscsi-initiator-utils (CentOS/RHEL) 또는 open-iscsi (Ubuntu/Debian) 패키지가 설치되어 있어야 합니다. 제가 처음 이걸 몰라서 삽질 좀 했습니다. 꼭 확인하세요!
      
      # CentOS/RHEL 계열
      sudo yum install -y iscsi-initiator-utils
      sudo systemctl enable --now iscsid
      
      # Ubuntu/Debian 계열
      sudo apt update
      sudo apt install -y open-iscsi
      sudo systemctl enable --now iscsid
      
    3. Helm 설치: 클러스터에 Helm이 설치되어 있어야 합니다.

    🚀 Longhorn 설치하기

    Helm을 이용하면 Longhorn 설치는 정말 간단합니다. 다음 명령어를 순서대로 실행해주세요.

    
    # 1. Longhorn Helm 레포지토리 추가
    helm repo add longhorn https://charts.longhorn.io
    helm repo update
    
    # 2. Longhorn 네임스페이스 생성 (선택 사항이지만 권장)
    kubectl create namespace longhorn-system
    
    # 3. Longhorn 설치 (기본 설정으로 충분합니다)
    helm install longhorn longhorn/longhorn --namespace longhorn-system --version 1.5.3 # 버전은 최신 안정 버전을 확인하세요!
    

    설치가 완료되면, 잠시 기다리면 모든 Longhorn 컴포넌트 파드들이 longhorn-system 네임스페이스에 배포되고 실행될 겁니다. kubectl get pods -n longhorn-system 명령으로 확인해보세요. 모든 파드가 Running 상태인지 확인하는 것이 중요합니다.

    🌐 Longhorn UI 접속하기

    Longhorn은 웹 UI를 제공해서 볼륨 상태, 노드 상태 등을 직관적으로 확인할 수 있습니다. UI에 접속하려면 보통 Ingress(인그레스, 외부 트래픽 진입점)를 설정하거나 NodePort(노드포트) 서비스를 생성하는 방법이 있습니다. 저는 간단하게 포트 포워딩(Port Forwarding)으로 접속해보겠습니다.

    
    # Longhorn UI 서비스 찾기
    kubectl get svc -n longhorn-system
    
    # UI 서비스 포트 포워딩 (예: longhorn-frontend 서비스)
    kubectl -n longhorn-system port-forward svc/longhorn-frontend 8080:80
    

    이제 웹 브라우저에서 http://localhost:8080으로 접속하면 Longhorn 대시보드를 볼 수 있습니다. 🎉 드디어 Longhorn의 세상으로 들어온 것을 환영합니다!

    롱혼 웹 UI 대시보드 화면. 클러스터 노드 스토리지 상태 및 볼륨 목록 확인

    이미지 캡션: Longhorn 웹 UI 대시보드 화면. 클러스터 내 노드들의 스토리지 상태와 생성된 볼륨 목록을 한눈에 확인할 수 있습니다.

    ⚙️ StorageClass 생성 및 PersistentVolumeClaim 사용

    Longhorn이 설치되었으니, 이제 쿠버네티스에서 스토리지를 사용할 차례입니다. Longhorn은 기본 StorageClass(스토리지 클래스)를 자동으로 생성하지만, 필요에 따라 커스터마이징할 수 있습니다. 저는 기본 StorageClass를 사용하되, 예시로 PVC를 만들어보겠습니다.

    
    apiVersion: v1
    kind: PersistentVolumeClaim
    metadata:
      name: my-longhorn-pvc
    spec:
      accessModes:
        - ReadWriteOnce # 하나의 파드에서만 읽기/쓰기 가능
      storageClassName: longhorn # Longhorn이 생성한 기본 StorageClass 이름
      resources:
        requests:
          storage: 5Gi # 5GB 볼륨 요청
    

    위 YAML 파일을 pvc.yaml로 저장하고 적용합니다.

    
    kubectl apply -f pvc.yaml
    kubectl get pvc my-longhorn-pvc
    

    PVC가 Pending에서 Bound 상태로 바뀌면 성공입니다. 이제 이 PVC를 사용하는 파드를 배포해봅시다. 간단한 Nginx(엔진엑스) 파드를 예시로 들어보겠습니다.

    
    apiVersion: apps/v1
    kind: Deployment
    metadata:
      name: nginx-with-longhorn
    spec:
      selector:
        matchLabels:
          app: nginx
      replicas: 1
      template:
        metadata:
          labels:
            app: nginx
        spec:
          containers:
            - name: nginx
              image: nginx:latest
              ports:
                - containerPort: 80
              volumeMounts:
                - name: longhorn-volume
                  mountPath: /usr/share/nginx/html # Nginx 웹 페이지 경로
          volumes:
            - name: longhorn-volume
              persistentVolumeClaim:
                claimName: my-longhorn-pvc # 위에서 생성한 PVC 이름
    

    위 YAML 파일을 nginx-deployment.yaml로 저장하고 적용하면, Nginx 파드가 Longhorn 볼륨을 마운트하여 시작됩니다. 이제 /usr/share/nginx/html 경로에 데이터를 써보면, 파드가 재시작되거나 다른 노드로 옮겨가도 데이터가 그대로 유지되는 것을 확인할 수 있습니다. 💡

    ⚠️ 삽질 경험: 주의사항 및 트러블슈팅

    제가 Longhorn을 운영하면서 겪었던 몇 가지 삽질 경험과 주의사항을 공유해드릴게요. 독자분들은 저처럼 고생하지 마시라고요! ㅎㅎ

    • iSCSI initiator 문제: 가장 흔한 문제 중 하나입니다. 노드에 iscsi-initiator-utils나 open-iscsi가 설치되어 있지 않거나, iscsid 서비스가 실행 중이 아니라서 볼륨 마운트가 실패하는 경우가 많습니다. 꼭 설치 여부와 서비스 상태를 확인해주세요!
    • 네트워크 대역폭: Longhorn은 데이터를 여러 노드에 복제하기 때문에, 노드 간 네트워크 대역폭이 충분해야 합니다. 네트워크가 느리면 볼륨 성능 저하로 이어질 수 있습니다. 특히 홈랩 환경에서는 유선 네트워크를 사용하는 것이 좋습니다.
    • 디스크 공간 관리: Longhorn은 노드의 가용 디스크 공간을 사용합니다. 볼륨을 너무 많이 생성하거나 스냅샷을 자주 찍으면 노드의 디스크 공간이 부족해질 수 있습니다. Longhorn UI에서 각 노드의 디스크 사용량을 주기적으로 확인하고, 불필요한 스냅샷이나 백업은 정리하는 습관을 들이는 것이 좋습니다.
    • 노드 드레인(Drain) 시 주의: 쿠버네티스 노드를 유지보수할 때 kubectl drain 명령을 사용하죠. Longhorn 볼륨이 마운트된 파드가 있는 노드를 드레인할 때는 Longhorn이 해당 볼륨을 다른 노드로 안전하게 옮길 수 있도록 충분한 시간을 주어야 합니다. 급하게 드레인하면 볼륨이 Faulted 상태가 될 수도 있더라고요.

    ✅ 검증 및 결과: Longhorn 볼륨 확인하기

    모든 설치와 설정이 끝났으니, 이제 제대로 작동하는지 확인해볼 차례입니다. 저는 Nginx 파드에 접속해서 간단한 HTML 파일을 만들어보고, 파드를 삭제 후 다시 생성하여 데이터 영속성을 확인하는 방법을 즐겨 씁니다.

    
    # Nginx 파드 이름 확인
    kubectl get pods -l app=nginx
    
    # Nginx 파드 내부로 접속하여 파일 생성
    kubectl exec -it <nginx-pod-name> -- bash
    echo "Hello from Longhorn!" > /usr/share/nginx/html/index.html
    exit
    
    # Nginx 서비스 포트 포워딩 (테스트용)
    kubectl port-forward svc/<nginx-service-name> 8080:80 # Nginx 서비스가 없다면 배포해야 합니다.
    
    # 웹 브라우저에서 http://localhost:8080 접속하여 내용 확인
    

    이제 Nginx 파드를 삭제했다가 다시 생성해보세요. 그리고 다시 접속해보면, 이전에 작성했던 “Hello from Longhorn!” 메시지가 그대로 남아있는 것을 확인할 수 있을 겁니다. 🎉 드디어 영구적인 스토리지를 성공적으로 구축한 거죠!

    Nginx 파드에 마운트된 Longhorn 볼륨과 데이터 영속성 확인 화면

    이미지 캡션: Nginx 파드에 성공적으로 마운트된 Longhorn 볼륨과 데이터 영속성을 확인하는 모습. 웹 브라우저를 통해 저장된 내용을 확인하고 있습니다.

    마무리: 13년차 서버실 지킴이의 한마디

    오늘은 Kubernetes Longhorn(쿠버네티스 롱혼) 스토리지의 설치부터 운영까지 제가 직접 경험한 내용을 바탕으로 자세히 설명해드렸습니다. Longhorn은 쿠버네티스 환경에서 영구 볼륨(Persistent Volume)을 안정적이고 유연하게 제공하는 훌륭한 분산 스토리지 솔루션이라고 생각합니다. 특히 홈랩이나 소규모 클러스터 환경에서는 초기 구축 비용이나 복잡성 측면에서 다른 엔터프라이즈 솔루션보다 훨씬 매력적이죠. 저는 Longhorn 덕분에 홈랩에서 다양한 스테이트풀 애플리케이션들을 걱정 없이 운영하고 있습니다. 백업과 스냅샷 기능도 정말 유용하구요!

    물론 Longhorn도 만능은 아닙니다. 대규모 엔터프라이즈 환경에서는 Ceph(세프)나 NetApp(넷앱) 같은 더욱 강력하고 복잡한 솔루션들이 필요할 수도 있습니다. 하지만 “간단하게 시작해서 점진적으로 확장하고 싶다”는 분들에게는 Longhorn이 정말 좋은 선택지가 될 거라고 확신합니다. 제 경험상, 중요한 건 어떤 툴을 쓰느냐보다, 그 툴을 얼마나 잘 이해하고 자신의 환경에 맞게 활용하느냐인 것 같아요. 저도 아직 배워야 할 게 많지만, 계속해서 새로운 기술들을 실험하고 삽질하면서 여러분께 유용한 정보를 공유해드리겠습니다.

    다음 글에서는 Longhorn의 백업 및 복구 기능에 대해 더 자세히 다뤄보거나, Longhorn 볼륨의 성능 튜닝 방법에 대해 이야기해볼까 합니다. 궁금한 점이 있다면 언제든지 댓글로 남겨주세요! 다음에 또 유익한 정보로 찾아뵙겠습니다. 감사합니다! 😊

    Longhorn 주요 특징, 장단점 및 다른 쿠버네티스 스토리지 솔루션 비교 인포그래픽

    이미지 캡션: Longhorn의 주요 특징과 장단점을 요약한 인포그래픽. 쿠버네티스 스토리지 선택에 있어 Longhorn의 위치를 보여줍니다.