IL-0001 Zalando · 2019-01-07kubernetesaws

CoreDNS 파드가 메모리 한도 100Mi 에 걸려 OOM 으로 계속 죽으면서 쿠버네티스 클러스터 전체의 DNS 가 멈췄다

2019년 1월 7일 월요일, Zalando Fashion Store 의 모든 웹 상품 페이지와 코디 페이지가 한 시간 넘게 오류를 냈다. 오류는 쿠버네티스 클러스터에서 도는 데이터 집계 계층 서비스에서 나왔고, 근본 원인은 클러스터 DNS 인 CoreDNS 의 전면 장애였다.

하위 서비스 하나에서 타임아웃이 나자 클라이언트가 재시도했고, 집계 계층으로 들어오는 요청이 급증했다. 집계 계층은 Node.js 애플리케이션이고 Node.js 의 기본 DNS 해석 방식을 썼다. 이 방식은 DNS 조회 결과를 캐시하지 않는다. 애플리케이션은 쿠버네티스 기본 DNS 설정으로 돌아서 ndots 5 문제를 그대로 안고 있었다. 이 문제 때문에 클러스터 밖 이름을 한 번 조회할 때마다 DNS 쿼리가 10개 나갔다. DNS 를 바꿔 트래픽을 전환하는 서비스들이 있어서, HTTP 클라이언트 커넥션 풀은 연결의 최대 수명도 짧게 잡고 있었다. 연결을 계속 새로 열면서 DNS 요청이 더 늘었다.

CoreDNS 파드의 메모리 한도는 과거 사용량을 근거로 100Mi 로 아주 작게 잡혀 있었다. 쿼리가 치솟자 CoreDNS 파드는 바로 OOM 으로 죽었다. 높은 쿼리 부하가 계속되는 데다 메모리 한도를 자동으로 올릴 방법이 없어 회복하지 못했다. Zalando 는 몇 달 전부터 일부 시스템 구성 요소에 Vertical Pod Autoscaler 를 쓰고 있었지만 CoreDNS 에는 쓰지 않았다. CoreDNS 에도 썼다면 파드가 자동으로 회복했을 수도 있었다.

DNS 가 멈추자 클러스터 내부 모니터링도 멈춰 당직 호출이 늦어졌고, 대응도 느린 데다 사람이 손으로 해야 했다. 연락을 받은 쿠버네티스 당직 엔지니어는 CoreDNS 파드가 OOM 으로 죽고 있는 것을 확인하고 메모리 request 와 limit 을 100Mi 에서 2000Mi 로 직접 올렸다. CoreDNS 파드가 회복하자 집계 계층은 서킷 브레이커를 닫았고 Fashion Store 는 완전히 회복했다.

심각도: –
영향 범위: all web product and outfit pages of the Zalando Fashion Store; DNS for the entire Kubernetes cluster
영향 사용자: –
지역: –
감지까지: –
복구까지: –

증상

Zalando Fashion Store 의 모든 웹 상품 페이지와 코디 페이지가 한 시간 넘게 고객에게 오류를 많이 냈다. 오류는 쿠버네티스 클러스터 하나에서 도는 핵심 데이터 집계 계층 서비스에서 나왔다.

시작은 집계 계층이 호출하는 여러 하위 서비스 가운데 하나에서 난 타임아웃이었다. 집계 계층은 타임아웃 난 호출에 404 로 응답했고, 클라이언트가 재시도하면서 집계 계층으로 들어오는 요청이 치솟았다. 이 요청 급증은 클러스터 DNS 인 CoreDNS 로 가는 DNS 쿼리 급증으로 그대로 이어졌다.

DNS 쿼리가 몰리자 CoreDNS 파드의 메모리 사용량이 치솟았고, CoreDNS 파드들은 한꺼번에 메모리를 다 써서 OOM Killed 상태로 종료됐다. 파드는 첫 OOM 이후 회복하지 못하고 메모리가 바닥나 죽기를 반복했다. 그 결과 클러스터 전체의 DNS 가 완전히 멈췄다. 집계 계층 서비스는 어떤 호스트 이름도 해석하지 못했고 DNS 캐시도 없었기 때문에 하위 서비스로 가는 서킷 브레이커를 열었다.

