사례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-0174 Fluent Bit 2.0 으로 올린 로그 수집 사이드카 가운데 Kafka output 플러그인을 쓰는 컨테이너가 SIGSEGV 로 계속 재시작됐다.

   Hyperconnect2023

   증상

   하이퍼커넥트는 운영 Kubernetes 클러스터의 로그 수집 에이전트인 Fluent Bit 를 2.0 으로 올렸다. 사용자 영향이 적은 서비스를 골라 Fluent Bit 사이드카부터 업그레이드하고 며칠 지켜보니, Kafka output 플러그인을 쓰는 컨테이너만 SIGSEGV 로 재시작되고 있었다.

   컨테이너 재시작 반복

   촉발

   운영 클러스터에서 Fluent Bit 사이드카를 2.0 으로 업그레이드했다. 이 버전의 Kafka output 플러그인은 map 이 아닌 레코드가 들어와도 타입을 확인하지 않고 처리했다.

   원인

   소프트웨어 결함

   구성 요소

   텔레메트리 에이전트

   기여 요인

   디버그 접근 제한

   감지

   업그레이드 뒤 며칠 동안 모니터링하다가 Kafka output 플러그인을 쓰는 컨테이너만 SIGSEGV 로 재시작되는 것을 발견했다.

   조치

   • produce_message 를 부르기 전에 map 이 아닌 데이터를 건너뛰도록 Fluent Bit Kafka output 플러그인을 고쳤다.
   • 고친 플러그인으로 커스텀 빌드를 만들어 사이드카로 적용했고, segmentation fault 가 사라졌다.
   • 수정 사항을 Fluent Bit 업스트림에 PR 6452 로 냈고, 제출 8일 만에 병합됐다.

   교훈

   Linux 는 segmentation fault 가 나면 core 를 덤프하고, 이 파일을 분석하면 버그를 찾을 수 있다. Kubernetes 환경에서는 core 가 저절로 남지 않으므로 볼륨과 core_pattern 을 미리 잡아 두어야 한다. 직접 분석하기 어려워 core 파일을 다른 사람에게 넘길 때는 조심해야 한다. core 에는 실행 중이던 프로세스의 메모리 일부가 들어 있어 민감 정보가 섞일 수 있다.

   사례 보기

원인별2