Ideal Path

1. Create a CloudNAT instance


2. Configure Cloud NAT as the Gateway in the nextHopGateway for a custom cloud route


3. The route is applied to the tagged VMs


4. Traffic is routed through the NAT only when needed, not for all the network traffic (matching dest. address).

Why?
GCP is advocating the use of CloudNAT as possible replacement to an instance based NAT Gateway, as described in the notes here:
https://cloud.google.com/vpc/docs/special-configurations#multiple-natgateways

Although the usage of CloudNAT is to provide Internet access to private insances or GKE nodes, there are use cases where customer require an IP whitelist for incoming traffic.

Current solutions on GKE will map the Pods' IP to the host node IP through masquerading, as described in how GCE implements the K8s network model.

https://kubernetes.io/docs/concepts/cluster-administration/networking/#google-compute-engine-gce

Current solutions exist:
1. Create a new node pool that will route to CluodNAT, by assigning the secondary range on a subnet, specific to this purpose.
2. Use an instance-based NAT Gateway and add a static route, where the source are the K8s nodes properly tagged to use it.
3. Add CloudNAT for the entire secondary range. Not acceptable, as all the traffic produced by the nodes/pods will pass through CloudNAT

Pricing is similar under comparable use cases.

Please advise on a current alternative or on how to overcome this with the current services.

Unlike nearly every automated build system, Google Cloud Build does not set environment variables inside of the running build docker containers automatically with the build context information. Instead it has "Substitution Variables" that a developer has to explicitly pass as environment variables. This makes tools that customize information based on the build environment impossible without special configuration to pass the default substitution variables as environment variables to each build step.

https://cloud.google.com/cloud-build/docs/configuring-builds/substitute-variable-values

By default the default substitution variables should be available as environment variables in the build containers. Maybe google could provide an option to disable that functionality for extremely sensitive build steps, but if this new functionality isn't the default behavior, it means Cloud Build is not on feature par with most other build systems and tools like "env-ci" will never work with them without special configuration (defeating the purpose of the library).

https://github.com/pvdlg/env-ci/pull/97#issuecomment-540040921

Right now, it is possible to define maintenance windows for some GCP resources like Cloud SQL instances and GKE clusters at the resource level:
- https://cloud.google.com/sql/docs/mysql/instance-settings#maintenance-window-2ndgen
- https://cloud.google.com/kubernetes-engine/docs/how-to/maintenance-window

CloudSQL even allows to define relative maintenance timing settings
between instances in the same project: https://cloud.google.com/sql/docs/mysql/instance-settings#maintenance-timing-2ndgen

> The relative timing of updates is not observed between projects; if you have instances with an earlier timing setting in a different project than your instances with a later timing setting, Cloud SQL makes no attempt to update the instances with the earlier timing setting first.

However, I like to separate staging/pre-production and production environments in independent projects.

It would be awesome if GCP provided relative canary and stable maintenance timing settings for projects attached to a same organization, maybe at the folder level.

That way, I'd be able to define staging/pre-production projects as "canary" and production as "stable" to get updates earlier in the former.
When disruptions would be noticed in staging/pre-production during maintenance, fixes could be implemented or on-call could be prepared when the same maintenance will happen in production.

Hey I'm a student and relatively new to cloud and as a student I CAN NOT afford a credit card and it's not easy to get credit card in my country when you are still a student.
I understand GCP can't accept debit cards due to VBV or requiring OTP for payment which conflicts with auto pay but that should not be the reason to kick out user as a whole from the service if they can't verify with a credit card?

What if GCP instead allowed user to verify using debit cards and let the user buy a subscription pack instead ?
Like the user creates a compute engine then it asks user to buy the subscription , the user can also pay in advance for a month where user manually pay the amount and not auto pay? If user didn't pay amount for next month then ofc there account will get disabled or whatever but it would be really nice and appreciated if there's another alternative to the credit card thingy.

I used GCP with free tier for a month and really loved it, it's exactly what I was looking for, but my account got terminated because I didn't verified my account with credit card.
(I'm sorry if Its already been posted or if I posted it at wrong thread)