Egress on existing clusters using node load balancer breaks after v1.9.x upgrade about cluster-api-provider-azure HOT 4 CLOSED

/assign

from cluster-api-provider-azure.

@dkoshkin I have two proposals for you:

1. We change the defaulting to not update existing subnets: eac62d2
   This is a bit of a hack because it relies on the ID field to determine that the defaulting is happening on an existing subnet vs a new subnet. Ideally, NAT Gateway would be a pointer so we could differentiate between disable NAT Gateway and new cluster, and we could have simply switch the default from empty string to default name, but that is not the case :(

2. We update existing subnets to "attach" the new NAT Gateway: b18f008

I'm leaning towards 2) because it's a better long-term solution. I agree with you that ideally we shouldn't touch existing cluster infra on upgrade. However, NAT Gateways are the recommended approach for outbound connectivity on Azure and we should provide a path forward for existing clusters. 1) is a hack and may work for now but we've talked about getting rid of ID altogether because it's an anti-pattern (we're setting the spec from the controller, there's a comment here about it).

Thoughts? I still need to run some tests to validate that these approaches work and write unit tests but wanted to get your input on these options.

from cluster-api-provider-azure.

Thanks for the suggestions @CecileRobertMichon!

What do you think about a combination of both of these approaches? Use 1 to fix this issue without making an infra change and then use 2 and allow users to opt in to this change by changing the spec (is this even possible?)

from cluster-api-provider-azure.

@dkoshkin done, PTAL: #3700

from cluster-api-provider-azure.