I have a AKS Cluster and some microservice with Nodeport available in it.
User -> Application Gateway -> Backend Pool -> Nodeport of microservice -> service
However, i have idea to use Application Gateway with Virtual machine scale sets from AKS Node Pool.
When i add backend (VMSS) of AKS Nodepool in application gateway
{
"status": "Failed",
"error": {
"code": "LinkedAuthorizationFailed",
"message": "The client has permission to perform action 'Microsoft.Compute/galleries/images/versions/read' on scope '/subscriptions/aa51d057-842e..../resourcegroups/MC_loadbalancer_aaa-aks-1_southeastasia/providers/Microsoft.Compute/virtualMachineScaleSets/aks-syspool-13675031-vmss', however the current tenant '1393b73d-faec-...' is not authorized to access linked subscription '911a5e88-712a-...'."
}
}
But if i create manual VMSS and add it to application gateway, it's fine. But when i add VMSS Node Pool by AKS Cluster, it's error like above.
The error is weird. It's like my Tenant ID doesn't have subscription to 911a5e88....
Is it really possible to connect application gateway to AKS Node Pool as backend-pool ?
I am in the exact same situation.
The fix was inspired from here: https://learn.microsoft.com/en-us/azure/virtual-machine-scale-sets/virtual-machine-scale-sets-upgrade-scale-set#update-the-load-balancer-for-your-scale-set It seems like in azure you can go also the other way around and configure your VMSS to a BackendPool, option which seems to be available only from the CLI.
az vmss update --resource-group myResourceGroup --name myScaleSet --add virtualMachineProfile.networkProfile.networkInterfaceConfigurations[0].ipConfigurations[0].ApplicationGatewayBackendAddressPools '{"id": "/subscriptions/{subscriptionId}/resourceGroups/myResourceGroup/providers/Microsoft.Network/applicationGateways/{applicationGatewayName}/backendAddressPools/{applicationGatewayBackendPoolName}"}'
I don't know why the current reply was accepted since it just providing an workaround; you must be able to add a VMSS to your AppGW backend pool. It's either a bug in Azure or an undocumented case with the latest upgrades.
You should never use IP or FQDN with a VMSS, it's not good practice.