Consider adding StorageClasses by default

[yuvipanda]

Heya! Following on from jupyterhub/zero-to-jupyterhub-k8s#88 :)

I'd love for there to be a default storage class. Almost all helm charts default to having PVCs that are provisioned by the default, and allow you to override it. I believe this stems from https://kubernetes.io/docs/concepts/storage/persistent-volumes/#writing-portable-configuration, especially:

In the future, we expect most clusters to have DefaultStorageClass enabled, and to have some form of storage available. However, there may not be any storage class names which work on all clusters, so continue to not set one by default. At some point, the alpha annotation will cease to have meaning, but the unset storageClass field on the PVC will have the desired effect.

When writing charts, one very useful attribute is if they can work 'out of the box' with just a helm install with default values - this is actually a requirement for getting them into the stable charts repo. This too only works with a default storage class.

So when following the AWS quickstart, at the end there's additional steps required to get most helm charts to work the way the helm documentation tells you they should work. So people just following the AWS Quickstart and then heading over to helm are a little lost, since there's this missing piece that isn't mentioned here.

In my ideal world, this would come with 4 storage classes (one for each io type), with gp2 set as default. A stop gap might be to add bits about 'you might want to create a storageclass' at the end of the README. However, I think adding the storageclasses as part of the quickstart itself is the right thing to do wrt meeting expectations set by the larger kubernetes community (1 and 2 specifically).

Thank you for the wonderful product and your consideration of this issue!

[rdodev]

👍 as stop-gap measure adding a paragraph in the docs about this and how to get around it would be helpful.

//cc @Bradamant3