storageClassName: gold
  ```


In order to promote the usage of dynamic provisioning this feature permits the cluster administrator to specify a **default** StorageClass. When present, the user can create a PVC without having specifying a storageClassName, further reducing the user’s responsibility to be aware of the underlying storage provider. When using default StorageClasses, there are some operational subtleties to be aware of when creating PersistentVolumeClaims (PVCs). This is particularly important if you already have existing PersistentVolumes (PVs) that you want to re-use:  

- PVs that are already “Bound” to PVCs will remain bound with the move to 1.6

  - They will not have a StorageClass associated with them unless the user manually adds it
  - If PVs become “Available” (i.e.; if you delete a PVC and the corresponding PV is recycled), then they are subject to the following
- If storageClassName **is not specified** in the PVC, the **default storage class will be used** for provisioning.

  - Existing, “Available”, PVs that do not have the default storage class label **will not be considered** for binding to the PVC
- If storageClassName **is set to an empty string** **(‘’)** in the PVC, no storage class will be used (i.e.; dynamic provisioning is disabled for this PVC)

  - Existing, “Available”, PVs (that do not have a specified storageClassName) **will be considered** for binding to the PVC
- If storageClassName is set to a specific value, then the matching storage class will be used

  - Existing, “Available”, PVs that have a matching storageClassName **will be considered** for binding to the PVC
  - If no corresponding storage class exists, the PVC will fail.
To reduce the burden of setting up default StorageClasses in a cluster, beginning with 1.6, Kubernetes installs (via the add-on manager) default storage classes for several cloud providers. To use these default StorageClasses, users **do not** need refer to them by name – that is, storageClassName need not be specified in the PVC.  

The following table provides more detail on default storage classes pre-installed by cloud provider as well as the specific parameters used by these defaults.  


| Cloud Provider | Default StorageClass Name | Default Provisioner |
|---|---|---|
| Amazon Web Services | gp2 | aws-ebs |
| Microsoft Azure | standard | azure-disk |
| Google Cloud Platform | standard | gce-pd |
| OpenStack | standard | cinder |
| VMware vSphere | thin | vsphere-volume |


While these pre-installed default storage classes are chosen to be “reasonable” for most storage users, [this guide](/docs/tasks/administer-cluster/change-default-storage-class) provides instructions on how to specify your own default.  



**Dynamically Provisioned Volumes and the Reclaim Policy**



All PVs have a reclaim policy associated with them that dictates what happens to a PV once it becomes released from a claim (see [user-guide](/docs/user-guide/persistent-volumes/#reclaiming)). Since the goal of dynamic provisioning is to completely automate the lifecycle of storage resources, the default reclaim policy for dynamically provisioned volumes is “delete”. This means that when a PersistentVolumeClaim (PVC) is released, the dynamically provisioned volume is de-provisioned (deleted) on the storage provider and the data is likely irretrievable. If this is not the desired behavior, the user must change the reclaim policy on the corresponding PersistentVolume (PV) object after the volume is provisioned.



**How do I change the reclaim policy on a dynamically provisioned volume?**

You can change the reclaim policy by editing the PV object and changing the “persistentVolumeReclaimPolicy” field to the desired value. For more information on various reclaim policies see [user-guide](/docs/user-guide/persistent-volumes/#reclaim-policy).