Give GKE Workloads a Stable Outbound IP Without NAT Gateways or Node Management

Point your GKE app at a QuotaGuard proxy, set one environment variable, and every outbound request leaves from the same fixed IP every time.

GKE clusters reassign node IPs on resize, upgrade, and node pool changes. That breaks any firewall allowlist that depends on the IP staying constant. The Kubernetes Users Group thread on this problem is years old and the answers are still messy: Cloud NAT, node static IPs, network tags, custom egress routers. Every option adds infrastructure you have to maintain. QuotaGuard cuts that down to one environment variable and 2 minutes of configuration.

GKE Workloads Need a Proxy to Maintain a Stable Egress IP

Google Kubernetes Engine assigns IPs from a pool. When you resize a node pool, add a new node group, or let the cluster autoscaler do its job, node IPs change. Any external API or database that allowlists your IP by address stops accepting your requests. The platform is working as designed. The IP contract you thought you had was never real.

Cloud NAT solves one direction of the problem. It gives your nodes a stable egress IP through a NAT gateway. But it requires provisioning a Cloud Router and a Cloud NAT config, and it applies to all outbound traffic from the VPC, not just the workloads that need allowlisting. You're changing network architecture to solve a problem that's really about one or two API integrations.

Node static IPs are even messier. You pin specific nodes to external static IPs, then you have to ensure those specific nodes are the ones running the pods that make the API calls. That means node affinity rules, taints, and careful scheduling logic. It breaks silently when the cluster changes.

A Proxy-Based Egress IP Survives Every Cluster Change

QuotaGuard runs outside your GKE cluster entirely. Your pods send outbound requests through a proxy URL. Those requests exit QuotaGuard's infrastructure from a fixed IP address that never changes regardless of what happens to your cluster. Resize, upgrade, add node pools, enable autoscaling. The egress IP stays the same.

This is the architectural difference that matters: the stable IP lives at the proxy layer, not the infrastructure layer. You're not managing GCP networking to make IP addresses behave. You're routing specific outbound calls through a service whose entire job is to make IPs stable.

QuotaGuard tip: route only the API calls that need allowlisting through the proxy, not all outbound traffic. It keeps latency low for general traffic and makes the proxy connection easier to debug if something goes wrong.

GKE Pods Get a Fixed Egress IP in 2 Minutes

Start with a QuotaGuard account. You'll get a QUOTAGUARDSTATIC_URL value that looks like this:

http://username:password@proxy.quotaguard.com:9293

Add it to your Kubernetes deployment as an environment variable:

apiVersion: apps/v1
  kind: Deployment
  metadata:
    name: your-app
  spec:
    template:
      spec:
        containers:
          - name: your-app
            image: your-image
            env:
              - name: QUOTAGUARDSTATIC_URL
                valueFrom:
                  secretKeyRef:
                    name: quotaguard-secret
                    key: url

Store the proxy URL as a Kubernetes secret:

kubectl create secret generic quotaguard-secret \
    --from-literal=url='http://username:password@proxy.quotaguard.com:9293'

Then configure your HTTP client to use the proxy. Here are the three most common patterns in GKE workloads:

Python (requests):

import os
  import requests

  proxy_url = os.environ.get("QUOTAGUARDSTATIC_URL")
  proxies = {
      "http": proxy_url,
      "https": proxy_url,
  }

  response = requests.get("https://api.example.com/endpoint", proxies=proxies)

Node.js (http-proxy-agent):

const { HttpProxyAgent } = require("http-proxy-agent");
  const https = require("https");

  const agent = new HttpProxyAgent(process.env.QUOTAGUARDSTATIC_URL);

  https.get("https://api.example.com/endpoint", { agent }, (res) => {
    // handle response
  });

Go (net/http):

package main

  import (
      "net/http"
      "net/url"
      "os"
  )

  func newProxiedClient() *http.Client {
      proxyURL, _ := url.Parse(os.Getenv("QUOTAGUARDSTATIC_URL"))
      transport := &http.Transport{Proxy: http.ProxyURL(proxyURL)}
      return &http.Client{Transport: transport}
  }
  

That's the setup. Your pods now make outbound API calls through a fixed IP. The IP appears on the QuotaGuard dashboard so you can give it to the API provider to allowlist.

Sensitive Data Workloads Belong on QuotaGuard Shield

The setup above uses QuotaGuard Static. It's the right choice for most GKE workloads. Standard proxy model, handles HTTP and HTTPS, works with every major HTTP client library.

If your pods handle healthcare records, financial data, payment information, or any data covered by HIPAA or PCI-DSS, use QuotaGuard Shield instead. Shield uses SSL passthrough. The TLS connection runs end-to-end between your pod and the destination API. QuotaGuard routes the packets but never decrypts the traffic. That's what keeps you in compliance: QuotaGuard is never a party to the unencrypted data.

The setup is identical. Replace QUOTAGUARDSTATIC_URL with QUOTAGUARDSHIELD_URL and use port 9294:

https://username:password@us-east-shield-01.quotaguard.com:9294

Pick the region closest to the destination API. QuotaGuard runs on 10 AWS regions: US-East, US-West, CA-Central, EU-West, EU-Central, AP-Northeast (Tokyo), AP-Southeast (Singapore), AP-Southeast-2 (Sydney), AP-South (Mumbai), and SA-East (São Paulo).

QuotaGuard Static and Shield Pricing Starts at $19/Month

QuotaGuard Static direct plans:

• Starter: $19/month
• Production: $49/month
• Business: $89/month
• Enterprise: $219/month (dedicated IPs)

QuotaGuard Shield direct plans:

• Starter: $29/month
• Production: $59/month
• Business: $109/month
• Enterprise: $259/month (dedicated IPs)

All plans include a 3-day trial. Enterprise trials run 7 days. Credit card required. Dedicated IPs are Enterprise-only on both products.

Compare that to Cloud NAT: a Cloud Router plus a reserved static IP plus bandwidth costs. For a workload that only needs a stable IP for a handful of API calls, the managed proxy is cheaper and requires no ongoing infrastructure work.

See full pricing and start a trial →

What QuotaGuard Doesn't Cover in GKE

QuotaGuard handles outbound HTTP and HTTPS traffic from your application code. It doesn't replace Cloud NAT for workloads that need all pod traffic to exit from a fixed IP at the network level. If you have non-HTTP traffic, raw TCP connections, or you need egress IP control outside of application code (for example, system-level calls), you'll need a network-layer solution in addition to or instead of QuotaGuard.

QuotaGuard also doesn't manage inbound traffic to your GKE cluster. For inbound static IPs, use a GKE load balancer with a reserved external IP.

For the most common case (an app pod making HTTP/HTTPS calls to an external API that requires IP allowlisting), QuotaGuard is the right tool and the fastest setup. No GCP network changes. No node scheduling constraints. One environment variable, 2 minutes, done.

Get started with QuotaGuard Static →