Static IP Addresses for GKE Outbound Traffic: A Practical Guide to Cloud NAT

Source: Dev.to

The problem

Your application running on Google Kubernetes Engine (GKE) needs to connect to an external database that requires IP whitelisting. Pods in Kubernetes have ephemeral IPs that change constantly. The solution? Cloud NAT with manual static IP assignment.

Why is this necessary?

In modern microservice architectures, Kubernetes applications often need access to:

• Managed databases in other GCP projects
• Third‑party APIs with strict firewall policies
• Legacy services that only allow access from known IPs

GKE nodes (especially in private clusters) don’t have fixed public IPs, making it impossible to maintain a stable whitelist.

The solution: Cloud NAT with manual assignment

Cloud NAT acts as a gateway that translates your cluster’s internal private addresses to a fixed, predictable public IP address.

Step‑by‑step implementation

Reserve a static IP address

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

Important: The IP must be in the same region as your GKE cluster.

Create a Cloud Router

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

Configure Cloud NAT with manual assignment

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

The --nat-external-ip-pool flag specifies the static IP reserved in the first step.

Add the IP to your destination’s whitelist

Once Cloud NAT is configured, all outbound traffic from your cluster will use the static IP. Add this IP to the firewall whitelist of your database or external service.

Key benefits

• Persistence: The IP won’t change even if the cluster restarts or nodes are recreated.
• Security: Nodes can remain in private subnets without public IPs, reducing attack surface.
• Scalability: Cloud NAT is a managed service that scales automatically without impacting performance.
• No application changes: Infrastructure‑level configuration; deployments remain untouched.

Important considerations

• Capacity management: In manual assignment mode you must calculate the required number of IPs/ports. Insufficient capacity can lead to OUT_OF_RESOURCES errors.
• Monitoring: Set up alerts for NAT port utilization to detect issues before they affect production.
• Alternatives: For highly custom NAT logic or complex firewall requirements, a manual NAT instance might be appropriate, though it adds operational overhead.

When to use this solution

Good fit

• ✅ Need to communicate with services requiring IP whitelisting
• ✅ Running private GKE clusters
• ✅ Want a scalable, managed solution
• ✅ Require compliance and centralized auditing of outbound traffic

Not a fit

• ❌ Extremely custom NAT logic
• ❌ Need granular control beyond what the managed service offers

Conclusion

Cloud NAT with manual IP assignment is GCP’s standard solution for this common use case. It’s reliable, scalable, and relatively simple to configure, allowing you to keep resources secure in private networks while maintaining controlled connectivity to the outside world.

---