{"id":"IL-0181","org":"Kevin","date":"2026-02-19","docs":[],"title":{"en":"A traffic spike from an external community post pushed product API pods into CPU throttling under a 1-core limit, and an e-commerce product page slowed down while every pod stayed Running","ko":"외부 커뮤니티 게시글로 트래픽이 몰려 상품 API 파드가 CPU limit 1코어에서 스로틀링되면서 상품 조회 페이지가 매우 느려졌다"},"domain":["kubernetes"],"impact":{"scope":"product lookup page and product API of an e-commerce platform","users":"unknown","region":"unknown"},"review":{"written_by":"session","reviewed_at":null,"reviewed_by":null},"lessons":{"en":"CPU throttling is hard to notice: pods stay Running, nothing restarts and the logs show no clear error, so a pod list does not reveal it and CPU usage metrics do.\n\nSettings that had handled expected event traffic became the bottleneck as soon as one external post multiplied the traffic. The author concludes that the team needs more preparation for traffic pattern changes and more thought about resource settings.","ko":"글쓴이는 예측 가능한 이벤트성 트래픽까지는 받아낼 수 있게 설정해 뒀다고 생각했다. 그러나 외부 커뮤니티 게시글 하나로 트래픽이 폭증하자 그동안 문제없던 리소스 설정이 순식간에 병목이 됐다. CPU 스로틀링은 파드 상태와 로그에 드러나지 않아서 파드 목록이 아니라 CPU 메트릭을 봐야 찾을 수 있었다. 글쓴이는 대규모 트래픽에 미리 대비한 경험이 부족했다고 돌아보고, 트래픽 패턴이 바뀔 때의 대비와 리소스 설정을 더 고민하기로 했다."},"related":[],"sources":[{"url":"https://velog.io/@yardyard/Kubernetes-CPU-Throttling-%EC%9E%A5%EC%95%A0-%EB%8C%80%EC%9D%91%EA%B8%B0","kind":"blog","license":"unknown","archived":null}],"summary":{"en":"The product service pods ran with a CPU request of 500m and a CPU limit of 1 core. When the sudden traffic hit the product lookup API, the containers reached that limit and the Linux CFS (Completely Fair Scheduler) held back their CPU use, so requests were not processed in time even though the pods looked healthy. The author had believed the resource settings could absorb the event traffic the team expected, and a single external post pushed traffic beyond that.\n\nThe author first raised minReplicas of the HorizontalPodAutoscaler for my-service-prd from 5 to 10 (maxReplicas 20, target average CPU utilization 70%). With the same traffic spread over 10 pods, per-pod CPU use dropped and response times returned to normal. The author then raised the container CPU limit from 1 core to 2 cores, noting that the base setting had been 3 cores, and plans to keep adjusting the limit through monitoring so that pods do not take too much node capacity.","ko":"이번 장애는 코드 버그나 인프라 결함에서 시작되지 않았다. 뽐뿌에 플랫폼 링크가 담긴 게시글이 올라오면서 짧은 시간에 사용자가 몰렸고, 상품 조회 API 호출이 상품 관련 파드에 집중됐다. 컨테이너가 CPU limit 인 1코어에 닿자 Linux 의 CFS 스케줄러가 CPU 사용을 강제로 제한했다. 파드는 Running 상태로 남은 채 요청을 제때 처리하지 못했다.\n\n글쓴이는 먼저 HPA 의 minReplicas 를 5에서 10으로 늘렸다. 같은 트래픽이 10개 파드로 나뉘면서 파드당 CPU 사용률이 크게 내려갔고, 이 조치만으로 응답 속도가 정상으로 돌아왔다. HPA 의 maxReplicas 는 20, CPU 평균 사용률 목표는 70% 였다.\n\n파드를 늘려도 파드당 CPU limit 이 낮으면 같은 문제가 되풀이될 수 있어서, Deployment 의 CPU limit 을 1코어에서 2코어로 올렸다. requests 는 cpu 500m, memory 1Gi 그대로였다."},"trigger":{"en":"A post on the external community Ppomppu linked to the platform and brought a large number of users in a short time, who called the product lookup API heavily.","ko":"외부 커뮤니티인 뽐뿌에 플랫폼 링크가 담긴 게시글이 올라와 짧은 시간에 많은 사용자가 몰렸고, 이 사용자들이 상품 조회 API 를 집중적으로 호출했다."},"severity":"unknown","symptoms":["cpu-throttling","high-latency"],"timeline":{"detected_after":null,"resolved_after":null},"date_kind":"published","detection":{"en":"Users reported that the product page would not open. The dashboard showed all pods Running, and the namespace CPU usage near 100% and the CPU usage metrics pointed to throttling.","ko":"사용자에게서 \"페이지가 안 열린다\"는 문의가 들어와 장애를 알았다. 대시보드의 파드 상태는 정상이었고, 네임스페이스 CPU 사용량과 CPU 메트릭을 직접 보고서야 CPU 스로틀링을 확인했다."},"components":["cpu-limit","hpa"],"root_cause":"capacity","remediation":[{"text":{"en":"raised the HPA minReplicas from 5 to 10","ko":"HPA 의 minReplicas 를 5에서 10으로 늘렸다."}},{"text":{"en":"raised the container CPU limit from 1 core to 2 cores","ko":"Deployment 의 CPU limit 을 1코어에서 2코어로 올렸다."}}],"action_items":[{"text":{"en":"Keep adjusting the CPU limit to a suitable level through monitoring","ko":"CPU limit 을 무작정 높이면 노드 자원을 과하게 차지할 수 있으므로, 모니터링하면서 적정 수준으로 계속 조정한다."}}],"contributing":["monitoring-blind-spot"],"recurrence_of":null,"symptoms_text":{"en":"An e-commerce platform suddenly became slow to respond, worst on the product lookup page, and users began reporting that the page would not open.\n\nThe Kubernetes dashboard showed every pod Running with no restarts. The CPU usage of the affected service's namespace was close to 100%. The pods were not restarted the way an OOMKill would restart them and the logs showed no clear error; looking at the pod list alone, the author did not see the cause. Only the CPU usage metrics showed that the containers were being throttled.","ko":"운영 중인 이커머스 플랫폼의 응답이 갑자기 느려졌다. 상품 조회 페이지가 특히 심했고, 사용자들에게서 \"페이지가 안 열린다\"는 문의가 들어왔다.\n\n쿠버네티스 대시보드에서는 모든 파드가 Running 이었고 재시작도 없었다. 그런데 문제 서비스의 네임스페이스 CPU 사용량은 100% 에 이르렀다.\n\nCPU 스로틀링이 일어나도 파드는 Running 으로 남고 OOMKill 처럼 재시작되지도 않는다. 로그에도 뚜렷한 오류가 남지 않고 응답만 느려진다. 그래서 대시보드에서 파드 목록만 볼 때는 원인을 전혀 짐작하지 못했고, CPU 사용량 메트릭을 직접 보고서야 스로틀링을 확인했다."},"updated_at":"2026-11-10T00:00:37.565963Z","url":"https://benchlet.com/incidentlib/app/cases/IL-0181","org_slug":"kevin"}