Terraform-provider-google: Add support to opt-out of the new VPC-Native cluster default

[moxli]

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

Beginning on March 31, 2019, new Kubernetes clusters will be created by default in VPC-native mode. Existing clusters will continue to use Routes-based clusters.

I am not sure how it should be implemented because there is the ip_allocation_policy option already.

New or Affected Resource(s)

• google_container_cluster

Potential Terraform Configuration

resource "google_container_cluster" "primary" {
  name               = "marcellus-wallace"
  zone               = "us-central1-a"
  initial_node_count = 3

  enable_vpc_native = "false"

  master_auth {
    username = "mr.yoda"
    password = "adoy.rm"
  }

References

This is a newsletter i received today.

Hello Google Kubernetes Engine Customer,

We’re writing to let you know that from March 31, 2019, newly created clusters will, by default, be VPC-native instead of routes-based. VPC-native clusters are by default integrated with VPC features, are more secure, scalable and do not exhaust Routes quota. There will be no changes to your existing Kubernetes clusters.

What do I need to know?
VPC-native clusters use secondary ranges for the IP address ranges of the cluster. One range is reserved for Pod IP addresses, and another is reserved for Service IP addresses.

Routes-based clusters (the previous default), use a single CIDR range for both Pod IP addresses and Service IP addresses.

CIDR blocks used in VPC-native clusters are visible to other Google Cloud Platform (GCP) services, while CIDR blocks used in Routes-based clusters are not. VPC-native CIDR ranges will not overlap with CIDR ranges used by other VPC resources. A newly created VPC-native cluster would by default consume an extra /20 private IP addresses.

What do I need to do?
Beginning on March 31, 2019, new Kubernetes clusters will be created by default in VPC-native mode. Your existing clusters will continue to use Routes-based clusters.

If you’d like to use Routes-based clusters for your newly created projects, you can deselect the "Enable VPC-native (using alias IP)" option for the relevant VPC and project from the Cloud Console when creating your cluster:

or using the gcloud command line tool:

gcloud container clusters create NAME --no-enable-ip-alias
Need more information or help?
If you have any questions or require assistance, please reply to this email to contact Google Cloud Support.

Thank you for being a valued Kubernetes Engine customer.

Googles guide fo creating VPC-native clusters using Alias IPs: https://cloud.google.com/kubernetes-engine/docs/how-to/alias-ips

[adrianlop]

@moxli technically I think this is already implemented.

I create my VPC-native clusters with:

ip_allocation_policy {
  cluster_secondary_range_name  = "xxx"
  services_secondary_range_name = "yyy"
}

xxx and yyy being the names of the secondary ranges I created in the subnet used

[moxli]

@adrianlop
I think you misunderstood me. This issue is not about creating vpc-native clusters but to prevent a cluster from being vpc-native after March 31, 2019.

If you’d like to use Routes-based clusters for your newly created projects, you can deselect the "Enable VPC-native (using alias IP)" option for the relevant VPC and project from the Cloud Console when creating your cluster:

[pcj]

Perhaps a title change to something like "Add support to opt-out of the new VPC-Native cluster default" would make the intent of this issue more clear.

Any progress on this?

[sryabkov]

@moxli

Google announcement says to use --no-enable-ip-alias. Google documentation on IPAllocationPolicy shows that there is useIpAliases setting. Are the two related? In other words, does --no-enable-ip-alias controls the value of useIpAliases? Sorry, I didn't have the time to test this hypothesis.

If the answer is yes, would it be better to implement the opt_out be by introducing use_ip_aliases to the ip_allocation_policy block, i.e. something like this:

ip_allocation_policy {
  use_ip_aliases  = false
}

[agosto-levitomes]

Is this feature/2.1.0 on track to be released before June 17th?

[rileykarson]

I didn't end up finding the time to include this in 2.1.0, but it should be fixed for 2.2.0 or a release soon after before the end of the month.

[agosto-levitomes]

Thanks for the update

[rileykarson]

Done- this should be included in 2.2.0.

[hashibot[bot]]

I'm going to lock this issue because it has been closed for _30 days_ ⏳. This helps our maintainers find and focus on the active issues.

If you feel this issue should be reopened, we encourage creating a new issue linking back to this one for added context. If you feel I made an error 🤖 🙉 , please reach out to my human friends 👉 [email protected]. Thanks!