Incident Library
적용된 필터 구성 요소텔레메트리 에이전트모두 풀기검색어 없이 필터만 적용한 목록입니다. 최근 사례부터입니다.
추천 필터 검색하면 검색어에서 찾은 분류 값이 여기에 나옵니다.

그래프

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

사례17건

17건 중 16~17번째

  1. 증상

    어느 저녁 데이터센터 OpenStack 의 네트워크 하위 시스템을 업그레이드한 뒤 Kafka 연결이 몇 시간 동안 간헐적으로 끊겼다. 개발 환경 워크로드 약 2,000개를 올린 큰 쿠버네티스 클러스터에서 노드들이 쿠버네티스에 비정상이라고 보고하기 시작했다.

    촉발

    OpenStack 의 네트워크 하위 시스템을 업그레이드하다가 예상과 달리 네트워크가 몇 시간 동안 끊겼고, Kafka 에는 간헐적으로만 닿았다. 그러자 모든 워크로드에 딸린 로깅 사이드카가 한꺼번에 깨어나 노드의 Docker 데몬에 높은 부하를 주었다.

    원인
    구성 요소
    기여 요인
    조치
    • Consul 의 gossip 암호화를 켜서 오염된 gossip 메시에서 오는 메시지를 바로 거부하게 했고, 이것으로 Consul 과 Vault 를 되살렸다.
    • 배포 엔진을 안정시킨 뒤 암호화 설정을 반영하려고 개발 환경 전체를 다시 배포했고, 암호화가 설정되지 않은 인스턴스는 종료했다.
    • 큰 클러스터를 다루는 수정이 들어간 Consul 1.2.3 으로 제자리 업그레이드했고, UI 버그 때문에 최종적으로 1.3.0 으로 올렸다. 운영 환경의 오염된 gossip 메시도 이 업그레이드로 빠르게 정리됐다.
    후속 조치
    • 노드의 워크로드가 함께 쓰는 Docker 데몬은 깨지기 쉬운 장애 지점이므로, 데몬 하나의 장애가 미치는 범위를 줄이는 데 더 힘쓴다. 작은 클러스터를 여러 개 두는 방침과 같은 방향이다.
    교훈

    글쓴이는 작은 클러스터를 여러 개 두라는 자신의 원칙이 옳았다고 확인했다. 더 작은 개발 클러스터와 운영 클러스터의 워크로드는 큰 클러스터처럼 영향을 받지 않았고, 개발과 운영이 한 클러스터에 있었다면 훨씬 큰 일이 났을 것이다. 노드의 워크로드가 함께 쓰는 Docker 데몬은 깨지기 쉬운 장애 지점이다. 워크로드마다 자기 로깅 사이드카와 메트릭 사이드카를 두는 방식이 옳다고도 확신하게 됐다. 이것들이 클러스터 공용 자원이었다면 문제가 거의 틀림없이 더 커졌고 고치기도 훨씬 어려웠을 것이다.

  2. 증상

    쿠버네티스 마이그레이션이 순조로워 보이던 중 Datadog 에서 노드의 열린 파일 수가 계속 늘어나는 것이 보였다.

    촉발

    로그 파일을 쓰는 컨테이너가 여럿 떠 있는 노드에 새 컨테이너가 뜰 때마다, 외부 업체의 로그 클라이언트가 기존 로그 파일의 파일 디스크립터까지 새로 열고 이전 디스크립터를 닫지 않았다.

    원인
    구성 요소
    기여 요인
    감지

    Datadog 에서 노드의 열린 파일 수가 계속 오르는 것을 보고 알았다.

    조치
    • 문제가 난 노드를 죽이고 새 노드를 띄운 뒤 서비스를 다시 배포해 복구했다.
    후속 조치
    • 업체와 함께 문제를 다뤘고, 결국 그 로그 수집 업체의 서비스를 쓰지 않게 됐다.
    교훈

    EC2 에서 믿고 쓰던 서비스와 라이브러리가 쿠버네티스에서도 똑같이 잘 동작한다고 가정하면 안 된다. 그런 도구는 배포 방식과 수명 주기가 다른 환경을 전제로 만들어졌을 수 있다. 쿠버네티스에서는 배포할 때마다 컨테이너가 생기고 사라지고 노드 사이를 옮겨 다니므로, 쓰는 서비스마다 이런 수명 주기에 맞게 만들어졌는지 의심하고 확인해야 한다.

내 클러스터에도 있는지 확인하기

이 17건에서 가장 많이 나오는 구성 요소: 텔레메트리 에이전트, 컨테이너 런타임. kubegap 은 Claude Code 나 Codex 에서 쿠버네티스 클러스터를 읽기만 하며 이런 틈을 점검합니다. 점검 항목의 근거는 이 라이브러리와 같은 공개 보고서입니다.

