Dynamic EBS provisioning ignoring AZ requirement

[pliu]

/kind bug

What happened?
I set up AWS EBS CSI driver and a StorageClass with WaitForNextConsumer for dynamic EBS provisioning. Upon creating a PVC and scheduling a Pod on a host in the 1b AZ, the dynamically provisioned EBS volume was provisioned in the 1a AZ, preventing it from being mounted into the Pod.

What you expected to happen?
I expected that the dynamically provisioned EBS volume would be in the same AZ as the host the requesting Pod is in.

How to reproduce it (as minimally and precisely as possible)?
Nothing special. For testing, I created a PVC and force-scheduled the Pod that would use that PVC to arbitrary hosts in various AZs to see how EBS is provisioned.

Anything else we need to know?:
The particular cluster this is happening on consists of hosts both in AWS as well as not in AWS. We used a nodeSelector in the deployment and daemon set to ensure that the AWS EBS CSI driver Pods are only scheduled on the AWS hosts.

Looking at the logs, the AccessibilityRequirements field of CreateVolume call is nil. Comparing to a cluster in which dynamic provisioning is working as expected, in the working cluster AccessibilityRequirements field of the CreateVolume has a list of AZs.

Environment

• Kubernetes version (use kubectl version): 1.16.10
• Driver version: 0.7.1

[pliu]

Found the issue. I'm just bad at looking at configuration.

[ronenl1]

I'm experiencing the same behaviour, can you share what was the problem in your case?

[pliu]

I had forgotten to set enableVolumeScheduling to true in values.yaml.

[ronenl1]

I think it should be documented under Dynamic Volume Provisioning, I missed that configuration.
Thank you for sharing 😄

[ayberk]

@pliu @ronenl1 PRs most welcome! :)

[ronenl1]

Done: #691