Incident Library

IL-0461 Datadog · 2022-04-13 (게시일)kubernetesawsnetworking

메트릭 질의 서비스를 롤아웃할 때마다 DNS 오류가 나며 질의가 실패했다

2021년 9월부터 Datadog 의 메트릭 질의 서비스를 롤아웃할 때마다 오류가 늘었다. 이 서비스는 데이터 저장소에서 실시간과 과거 메트릭 데이터를 읽어 웹 프런트엔드와 모니터 평가 클라이언트에 준다. 로그는 DNS 오류를 가리켰고, 팀은 OOM 이 나던 node-local-dns 파드의 메모리를 64 MB 에서 256 MB 로 올렸지만 DNS 오류는 계속됐다. ENA 지표의 conntrack_allowance_exceeded 로 VPC conntrack 이 포화된 것을 확인했다. 더 큰 인스턴스 유형으로 올리면 문제가 사라진다는 것도 확인했지만, 팀은 conntrack 테이블이 왜 차는지 알고자 했다.

VPC Flow Logs 를 보니 롤아웃 때 메트릭 평가 클라이언트가 지워진 파드의 옛 IP 로 SYN 을 대량으로 보냈다. 이 클러스터는 Cilium 을 ipam:eni 모드로 쓰고, 파드 트래픽은 보조 ENI 인 ens6 으로 다닌다. 파드가 지워지면 Cilium 이 그 파드의 경로와 IP 규칙을 지우지만 VPC 는 옛 IP 로 가는 트래픽을 여전히 그 노드의 ens6 으로 보낸다. 돌아갈 경로가 기본 경로인 ens5 뿐이라, 역경로 필터가 이 패킷을 martian 으로 보고 리눅스 conntrack 에 넣기 전에 버렸다. 호스트가 SYN-ACK, RST, ICMP host unreachable 중 어느 것도 보내지 않아 클라이언트는 옛 IP 라는 것을 몰랐고, 이 연결 요청은 VPC conntrack 에만 남았다. 응답이 없는 요청은 60초 안에 지워져야 하지만, 지워지는 속도보다 쌓이는 속도가 빨랐다. 역경로 필터는 loose 모드였다. 장애를 닫은 뒤 커널 코드를 보니, IP 주소가 없는 장치에서는 no_addr 검사 때문에 역경로 필터가 strict 모드처럼 동작했다. ens6 에 IP 를 하나 할당하자 예상대로 동작했다.

클라이언트가 새 파드 IP 를 받기까지는 약 60초가 걸렸다. 쓰던 external-dns 버전은 kubelet 이 파드 삭제를 끝낸 뒤에야 레코드를 바꿨다. 서비스는 SIGTERM 을 받은 뒤 GracefulStop 에 10초 타임아웃을 두었다. external-dns 는 15초마다 동기화했고, TTL 은 15초였다. gRPC 클라이언트는 min_time_between_resolutions 기본값 때문에 30초마다만 DNS 를 다시 조회했다. 2021년 6월 다른 장애를 고치려고 그 서비스의 클라이언트를 round_robin 으로 바꿨고, 그 뒤 round_robin 을 여러 서비스의 기본 정책으로 정했다. 8월 메트릭 질의 클라이언트 롤아웃에서 이 기본값이 처음 적용됐다. 이 앱은 백엔드마다 gRPC 채널을 하나씩 만들었으므로 연결 수는 pick_first 를 쓸 때와 같았다. 다만 round_robin 은 끊긴 채널을 자동으로 다시 연결했다. 여기에 오래전에 정한 공격적인 재연결 타임아웃이 겹쳐, 600개 파드에 15개씩 컨테이너가 있는 약 900개 클라이언트가 약 300 ms 마다 재연결하며 초당 최대 30,000개의 SYN 을 보냈다. 이 재연결 파라미터를 지우고 기본값으로 되돌린 다음 롤아웃에서는 오류가 나지 않았고, 장애를 닫았다.

심각도
–
영향 범위
Errors and added latency for dashboards and monitors that read from the metrics query service during its rollouts; client retries kept most errors from users
영향 사용자
–
지역
–
감지까지
–
복구까지
–

증상

2021년 9월부터 메트릭 질의 서비스의 업데이트를 롤아웃할 때마다 오류가 늘었다. 서비스 로그에는 DNS 오류 때문에 메트릭 데이터 저장소에 연결하지 못했다는 내용이 찍혔다. 클라이언트가 실패한 질의를 자동으로 재시도해 사용자에게 보이는 오류는 적었지만, 재시도 때문에 대시보드와 모니터의 지연이 늘었다.

