그래프
사례3건
3건 중 1~3번째
IL-0006AWS VPC CNI 가 자원이 찬 노드에 IP 를 붙잡아 두어 us-east-1 서브넷 IP 가 바닥났고, WARM_IP_TARGET 을 바꾼 조치가 파드 시작 실패를 더 오래 끌었다Neon2025- 증상
2025년 5월 16일, Neon 의 AWS us-east-1 클러스터에서 새 파드가 스케줄링은 되지만 IP 할당 오류를 내며 시작하지 못했다. 새 컴퓨트 파드를 시작할 수 없어 유휴 데이터베이스를 깨울 수도 없었다.
- 촉발
5월 16일 유휴 컴퓨트를 종료하는 Neon 컨트롤 플레인의 주기 작업이 실패했다. 종료는 멈췄는데 생성은 계속되어 활성 컴퓨트가 몇 분 만에 약 8천 개로 늘었다. 5월 19일에는 후속 조치로 WARM_IP_TARGET=1 을 다시 배포한 것이 계기가 되어 같은 장애가 다시 났다.
- 원인
- 구성 요소
- 기여 요인
- 감지
노드가 추가되면서 새 파드가 스케줄링은 되지만 시작하지 못하고 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만 컴퓨트를 넘지 않는다는 가정에 맞춰 잡혀 있었다. 서비스가 예상보다 빨리 커지면서 이 가정이 맞지 않게 됐다.
- 증상
어느 저녁 일부 DaemonSet 이 실패하고 있다는 호출이 왔다. 당직자가 서버에 들어가 파드 상태를 보니 다음 오류가 찍혀 있었다: name=“aws-cni” failed (add): add cmd: failed to assign an IP address to container
- 촉발
첫 호출의 계기는 원문에 나오지 않는다. 호출은 6월, kube-aws 기반 SCHIP 에서 EKS 기반 클러스터로 옮기던 중에 왔다. 원문은 클러스터의 IP 가 바닥나는 경우로, 잡이 폭주하거나 실패하면서도 회수될 때까지 IP 를 붙잡고 있어 파드가 갑자기 늘어나는 경우를 든다.
- 원인
- 구성 요소
- 기여 요인
- 감지
어느 저녁 일부 DaemonSet 이 실패한다는 호출이 왔다. 당직자가 서버에 들어가 파드 상태를 확인하다 aws-cni 의 IP 할당 실패 오류를 보았다. 팀은 그전부터 IP 사용량을 감시하고 있었다.
- 조치
- 8월 말부터 작은 클러스터에 Secondary CIDR 를 쓰는 VPC-CNI 커스텀 네트워킹을 배포했다.
- 9월에 사용 가능한 IP 가 너무 적어지자 EKS 이전을 잠시 멈췄다.
- 커스텀 네트워킹을 나머지 클러스터 전체에 배포했다.
- Karpenter 배포에 --reserved-enis 파라미터를 더했다.
- 후속 조치
- 커스텀 네트워킹을 나머지 클러스터 전체에 배포해 IP 여유를 되찾고 EKS 이전을 끝냈다.
- Karpenter 배포에 --reserved-enis 파라미터를 더해 커스텀 네트워킹이 쓰는 첫 번째 ENI 를 빼고 노드당 파드 수를 계산하게 했다.
- 교훈
플랫폼 팀이나 클러스터 운영자가 용량 계획에 시간을 들이지 않으면, VPC-CNI 는 큰 규모의 운영 환경에 바로 쓸 수 있는 도구가 아니다. 선택지마다 장단점이 있다. 지금 큰 클러스터를 새로 띄운다면 더 싸고 앞으로도 오래 쓸 수 있는 IPv6 를 쓸 수 있는지 먼저 확인할 만하다. 작은 클러스터에서 되던 것이 규모를 키워도 된다고 가정하면 안 된다. 예측과 용량 계획을 잘하면 이 요구는 감당할 수 있다. 하지만 폭주하는 잡이나, 실패하면서도 회수될 때까지 IP 를 붙잡는 잡을 여럿 띄우는 잘못된 설정 때문에 파드가 갑자기 늘 수 있다.
- 증상
동료가 슬랙으로 애플리케이션 배포가 오래 걸린다고 알려 왔다. 평소 몇 분이면 끝나는 배포가 한 시간째 새 파드 일부만 띄운 채 머물러 있었다. 새 파드의 절반쯤은 트래픽을 받고 있었고 나머지 절반은 Pending 상태였다.
- 촉발
클러스터의 노드 수가 256개에 이르렀다. GKE 는 노드당 최대 파드 수를 기본 110 으로 두고, 그 두 배 이상을 담을 수 있는 서브넷 마스크를 노드마다 미리 할당한다. 노드 하나가 IP 256개를 차지하므로 /16 보조 범위의 65,536개 주소가 노드 256개에서 바닥났다.
- 원인
- 구성 요소
- 기여 요인
- 감지
동료가 슬랙으로 배포가 오래 걸린다고 알려 왔다. 확인해 보니 평소 몇 분이면 끝나는 배포가 한 시간째 새 파드 일부만 띄운 채 멈춰 있었다.
- 조치
- 파드가 많이 뜨지 않을 노드 풀에서 노드당 최대 파드 수를 줄여 전체 IP 사용량을 약 30% 줄였다.
- 일부 노드 풀의 인스턴스 크기를 키워 노드당 더 많은 파드를 돌리게 했다.
- 후속 조치
- 상태 저장 애플리케이션, 캐시, 보안을 강화한 워크로드처럼 노드에 파드가 많이 뜨지 않는 노드 풀은 노드당 최대 파드 수를 낮춰 운영한다.
- 일부 노드 풀에 더 큰 인스턴스를 쓴다.
- 교훈
GKE 는 기본으로 노드마다 IP 256개를 할당한다. /16 처럼 큰 범위도 노드가 256개면 바닥난다. 노드당 최대 파드 수가 파드 IP 소비량을 정하므로, 노드 풀마다 실제로 띄울 파드 수에 맞춰야 한다. 큰 노드를 쓰면 IP 를 효율적으로 쓰고 자원 활용도도 높아지지만, 노드 하나가 죽을 때 더 많은 파드가 함께 내려간다.
이 3건에서 가장 많이 나오는 구성 요소: VPC 서브넷 또는 파드 주소 범위, 클러스터 오토스케일러. kubegap 은 Claude Code 나 Codex 에서 쿠버네티스 클러스터를 읽기만 하며 이런 틈을 점검합니다. 점검 항목의 근거는 이 라이브러리와 같은 공개 보고서입니다.