Back to Blogs

Why We Need Static IPs for Pods (and How to Solve It)

July 5, 2026 Kubernetes, Networking, DevOps

Kubernetes was designed around the idea that pods are disposable — they can be killed, rescheduled, and recreated at any time, and each time that happens, they get a brand-new IP address. This is great for flexibility and resilience, but it creates a real headache the moment something outside your cluster needs a fixed address to talk to.

The Problem: Pods Are Ephemeral by Design

Every pod in Kubernetes gets an IP address from the cluster's internal network when it starts. But that IP is not permanent:

  • If a pod crashes and gets rescheduled, it gets a new IP.
  • If you scale a deployment up or down, pods are created and destroyed, each with a different IP.
  • If a node fails and pods move to another node, the IPs change again.

For internal cluster communication, this isn't a problem — Kubernetes Services already handle this by giving a stable DNS name and virtual IP that routes to whichever pods are currently healthy. But certain real-world situations need something more static:

Common Scenarios Where a Static IP Is Needed

  • Third-party firewall whitelisting — a partner API, bank, or payment gateway only allows requests from a specific whitelisted IP address.
  • Legacy systems — an on-premise database or internal tool that's configured to only trust a fixed IP.
  • Compliance requirements — some regulations require traceable, fixed source IPs for outbound traffic.
  • License servers — some software licenses are bound to a specific IP address.
  • VPN or private network peering — where the other side expects a fixed peer IP.

If your pod's outbound traffic has a different IP every time it restarts, none of these integrations work reliably.

Why You Can't Just Assign a Static IP to a Pod Directly

Kubernetes doesn't support statically assigning an IP directly to a pod in most standard setups, because:

  • Pod IPs come from the cluster's internal CNI (Container Network Interface) IP pool, which is dynamically managed.
  • Pods are meant to be replaceable — hardcoding an IP to a specific pod would break the self-healing model that makes Kubernetes useful in the first place.
  • Even if you pinned an IP to a pod, that IP would only be valid inside the cluster network, not usable for external traffic without additional networking.

So instead of fighting the pod-level model, the solution is to introduce a stable layer between your pod and the outside world.

Solutions

1. Static Egress IP via NAT Gateway (Cloud Environments)

On cloud providers like AWS, GCP, or Azure, the cleanest solution is routing your cluster's outbound traffic through a NAT Gateway (or Cloud NAT) that has a fixed public IP. All outbound traffic from your pods — regardless of which node or pod it originates from — appears to external services as coming from that one static IP.

Best for: whitelisting your cluster's outbound traffic with third-party APIs or partners.

2. LoadBalancer Service with a Reserved Static IP

For inbound traffic (external clients reaching your app), most cloud providers let you reserve a static public IP and assign it to a Kubernetes LoadBalancer Service. Even as pods behind it are recreated, the external IP stays the same.

apiVersion: v1
kind: Service
metadata:
  name: my-app
spec:
  type: LoadBalancer
  loadBalancerIP: <reserved-static-ip>
  selector:
    app: my-app
  ports:
    - port: 80
      targetPort: 8080

Best for: exposing an application to the internet or external clients with a fixed inbound address.

3. MetalLB (For On-Premise / Bare-Metal Clusters)

Cloud LoadBalancer IPs aren't available on bare-metal or on-prem clusters. MetalLB fills that gap by letting you assign static IPs from a pre-configured pool to Services, giving on-prem Kubernetes the same static-IP experience cloud users get natively.

Best for: self-hosted or on-premise Kubernetes deployments.

4. StatefulSets for Stable Network Identity

If what you actually need is a predictable, stable identity (not necessarily a fixed IP, but a consistent, addressable hostname) — for databases or clustered apps like Kafka, Elasticsearch, or Cassandra — StatefulSets combined with a headless Service give each pod a stable DNS name (e.g., pod-0.my-service) that persists across restarts, even though the underlying IP can still change.

Best for: internal service-to-service communication where hostname stability matters more than raw IP stability.

5. Service Mesh Egress Gateway

Tools like Istio let you route all outbound traffic through a dedicated egress gateway pod (or set of pods) with a fixed, controlled IP. This adds observability and policy control on top of the static IP itself.

Best for: organizations that need fine-grained control, auditing, or policy enforcement on outbound traffic, not just a fixed IP.

Choosing the Right Solution

| Need | Recommended Solution | |---|---| | External API needs to whitelist your outbound traffic | NAT Gateway / Cloud NAT | | External clients need a stable inbound address | LoadBalancer with reserved static IP | | On-premise cluster, need static IP for a Service | MetalLB | | Stable identity for databases/stateful apps | StatefulSet + headless Service | | Fine-grained control over egress traffic | Service mesh egress gateway |

The Takeaway

Pods being ephemeral isn't a flaw — it's the whole point of Kubernetes' self-healing, scalable design. The need for a "static IP" almost always comes from something outside the cluster that wasn't built with dynamic infrastructure in mind. The right fix isn't to fight Kubernetes' pod model, but to introduce a stable networking layer — a NAT gateway, a reserved LoadBalancer IP, or MetalLB — that absorbs that instability before it reaches whatever legacy system, partner API, or compliance rule actually needs the fixed address.