kaffa/obsidian
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity
Files
aec8891bac3aa1dcb8348186917da3818d26aa56
obsidian/history/2026-05-17-safeline-pvc-fsck-incompat.md

7.4 KiB
Raw Blame History

date, topic, areas
date topic areas
2026-05-17 SafeLine RWX PVC ext4 호환성 인시던트 — Longhorn v1.11.2 strict fsck 거부
infra/platform/longhorn
infra/security/crowdsec-safeline

2026-05-17 / SafeLine RWX PVC 손상 복구 — Longhorn 1.11.2 share-manager strict fsck

증상

/sc:test 클러스터 상태 점검 중 발견:

  • safeline-mgt Pod: CrashLoopBackOff (restart 1008회, 3일 15시간)
  • safeline-luigi Pod: Init:0/1 (43시간 wait, mgt:1443 폴링)
  • 그 외 SafeLine pods (chaos/database/detector/fvm) 정상

mgt 로그:

panic: failed to init models: init empty license error: database disk image is malformed (11)
  /work/initialize/pg_init.go:82
  SELECT * FROM `options` WHERE key = "license"

표면적으로는 SQLite SQLITE_CORRUPT(11). 실제 SafeLine 메인 DB(PostgreSQL safeline-database-0)는 정상.

근본 원인

mgt를 scale 0으로 내리고 디버그 pod로 PVC mount 시도하니 FailedAttachVolume "Waiting for volume share to be available" — Longhorn share-manager pod가 1초만에 Failed로 죽고 2분 backoff 사이클 반복. share-manager 로그 캡처:

/dev/longhorn/pvc-8534d9f3-...: Resize inode not valid.
UNEXPECTED INCONSISTENCY; RUN fsck MANUALLY.
        (i.e., without -a or -p options)
fatal: 'fsck' found errors on device but could not correct them

즉 ext4 superblock metadata 손상 (Resize inode not valid)으로 share-manager가 자동 모드 fsck (-a/-p)로 거부 → NFS export 못함 → 모든 PVC mount 실패.

2026-05-07-longhorn-1-11-2-upgrade 업그레이드에서 share-manager 이미지가 v1.11.2로 바뀌면서 fsck strict 모드로 동작. 옛 fs metadata와 호환성 깨진 것이 주범으로 판단. 실제 데이터는 정상일 가능성 매우 큼 (수동 fsck -y 한 번이면 풀림).

영향 받은 PVC

같은 시점에 만들어진 incus-hp2 노드의 RWX PVC 3개 모두 동일 패턴:

PVC 옛 PV 상태
safeline/safeline-mgt pvc-8534d9f3-91b9-49c3-9acd-804581c51893 Released (Retain 보존)
safeline/safeline-tengine-logs pvc-15af4f6d-6129-4858-ae51-a3aa3546c4c2 Released (Retain 보존)
safeline/safeline-luigi pvc-3c39ef90-d8ea-402d-8363-772ddbaf56a2 Released (Retain 보존)

같은 노드의 다른 RWX 4개 (chaos/detector/detector-logs/8f9bfed6)는 mount 유지 중이라 영향 없음 — 다음 재기동 시 동일 에러 가능성.

시도한 조치

  1. Longhorn snapshot revert (2026-05-13 16:03, 52eb920e, 손상 직전 시점) — 실패. blockdev revert로 ext4 metadata도 같이 복원되어 동일 fsck 에러 재현.
  2. PVC 폐기 + 동일 이름 새 PVC 생성 — 성공. 새 mkfs.ext4로 만들어진 fs는 strict fsck 통과.

복구 절차 (재사용 가능)

NS=safeline
NAME=safeline-mgt      # 손상 PVC 이름
SIZE=1Gi               # 동일 사이즈

# 1. 워크로드 내림
kubectl -n $NS scale deploy $NAME --replicas=0

# 2. PV reclaim Retain으로 변경 (포렌식용 보존)
PV=$(kubectl -n $NS get pvc $NAME -o jsonpath='{.spec.volumeName}')
kubectl patch pv $PV -p '{"spec":{"persistentVolumeReclaimPolicy":"Retain"}}'

# 3. PVC 삭제 (PV는 Released 상태로 살아남음)
kubectl -n $NS delete pvc $NAME

# 4. 동일 이름 새 PVC 생성
cat <<EOF | kubectl apply -f -
apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: $NAME
  namespace: $NS
spec:
  accessModes: [ReadWriteMany]
  resources:
    requests:
      storage: $SIZE
  storageClassName: longhorn
  volumeMode: Filesystem
EOF

# 5. 워크로드 올림
kubectl -n $NS scale deploy $NAME --replicas=1

