사례2건

2건 중 1~2번째

1. IL-0138 nvidia-dkms-390 드라이버 빌드 실패로 망가진 커널 헤더가 몇 주 동안 방치됐다가, 정전 뒤 재부팅하자 하나뿐인 마스터 노드가 커널 패닉에 빠져 홈랩 쿠버네티스 클러스터가 6일 동안 멈췄다.

   Barush Mendez2025

   증상

   2025년 3월 3일 14:15:34부터 홈랩 쿠버네티스에 올린 서비스에 접속되지 않았다. 운영자가 서비스에 들어가려다 직접 알아챘고, 알아채기까지 3시간이 걸렸다.

   컨트롤 플레인 무응답서비스 중단모니터링 중단

   촉발

   정전 때문에 마스터 노드가 재부팅됐다.

   원인

   소프트웨어 결함

   구성 요소

   GPU 드라이버리눅스 커널쿠버네티스 API 서버

   기여 요인

   초기 신호 무시늦게 드러난 변경단일 장애점모니터링 사각지대

   감지

   운영자가 서비스에 접속하려다 직접 알아챘다. 자동 알림이 없어서 알아채기까지 3시간이 걸렸다.

   조치

   • 원격 접속이 되지 않아 모니터를 연결해 부팅 로그를 보고 커널 패닉을 확인했다.
   • 이전 커널 버전으로 부팅해 시스템을 되살렸다.
   • sudo apt-get remove --purge '^nvidia-.*' 로 망가진 패키지를 지우고 sudo dpkg --configure -a 로 패키지 설정 문제를 고쳤다.
   • dpkg -l | grep -v ^ii 로 남은 망가진 패키지를 찾아 sudo apt-get remove --purge <package_name> 으로 하나씩 지웠다.
   • sudo apt-get install -f 로 빠진 의존성을 채우고 sudo apt-get install --reinstall linux-headers-$(uname -r) 로 커널 헤더를 다시 설치했다.
   • 머신을 재부팅해 커널 패닉이 사라진 것을 확인했다.

   후속 조치

   • GPU 드라이버 설치가 완전히 성공했는지 확인하고, 오류가 나면 바로 변경을 되돌린다.
   • 단일 장애 지점을 없애도록 클러스터를 고가용성 구성으로 옮긴다.
   • 고가용성 구성에서 Kube-API 를 로드 밸런서 뒤에 둔다.
   • 장애를 기록하고 해결 과정을 추적할 티켓 시스템을 만든다.
   • 미리 정해 둔 문제 해결 절차를 만들어 홈랩 장애 대응 시간을 줄인다.
   • Prometheus 와 Grafana 같은 인프라 모니터링을 넣어 문제를 미리 잡는다.
   • 주요 서비스에 HTTP, TCP 검사를 거는 블랙박스 모니터링을 넣어 쿠버네티스 클러스터 밖에서도 장애를 잡는다.

   교훈

   드라이버 빌드 실패를 그대로 두면 몇 주 뒤 재부팅 때 터질 수 있다. 자동 알림이 없어서 발견과 복구가 늦었다. 마스터 노드가 하나뿐이라 노드 하나의 고장이 클러스터 전체 장애가 됐다. 원인을 찾은 뒤에는 비교적 간단히 고쳤고, 데이터 손실은 없었다.

   사례 보기
2. IL-0064 CPU 를 많이 쓰는 파드가 Google Cloud 노드 하나에 몰려 노드가 커널 패닉으로 죽었고, 다시 배치된 파드가 다음 노드를 또 죽이며 웹사이트와 API 가 멈췄다.

   Moonlight2019

   증상

   1월 18일 금요일, Moonlight API 가 가끔 오류를 냈다. 처음 오류는 Redis 데이터베이스와 연결이 안 되는 문제로 보였다. Moonlight API 는 인증된 요청마다 Redis 에서 세션을 확인한다.

   오류율 상승간헐적 연결 실패노드 NotReady서비스 중단노드 CPU 고부하

   촉발

   쿠버네티스 스케줄러가 CPU 를 많이 쓰는 파드 여러 개를 같은 노드에 배치했다. 이 파드들이 노드 CPU 를 100% 쓰자 노드 VM 이 커널 패닉으로 죽었다.

   원인

   용량 한계

   구성 요소

   파드 스케줄링과 배치리눅스 커널애플리케이션 데이터베이스

   기여 요인

   단일 장애점미검증 가정자동화 증폭

   감지

   API 오류가 가끔 나면서 문제가 드러났다. 쿠버네티스 모니터링이 일부 노드와 파드가 응답하지 않는다고 보고했다. 노드가 CPU 100% 상태에서 커널 패닉으로 죽는다는 패턴은 Google Cloud 지원팀이 찾아냈다.

   조치

   • 주요 배포 전부에 안티 어피니티 규칙을 넣어 파드를 여러 노드에 흩어 놓았다.

   후속 조치

   • Google Cloud 지원팀과 함께 노드 커널 패닉의 근본 원인을 찾아 고친다.

   교훈

   복제본을 세 개 두어도 스케줄러가 한 노드에 몰아 놓으면 그 노드가 단일 장애점이 된다. 사용자에게 응답하는 서비스에는 안티 어피니티 규칙을 넣어 파드를 여러 노드에 나눠 놓아야 한다. 팀은 처음에 클라우드 업체의 네트워크 장애를 원인으로 짐작했지만 실제 원인은 노드의 CPU 포화와 커널 패닉이었다.

   사례 보기

원인별2