{"id":"IL-0055","org":"Target","date":"2018-09-20","docs":[],"title":{"en":"A failing CronJob with the default concurrency policy piled up thousands of restarting pods and took down a cluster","ko":"실패하는 CronJob 이 기본 concurrencyPolicy 때문에 겹겹이 쌓여 재시작하는 파드가 수천 개로 늘었고 클러스터가 내려갔다"},"domain":["kubernetes"],"impact":{"scope":"one Kubernetes cluster down; the autoscaled cluster grew to a few hundred virtual CPUs","users":"unknown","region":"unknown"},"review":{"written_by":"session","reviewed_at":null,"reviewed_by":null},"lessons":{"en":"When deploying a CronJob, set its concurrency policy to Replace or Forbid; with the default, failing runs accumulate and restart together.\n\nAn application should handle a missing dependency with probes and bounded back-off rather than crash in a loop, which also keeps it from hammering a dependency that is already struggling.","ko":"CronJob 을 배포할 때는 concurrencyPolicy 를 Replace 나 Forbid 로 정한다. 기본값에서는 실패한 작업이 쌓여 한꺼번에 재시작한다. 오토스케일링이 켜진 클러스터에서는 이렇게 늘어난 파드가 그대로 노드 증가와 비용 증가로 이어진다. 발표자는 의존 대상에 연결하지 못할 때 바로 죽어 재시작을 반복하기보다 지수 백오프로 일정 시간 재시도한 뒤 종료하라고 권했다. readiness 검사와 liveness 검사도 쓰라고 했다."},"related":[],"sources":[{"url":"https://www.youtube.com/watch?v=V0DVkrHf08k","kind":"talk","license":"unknown","archived":null}],"summary":{"en":"The speaker began her career at Target, which started running Kubernetes about three years before the talk for thousands of application developers who were eager to use it but, in her words, not ready for it. She goes through the mistakes she saw there, several of which took a cluster down, and calls the failing CronJob the most common cause of a cluster outage she has seen.\n\nA CronJob's default concurrency policy lets a new run start while earlier runs still exist. When the job fails, for example because the database it writes to is not there, each run keeps restarting and the next scheduled run adds another restarting pod instead of replacing the old one. A job scheduled every minute that fails for three days produces 4,320 restarting pods. On this cluster the pods reached about four thousand, the autoscaled cluster grew to a few hundred virtual CPUs, and the cluster went down.\n\nHer advice is to set the CronJob concurrency policy to Replace or Forbid, and to make applications fail well: use init containers, readiness and liveness probes, and retry a missing dependency such as a database with exponential back-off for a bounded time instead of crashing and restarting against it in a tight loop.","ko":"Target 에서 일했던 발표자가 쿠버네티스 클러스터가 내려간 원인이 된 실수들을 소개했다. 이 사례는 발표자가 가장 흔하게 본 원인으로 꼽은 CronJob 건이다.\n\nCronJob 의 concurrencyPolicy 기본값은 작업을 동시에 실행하도록 허용한다. 그래서 작업이 실패해 재시작하는 동안에도 다음 작업이 새로 만들어졌고, 새 작업이 앞선 작업을 대신하지 않고 나란히 쌓였다. 발표자의 계산으로는 매분 실행되는 작업 하나가 사흘 동안 실패하면 재시작하는 파드가 4320개가 된다. 이 클러스터에서는 파드가 약 4천 개에 이르렀다.\n\n클러스터는 오토스케일링을 쓰고 있어서 파드가 늘어나는 만큼 커졌고, 가상 CPU 수백 개 규모가 됐다. 클러스터는 내려갔고 비용도 크게 들었다.\n\n발표자는 CronJob 의 concurrencyPolicy 를 Replace 나 Forbid 로 정하고, 애플리케이션이 실패를 안전하게 다루도록 만들라고 권했다. init 컨테이너와 readiness 검사, liveness 검사를 쓰고, 데이터베이스 같은 의존 대상이 없을 때는 바로 죽어 재시작을 반복하지 말고 지수 백오프로 정해진 시간 동안 재시도하라고 했다."},"trigger":{"en":"A CronJob kept failing.","ko":"CronJob 하나가 계속 실패했다."},"severity":"unknown","symptoms":["service-unavailable"],"timeline":{"detected_after":null,"resolved_after":null},"date_kind":"published","detection":null,"components":["job-controller","node-pool"],"root_cause":"config-change","remediation":[],"action_items":[],"contributing":["default-config-unchanged","automation-amplified"],"recurrence_of":null,"symptoms_text":{"en":"A Kubernetes cluster went down after one CronJob kept failing and its pods piled up. Because each failed run kept restarting instead of being replaced by the next one, the pods accumulated into the thousands. The speaker's arithmetic for a job scheduled every minute that fails for three days is 4,320 restarting pods.\n\nThe cluster was autoscaled, so it grew with the pods. By the time the pods reached about four thousand, the cluster had a few hundred virtual CPUs attached, which also cost a lot of money.","ko":"CronJob 하나가 계속 실패했다. 실패한 작업이 끝나지 않은 채 다음 작업이 계속 만들어졌고, 재시작을 거듭하는 파드가 수천 개로 쌓였다. 발표자의 계산으로는 매분 실행되는 작업 하나가 사흘 동안 실패하면 재시작하는 파드가 4320개가 된다.\n\n클러스터는 오토스케일링을 쓰고 있어서 파드 수를 따라 커졌다. 파드가 약 4천 개에 이르렀을 때 클러스터의 가상 CPU 는 수백 개까지 늘어 있었고, 비용도 크게 들었다. 결국 클러스터가 내려갔다."},"updated_at":"2026-11-08T19:10:30.763984Z","url":"https://benchlet.com/incidentlib/app/cases/IL-0055","org_slug":"target"}