사례22건

22건 중 6~10번째

1. IL-0048 대형 EKS 클러스터에서 CoreDNS 가 VPC DNS 리졸버로 보내는 질의가 링크 로컬 트래픽의 초당 1024 패킷 한도에 걸려 DNS 조회가 간헐적으로 타임아웃됐다.

   unknown2025

   증상

   처음 들어온 보고는 CI 가 간헐적으로 실패한다는 것이었다. 실패는 tensorstore 안에서 났고, 오류는 ./tensorstore/util/result.h:420: Status not ok: status(): UNAVAILABLE: CURL error Could not resolve hostname: Could not resolve host: company-bucket.s3.amazonaws.com 이었다.

   DNS 조회 실패간헐적 타임아웃

   촉발

   호스트 네트워크를 쓰는 시스템 관리용 파드가 몇 초마다 sudo 명령을 실행했다. sudo 는 기본 설정에서 실행할 때마다 노드 자신의 호스트 이름을 조회했다. 파드의 resolv.conf 에 있는 ndots:5 와 검색 도메인 네 개 때문에 이 조회 하나가 A 와 AAAA 를 합쳐 질의 열 번이 됐고, CoreDNS 캐시에 걸리지 않은 질의가 VPC DNS 리졸버로 몰렸다.

   원인

   용량 한계

   구성 요소

   CoreDNS클라이언트 쪽 DNS 리졸버와 캐시VPC DNS 리졸버

   기여 요인

   한계 미인지기본 설정 방치

   감지

   CI 가 간헐적으로 실패한다는 보고가 시작이었다. tensorstore 가 company-bucket.s3.amazonaws.com 의 DNS 조회에 실패했다는 오류를 냈다. 글쓴이는 kubectl logs 로 CoreDNS 파드 로그를 뒤져 i/o timeout 오류를 찾았다.

   조치

   • 컨테이너 이미지에 /etc/sudoers.d/00-no-fqdn 파일로 Defaults !fqdn 을 넣어 sudo 가 호스트 이름을 조회하지 않게 했다.

   교훈

   EC2 에서 링크 로컬 주소로 가는 VPC DNS 질의에는 초당 1024 패킷의 한도가 있다. 한도를 넘은 UDP 패킷은 버려지는데, 보낸 쪽은 이를 알 수 없다. 노드에서 ethtool -S eth0 | grep linklocal_allowance_exceeded 로 이 한도에 걸렸는지 볼 수 있다. ndots:5 와 검색 도메인 때문에 FQDN 이 아닌 이름 하나가 질의 다섯 번이 되고, AAAA 까지 물으면 열 번이 된다. sudo 는 기본 설정에서 실행할 때마다 호스트 이름을 조회하므로, sudo 를 자주 부르는 파드는 DNS 트래픽을 많이 만든다.

   사례 보기
2. IL-0080 트래픽이 몰린 GKE 클러스터에서 kube-dns 가 DNS 질의를 감당하지 못해 여러 서비스의 이름 해석이 실패하고 운영 장애로 번졌다.

   Mercari2025sev1

   증상

   Mercari 의 GKE 클러스터에서 여러 서비스가 한꺼번에 DNS 이름 해석에 실패하기 시작했다. 요청은 타임아웃으로 끝났고, 마이크로서비스가 서로 엮여 있어서 실패가 연쇄로 번지며 운영 장애가 됐다. 회사는 이 장애를 Sev1 로 분류했다.

   DNS 조회 실패간헐적 타임아웃서비스 중단

   촉발

   피크 시간대에 클러스터가 처리하는 초당 요청 수가 크게 늘면서 DNS 질의가 소수의 kube-dns 파드로 몰렸다.

   원인

   용량 한계

   구성 요소

   kube-dns

   기여 요인

   캐시 부재단일 장애점

   감지

   피크 시간대에 NXDOMAIN, 잘린 응답, "failed to refresh DNS cache" 오류가 반복되는 것을 보고 kube-dns 가 한계에 이르렀다는 것을 알았다.

   조치

   • Platform 팀만 내부 시험용으로 쓰는 Laboratory GKE 클러스터에 nodeAffinity 를 걸어 NodeLocal DNSCache 를 배포하고, 전체 워크로드에 영향을 주지 않은 채 효과를 측정했다.
   • 노드 풀에 레이블을 붙여 NodeLocal DNSCache 파드가 뜰 수 있게 하는 방식으로 Dev 와 Prod 환경 전체에 점진적으로 배포했다.

   교훈

   트래픽이 많은 쿠버네티스 클러스터에서는 DNS 를 최적화하는 일이 중요하다. 모든 파드가 몇 개의 kube-dns 파드에 기대는 구조는 피크 시간대에 장애 지점이 됐고, 노드 단위 캐시를 두자 DNS 트래픽과 오류가 크게 줄었다.

   사례 보기
