{"id":"IL-0096","org":"2i2c","date":"2022-11-14","docs":["https://github.com/2i2c-org/infrastructure/issues/1915","https://github.com/2i2c-org/infrastructure/issues/1944","https://github.com/2i2c-org/infrastructure/issues/1945","https://github.com/2i2c-org/team-compass/issues/574"],"title":{"en":"A GKE node pool pinned to the europe-west2-b zone could not scale for 6.5 hours because Google ran out of resources in that zone (ZONE_RESOURCE_POOL_EXHAUSTED)","ko":"GCP europe-west2-b 존의 자원이 바닥나 이 존 하나에 묶인 GKE 노드 풀이 늘어나지 못했고, LIS 허브의 사용자 서버가 6시간 30분 동안 뜨지 않았다."},"domain":["kubernetes","gcp"],"impact":{"scope":"LIS JupyterHub: user servers could not start because its node pool could not scale","users":"unknown","region":"europe-west2 (London), zone europe-west2-b"},"review":{"written_by":"session","reviewed_at":null,"reviewed_by":null},"lessons":{"en":"A node pool pinned to one zone for storage performance cannot scale when the cloud provider runs out of capacity in that zone. The autoscaler's \"backoff after failed scale-up\" message usually points to quotas, and raising quotas does nothing here; the ZONE_RESOURCE_POOL_EXHAUSTED error in the logs is what identifies a zone without capacity.\n\nThe review found that one engineer wearing many hats (incident commander, comms and debugging), with pages not reaching the other responders, made the response harder; a team response would have given more support.","ko":"엔지니어 한 명이 인시던트 지휘, 공지, 디버깅을 오랫동안 혼자 맡았다. 팀이 함께 나서서 이 엔지니어를 더 많이 도울 수 있었다. 호출 알림이 대응 엔지니어에게 닿지 않아 이 문제가 더 커졌다. \"backoff after failed scale-up\" 은 보통 쿼터 문제지만 이번에는 쿼터를 올려도 소용이 없었다. 원인은 로그의 ZONE_RESOURCE_POOL_EXHAUSTED 오류에서 드러났다."},"related":[],"sources":[{"url":"https://github.com/2i2c-org/incident-reports/blob/main/reports/2022-11-14-lis-hub-zone-pool-resource-exhaustion.pdf","kind":"github","license":"unknown","archived":null}],"summary":{"en":"2i2c runs the LIS JupyterHub on a regional GKE cluster in europe-west2 (London). To get the best performance from its NFS Filestore, the nodes were restricted to the B zone, where the Filestore is. When Google's europe-west2-b zone ran out of resources at 10 AM UK time, the cluster autoscaler could not add nodes, new user server pods could not be scheduled, and the hub gave up on each server after 600 seconds.\n\nFor a long period one engineer handled the incident alone as incident commander, communicator and debugger, and pages did not reach the other response engineers. The error message pointed toward quotas, so time went into raising the SSD and CPU quotas, resizing the node pool by hand and restarting the hub, none of which helped. The ZONE_RESOURCE_POOL_EXHAUSTED error in the logs showed that Google had no more resources in the requested zone.\n\nThe affected node pool was edited in the GCP console to allow nodes in the A and C zones of the region as well, and new nodes came up in europe-west2-c. The report calls this a temporary fix, because the NFS Filestore is now used across zones, which costs performance. Impact lasted from 02:00 to 08:30 Pacific, 6 hours 30 minutes.","ko":"2i2c 는 리전 클러스터를 배포하지만, 성능을 높이려고 노드를 NFS Filestore 와 같은 존 하나에만 두도록 묶어 두었다. 2022년 11월 14일 영국 시각 오전 10시, 태평양 시각 02:00 에 Google Cloud 런던 리전인 europe-west2 의 B 존에서 할당할 자원이 바닥났다. 그 결과 LIS 허브 클러스터가 늘어나지 못했고 사용자는 \"backoff after failed scale-up\" 메시지를 봤다.\n\n엔지니어는 이 오류를 흔한 쿼터 문제로 보고 Persistent Disk SSD 쿼터와 CPU 쿼터를 올렸지만 둘 다 효과가 없었다. 결국 로그에서 ZONE_RESOURCE_POOL_EXHAUSTED 오류를 찾았고, 요청한 존에 Google 의 자원이 남아 있지 않다는 뜻임을 확인했다. GCP 콘솔에서 해당 노드 풀을 고쳐 같은 리전의 A 존과 C 존에도 노드를 만들 수 있게 하자 문제가 풀렸다. 새 노드는 europe-west2-c 에 생겼다. 영향은 태평양 시각 02:00 부터 08:30 까지 6시간 30분 이어졌다.\n\n이 조치는 임시방편이다. NFS Filestore 를 존을 넘어 쓰게 되므로 성능이 떨어진다. 장애 동안 엔지니어 한 명이 인시던트 지휘, 공지, 디버깅을 오랜 시간 혼자 맡았다. 호출 알림도 대응 엔지니어에게 닿지 않았다."},"trigger":{"en":"At 10 AM UK time on 14 November 2022, the B zone of Google Cloud's europe-west2 region (London) ran out of resources to allocate. The LIS cluster's nodes were restricted to that zone.","ko":"영국 시각 오전 10시에 Google Cloud europe-west2 리전의 B 존에서 할당할 자원이 바닥났다."},"severity":"unknown","symptoms":["autoscaler-scale-up-failed","pod-pending","service-unavailable"],"timeline":{"detected_after":"3h 40m","resolved_after":"6h 30m"},"date_kind":"incident","detection":{"en":"A user reported the \"backoff after failed scale-up\" error; an engineer opened the incident at 5:40 AM Pacific, about three hours and forty minutes after the zone ran out of resources.","ko":"사용자가 \"backoff after failed scale-up\" 오류를 보고하면서 장애가 드러났다. 영향은 태평양 시각 02:00 에 시작됐고, 인시던트는 3시간 40분 뒤인 05:40 에 열렸다."},"components":["node-pool","cluster-autoscaler"],"root_cause":"cloud-provider","remediation":[{"text":{"en":"edited the node pool in the GCP console to allow node creation in the A and C zones of europe-west2, which were not exhausted","ko":"GCP 콘솔에서 해당 노드 풀을 고쳐, 자원이 남아 있던 같은 리전의 A 존과 C 존에도 노드를 만들 수 있게 했다."}}],"action_items":[{"text":{"en":"Either restrict the node pool back to the B zone after the Black Friday event, or move the cluster and the NFS Filestore to the A zone (infrastructure issue #1944)","ko":"다음 둘 중 하나를 한다. 블랙 프라이데이 행사가 끝나면 노드 풀을 다시 B 존으로만 묶거나, 클러스터와 NFS 를 A 존으로 옮긴다."}},{"text":{"en":"Investigate an enterprise plan that allows a regional NFS, at higher cost (infrastructure issue #1945)","ko":"리전 단위 NFS 를 쓸 수 있는 엔터프라이즈 요금제를 알아본다. 비용은 더 든다."}},{"text":{"en":"Make sure PagerDuty notifications always get through to engineers (team-compass issue #574)","ko":"PagerDuty 알림이 언제나 엔지니어에게 닿도록 한다."}}],"contributing":["single-point-of-failure","paging-failed"],"recurrence_of":null,"symptoms_text":{"en":"A user of the LIS JupyterHub reported a \"backoff after failed scale-up\" error, and user servers would not start. An engineer opened incident #36, \"LIS hub cannot scale\", at 5:40 AM Pacific on 14 November 2022.\n\nThe pod events read \"Warning FailedScheduling 3m29s http://gke.io/optimize-utilization-scheduler 0/2 nodes are available: 2 node(s) didn't match Pod's node affinity/selector. preemption: 0/2 nodes are available: 2 Preemption is not helpful for scheduling.\" and \"Normal NotTriggerScaleUp 3m27s cluster-autoscaler pod didn't trigger scale-up: 1 node(s) didn't match Pod's node affinity/selector, 1 in backoff after failed scale-up\". The hub log showed \"sgibson91's server failed to start in 600 seconds, giving up\", \"3 consecutive spawns failed. Hub will exit if failure count reaches 5 before succeeding\" and \"asyncio.exceptions.TimeoutError: pod lis/jupyter-sgibson91 did not start in 600 seconds!\".\n\nBecause \"backoff after failed scale-up\" usually means a quota problem, the engineer first doubled the Persistent Disk SSD quota, which was shown in red, and later doubled the CPU quota to 48; neither helped. A 100GB persistent volume claim belonging to the Prometheus server turned up but did not explain the failure. Resizing the nb-user node pool to one node by hand completed in the GCP console, yet the node count stayed at 0 and kubectl get nodes showed no new node. Deleting the hub pod did not help either.\n\nThe logs turned out to contain ZONE_RESOURCE_POOL_EXHAUSTED errors. Another engineer found that the first one had appeared at 10 AM UK time, three hours and forty minutes before the incident was opened.","ko":"2022년 11월 14일 LIS 허브 사용자가 \"backoff after failed scale-up\" 오류를 보고했다. 사용자 서버가 뜨지 않았고 노드 풀이 늘어나지 않았다.\n\n파드 이벤트에는 다음 두 줄이 찍혔다. 첫 줄은 \"Warning FailedScheduling 3m29s http://gke.io/optimize-utilization-scheduler 0/2 nodes are available: 2 node(s) didn't match Pod's node affinity/selector. preemption: 0/2 nodes are available: 2 Preemption is not helpful for scheduling.\" 이고, 둘째 줄은 \"Normal NotTriggerScaleUp 3m27s cluster-autoscaler pod didn't trigger scale-up: 1 node(s) didn't match Pod's node affinity/selector, 1 in backoff after failed scale-up\" 이다. 허브 로그에는 \"sgibson91's server failed to start in 600 seconds, giving up.\", \"3 consecutive spawns failed. Hub will exit if failure count reaches 5 before succeeding\", \"pod lis/jupyter-sgibson91 did not start in 600 seconds!\" 가 남았다.\n\n엔지니어는 \"backoff after failed scale-up\" 이 보통 쿼터 문제라고 보고, 빨간색으로 표시된 Persistent Disk SSD 쿼터를 두 배로 올렸다. 효과가 없었다. 프로메테우스 서버가 쓰는 100GB PVC 를 찾았지만, 이 PVC 가 스케일 실패와 무슨 상관인지는 알 수 없었다. CPU 쿼터도 48로 두 배 올렸지만 소용없었다. 사용자 서버라도 하나 띄워 보려고 콘솔에서 nb-user 노드 풀을 노드 1개로 직접 늘렸다. 콘솔에는 크기 조정이 끝났다고 나왔지만 `k get nodes` 에 새 노드가 보이지 않았고 콘솔의 노드 수도 0 그대로였다. 허브 파드를 지워 봤지만 이것도 효과가 없었다.\n\n결국 로그에서 ZONE_RESOURCE_POOL_EXHAUSTED 오류를 찾았다. 첫 오류는 영국 시각 오전 10시에 찍혀 있었다. 엔지니어들은 이 오류가 요청한 존에 Google 이 내줄 자원이 더는 없다는 뜻임을 확인했다."},"updated_at":"2026-11-10T00:00:32.751154Z","url":"https://benchlet.com/incidentlib/app/cases/IL-0096","org_slug":"2i2c"}