사례1건
1건 중 1~1번째
- 증상
2025년 5월 12일 20:15 EEST 에 Freshdesk 지원 티켓이 들어왔다. 워크숍 중 사용자 서버가 시작하는 데 15분 넘게 걸리고 커널이 죽는다는 내용이었다. 같은 허브를 다른 용도로 쓰던 강사들도 영향을 받았다.
- 촉발
워크숍 사용자들이 메모리 상한이 없는 프로필로 보장량 8GB 보다 많은 메모리를 꾸준히 썼다.
- 원인
- 구성 요소
- 기여 요인
- 감지
커뮤니티가 Freshdesk 지원 티켓으로 알렸다. 티켓은 20:15 에 열렸고 20:49 에 #support-freshdesk 슬랙 채널로 팀에 전달됐으며, 20:57 에 첫 엔지니어가 확인했다.
- 조치
- 5월 12일 21:05 에 helm 롤아웃과 허브 재배포를 했고 상황이 일부 나아졌다.
- 5월 13일 15:51 에 medium 프로필을 열었고, 그 메모리 보장량을 올려 오버커밋을 줄였다.
- 17:15 에 30명 워크숍을 위해 노드 15개를 미리 띄웠다.
- 5월 14일 워크숍 전에 작은 노드용 프로필의 메모리 보장량과 상한을 같게 맞춰 명시적인 메모리 상한을 두는 변경을 배포했다.
- 후속 조치
- 장애 보고서를 쓴다.
- 내부 회고를 열어 이번 장애에서 배울 점을 정리한다.
- 교훈
메모리 상한 없이 보장량만 둔 프로필에서는 노드를 나눠 쓰는 사용자끼리 서로를 축출할 수 있다. 메모리 보장량과 상한을 같게 두면 한 사용자의 메모리 급증이 같은 노드의 다른 사용자에게 번지지 않는다. 이번에는 로그에 뚜렷한 오류가 없었고 원인은 프로필 설정에 있었다. 워크숍 직전에는 프로필 구조를 바꾸지 않고 노드를 미리 띄우는 쪽으로 대응했다.
내 클러스터에도 있는지 확인하기
이 사례에서 가장 많이 나오는 구성 요소: 컨테이너 메모리 한도, 노드 풀. kubegap 은 Claude Code 나 Codex 에서 쿠버네티스 클러스터를 읽기만 하며 이런 틈을 점검합니다. 점검 항목의 근거는 이 라이브러리와 같은 공개 보고서입니다.