{"id":"IL-0015","org":"loveholidays","date":"2020-02-03","docs":["https://tools.ietf.org/html/rfc1918","https://cloud.google.com/blog/products/gcp/introducing-shared-vpc-for-google-kubernetes-engine","https://cloud.google.com/blog/products/gcp/introducing-vpc-native-clusters-for-google-kubernetes-engine","https://cloud.google.com/kubernetes-engine/docs/concepts/cluster-autoscaler","https://cloud.google.com/kubernetes-engine/docs/how-to/flexible-pod-cidr","https://cloud.google.com/vpc/docs/using-vpc#expand-subnet"],"title":{"en":"A GKE cluster's /16 pod address range ran out at 256 nodes, leaving new pods Pending and node scale-ups failing","ko":"GKE 가 노드마다 IP 256개를 미리 잡아 /16 파드 주소 범위가 바닥나고 노드 증설과 배포가 멈췄다"},"domain":["kubernetes","gcp","networking"],"impact":{"scope":"one cluster: deployments could not fully roll out and no node could be added","users":"unknown","region":"unknown"},"review":{"written_by":"session","reviewed_at":null,"reviewed_by":null},"lessons":{"en":"In a VPC-native GKE cluster the number of nodes, not the number of pods, uses up the pod range: by default each node reserves 256 addresses, so even a /16 is full at 256 nodes. Maximum pods per node and node size are the practical levers; larger nodes pack better but take more pods down when they fail.","ko":"GKE 는 기본으로 노드마다 IP 256개를 할당한다. /16 처럼 큰 범위도 노드가 256개면 바닥난다. 노드당 최대 파드 수가 파드 IP 소비량을 정하므로, 노드 풀마다 실제로 띄울 파드 수에 맞춰야 한다. 큰 노드를 쓰면 IP 를 효율적으로 쓰고 자원 활용도도 높아지지만, 노드 하나가 죽을 때 더 많은 파드가 함께 내려간다."},"related":["IL-0017"],"sources":[{"url":"https://deploy.live/blog/when-gke-ran-out-of-ip-addresses/","kind":"blog","license":"unknown","archived":"http://web.archive.org/web/20260427185830/https://deploy.live/blog/when-gke-ran-out-of-ip-addresses/"}],"summary":{"en":"loveholidays uses Shared VPC to keep networking and compute in separate projects, and runs VPC-native GKE clusters, which take pod IP addresses from a secondary range of the subnet. The affected cluster had a dedicated subnet whose secondary range was a /16, which looks like room for 65,536 pods.\n\nGKE allows 110 pods per node by default and pre-allocates addresses for them on every node, however few pods actually run there. The team expected that to cap the cluster at 595 nodes (65,536 / 110), but GKE also gives each node a block holding at least twice the maximum pod count, so that addresses are not reused too quickly as pods come and go. Each node therefore took 256 addresses, and 65,536 / 256 = 256 nodes, exactly where the cluster stopped growing.\n\nThe most effective fix was lowering the maximum pods per node on node pools that never run many pods, such as nodes for stateful applications, caches or security-sensitive workloads, which cut overall IP consumption by about 30%. The team also moved some node pools to larger instance types, which run more pods per node and pack them better, at the cost of more pods lost when one node fails. Expanding the subnet, which GCE supports by shortening the mask when no range collides, was considered and not done, because the documentation says nothing about secondary ranges. Two commands helped: kubectl describe -n kube-system configmap cluster-autoscaler-status for the autoscaler state, and kubectl get node NODE-NAME -ojson | jq .status.allocatable.pods for a node's maximum pods.","ko":"loveholidays 는 GKE 에서 공유 VPC 를 쓰고, 클러스터 하나를 전용 서브넷을 둔 VPC 네이티브 모드로 돌린다. VPC 네이티브 클러스터는 파드 IP 를 서브넷의 보조 범위에서 할당한다. 보조 범위가 /16 이라 파드를 최대 65,536개 띄울 수 있다고 봤다.\n\nGKE 는 노드당 최대 파드 수를 기본 110 으로 두고, 노드에 파드를 몇 개만 띄울 계획이어도 IP 110개를 미리 할당한다. 게다가 파드가 노드에 추가되고 제거될 때 IP 재사용을 줄이려고, 최대 파드 수의 두 배 이상을 담을 수 있는 서브넷 마스크를 노드마다 준다. 그래서 노드 하나가 IP 256개를 차지했고, 65,536 / 256 = 256 으로 관찰한 노드 수와 정확히 맞았다. IP 가 바닥나자 클러스터 오토스케일러는 노드를 추가하지 못했고, 배포는 끝까지 롤아웃되지 못했다.\n\n팀은 파드를 많이 띄우지 않을 노드 풀에서 노드당 최대 파드 수를 줄여 전체 IP 사용량을 약 30% 줄였다. 일부 노드 풀의 인스턴스를 키워 노드당 더 많은 파드를 돌리게 했다. 서브넷 확장도 검토했지만 문서가 보조 범위를 다루지 않아 쓰지 않았다."},"trigger":{"en":"The cluster reaching 256 nodes, the most its /16 pod secondary range could hold at 256 addresses per node; every further node creation failed.","ko":"클러스터의 노드 수가 256개에 이르렀다. GKE 는 노드당 최대 파드 수를 기본 110 으로 두고, 그 두 배 이상을 담을 수 있는 서브넷 마스크를 노드마다 미리 할당한다. 노드 하나가 IP 256개를 차지하므로 /16 보조 범위의 65,536개 주소가 노드 256개에서 바닥났다."},"severity":"unknown","symptoms":["pod-pending","no-available-ip","autoscaler-scale-up-failed"],"timeline":{"detected_after":"1h","resolved_after":null},"date_kind":"published","detection":{"en":"A colleague reported in Slack that a deployment was slow; the pending pods' events and the cluster autoscaler status ConfigMap showed the exhausted IP space.","ko":"동료가 슬랙으로 배포가 오래 걸린다고 알려 왔다. 확인해 보니 평소 몇 분이면 끝나는 배포가 한 시간째 새 파드 일부만 띄운 채 멈춰 있었다."},"components":["subnet","cluster-autoscaler","node-pool"],"root_cause":"capacity","remediation":[{"text":{"en":"lowered the maximum pods per node on selected node pools, cutting IP consumption by about 30%","ko":"파드가 많이 뜨지 않을 노드 풀에서 노드당 최대 파드 수를 줄여 전체 IP 사용량을 약 30% 줄였다."}},{"text":{"en":"moved some node pools to larger instance types","ko":"일부 노드 풀의 인스턴스 크기를 키워 노드당 더 많은 파드를 돌리게 했다."}}],"action_items":[{"text":{"en":"Lower the maximum pods per node on node pools that do not run many pods","ko":"상태 저장 애플리케이션, 캐시, 보안을 강화한 워크로드처럼 노드에 파드가 많이 뜨지 않는 노드 풀은 노드당 최대 파드 수를 낮춰 운영한다."}},{"text":{"en":"Use larger instance types in some node pools","ko":"일부 노드 풀에 더 큰 인스턴스를 쓴다."}}],"contributing":["default-config-unchanged","limit-unknown"],"recurrence_of":null,"symptoms_text":{"en":"A colleague wrote in Slack that his application was taking a long time to deploy. A deployment that normally finishes in minutes had been running for about an hour: about half of the new pods were running and serving traffic, and the other half were Pending.\n\nIt did not look like the usual causes of a stuck deployment, such as a missing ConfigMap or Secret or a wrong nodeSelector. Describing one of the pending pods showed \"Warning FailedScheduling 2m18s (x4 over 3m48s) default-scheduler 0/256 nodes are available: 1 node(s) were unschedulable, 173 Insufficient memory, 214 node(s) didn't match node selector, 87 Insufficient cpu.\" The GKE cluster autoscaler, which normally adds nodes in this situation, was getting nowhere, and the round power-of-two number of 256 nodes looked suspicious.\n\nThe cluster autoscaler status, read with kubectl describe -n kube-system configmap cluster-autoscaler-status, showed repeated failures: \"Warning ScaleUpFailed 11m (x14 over 36m) cluster-autoscaler (combined from similar events): Failed adding 3 nodes to group ... Instance 'INSTANCE' creation failed: IP space of 'projects/PROJECT/regions/OUR_REGION/subnetworks/SUBNETWORK' is exhausted.\" That was puzzling, because the cluster's pod range was a /16 with 65,536 addresses and the cluster ran thousands of pods, far from that number.","ko":"동료가 슬랙으로 애플리케이션 배포가 오래 걸린다고 알려 왔다. 평소 몇 분이면 끝나는 배포가 한 시간째 새 파드 일부만 띄운 채 머물러 있었다. 새 파드의 절반쯤은 트래픽을 받고 있었고 나머지 절반은 Pending 상태였다.\n\nPending 파드 하나를 describe 하자 Warning FailedScheduling 2m18s (x4 over 3m48s) default-scheduler 0/256 nodes are available: 1 node(s) were unschedulable, 173 Insufficient memory, 214 node(s) didn't match node selector, 87 Insufficient cpu. 이벤트가 보였다. 보통은 클러스터 오토스케일러가 노드를 늘리는데 이번에는 진척이 없었다. 0/256 이라는, 2의 거듭제곱으로 딱 떨어지는 숫자가 수상했다.\n\nkubectl describe -n kube-system configmap cluster-autoscaler-status 로 오토스케일러 이벤트를 보니 Warning ScaleUpFailed 와 함께 Failed adding 3 nodes to group 이 찍혀 있었다. 원인은 Instance 'INSTANCE' creation failed: IP space of 'projects/PROJECT/regions/OUR_REGION/subnetworks/SUBNETWORK' is exhausted. 였고, 같은 오류가 36분 동안 14번 반복됐다.\n\n팀은 처음에 IP 를 다 썼다는 것을 이해하지 못했다. 파드가 수천 개여도 65,536개 IP 에는 한참 못 미친다고 봤기 때문이다. 그래서 GKE 문서를 다시 찾아봤다."},"updated_at":"2026-11-10T00:00:34.971889Z","url":"https://benchlet.com/incidentlib/app/cases/IL-0015","org_slug":"loveholidays"}