Support use of non RFC-1918 address space in GKE google_container_cluster resource since GCP supports it

[donjmilligan]

Community Note

• Please vote on this issue by adding a 👍 reaction to the original issue to help the community and maintainers prioritize this request
• Please do not leave "+1" or "me too" comments, they generate extra noise for issue followers and do not help prioritize the request
• If you are interested in working on this issue or have submitted a pull request, please leave a comment. If the issue is assigned to the "modular-magician" user, it is either in the process of being autogenerated, or is planned to be autogenerated soon. If the issue is assigned to a user, that user is claiming responsibility for the issue. If the issue is assigned to "hashibot", a community member has claimed the issue already.

Description

In some enterprise use cases it makes sense to use non RFC-1918 spaces since other ranges are already in use, and this is recognized and supported by GCP. According to GCPs Kubernetes Engine Documentation the use of non-RFC-1918 address space in GKE clusters is supported. We might even say it is encouraged if we need additional IP space. Another location that lists these other RFC ranges as valid for use by GCP is in their Subnets Documentation.

The terraform resource _google_containercluster aught to support other RFC specifications in the cluster_ipv4_cidr field.

New or Affected Resource(s)

google_container_cluster

References

https://cloud.google.com/kubernetes-engine/docs/how-to/alias-ips#enable_reserved_ip_ranges

https://cloud.google.com/vpc/docs/subnets#valid-ranges

• b/298499928

[donjmilligan]

I have since recognized that removing cluster_ipv4_cidr and using these fields in the ip_allocation_policy block with non RFC-1918 address spaces will allow a terraform plan to complete without any errors regarding RFC 1918.

ip_allocation_policy {
    cluster_ipv4_cidr_block  =
    services_ipv4_cidr_block = 
  }

Shouldn't cluster_ipv4_cidr still also support this?