DNS 가 멈추자 클러스터 내부 모니터링도 함께 완전히 멈췄다. 이 모니터링은 알림을 보내고 지표를 올리려면 외부 서비스와 통신해야 했기 때문이다. 당직 호출이 자동으로 가지 않아, 집계 계층 서비스 당직 엔지니어가 쿠버네티스 담당 당직 엔지니어에게 직접 전화해야 했다.

증상 오류율 상승 DNS 조회 실패 OOMKilled

원인

원인 용량 한계

구성 요소 CoreDNS 컨테이너 메모리 한도 클라이언트 쪽 DNS 리졸버와 캐시

기여 요인 한계 미인지

감지

DNS 장애로 클러스터 내부 모니터링이 함께 멈춰 당직 호출이 자동으로 가지 않았다. 집계 계층 서비스 당직 엔지니어가 평소처럼 자동 호출에 기대지 못하고 쿠버네티스 담당 당직 엔지니어에게 직접 전화했다. 그래서 쿠버네티스 당직 엔지니어가 장애를 알기까지 예상보다 오래 걸렸다. 연락을 받은 엔지니어가 CoreDNS 파드가 OOM 으로 죽고 있는 것을 찾아냈다.

조치

쿠버네티스 당직 엔지니어가 CoreDNS 파드의 메모리 request 와 limit 을 100Mi 에서 2000Mi 로 직접 올렸다.

후속 조치

노드마다 dnsmasq 를 앞에 둔 CoreDNS 를 띄우는 방식으로 더 튼튼한 DNS 구성을 도입한다. 검토하고 시험한 다른 어떤 구성보다 이 방식의 성능이 좋았다.
클러스터 바깥에서 클러스터 전체 상태를 보는 알림을 강화한다. 팀은 클러스터 안 애플리케이션이 영향을 받기 전에, 늦어도 같은 시점에는 클러스터 이상을 알아야 한다.
장애 대응 절차와 도구를 개선한다. 자동 당직 호출이 실패해도 당직 엔지니어가 다른 도구로 옮겨 가지 않고 다른 팀에 바로 에스컬레이션할 수 있게 한다. 채팅 봇으로 에스컬레이션을 단순하게 만드는 방안을 추진하고 있다.

교훈

쿠버네티스 DNS 구성은 충분히 튼튼하지 않았다. 애플리케이션 하나가 DNS 를 사실상 서비스 거부 공격하듯 몰아붙여 클러스터 전체를 멈추게 할 수 있어서는 안 된다. DNS 쿼리를 늘린 애플리케이션의 영향 범위는 적어도 노드 하나, 가능하면 파드 하나 안에 갇혀야 한다.

팀은 conntrack 을 처리하는 리눅스 커널의 경쟁 상태나 ndots 5 문제 같은 쿠버네티스 DNS 문제를 대부분 알고 있었고, 일부는 완화책도 갖고 있었다. 하지만 이 문제들이 DNS 구성에 얼마나 크게 영향을 주는지는 제대로 알지 못했다.

모니터링도 충분히 튼튼하지 않았다. 일부 알림은 클러스터 밖에서 돌았지만 대부분은 클러스터 안에서 돌았다. 그래서 DNS 가 무너졌을 때 당직 엔지니어가 자동으로 호출되지 않았고 복구 시간이 필요 이상으로 길어졌다.

출처

https://github.com/zalando-incubator/kubernetes-on-aws/blob/dev/docs/postmortems/jan-2019-dns-outage.md · github · 보관본

참고 문서

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

kubegap 은 Claude Code 나 Codex 에서 쿠버네티스 클러스터를 읽기만 하며 이 사례와 같은 상태를 점검합니다. 이 사례의 구성 요소: CoreDNS, 컨테이너 메모리 한도, 클라이언트 쪽 DNS 리졸버와 캐시. 점검 항목의 근거는 이 사례 같은 공개 보고서입니다.

kubegap 열기

AI 도구와 스크립트용

이 사례의 JSON: https://incidentlib-api.benchlet.com/cases/IL-0001
가장 비슷한 사례들: https://incidentlib-api.benchlet.com/cases/IL-0001/similar
MCP 서버(Streamable HTTP, 키 없음): https://incidentlib-mcp.benchlet.com/mcp

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

증상

원인

감지

조치

후속 조치

교훈

출처

참고 문서

관련 사례

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

AI 도구와 스크립트용