{"id":"IL-0064","org":"Moonlight","date":"2019-01-18","docs":[],"title":{"en":"CPU-heavy pods packed onto one Google Cloud node drove it to kernel panics, and the crash moved from node to node until the site was down","ko":"CPU 를 많이 쓰는 파드가 Google Cloud 노드 하나에 몰려 노드가 커널 패닉으로 죽었고, 다시 배치된 파드가 다음 노드를 또 죽이며 웹사이트와 API 가 멈췄다."},"domain":["kubernetes","gcp"],"impact":{"scope":"website and API: occasional errors from January 18, complete outages on January 22","users":"unknown","region":"unknown"},"review":{"written_by":"session","reviewed_at":null,"reviewed_by":null},"lessons":{"en":"Three replicas give no fault tolerance if the scheduler places them all on one node; anti-affinity rules make the spread explicit. A node failure that comes from the workload itself moves with the workload when the scheduler reschedules it.","ko":"복제본을 세 개 두어도 스케줄러가 한 노드에 몰아 놓으면 그 노드가 단일 장애점이 된다. 사용자에게 응답하는 서비스에는 안티 어피니티 규칙을 넣어 파드를 여러 노드에 나눠 놓아야 한다. 팀은 처음에 클라우드 업체의 네트워크 장애를 원인으로 짐작했지만 실제 원인은 노드의 CPU 포화와 커널 패닉이었다."},"related":[],"sources":[{"url":"https://updates.moonlightwork.com/outage-post-mortem-87370","kind":"blog","license":"unknown","archived":null}],"summary":{"en":"Moonlight's website and API had intermittent outages from January 18 to January 22, ending in periods of complete downtime. The application ran on a managed Kubernetes cluster on Google Cloud with three nodes, and every web-facing application had three replicas. The team expected one replica per node, so that two nodes could fail before the site went down.\n\nThe scheduler did not spread the replicas. It sometimes put all three website pods on one node, together with other CPU-heavy work such as server-side rendering. Those pods drove the node to 100% CPU, the node's kernel panicked, and the node stopped responding. The scheduler then moved all the crashed pods to another node, which went through the same cycle, and the effects compounded. What started with the Redis pod ended with every web-serving pod offline.\n\nThe team first assumed a Google Cloud network outage, because Google had reported networking problems at the time. Google Cloud Support identified the link between sustained full CPU and kernel panics. Adding anti-affinity rules to all major deployments, so their pods are spread across nodes, restored the site. The cause of the kernel panics themselves was still being investigated with Google when the post was written.","ko":"Moonlight 의 웹사이트와 API 가 1월 18일부터 22일까지 간헐적으로 멈췄다. 처음에는 가끔 나는 API 오류였지만 22일에는 서비스가 완전히 내려간 시간이 있었다. Moonlight 는 Google Cloud 의 관리형 쿠버네티스 클러스터를 쓴다.\n\n팀은 처음에 Redis 연결 문제와 Google Cloud 의 네트워크 장애를 의심했다. 실제 패턴은 Google Cloud 지원팀이 찾아냈다. 노드 CPU 사용률이 100% 로 오래 이어지면 VM 이 커널 패닉으로 죽었다.\n\n장애는 이렇게 되풀이됐다. 스케줄러가 CPU 를 많이 쓰는 파드 여러 개를 한 노드에 배치했다. 파드들이 노드 CPU 를 100% 썼고, 노드는 커널 패닉으로 한동안 스케줄러에 응답하지 않았다. 스케줄러는 죽은 파드를 모두 새 노드에 다시 배치했고, 그 노드에서 같은 일이 되풀이되며 피해가 커졌다.\n\nMoonlight 는 노드 세 대에 웹 서비스마다 복제본 세 개를 돌렸다. 노드마다 하나씩 놓아 노드 두 대가 죽어도 버티게 하려는 의도였다. 그러나 쿠버네티스가 웹사이트 파드 세 개를 모두 한 노드에 배치하는 일이 있었고, 그 노드가 단일 장애점이 됐다. 서버 사이드 렌더링처럼 CPU 를 많이 쓰는 다른 애플리케이션도 같은 노드에 몰렸다. 팀은 주요 배포 전부에 안티 어피니티 규칙을 넣어 파드를 여러 노드로 흩었고, 웹사이트가 다시 살아났다. 노드 커널 패닉의 근본 원인은 Google 과 함께 계속 찾고 있다."},"trigger":{"en":"The Kubernetes scheduler put several CPU-heavy pods on the same node, including all three replicas of the website and the server-side rendering pods.","ko":"쿠버네티스 스케줄러가 CPU 를 많이 쓰는 파드 여러 개를 같은 노드에 배치했다. 이 파드들이 노드 CPU 를 100% 쓰자 노드 VM 이 커널 패닉으로 죽었다."},"severity":"unknown","symptoms":["high-error-rate","intermittent-connection-failures","node-not-ready","service-unavailable","node-high-cpu"],"timeline":{"detected_after":null,"resolved_after":"4d"},"date_kind":"incident","detection":{"en":"API errors that looked like Redis connectivity problems, and Kubernetes monitoring that showed nodes and pods as unresponsive. Google Cloud Support later found the link between sustained 100% CPU and kernel panics.","ko":"API 오류가 가끔 나면서 문제가 드러났다. 쿠버네티스 모니터링이 일부 노드와 파드가 응답하지 않는다고 보고했다. 노드가 CPU 100% 상태에서 커널 패닉으로 죽는다는 패턴은 Google Cloud 지원팀이 찾아냈다."},"components":["pod-scheduling","linux-kernel","database"],"root_cause":"capacity","remediation":[{"text":{"en":"added anti-affinity rules to all major deployments so their pods spread across nodes","ko":"주요 배포 전부에 안티 어피니티 규칙을 넣어 파드를 여러 노드에 흩어 놓았다."}}],"action_items":[{"text":{"en":"Keep working with Google Cloud support to find and fix the cause of the node kernel panics","ko":"Google Cloud 지원팀과 함께 노드 커널 패닉의 근본 원인을 찾아 고친다."}}],"contributing":["single-point-of-failure","assumption-unverified","automation-amplified"],"recurrence_of":null,"symptoms_text":{"en":"On Friday, January 18, Moonlight's API began returning occasional errors that looked like connection problems with its Redis database. The API checks Redis on every authenticated request to validate the session. At the same time the Kubernetes monitoring reported some nodes and pods as unresponsive.\n\nOver the weekend, as traffic dropped, the errors mostly went away. On Tuesday morning the website was completely offline, with no external traffic reaching the cluster at all.\n\nThe team first blamed Google Cloud: Google had reported networking service disruptions, and another person on Twitter described similar symptoms. Google Cloud Support escalated the case to its support engineers, who found the real pattern: whenever a node ran at 100% CPU for a sustained period, the virtual machine hit a kernel panic and crashed.\n\nThe failure grew over the days. At first only the Redis pod was crashing; later every pod serving web traffic went offline. Exponential back-off rules made the periods of downtime longer.","ko":"1월 18일 금요일, Moonlight API 가 가끔 오류를 냈다. 처음 오류는 Redis 데이터베이스와 연결이 안 되는 문제로 보였다. Moonlight API 는 인증된 요청마다 Redis 에서 세션을 확인한다.\n\n쿠버네티스 모니터링은 일부 노드와 파드가 응답하지 않는다고 보고했다. 같은 시기에 Google Cloud 가 네트워크 서비스 장애를 알렸고, 팀은 그 장애가 원인이라고 생각했다.\n\n주말에 트래픽이 줄자 오류는 가끔만 났다. 1월 22일 화요일 아침에는 웹사이트가 내려가 클러스터에 외부 트래픽이 하나도 들어오지 않았다. 팀은 트위터에서 비슷한 증상을 겪는 사람을 찾고는 Google 쪽 네트워크 장애라고 믿었고, Google Cloud 지원팀에 연락했다.\n\n처음에는 Redis 파드만 죽었다. 시간이 지나면서 웹 트래픽을 받는 파드가 모두 내려가 서비스 전체가 멈췄다. 지수 백오프 규칙 때문에 다운타임은 갈수록 길어졌다."},"updated_at":"2026-11-10T00:00:39.213748Z","url":"https://benchlet.com/incidentlib/app/cases/IL-0064","org_slug":"moonlight"}