-
Notifications
You must be signed in to change notification settings - Fork 276
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Hardcoded virtualnetworklink suffix causes issues if virtualnetworklink already exists with different name #6520
Labels
kind/bug
Categorizes issue or PR as related to a bug.
Comments
I think I have the same issue. My upgrade path was This is the error I get on a newly created pvc: Events:
Type Reason Age From Message
---- ------ ---- ---- -------
Normal ExternalProvisioning 10s persistentvolume-controller Waiting for a volume to be created either by the external provisioner 'file.csi.azure.com' or manually by the system administrator. If volume creation is delayed, please verify that the provisioner is running and correctly registered.
Normal Provisioning 2s (x4 over 10s) file.csi.azure.com_csi-azurefile-controller-[...] External provisioner is provisioning volume for claim "[...]"
Warning ProvisioningFailed 1s (x4 over 10s) file.csi.azure.com_csi-azurefile-controller-[...] failed to provision volume with StorageClass "my-custom-storage-class": rpc error: code = Internal desc = failed to ensure storage account: get virtual link for vnet(aks-vnet-14154989) and DNS Zone(privatelink.file.core.windows.net) in resourceGroup([...]) returned with GET http://localhost:7788/subscriptions/[...]/resourceGroups/[...]/providers/Microsoft.Network/privateDnsZones/privatelink.file.core.windows.net/virtualNetworkLinks/aks-vnet-14154989-vnetlink
--------------------------------------------------------------------------------
RESPONSE 404: 404 Not Found
ERROR CODE: NotFound
--------------------------------------------------------------------------------
{
"code": "NotFound",
"message": "The virtual network link 'aks-vnet-14154989-vnetlink' does not exist for Private DNS zone 'privatelink.file.core.windows.net' in resource group '[...]' of subscription '[...]'."
}
-------------------------------------------------------------------------------- |
After updating to Warning ProvisioningFailed 119s file.csi.azure.com_csi-azurefile-controller-[...] failed to provision volume with StorageClass "my-custom-storage-class": rpc error: code = Internal desc = failed to ensure storage account: get private dns zone privatelink.file.core.windows.net returned with GET http://localhost:7788/subscriptions/[...]/resourceGroups/[...]/providers/Microsoft.Network/privateDnsZones/privatelink.file.core.windows.net
--------------------------------------------------------------------------------
RESPONSE 401: 401 Unauthorized
ERROR CODE: ExpiredAuthenticationToken
--------------------------------------------------------------------------------
{
"error": {
"code": "ExpiredAuthenticationToken",
"message": "The access token expiry UTC time '8/2/2024 5:22:59 AM' is earlier than current UTC time '8/2/2024 7:31:24 AM'."
}
}
-------------------------------------------------------------------------------- |
After updating to 1.29.7 I was back to the error as in 1.29.5 I recreated the link now with the currently expected name. It worked then as expected. |
@andyzhangx @cvvz could you help check this one? |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
What happened:
cloud-provider-azure/pkg/provider/azure_storageaccount.go
Lines 365 to 375 in 3e88183
This piece of code assumes that all virtual networks have a name with the '-vnetlink' suffix.
If this is not the case it will try to create the vnetlink, but if a different link already exists for the same vnet. It will fail.
What you expected to happen:
The code should get all virtualnetworklinks and check if one already exists for that vnet (preferably with the Resource ID of the vNet). If it exists, it should not try to create a new virtualnetworklink as only one can exist per vnet.
How to reproduce it (as minimally and precisely as possible):
We hit this issue while upgrading from AKS 1.27 --> 1.28. This also upgrades the CSI drivers, which use this provider. Initially you notice no issues, but when you try to do any actions on your PVC it will report in the logs with errors about not being able to create the virtualnetworklink.
Anything else we need to know?:
The workaround is to manually delete the vnetlink and recreate it with the '-vnetlink' suffix, however that causes a temporary failure in name resolution (depending on TTL of records)
Environment:
kubectl version
): happened after upgrading from AKS 1.27 --> 1.28.9cat /etc/os-release
): Ubuntuuname -a
): -The text was updated successfully, but these errors were encountered: