Allow upgrades on azure without Terraform changes on LBs created from within Kubernetes (#3257)

* k8s: use separate lb for K8s services on azure

* terraform: introduce local revision variable and data resource

* terraform: azure: dont expose full nodeport range

* docs: add Azure load balancer migration
This commit is contained in:
3u13r 2024-10-09 11:31:17 +02:00 committed by GitHub
parent 2dcea4fa63
commit 2854136192
No known key found for this signature in database
GPG key ID: B5690EEEBB952194
8 changed files with 75 additions and 13 deletions

View file

@ -3,7 +3,19 @@
This document describes breaking changes and migrations between Constellation releases.
Use [`constellation config migrate`](./cli.md#constellation-config-migrate) to automatically update an old config file to a new format.
## Migrating from Azure's service principal authentication to managed identity authentication
## Migrations to v2.19.0
### Azure
* To allow seamless upgrades on Azure when Kubernetes services of type `LoadBalancer` are deployed, the target
load balancer in which the `cloud-controller-manager` creates load balancing rules was changed. Instead of using the load balancer
created and maintained by the CLI's Terraform code, the `cloud-controller-manager` now creates its own load balancer in Azure.
If your Constellation has services of type `LoadBalancer`, please remove them before the upgrade and re-apply them
afterward.
## Migrating from Azure's service principal authentication to managed identity authentication (during the upgrade to Constellation v2.8.0)
- The `provider.azure.appClientID` and `provider.azure.appClientSecret` fields are no longer supported and should be removed.
- To keep using an existing UAMI, add the `Owner` permission with the scope of your `resourceGroup`.