Longhorn recurring job 라벨 오타 수정 + history 기록
critical/standard 18 볼륨이 recurringjob-group (대시 누락) 으로 라벨 붙어 3주간 백업 전무. recurring-job-group 으로 재라벨 + backup.md 에 라벨 키 규약 명시.
This commit is contained in:
heimdall
74
history/2026-04-15-longhorn-backup-label-typo.md
Normal file
74
history/2026-04-15-longhorn-backup-label-typo.md
Normal file
@@ -0,0 +1,74 @@
|
||||
---
|
||||
date: 2026-04-15
|
||||
topic: Longhorn recurring job 라벨 오타로 백업 전면 미동작
|
||||
areas: [infra/backup.md, infra/storage-plan.md]
|
||||
---
|
||||
|
||||
## 요약
|
||||
|
||||
2026-04-15 02:00 UTC 기준 점검에서 **critical/standard 그룹 recurring 백업·스냅샷이 약 3주간 전혀 실행되지 않고 있었음**을 발견. 원인은 Longhorn 볼륨에 부착된 라벨 키가 컨트롤러가 인식하는 형식과 달라서 그룹 셀렉터가 0건을 리턴.
|
||||
|
||||
## 증상
|
||||
|
||||
- BackupTarget `default` 는 AVAILABLE, R2 접근 정상
|
||||
- K8s CronJob `critical-snapshot/backup`, `standard-snapshot/backup` 발화 정상 (매시/6h/24h 주기)
|
||||
- 각 job pod 는 3~4초 내 Complete, 로그상 **`Found 0 volumes with recurring job <name>`**
|
||||
- 결과: production 볼륨 18개(critical 13 + standard 5) 전부 BackupVolume CR 미존재, R2 버킷에 e2e-test 3 볼륨·100KB 만 존재
|
||||
|
||||
## 근본 원인
|
||||
|
||||
운영 볼륨에 다음 라벨이 붙어 있었음:
|
||||
- `recurringjob-group.longhorn.io/critical=enabled`
|
||||
- `recurringjob-group.longhorn.io/standard=enabled`
|
||||
|
||||
Longhorn 1.8 recurring-job 컨트롤러가 기대하는 키는 **`recurring-job-group.longhorn.io/<group>`** (`recurring` 과 `job` 사이 대시 포함). 두 번째 형식은 완전히 다른 라벨로 간주되어 셀렉터 매칭 실패.
|
||||
|
||||
정상 키로 라벨링된 동일 그룹 볼륨은 0개였기에 어떤 recurring job 도 대상 볼륨을 찾지 못함.
|
||||
|
||||
### 유입 경로 조사
|
||||
|
||||
- Helm chart (longhorn 1.8.2): `helm get values longhorn` → null (기본값), 라벨 정의 없음
|
||||
- ArgoCD: longhorn 애플리케이션 없음 (Helm 직접 설치)
|
||||
- StorageClass `longhorn`/`longhorn-static`: `recurringJobSelector` 파라미터 없음
|
||||
- PVC metadata.labels: 해당 라벨 없음
|
||||
- ops-agents-tofu repo: grep 무결, runbook 에만 일반 설명
|
||||
- 기타 kaffa 소유 gitea repo (k3s-apps, helm-charts, k8s, infra-apps, runbooks, server-docs): grep 무결
|
||||
- obsidian vault: grep 무결
|
||||
|
||||
결론: 타이포 라벨은 **수동 `kubectl label` 또는 Longhorn UI** 로 볼륨마다 직접 부착된 것으로 추정. 업스트림 manifest 수정 불필요.
|
||||
|
||||
## 조치
|
||||
|
||||
1. 18개 volumes.longhorn.io 전체에 대해 재라벨:
|
||||
```bash
|
||||
kubectl -n longhorn-system label volumes.longhorn.io <vol> \
|
||||
recurringjob-group.longhorn.io/<group>- \
|
||||
recurring-job-group.longhorn.io/<group>=enabled --overwrite
|
||||
```
|
||||
실행 시각: 2026-04-15 01:37 UTC. 13 critical + 5 standard 전부 성공.
|
||||
|
||||
2. 01:44 UTC 수동 트리거 (`kubectl create job --from=cronjob/critical-snapshot ...`) 에서 **13 볼륨 전부 snapshot 생성** 확인. standard-snapshot 수동 트리거에서도 5 볼륨 전부 snapshot 생성.
|
||||
|
||||
3. 01:46 UTC critical-backup 수동 트리거 → 13 볼륨을 concurrency=1 로 순차 업로드. 첫 볼륨 (`pvc-c4bb2746`) Completed 100% 확인. 나머지 12 볼륨 backup CR 생성 후 진행.
|
||||
|
||||
4. 02:00 UTC 정규 스케줄 critical-snapshot run 에서도 13 볼륨 매칭 (로그 `Found 13 volumes` 확인 예정 — 이 문서 작성 시점 직전에 발화).
|
||||
|
||||
## 검증 방법 (재발 감시)
|
||||
|
||||
```bash
|
||||
# 주기적으로 돌려 볼륨이 실제로 매칭되는지 검증
|
||||
kubectl -n longhorn-system get volumes.longhorn.io \
|
||||
-l recurring-job-group.longhorn.io/critical=enabled --no-headers | wc -l
|
||||
# → 기대: 13 (현 기준). 0 이 나오면 즉시 조사
|
||||
|
||||
# R2 버킷 오브젝트 수 — 꾸준히 증가해야 정상
|
||||
aws s3 ls s3://longhorn-backup --recursive --summarize \
|
||||
--endpoint-url=$(kubectl -n longhorn-system get secret longhorn-backup-r2 \
|
||||
-o jsonpath='{.data.AWS_ENDPOINTS}' | base64 -d) | tail -3
|
||||
```
|
||||
|
||||
## 재발 방지
|
||||
|
||||
- [[../infra/backup.md|infra/backup.md]] Longhorn 섹션에 라벨 키 규약 명시. 신규 PVC 를 critical/standard 그룹에 넣을 때 **반드시 `recurring-job-group.longhorn.io/<group>`** 을 쓸 것.
|
||||
- 향후 Longhorn UI 에서 볼륨 group 설정 시 UI 가 어떤 키를 쓰는지 확인 필요 (UI 가 타이포 키를 쓰는 경로였다면 upstream 이슈) — 현 시점 미확인 액션.
|
||||
- 모니터링: VictoriaMetrics/Grafana 에 "최근 24h BackupVolume 신규 생성 0건" 알람 추가 검토 (별도 작업).
|
||||
@@ -1,9 +1,29 @@
|
||||
---
|
||||
title: 백업 파이프라인
|
||||
updated: 2026-04-05
|
||||
updated: 2026-04-15
|
||||
tags: [infra, backup]
|
||||
---
|
||||
|
||||
## Longhorn PVC 백업 (K3s)
|
||||
|
||||
BackupTarget `default` → R2 버킷 `longhorn-backup` (시크릿 `longhorn-backup-r2`). RecurringJob 4종 (critical-snapshot 매시, critical-backup 6h, standard-snapshot 일 1회 03:00 UTC, standard-backup 일 1회 04:00 UTC).
|
||||
|
||||
### RecurringJob 그룹 볼륨 라벨 — **정확한 키 주의**
|
||||
|
||||
Longhorn 컨트롤러가 인식하는 라벨 키는 **`recurring-job-group.longhorn.io/<group>=enabled`** (대시 포함). `recurringjob-group.longhorn.io/...` (대시 누락) 은 무효이며 컨트롤러가 볼륨을 찾지 못한다.
|
||||
|
||||
```bash
|
||||
# 신규 볼륨을 critical 그룹에 등록
|
||||
kubectl -n longhorn-system label volumes.longhorn.io <pvc-...> \
|
||||
recurring-job-group.longhorn.io/critical=enabled --overwrite
|
||||
|
||||
# 라벨 검증 (선택자가 볼륨을 실제로 잡는지)
|
||||
kubectl -n longhorn-system get volumes.longhorn.io \
|
||||
-l recurring-job-group.longhorn.io/critical=enabled
|
||||
```
|
||||
|
||||
라벨 기록이 꼬였을 때의 대응은 [[../history/2026-04-15-longhorn-backup-label-typo|history]] 참고.
|
||||
|
||||
## incus 백업 (inbest 데이터)
|
||||
|
||||
3단계 백업 파이프라인. 소스: incus-kr2 inbest 프로젝트 `inbest-data` 커스텀 볼륨.
|
||||
|
||||
Reference in New Issue
Block a user