GKE 가 노드마다 IP 256개를 미리 잡아 /16 파드 주소 범위가 바닥나고 노드 증설과 배포가 멈췄다

증상

동료가 슬랙으로 애플리케이션 배포가 오래 걸린다고 알려 왔다. 평소 몇 분이면 끝나는 배포가 한 시간째 새 파드 일부만 띄운 채 머물러 있었다. 새 파드의 절반쯤은 트래픽을 받고 있었고 나머지 절반은 Pending 상태였다.

Pending 파드 하나를 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의 거듭제곱으로 딱 떨어지는 숫자가 수상했다.

kubectl 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번 반복됐다.

팀은 처음에 IP 를 다 썼다는 것을 이해하지 못했다. 파드가 수천 개여도 65,536개 IP 에는 한참 못 미친다고 봤기 때문이다. 그래서 GKE 문서를 다시 찾아봤다.

증상 파드 PendingIP 주소 고갈노드 증설 실패

원인

감지

동료가 슬랙으로 배포가 오래 걸린다고 알려 왔다. 확인해 보니 평소 몇 분이면 끝나는 배포가 한 시간째 새 파드 일부만 띄운 채 멈춰 있었다.

조치

• 파드가 많이 뜨지 않을 노드 풀에서 노드당 최대 파드 수를 줄여 전체 IP 사용량을 약 30% 줄였다.
• 일부 노드 풀의 인스턴스 크기를 키워 노드당 더 많은 파드를 돌리게 했다.

후속 조치

• 상태 저장 애플리케이션, 캐시, 보안을 강화한 워크로드처럼 노드에 파드가 많이 뜨지 않는 노드 풀은 노드당 최대 파드 수를 낮춰 운영한다.
• 일부 노드 풀에 더 큰 인스턴스를 쓴다.

교훈

GKE 는 기본으로 노드마다 IP 256개를 할당한다. /16 처럼 큰 범위도 노드가 256개면 바닥난다. 노드당 최대 파드 수가 파드 IP 소비량을 정하므로, 노드 풀마다 실제로 띄울 파드 수에 맞춰야 한다. 큰 노드를 쓰면 IP 를 효율적으로 쓰고 자원 활용도도 높아지지만, 노드 하나가 죽을 때 더 많은 파드가 함께 내려간다.

출처

• https://deploy.live/blog/when-gke-ran-out-of-ip-addresses/ · blog · 보관본

참고 문서

• 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

관련 사례

• IL-0006 AWS VPC CNI 가 자원이 찬 노드에 IP 를 붙잡아 두어 us-east-1 서브넷 IP 가 바닥났고, WARM_IP_TARGET 을 바꾼 조치가 파드 시작 실패를 더 오래 끌었다Neon · 2025

  같은 원인 · 공통 클러스터 오토스케일러, VPC 서브넷 또는 파드 주소 범위

• IL-0102 배포와 워커 오토스케일링 폭주가 겹치자 크기를 고정해 둔 CoreDNS 가 메모리 한도를 넘겨 재시작된 뒤 회복하지 못했고, Buildkite 사이트 전체가 약 30분 멈췄다.Buildkite · 2026

  같은 원인 · 공통 노드 풀

• IL-0155 NYC1 의 일부 DOKS 클러스터에서 공유 CPU 노드 위의 CoreDNS 때문에 DNS 가 간헐적으로 실패하고 NodeNotReady 가 났다DigitalOcean · 2026

  같은 원인 · 공통 노드 풀

• IL-0100 노드가 파드의 CPU 요청에 비해 작아 CPU 가 포화되면서 PostHog 기능 플래그 서비스에 열흘 사이 장애가 세 번 났다.PostHog · 2025

  같은 원인 · 공통 노드 풀

• IL-0082 EKS 노드 교체 중 CoreDNS 파드 하나가 종료되자 남은 CoreDNS 파드가 늘어난 부하를 버티지 못해 DNS 조회가 느려지고 타임아웃이 났다.RebelMouse · 2025

  같은 원인 · 공통 노드 풀

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

AI 도구와 스크립트용

• 이 사례의 JSON: https://incidentlib-api.benchlet.com/cases/IL-0015
• 가장 비슷한 사례들: https://incidentlib-api.benchlet.com/cases/IL-0015/similar
• MCP 서버(Streamable HTTP, 키 없음): https://incidentlib-mcp.benchlet.com/mcp

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