cluster-api-provider-azure: Service type loadbalancer does not work when AzureClusterName!=ClusterName with node outbound LB
/kind bug
[Before submitting an issue, have you checked the Troubleshooting Guide?] When a workload cluster is created with AzureClusterName!=ClusterName and node outbound load balancer is opted, k8s service with type load balancer fails to route even if it gets a public IP assigned.
What steps did you take and what happened: [A clear and concise description of what the bug is.]
- Create a workload cluster so that AzureClusterName!=ClusterName
- Opt for out bound load balancer.
- Deploy a service of type load balancer. ( A simple nginx server with service of type load balancer can be used to test )
- The nginx server will not be accessible via the public IP
What did you expect to happen: The nginx server should be accessible via the public IP
Anything else you would like to add: [Miscellaneous information that will assist in solving the issue.]
-
Node outbound load balancer is created whose name is the same as that of azure cluster name. ( by capz )
-
When service of type LoadBalancer is created for an app, it creates a load balancer with the same name as cluster name. ( by in-tree cloud provider azure )
-
Now this load balancer created for service cannot add backend bools as the one created by capz has already added the nodes in the backend pool. And the reason for this is Azure does not allow multiple load balancers of same type (public or internal) to be attached to the same backend pool.
-
Now the the load balancer created for service is not able to attach backend pool causing the disconnect.
-
One suggested fix top off my head is to use ClusterName as the default outbound lb name instead of AzureClusterName.
Environment:
- cluster-api-provider-azure version:
- Kubernetes version: (use
kubectl version): - OS (e.g. from
/etc/os-release):
About this issue
- Original URL
- State: closed
- Created a year ago
- Reactions: 1
- Comments: 19 (16 by maintainers)
Yes. That only. Oh, I used the word flag – I meant the flag in azure.json config file. So this is more neat solution.
Chiming in after being pinged by @sonasingh46
This use case happens with any cluster generated from a ClusterClass, and more specifically it happens when the Topology controller generates an object starting from the AzureClusterTemplate linked from the ClusterClass.
In this case, the object being generated by the controller is named with a well know prefix, the cluster name in this case, plus a random suffix, and this is done to prevent name clashes (nothing prevents someone to create an AzureCluster object with the same).
Then the Azure Cluster is explicitly linked from the Cluster using corev1.Reference type that requires users to specify the name, and the name can be any valid K8s name.