[프로젝트 5]💾 K3s CronJob이 CPU를 1291%까지 폭주시킨 날 – Store-and-Forward 티어링 구현기

라즈베리파이 SSD는 무한하지 않습니다. AI 파드들이 매초 데이터를 InfluxDB에 쌓으면 언젠가는 스토리지가 꽉 찹니다. 그래서 오래된 데이터를 주기적으로 Windows PC의 NFS Cold Storage로 옮기는 티어링 파이프라인을 구현하기로 했습니다. 간단할 것 같았는데, K3s CronJob이 클러스터를 마비시키고, NFS가 유령 연결을 만들고, Python 프로세스가 커널에 갇혀버리는 일들이 기다리고 있었습니다.

🔗 데이터 티어링 실증: GitHub Wiki — Proof Tiering | 데이터 생명주기

---

📐 전체 설계 — Windowing 전략

왜 InfluxDB 데이터를 주기적으로 비워야 하는지부터 설명하면, Longhorn 볼륨은 5Gi로 제한됩니다. AI 파드가 계속 데이터를 쌓으면 스토리지가 가득 차 시스템이 멈춥니다.

←──── 5시간 InfluxDB 보존 (Hot) ────→ | 5시간 초과 → CSV 변환 + Cold 이관

  Hot Data                               Cold Data
  InfluxDB 상주                          CSV 변환 후
  Grafana 실시간 시각화 ✅               NFS Cold Storage 영구 보존 ✅

5시간 이내 데이터는 InfluxDB에서 실시간 시각화하고, 5시간이 지난 데이터는 CSV로 변환해 Windows PC의 NFS로 이관 후 삭제합니다. 이 구조가 RPO 0초를 달성하는 핵심 메커니즘입니다.

---

💥 Episode 14. K3s CronJob이 CPU를 폭주시켰다

처음엔 쿠버네티스스러운 방식으로 구현했습니다. K3s kind: CronJob으로 매시간 InfluxDB 데이터를 CSV로 변환하는 파드를 실행하는 방식이었습니다.

그런데 Grafana 인프라 대시보드에서 이상한 걸 봤습니다.

Master 노드 Sys Load: 652% → 1291%

파드 목록을 확인하니 이런 상태들이 쌓여 있습니다.

NAME                                  STATUS
data-tiering-cronjob-29545176-g725b   CreateContainerError
data-tiering-cronjob-29545178-dszqq   ContainerCreating
data-tiering-cronjob-29545180-v64cr   CreateContainerError

에러 3연속:

Error: context deadline exceeded
Error: failed to reserve container name "tiering-worker_..._0":
       name "..." is reserved for "3bb74dbc5b6782c..."
Error: stream terminated by RST_STREAM with error code: CANCEL

처음엔 스크립트 로직 문제라고 생각했습니다. 그런데 crictl ps -a로 컨테이너를 확인하려 해도 조회 자체가 되지 않습니다. 유령 레코드입니다.

근본 원인: CronJob의 볼륨이 hostPath: /mnt/safe-edge-nfs로 설정되어 있었는데, 이 경로가 Windows NFS 서버(WinNFSd)를 마운트한 경로였습니다. containerd가 컨테이너를 생성할 때 볼륨 마운트를 시도하는 순간, NFS 응답이 느리면 context deadline exceeded 타임아웃이 발생합니다.

타임아웃으로 컨테이너 생성은 실패했지만 containerd 내부 DB에 컨테이너 이름 예약 레코드가 남아버립니다. 이후 재시도할 때 이름 충돌 → 무한 반복 → CPU 폭주의 연쇄가 발생한 것입니다.

[타임아웃 발생]
    └→ 컨테이너 생성 실패
    └→ containerd DB에 유령 레코드 잔존
        └→ 재시도 시 이름 충돌 반복
            └→ CPU 1291% 폭주 🔴

10가지 시도를 거쳐 내린 결론: CronJob을 완전히 포기하고 리눅스 crontab으로 전환합니다.

