사례2건

2건 중 1~2번째

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

   Neon2025

   증상

   2025년 5월 16일, Neon 의 AWS us-east-1 클러스터에서 새 파드가 스케줄링은 되지만 IP 할당 오류를 내며 시작하지 못했다. 새 컴퓨트 파드를 시작할 수 없어 유휴 데이터베이스를 깨울 수도 없었다.

   IP 주소 고갈파드 Pending

   촉발

   5월 16일 유휴 컴퓨트를 종료하는 Neon 컨트롤 플레인의 주기 작업이 실패했다. 종료는 멈췄는데 생성은 계속되어 활성 컴퓨트가 몇 분 만에 약 8천 개로 늘었다. 5월 19일에는 후속 조치로 WARM_IP_TARGET=1 을 다시 배포한 것이 계기가 되어 같은 장애가 다시 났다.

   원인

   용량 한계

   구성 요소

   AWS VPC CNIVPC 서브넷 또는 파드 주소 범위클러스터 오토스케일러

   기여 요인

   기본 설정 방치용량 계획 부재미검증 가정수동 조치 악화롤백 무효재시도 폭주

   감지

   노드가 추가되면서 새 파드가 스케줄링은 되지만 시작하지 못하고 IP 할당 오류를 내는 것이 보였다. 5월 19일에는 WARM_IP_TARGET=1 배포 직후 IP 배정 실패와 파드 시작 성공률 하락이 바로 나타났다.

   조치

   • 5월 16일 노드에 묶인 IP 를 풀려고 WARM_IP_TARGET=1 을 설정했다.
   • 컨트롤 플레인의 실패하던 주기 작업을 안정시켜 유휴 컴퓨트 약 7천 개를 종료했다.
   • aws-node DaemonSet 을 재시작해 ipamd 를 다시 초기화했고, 재시작할 때마다 잠시 나아졌다.
   • WARM_IP_TARGET, MINIMUM_IP_TARGET, WARM_ENI_TARGET 을 모두 0 으로 바꿔 파드 시작 성공률을 정상으로 되돌렸다.
   • 5월 19일 WARM_IP_TARGET=1 을 다시 배포했다가 같은 증상이 나오자 0 으로 되돌렸다.
   • 미리 만들어 두는 컴퓨트 풀을 늘려 약 10% 의 파드 시작 실패를 메우고 사용자 영향을 줄였다.

   후속 조치

   • ipamd 의 동작을 개선하는 PR 을 AWS CNI 에 올렸다.
   • 서브넷에서 IP 약 100개가 왜 할당되지 않고 남았는지 AWS Support 와 확인한다.
   • 수평 확장을 지원하도록 아키텍처를 바꾼다.

   교훈

   AWS CNI 기본 설정에서는 노드마다 적어도 ENI 한두 개 분량의 IP 가 더 잡히고, IP 는 ENI 가 통째로 비어야만 반납된다. 그래서 파드에 배정된 IP 수만 보고 서브넷 여유를 판단하면 안 된다. 이번에는 IP 의 71% 만 파드에 배정된 상태에서 서브넷이 바닥났다. WARM_IP_TARGET 은 지정하지 않을 때, 0 일 때, 1 일 때 동작이 서로 크게 다르다. cooldown 중인 IP 도 여유 IP 로 세기 때문에 WARM_IP_TARGET=1 은 파드가 지워질 때마다 그 노드의 파드 시작을 30초 동안 막을 수 있다. 문서를 잘못 읽고 바꾼 설정도, 원래대로 돌린 설정도 예상과 다르게 동작했고, 되돌리는 것만으로는 망가진 상태가 회복되지 않았다. 서브넷 크기는 부하 시험에서 정한 상한인 1만 컴퓨트를 넘지 않는다는 가정에 맞춰 잡혀 있었다. 서비스가 예상보다 빨리 커지면서 이 가정이 맞지 않게 됐다.

   사례 보기
2. IL-0015 GKE 가 노드마다 IP 256개를 미리 잡아 /16 파드 주소 범위가 바닥나고 노드 증설과 배포가 멈췄다

   loveholidays2020

   증상

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

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

   촉발

   클러스터의 노드 수가 256개에 이르렀다. GKE 는 노드당 최대 파드 수를 기본 110 으로 두고, 그 두 배 이상을 담을 수 있는 서브넷 마스크를 노드마다 미리 할당한다. 노드 하나가 IP 256개를 차지하므로 /16 보조 범위의 65,536개 주소가 노드 256개에서 바닥났다.

   원인

   용량 한계

   구성 요소

   VPC 서브넷 또는 파드 주소 범위클러스터 오토스케일러노드 풀

   기여 요인

   기본 설정 방치한계 미인지

   감지

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

   조치

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

   후속 조치

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

   교훈

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

   사례 보기

원인별1