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

사례8건

8건 중 8~8번째

  1. 증상

    2019-01-08 이른 아침 Tinder 플랫폼에 오래 이어지는 장애가 났다. 노드에서 파드로 가는 통신과 DNS 조회가 실패했다.

    촉발

    그날 아침 장애에 앞서 이번 장애와 관계없는 플랫폼 지연이 늘자 클러스터의 파드와 노드 수를 늘렸다. 장애 당시 노드는 605개였고, 이 수는 기본 gc_thresh3 값을 넘기에 충분했다.

    원인
    구성 요소
    기여 요인
    조치
    • gc_thresh1, gc_thresh2, gc_thresh3 값을 올렸다.
    • Flannel 을 재시작해 ARP 표에서 빠진 네트워크를 다시 등록했다.
    교훈

    Tinder 는 이 장애로 네트워크 구성의 한계를 알게 됐다고 정리했다. Flannel 과 VXLAN 을 쓰는 클러스터에서는 노드마다 ARP 항목이 생기고, ELB 를 거쳐 다른 노드의 파드로 가는 통신이 항목을 더 늘린다. 그래서 노드가 605개에 이르자 리눅스의 기본 gc_thresh3 값으로는 모자랐다. 이 한계를 넘으면 패킷만 버려지는 것이 아니라 Flannel 의 /24 대역이 ARP 표에서 통째로 빠져 노드와 파드 사이 통신과 클러스터 안 DNS 가 함께 멈춘다.

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

이 8건에서 가장 많이 나오는 구성 요소: 네트워크 컨트롤 플레인, BGP 라우팅. kubegap 은 Claude Code 나 Codex 에서 쿠버네티스 클러스터를 읽기만 하며 이런 틈을 점검합니다. 점검 항목의 근거는 이 라이브러리와 같은 공개 보고서입니다.

원인별6

클라우드 제공자 장애1건

기여 요인
–
조직
  1. IL-0463 Harness Secure Connect 의 내부 로드 밸런서에 닿을 수 없게 되어 Secure Connect 를 쓰는 git 커넥터 검사와 CI 파이프라인이 실패했다

용량 한계2건

  1. IL-0350 TXL 클러스터 한 곳의 호스트 네트워크가 끊기고 프로비저닝 대기열이 밀려 여러 서비스가 오래 나빠졌다
  2. IL-0472 노드 605개 클러스터의 모든 노드에서 ARP 캐시가 넘쳐 노드와 파드 사이 통신과 DNS 조회가 끊겼다
    Tinder2019

소프트웨어 결함2건

  1. IL-0233 eu-west1 에서 Managed Kubernetes 의 거의 모든 파드가 네트워크 연결을 잃었고 롤백으로도 돌아오지 않았다
    Nebius2025
  2. IL-0347 FR-PAR-1 가용 영역에서 하이퍼바이저 약 25% 의 VPC 연결이 11분 동안 끊겼다

운영 실수1건

  1. IL-0244 EKS 서브넷의 라우팅 테이블 연결이 사라져 live 클러스터의 Cloud Platform 서비스에 접근할 수 없었다

배포 결함1건

  1. IL-0530 us-central1 의 가상 네트워크 라우터 컨트롤러가 메모리 부족으로 재시작을 되풀이해 새 VM 과 마이그레이션된 VM 의 네트워크가 오래 끊겼다

설정 변경1건

  1. IL-0473 Azure 공개 쿠버네티스 클러스터의 노드 풀이 모두 지워지고 다시 만들어지지 않아 Jenkins 인프라 서비스가 4시간 넘게 멈췄다