{"id":"IL-0466","org":"Kubernetes project","date":"2019-02-08","docs":["https://github.com/kubernetes/test-infra/pull/11209"],"title":{"en":"Prow scheduled test job pods onto its service cluster, leaving hundreds Pending and starving Prow's own services","ko":"Prow 가 테스트 작업을 서비스 클러스터에 스케줄해 작업이 뜨지 못하고 Prow 전체가 느려졌다"},"domain":["kubernetes","gcp"],"impact":{"scope":"Test jobs scheduled onto the service cluster could not start from 1:46pm to 5:30pm PST, and all other Prow controllers were very slow or unusable from 4:06pm to 5:30pm","users":"unknown","region":"unknown"},"review":{"written_by":"session","reviewed_at":null,"reviewed_by":null},"lessons":{"en":"The behaviour was not deterministic, and the change was deployed on a Friday afternoon. Prow instances are set up differently, for example in how build clusters are defined, so another project's Prow running a version fine does not show it is safe for the Kubernetes Prow, which needs a staging environment that looks like it.","ko":"사람들이 자리에 있어 문제를 적극적으로 찾고 완화했다. 이번에도 금요일 오후에 일어났고, 동작이 비결정적이었다. 실제 스테이징 Prow 가 필요하다. 지금은 OpenShift 의 Prow 가 잘 돌면 쿠버네티스 Prow 를 올려도 안전하다고 보며 서로에게 기댄다. 그러나 빌드 클러스터를 정의하는 방식처럼 Prow 마다 구성이 다르므로, 쿠버네티스 Prow 와 매우 비슷한 스테이징 환경이 있어야 한다. 크게 바꾸는 Prow 변경은 e2e 테스트를 늘리거나 실제 스테이징 Prow 를 두어 더 조심해서 배포해야 한다."},"related":[],"sources":[{"url":"https://github.com/kubernetes/test-infra/blob/master/docs/post-mortems/2019-02-08.md","kind":"github","archived":null}],"summary":{"en":"Prow, the Kubernetes project's CI system, runs its controllers in a service cluster and schedules test jobs into separate build clusters. The build-cluster secret literally defines a \"default\" cluster alias pointing at the build cluster. A client refactor in Prow did not respect that literal alias and fell back to its own default, the service cluster. After a Prow bump was deployed at 13:20 PST on 8 February 2019, test jobs were scheduled into the service cluster, where they could not start because their volumes and credentials were missing, and the service cluster ran out of resources. In the chat, a responder who was surprised that the scheduler could starve the core Prow services asked whether CPU and memory requests and limits were in use, and from the reply took it that no Prow service deployment had them.\n\nProw was first noticed slow at 16:04. At 16:40 Prow was rolled back to v20190206-b01b288 and the pods and ProwJobs in the service cluster were cleaned up, but the responder lacked permission for the manual deployment that was needed, filed an issue and applied the revert by hand with kubectl apply at 16:50. The problem persisted because the bug was older than that bump and did not show deterministically. At 17:15 the literal \"default\" alias was identified, a fix was sent as PR 11209, and Prow was rolled back to v20190125-2aca69d. By 17:59 the wrong pods and ProwJobs were cleaned up again and Prow was healthy; the mailing list was notified at 18:09.","ko":"2019-02-08 13:20 PST 에 Prow 의 자동 버전 올림 PR 이 머지돼 배포되자, prow.k8s.io 가 테스트 작업을 빌드 클러스터가 아닌 Prow 서비스 클러스터에 스케줄하기 시작했다. 빌드 클러스터 시크릿에는 빌드 클러스터를 가리키는 \"default\" 라는 클러스터 별칭이 그 이름 그대로 정의돼 있었다. 새 클라이언트 코드 리팩터링은 이 별칭을 무시했고, Prow 는 기본적으로 모든 워크로드를 기본 별칭인 서비스 클러스터에 스케줄한다. 서비스 클러스터에 스케줄된 작업은 자격 증명과 볼륨이 없어 시작하지 못했다. 서비스 클러스터의 자원이 바닥나 다른 Prow 컨트롤러가 매우 느려지거나 쓸 수 없게 됐다.\n\n16:04 에 Prow 가 느리다는 것을 알아챘고, 16:19 에 서비스 노드의 CPU 와 메모리가 높은 것을, 16:21 에 서비스 클러스터의 Pending 파드 수백 개를 찾았다. 16:40 에 버전 올림 직전인 v20190206-b01b288 로 롤백하고 서비스 클러스터의 파드와 prowjob 을 지웠다. 직접 배포할 권한이 없어 이슈를 연 뒤 16:50 에 kubectl apply 로 배포했지만 문제는 계속됐다. 결함이 들어간 커밋이 그 버전보다 앞에 있었기 때문이다. 17:15 에 시크릿에 \"default\" 라는 별칭이 그 이름 그대로 정의돼 있다는 점에서 원인을 찾았다. 17:25 에 수정 PR 을 올리고, 결함이 들어가기 전인 v20190125-2aca69d 로 다시 롤백했다. 17:59 에 잘못 스케줄된 파드와 prowjob 을 다시 지우고 Prow 가 정상임을 확인했으며, 18:09 에 k-dev 메일링 리스트에 알렸다. 이 동작이 왜 비결정적으로 나타나는지는 아직 밝히지 못했다."},"trigger":{"en":"At 13:20 PST an auto-generated bump PR for Prow was merged and deployed, and Prow started scheduling workloads onto the service cluster.","ko":"13:20 PST 에 Prow 가 자동으로 만든 버전 올림 PR 이 머지돼 배포가 시작됐다. 새로 들어간 클라이언트 코드 리팩터링이 빌드 클러스터 시크릿에 적힌 \"default\" 클러스터 별칭을 무시해, Prow 가 작업을 기본 별칭인 서비스 클러스터에 스케줄하기 시작했다."},"severity":"unknown","symptoms":["pod-pending","node-high-cpu","high-latency"],"timeline":{"detected_after":"2h 18m","resolved_after":"3h 44m"},"date_kind":"incident","detection":{"en":"While working on a PR, a maintainer noticed the bot's cat command failing, found GitHub status normal, learned on Slack that the Prow nodes were above 100% CPU and memory, and then found 600 pending pods in the test-pods namespace.","ko":"16:04 PST 에 담당자가 PR 을 보다가 cat 명령이 동작하지 않는 것을 알아챘다. githubstatus.com 은 정상이었다. Slack 에서 Prow 노드가 CPU 와 메모리를 100% 넘게 쓰는 것을 찾았고, 이어서 test-pods 네임스페이스에서 시크릿을 찾지 못해 멈춘 Pending 파드 600개를 확인했다."},"components":["ci-system"],"root_cause":"deploy-rollout","remediation":[{"text":{"en":"Rolled Prow back to v20190206-b01b288 and cleaned up the pods and ProwJobs in the service cluster","ko":"16:40 에 Prow 를 버전 올림 이전인 v20190206-b01b288 로 롤백했고, 그사이 서비스 클러스터의 파드와 prowjob 을 모두 지웠다."}},{"text":{"en":"Applied the revert by hand with kubectl apply after the deployment permission was missing","ko":"직접 배포할 권한이 없어 이슈를 연 뒤, 16:50 에 되돌린 버전을 kubectl apply 로 직접 배포했다. 문제는 계속됐다."}},{"text":{"en":"Sent a fix, PR 11209, so the client no longer overwrites a provided literal default client","ko":"17:25 에 주어진 \"default\" 클라이언트를 덮어쓰지 않게 하는 수정 PR https://github.com/kubernetes/test-infra/pull/11209 을 올렸다."}},{"text":{"en":"Rolled Prow back to v20190125-2aca69d, from before the bug was introduced","ko":"17:25 에 결함이 들어가기 전인 v20190125-2aca69d 로 Prow 를 다시 롤백했다."}},{"text":{"en":"Cleaned up the wrongly scheduled pods and ProwJobs again and confirmed Prow was healthy","ko":"17:59 에 잘못 스케줄된 파드와 prowjob 을 모두 다시 지우고 Prow 가 정상임을 확인했다."}}],"action_items":[{"text":{"en":"Find out why the bug did not show deterministically","ko":"이 동작이 왜 비결정적으로 나타나는지 더 알아본다."}},{"text":{"en":"Be more careful with sweeping Prow changes, with more end-to-end tests or a real staging Prow","ko":"Prow 를 크게 바꾸는 변경을 배포할 때 더 조심한다. e2e 테스트를 늘리거나 실제 스테이징 Prow 를 둔다."}}],"contributing":["staging-not-representative","no-resource-limits","limited-debug-access"],"recurrence_of":null,"symptoms_text":{"en":"On 8 February 2019 the Kubernetes project's Prow instance at prow.k8s.io became very slow: its controllers took about five minutes to respond to the hook, bot commands such as the cat command stopped working, and the prow.k8s.io site was hard to reach. GitHub status was normal, and the Prow service nodes were found running above 100% of CPU and memory.\n\nkubectl top showed a node of the service cluster at \"gke-prow-default-pool-116f5d3e-bl6h   4022m        102%      13681Mi         110%\". The test-pods namespace of the service cluster held hundreds of test job pods that belonged in the build cluster, 600 Pending pods stuck because they could not find the right secret, and the GKE console showed 225 unschedulable pods. Jobs that did run failed on network operations and on uploading logs to GCS, and /lgtm and assignment commands returned errors.\n\nRolling Prow back to the version before that day's bump, v20190206-b01b288, did not stop the problem. The bug was found when a responder asked whether the cluster file literally defined a \"default\" cluster alias, and a rollback to v20190125-2aca69d, from before the bug was introduced, ended it.","ko":"16:04 PST 에 Prow 의 응답이 매우 느려졌다. hook 의 응답이 5분쯤 늦었고 봇 명령이 응답하지 않았으며, /lgtm 과 담당자 지정이 오류를 냈다. 작업은 네트워크 문제로 실패하고 GCS 에 로그를 올리지 못했다.\n\n처음에는 GitHub 문제를 의심했지만 githubstatus.com 은 모두 정상이라고 했다. 그 무렵 cat 명령을 부른 엔지니어에게는 \"https://thecatapi.com appears to be down\" 이라는 답이 돌아왔다.\n\n16:19 에 Prow 서비스 클러스터 노드의 CPU 와 메모리가 비정상적으로 높았다. kubectl top nodes 에 `gke-prow-default-pool-116f5d3e-bl6h   4022m        102%      13681Mi         110%` 가 찍혔다.\n\n16:21 에 빌드 클러스터에 있어야 할 파드 수백 개가 서비스 클러스터에서 Pending 이었다. GKE 콘솔에는 스케줄할 수 없는 파드가 225개로 보였고, test-pods 네임스페이스에는 맞는 시크릿을 찾지 못해 멈춘 Pending 파드가 600개 있었다. 서비스 클러스터에 스케줄된 작업은 볼륨이 없어 시작하지 못했다.\n\n16:40 에 Prow 를 직전 버전 v20190206-b01b288 로 롤백하고 16:50 에 kubectl apply 로 직접 배포했지만, 17:07 에도 문제가 그대로였다. 수요일 버전으로 되돌려도 서비스 클러스터에 스케줄되는 일은 계속됐다."},"updated_at":"2026-11-14T12:34:11.372118Z","url":"https://benchlet.com/incidentlib/app/cases/IL-0466","org_slug":"kubernetes-project"}