Not able to dynamically provision a share file from a provided storage class about azurefile-csi-driver

[aelmanaa]

hello @andyzhangx

I want dynamic provisioning :) However, I want AKS to dynamically create share files in a pre-defined shared account.

[andyzhangx]

still noticed that the activity logs of my storage account don't mention that a process created the file storage. Any reason why the Activity logs are not updated?

not sure, azure file creation activity may not exist in Activity logs

is the in-tree version "kubernetes.io/azure-file" based on "file.csi.azure.com"? Meaning that a certain point, "kubernetes.io/azure-file" will contain the fixes en enhancements of "file.csi.azure.com" ?

in-tree and csi drivers share the same azure cloud provider library, and in a certain time(this year), we will switch to use csi driver

Is "file.csi.azure.com" officially supported by Microsoft? We have a support contract for Azure so I'd like to know if we will have a support for "file.csi.azure.com" should we decide to install it

Yes, it's officially supported by Microsoft

[andyzhangx]

that's for dynamic provisioning, I see you want to use static provisoining(use existing file share), you could refer to https://docs.microsoft.com/en-us/azure/aks/azure-files-volume

[andyzhangx]

@aelmanaa could you try this azure file storage class example: https://github.com/andyzhangx/demo/blob/master/pv/storageclass-azurefile-sharename.yaml

[aelmanaa]

thanks.

where do you put the secret holding the storage account access key?

[andyzhangx]

thanks.

where do you put the secret holding the storage account access key?

if your storage account is in the same resource group as aks cluster, and when you use that storage class, it would get storage account key automatically, you don't need to use secret in azure file storage class.

[aelmanaa]

thanks.
where do you put the secret holding the storage account access key?

if your storage account is in the same resource group as aks cluster, and when you use that storage class, it would get storage account key automatically, you don't need to use secret in azure file storage class.

no it's not. we decided to put our AKS dashboards, log analytics and storage account in a different resource group (in order to keep everything even when you redeploy the cluster)

[andyzhangx]

thanks.
where do you put the secret holding the storage account access key?

if your storage account is in the same resource group as aks cluster, and when you use that storage class, it would get storage account key automatically, you don't need to use secret in azure file storage class.

no it's not. we decided to put our AKS dashboards, log analytics and storage account in a different resource group (in order to keep everything even when you redeploy the cluster)

if your service principle in aks cluster has access to that storage account, it should also work, no need to use secret

[andyzhangx]

hi, is it resolved?

[aelmanaa]

hi, is it resolved?

Hello Andy,

sorry I was busy on other tasks. I'll test and get back to you before the end of the week

[aelmanaa]

Hello @andyzhangx

I tested. it didn't work at the beginning because of this issue
kubernetes/kubernetes#85475

so I allowed access to all network just for testing purpose and noticed that it worked. I think we will stick with the workaround for now (creating the volumes statically) until that the fix is available in a GA AKS version. In fact, we prefer not to open access of our storage account to all networks

Questions though:

*I was curious to see the the identity and ip address of the process(file controller on the master node) which created the storage and I couldn't find anything in the activity logs of my storage account. When we create them manually, we can see who created the storage, but in this case, there is no trace in the logs. Do you have any idea why?

• I noticed that the IP address of the master node is static (I mean i keep nslookup and it doesn't change). So I decided to restrict the access to this IP and to our subnet. It didn't work though :)

[andyzhangx]

Hello @andyzhangx

I tested. it didn't work at the beginning because of this issue
kubernetes/kubernetes#85475

so I allowed access to all network just for testing purpose and noticed that it worked. I think we will stick with the workaround for now (creating the volumes statically) until that the fix is available in a GA AKS version. In fact, we prefer not to open access of our storage account to all networks

Questions though:

*I was curious to see the the identity and ip address of the process(file controller on the master node) which created the storage and I couldn't find anything in the activity logs of my storage account. When we create them manually, we can see who created the storage, but in this case, there is no trace in the logs. Do you have any idea why?

• I noticed that the IP address of the master node is static (I mean i keep nslookup and it doesn't change). So I decided to restrict the access to this IP and to our subnet. It didn't work though :)

hi, could you try the master version, I think master version already fixed that network restriction issue (on Dec 3, 2019):

azurefile-csi-driver/vendor/k8s.io/legacy-cloud-providers/azure/azure_storageaccount.go

Line 25 in 87b0e16

"github.com/Azure/azure-sdk-for-go/services/storage/mgmt/2019-06-01/storage"

Pls verify it by following: https://github.com/kubernetes-sigs/azurefile-csi-driver/blob/master/docs/install-csi-driver-master.md

And I could publish a new stable release if master branch fixed you isssue, thanks.

[andyzhangx]

Btw, by trying this, you need to delete existing storage account in MC_ resource group, otherwise it will search for a matching storage account, and then use that storage account

[aelmanaa]

thanks @andyzhangx
just a question before installing: If I install "https://github.com/kubernetes-sigs/azurefile-csi-driver/blob/master/docs/install-csi-driver-master.md" then how will the controller know that it should use the installed one, rather than the "official" version and which is referenced in the storage class (provisioner: kubernetes.io/azure-file) ?

thanks

[andyzhangx]

it depends on which storage class you are using, if the provisioner is kubernetes.io/azure-file, then it would use in-tree azure file driver, if the provisioner is file.csi.azure.com, then it would use azure file csi driver.

[aelmanaa]

Hi @andyzhangx

so I tested with "file.csi.azure.com" instead of "kubernetes.io/azure-file" and I've confirmed that I could create a file storage even though the access is limited to a specific subnet. which is good thanks. However, I've got few questions:

• I still noticed that the activity logs of my storage account don't mention that a process created the file storage. Any reason why the Activity logs are not updated?

• is the in-tree version "kubernetes.io/azure-file" based on "file.csi.azure.com"? Meaning that a certain point, "kubernetes.io/azure-file" will contain the fixes en enhancements of "file.csi.azure.com" ?

• Is "file.csi.azure.com" officially supported by Microsoft? We have a support contract for Azure so I'd like to know if we will have a support for "file.csi.azure.com" should we decide to install it

thanks a lot!

[aelmanaa]

thanks @andyzhangx for your help. I'm closing the issue