instruction: Create a Kubernetes configuration with Pod, PersistentVolumeClaim, PersistentVolume resources
output: ```dockerfile
  from both matchLabels and matchExpressions, are
  ANDed together – they must all be satisfied in order to match.
  Class
  A claim can request a particular class by specifying the name of a
  StorageClass
  using the attribute storageClassName.
  Only PVs of the requested class, ones with the same storageClassName as the PVC, can
  be bound to the PVC.
  PVCs don't necessarily have to request a class. A PVC with its storageClassName set
  equal to "" is always interpreted to be requesting a PV with no class, so it
  can only be bound to PVs with no class (no annotation or one set equal to
  ""). A PVC with no storageClassName is not quite the same and is treated differently
  by the cluster, depending on whether the
  DefaultStorageClass admission plugin
  is turned on.
  
  If the admission plugin is turned on, the administrator may specify a
  default StorageClass. All PVCs that have no storageClassName can be bound only to
  PVs of that default. Specifying a default StorageClass is done by setting the
  annotation storageclass.kubernetes.io/is-default-class equal to true in
  a StorageClass object. If the administrator does not specify a default, the
  cluster responds to PVC creation as if the admission plugin were turned off. If more than one
  default StorageClass is specified, the newest default is used when the
  PVC is dynamically provisioned.
  If the admission plugin is turned off, there is no notion of a default
  StorageClass. All PVCs that have storageClassName set to "" can be
  bound only to PVs that have storageClassName also set to "".
  However, PVCs with missing storageClassName can be updated later once
  default StorageClass becomes available. If the PVC gets updated it will no
  longer bind to PVs that have storageClassName also set to "".
  
  See retroactive default StorageClass assignment for more details.
  Depending on installation method, a default StorageClass may be deployed
  to a Kubernetes cluster by addon manager during installation.
  When a PVC specifies a selector in addition to requesting a StorageClass,
  the requirements are ANDed together: only a PV of the requested class and with
  the requested labels may be bound to the PVC.
  Note:Currently, a PVC with a non-empty selector can't have a PV dynamically provisioned for it.
  In the past, the annotation volume.beta.kubernetes.io/storage-class was used instead
  of storageClassName attribute. This annotation is still working; however,
  it won't be supported in a future Kubernetes release.
  Retroactive default StorageClass assignment
  
  FEATURE STATE: Kubernetes v1.28 [stable]
  
  You can create a PersistentVolumeClaim without specifying a storageClassName
  for the new PVC, and you can do so even when no default StorageClass exists
  in your cluster. In this case, the new PVC creates as you defined it, and the
  storageClassName of that PVC remains unset until default becomes available.
  When a default StorageClass becomes available, the control plane identifies any
  existing PVCs without storageClassName. For the PVCs that either have an empty
  value for storageClassName or do not have this key, the control plane then
  updates those PVCs to set storageClassName to match the new default StorageClass.
  If you have an existing PVC where the storageClassName is "", and you configure
  a default StorageClass, then this PVC will not get updated.
  In order to keep binding to PVs with storageClassName set to ""
  (while a default StorageClass is present), you need to set the storageClassName
  of the associated PVC to "".
  This behavior helps administrators change default StorageClass by removing the
  old one first and then creating or setting another one. This brief window while
  there is no default causes PVCs without storageClassName created at that time
  to not have any default, but due to the retroactive default StorageClass
  assignment this way of changing defaults is safe.
  Claims As Volumes
  Pods access storage by using the claim as a volume. Claims must exist in the
  same namespace as the Pod using the claim. The cluster finds the claim in the
  Pod's namespace and uses it to get the PersistentVolume backing the claim.
  The volume is then mounted to the host and into the Pod.
  apiVersion: v1
  kind: Pod
  metadata:
   name: mypod
  spec:
   containers:
   - name: myfrontend
   image: nginx
   volumeMounts:
   - mountPath: "/var/www/html"
   name: mypd
   volumes:
   - name: mypd
   persistentVolumeClaim:
   claimName: myclaim
  A Note on Namespaces
  PersistentVolumes binds are exclusive, and since PersistentVolumeClaims are
  namespaced objects, mounting claims with "Many" modes (ROX, RWX) is only
  possible within one namespace.
  PersistentVolumes typed hostPath
  A hostPath PersistentVolume uses a file or directory on the Node to emulate
  network-attached storage. See
  an example of hostPath typed volume.
  Raw Block Volume Support
  
  FEATURE STATE: Kubernetes v1.18 [stable]
  
  The following volume plugins support raw block volumes, including dynamic provisioning where
  applicable:
  
  CSI
  FC (Fibre Channel)
  iSCSI
  Local volume
  OpenStack Cinder
  RBD (deprecated)
  RBD (Ceph Block Device; deprecated)
  VsphereVolume
  
  PersistentVolume using a Raw Block Volume
  apiVersion: v1
  kind: PersistentVolume
  metadata:
   name: block-pv
  spec:
   capacity:
   storage: 10Gi
   accessModes:
   - ReadWriteOnce
   volumeMode: Block
   persistentVolumeReclaimPolicy: Retain
   fc:
   targetWWNs: ["50060e801049cfd1"]
   lun: 0
   readOnly: false
  PersistentVolumeClaim requesting a Raw Block Volume
  apiVersion: v1
  kind: PersistentVolumeClaim
  metadata:
   name: block-pvc
  spec:
   accessModes:
   - ReadWriteOnce
   volumeMode: Block
   resources:
   requests:
   storage: 10Gi
  Pod specification adding Raw Block Device path in container
  apiVersion: v1
  kind: Pod
  metadata:
   name: pod-with-block-volume
  spec:
   containers:
   - name: fc-container
   image: fedora:26
   command: ["/bin/sh", "-c"]
   args: [ "tail -f /dev/" ]
   volumeDevices:
   - name: data
   devicePath: /dev/xvda
   volumes:
   - name: data
   persistentVolumeClaim:
   claimName: block-pvc
  
  Note:When adding a raw block device for a Pod, you specify the device path in the
  container instead of a mount path.
  Binding Block Volumes
  If a user requests a raw block volume by indicating this using the volumeMode
  field in the PersistentVolumeClaim spec, the binding rules differ slightly
  ```