3. IL-0082 EKS 노드 교체 중 CoreDNS 파드 하나가 종료되자 남은 CoreDNS 파드가 늘어난 부하를 버티지 못해 DNS 조회가 느려지고 타임아웃이 났다.

   RebelMouse2025

   증상

   2025년 5월 19일 13:42 UTC 에 RebelMouse 모니터링 도구가 오류율 상승과 서비스 성능 저하를 잡아냈다.

   DNS 조회 실패지연 시간 증가오류율 상승서비스 중단

   촉발

   보안 패치를 적용하는 정기 EKS 노드 교체 중에 계획된 EC2 인스턴스 종료가 자동으로 실행됐고, 그 인스턴스에서 돌던 CoreDNS 파드 하나도 함께 종료됐다.

   원인

   용량 한계

   구성 요소

   CoreDNS노드 풀

   기여 요인

   피크 시간 변경

   감지

   13:42 UTC 에 RebelMouse 모니터링 도구가 오류율 상승과 서비스 성능 저하를 잡아냈다. 노드 교체를 시작한 지 27분 뒤였다. 기술팀은 2분 뒤인 13:44 UTC 에 조사를 시작했다.

   조치

   • 영향을 받은 CoreDNS 파드를 새 EC2 인스턴스로 다시 스케줄했다.
   • CoreDNS 디플로이먼트를 스케일 업해 레플리카 수를 늘리고, 부하가 모든 파드에 고르게 나뉘게 했다.

   후속 조치

   • 부하가 몰리는 시간대에 CoreDNS 파드가 예기치 않게 종료되지 않도록 스케일 인 보호 장치를 넣는다.
   • CoreDNS 파드의 수직 확장이 제대로 되도록 CoreDNS 설정을 다시 살펴본다.
   • CoreDNS 디플로이먼트가 최대 부하를 감당할 만큼 준비돼 있는지 정기적으로 용량을 점검한다.

   사례 보기
