What is an egress gateway, and how do Pods get a fixed outbound IP?

A Kubernetes egress gateway is a node or proxy that outbound Pod traffic passes through before it leaves the cluster, where its source address is rewritten to a fixed IP address. External services that allowlist source IPs, such as payment APIs, partner networks or managed databases, then see one predictable address instead of the changing IPs of every worker node. The common options are a cloud NAT gateway, a CNI egress gateway and a service mesh egress gateway, and they differ in scope, availability and what they control.

Why Pod traffic has no stable source IP

Pod IP addresses are usually private and routable only inside the cluster. When a Pod connects to an address outside the cluster, most CNI plugins masquerade the packet: they replace the Pod IP with the IP of the node that runs the Pod. This is source NAT, and the external service sees the node IP.

That address is not stable. Pods move between nodes on every rollout, and nodes come and go with autoscaling, spot interruptions and upgrades. A firewall rule written for today’s node IPs breaks the next time the cluster scales. Allowlisting every node, or a provider’s whole IP range, defeats the purpose of an allowlist.

Ways to get a fixed outbound IP

Cloud NAT gateway

A managed NAT service, such as an AWS NAT gateway or Google Cloud NAT, translates outbound traffic from private subnets to reserved public IPs. It is the simplest option when the whole cluster runs in one provider network and every workload may share the same address. It knows nothing about Pods, so it cannot give one team’s workloads a different IP from another team’s, and it does not cover nodes at another provider or in your own data center.

CNI egress gateway

A CNI egress gateway works inside Kubernetes. You write a policy that selects Pods by label or namespace and lists destination CIDRs. The CNI plugin routes matching traffic to a designated gateway node, which source-NATs it to an egress IP configured on that node. Other traffic keeps its normal path.

Cilium implements this with the CiliumEgressGatewayPolicy resource, and Antrea with its Egress resource. Tigera documents egress gateways for its commercial Calico Enterprise and Calico Cloud products. Cilium requires BPF masquerading and its kube-proxy replacement for the feature, so check those settings before you plan on it.

Service mesh egress gateway

An Istio egress gateway is a dedicated proxy deployment that mesh traffic to external hosts passes through. Its purpose is control: apply routing rules, originate TLS, record telemetry and force traffic through nodes that the security team monitors. It does not provide a fixed IP by itself, because traffic leaves with the address of whichever node runs the gateway Pod. Istio’s documentation also states that the mesh cannot guarantee all traffic uses the gateway and recommends network policies or firewalls to block other paths. For more on what a mesh adds, see what a service mesh is and when you need one.

High availability

The gateway node is a single point of failure unless the implementation fails over. Check the behavior before you rely on it:

• Open-source Cilium assigns each source Pod to one gateway node. If several nodes match a single-gateway policy, Cilium picks the first one in lexical order by name. If no node matches, it drops the traffic. Changing the gateway node breaks existing connections. Isovalent, the company behind Cilium, sells an enterprise edition with health-checked gateway groups.
• Antrea fails over automatically when the egress IP comes from an ExternalIPPool: if the node that holds the IP fails, another eligible node takes it over.
• The IP has to move with the role. On cloud providers, that usually means a floating or elastic IP that is reassigned to the new gateway node.

Run gateway nodes in a dedicated group with stable names, and size them like the NAT layer they are.

Common mistakes

Capturing cluster traffic. A policy with the destination 0.0.0.0/0 also catches traffic to the Kubernetes API server, which then becomes unreachable from the selected Pods. Exclude the API server endpoint, and any other internal ranges, with excludedCIDRs or the equivalent field.

Ignoring the startup window. Cilium documents that a new Pod’s traffic can briefly leave the cluster with the node IP before the policy applies. A destination that rejects unknown IPs will drop those first connections, so build retries into the client.

Treating a fixed IP as access control. An egress IP shows where traffic came from, not whether it should go there. Pair the gateway with egress network policies that allow only the destinations each workload needs. Domain-based rules, such as Cilium’s toFQDNs, limit data exfiltration even when the destination’s IP addresses change.

Egress in hybrid and multi-cloud clusters

When one cluster has nodes in several clouds and on-premises, provider NAT gateways give each location a different IP, so every partner has to allowlist several addresses. A CNI egress gateway keeps one address: Pods in any location route through the gateway node over the cluster network. The cost is a detour. Traffic from a Pod in one cloud crosses to the gateway’s location before it leaves, which adds latency and data transfer that may be billed as cloud egress fees.

The same pattern works in the other direction. A gateway node inside your data center lets cloud Pods reach systems that accept connections only from internal addresses. For how nodes in different providers share one network in the first place, see how nodes in different clouds join one cluster network.

Egress gateways on Cloudfleet

Cloudfleet Kubernetes Engine (CFKE) runs Cilium with the egress gateway feature enabled, so a CiliumEgressGatewayPolicy can route selected Pods through any labeled node, including a self-managed node in your own data center. The egress gateway guide covers the policy fields, verification and the API server exclusion.