요약

  • Spiro Stathakis는 isp6 주문 플랫폼의 EKS를 ipFamily: ipv6로 구성하면서, 남은 호환성 수요를 위해 IPv4 /28 서브넷을 마련했다.
  • 노드 기본 인터페이스와 이중 스택 서비스 엔드포인트의 인터페이스가 그 주소를 소모했다. 팀은 공용 서브넷을 /27, 사설 서브넷을 /26으로 키웠다.

IPv6를 먼저 쓰겠다는 의지를 가장 작은 IPv4 서브넷에 담을 수 있을까. Spiro Stathakis는 실제로 그렇게 했다. 그가 RIPE Labs에 쓴 isp6 운영 기록에 따르면 주문 관리 플랫폼의 Pod는 회사가 보유한 IPv6 할당에서 주소를 받았다. IPv4는 오래된 연결을 위한 /28만 남겼다. 하지만 애플리케이션의 주소보다 그 애플리케이션을 받치는 인터페이스의 주소가 먼저 문제가 됐다.

/28에는 전체 16개 주소가 있다. AWS는 IPv4 서브넷마다 처음 네 개와 마지막 한 개를 예약한다. 실제로 쓸 수 있는 것은 11개다. Stathakis는 노드의 기본 네트워크 인터페이스와 이중 스택 서비스 엔드포인트의 인터페이스가 이 여유를 소진했다고 설명한다. 결국 공용 서브넷은 /27, 사설 서브넷은 /26으로 늘렸다. 그의 글에는 서브넷별 ENI 수를 기록한 날짜 있는 목록이 없으므로 현재 잔여 주소까지 계산할 수는 없다.

EKS 공식 문서가 말하는 IPv6 모드의 범위는 분명하다. Pod와 서비스에는 IPv6가 배정된다. IPv4만 지원하는 목적지로 나갈 때 Pod는 노드 내부에서 쓰는 IPv4도 갖고, 네트워크 구성 요소는 송신 주소를 노드의 기본 IPv4로 바꾼다. 이 호환 경로 덕분에 기존 연결은 작동하지만, 성공한 요청만 보고 IPv4 의존성이 사라졌다고 판단할 수 없다. 클러스터의 IP 주소 체계는 생성할 때 선택하며 나중에 바꾸지 못한다.

isp6는 여전히 IPv4가 필요한 목적지를 위해 NAT 게이트웨이 하나를 남겼다. 일부 이중 스택 AWS 엔드포인트에서는 443번 포트의 IPv6만 허용했다. 클라이언트가 A 레코드를 골랐다면 몰래 IPv4로 돌아가는 대신 연결이 실패한다. NAT 흐름 로그는 아직 우회로를 쓰는 의존성을 찾는 데 쓰였다. 현재 규모를 보려면 날짜가 있는 서브넷·인터페이스 목록과 그 로그의 표본이 필요하다.

이 사례의 핵심은 IPv6 Pod가 실패했다는 이야기가 아니다. Pod는 돌아갔다. 그 곁의 노드와 엔드포인트가 IPv4 주소 장부를 계속 채웠다. /28은 방향 선언이었고, 필요한 인터페이스 수가 실제 용량을 결정했다.