Incident Library
적용된 필터 원인용량 한계구성 요소애플리케이션 데이터베이스증상노드 NotReady모두 풀기검색어 없이 필터만 적용한 목록입니다. 최근 사례부터입니다.
추천 필터 검색하면 검색어에서 찾은 분류 값이 여기에 나옵니다.

그래프

  • 원인
  • 구성 요소
  • 증상
  • 기여 요인
  • 사례

사례2건

2건 중 1~2번째

  1. IL-0110 Grafana Agent 파드가 메모리를 많이 쓰던 노드에 Hangfire 파드가 함께 올라가 시스템 OOM 으로 CrashLoopBackOff 를 반복했고, 노드가 응답을 멈추고 NotReady 가 됐다.
    DFDS2024
    증상

    2024-03-13 10:01 UTC 에 쿠버네티스 노드 하나가 NotReady 상태가 됐다. 그때 노드에 잡힌 requests 는 CPU 78%, 메모리 82% 였다. 10:03 에 Slack 으로 알림이 왔고, 10:05 에 알림을 보고 조사를 시작했다.

    노드 NotReady컨테이너 재시작 반복OOMKilled모니터링 중단
    촉발

    Hangfire 로 작업을 실행하는 개발 컨테이너가 Grafana Agent 가 메모리를 많이 쓰고 있던 노드에 배치됐고, 작업이 OOM 으로 실패하며 CrashLoopBackOff 를 반복했다.

    원인
    용량 한계
    구성 요소
    텔레메트리 에이전트컨테이너 메모리 한도애플리케이션 데이터베이스
    기여 요인
    과도한 영향 범위리소스 요청과 한도 미설정수동 조치 악화모니터링 사각지대
    감지

    10:03 UTC 에 Slack 으로 알림이 왔고, 10:05 에 알림을 확인하고 조사를 시작했다. 두 번째 노드는 15:03 에 Slack 알림이 왔고 15:09 에 확인했다. 탐지까지 걸린 시간은 4분이었다.

    조치
    • 10:22 에 EC2 인스턴스를 비정상으로 표시해 새 노드를 띄웠다.
    • 10:30 에 NotReady 노드를 cordon 하고 강제로 drain 했고, 10:36 에 그 EC2 인스턴스를 종료했다.
    • 13:02 에 네임스페이스에서 LimitRange 를 지우고 Grafana Agent 파드를 재시작했다.
    • 14시대에 문제의 개발 컨테이너를 0개로 줄였고, 몇 분 뒤 EC2 네트워크 트래픽이 정상으로 돌아왔다.
    • 두 번째 NotReady 뒤 15:15 에 개발 컨테이너를 다시 0개로 줄였고, 15:18 에 새 노드가 추가됐다.
    • 15:19 에 개발 컨테이너를 맡은 팀에 메일을 보냈고, 15:52 에 그 팀이 문제를 확인하고 수정 중이라고 답했다.
    후속 조치
    • grafana-agent 를 모니터링 노드 그룹으로 옮긴다.
    • 클러스터 전체 대역폭이 정해 둔 기준에 닿으면 알림을 보낸다.
    • grafana-agent Helm 차트에 메모리 한도를 걸 수 있는지 조사한다.
    • grafana-agent 의 메모리 사용량을 조사한다.
    • grafana-agent 에 PVC 를 써야 하는지 Grafana 지원팀에 묻는다.
    • 보존 기간을 제한한 채 노드 로그를 Loki 로 보내는 방안을 검토한다.
    • 쿠버네티스 노드 문제를 조사할 때 확인할 자주 쓰는 지표와 로그 쿼리를 위키 페이지로 만든다.
    교훈

    포스트모템에서 나온 후속 조치를 끝까지 챙겨야 한다. CloudWatch 에서 어떤 지표가 쓸모 있는지가 팀에 제대로 공유되지 않아 진단과 조사가 어려웠다.

    사례 보기
  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건에서 가장 많이 나오는 구성 요소: 애플리케이션 데이터베이스, 리눅스 커널. kubegap 은 Claude Code 나 Codex 에서 쿠버네티스 클러스터를 읽기만 하며 이런 틈을 점검합니다. 점검 항목의 근거는 이 라이브러리와 같은 공개 보고서입니다.

kubegap 열기

원인별1

용량 한계2건

구성 요소
애플리케이션 데이터베이스2건리눅스 커널1건컨테이너 메모리 한도1건파드 스케줄링과 배치1건텔레메트리 에이전트1건
기여 요인
미검증 가정1건자동화 증폭1건과도한 영향 범위1건수동 조치 악화1건모니터링 사각지대1건리소스 요청과 한도 미설정1건단일 장애점1건
조직
DFDS1건Moonlight1건
  1. IL-0110 Grafana Agent 파드가 메모리를 많이 쓰던 노드에 Hangfire 파드가 함께 올라가 시스템 OOM 으로 CrashLoopBackOff 를 반복했고, 노드가 응답을 멈추고 NotReady 가 됐다.
    DFDS2024
  2. IL-0064 CPU 를 많이 쓰는 파드가 Google Cloud 노드 하나에 몰려 노드가 커널 패닉으로 죽었고, 다시 배치된 파드가 다음 노드를 또 죽이며 웹사이트와 API 가 멈췄다.
    Moonlight2019