Misleading example of static provisioning

[jsafrane]

/kind bug

What happened?
The example at https://github.com/kubernetes-sigs/aws-ebs-csi-driver/tree/master/examples/kubernetes/static-provisioning
uses StorageClass with volumeBindingMode: WaitForFirstConsumer. In this mode, a Pod + PVC is scheduled together and are assigned to a random node / zone. Scheduler does not take pre-existing unbound PVs into account here at all. Therefore a new empty PV may be provisioned for the PVC, leaving users confused.

What you expected to happen?

The example is hard to do right. Either a PV must exist in every AWS zone where cluster has a node, which is odd, or the StorageClass must use volumeBindingMode: Immediate, which may then break other cases where dynamic provisioning + topology is preferred. Does it make sense to have a dedicated StorageClass just for pre-provisioned PVs?

How to reproduce it (as minimally and precisely as possible)?

1. Create a cluster with 3 AWS zones.
2. Follow the example
3. Sometimes, you get a dynamically provisioned PV instead of the pre-provisioned one.

[wongma7]

No, let's remove the StorageClass, I have only ever heard confusion about it.