instruction: Create a Kubernetes configuration with Pod, PersistentVolume resources
output: ```dockerfile
  from as many Pods as you need. Unfortunately,
  iSCSI volumes can only be mounted by a single consumer in read-write mode.
  Simultaneous writers are not allowed.
  See the iSCSI example for more details.
  local
  A local volume represents a mounted local storage device such as a disk,
  partition or directory.
  Local volumes can only be used as a statically created PersistentVolume. Dynamic
  provisioning is not supported.
  Compared to hostPath volumes, local volumes are used in a durable and
  portable manner without manually scheduling pods to nodes. The system is aware
  of the volume's node constraints by looking at the node affinity on the PersistentVolume.
  However, local volumes are subject to the availability of the underlying
  node and are not suitable for all applications. If a node becomes unhealthy,
  then the local volume becomes inaccessible by the pod. The pod using this volume
  is unable to run. Applications using local volumes must be able to tolerate this
  reduced availability, as well as potential data loss, depending on the
  durability characteristics of the underlying disk.
  The following example shows a PersistentVolume using a local volume and
  nodeAffinity:
  apiVersion: v1
  kind: PersistentVolume
  metadata:
   name: example-pv
  spec:
   capacity:
   storage: 100Gi
   volumeMode: Filesystem
   accessModes:
   - ReadWriteOnce
   persistentVolumeReclaimPolicy: Delete
   storageClassName: local-storage
   local:
   path: /mnt/disks/ssd1
   nodeAffinity:
   required:
   nodeSelectorTerms:
   - matchExpressions:
   - key: kubernetes.io/hostname
   operator: In
   values:
   - example-node
  You must set a PersistentVolume nodeAffinity when using local volumes.
  The Kubernetes scheduler uses the PersistentVolume nodeAffinity to schedule
  these Pods to the correct node.
  PersistentVolume volumeMode can be set to "Block" (instead of the default
  value "Filesystem") to expose the local volume as a raw block device.
  When using local volumes, it is recommended to create a StorageClass with
  volumeBindingMode set to WaitForFirstConsumer. For more details, see the
  local StorageClass example.
  Delaying volume binding ensures that the PersistentVolumeClaim binding decision
  will also be evaluated with any other node constraints the Pod may have,
  such as node resource requirements, node selectors, Pod affinity, and Pod anti-affinity.
  An external static provisioner can be run separately for improved management of
  the local volume lifecycle. Note that this provisioner does not support dynamic
  provisioning yet. For an example on how to run an external local provisioner,
  see the local volume provisioner user
  guide.
  
  Note: The local PersistentVolume requires manual cleanup and deletion by the
  user if the external static provisioner is not used to manage the volume
  lifecycle.
  
  nfs
  An nfs volume allows an existing NFS (Network File System) share to be
  mounted into a Pod. Unlike emptyDir, which is erased when a Pod is
  removed, the contents of an nfs volume are preserved and the volume is merely
  unmounted. This means that an NFS volume can be pre-populated with data, and
  that data can be shared between pods. NFS can be mounted by multiple
  writers simultaneously.
  apiVersion: v1
  kind: Pod
  metadata:
   name: test-pd
  spec:
   containers:
   - image: registry.k8s.io/test-webserver
   name: test-container
   volumeMounts:
   - mountPath: /my-nfs-data
   name: test-volume
   volumes:
   - name: test-volume
   nfs:
   server: my-nfs-server.example.com
   path: /my-nfs-volume
   readOnly: true
  
  Note: You must have your own NFS server running with the share exported before you can use it.
  Also note that you can't specify NFS mount options in a Pod spec. You can either set mount options server-side or
  use /etc/nfsmount.conf.
  You can also mount NFS volumes via PersistentVolumes which do allow you to set mount options.
  
  See the NFS example
  for an example of mounting NFS volumes with PersistentVolumes.
  persistentVolumeClaim
  A persistentVolumeClaim volume is used to mount a
  PersistentVolume into a Pod. PersistentVolumeClaims
  are a way for users to "claim" durable storage (such as an iSCSI volume)
  without knowing the details of the particular cloud environment.
  See the information about PersistentVolumes for more
  details.
  portworxVolume (deprecated)
  
  FEATURE STATE: Kubernetes v1.25 [deprecated]
  
  A portworxVolume is an elastic block storage layer that runs hyperconverged with
  Kubernetes. Portworx fingerprints storage
  in a server, tiers based on capabilities, and aggregates capacity across multiple servers.
  Portworx runs in-guest in virtual machines or on bare metal Linux nodes.
  A portworxVolume can be dynamically created through Kubernetes or it can also
  be pre-provisioned and referenced inside a Pod.
  Here is an example Pod referencing a pre-provisioned Portworx volume:
  apiVersion: v1
  kind: Pod
  metadata:
   name: test-portworx-volume-pod
  spec:
   containers:
   - image: registry.k8s.io/test-webserver
   name: test-container
   volumeMounts:
   - mountPath: /mnt
   name: pxvol
   volumes:
   - name: pxvol
   # This Portworx volume must already exist.
   portworxVolume:
   volumeID: "pxvol"
   fsType: "<fs-type>"
  
  Note: Make sure you have an existing PortworxVolume with name pxvol
  before using it in the Pod.
  
  For more details, see the Portworx volume examples.
  Portworx CSI migration
  
  FEATURE STATE: Kubernetes v1.25 [beta]
  
  The CSIMigration feature for Portworx has been added but disabled by default in Kubernetes 1.23 since it's in alpha state.
  It has been beta now since v1.25 but it is still turned off by default.
  It redirects all plugin operations
  ```