instruction: Create a Kubernetes PersistentVolume configuration with best practices
output: ```dockerfile
  from failing PVC expansion by users is available as an alpha feature
  since Kubernetes 1.23. The RecoverVolumeExpansionFailure feature must be
  enabled for this feature to work. Refer to the
  feature gate
  documentation for more information.
  If the feature gates RecoverVolumeExpansionFailure is
  enabled in your cluster, and 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 Volumes
  PersistentVolume types are implemented as plugins. Kubernetes currently supports the following plugins:
  
  csi - Container Storage Interface (CSI)
  fc - Fibre Channel (FC) storage
  hostPath - 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) storage
  local - local storage devices
  mounted on nodes.
  nfs - Network File System (NFS) storage
  
  The 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)
  cephfs - CephFS volume
  (deprecated starting v1.28, no migration plan, support will be removed in a future release)
  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
  (deprecated starting v1.25)
  rbd - Rados Block Device (RBD) volume
  (deprecated starting v1.28, no migration plan, support will be removed in a future release)
  vsphereVolume - vSphere VMDK volume
  (migration on by default starting v1.25)
  
  Older versions of Kubernetes also supported the following in-tree PersistentVolume types:
  
  photonPersistentDisk - Photon controller persistent disk.
  (not available starting v1.15)
  scaleIO - ScaleIO volume.
  (not available starting v1.21)
  flocker - Flocker storage.
  (not available starting v1.25)
  quobyte - Quobyte volume.
  (not available starting v1.25)
  storageos - StorageOS volume.
  (not available starting v1.25)
  
  Persistent Volumes
  Each 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.
  Capacity
  Generally, 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 Mode
  
  FEATURE 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 Modes
  A 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:
  
  ReadWriteOnce
  the volume can be mounted as read-write by a single node. ReadWriteOnce access
  mode still can allow multiple pods to access the volume when the pods are
  running on the same node. For single pod access, please see ReadWriteOncePod.
  ReadOnlyMany
  the volume can be mounted as read-only by many nodes.
  ReadWriteMany
  the volume can be mounted as read-write by many nodes.
  ReadWriteOncePod
  
  FEATURE STATE: Kubernetes v1.29 [stable]
  
  the volume can be mounted as read-write by a single Pod. Use ReadWriteOncePod
  access mode if you want to ensure that only one pod across the whole cluster can
  read that PVC or write to it.
  
  Note:The ReadWriteOncePod access mode is only supported for
  CSI volumes and Kubernetes version
  1.22+. To use this feature you will need to update the following
  CSI sidecars
  to these versions or greater:
  
  csi-provisioner:v3.0.0+
  csi-attacher:v3.3.0+
  csi-resizer:v1.3.0+
  
  In the CLI, the access modes are abbreviated to:
  
  RWO - ReadWriteOnce
  ROX - ReadOnlyMany
  RWX - ReadWriteMany
  RWOP - ReadWriteOncePod
  
  Note:Kubernetes uses volume access modes to match PersistentVolumeClaims and PersistentVolumes.
  In some cases, the volume access modes also constrain where the PersistentVolume can be mounted.
  Volume access modes do not enforce write protection once the storage has been mounted.
  Even if the access modes are specified as ReadWriteOnce, ReadOnlyMany, or ReadWriteMany,
  they don't set any constraints on the volume. For example, even if a PersistentVolume is
  created as ReadOnlyMany, it is no guarantee that it will be read-only. If the access modes
  are specified as ReadWriteOncePod, the volume is constrained and can be mounted on only a single Pod.
  
  Important! A volume can only be mounted using one access mode at a time,
  even if it supports many.
  
  Volume Plugin
  ReadWriteOnce
  ReadOnlyMany
  ReadWriteMany
  ReadWriteOncePod
  
  AzureFile
  ✓
  ✓
  ✓
  -
  
  CephFS
  ✓
  ✓
  ✓
  -
  
  CSI
  depends on the driver
  depends on the driver
  depends on the driver
  depends on the driver
  
  FC
  ✓
  ✓
  -
  -
  
  FlexVolume
  ✓
  ✓
  depends on the driver
  -
  
  HostPath
  ✓
  -
  -
  -
  
  iSCSI
  ✓
  ✓
  -
  -
  
  NFS
  ✓
  ✓
  ✓
  -
  
  RBD
  ✓
  ✓
  -
  -
  
  VsphereVolume
  ✓
  -
  - (works when Pods are collocated)
  -
  
  PortworxVolume
  ✓
  -
  ✓
  -
  
  Class
  A PV can have a class, which is specified by setting the
  storageClassName attribute to the name of a
  StorageClass.
  A PV of a particular class can only be bound to PVCs requesting
  that class. A PV with no storageClassName has no class and can only be bound
  to PVCs that request no particular class.
  In the past, the annotation volume.beta.kubernetes.io/storage-class was used instead
  of the storageClassName attribute. This annotation is still working; however,
  it will become fully deprecated in a future Kubernetes release.
  Reclaim Policy
  Current reclaim policies are:
  
  Retain -- manual reclamation
  Recycle -- basic scrub (rm -rf /thevolume/*)
  Delete -- delete the volume
  
  For Kubernetes 1.30, only nfs and hostPath volume types support recycling.
  Mount Options
  A Kubernetes administrator can specify additional mount options for when a
  Persistent Volume is mounted on a node.
  Note:Not all Persistent Volume types support mount options.
  The following volume types support mount options:
  
  azureFile
  cephfs (deprecated in v1.28)
  cinder (deprecated in v1.18)
  iscsi
  nfs
  rbd (deprecated in v1.28)
  vsphereVolume
  
  Mount options are not validated. If a mount option is invalid, the mount fails.
  In the past, the annotation volume.beta.kubernetes.io/mount-options was used instead
  of the mountOptions attribute. This annotation is still working; however,
  it will become fully deprecated in a future Kubernetes release.
  Node Affinity
  Note:For most volume types, you do not need to set this field.
  You need to explicitly set this for local volumes.
  A PV can specify node affinity to define constraints that limit what nodes this
  volume can be accessed
  ```