<p>We have been trying to configure a K8 cluster that is deployed into Google Cloud Platform using the most economical set-up possible. Our solution will be deployed into different regional data centers due to regulatory and Geo-political constraints surrounding our commercial billing as a service platform called Bill Rush.</p>

<p>Given our regional requirements means that we want to make use of the following infrastructure settings:</p>

<ol>
<li>Committed Use virtual machine resource allocations. Our K8 nodes will be allocated to predefined fixed term compute infrastructure quotas when provisioned.</li>
<li>Standard Network Tier - as local customers are only one or two hops away from a GCP regional/zone data center location we are happy to use external network providers to carry traffic across to the closest google network egress point into the data center. Premium network routing is not required. </li>
<li>Regional environments and deployments. We only require a system to be running regionally across one or two zones for redundancy. We do not require fancier global redundancy set-ups.</li>
</ol>

<p>Using these 3 options would give us the cheapest set-up for each of our regional application environments. </p>

<p>Also, all regional instances need bookmarkable URL's so that users can easily find our application environments. As such we need to seed each environment with DNS and external IPs. These need to be referenced in our YAML ingress files when we apply them to our K8 cluster environments.</p>

<p><strong>The Issue:</strong></p>

<p>We would like to use conventional Kubernetes best practice and define an ingress. This will expose an external entry point into the cluster that is provisioned and managed by a GKE specific Google Cloud Controller.</p>

<p>In the case of a GKE ingress, only a single set-up is supported: A Global HTTP(S) Load Balancer which includes [proxy, forwarding rule, external IPs, back ends, certificates]. When using a regional external IP the LB set-up fails. </p>

<p><strong>Questions:</strong></p>

<ol>
<li>Why are we not allowed to use regional external IPs in an ingress YAML declaration?</li>
<li>What alternative GKE cluster configurations will support a standard network tier compliant external IP address</li>
<li>Will this impact our ability to use Anthos for development and UAT clusters deployed on-premise.</li>
</ol>

<p>Thanks in advance.</p>

Shaun Forgie
<p>1) Why are we not allowed to use regional external IPs in an ingress YAML declaration?</p>

<p>As per GCP documentation on <a href="https://cloud.google.com/compute/docs/ip-addresses#reservedaddress" rel="nofollow noreferrer">Static external IP addresses</a>, "Static external IP addresses can be either a regional or a global resource. A regional static IP address allows resources of that region or resources of zones within that region to use the IP address. In this case, VM instances and regional forwarding rules can use a regional static IP address.</p>

<p>Global static external IP addresses are available only to global forwarding rules, used for global load balancing. You can't assign a global IP address to a regional or zonal resource."</p>

<p>2) What alternative GKE cluster configurations will support a standard network tier compliant external IP address?</p>

<p>You might have to consider some regional ingress or third-party nginx ingress and use a regional ip address there, you would have to create a new regional external IP address using the <a href="https://cloud.google.com/sdk/gcloud/reference/compute/addresses/create" rel="nofollow noreferrer">--region flag</a>. You might be able to find more information in this community documentation on <a href="https://cloud.google.com/community/tutorials/nginx-ingress-gke" rel="nofollow noreferrer">"Ingress with NGINX controller on Google Kubernetes Engine"</a></p>

<p>3) Will this impact our ability to use Anthos for development and UAT clusters deployed on-premise.</p>

<p>As per my understanding, it will use regional resources so you won't get any advantages of global resources like accessing GCP GFE to the nearest location of the client or your service user.</p>
