No matter how you like to participate in developer communities, Pulumi wants to meet you there. If you want to meet other Pulumi users to share use-cases and best practices, contribute code or documentation, see us at an event, or just tell a story about something cool you did with Pulumi, you are part of our community.

Pulumi Community

Continuing what I sent on general
Take a look <https://cloud.google.com/kubernetes-engine/docs/how-to/alias-ips|here> about VPC-native clusters and <https://cloud.google.com/kubernetes-engine/docs/how-to/routes-based-cluster|here> about routes-based clusters
They work differently regarding IP allocations and interaction with the VPC network.

image.png

The default can trick you because they are not very consistent:

And although newer gcloud versions returned to routes-based, they add a lot of options that are not the default for the API. Pulumi used the API directly, so you need to set those values to work.

VPC-native clusters have advantages over routes-based ones, but they also require more configuration and care

The parameter for VPC-native on Pulumi is <https://www.pulumi.com/docs/reference/pkg/nodejs/pulumi/gcp/container/#ClusterArgs-ipAllocationPolicy|this one>

I also tried with the (undocumented?) networking_mode <https://github.com/pulumi/pulumi-gcp/blob/8a0db4aff3c832cee0e6f89ade72415858291669/sdk/go/gcp/container/cluster.go#L157>

If there is no `ipAllocationPolicy` the cluster will be routes-based

For routes-based there must be a subnetwork in the same region and the network must have a /14 range available

is there a way to do “pulumi up” using the old gcp plugin? seems the only change.

I think this might be leftovers, so you should check if the cluster auto allocated a range and left it there after it was destroyed

and in that case: cli continues to work? sounds strange. But I check

but the range is visible in “vpc networks”? theorically no, only ip aliases area visible. Where i can check this leftover?

You can set the <https://cloud.google.com/kubernetes-engine/docs/how-to/routes-based-cluster#pod_address_range|range directly>. I personally prefer to have everything on the infrastructure explicit

Schermata 2020-08-24 alle 18.13.48.png

I have a running cluster at the moment. But no sign of its range here

Sorry, it should be under routes in your case

yes.  Found thanks. But I see only that cluster. I figure that I setup several VPNs from the creation of that cluster to now. and I have a 10.0.0.0/8 sattic route.  mhmhm may be?

If you aready have a route for 10.0.0.0/8 you can't auto-allocate a /14 inside of it. Not sure what magic gcloud is doing in this case, might be worth creating a cluster with it just to see which route appears

but with CLI it is working… I’m not so sure that is a 10.0.0.0 route issue…

That is why I said that it might be worth creating the cluster with gcloud and inspecting it. It might be setting something different

without 10.0.0.0/8 route it is working. It is a huge problem, but it make sense now.