원인별6

설정 변경3건

  1. IL-0179 DEBUG 로그가 쏟아지자 동기 로깅을 하던 요청 스레드들이 가득 찬 stdout 파이프에서 멈춘 채 DB 커넥션을 쥐고 있어, HikariCP 커넥션 풀이 고갈되고 요청이 30초 주기로 한꺼번에 실패했다.
  2. IL-0005 새 텔레메트리 서비스가 모든 노드에서 무거운 쿠버네티스 API 요청을 보내 대형 클러스터의 컨트롤 플레인이 무너졌고, DNS 기반 서비스 디스커버리가 깨져 OpenAI 의 모든 서비스가 멈췄다
    OpenAI2024
  3. IL-0109 로그 수집을 고치려던 EKS 노드 롤오버가 꼬이면서 Auto Scaling 그룹이 정상 워커 노드를 모두 종료해 클러스터에 노드가 하나도 남지 않았다.
    DFDS2023

배포 결함3건

  1. IL-0160 고쳐서 다시 돌린 레거시 GPU 모니터링 스크립트의 펌웨어 조회가 GSP 레이스 컨디션을 일으켜 Linode 의 RTX 4000 Ada GPU 가 잠기고 LKE 워커 노드의 GPU 작업이 멈췄다
    Linode2026
  2. IL-0142 GKE 1.24 이상 클러스터에서 로그를 처리하는 구성 요소의 새 버전이 불필요한 오류 로그를 쏟아내 일부 고객의 Logging API 쓰기 할당량이 바닥났다
  3. IL-0034 메트릭 에이전트 사이드카가 업그레이드 중 크래시하자 클러스터의 모든 파드가 준비되지 않은 상태가 되어 서비스가 트래픽을 받지 못했다
    Airbnb2019

용량 한계6건

  1. IL-0042 OpenSearch 디스크가 가득 찬 동안 fluent-bit 가 로그를 처리하지 못해 Elasticsearch 와 OpenSearch 에 애플리케이션 로그가 들어오지 않았다.
  2. IL-0110 Grafana Agent 파드가 메모리를 많이 쓰던 노드에 Hangfire 파드가 함께 올라가 시스템 OOM 으로 CrashLoopBackOff 를 반복했고, 노드가 응답을 멈추고 NotReady 가 됐다.
    DFDS2024
  3. IL-0043 새 버전 fluent-bit에서 청크를 버리는 방식이 바뀌어 Kibana의 애플리케이션 로그에 긴 공백이 생겼다
  4. IL-0194 kube-apiserver 재시작 뒤 Vector DaemonSet 의 파드 list 요청이 한꺼번에 몰려 etcd 메모리가 세 배 가까이 늘고 마스터 노드가 연쇄적으로 재시작했다.
    Palark2023
  5. IL-0026 메모리 제한이 없는 fluentd-sumologic 파드가 메모리를 다 써서 운영 쿠버네티스 노드 두 대에 이틀 연속 SystemOOM 이 났다
  6. IL-0075 클러스터가 EC2 인스턴스 약 290대로 커지자 노드마다 도는 Datadog 에이전트가 쿠버네티스 API 를 폴링하면서 API 서버가 CPU 와 메모리를 다 써 쿠버네티스 컨트롤 플레인을 쓸 수 없게 됐다.

DNS·네트워크 장애1건

조직
  1. IL-0083 멀티 테넌트 쿠버네티스 클러스터에서 노드 로컬 dnsmasq 가 동시 질의 한도에 걸리고 cluster.local 응답을 캐시하지 못한 데다 ndots 검색 도메인 질의가 CoreDNS 로 몰려, 서비스 간 호출이 간헐적인 5xx 를 냈다.

소프트웨어 결함3건

  1. IL-0174 Fluent Bit 2.0 으로 올린 로그 수집 사이드카 가운데 Kafka output 플러그인을 쓰는 컨테이너가 SIGSEGV 로 계속 재시작됐다.
  2. IL-0041 fluent-bit 이 오류 없이 멈춰 운영 노드 한 대의 애플리케이션 로그가 Elasticsearch 로 전혀 가지 않았다.
  3. IL-0051 외부 업체의 로그 클라이언트가 새 컨테이너가 뜰 때마다 파일 디스크립터를 다시 열고 이전 것을 닫지 않아 쿠버네티스 노드가 too many open files 로 내려갔다

의존성 장애1건

조직
  1. IL-0073 Kafka 연결이 끊기자 로깅 사이드카가 Docker 데몬에 부하를 주어 노드가 줄줄이 비정상이 되었고, 재스케줄링으로 생긴 노드 약 41,000개가 Consul gossip 메시를 오염시켜 Vault 와 배포 엔진까지 멈췄다
    Target2019