Open MrAbaddon opened 3 months ago
if you set volumeBindingMode: WaitForFirstConsumer
in storage class, the pod would be scheduled to the node first, and then pvc creation would happen, that could make sure you have the right region together with pod. Otherwise how does the disk controller know which region you want to create a disk pv?
This is my StorageClasse manifest.
apiVersion: storage.k8s.io/v1 kind: StorageClass metadata: name: managed-csi annotations: storageclass.kubernetes.io/is-default-class: "true" provisioner: disk.csi.azure.com parameters: skuName: StandardSSD_LRS # available values: StandardSSD_LRS, StandardSSD_ZRS, Premium_LRS, Premium_ZRS, etc. reclaimPolicy: Delete volumeBindingMode: WaitForFirstConsumer allowVolumeExpansion: true
So I've seted volumeBindingMode: WaitForFirstConsumer
.
I can see in logs that the request is made for the correct region:
I0528 21:30:38.162962 1 utils.go:106] GRPC request: {"accessibility_requirements":{"preferred":[{"segments":{"topology.disk.csi.azure.com/zone":"westeurope-1","topology.kubernetes.io/zone":"westeurope-1"}}],"requisite":[{"segments":{"topology.disk.csi.azure.com/zone":"westeurope-1","topology.kubernetes.io/zone":"westeurope-1"}}]},"capacity_range":{"required_bytes":10737418240},"name":"pvc-669b1eae-d04b-485a-9987-8f95d86b2a10","parameters":{"csi.storage.k8s.io/pv/name":"pvc-669b1eae-d04b-485a-9987-8f95d86b2a10","csi.storage.k8s.io/pvc/name":"persistent-storage-statefulset-azuredisk-0","csi.storage.k8s.io/pvc/namespace":"default","skuName":"StandardSSD_LRS"},"volume_capabilities":[{"AccessType":{"Mount":{}},"access_mode":{"mode":7}}]}
The pod is created in a node in westeurope but the disk is requested where the controller is based, in this case northeurope:
I0528 21:38:38.132827 1 controllerserver.go:219] begin to create azure disk(pvc-6083de42-5d50-4b6b-84ca-2812374d9a60) account type(StandardSSD_LRS) rg(xxxxxxxxx) location(northeurope) size(10) diskZone(northeurope-1) maxShares(0)
Im using the helm charts to install the driver. So as a work around I'm using the values to force the controller to be replica 1 and with node selectors I'm placing the controller in a node that is located in a region where I want to place the disk. A bit manual but works...
What happened:
I have a self managed cluster in Azure in 2 different regions. North Europe and west Europe. 1 control plane and 3 worker nodes in North Europe. 1 control plane and 3 worker nodes in West Europe. I apply a PVC manifest and a Statefullset with node selector for westeurope and I see that the azure disk is provisioned in northeurope.
Looking at the logs in the controller:
We can see that in the Request it detects the topology
"topology.disk.csi.azure.com/zone":"westeurope-1","topology.kubernetes.io/zone":"westeurope-1"
. Thats correct. But the controller then creates inlocation(northeurope) size(10) diskZone()
. northeurope without an AZ and this is wrong.If I change the node selector to northeurope, the azure disk is provisioned in northeurope and everything works good.
And the Logs:
We can see that in request it detects topology
"topology.disk.csi.azure.com/zone":"northeurope-1","topology.kubernetes.io/zone":"northeurope-1"
. Thats correct. And the controller creates in correct location:begin to create azure disk(pvc-6083de42-5d50-4b6b-84ca-2812374d9a60) account type(StandardSSD_LRS) rg(xxxxxxxxx) location(northeurope) size(10) diskZone(northeurope-1) maxShares(0)
.What you expected to happen:
The correct azure disk is provisioned in the correct region and zone
Environment:
kubectl version
): Client Version: version.Info{Major:"1", Minor:"23", GitVersion:"v1.23.0", GitCommit:"ab69524f795c42094a6630298ff53f3c3ebab7f4", GitTreeState:"clean", BuildDate:"2021-12-07T18:16:20Z", GoVersion:"go1.17.3", Compiler:"gc", Platform:"linux/amd64"} Server Version: version.Info{Major:"1", Minor:"29", GitVersion:"v1.29.5", GitCommit:"59755ff595fa4526236b0cc03aa2242d941a5171", GitTreeState:"clean", BuildDate:"2024-05-14T10:39:39Z", GoVersion:"go1.21.9", Compiler:"gc", Platform:"linux/amd64"} WARNING: version difference between client (1.23) and server (1.29) exceeds the supported minor version skew of +/-1