1. Longhorn 볼륨 파일 시스템 손상 시 Pod 생성 중단
해당 버전
모든 Longhorn 버전
증상
Pod가 Creating 상태에 머물며, 로그에 다음과 같은 오류가 기록됩니다.
Warning FailedMount 30s (x7 over 63s) kubelet MountVolume.SetUp failed for volume "pvc-bb8582d5-eaa4-479a-b4bf-328d1ef1785d" : rpc error: code = Internal desc = 'fsck' found errors on device /dev/longhorn/pvc-bb8582d5-eaa4-479a-b4bf-328d1ef1785d but could not correct them: fsck from util-linux 2.31.1
ext2fs_check_if_mount: Can't check if filesystem is mounted due to missing mtab file while determining whether /dev/longhorn/pvc-bb8582d5-eaa4-479a-b4bf-328d1ef1785d is mounted.
/dev/longhorn/pvc-bb8582d5-eaa4-479a-b4bf-328d1ef1785d contains a file system with errors, check forced.
/dev/longhorn/pvc-bb8582d5-eaa4-479a-b4bf-328d1ef1785d: Inodes that were part of a corrupted orphan linked list found.
/dev/longhorn/pvc-bb8582d5-eaa4-479a-b4bf-328d1ef1785d: UNEXPECTED INCONSISTENCY; RUN fsck MANUALLY. (i.e., without -a or -p options)원인
Longhorn 볼륨의 파일 시스템이 손상되면 Longhorn이 해당 볼륨을 다시 마운트할 수 없으며, 결국 워크로드가 재시작되지 않습니다. Longhorn은 이 문제를 자동으로 복구할 수 없으며, 수동 조치가 필요합니다.
해결 방법
- 증상 확인:
- Longhorn UI에서 볼륨이
error상태인지 확인합니다. - Longhorn 매니저 Pod 로그에서 파일 시스템 손상 관련 오류 메시지를 확인합니다.
볼륨이
error상태가 아니라면, 외부 요인에 의해 파일 시스템이 손상되었을 가능성이 있습니다. - Longhorn UI에서 볼륨이
- 워크로드 스케일 다운
- UI를 통해 볼륨을 아무 노드에 연결
- 해당 노드에 SSH 접속
/dev/longhorn/디렉터리에서 Longhorn 볼륨에 해당하는 블록 장치를 찾습니다.fsck명령어를 실행하여 파일 시스템을 복구합니다.- UI에서 볼륨 분리
- 워크로드 스케일 업
2. 비표준 Kubelet 디렉터리
해당 버전
모든 Longhorn 버전
증상
Kubernetes 클러스터가 비표준 Kubelet 디렉터리를 사용하는 경우, longhorn-csi-plugin이 시작되지 않습니다.
ip-172-30-0-73:/home/ec2-user # kubectl -n longhorn-system get pod
NAME READY STATUS RESTARTS AGE
longhorn-ui-5b864949c4-4sgws 1/1 Running 0 7m35s
longhorn-manager-tx469 1/1 Running 0 7m35s
longhorn-driver-deployer-5444f75b8f-kgq5v 1/1 Running 0 7m35s
longhorn-csi-plugin-s4fg7 0/2 ContainerCreating 0 6m59s
instance-manager-r-d185a1e9 1/1 Running 0 7m10s
instance-manager-e-b5e69e2d 1/1 Running 0 7m10s원인
Longhorn이 Kubelet의 루트 디렉터리 위치를 감지하지 못하기 때문입니다.
해결 방법
longhorn.yaml을 통해 설치한 경우:
다음 줄의 주석 처리를 제거하고 값을 편집합니다.
#- name: KUBELET_ROOT_DIR
# value: /var/lib/rancher/k3s/agent/kubeletRancher App을 통해 설치한 경우:
"Customize Default Settings"에서 Kubelet 루트 디렉터리를 설정합니다.
관련 정보
- Longhorn 이슈: #2537
- 운영체제/배포판별 추가 설정 관련 내용은 문제 해결 문서의 "OS/Distro Specific Configuration" 부분을 참고하세요.
3. Longhorn 기본 설정 유지 안 됨
해당 버전
모든 Longhorn 버전
증상
- Helm 또는 Rancher App을 통해 Longhorn 시스템을 업그레이드할 때, 수정된 기본 설정이 유지되지 않습니다.
kubectl -n longhorn-system edit configmap longhorn-default-setting명령어로 기본 설정을 수정해도 변경 사항이 적용되지 않습니다.
배경
기본 설정은 아직 배포되지 않은 Longhorn 시스템에만 적용됩니다. 기존 시스템에는 영향을 미치지 않습니다.
해결 방법
기존 클러스터의 Longhorn 설정을 변경하려면 Longhorn UI를 사용하는 것이 좋습니다. kubectl을 사용할 수도 있지만, 이 경우 Longhorn 백엔드의 검증 과정을 우회한다는 점에 유의해야 합니다.
kubectl edit settings <설정 이름> -n longhorn-system4. 볼륨 분리 후 재연결 시 Recurring Job 생성 안 됨
해당 버전
모든 Longhorn 버전
증상
볼륨이 오랜 시간 분리되었다가 다시 연결되면, Recurring Job이 새로운 Job을 생성하지 않습니다.
Kubernetes CronJob의 제한 사항(참고)에 따르면, CronJob 컨트롤러는 마지막 스케줄 시간부터 현재까지 누락된 스케줄 수를 확인합니다. 만약 누락된 스케줄이 100개를 초과하면 Job을 시작하지 않고 오류를 기록합니다.
Cannot determine if job needs to be started. Too many missed start time (> 100). Set or decrease .spec.startingDeadlineSeconds or check clock skew.이는 Recurring Job이 허용할 수 있는 분리/연결 작업의 지속 시간이 스케줄 간격에 따라 달라짐을 의미합니다. 예를 들어, Recurring Backup Job이 1분마다 실행되도록 설정된 경우, 허용 시간은 100분입니다.
해결 방법
중단된 CronJob을 직접 삭제하고 Longhorn이 다시 생성하도록 합니다.
ip-172-30-0-211:/home/ec2-user # kubectl -n longhorn-system get cronjobs
NAME SCHEDULE SUSPEND ACTIVE LAST SCHEDULE AGE
pvc-394e6006-9c34-47da-bf27-2286ae669be1-c-ptl8l1-c * * * * * False 1 47s 2m23s
ip-172-30-0-211:/home/ec2-user # kubectl -n longhorn-system delete cronjobs/pvc-394e6006-9c34-47da-bf27-2286ae669be1-c-ptl8l1-c
cronjob.batch "pvc-394e6006-9c34-47da-bf27-2286ae669be1-c-ptl8l1-c" deleted
ip-172-30-0-211:/home/ec2-user # kubectl -n longhorn-system get cronjobs
No resources found in longhorn-system namespace.
ip-172-30-0-211:/home/ec2-user # sleep 60
ip-172-30-0-211:/home/ec2-user # kubectl -n longhorn-system get cronjobs
NAME SCHEDULE SUSPEND ACTIVE LAST SCHEDULE AGE
pvc-394e6006-9c34-47da-bf27-2286ae669be1-c-ptl8l1-c * * * * * False 1 2s 3m21s관련 정보
- Longhorn 이슈: #2513
5. Traefik 2.x를 Ingress Controller로 사용
해당 버전
모든 Longhorn 버전
증상
Longhorn GUI 프론트엔드 API 요청이 longhorn-manager 백엔드에 도달하지 못하는 경우가 발생합니다.
원인
API 요청이 HTTPS/WSS 간 프로토콜을 변경하면서 CORS 문제가 발생하기 때문입니다.
해결 방법
Traefik 2.x Ingress Controller는 WebSocket 헤더를 자동으로 설정하지 않습니다. 따라서 Longhorn 프론트엔드 서비스 라우트에 다음과 같은 미들웨어를 추가해야 합니다.
apiVersion: traefik.containo.us/v1alpha1
kind: Middleware
metadata:
name: svc-longhorn-headers
namespace: longhorn-system
spec:
headers:
customRequestHeaders:
X-Forwarded-Proto: "https"그런 다음 Ingress에 미들웨어 규칙을 적용합니다.
apiVersion: networking.k8s.io/v1beta1
kind: Ingress
metadata:
name: longhorn-ingress
namespace: longhorn-system
annotations:
traefik.ingress.kubernetes.io/router.entrypoints: websecure
traefik.ingress.kubernetes.io/router.tls: "true"
traefik.ingress.kubernetes.io/router.middlewares: longhorn-system-svc-longhorn-headers@kubernetescrd
spec:
rules:
- http:
paths:
- path: /
backend:
serviceName: longhorn-frontend
servicePort: 80관련 정보
- Longhorn 이슈 코멘트: #1442
6. cURL을 사용한 Support Bundle 생성
해당 버전
모든 Longhorn 버전
증상
웹 브라우저를 통해 Support Bundle을 생성할 수 없습니다.
해결 방법
- Longhorn 백엔드 서비스를 외부에 노출합니다. 다음은 NodePort를 사용하는 예시입니다. 로드 밸런서가 설정되어 있다면 해당 주소를 사용할 수도 있습니다.
ip-172-30-0-21:~ # kubectl -n longhorn-system patch svc longhorn-backend -p '{"spec": {"type":"NodePort"}}'
service/longhorn-backend patched
ip-172-30-0-21:~ # kubectl -n longhorn-system get svc/longhorn-backend
NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE
longhorn-backend NodePort 10.43.136.157 <none> 9500:32595/TCP 156m- 다음 스크립트를 실행하여 Support Bundle을 생성하고 다운로드합니다.
BACKEND_URL,ISSUE_URL,ISSUE_DESCRIPTION을 적절히 변경해야 합니다.
# 이 블록을 변경하세요 ====>
BACKEND_URL="18.141.237.97:32595"
ISSUE_URL="https://github.com/longhorn/longhorn/issues/dummy"
ISSUE_DESCRIPTION="dummy description"
# <==== 이 블록을 변경하세요
# Support Bundle 생성을 요청합니다.
REQUEST_SUPPORT_BUNDLE=$( curl -sSX POST -H 'Content-Type: application/json' -d '{ "issueURL": "'"${ISSUE_URL}"'", "description": "'"${ISSUE_DESCRIPTION}"'" }' http://${BACKEND_URL}/v1/supportbundles )
ID=$( jq -r '.id' <<< ${REQUEST_SUPPORT_BUNDLE} )
SUPPORT_BUNDLE_NAME=$( jq -r '.name' <<< ${REQUEST_SUPPORT_BUNDLE} )
echo "Creating support bundle ${SUPPORT_BUNDLE_NAME} on Node ${ID}"
while [ $(curl -sSX GET http://${BACKEND_URL}/v1/supportbundles/${ID}/${SUPPORT_BUNDLE_NAME} | jq -r '.state' ) != "ReadyForDownload" ]; do
echo "Progress: $(curl -sSX GET http://${BACKEND_URL}/v1/supportbundles/${ID}/${SUPPORT_BUNDLE_NAME} | jq -r '.progressPercentage' )%"
sleep 1s
done
curl -i -X GET http://${BACKEND_URL}/v1/supportbundles/${ID}/${SUPPORT_BUNDLE_NAME}/download --output /tmp/${SUPPORT_BUNDLE_NAME}.zip
echo "Downloaded support bundle to /tmp/${SUPPORT_BUNDLE_NAME}.zip"관련 정보
- Longhorn 이슈 코멘트: #2118
7. Longhorn RWX 공유 마운트 소유권이 Consumer Pod에서 nobody로 표시됨
해당 버전
Longhorn v1.1.0
증상
Pod가 RWX 볼륨을 마운트할 때, 공유 마운트 디렉터리 및 그 하위 항목의 소유권이 nobody로 표시되지만, share-manager 내에서는 root로 표시됩니다.
root@ip-172-30-0-139:/home/ubuntu# kubectl exec -it rwx-test-2pml2 -- ls -l /data
total 16
drwx------ 2 nobody 42949672 16384 Mar 31 04:16 lost+found
root@ip-172-30-0-139:~# kubectl -n longhorn-system exec -it share-manager-pvc-f3775852-1e27-423f-96ab-95ccd04e4777 -- ls -l /export/pvc-f3775852-1e27-423f-96ab-95ccd04e4777
total 16
drwx------ 2 root root 16384 Mar 31 04:42 lost+found배경
share-manager의 nfs-ganesha는 NFSv4 ID 매핑을 위해 idmapd를 사용하며, Export 도메인으로 localdomain을 사용하도록 설정되어 있습니다.
원인
클라이언트(호스트)와 서버(share-manager) 간 /etc/idmapd.conf의 내용이 일치하지 않아 소유권이 변경됩니다. 예를 들어, 클러스터 호스트의 /etc/idmapd.conf에서 Domain = localdomain이 주석 처리되어 있고, 기본값으로 FQDN에서 호스트 이름을 뺀 값을 사용하는 경우, share-manager의 도메인(localdomain)과 호스트의 도메인(예: lan)이 달라져 파일 권한이 nobody로 변경됩니다.
해결 방법
- 모든 클러스터 호스트의
/etc/idmapd.conf에서Domain = localdomain의 주석을 제거하거나 추가합니다.
root@ip-172-30-0-139:~# cat /etc/idmapd.conf
[General]
Verbosity = 0
Pipefs-Directory = /run/rpc_pipefs
# set your own domain here, if it differs from FQDN minus hostname
Domain = localdomain
[Mapping]
Nobody-User = nobody
Nobody-Group = nogroup- RWX 리소스 스택(PVC + Pod)을 삭제하고 다시 생성합니다.
root@ip-172-30-0-139:/home/ubuntu# kubectl exec -it volume-test -- ls -l /data
total 16
drwx------ 2 root root 16384 Mar 31 04:42 lost+found관련 정보
- Longhorn 이슈: #2357
- idmapd.conf 문서: https://linux.die.net/man/5/idmapd.conf
8. 노드의 다중 경로( multipath)로 인한 볼륨 마운트 실패
해당 버전
모든 Longhorn 버전
증상
볼륨을 사용하는 Pod가 시작되지 않고, longhorn-csi-plugin에서 다음과 같은 오류가 발생합니다.
time="2020-04-16T08:49:27Z" level=info msg="GRPC request: {\"target_path\":\"/var/lib/kubelet/pods/cf0a0b5b-106e-4793-a74a-28bfae21be1a/volumes/kubernetes.io~csi/pvc-d061512e-870a-4ece-bd45-2f04672d5256/mount\",...}"
...
E0416 08:49:27.567704 1 mount_linux.go:143] Mount failed: exit status 32
Mounting command: mount
Mounting arguments: -t ext4 -o defaults /dev/longhorn/pvc-d061512e-870a-4ece-bd45-2f04672d5256 /var/lib/kubelet/pods/cf0a0b5b-106e-4793-a74a-28bfae21be1a/volumes/kubernetes.io~csi/pvc-d061512e-870a-4ece-bd45-2f04672d5256/mount
Output: mount: /var/lib/kubelet/pods/cf0a0b5b-106e-4793-a74a-28bfae21be1a/volumes/kubernetes.io~csi/pvc-d061512e-870a-4ece-bd45-2f04672d5256/mount: /dev/longhorn/pvc-d061512e-870a-4ece-bd45-2f04672d5256 already mounted or mount point busy.상세 설명
이는 다중 경로 데몬이 명시적으로 블랙리스트에 추가되지 않은 모든 Longhorn 볼륨 장치를 포함하여 조건에 맞는 모든 장치 경로에 대해 다중 경로 장치를 생성하기 때문에 발생합니다.
문제 해결
- Longhorn 장치의
major:minor번호를 찾습니다. 노드에서ls -l /dev/longhorn/을 실행합니다.
ls -l /dev/longhorn
brw-rw---- 1 root root 8, 32 Aug 10 21:50 pvc-39c0db31-628d-41d0-b05a-4568ec02e487- Linux가 동일한
major:minor번호에 대해 생성한 장치를 찾습니다.ls -l /dev를 사용하여 동일한 번호의 장치(예:/dev/sde)를 찾습니다.
brw-rw---- 1 root disk 8, 32 Aug 10 21:50 sdc- 프로세스를 찾습니다.
lsof를 사용하여 사용 중인 파일 핸들러 목록을 가져온 후,grep으로 장치 이름(예:sde또는/dev/longhorn/xxx)을 필터링합니다.
lsof | grep sdc
multipath 514292 root 8r BLK 8,32 0t0 534 /dev/sdc
multipath 514292 514297 multipath root 8r BLK 8,32 0t0 534 /dev/sdc해결 방법
다중 경로 데몬이 Longhorn에서 생성한 추가 블록 장치를 추가하지 못하도록 방지합니다.
lsblk를 사용하여 Longhorn이 생성한 장치를 확인합니다.
root@localhost:~# lsblk
NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINT
sda 8:0 0 79.5G 0 disk /
sdb 8:16 0 512M 0 disk [SWAP]
sdc 8:32 0 1G 0 disk /var/lib/kubelet/pods/.../mount
sdd 8:48 0 1G 0 disk /var/lib/kubelet/pods/.../mountLonghorn 장치 이름은 /dev/sd[x]로 시작합니다.
- 기본 설정 파일
/etc/multipath.conf가 없으면 생성하고, 블랙리스트 섹션에 다음 줄을 추가합니다.
blacklist {
devnode "^sd[a-z0-9]+"
}- 다중 경로 서비스를 재시작합니다.
systemctl restart multipathd.service- 설정이 적용되었는지 확인합니다.
multipath -t다중 경로 블랙리스트 섹션의 기본 설정은 기본적으로 다음 장치 이름을 차단합니다: ^(ram|raw|loop|fd|md|dm-|sr|scd|st|dcssblk)[0-9], ^(td|hd|vd)[a-z]
관련 정보
- Longhorn 이슈: #1210
- 매뉴얼: http://manpages.org/multipathconf/5
9. Longhorn UI WebSocket 핸드셰이크 오류
해당 버전
기존 Longhorn 버전 < v1.1.0에서 Longhorn >= v1.1.0으로 업그레이드한 경우
증상
Longhorn을 v1.1.0 이상으로 업그레이드한 후, Ingress 로그와 Longhorn UI 로그에 다음과 같은 메시지가 나타납니다.
Ingress 로그:
{"level":"error","msg":"vulcand/oxy/forward/websocket: Error dialing \"10.17.1.246\": websocket: bad handshake with resp: 200 200 OK","time":"2021-03-09T08:29:03Z"}Longhorn UI 로그:
10.46.0.3 - - [19/Feb/2021:11:33:24 +0000] "GET /node/v1/ws/1s/engineimages HTTP/1.1" 200 578 "-" "Mozilla/5.0 ..."원인
v1.1.0부터 Longhorn UI는 다양한 라우팅 방식을 지원하기 위해 해시 히스토리(hash history)를 사용하도록 재구성되었습니다. 이로 인해 URL 경로가 /<TAG>에서 /#/<TAG>로 변경되었으며, 기존 Ingress 설정이 이를 처리하지 못하여 WebSocket 오류가 발생합니다.
해결 방법
- 브라우저 캐시를 지웁니다.
<LONGHORN_URL>/#주소로 Longhorn URL에 접근하거나 북마크를 다시 저장합니다.
관련 정보
10. Longhorn 볼륨 마운트 지연
해당 버전
모든 Longhorn 버전
증상
Longhorn 볼륨을 사용하는 워크로드 Pod를 시작할 때, Longhorn UI에서는 볼륨 연결이 빠르게 완료되지만, 실제 마운트가 완료되고 워크로드가 시작되기까지 오랜 시간이 걸립니다. 이 문제는 Longhorn 볼륨에 파일/디렉터리가 많고, 워크로드 Pod에 securityContext.fsGroup이 설정된 경우에 주로 발생합니다.
spec:
securityContext:
runAsUser: 1000
runAsGroup: 3000
fsGroup: 2000원인
Kubernetes는 fsGroup 필드가 설정되면 볼륨이 마운트될 때마다 볼륨 내의 모든 파일과 디렉터리에 대해 chown() 및 chmod()를 재귀적으로 호출합니다. 이는 볼륨의 그룹 소유권이 이미 요청된 fsGroup과 일치하는 경우에도 발생하며, 많은 수의 작은 파일을 포함하는 대용량 볼륨의 경우 Pod 시작 시간이 크게 지연될 수 있습니다.
해결 방법
Kubernetes v1.19.x 이전 버전에서는 해결 방법이 없습니다.
Kubernetes v1.20.x부터 fsGroupChangePolicy 필드(베타)가 도입되었습니다. 이 필드를 OnRootMismatch로 설정하면, 루트 디렉터리의 권한이 이미 올바른 경우 재귀적인 권한 및 소유권 변경을 건너뜁니다.
spec:
securityContext:
runAsUser: 1000
runAsGroup: 3000
fsGroup: 2000
fsGroupChangePolicy: "OnRootMismatch"관련 정보
- Longhorn 이슈: #2131
- Kubernetes 문서: fsGroupChangePolicy
11. 볼륨 읽기 전용 또는 I/O 오류
해당 버전
모든 Longhorn 버전
증상
애플리케이션이 Longhorn 볼륨의 마운트 지점에 데이터를 쓰거나 파일을 생성할 때 다음 오류가 발생합니다.
/ # cd data
/data # echo test > test
sh: can't create test: I/O error관련 Pod 또는 노드 호스트에서 dmesg를 실행하면 다음 메시지가 표시됩니다.
[1586907.286218] EXT4-fs (sdc): mounted filesystem with ordered data mode. Opts: (null)
[1587396.152106] EXT4-fs warning (device sdc): ext4_end_bio:323: I/O error 10 writing to inode 12 (offset 0 size 4096 starting block 33026)
...
[1587404.355087] EXT4-fs (sdc): Remounting filesystem read-onlykubectl -n longhorn-system get event | grep <볼륨 이름> 명령어로 이벤트를 확인하면 다음과 같은 이벤트가 표시됩니다.
2m26s Warning DetachedUnexpectly volume/pvc-342edde0-d3f4-47c6-abf6-bf8eeda3c32c Engine of volume pvc-342edde0-d3f4-47c6-abf6-bf8eeda3c32c dead unexpectedly, reattach the volume실패 원인
Longhorn 볼륨이 예기치 않게 중단되면(Engine crash) 마운트 지점이 무효화되어 읽기/쓰기가 불가능해집니다.
근본 원인
엔진 중단은 일반적으로 각 복제본과의 연결이 끊어져서 발생합니다. 가능한 원인은 다음과 같습니다.
- 노드의 CPU 사용률이 너무 높은 경우. Longhorn 엔진이 요청을 처리할 충분한 CPU 리소스를 확보하지 못하면 요청이 시간 초과되어 복제본과의 연결이 끊어질 수 있습니다.
- 네트워크 대역폭이 부족한 경우. 일반적으로 1Gbps 네트워크는 고집적 워크로드가 실행되는 경우 약 3개의 볼륨만 처리할 수 있습니다.
- 네트워크 지연 시간이 상대적으로 높은 경우. 하나의 노드에 여러 볼륨이 동시에 읽기/쓰기를 수행하는 경우, 지연 시간은 20ms 미만이어야 합니다.
- 네트워크 중단. 모든 복제본의 연결이 끊어지고 엔진이 중단될 수 있습니다.
- 디스크 성능이 너무 낮아 요청을 적시에 완료하지 못하는 경우. Longhorn 시스템에서는 낮은 IOPS의 디스크(예: 회전 디스크)를 사용하지 않는 것이 좋습니다.
자동 복구
v1.1.0 이전 Longhorn 버전에서는 Longhorn이 자동으로 볼륨을 다시 마운트하려고 시도하지만, 처리할 수 있는 시나리오가 제한적입니다.
Longhorn v1.1.0부터 "Automatically Delete Workload Pod when The Volume Is Detached Unexpectedly" 설정이 도입되어, Longhorn이 컨트롤러(Deployment, StatefulSet, DaemonSet 등)에 의해 관리되는 워크로드 Pod를 자동으로 삭제할 수 있습니다.
수동 복구
워크로드가 단순한 Pod인 경우 Pod를 삭제하고 다시 배포합니다. PVC/PV의 회수 정책이 Retain이 아닌 경우, 관련 PVC 또는 PV가 삭제되지 않도록 주의해야 합니다. 그렇지 않으면 Longhorn 볼륨이 삭제됩니다.
워크로드 Pod가 Deployment/StatefulSet에 속하는 경우, 워크로드 복제본을 축소했다가 다시 확장하여 Pod를 재시작할 수 있습니다.
Longhorn v1.1.0 이상에서는 "Automatically Delete Workload Pod when The Volume Is Detached Unexpectedly" 설정을 활성화할 수 있습니다.
기타 원인
관련 워크로드가 여전히 볼륨을 사용 중인 상태에서 사용자가 실수로 또는 의도적으로 Longhorn 볼륨을 분리한 경우입니다.
관련 정보
- 최소 리소스 요구 사항 조사 및 결과: #1691
- "Automatically Delete Workload Pod when The Volume Is Detached Unexpectedly" 설정 논의: #1719
12. 볼륨 스케줄링 실패
해당 버전
모든 Longhorn 버전
증상
Longhorn 볼륨을 PVC로 사용하는 Pod를 생성할 때 Pod가 시작되지 않습니다. kubectl describe <pod> 명령어로 오류를 확인하면 다음과 같은 메시지가 표시됩니다.
Warning FailedAttachVolume 4m29s (x3 over 5m33s) attachdetach-controller AttachVolume.Attach failed for volume "pvc-xxx" : rpc error: code = Internal desc = Bad response statusCode [500]. Status [500 Internal Server Error]. Body: [message=unable to attach volume pvc-xxx to node-xxx: volume pvc-xxx not scheduled, code=Server Error, detail=] from [http://longhorn-backend:9500/v1/volumes/pvc-xxx?action=attach]오류 메시지에는 volume pvc-xxx not scheduled라고 명시되어 있습니다.
상세 설명
이는 Longhorn이 볼륨 데이터를 저장할 충분한 공간을 다른 노드에서 찾지 못하여 볼륨 스케줄링이 실패했기 때문입니다.
가장 일반적인 원인
Longhorn v1.0.x의 기본 설치 설정은 다음과 같습니다.
Node Level Soft Anti-affinity: false- 기본 StorageClass
longhorn의 복제본 수가3으로 설정됨.
이는 Longhorn이 항상 세 개의 다른 노드에 세 개의 복제본을 위한 충분한 공간을 할당하려고 시도함을 의미합니다. 클러스터의 노드 수가 3개 미만인 경우와 같이 이 요구 사항을 충족할 수 없으면 볼륨 스케줄링이 실패합니다.
해결 방법
다음 중 하나를 선택하여 해결합니다.
Node Level Soft Anti-affinity를true로 설정합니다.- 복제본 수를
1또는2로 설정한 새 StorageClass를 생성합니다. - 클러스터에 노드를 더 추가합니다.
기타 원인
스케줄링 정책에 대한 자세한 설명은 Longhorn 문서의 스케줄링 섹션을 참조하세요. (링크)
관련 정보
Longhorn v1.1.0부터 Allow Volume Creation With Degraded Availability 설정(기본값: true)이 도입되어, 소규모 클러스터에서의 사용 사례를 지원합니다. (#1701)