{"id":"IL-0204","org":"Render","date":"2024-12-17","docs":[],"title":{"en":"An etcd memory spike overloaded the control plane of a Render Frankfurt cluster, and DNS then failed because CoreDNS ran on the rebooted control plane nodes and could not start without the API server","ko":"Render 프랑크푸르트 클러스터에서 etcd 메모리 급증으로 컨트롤 플레인이 과부하에 걸렸고, 컨트롤 플레인 노드를 재부팅하자 그 위의 CoreDNS 가 다시 뜨지 못해 DNS 가 멈췄다."},"domain":["kubernetes","networking"],"impact":{"scope":"One of Render's Kubernetes clusters in Frankfurt: deploys and cron job runs failed, then requests to already running services failed once DNS was down","users":"unknown","region":"Frankfurt"},"review":{"written_by":"session","reviewed_at":null,"reviewed_by":null},"lessons":{"en":"CoreDNS can keep answering from its in-memory cache while the API server is down, but it cannot initialise without it. With CoreDNS on the control plane nodes, a reboot or restart during a control plane outage turned a failure of deploys and cron jobs into a failure of requests to services that were already running.\n\nThe core problem was that the data plane was not isolated enough from the control plane: even without the reboot, the etcd memory spike alone could have forced CoreDNS to restart.","ko":"CoreDNS 는 API 서버가 내려가 있어도 메모리 캐시로 DNS 질의에 답할 수 있지만, 초기화할 때는 API 서버가 필요하다. CoreDNS 가 컨트롤 플레인 노드에 있었기 때문에, 컨트롤 플레인 장애 중에 노드를 재부팅하자 새 배포와 크론 잡만 실패하던 장애가 이미 돌던 서비스로 가는 요청까지 실패하는 장애로 커졌다.\n\n핵심 문제는 데이터 플레인이 컨트롤 플레인에서 충분히 분리되어 있지 않았다는 점이다. 노드를 재부팅하지 않았더라도 etcd 메모리 급증만으로 CoreDNS 가 재시작될 수 있었다."},"related":[],"sources":[{"url":"https://render.com/blog/a-hidden-dns-dependency-in-kubernetes","kind":"blog","license":"unknown","archived":null}],"summary":{"en":"Render runs self-managed Kubernetes clusters. In January 2022 an etcd memory spike overloaded the control plane of a cluster in Frankfurt, so deploys and cron jobs failed. The cluster's CoreDNS servers ran on the control plane nodes, and the team rebooted those nodes during the incident. CoreDNS does not need the Kubernetes API server to answer queries, since its kubernetes plugin keeps an in-memory cache, but it does need the API server to initialise. With the API server down, CoreDNS could not start again, and DNS failed for running services too.\n\nThe author notes that even without the reboot, the etcd memory spike alone could have forced CoreDNS to restart, because the data plane was not isolated from the control plane. In response to the incident Render moved CoreDNS from control plane nodes to data plane nodes, and moved etcd to dedicated nodes because etcd performs poorly under resource contention, especially when disk write latency rises.","ko":"2022년 1월 Render 의 프랑크푸르트 클러스터 하나에서 etcd 메모리가 급증해 Kubernetes 컨트롤 플레인이 과부하에 걸렸다. 처음에는 새 배포와 크론 잡 실행만 실패했다. Render 는 이 단계를 매우 나쁘지만 치명적이지는 않은 상태로 봤다.\n\nDNS 서버인 CoreDNS 는 컨트롤 플레인 노드에서 돌고 있었고, 팀은 장애 중에 그 노드들을 재부팅했다. Kubernetes API 서버는 DNS 질의에 답할 때는 필요 없지만 DNS 서버가 초기화할 때는 필요하다. API 서버가 컨트롤 플레인과 함께 내려가 있었기 때문에 CoreDNS 가 다시 시작하지 못했다. 그 결과 이미 돌던 서비스로 가는 요청까지 실패했다. CoreDNS 가 장애 내내 떠 있었다면 kubernetes 플러그인이 관리하는 메모리 캐시로 DNS 요청에 답해 영향을 줄일 수 있었다.\n\nRender 는 데이터 플레인이 컨트롤 플레인에서 충분히 분리되지 않은 것을 핵심 문제로 꼽았다. 노드를 재부팅하지 않았더라도 etcd 메모리 급증만으로 DNS 서버가 재시작될 수 있었다."},"trigger":{"en":"A memory spike in etcd overloaded the cluster's control plane.","ko":"etcd 메모리가 급증해 Kubernetes 컨트롤 플레인이 과부하에 걸렸다."},"severity":"unknown","symptoms":["control-plane-unresponsive","deploys-failing","dns-resolution-failures","high-error-rate"],"timeline":{"detected_after":null,"resolved_after":null},"date_kind":"published","detection":null,"components":["etcd","coredns","kube-apiserver"],"root_cause":"capacity","remediation":[],"action_items":[{"text":{"en":"Run CoreDNS on data plane nodes instead of control plane nodes","ko":"CoreDNS 를 컨트롤 플레인 노드가 아닌 데이터 플레인 노드에서 돌게 했다."}},{"text":{"en":"Run etcd on dedicated nodes","ko":"etcd 를 전용 노드에서 돌게 했다."}}],"contributing":["default-config-unchanged","manual-action-worsened"],"recurrence_of":null,"symptoms_text":{"en":"In January 2022 an etcd memory spike overloaded the Kubernetes control plane of one of Render's clusters in Frankfurt. At first only operations that need the control plane failed: new deploys and cron job runs.\n\nThe incident became far more severe when DNS resolution started failing. From then on, requests to services that were already running failed as well.","ko":"2022년 1월 Render 의 프랑크푸르트 Kubernetes 클러스터 하나에서 새 배포와 크론 잡 실행이 실패했다. etcd 메모리 급증으로 컨트롤 플레인이 과부하에 걸린 상태였다.\n\n처음에는 새 배포와 크론 잡처럼 컨트롤 플레인을 거치는 작업만 실패했다. 장애 중에 컨트롤 플레인 노드를 재부팅한 뒤로 DNS 조회가 실패하기 시작했고, 이미 돌고 있던 서비스로 가는 요청까지 실패했다."},"updated_at":"2026-11-10T00:00:41.007461Z","url":"https://benchlet.com/incidentlib/app/cases/IL-0204","org_slug":"render"}