데이터 영향

  • mgt: 라이선스/룰/설정 초기화 → SafeLine UI 첫 로그인 + 라이선스 재입력 필요. WAF 검출 룰 정본은 PG에 있으므로 검출 자체는 그대로 동작.
  • tengine-logs: nginx access log 손실 (가치 없음).
  • luigi: 검출 캐시 손실, 정본은 PG.

옛 PV 데이터 복구 가능성

3개 옛 PV는 reclaim Retain으로 Released 상태 보존 중. 향후 시간 있을 때 fsck.ext4 -y /dev/longhorn/pvc-... 로 메타 복구 후 디버그 pod에 mount해서 데이터 추출 시도 가능. 특히 mgt 라이선스 파일(/app/data/license) 회수 가능성.

Longhorn HTTP API 작업 노트

snapshot revert 시도 시 사용. port-forward는 longhorn-manager 포트 9500이 0.0.0.0이 아닌 다른 인터페이스에 bind되어 macOS에서 직접 forward 실패 → in-cluster pod에서 호출 필요.

# in-cluster curl pod
kubectl -n longhorn-system run lh-curl --image=curlimages/curl:8.10.1 \
  --command -- sleep 7200

# Volume detach → maintenance attach → snapshot revert
VOL=pvc-XXX
LH=http://longhorn-backend:9500
kubectl -n longhorn-system exec lh-curl -- sh -c "
  curl -X POST $LH/v1/volumes/$VOL?action=detach -d '{}'
  curl -X POST $LH/v1/volumes/$VOL?action=attach \
    -d '{\"hostId\":\"<node>\",\"disableFrontend\":true,\"attachedBy\":\"manual\"}'
  curl -X POST $LH/v1/volumes/$VOL?action=snapshotRevert \
    -d '{\"name\":\"snapshot-<uuid>\"}'
  curl -X POST $LH/v1/volumes/$VOL?action=detach -d '{}'
"

잠재 위험 (TODO)

  • 같은 노드/같은 시점 mkfs된 다른 RWX 볼륨도 share-manager 재기동 시 동일 에러 가능. 사전 점검 가치 있음 — 한 번씩 detach/reattach 사이클 돌려 fail하는 PVC 식별 후 미리 교체.
  • 또는 share-manager의 fsck 옵션을 -y로 patch (Longhorn 자체 코드 수정 필요, upstream 이슈로 보고 권장).

2026-05-18 후속 — detector PVC 폭발 (예측 적중)

어제 명시한 4개 위험 PVC 중 safeline/safeline-detector (옛 PV pvc-8f9bfed6)가 2026-05-17 23:12 KST부터 6시간 이상 VolumeAttachment finalizer hang (Waiting for volume share to be available) 후 2026-05-18 14:18 KST 동일 절차로 복구됨. 신규 PV pvc-d2654f70-01e2-4a40-8336-1b56ddacb2cb 바인딩, detector 파드 정상 기동(rskynet hyperscan 47 패턴 로드, NFSv4.1 클라이언트 정상 등록). 데이터 영향 없음(detector PVC는 룰셋/캐시, 이미지에 포함).

복구 actor 미상 — helm/Argo 변경 없음(generation/RS 변동 없음), K3s audit log 부재로 PVC 삭제 호출자 식별 불가. csi-plugin이 attach 강제 시도까지는 자동, PVC delete/recreate는 사람 또는 다른 자동화로 추정.

남은 시간폭탄

PVC PV 노드 mkfs 시점 위험
safeline/safeline-chaos pvc-0440758f-f056-46d0-9733-dbb77f2e9101 incus-hp2 55d (2026-03-24) 다음 share-manager 재기동 시 동일 ext4 fsck 거부 예상
safeline/safeline-detector-logs pvc-384dd143-05b6-4cd6-a0dd-3edf5dca3acc incus-hp2 55d (2026-03-24) 동일

어제 위험 명단의 detector와 8f9bfed6은 동일 PVC(safeline-detector)에 옛 PV였고 이번에 해소됨. 남은 둘은 어제 절차로 사전 교체 가능 — 데이터 가치 낮음(chaos = 검출 룰 캐시 / detector-logs = nginx access 로그).

학습

  • v1.11.2 share-manager strict fsck는 옛 ext4 metadata와 호환 안 됨 — 같은 시점 mkfs된 RWX 볼륨은 share-manager 재기동을 절대 트리거하지 말거나 사전에 강제 교체해야 함.
  • 같은 노드 RWX share-manager 6개 집중 위험은 별건 — incus-hp2 share-manager 이슈 시 SafeLine 전체 영향.

관련

Reference in New Issue View Git Blame Copy Permalink