[기존] K3s CronJob → 매번 컨테이너 생성 → NFS 마운트 타임아웃 위험
[변경] 리눅스 crontab → 이미 떠있는 host에서 Python 직접 실행 → 컨테이너 생성 없음

# root 크론탭에 등록 (매시 정각 실행)
sudo crontab -e
0 * * * * /home/minsoo/safe-edge-tiering/run_tiering.sh >> /home/minsoo/safe-edge-tiering/tiering.log 2>&1

💡 교훈: 쿠버네티스에서 주기적 작업의 정석은 CronJob이지만, 라즈베리파이처럼 리소스가 제한적인 엣지 환경에서는 매번 컨테이너를 생성하는 오버헤드가 치명적입니다. 클라우드 네이티브 정석보다 환경의 제약을 먼저 고려해야 합니다.

---

💥 Episode 15. NFS STALE — 연결이 살아있는 척하는 유령 마운트

재부팅 후 tiering 스크립트를 실행했더니 데이터가 Windows PC로 가지 않습니다. 리눅스에서는 파일이 있는 것처럼 보이는데 실제 Windows C:\safe-edge-nfs 폴더는 비어 있습니다.

minsoo@master:/mnt/safe-edge-nfs $ ls
acoustic_detection_cold_20260305_110742.csv  # 파일이 있는 것처럼 보임

minsoo@master:/mnt/safe-edge-nfs $ touch tt.txt
touch: cannot touch 'tt.txt': Permission denied  # 실제로는 끊긴 상태

WinNFSd 로그에는 STALE 에러가 반복됩니다.

STALE이란: 리눅스가 예전에 연결했던 NFS File Handle이 살아있다고 착각하지만, 실제로는 Windows와의 연결이 끊긴 상태입니다. WinNFSd는 재시작 후 기존 연결 상태를 복구하는 Grace Period를 지원하지 않아서, 재부팅할 때마다 모든 연결이 STALE이 됩니다.

즉시 복구:

# 유령 마운트 강제 해제 (-l: lazy unmount, 응답 없어도 강제 해제)
sudo umount -l /mnt/edge-nfs/nfs-complete

# 새로 마운트
sudo mount -t nfs -o vers=3,nolock \
  10.10.10.100:/C/safe-edge-nfs /mnt/edge-nfs/nfs-complete

근본 해결 — run_tiering.sh에 자동 재연결 로직 내장:

#!/bin/bash
# 매 실행마다 기존 마운트 강제 해제 후 새로 연결
sudo umount -l /mnt/edge-nfs/nfs-complete 2>/dev/null
sudo timeout 5 mount -t nfs -o vers=3,nolock \
  10.10.10.100:/C/safe-edge-nfs /mnt/edge-nfs/nfs-complete

NFS_STATUS=$?

💡 교훈: umount -l은 STALE 마운트의 만능 해결사입니다. 그리고 “스크립트 실행 시 항상 마운트를 갱신”하는 방어 로직이 운영 자동화의 핵심입니다.

---

💥 Episode 16. stat은 NFS 끊김을 감지 못한다 — 커널 레벨 블로킹

NFS가 끊겼는지 Python 코드에서 검증하는 함수를 만들었습니다.

# 1차 시도: stat으로 검증
def check_nfs_alive(mount_path):
    result = subprocess.run(['timeout', '3', 'stat', mount_path], ...)
    return result.returncode == 0  # NFS 끊겨도 True 반환 ← 문제!

NFS가 끊긴 상태에서도 stat은 True를 반환합니다. stat은 실제 NFS 서버에 I/O 요청을 보내지 않고 리눅스 로컬 캐시를 읽기 때문입니다.

touch로 바꿔봤더니 이번엔 스크립트가 아예 멈춥니다.

🔍 NFS 마운트 상태 검증 중...   ← 여기서 영원히 멈춤

touch는 실제 파일을 생성하므로 NFS 서버에 I/O 요청을 보냅니다. NFS가 꺼진 상태에서는 커널이 응답을 무한 대기하는 **D-State(언인터럽터블 슬립)**에 빠집니다. subprocess.run(timeout=3) 같은 애플리케이션 레벨 타임아웃으로는 커널이 잡고 있는 프로세스를 중단시킬 수 없습니다.

