GKE 아웃바운드 트래픽용 정적 IP 주소: Cloud NAT 실용 가이드

Source: Dev.to

문제점

Google Kubernetes Engine(GKE)에서 실행 중인 애플리케이션이 IP 화이트리스트가 필요한 외부 데이터베이스에 연결해야 합니다. Kubernetes의 Pod는 일시적인 IP를 사용하므로 지속적으로 변합니다. 해결책은? 수동 정적 IP 할당이 가능한 Cloud NAT.

왜 필요할까?

현대 마이크로서비스 아키텍처에서 Kubernetes 애플리케이션은 종종 다음과 같은 접근이 필요합니다.

• 다른 GCP 프로젝트에 있는 관리형 데이터베이스
• 엄격한 방화벽 정책을 가진 서드파티 API
• 알려진 IP만 허용하는 레거시 서비스

특히 프라이빗 클러스터의 GKE 노드는 고정된 퍼블릭 IP가 없기 때문에 안정적인 화이트리스트를 유지하기 어렵습니다.

해결책: 수동 할당이 가능한 Cloud NAT

Cloud NAT는 클러스터 내부 사설 주소를 고정되고 예측 가능한 퍼블릭 IP 주소로 변환해 주는 게이트웨이 역할을 합니다.

단계별 구현

정적 IP 주소 예약

gcloud compute addresses create nat-static-ip \
  --region=us-central1

중요: IP는 GKE 클러스터와 동일한 리전에 있어야 합니다.

Cloud Router 생성

gcloud compute routers create nat-router \
  --network=my-vpc \
  --region=us-central1

수동 할당으로 Cloud NAT 구성

gcloud compute routers nats create nat-config \
  --router=nat-router \
  --region=us-central1 \
  --nat-external-ip-pool=nat-static-ip \
  --nat-all-subnet-ip-ranges

--nat-external-ip-pool 플래그는 첫 번째 단계에서 예약한 정적 IP를 지정합니다.

대상 서비스의 화이트리스트에 IP 추가

Cloud NAT 구성이 완료되면 클러스터에서 나가는 모든 트래픽은 해당 정적 IP를 사용합니다. 이 IP를 데이터베이스나 외부 서비스의 방화벽 화이트리스트에 추가하세요.

주요 장점

• 지속성: 클러스터가 재시작되거나 노드가 재생성되어도 IP가 변하지 않습니다.
• 보안: 노드가 퍼블릭 IP 없이 프라이빗 서브넷에 머물 수 있어 공격 표면이 감소합니다.
• 확장성: Cloud NAT는 관리형 서비스로 자동으로 확장되며 성능에 영향을 주지 않습니다.
• 애플리케이션 변경 없음: 인프라 수준 설정이므로 배포 파이프라인을 수정할 필요가 없습니다.

중요한 고려 사항

• 용량 관리: 수동 할당 모드에서는 필요한 IP/포트 수를 직접 계산해야 합니다. 용량이 부족하면 OUT_OF_RESOURCES 오류가 발생할 수 있습니다.
• 모니터링: NAT 포트 사용량에 대한 알림을 설정해 문제 발생 시 신속히 대응하세요.
• 대안: 매우 맞춤형 NAT 로직이나 복잡한 방화벽 요구사항이 있는 경우, 직접 NAT 인스턴스를 운영하는 것이 적합할 수 있지만 운영 부담이 늘어납니다.

언제 이 솔루션을 사용해야 할까

적합한 경우

• ✅ IP 화이트리스트가 필요한 서비스와 통신해야 할 때
• ✅ 프라이빗 GKE 클러스터를 운영 중일 때
• ✅ 확장 가능하고 관리형 솔루션을 원할 때
• ✅ 아웃바운드 트래픽에 대한 컴플라이언스 및 중앙 감사가 필요할 때

부적합한 경우

• ❌ 매우 맞춤형 NAT 로직이 필요할 때
• ❌ 관리형 서비스가 제공하는 범위를 넘어선 세밀한 제어가 필요할 때

결론

수동 IP 할당이 가능한 Cloud NAT는 이와 같은 일반적인 사용 사례에 대한 GCP 표준 솔루션입니다. 신뢰성이 높고 확장 가능하며 비교적 간단하게 구성할 수 있어, 프라이빗 네트워크 내에서 리소스를 안전하게 보호하면서 외부와의 연결을 제어할 수 있습니다.

---