사례5건

5건 중 1~5번째

1. IL-0104 Istio 의 공격적인 DNS 캐시 갱신과 클라이언트 포트 재사용, kube-proxy 가 종료된 파드의 conntrack 항목을 정리하지 않는 문제, 2분짜리 UDP conntrack 기본 타임아웃이 겹쳐 CoreDNS 파드가 OOMKilled 됐다.

   Cisco ThousandEyes2025

   증상

   2025년 9월 4일, CoreDNS 파드 하나가 OOMKilled 됐다.

   DNS 조회 실패오래된 엔드포인트 라우팅OOMKilled

   촉발

   CoreDNS 파드 하나가 OOMKilled 됐다.

   원인

   소프트웨어 결함

   구성 요소

   CoreDNSkube-proxyconntrack 테이블Istio

   기여 요인

   기본 설정 방치

   교훈

   장애는 Istio, kube-proxy, conntrack 각각의 동작이 겹쳐 생겼다. Istio 는 DNS 캐시를 공격적으로 갱신하며 클라이언트 포트를 다시 썼고, kube-proxy 는 conntrack 항목을 정리하지 않았고, conntrack 의 UDP 기본 타임아웃은 2분이었다. kube-proxy 쪽 문제는 쿠버네티스 v1.32 에서 고쳐졌다. 발표자는 Istio 가 아주 복잡한 일은 단순하게 만들지만 아주 단순한 일은 복잡하게 만든다고 평했다. 발표자는 또 Cilium 을 소개했다. Cilium 은 iptables 체인을 차례로 훑는 대신 맵으로 Service 를 찾고, eBPF 데이터 경로로 kube-proxy 를 완전히 대체할 수 있다.

   사례 보기
2. IL-0461 메트릭 질의 서비스를 롤아웃할 때마다 DNS 오류가 나며 질의가 실패했다

   Datadog2022

   증상

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

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

   촉발

   2021년 8월 메트릭 질의 클라이언트의 업데이트를 롤아웃하면서 새 기본값인 gRPC round_robin 부하 분산 정책이 처음 적용됐다. round_robin 은 끊긴 채널을 자동으로 다시 연결하는데, 오래전에 넣어 둔 매우 공격적인 gRPC 재연결 타임아웃과 겹쳐 서비스 롤아웃 때마다 사라진 파드 IP 로 SYN 이 쏟아졌다.

   원인

   설정 변경

   구성 요소

   conntrack 테이블Cilium리눅스 커널CoreDNS클라이언트 쪽 DNS 리졸버와 캐시external-dnsHTTP·RPC 클라이언트 라이브러리

   기여 요인

   늦게 드러난 변경재시도 폭주한계 미인지모니터링 사각지대

   감지

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

   조치

   • node-local-dns 파드의 메모리를 64 MB 에서 256 MB 로 올렸다. OOM 오류는 멈췄지만 DNS 오류는 계속됐다.
   • AWS 가 더 많은 연결을 추적할 수 있다고 한 더 큰 인스턴스 유형으로 서비스 인프라를 올려 보았고, 그것만으로 문제가 사라지는 것을 확인했다.
   • SYN 폭주를 일으킨 사용자 지정 gRPC 재연결 파라미터를 지우고 기본값으로 되돌리는 PR 을 만들었다. 다음 롤아웃에서는 오류가 나지 않았다.

   후속 조치

   • Cilium 프로젝트에 PR 을 기여한다. 이 PR 은 옛 파드 IP 에 unreachable 경로를 더해, 지워진 파드로 가는 요청이 martian 패킷이 되지 않게 한다. 그러면 역경로 필터가 SYN 을 버리지 않고, 클라이언트는 분명한 ICMP 오류를 받는다.

   교훈

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

   사례 보기
3. IL-0445 EKS 로 옮기던 레거시 시스템에서 conntrack 테이블이 넘쳐 연결이 끊겼고, 이어 CoreDNS 파드가 축출될 때와 node-local-dns 를 넣은 뒤에 DNS 오류가 났다

   Chatwork2021

   증상

   Route53 가중치로 EC2 와 EKS 를 함께 돌리며 레거시 시스템을 옮기던 중, 일정 비율이 넘는 요청을 EKS 쪽으로 보내자 서비스가 갑자기 불안정해졌다. 일부 노드에서 conntrack 테이블이 한계를 넘어 애플리케이션으로 가는 연결이 드롭되고 있었다.

   간헐적 연결 실패DNS 조회 실패간헐적 타임아웃부하 불균형

   촉발

   첫 번째 불안정은 Route53 가중치로 EKS 쪽에 보내는 요청 비율을 일정 이상으로 올리면서 시작됐다. 두 번째 불안정은 문서에 나온 매니페스트로 force_tcp 를 쓰는 node-local-dns 를 운영 환경에 apply 하면서 시작됐다.

   원인

   용량 한계

   구성 요소

   conntrack 테이블CoreDNSkube-proxy클라이언트 쪽 DNS 리졸버와 캐시VPC DNS 리졸버

   기여 요인

   기본 설정 방치스테이징 불일치한계 미인지

   조치

   • conntrack 상한이 기본값과 다른 값으로 설정되어 있었고 그 값은 kube-proxy 가 정하고 있었다. 팀은 kube-proxy 설정에서 conntrack 의 maxPerCore 를 늘렸다.
   • EKS 에 빠져 있던 dns-autoscaler 를 넣었다. CoreDNS 파드가 어느 정도 늘자 서비스가 크게 안정됐다.
   • CoreDNS 파드가 축출될 때 나던 DNS 오류를 없애려고 각 노드에 DaemonSet 으로 실행되는 node-local-dns 를 넣었다.
   • node-local-dns 설정에서 force_tcp 를 빼고 prefer_udp 로 바꾸자 DNS 가 안정됐다.

   교훈

   EKS 에서 DNS 를 안정시킨 것은 dns-autoscaler 를 넣은 것과, force_tcp 없이 node-local-dns 를 넣은 것 두 가지였다. node-local-dns 를 쓸 때는 eksctl 로 kubelet 의 DNS 대상을 바꿀 필요가 없고, kube-dns 를 그대로 두면 된다. node-local-dns 를 업데이트하는 동안처럼 잠시 쓸 수 없을 때는 dummy device 덕에 애플리케이션의 DNS 요청이 CoreDNS 로 바로 가므로 클러스터 전체의 가용성이 오른다. DNS 가 불안정하면 조회가 막혀 파드가 쓸데없이 늘어나므로, 파드 수를 알맞게 유지하는 데도 DNS 안정이 중요하다.

   사례 보기
