Longhorn 은 각 노드의 로컬 디스크를 모아 Kubernetes 에 블록 스토리지를 제공한다. 볼륨 하나는 엔진 프로세스 하나와 복제본(replica) 여럿으로 이루어지고, 복제본은 서로 다른 노드에 흩어진다. 운영 중에 자주 부딪히는 것은 세 가지다 — 볼륨이 Faulted 로 떨어지는 것, 실제 사용량이 선언한 용량보다 커지는 것, 그리고 확장이 거부되는 것이다.
정상 복제본이 하나도 남지 않으면 볼륨이 Faulted 가 된다. 노드가 갑자기 죽었거나, 복제본이 있던 디스크가 고장 났거나, 여러 노드가 동시에 재부팅된 뒤에 나타난다.
상태를 먼저 확인한다.
kubectl -n longhorn-system get volumes.longhorn.io
kubectl -n longhorn-system describe volumes.longhorn.io <volume-name>
kubectl -n longhorn-system get replicas.longhorn.io -l longhornvolume=<volume-name>
kubectl get volumes 만 쓰면 다른 API 그룹과 이름이 겹칠 수 있으므로 volumes.longhorn.io 로 적는 편이 안전하다.
Longhorn 은 기본적으로 자동 복구를 켜 둔다. 남아 있는 복제본 가운데 가장 최신 것을 골라 볼륨을 Detached 로 되돌린다.
kubectl -n longhorn-system get settings.longhorn.io auto-salvage -o jsonpath='{.value}'
꺼져 있으면 켠다.
kubectl -n longhorn-system patch settings.longhorn.io auto-salvage --type=merge -p '{"value":"true"}'
자동 복구가 되지 않으면 Longhorn UI 의 볼륨 화면에서 Salvage 를 눌러 복제본을 직접 고른다. Salvage 는 손상된 복제본을 버리고 남은 것으로 볼륨을 다시 세우는 작업이므로, 어느 복제본을 고르느냐에 따라 유실되는 구간이 달라진다. UI 는 복제본별 마지막 갱신 시각을 보여 주므로 그것을 보고 고른다.
CLI 로 Salvage 를 거는 방법은 Longhorn 버전에 따라 다르다 (확인 필요). 인터넷에 도는 longhorn.io/volume-salvage 애노테이션은 공식 문서에서 확인되지 않는다. 복구 경로는 UI 또는 auto-salvage 설정을 쓰는 것이 안전하다.
Salvage 이후 볼륨은 Detached 가 된다. 워크로드를 다시 띄우면 붙는다.
kubectl -n <namespace> scale deployment/<name> --replicas=1
정상 복제본이 하나도 없으면 Salvage 도 실패한다. 이때는 백업에서 복원하는 길밖에 없다. 그래서 Longhorn 을 쓰는 클러스터는 백업 타깃(S3 또는 NFS)과 반복 백업 일정을 반드시 걸어 둔다.
480Gi 짜리 PV 인데 Longhorn UI 의 Actual Size 가 700Gi 를 넘는 일이 있다. 고장이 아니라 설계상 그렇다.
TRIM 이 전달되어야 Longhorn 이 공간을 되돌려 받는다.스냅샷부터 정리한다. UI 의 볼륨 상세 화면에서 스냅샷 트리를 보고 필요 없는 것을 지운 뒤, 삭제 표시된 스냅샷을 실제로 합치도록 한다. 되풀이 작업의 retain 값이 과하면 그것부터 줄인다.
그다음 파일시스템을 trim 한다. Longhorn v1.4 이후 UI 에 Trim Filesystem 동작이 있다. 볼륨이 붙어 있는 상태에서 실행한다.
# 워크로드 파드 안에서 직접 거는 방법
kubectl -n <namespace> exec -it <pod> -- fstrim -v /data
fstrim 이 통하려면 마운트된 파일시스템이 discard 를 지원해야 한다. XFS · ext4 는 지원한다.
PVC 를 키웠는데 Longhorn 이 405 Method Not Allowed 를 돌려주는 경우다. 세 가지를 순서대로 본다.
StorageClass 에 확장 허용이 없다.
kubectl get sc longhorn -o jsonpath='{.allowVolumeExpansion}'
true 가 아니면 확장 요청 자체가 막힌다. StorageClass 는 이 필드를 나중에 바꿀 수 있지만, 이미 만들어진 PVC 에 반영되려면 PV 쪽도 확인해야 한다.
Longhorn 버전이 온라인 확장을 지원하지 않는다. v1.4 이전에는 볼륨이 붙어 있는 동안에는 확장할 수 없어 워크로드를 내려 Detached 로 만든 뒤에야 가능했다. v1.4 이상은 붙어 있는 상태에서도 확장된다. 쓰고 있는 버전을 먼저 본다.
kubectl -n longhorn-system get daemonset longhorn-manager -o jsonpath='{.spec.template.spec.containers[0].image}'
오래된 버전이면 내렸다가 확장한다.
kubectl -n <namespace> scale deployment/<name> --replicas=0
kubectl -n <namespace> patch pvc <pvc-name> --type=merge \
-p '{"spec":{"resources":{"requests":{"storage":"600Gi"}}}}'
kubectl -n <namespace> scale deployment/<name> --replicas=1
줄이려 했다. Kubernetes 는 PVC 축소를 지원하지 않는다. 요청 값이 현재보다 작으면 거부된다.
확장 뒤 파일시스템까지 늘어났는지는 파드 안에서 확인한다. 자동으로 늘지 않으면 resize2fs 또는 xfs_growfs 를 건다.
파드가 Insufficient Storage 또는 복제본 스케줄 실패로 뜨는 경우, 남은 것은 클러스터 전체 용량이 아니라 각 노드 디스크의 여유다. Longhorn 은 복제본을 서로 다른 노드에 두려 하므로, 노드 한 곳이 꽉 차면 복제본 수를 못 채운다.
UI 의 Node 화면에서 디스크별 Storage Available 과 Storage Scheduled 를 본다. 예약분이 실제 가용량을 넘지 않도록 하는 값이 두 개 있다.
storage-over-provisioning-percentage — 실제 용량 대비 얼마까지 예약을 허용할지.storage-minimal-available-percentage — 이 비율 아래로 남으면 그 디스크에는 더 배치하지 않는다.kubectl -n longhorn-system get settings.longhorn.io | grep -i storage
공간을 실제로 만들어야 하면 순서대로 확인한다 — 삭제 표시만 되고 남아 있는 스냅샷, 쓰이지 않는 백업, 이미 지운 워크로드의 PVC, 그리고 노드의 컨테이너 이미지 캐시다. 이미지 캐시는 Longhorn 과 같은 디스크를 쓰는 경우가 많다.
kubectl get pvc -A --field-selector=status.phase=Pending
crictl images prune