Incident Library
적용된 필터 구성 요소CNI 플러그인증상DNS 조회 실패기여 요인기본 설정 방치모두 풀기검색어 없이 필터만 적용한 목록입니다. 최근 사례부터입니다.
추천 필터 검색하면 검색어에서 찾은 분류 값이 여기에 나옵니다.

그래프

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

사례1건

1건 중 1~1번째

  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 가 함께 멈춘다.

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

이 사례에서 가장 많이 나오는 구성 요소: CNI 플러그인, 리눅스 커널. kubegap 은 Claude Code 나 Codex 에서 쿠버네티스 클러스터를 읽기만 하며 이런 틈을 점검합니다. 점검 항목의 근거는 이 라이브러리와 같은 공개 보고서입니다.

원인별1