노드마다 도는 NodeLocal DNSCache DaemonSet 인 node-local-dns 파드에 OOM 오류가 났다. 이 파드는 메모리 한도가 64 MB 였고, max_concurrent 설정으로 동시 요청을 1,000개까지만 처리했다. 롤아웃 중에는 그 한도를 넘는 요청을 거절했다. 서비스의 요청률은 평소 초당 400건 안팎이었고 롤아웃 중에도 2,000건 가까이에 그쳐, node-local-dns 가 동시 요청 한도에 닿을 이유가 없어 보였다.

node-local-dns 지표에서 로컬 DNS 캐시가 상위 DNS 리졸버를 unhealthy 로 표시하고 있었다. 팀은 헬스체크 실패를 node-local-dns 가 상위 리졸버에 연결하지 못한다는 뜻으로 보았다. 그렇다면 요청마다 forward 플러그인의 5초 타임아웃 동안 슬롯을 잡고 있어, 초당 200건만으로도 max_concurrent 한도에 닿는다는 설명이 됐다.

인스턴스 유형의 지속 처리량 한도인 5 Gbps 에는 한참 못 미쳤지만, 롤아웃에 맞춰 TCP 재전송이 늘었다. 처리량 그래프에 잡히지 않는 짧은 트래픽 급증을 의심해 Datadog Agent 에서 ENA 지표를 켜자, 대역폭과 처리량에는 이상이 없었고 conntrack_allowance_exceeded 지표가 늘었다. VPC conntrack 이 포화된 것이었다. 같은 인스턴스의 리눅스 conntrack 연결 수는 60,000개 아래로 낮았다.

VPC Flow Logs 를 TCP 플래그별로 모아 보니, 롤아웃 중 파드가 지워진 뒤에도 메트릭 데이터를 평가하는 클라이언트들이 옛 파드 IP 로 계속 SYN 을 보냈다. 옛 IP 하나가 약 90초 동안 약 90,000번의 연결 시도를 받았고, 기대했던 RST 는 돌아가지 않았으며 SYN 은 응답 없이 버려졌다.

노드 두 대로 재현하자 받는 쪽 노드의 tcpdump 에는 SYN 과 재시도가 보였지만 응답이 없었다. `ip route get 10.x.y.z from 10.a.b.c iif ens6` 은 "RTNETLINK answers: Invalid cross-device link" 를 냈고, 커널 로그에는 "IPv4: martian source 10.x.y.z from 10.a.b.c, on dev ens6" 이 찍혔다. 역경로 필터가 loose 모드로 설정돼 있었는데도 strict 모드처럼 패킷을 버렸다.

증상 오류율 상승DNS 조회 실패지연 시간 증가OOMKilled패킷 손실오래된 엔드포인트 라우팅

원인

원인 설정 변경

구성 요소 conntrack 테이블Cilium리눅스 커널CoreDNS클라이언트 쪽 DNS 리졸버와 캐시external-dnsHTTP·RPC 클라이언트 라이브러리
기여 요인 늦게 드러난 변경재시도 폭주한계 미인지모니터링 사각지대
촉발
2021년 8월 메트릭 질의 클라이언트의 업데이트를 롤아웃하면서 새 기본값인 gRPC round_robin 부하 분산 정책이 처음 적용됐다. round_robin 은 끊긴 채널을 자동으로 다시 연결하는데, 오래전에 넣어 둔 매우 공격적인 gRPC 재연결 타임아웃과 겹쳐 서비스 롤아웃 때마다 사라진 파드 IP 로 SYN 이 쏟아졌다.

감지

2021년 9월부터 메트릭 질의 서비스 롤아웃 때 오류가 늘어나는 것을 보았고, 서비스 로그에서 DNS 오류가 데이터 저장소 연결을 막는 것을 확인했다.

조치

후속 조치

교훈

gRPC, 쿠버네티스, AWS 같은 강력한 추상화도 엣지 케이스에서는 평소에 숨어 있던 복잡함이 오류로 드러난다. 몇 달을 조사한 끝에, 이번 장애의 뿌리가 팀이 직접 한 변경에 있다는 것을 찾았다. 의존성의 버그를 피해 가려던 변경, 이전 장애를 고치려던 변경, 기본 재연결 파라미터를 덮어쓴 변경이었다. 이 변경들은 당시에는 안전해 보였지만 한참 뒤에 상관관계를 찾기 어려운 때에 뜻밖의 결과를 냈다. DNS 문제처럼 보여도 DNS 문제가 아닐 때가 있다. AWS ENA 지표와 VPC Flow Logs 는 연결 추적을 들여다보는 데 중요하다. DNS 전파 시간은 여러 요인에 좌우된다.

출처

관련 사례

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

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

kubegap 열기

AI 도구와 스크립트용

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