{"id":"IL-0205","org":"GitLab","date":"2021-06-21","docs":["https://ops.gitlab.net/gitlab-com/gitlab-com-infrastructure/-/merge_requests/2666"],"title":{"en":"The GKE cluster autoscaler could not add nodes to GitLab.com's production cluster because Google Cloud ran out of SSD persistent disks in us-east1","ko":"Google Cloud us-east1 의 SSD 영구 디스크 재고가 바닥나 GKE 클러스터 오토스케일러가 프로덕션 노드를 늘리지 못했고, API 디플로이먼트가 파드를 띄울 용량을 얻지 못했다."},"domain":["kubernetes","gcp"],"impact":{"scope":"API service degraded for 146 minutes; Auto-Deploy blocked for 1.5 days; Sidekiq, Git and the CI runners also affected","users":"All GitLab.com customers during the 146 minutes of API degradation; all requests in that period were slow","region":"GCP us-east1"},"review":{"written_by":"session","reviewed_at":null,"reviewed_by":null},"lessons":{"en":"A cloud region can run out of one specific resource, here SSD persistent disks, and the only error may be a generic ZONE_RESOURCE_POOL_EXHAUSTED that does not name it. GitLab could neither monitor nor reserve resource availability, so detection took 22 hours and the cause came from Google Cloud support.\n\nThe workloads ran fine on pd-standard disks. A second problem found on the way, a cluster autoscaler that does not fall back to another matching node pool when one cannot scale, slowed the move to the new node pools.","ko":"장애를 수습하는 도중 다른 버그를 만나 대응 전체가 느려졌다. 팀에는 클라우드 자원 가용성을 감시할 수단도, 자원을 미리 예약해 둘 수단도 없었다. 워크로드는 pd-ssd 대신 pd-standard 디스크에서도 문제없이 도는 것으로 보였다."},"related":[],"sources":[{"url":"https://gitlab.com/gitlab-com/gl-infra/production/-/issues/4940","kind":"github","license":"unknown","archived":null}],"summary":{"en":"GitLab.com runs its Kubernetes services on GKE in us-east1, on node pools backed by SSD persistent disks. Google Cloud ran short of SSD stock in that region, so neither the cluster autoscaler nor the CI runners could create machines. The shortage started to hurt the API service on 2021-06-21, when it needed to scale up with user traffic and no new nodes came up; for about 146 minutes the API was degraded with slow responses.\n\nGoogle Cloud support said the shortage did not affect pd-standard disks, so the team added a node pool with pd-standard disks and, when it did not scale up by itself, scaled it by hand across all three zones to relieve the API. Auto-Deploy stayed blocked for about 1.5 days. Moving the other workloads to new pd-standard node pools exposed a cluster autoscaler bug: when one node pool that matches a pod's selector cannot scale, the autoscaler does not try another node pool whose labels also match. Google listed this as a known issue with no date for a fix, so the team changed node pools and nodeSelectors for the remaining workloads. The first canary deploy completed at 16:28 and the first production deploy since the start of the incident at 19:21 UTC on 2021-06-22.\n\nAfter about a day running mainly on the pd-standard node pools with no problems, the team removed the SSD-backed node pools. The review records a time to detection of 22 hours and states that no GitLab change triggered the incident.","ko":"이번 장애는 여러 문제가 얽혀 있었고, 대응하는 동안 다른 문제도 몇 가지 드러났다. 시작은 CI 러너가 새 머신을 띄우지 못한 장애 #4937 이었고, 원인은 GitLab 이 쓰는 GCP us-east1 리전의 SSD 부족이었다. API 서비스에는 다음 날 영향이 왔다. 사용자 트래픽과 함께 커지는 부하를 받으려고 API 가 노드를 늘려야 했는데 새 노드가 올라오지 않았다. 팀은 SSD 를 쓰지 않는 노드를 올리고 API 가 도는 노드 풀을 손으로 늘려 이 문제를 풀었다. API 서비스는 약 146분 동안 성능이 떨어진 상태였고, 사용자는 느린 응답을 겪었다. 오류율이 올라간 흔적은 없었다.\n\nAPI 를 수습한 뒤에도 Auto-Deploy 가 막혀 있었다. 새 파드를 스케줄하려면 새 노드가 필요했는데 staging, canary, production 어디에서도 노드를 만들 수 없었다. 팀은 그날 내내 pd-standard 디스크를 쓰는 새 노드 풀을 올렸고, 이 과정에서 클러스터 오토스케일러 버그를 새로 만났다. 셀렉터에 맞는 노드 풀 하나가 확장하지 못하면 라벨이 맞는 다른 노드 풀로 확장을 시도하지 않는 문제였다. Auto-Deploy 는 1.5일 동안 막혔고, 2021-06-22 16:28 에 canary 배포가, 19:21 에 장애 이후 첫 프로덕션 배포가 끝났다.\n\n팀은 모든 쿠버네티스 리소스를 pd-standard 디스크로 옮기기로 했다. 하루 동안 주로 새 노드 풀에서 운영하며 이상한 동작이 없는 것을 확인한 뒤 SSD 노드 풀을 정리했다. 영향받은 서비스는 API, Sidekiq, Git, GCP, Auto-Deploy 였다. 장애를 알아차리기까지 22시간이 걸렸다."},"trigger":{"en":"Google Cloud ran out of SSD persistent disk stock in us-east1, the region GitLab.com runs in, while the API service needed more nodes for rising user traffic.","ko":"GitLab 이 운영하는 GCP us-east1 리전에서 SSD 재고가 바닥난 상태였는데, 사용자 트래픽이 늘어 API 서비스가 노드를 늘려야 했다."},"severity":"unknown","symptoms":["autoscaler-scale-up-failed","high-latency","pod-pending","deploys-failing"],"timeline":{"detected_after":"22h","resolved_after":"2d 8h 51m"},"date_kind":"incident","detection":{"en":"There was no alert on resource availability. Apdex and Rails queuing began trending the wrong way at 08:05 UTC and an engineer declared the incident in Slack at 08:43; finding the cause took a lot of log digging: cluster autoscaler errors about node pools in backoff, then ZONE_RESOURCE_POOL_EXHAUSTED at the instance-group level, and finally Google Cloud support naming SSD as the exhausted resource.","ko":"로그를 한참 뒤져서 찾았다. 클러스터 오토스케일러 오류는 일부 노드가 백오프 상태라 확장할 수 없다고만 했고, 인스턴스 그룹 수준 오류도 ZONE_RESOURCE_POOL_EXHAUSTED 뿐이어서 어떤 자원이 바닥났는지 알 수 없었다. 결국 GCP 지원팀이 SSD 재고 부족을 알려 주었다. 탐지까지 22시간이 걸렸고, 팀은 자원 가용성 알림이 있었다면 탐지와 진단을 앞당길 수 있었다고 보았다."},"components":["cluster-autoscaler","node-pool"],"root_cause":"cloud-provider","remediation":[{"text":{"en":"added a node pool that uses pd-standard disks","ko":"09:55 에 pd-standard 디스크를 쓰는 노드 풀을 하나 더 만들었다."}},{"text":{"en":"scaled the new node pool by hand across all three zones to relieve the API","ko":"10:37 에 새 노드 풀이 늘어나지 않자 API 부담을 덜려고 이 노드 풀을 세 존 모두에서 손으로 늘렸다."}},{"text":{"en":"brought more pd-standard node pools online for the other blocked workloads","ko":"13:42 에 배포가 막혀 있고 다른 워크로드도 같은 영향을 받고 있어서 pd-standard 디스크를 쓰는 새 노드 풀들을 올리기로 했다."}},{"text":{"en":"stopped production deployments and opened a Google Cloud support case about the cluster autoscaler not working with the new node pools","ko":"18:16 에 canary 시험에서 클러스터 오토스케일러가 새 노드 풀과 함께 동작하지 않자 프로덕션 배포를 막는다고 공지하고, 오토스케일러 문제로 Google 에 지원 케이스를 열었다."}},{"text":{"en":"changed node pools and nodeSelectors so the remaining workloads ran on pd-standard nodes","ko":"18:26 에 남은 워크로드의 노드 풀과 nodeSelector 를 바꾸는 인프라 작업을 시작했다."}},{"text":{"en":"removed the SSD-backed node pools after a day without problems","ko":"pd-standard 노드 풀 위주로 하루 동안 운영하며 문제가 없는 것을 확인한 뒤 SSD 노드 풀을 정리해 없앴다."}}],"action_items":[{"text":{"en":"Move Kubernetes services to pd-standard disks (delivery#1837)","ko":"쿠버네티스 서비스를 pd-standard 디스크로 옮겼다."}},{"text":{"en":"Capture resource exhaustion errors as a metric","ko":"자원 고갈 오류를 지표로 수집한다."}}],"contributing":["monitoring-blind-spot","limited-debug-access","overlapping-failures"],"recurrence_of":null,"symptoms_text":{"en":"At 08:05 UTC on 2021-06-21 the API service's Apdex (the share of requests that finish within a target time) and Rails request queuing began trending the wrong way. At 09:01 the team found the API deployment unhealthy: it needed more pods for the day's growing traffic, but no new nodes could be added to give it pod capacity. Users saw slow responses; the review found no sign that error rates rose.\n\nThe first sign had come the day before: at 10:30 UTC on 2021-06-20 the cluster autoscaler first failed to add nodes to the production cluster for a Sidekiq workload, and at 05:51 on 2021-06-21 the CI runners began failing to start new machines (tracked separately in issue #4937). The cluster autoscaler errors said that some node pools were in a backoff state but not why. At the instance-group level the only error was ZONE_RESOURCE_POOL_EXHAUSTED, which did not say which resource was exhausted. At 08:19 Google Support told GitLab that Google was low on SSD stock.\n\nOnce the API had recovered, Auto-Deploy stayed blocked, because new pods in staging, canary and production all needed new nodes. A node pool with pd-standard disks added at 09:55 did not scale up on its own, and at 18:16 testing in the canary stage showed that the cluster autoscaler did not work with the new node pools, so production deployments were stopped.","ko":"2021-06-21 08:05 UTC 부터 API 의 Apdex 가 나빠지고 Rails 대기열이 늘어나는 추세가 보였다. Apdex 는 목표 시간 안에 끝난 요청의 비율로 사용자 만족도를 나타내는 지표다. 08:43 에 ahmad 가 Slack 에서 장애를 선언했고, 09:01 에 API 디플로이먼트가 비정상 상태이고, 노드를 늘려 파드 용량을 더할 수도 없다는 것을 확인했다.\n\n징후는 그보다 먼저 나타나 있었다. 2021-06-20 10:30 에 클러스터 오토스케일러가 Sidekiq 을 위해 프로덕션 클러스터의 노드를 늘리려다 처음으로 실패했다. 2021-06-21 05:51 부터는 CI 러너에서 SSD 고갈 징후가 보였다. CI 러너가 새 머신을 띄우지 못한 문제는 별도 장애 #4937 로 다루고 있었다.\n\n클러스터 오토스케일러 로그에는 일부 노드가 백오프 상태라 확장할 수 없다는 오류만 있었다. 노드 풀이 왜 백오프 상태인지는 로그 어디에도 없었다. 팀은 다른 경로로 인스턴스 그룹 수준의 오류를 찾아냈지만, 거기에도 ZONE_RESOURCE_POOL_EXHAUSTED 만 있었고 어떤 자원이 바닥났는지는 나오지 않았다. 08:19 에 Google 지원팀이 SSD 재고가 부족하다고 알려 왔고, 바닥난 자원이 무엇인지는 결국 GCP 지원팀만 알려 줄 수 있었다.\n\nAPI 를 수습한 뒤에도 새 파드를 띄울 노드를 만들 수 없어서 staging, canary, production 전체에서 Auto-Deploy 가 막혔다. pd-standard 디스크를 쓰는 새 노드 풀을 만들자, 이번에는 클러스터 오토스케일러가 새 노드 풀을 늘리지 않았다. 셀렉터에 맞는 노드 풀 하나가 확장에 실패하면 라벨이 맞는 다른 노드 풀로는 확장을 시도하지 않는 버그였다. Google 도 아는 문제였지만 수정 일정은 없었다."},"updated_at":"2026-11-10T00:00:41.056596Z","url":"https://benchlet.com/incidentlib/app/cases/IL-0205","org_slug":"gitlab"}