instruction: Create a Kubernetes configuration with StorageClass, Pod, PersistentVolumeClaim, PersistentVolume resources
output: ```dockerfile
  from Kubernetes, as well as the associated
  storage asset in the external infrastructure. Volumes that were dynamically provisioned
  inherit the reclaim policy of their StorageClass, which
  defaults to Delete. The administrator should configure the StorageClass
  according to users' expectations; otherwise, the PV must be edited or
  patched after it is created. See
  Change the Reclaim Policy of a PersistentVolume.
  Recycle
  Warning:The Recycle reclaim policy is deprecated. Instead, the recommended approach
  is to use dynamic provisioning.
  If supported by the underlying volume plugin, the Recycle reclaim policy performs
  a basic scrub (rm -rf /thevolume/*) on the volume and makes it available again for a new claim.
  However, an administrator can configure a custom recycler Pod template using
  the Kubernetes controller manager command line arguments as described in the
  reference.
  The custom recycler Pod template must contain a volumes specification, as
  shown in the example below:
  apiVersion: v1
  kind: Pod
  metadata:
   name: pv-recycler
   namespace: default
  spec:
   restartPolicy: Never
   volumes:
   - name: vol
   hostPath:
   path: /any/path/it/will/be/replaced
   containers:
   - name: pv-recycler
   image: "registry.k8s.io/busybox"
   command: ["/bin/sh", "-c", "test -e /scrub && rm -rf /scrub/..?* /scrub/.[!.]* /scrub/* && test -z \"$(ls -A /scrub)\" || exit 1"]
   volumeMounts:
   - name: vol
   mountPath: /scrub
  However, the particular path specified in the custom recycler Pod template in the
  volumes part is replaced with the particular path of the volume that is being recycled.
  PersistentVolume deletion protection finalizer
  
  FEATURE STATE: Kubernetes v1.23 [alpha]
  
  Finalizers can be added on a PersistentVolume to ensure that PersistentVolumes
  having Delete reclaim policy are deleted only after the backing storage are deleted.
  The newly introduced finalizers kubernetes.io/pv-controller and
  external-provisioner.volume.kubernetes.io/finalizer
  are only added to dynamically provisioned volumes.
  The finalizer kubernetes.io/pv-controller is added to in-tree plugin volumes.
  The following is an example
  kubectl describe pv pvc-74a498d6-3929-47e8-8c02-078c1ece4d78
  Name: pvc-74a498d6-3929-47e8-8c02-078c1ece4d78
  Labels: <none>
  Annotations: kubernetes.io/createdby: vsphere-volume-dynamic-provisioner
   pv.kubernetes.io/bound-by-controller: yes
   pv.kubernetes.io/provisioned-by: kubernetes.io/vsphere-volume
  Finalizers: [kubernetes.io/pv-protection kubernetes.io/pv-controller]
  StorageClass: vcp-sc
  Status: Bound
  Claim: default/vcp-pvc-1
  Reclaim Policy: Delete
  Access Modes: RWO
  VolumeMode: Filesystem
  Capacity: 1Gi
  Node Affinity: <none>
  Message:
  Source:
   Type: vSphereVolume (a Persistent Disk resource in vSphere)
   VolumePath: [vsanDatastore] d49c4a62-166f-ce12-c464-020077ba5d46/kubernetes-dynamic-pvc-74a498d6-3929-47e8-8c02-078c1ece4d78.vmdk
   FSType: ext4
   StoragePolicyName: vSAN Default Storage Policy
  Events: <none>
  The finalizer external-provisioner.volume.kubernetes.io/finalizer is added for CSI volumes.
  The following is an example:
  Name: pvc-2f0bab97-85a8-4552-8044-eb8be45cf48d
  Labels: <none>
  Annotations: pv.kubernetes.io/provisioned-by: csi.vsphere.vmware.com
  Finalizers: [kubernetes.io/pv-protection external-provisioner.volume.kubernetes.io/finalizer]
  StorageClass: fast
  Status: Bound
  Claim: demo-app/nginx-logs
  Reclaim Policy: Delete
  Access Modes: RWO
  VolumeMode: Filesystem
  Capacity: 200Mi
  Node Affinity: <none>
  Message:
  Source:
   Type: CSI (a Container Storage Interface (CSI) volume source)
   Driver: csi.vsphere.vmware.com
   FSType: ext4
   VolumeHandle: 44830fa8-79b4-406b-8b58-621ba25353fd
   ReadOnly: false
   VolumeAttributes: storage.kubernetes.io/csiProvisionerIdentity=1648442357185-8081-csi.vsphere.vmware.com
   type=vSphere CNS Block Volume
  Events: <none>
  When the CSIMigration{provider} feature flag is enabled for a specific in-tree volume plugin,
  the kubernetes.io/pv-controller finalizer is replaced by the
  external-provisioner.volume.kubernetes.io/finalizer finalizer.
  Reserving a PersistentVolume
  The control plane can bind PersistentVolumeClaims to matching PersistentVolumes
  in the cluster. However, if you want a PVC to bind to a specific PV, you need to pre-bind them.
  By specifying a PersistentVolume in a PersistentVolumeClaim, you declare a binding
  between that specific PV and PVC. If the PersistentVolume exists and has not reserved
  PersistentVolumeClaims through its claimRef field, then the PersistentVolume and
  PersistentVolumeClaim will be bound.
  The binding happens regardless of some volume matching criteria, including node affinity.
  The control plane still checks that storage class,
  access modes, and requested storage size are valid.
  apiVersion: v1
  kind: PersistentVolumeClaim
  metadata:
   name: foo-pvc
   namespace: foo
  spec:
   storageClassName: "" # Empty string must be explicitly set otherwise default StorageClass will be set
   volumeName: foo-pv
   ...
  This method does not guarantee any binding privileges to the PersistentVolume.
  If other PersistentVolumeClaims could use the PV that you specify, you first
  need to reserve that storage volume. Specify the relevant PersistentVolumeClaim
  in the claimRef field of the PV so that other PVCs can not bind to it.
  apiVersion: v1
  kind: PersistentVolume
  metadata:
   name: foo-pv
  spec:
   storageClassName: ""
   claimRef:
   name: foo-pvc
   namespace: foo
   ...
  This is useful if you want to consume PersistentVolumes that have their persistentVolumeReclaimPolicy set
  to Retain, including cases where you are reusing an existing PV.
  Expanding Persistent Volumes Claims
  
  FEATURE STATE: Kubernetes v1.24 [stable]
  
  Support for expanding PersistentVolumeClaims (PVCs) is enabled by default. You can expand
  the following types of volumes:
  
  azureFile (deprecated)
  csi
  flexVolume (deprecated)
  rbd (deprecated)
  portworxVolume (deprecated)
  
  You can only expand a PVC if its storage class's allowVolumeExpansion field is set to true.
  apiVersion: storage.k8s.io/v1
  kind: StorageClass
  metadata:
   name: example-vol-default
  provisioner: vendor-name.example/magicstorage
  parameters:
   resturl: "http://192.168.10.100:8080"
   restuser: ""
   secretNamespace: ""
   secretName: ""
  allowVolumeExpansion: true
  To request a larger volume for a PVC, edit the PVC object and specify a larger
  size. This triggers expansion of the volume that backs the underlying PersistentVolume. A
  new PersistentVolume is never created to satisfy the claim. Instead, an existing volume is resized.
  Warning:Directly editing the size of a PersistentVolume can prevent an automatic resize of that volume.
  If you edit the capacity of a PersistentVolume, and then edit the .spec of a matching
  PersistentVolumeClaim to make the size of the PersistentVolumeClaim match the PersistentVolume,
  then no storage resize happens.
  The Kubernetes control plane will see that the desired state of both resources matches,
  conclude that the backing volume size has been manually
  increased and that no resize is necessary.
  CSI Volume expansion
  
  FEATURE STATE: Kubernetes v1.24 [stable]
  
  Support for expanding CSI volumes is enabled by default but it also requires a
  specific CSI driver to support volume expansion. Refer to documentation of the
  specific CSI driver for more information.
  Resizing a volume containing a file system
  You can only resize volumes containing a file system if the file system is XFS, Ext3, or Ext4.
  When a volume contains a file system, the file system is only resized when a new Pod is using
  the PersistentVolumeClaim in ReadWrite mode. File system expansion is either done when a Pod is starting up
  or when a Pod is running and the underlying file system supports online expansion.
  FlexVolumes (deprecated since Kubernetes v1.23) allow resize if the driver is configured with the
  RequiresFSResize capability to true. The FlexVolume can be resized on Pod restart.
  Resizing an in-use PersistentVolumeClaim
  
  FEATURE STATE: Kubernetes v1.24 [stable]
  
  In this case, you don't need to delete and recreate a Pod or deployment that is using an existing PVC.
  Any in-use PVC automatically becomes available to its Pod as soon as its file system has been expanded.
  This feature has no effect on PVCs that are not in use by a Pod or deployment. You must create a Pod that
  uses the PVC before the expansion can complete.
  Similar to other volume types - FlexVolume volumes can also be expanded when in-use by a Pod.
  Note:FlexVolume resize is possible only when the underlying driver supports resize.
  
  <h4 id="recovering-
  ```