<p>Consider a microservice <code>X</code> which is containerized and deployed in a kubernetes cluster. <code>X</code> communicates with a Payment Gateway <code>PG</code>. However, the payment gateway requires a static IP for services contacting it as it maintains a whitelist of IP addresses which are authorized to access the payment gateway. One way for <code>X</code> to contact <code>PG</code> is through a third party proxy server like <code>QuotaGuard</code> which will provide a static IP address to service <code>X</code> which can be whitelisted by the Payment Gateway. 
However, is there an inbuilt mechanism in kubernetes which can enable a service deployed in a kube-cluster to obtain a static IP address?</p>

adi
<p>there's no mechanism in Kubernetes for this yet.</p>

<p>other possible solutions:</p>

<ul>
<li><p>if nodes of the cluster are in a private network behind a NAT then just add your network's default gateway to the PG's whitelist.</p></li>
<li><p>if whitelist can accept a cidr apart from single IPs (like <code>86.34.0.0/24</code> for example) then add your cluster's network cidr to the whitelist</p></li>
</ul>

<p>If every node of the cluster has a public IP and you can't add a cidr to the whitelist then it gets more complicated:</p>

<ul>
<li><p>a naive way would be to add ever node's IP to the whitelist, but it doesn't scale above tiny clusters few just few nodes.</p></li>
<li><p>if you have access to administrating your network, then even though nodes have pubic IPs, you can setup a NAT for the network anyway that targets only packets with PG's IP as a destination.</p></li>
<li><p>if you don't have administrative access to the network, then another way is to allocate a machine with a static IP somewhere and make it act as a proxy using iptables NAT similarly like above again. This introduces a single point of failure though. In order to make it highly available, you could deploy it on a kubernetes cluster again with few (2-3) replicas (this can be the same cluster where X is running: see below). The replicas instead of using their node's IP to communicate with PG would share a VIP using <a href="https://www.keepalived.org/" rel="nofollow noreferrer">keepalived</a> that would be added to PG's whitelist. (you can have a look at <a href="https://www.reddit.com/r/kubernetes/comments/92xhum/easykeepalived_simple_load_balancing_for/" rel="nofollow noreferrer">easy-keepalived</a> and either try to use it directly or learn from it how it does things). This requires high privileges on the cluster: you need be able to grant to pods of your proxy <code>NET_ADMIN</code> and <code>NET_RAW</code> capabilities in order for them to be able to add iptables rules and setup a VIP.</p></li>
</ul>

<p><strong>update:</strong></p>

<p>While waiting for builds and deployments during last few days, I've polished my old VIP-iptables scripts that I used to use as a replacement for external load-balancers on bare-metal clusters, so now they can be used as well to provide egress VIP as described in the last point of my original answer. You can give them a try: <a href="https://github.com/morgwai/kevip" rel="nofollow noreferrer">https://github.com/morgwai/kevip</a></p>
