instruction: Create a Kubernetes PersistentVolume configuration with best practices
output: ```dockerfile
  from failing PVC expansion by users (RecoverVolumeExpansionFailure) is available as an beta feature
  since Kubernetes 1.32 and should be enabled by default. Refer to the
  feature gate
  documentation for more information.When using RecoverVolumeExpansionFailure feature, if expansion has failed for a PVC, you can retry expansion with a
  smaller size than the previously requested value. To request a new expansion attempt with a
  smaller proposed size, edit .spec.resources for that PVC and choose a value that is less than the
  value you previously tried.
  This is useful if expansion to a higher value did not succeed because of capacity constraint.
  If that has happened, or you suspect that it might have, you can retry expansion by specifying a
  size that is within the capacity limits of underlying storage provider. You can monitor status of
  resize operation by watching .status.allocatedResourceStatuses and events on the PVC.Note that,
  although you can specify a lower amount of storage than what was requested previously,
  the new value must still be higher than .status.capacity.
  Kubernetes does not support shrinking a PVC to less than its current size.Types of Persistent VolumesPersistentVolume types are implemented as plugins. Kubernetes currently supports the following plugins:csi - Container Storage Interface (CSI)fc - Fibre Channel (FC) storagehostPath - HostPath volume
  (for single node testing only; WILL NOT WORK in a multi-node cluster;
  consider using local volume instead)iscsi - iSCSI (SCSI over IP) storagelocal - local storage devices
  mounted on nodes.nfs - Network File System (NFS) storageThe following types of PersistentVolume are deprecated but still available.
  If you are using these volume types except for flexVolume, cephfs and rbd,
  please install corresponding CSI drivers.awsElasticBlockStore - AWS Elastic Block Store (EBS)
  (migration on by default starting v1.23)azureDisk - Azure Disk
  (migration on by default starting v1.23)azureFile - Azure File
  (migration on by default starting v1.24)cinder - Cinder (OpenStack block storage)
  (migration on by default starting v1.21)flexVolume - FlexVolume
  (deprecated starting v1.23, no migration plan and no plan to remove support)gcePersistentDisk - GCE Persistent Disk
  (migration on by default starting v1.23)portworxVolume - Portworx volume
  (migration on by default starting v1.31)vsphereVolume - vSphere VMDK volume
  (migration on by default starting v1.25)Older versions of Kubernetes also supported the following in-tree PersistentVolume types:cephfs
  (not available starting v1.31)flocker - Flocker storage.
  (not available starting v1.25)glusterfs - GlusterFS storage.
  (not available starting v1.26)photonPersistentDisk - Photon controller persistent disk.
  (not available starting v1.15)quobyte - Quobyte volume.
  (not available starting v1.25)rbd - Rados Block Device (RBD) volume
  (not available starting v1.31)scaleIO - ScaleIO volume.
  (not available starting v1.21)storageos - StorageOS volume.
  (not available starting v1.25)Persistent VolumesEach PV contains a spec and status, which is the specification and status of the volume.
  The name of a PersistentVolume object must be a valid
  DNS subdomain name.apiVersion: v1
  kind: PersistentVolume
  metadata:
   name: pv0003
  spec:
   capacity:
   storage: 5Gi
   volumeMode: Filesystem
   accessModes:
   - ReadWriteOnce
   persistentVolumeReclaimPolicy: Recycle
   storageClassName: slow
   mountOptions:
   - hard
   - nfsvers=4.1
   nfs:
   path: /tmp
   server: 172.17.0.2
  Note:Helper programs relating to the volume type may be required for consumption of
  a PersistentVolume within a cluster. In this example, the PersistentVolume is
  of type NFS and the helper program /sbin/mount.nfs is required to support the
  mounting of NFS filesystems.CapacityGenerally, a PV will have a specific storage capacity. This is set using the PV's
  capacity attribute which is a Quantity value.Currently, storage size is the only resource that can be set or requested.
  Future attributes may include IOPS, throughput, etc.Volume ModeFEATURE STATE:
  Kubernetes v1.18 [stable]Kubernetes supports two volumeModes of PersistentVolumes: Filesystem and Block.volumeMode is an optional API parameter.
  Filesystem is the default mode used when volumeMode parameter is omitted.A volume with volumeMode: Filesystem is mounted into Pods into a directory. If the volume
  is backed by a block device and the device is empty, Kubernetes creates a filesystem
  on the device before mounting it for the first time.You can set the value of volumeMode to Block to use a volume as a raw block device.
  Such volume is presented into a Pod as a block device, without any filesystem on it.
  This mode is useful to provide a Pod the fastest possible way to access a volume, without
  any filesystem layer between the Pod and the volume. On the other hand, the application
  running in the Pod must know how to handle a raw block device.
  See Raw Block Volume Support
  for an example on how to use a volume with volumeMode: Block in a Pod.Access ModesA PersistentVolume can be mounted on a host in any way supported by the resource
  provider. As shown in the table below, providers will have different capabilities
  and each PV's access modes are set to the specific modes supported by that particular
  volume. For example, NFS can support multiple read/write clients, but a specific
  NFS PV might be exported on the server as read-only. Each PV gets its own set of
  access modes describing that specific PV's capabilities.The access modes are:ReadWriteOncethe volume can be mounted as read-write by a single node. ReadWriteOnce access
  mode still can allow multiple pods to access (read
  ```