최종 해결: 검증 책임을 shell 스크립트 한 곳에 집중시키고, 환경변수로 전달합니다.

# run_tiering.sh
sudo timeout 5 mount -t nfs ... /mnt/edge-nfs/nfs-complete
NFS_STATUS=$?

# NFS 상태를 환경변수로 Python에 전달
NFS_CONNECTED=$NFS_STATUS python3 /home/minsoo/scripts/tiering_host.py

# tiering_host.py — Python 내부에서 NFS I/O 완전 금지
nfs_connected = os.environ.get('NFS_CONNECTED', '1') == '0'

if nfs_connected:
    move_buffer_to_nfs(NFS_READY, NFS_COMPLETE)  # Forward
else:
    print("NFS 단절 — nfs-ready 버퍼에 보관 중")  # Store

상황	mount 결과	Python 판단	결과
NFS 정상	성공 (0)	nfs_connected=True	nfs-complete로 전송 ✅
NFS 끊김	timeout (124)	nfs_connected=False	nfs-ready 버퍼에 보관 ✅

💡 교훈: stat은 NFS 연결 검증 수단이 아닙니다. NFS I/O는 커널 레벨에서 블로킹되므로 Python 타임아웃으로 막을 수 없습니다. 검증 책임은 한 곳(shell)에서만 지게 하고 결과를 환경변수로 전달하는 것이 가장 안전합니다.

---

💥 Episode 17. 재부팅 후 KUBECONFIG 권한 초기화 — 에러 위장

재부팅 전까지 정상 동작하던 사진 백업 스크립트가 재부팅 이후 이런 메시지를 내고 즉시 종료됩니다.

⚠️ 실행 중인 AI 파드를 찾을 수 없습니다

파드는 실제로 멀쩡히 돌고 있는데 “파드 없음”이라고 합니다.

원인: 스크립트가 kubectl 명령어를 실행하기 위해 이 경로를 참조하고 있었습니다.

export KUBECONFIG=/etc/rancher/k3s/k3s.yaml

K3s는 보안 정책상 재부팅할 때마다 이 파일의 권한을 600(root 전용)으로 초기화합니다. 일반 사용자 계정(minsoo)으로 스크립트를 실행하면 Permission Denied가 발생하고, kubectl get pod가 아무 결과도 반환하지 못해 “파드 없음”으로 판단하는 것이었습니다.

해결: 개인 전용 kubeconfig 경로로 변경합니다.

# 변경 전 (재부팅 후 root 전용으로 초기화됨)
export KUBECONFIG=/etc/rancher/k3s/k3s.yaml

# 변경 후 (minsoo 계정 소유, 재부팅 후에도 권한 유지)
export KUBECONFIG=/home/minsoo/.kube/config

💡 교훈: “파드 없음” 같은 로직 에러 메시지가 실제로는 권한 문제일 수 있습니다. 재부팅 후에만 발생하는 버그는 파일 권한, 환경변수, 서비스 기동 순서를 먼저 의심하세요.

---

✅ Store-and-Forward 파이프라인 완성

모든 트러블슈팅을 거친 최종 구조입니다.

InfluxDB (Hot, Worker2)
    │ run_tiering.sh — 매시 정각
    ▼
nfs-ready (로컬 버퍼)
    │
    ├── NFS 정상 → nfs-complete (NFS 마운트) → Cold Storage ✅
    └── NFS 끊김 → 여기서 대기 (Store)
                       └── NFS 복구 시 자동 전송 (Forward) ✅

AI 파드 스냅샷 → run_photo_tiering.sh (10분마다) → Cold Storage/photos ✅

NFS가 끊겨도 로컬 버퍼에 데이터를 보관하고, 복구되면 자동으로 전송합니다. 사고가 나서 네트워크가 끊기는 바로 그 순간에도 데이터는 보존됩니다.

🔗 다음 편: 6편 — Failover 실증: 랜선을 뽑았다, 시스템은 살아남았다
🔗 티어링 실증 전체: GitHub Wiki — Proof Tiering