Incident Library

IL-0472 Tinder · 2019-01-08kubernetesawsnetworking

노드 605개 클러스터의 모든 노드에서 ARP 캐시가 넘쳐 노드와 파드 사이 통신과 DNS 조회가 끊겼다

2019-01-08 이른 아침 Tinder 플랫폼에 오래 이어지는 장애가 났다. 그날 아침 장애에 앞서 이번 장애와 관계없는 지연이 늘어 클러스터의 파드와 노드 수를 늘렸다. 그 결과 모든 노드에서 ARP 캐시가 바닥났다. ARP 캐시를 다루는 리눅스 커널 값 셋 가운데 gc_thresh3 는 넘을 수 없는 상한이다. 동기 가비지 컬렉션 뒤에도 자리가 없으면 커널은 패킷을 버린다.

Tinder 는 쿠버네티스 네트워크로 Flannel 을 쓰고 패킷을 VXLAN 으로 전달했다. 워커 노드는 저마다 큰 /9 대역에서 /24 가상 주소 대역을 받는다. 노드 하나마다 라우팅 표 항목 하나, flannel.1 인터페이스의 ARP 항목 하나, 포워딩 데이터베이스 항목 하나가 생긴다. 노드에서 파드로, 파드에서 파드로 가는 통신은 결국 eth0 를 거치므로 출발 노드와 도착 노드마다 ARP 항목이 하나씩 더 생긴다. Tinder 환경에서는 이런 통신이 아주 많았다. 쿠버네티스 서비스마다 ELB 가 하나씩 생기고 모든 노드가 ELB 에 등록되는데, ELB 는 파드를 모른다. 그래서 패킷을 받은 노드가 iptables 규칙에 따라 다른 노드의 파드를 무작위로 골라 다시 보냈다.

장애 당시 클러스터에는 노드가 605개 있었고, 이 수는 기본 gc_thresh3 값을 넘기에 충분했다. 그러자 패킷이 버려질 뿐 아니라 Flannel 의 /24 가상 주소 대역 전체가 ARP 표에서 빠져, 노드에서 파드로 가는 통신과 클러스터 안에서 도는 DNS 의 조회가 실패했다. Tinder 는 gc_thresh1, gc_thresh2, gc_thresh3 값을 올리고, Flannel 을 재시작해 빠진 네트워크를 다시 등록해서 장애를 해결했다.

심각도
–
영향 범위
Tinder's platform had a persistent outage: node-to-pod communication and in-cluster DNS lookups failed across the 605-node cluster
영향 사용자
–
지역
–
감지까지
–
복구까지
–

증상

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

ARP 캐시를 다루는 리눅스 커널 값 가운데 gc_thresh3 는 넘을 수 없는 상한이다. 로그에 "neighbor table overflow" 가 찍히면 ARP 캐시를 동기 가비지 컬렉션한 뒤에도 이웃 항목을 넣을 자리가 없다는 뜻이다. 이때 커널은 패킷을 통째로 버린다.

이 상한을 넘으면 패킷이 버려질 뿐 아니라 Flannel 이 노드마다 나눠 준 /24 가상 주소 대역 전체가 ARP 표에서 빠진다. DNS 는 클러스터 안에서 돌았기 때문에 DNS 조회도 함께 실패했다.

장애 직전인 그날 아침, 이번 장애와 관계없는 플랫폼 지연이 늘어서 그 대응으로 클러스터의 파드와 노드 수를 늘렸다. 그 결과 모든 노드에서 ARP 캐시가 바닥났다.

증상 서비스 중단네트워크 도달 불가DNS 조회 실패

원인

원인 용량 한계

구성 요소 리눅스 커널CNI 플러그인
기여 요인 기본 설정 방치
촉발
그날 아침 장애에 앞서 이번 장애와 관계없는 플랫폼 지연이 늘자 클러스터의 파드와 노드 수를 늘렸다. 장애 당시 노드는 605개였고, 이 수는 기본 gc_thresh3 값을 넘기에 충분했다.

감지

–

조치

후속 조치

–

교훈

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

출처

관련 사례

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

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

kubegap 열기

AI 도구와 스크립트용

API 는 키가 필요 없습니다. MCP 서버는 search_incidents, get_incident, list_incidents, get_topic, vocab 도구를 내놓습니다. 사용법은 API 와 MCP.