안녕하세요! Zeabur가 VPS 인스턴스에 대해 스케줄에 따라 자동으로 docker system prune을 실행하는지, 아니면 정리를 전적으로 수동으로 해야 하는지 궁금합니다. 스토리지 사용량이 왜 변동되는지 이해하고 싶습니다. 제 VPS 인스턴스에서 기본적으로 실행되는 cron job이 있나요?
예를 들어, 오늘 아침에만 디스크 사용량이 11.7GB에서 10.9GB로 줄었습니다. 이전에도 매일 아침 비슷한 시간에 디스크 사용량이 감소하는 유사한 스토리지 변동이 수없이 많았는데, 그 실제 원인과 이유를 찾고 싶습니다.
안녕하세요. Zeabur는 docker system prune을 주기적으로 실행하지 않습니다. 하지만 k3s에 내장된 containerd 가비지 컬렉션은 디스크 사용량이 85%를 초과하면 사용하지 않는 컨테이너 이미지를 자동으로 정리하여 80%까지 낮춰줍니다. 이 작업은 주기적으로 실행되며, 매일 저장 공간이 줄어드는 현상에 대한 가장 유력한 설명입니다. 이는 디스크가 오래된 이미지 레이어로 가득 차는 것을 방지하기 위한 정상적인 동작입니다.
정보 감사합니다. 한 가지 명확히 하고 싶은 점은, 게시물에 첨부한 이미지에서 볼 수 있듯이 현재 제 디스크 사용량은 약 14%(10.9GB / 78.4GB) 수준이며, 11-12GB 정도였을 때도 15-16%였습니다. 따라서 언급하신 85% 임계값과는 거리가 멉니다. 제가 겪고 있는 일일 저장 공간 감소 현상을 설명할 수 있는 다른 정리 프로세스가 있을까요?
And I'd like to request a staff from Zeabur to check what's possibly taking up disk space of my server alongside cleaning up old logs if they're contributing to storage usage.
I may also request a clean up later on of unused container images via k3s crictl rmi --prune but first I'd like to understand what's currently being used on my disk usage. Thanks!
안녕하세요. 이전 답변에 오류가 있었습니다. 죄송합니다. 85% 임계값은 k3s의 내장 GC에 대한 것이며, 매일 발생하는 스토리지 감소의 원인은 아닙니다.
Zeabur는 모든 전용 서버에서 crictl-image-prune DaemonSet을 실행하며, 24시간마다 crictl rmi --prune을 (디스크 사용량과 관계없이 무조건) 실행합니다. 고객님의 서버에서는 매일 01:21 UTC경에 실행됩니다. 이는 사용되지 않는 컨테이너 이미지, 즉 더 이상 실행 중인 Pod에서 참조하지 않는 오래된 배포 이미지 레이어를 제거합니다. 이것이 매일 약 0.8GB씩 감소하는 이유입니다.
이는 정상적이고 의도된 동작이며, 오래된 이미지가 시간이 지남에 따라 쌓이는 것을 방지합니다. 현재 디스크 사용량 구성은 다음과 같습니다:
디스크 공간 사용량에 대한 자세한 분석이 필요하시면 대시보드의 메트릭 페이지에서 확인하시거나, 저희가 서버에서 du 명령어를 대신 실행해 드릴 수 있습니다. 필요하시면 말씀해 주세요.
설명 감사합니다! 네, 부탁드립니다. 서버에서 du 명령어를 실행하여 디스크 공간을 무엇이 차지하고 있는지 자세한 분석 결과를 알려주실 수 있나요? 필요할 경우 무엇을 정리할 수 있는지 파악하고 싶습니다.
안녕하세요. 서버의 디스크 사용량 분석 결과입니다 (11GB / 79GB, 15%):
| 카테고리 | 크기 |
|---|---|
| 컨테이너 이미지 (실행 중인 배포) | 2.2 GB |
| PVC 볼륨 (lumiverse-staging + 기타 1개) | 2.3 GB |
| Systemd journal 로그 | 2.8 GB |
| 로그인 실패 로그 (btmp/auth) | ~250 MB |
| OS + k3s 시스템 파일 | 2.2 GB |
| 기타 (Pod 로그, apt 캐시 등) | ~0.5 GB |
가장 용량을 많이 차지하며 정리 가능한 항목은 systemd journal 로그 (2.8GB) 입니다. SSH를 통해 다음 명령어로 정리할 수 있습니다:
sudo journalctl --vacuum-size=500M
이렇게 하면 약 2.3GB의 공간을 확보할 수 있습니다.
btmp/auth 로그(~250MB, 대부분 SSH 무차별 대입 공격 시도)는 다음 명령어로 정리 가능합니다:
sudo truncate -s 0 /var/log/btmp.1 /var/log/btmp
컨테이너 이미지와 PVC 볼륨은 모두 실행 중인 서비스에서 사용 중이므로 정상적인 사용량입니다. 매일 실행되는 crictl rmi --prune 명령어가 사용하지 않는 이미지를 자동으로 정리합니다.
자세한 설명 감사합니다! 가능하다면 systemd journal 로그를 정리(500M까지 vacuum)하고 실패한 로그인 로그(btmp/auth)를 잘라내 주실 수 있을까요? 약 2.3GB와 250MB의 공간을 확보하고 싶습니다.
k3s crictl rmi --prune를 수동으로 실행하는 것에 관하여 — 저희가 대신 실행해 드리는 것은 지양하고 있습니다. 실행 중인 Pod가 참조하는 이미지를 실수로 삭제할 위험은 낮지만 0은 아니며, 데이터 안전을 위해 서비스에 지장을 줄 수 있는 개입은 피하고자 합니다. 일일 자동 정리 기능이 이미 사용하지 않는 이미지를 안전하게 처리하고 있습니다.
직접 실행하고 싶으시다면, 서버에 SSH로 접속하여 다음을 실행하십시오:
sudo k3s crictl rmi --prune
이렇게 하면 직접 제어할 수 있으며, 실행 후 서비스에 영향이 없는지 확인할 수 있습니다.
명확히 말씀드리자면, 저는 crictl rmi --prune에 대해 질문한 것이 아닙니다(매일 수행되는 자동 정리 작업으로 처리된다는 점은 이미 알고 있습니다). 제가 질문드린 것은 분석 내용에서 언급했던 systemd journal logs(500M로 압축)와 btmp/auth logs를 정리할 수 있는지 여부입니다. 이는 시스템 로그이며 컨테이너 이미지가 아니므로, 실행 중인 서비스에는 영향을 주지 않을 것입니다. 해당 정리 작업을 처리해 주실 수 있나요?
위에서 전체 디스크 분석 및 정리 명령어를 제공해 드렸습니다. 그 이상의 서버 작업은 데이터 안전을 위해 사용자님께서 직접 수행하시도록 권장합니다.
혹시 플랫폼 측에서 저희가 조사해 드릴 만한 특정 문제나 버그가 발생했나요?
아, 알겠습니다. 다시 한번 감사드려요! 명령어를 사용해서 정리했더니 잘 작동하네요.
resolved 이슈에는 새 답글을 작성할 수 없습니다.