4. IL-0049 CoreDNS 파드가 줄어든 뒤 kube-proxy 가 conntrack 항목을 지우지 못해 일부 서비스의 DNS 요청이 없어진 파드로 가면서 5xx 가 쏟아졌다

   Preply2020

   증상

   Prometheus 모니터링이 서비스 A, B, C 에서 5xx 비율이 높아진 것을 잡아 당직자를 호출했다. 당직 엔지니어들은 22시 18분부터 VictorOps 호출을 받기 시작했다. Kibana 에서도 5xx 비율이 올라간 것이 보였다.

   DNS 조회 실패오류율 상승오래된 엔드포인트 라우팅

   촉발

   클러스터 안의 부하가 낮아지자 CoreDNS-autoscaler 가 CoreDNS 파드를 3개에서 2개로 줄였다.

   원인

   DNS·네트워크 장애

   구성 요소

   CoreDNSkube-proxyconntrack 테이블

   기여 요인

   자동화 증폭초기 신호 무시캐시 부재

   감지

   Prometheus 모니터링이 서비스 A, B, C 에서 5xx 비율이 높아진 것을 잡아 VictorOps 로 당직자를 호출했다. 포스트모템이 적은 감지 시간은 4분이다.

   조치

   • 22시 39분에 당직 엔지니어들이 해당 서비스의 최신 릴리스를 되돌렸다.
   • 정기 배포로 새 노드가 생기자 CoreDNS-autoscaler 가 CoreDNS 파드를 다시 늘렸고, conntrack 테이블이 자동으로 새로 쓰였다.

   후속 조치

   • CoreDNS 의 오토스케일러를 끈다.
   • 운영 환경에 DNS 캐시 서버를 둔다.
   • conntrack 사용량을 모니터링한다.

   교훈

   모니터링은 장애를 빨리 잡았고 대응도 빠르고 체계적이었다. 노드는 어떤 한도에도 닿지 않았다. 진짜 근본 원인은 아직 모른다. conntrack 의 특정 버그로 보인다. 팀이 정한 후속 조치는 모두 장애가 낳는 결과를 막는 것이지 근본 원인을 고치는 것이 아니다. 팀은 DNS 에서 문제가 날 수 있다는 것을 알고 있었지만 이 일을 우선해서 다루지 않았다.

   사례 보기
5. IL-0047 conntrack 경합으로 DNS 조회가 5초씩 늦어져 파드 사이 요청이 간헐적으로 5초, 10초, 15초씩 지연되었다.

   MindTickle2019

   증상

   클러스터 전체 네트워크 장애를 겪은 뒤, 팀은 파드 사이 통신이 간헐적으로 늦어지고 웹 애플리케이션 전체가 이따금 느려지는 것을 알아챘다.

   간헐적 타임아웃지연 시간 증가DNS 조회 실패

   촉발

   libc 리졸버가 A 레코드와 AAAA 레코드 조회를 같은 포트로 보냈고, DNAT 와 SNAT 변환이 일어나는 경로에서 conntrack 경합 조건 때문에 그중 하나가 응답을 받지 못했다.

   원인

   DNS·네트워크 장애

   구성 요소

   conntrack 테이블클라이언트 쪽 DNS 리졸버와 캐시리눅스 커널

   기여 요인

   기본 설정 방치

   감지

   웹 애플리케이션이 간헐적으로 느려지고 파드 사이 요청이 5초의 배수만큼 늦게 도착하는 것을 보고 알았다. 지연이 5초 단위라는 점에서 DNS 조회를 의심했고, tcpdump 로 확인했다.

   조치

   • 파드 스펙의 dnsConfig options 에 single-request-reopen 을 넣어 A 와 AAAA 조회가 서로 다른 포트로 나가게 했다.
   • gRPC 애플리케이션의 Dockerfile 에 GRPC_DNS_RESOLVER=native 를 넣어 ares 대신 libc 리졸버를 쓰게 했다.
   • `tcpdump port 53` 으로 A 와 AAAA 조회가 서로 다른 포트로 나가는 것을 확인했다.

   교훈

   지연이 5초, 10초, 15초처럼 5초의 배수로 나타나면 DNS 조회 재시도를 먼저 의심한다. 리눅스 이미지는 파드 dnsConfig 에 single-request-reopen 을 넣으면 된다. gRPC 는 기본 리졸버가 libc 를 쓰지 않을 수 있으므로 GRPC_DNS_RESOLVER=native 도 함께 설정해야 한다. 설정이 먹었는지는 tcpdump 로 A 와 AAAA 조회가 나가는 포트를 보고 확인한다.

   사례 보기

원인별4