f55e1cffb4
critical/standard 18 볼륨이 recurringjob-group (대시 누락) 으로 라벨 붙어 3주간 백업 전무. recurring-job-group 으로 재라벨 + backup.md 에 라벨 키 규약 명시.
75 lines
4.1 KiB
Markdown
75 lines
4.1 KiB
Markdown
---
|
|
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건" 알람 추가 검토 (별도 작업).
|