[K8s] DiskPressure(ephemeral-storage) 반복 해결: containerd 디스크 분리 + 로그 상한 표준화
publishedkubeadmOpenStackcontainerdCalicoops
요약
- 루트 디스크(약 20G) 환경에서
/var/lib/containerd + 로그(journald/파일 로그)가 누적되면 DiskPressure가 반복되고, 결국 스케줄링/네트워크까지 연쇄 장애가 날 수 있다.
- 해결은 단순했다: containerd 데이터 경로를 별도 볼륨으로 분리하고(
/dev/sdb), 로그 상한(journald + logrotate)을 표준화했다.
- 부작용/교훈: 이관 중 containerd snapshot이 꼬이면 Calico가 먼저 쓰러져 "네트워크 문제"처럼 보일 수 있다. 실제 원인은 런타임 스토리지 무결성이었다.
환경
- OpenStack 위 3노드 kubeadm 클러스터 (control-plane 1, worker 2)
- OS: Ubuntu 24.04 계열
- 런타임: containerd
- CNI: Calico
- 특징: 루트 디스크가 작고(
~19G), 컨테이너/로그 누적에 취약
증상
- 노드가 DiskPressure로 taint/eviction을 반복
- 파드가
ContainerCreating, CrashLoopBackOff로 증가
- 특히 Calico 쪽 readiness가 무너지며 네트워크가 망가진 것처럼 보임
원인 가설 → 결론
- 가설 1: 로그가 루트를 잠식 (journald, syslog/auth 등)
- 가설 2:
/var/lib/containerd (images/snapshots)가 루트를 잠식
- 결론: 둘 다 맞았고, 특히
/var/lib/containerd가 루트 디스크를 가장 빠르게 소모했다.
해결 1) containerd 데이터 디스크 분리
- 각 노드에 별도 볼륨(예: 50G)을 attach →
/dev/sdb
/var/lib/containerd를 새 볼륨에 마운트하고(/etc/fstab 등록), 기존 데이터는 백업/이관- 이후 루트 디스크는 OS/제어플레인/기본 로그 정도만 담당
해결 2) 로그 상한 표준화 (재발 방지)
- journald:
SystemMaxUse=200M, MaxRetentionSec=7day 등으로 상한 설정
- logrotate:
/var/log의 주요 로그를 daily + rotate 7 + compress + maxsize로 제한
- 포인트:
/var/log 권한/소유가 배포마다 다를 수 있어 su root adm 같은 설정이 필요할 수 있다.
주의: 이관 중 containerd snapshot 꼬임 → Calico 연쇄 장애
- 이관 작업이 중간에 끊기면(강제 종료/부분 rsync 등) containerd snapshot 트리가 불완전해질 수 있다.
- 그 결과
failed to stat parent ... snapshots/.../fs: no such file or directory 류의 에러가 나고, calico-node가 먼저 죽어 "CNI 문제"처럼 보인다.
- 복구는 결국 containerd 데이터 리셋(백업 이동) + 파드 재생성으로 정리했다. (이미지 재-pull 비용은 감안)
운영 체크리스트 (짧게)
df -h /, df -h /var/lib/containerd를 매일/매주 확인journalctl --disk-usage 상한 유지 확인kubectl get nodes에서 DiskPressure/NotReady 감시kubectl get pods -A에서 비정상 상태(Non-Running) 급증 감시
[K8s] 단일 노드 k3s에서 운영 가능한 최소 구성
published-ishk3singress-nginxcert-manager
현재 구성
k3s single nodeingress-nginx NodePort(30080/30443)cert-manager 설치 완료