4. IL-0027 CoreDNS 파드가 모두 한 노드에 몰린 채 그 노드의 메모리가 고갈되자 DNS 가 응답하지 못해 아이디어스 서비스 전체가 멈췄다

   Backpackr2025

   증상

   프로덕션 EKS 클러스터에서 원인을 바로 알기 어려운 서비스 에러가 간헐적으로 났다. RDS 나 Redis 같은 외부 서비스를 호출할 때 연결이 가끔 실패했다. DNS 요청이 몰릴 때는 도메인 조회 응답이 늦어지거나 조회가 아예 실패했다.

   DNS 조회 실패간헐적 연결 실패지연 시간 증가OOMKilled서비스 중단

   촉발

   모든 CoreDNS 파드가 같은 노드에 배치되었고, 그 노드의 메모리 사용률이 급증해 메모리가 고갈됐다.

   원인

   용량 한계

   구성 요소

   CoreDNS클라이언트 쪽 DNS 리졸버와 캐시kubelet컨테이너 메모리 한도노드 풀

   기여 요인

   기본 설정 방치단일 장애점캐시 부재

   감지

   글은 전면 장애를 어떻게 알아챘는지 적지 않았다. 그 전의 DNS 문제는 원인을 알기 어려운 서비스 에러가 간헐적으로 나면서 드러났다. 팀은 RDS 와 Redis 호출이 가끔 실패하는 현상을 추적하다가 DNS 이름 해석 실패가 근본 원인이라는 것을 확인했다.

   조치

   • CoreDNS 앞에서 DNS 질의를 받아 노드마다 캐시하는 NodeLocalDNS Cache 를 데몬셋으로 배포해 CoreDNS 부하를 줄였다.
   • CoreDNS 에 maxUnavailable: 1 인 PodDisruptionBudget 과 topology.kubernetes.io/zone 기준의 topologySpreadConstraints 를 적용해 파드가 한 곳에 몰리지 않게 했다.
   • Deployment 의 dnsConfig 로 ndots 값을 5 에서 2 로 낮춰 불필요한 DNS 조회를 줄였다.

   교훈

   쿠버네티스의 ndots:5 기본값은 점이 적은 외부 도메인을 조회할 때마다 질의를 여러 번 만든다. 이 부하는 트래픽이 큰 프로덕션 환경에서야 드러난다. CoreDNS 를 파드 2개의 기본 구성으로 두면 클러스터 전체의 단일 장애점이 된다. CoreDNS 파드는 노드와 가용 영역에 흩어 둔다. 별도 노드 그룹이나 Fargate 로 분리하면 다른 워크로드와 자원을 다투지 않는다. Affinity 와 PriorityClassName 으로 우선순위를 주면 더 안정적이다. CoreDNS 의 캐시와 bufsize 조정은 증상을 잠깐 줄였을 뿐이다. ndots 값은 여러 자료가 1이나 2를 권하지만 각 환경에 맞춰 정해야 한다.

   사례 보기
5. IL-0162 데이터베이스 업데이트 뒤 LKE 내부 DNS 서비스가 멈춰 사용자가 LKE 클러스터 컨트롤 플레인과 LKE 대시보드에 접속하지 못했다

   Linode2025

   증상

   2025년 4월 1일 Linode Kubernetes Engine, 줄여서 LKE 의 사용자들이 자기 클러스터에 연결하지 못하기 시작했다. 외부에서 클러스터 컨트롤 플레인과 LKE 대시보드에 접근할 수 없었다.

   DNS 조회 실패컨트롤 플레인 무응답

   촉발

   앞서 진행한 데이터베이스 업데이트 때문에 LKE DNS 서비스가 멈췄다.

   원인

   의존성 장애

   구성 요소

   DNS 서버와 레코드애플리케이션 데이터베이스

   기여 요인

   –

   감지

   Linode 는 20시 28분 UTC 상태 페이지에 사용자가 클러스터 컨트롤 플레인에 연결하기 어려울 수 있다고 알리고 조사를 시작했다. 21시 33분 문제를 LKE 의 DNS 기능으로 좁혔고, 22시 29분 근본 원인을 찾았다.

   조치

   • 영향받은 LKE DNS 서비스를 재시작해 클러스터와 LKE 대시보드 접근을 되살렸다.

   후속 조치

   • DNS 서비스가 의존하는 시스템과 잠깐 연결이 끊겨도 스스로 회복하도록 개선한다.
   • 비슷한 문제를 더 빨리 찾도록 모니터링을 강화한다.
   • 서로 의존하는 시스템 사이의 변경을 더 잘 조율하도록 배포 절차를 고친다.

   교훈

   DNS 서비스가 의존하는 데이터베이스를 바꾸면 DNS 서비스가 멈출 수 있고, 그러면 클러스터 안은 멀쩡해도 사용자는 컨트롤 플레인에 닿지 못한다. Linode 는 DNS 서비스가 의존하는 시스템과 잠깐 연결이 끊겨도 회복할 수 있어야 하고, 서로 의존하는 시스템의 변경은 함께 조율해야 한다고 정리했다.

   사례 보기

원인별6