Incident Library

IL-0466 Kubernetes project · 2019-02-08kubernetesgcp

Prow 가 테스트 작업을 서비스 클러스터에 스케줄해 작업이 뜨지 못하고 Prow 전체가 느려졌다

2019-02-08 13:20 PST 에 Prow 의 자동 버전 올림 PR 이 머지돼 배포되자, prow.k8s.io 가 테스트 작업을 빌드 클러스터가 아닌 Prow 서비스 클러스터에 스케줄하기 시작했다. 빌드 클러스터 시크릿에는 빌드 클러스터를 가리키는 "default" 라는 클러스터 별칭이 그 이름 그대로 정의돼 있었다. 새 클라이언트 코드 리팩터링은 이 별칭을 무시했고, Prow 는 기본적으로 모든 워크로드를 기본 별칭인 서비스 클러스터에 스케줄한다. 서비스 클러스터에 스케줄된 작업은 자격 증명과 볼륨이 없어 시작하지 못했다. 서비스 클러스터의 자원이 바닥나 다른 Prow 컨트롤러가 매우 느려지거나 쓸 수 없게 됐다.

16: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 메일링 리스트에 알렸다. 이 동작이 왜 비결정적으로 나타나는지는 아직 밝히지 못했다.

심각도
–
영향 범위
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
영향 사용자
–
지역
–
감지까지
2h 18m
복구까지
3h 44m

증상

16:04 PST 에 Prow 의 응답이 매우 느려졌다. hook 의 응답이 5분쯤 늦었고 봇 명령이 응답하지 않았으며, /lgtm 과 담당자 지정이 오류를 냈다. 작업은 네트워크 문제로 실패하고 GCS 에 로그를 올리지 못했다.

처음에는 GitHub 문제를 의심했지만 githubstatus.com 은 모두 정상이라고 했다. 그 무렵 cat 명령을 부른 엔지니어에게는 "https://thecatapi.com appears to be down" 이라는 답이 돌아왔다.

16:19 에 Prow 서비스 클러스터 노드의 CPU 와 메모리가 비정상적으로 높았다. kubectl top nodes 에 `gke-prow-default-pool-116f5d3e-bl6h 4022m 102% 13681Mi 110%` 가 찍혔다.

16:21 에 빌드 클러스터에 있어야 할 파드 수백 개가 서비스 클러스터에서 Pending 이었다. GKE 콘솔에는 스케줄할 수 없는 파드가 225개로 보였고, test-pods 네임스페이스에는 맞는 시크릿을 찾지 못해 멈춘 Pending 파드가 600개 있었다. 서비스 클러스터에 스케줄된 작업은 볼륨이 없어 시작하지 못했다.

16:40 에 Prow 를 직전 버전 v20190206-b01b288 로 롤백하고 16:50 에 kubectl apply 로 직접 배포했지만, 17:07 에도 문제가 그대로였다. 수요일 버전으로 되돌려도 서비스 클러스터에 스케줄되는 일은 계속됐다.

증상 파드 Pending노드 CPU 고부하지연 시간 증가

원인

원인 배포 결함

구성 요소 CI 시스템
기여 요인 스테이징 불일치리소스 요청과 한도 미설정디버그 접근 제한
촉발
13:20 PST 에 Prow 가 자동으로 만든 버전 올림 PR 이 머지돼 배포가 시작됐다. 새로 들어간 클라이언트 코드 리팩터링이 빌드 클러스터 시크릿에 적힌 "default" 클러스터 별칭을 무시해, Prow 가 작업을 기본 별칭인 서비스 클러스터에 스케줄하기 시작했다.

감지

16:04 PST 에 담당자가 PR 을 보다가 cat 명령이 동작하지 않는 것을 알아챘다. githubstatus.com 은 정상이었다. Slack 에서 Prow 노드가 CPU 와 메모리를 100% 넘게 쓰는 것을 찾았고, 이어서 test-pods 네임스페이스에서 시크릿을 찾지 못해 멈춘 Pending 파드 600개를 확인했다.

조치

후속 조치

교훈

사람들이 자리에 있어 문제를 적극적으로 찾고 완화했다. 이번에도 금요일 오후에 일어났고, 동작이 비결정적이었다. 실제 스테이징 Prow 가 필요하다. 지금은 OpenShift 의 Prow 가 잘 돌면 쿠버네티스 Prow 를 올려도 안전하다고 보며 서로에게 기댄다. 그러나 빌드 클러스터를 정의하는 방식처럼 Prow 마다 구성이 다르므로, 쿠버네티스 Prow 와 매우 비슷한 스테이징 환경이 있어야 한다. 크게 바꾸는 Prow 변경은 e2e 테스트를 늘리거나 실제 스테이징 Prow 를 두어 더 조심해서 배포해야 한다.

출처

참고 문서

관련 사례

내 클러스터에도 있는지 확인하기

kubegap 은 Claude Code 나 Codex 에서 쿠버네티스 클러스터를 읽기만 하며 이 사례와 같은 상태를 점검합니다. 이 사례의 구성 요소: CI 시스템. 점검 항목의 근거는 이 사례 같은 공개 보고서입니다.

kubegap 열기

AI 도구와 스크립트용

API 는 키가 필요 없습니다. MCP 서버는 search_incidents, get_incident, list_incidents, get_topic, vocab 도구를 내놓습니다. 사용법은 API 와 MCP.