사례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-0458 Toolforge 쿠버네티스 API 서버가 재시작 뒤 올라오지 못해 몇 시간 동안 클러스터 전체가 멈췄다

   Wikimedia Foundation2019

   증상

   18:45 에 toolschecker 의 icinga 검사 "All k8s nodes healthy" 가 알림을 울렸다. 쿠버네티스 API 서버가 응답하지 않아 모니터링에서도 사용자 쪽에서도 클러스터가 완전히 내려간 것처럼 보였다. 사용자는 webservice 명령으로 도구를 띄울 수 없었고 kubectl 로 상태를 보거나 도구를 다룰 수도 없었다.

   컨트롤 플레인 무응답서비스 중단TLS 인증서 오류

   촉발

   18:30 에 maintain-kubeusers 프로세스가 쿠버네티스 API 서버를 재시작했다. 재시작한 API 서버는 etcd 에 다시 연결해야 했는데, 전날 밤 퍼핏 변경으로 CA 인증서가 etcd 서버의 것과 어긋나 있어 연결하지 못했다.

   원인

   설정 변경

   구성 요소

   쿠버네티스 API 서버etcd구성 관리 도구

   기여 요인

   늦게 드러난 변경수동 조치 악화런북 부재

   감지

   처음 울린 것은 http://checker.tools.wmflabs.org/k8s/nodes/ready 를 검사하는 icinga 알림이었다. 18:45 에 toolschecker 의 "All k8s nodes healthy" 검사가 울렸다.

   조치

   • 19:10 과 20:30 에 쿠버네티스 마스터를, 20:18 에 etcd 클러스터를 재부팅했지만 도움이 되지 않았다.
   • 21:06 에 백업을 떠 둔 뒤 잦은 raft 선출을 원인에서 빼려고 etcd 클러스터를 노드 하나로 줄였다.
   • 노드를 다시 넣다 클러스터가 무너진 뒤 여러 시도 끝에 백업에서 etcd 전체 재해 복구를 해 00:25 쯤 etcd 를 원래 용량으로 되돌렸다.
   • 01:28 에 API 서버가 쓰는 CA 를 etcd 서버의 CA 로 바꿨고, 통신과 서비스가 돌아왔다. 퍼핏이 곧 이 변경을 되돌렸다.
   • 01:43 에 etcd 퍼핏 CA 인증서를 /var/lib/puppet/client/ssl/certs/ca.pem 에 두었고, 퍼핏이 이 인증서를 가져가 장애가 안정적으로 끝났다.

   후속 조치

   • etcd 클러스터 운영 절차를 문서로 남긴다. 작업 번호는 T232769 다.
   • Toolforge 쿠버네티스 업그레이드로 etcd 와 쿠버네티스의 오류 보고를 개선하고, 도구를 추가할 때 API 서버를 재시작하지 않아도 되게 한다. 작업 번호는 T214513 이다.
   • kube2proxy 가 API 서버 장애를 더 잘 견디게 만들어 본다. 작업 번호는 T232770 이다.
   • 퍼핏 CA 인증서를 점검한다. tools 프로젝트 안에 CA 인증서가 둘 이상 있어서는 안 된다. 작업 번호는 T232772 다.
   • 쿠버네티스 컨트롤 플레인을 고가용성으로 만든다. 작업 번호는 T142862 다.

   교훈

   etcd 처럼 원래 말썽이 잦은 구성 요소가 해법 찾기를 헷갈리게 했다. 퍼핏 인증서는 위험하다. 아주 오래된 쿠버네티스 버전은 로그에 남기는 오류 메시지가 형편없다. 팀은 CA 인증서가 아니라 etcd 를 고치려다 상황을 더 나쁘게 만들었다. 문제는 API 서버를 재시작할 때에야 드러났다. etcd 클러스터에는 문서화되지 않은 오래된 특이점이 있었고, etcd 재해 복구와 노드 교체 절차는 문서로 남아 있지 않았다. 이 셋이 겹쳐 해법을 찾는 데 오래 걸렸다. 교차 교육이 있었다면 도움이 됐을 수 있지만, 이번 일은 어차피 여럿이 함께 풀어야 했다.

   사례 보기

원인별2