instruction: Create a Kubernetes configuration with Pod, StorageClass resources
output: ```dockerfile
  from all Nodes
  in the cluster, PersistentVolumes will be bound or provisioned without knowledge of the Pod's scheduling
  requirements. This may result in unschedulable Pods.A cluster administrator can address this issue by specifying the WaitForFirstConsumer mode which
  will delay the binding and provisioning of a PersistentVolume until a Pod using the PersistentVolumeClaim is created.
  PersistentVolumes will be selected or provisioned conforming to the topology that is
  specified by the Pod's scheduling constraints. These include, but are not limited to, resource
  requirements,
  node selectors,
  pod affinity and
  anti-affinity,
  and taints and tolerations.The following plugins support WaitForFirstConsumer with dynamic provisioning:CSI volumes, provided that the specific CSI driver supports thisThe following plugins support WaitForFirstConsumer with pre-created PersistentVolume binding:CSI volumes, provided that the specific CSI driver supports thislocalNote:If you choose to use WaitForFirstConsumer, do not use nodeName in the Pod spec
  to specify node affinity.
  If nodeName is used in this case, the scheduler will be bypassed and PVC will remain in pending state.Instead, you can use node selector for kubernetes.io/hostname:storage/storageclass/pod-volume-binding.yaml
  apiVersion: v1
  kind: Pod
  metadata:
   name: task-pv-pod
  spec:
   nodeSelector:
   kubernetes.io/hostname: kube-01
   volumes:
   - name: task-pv-storage
   persistentVolumeClaim:
   claimName: task-pv-claim
   containers:
   - name: task-pv-container
   image: nginx
   ports:
   - containerPort: 80
   name: "http-server"
   volumeMounts:
   - mountPath: "/usr/share/nginx/html"
   name: task-pv-storage
  Allowed topologiesWhen a cluster operator specifies the WaitForFirstConsumer volume binding mode, it is no longer necessary
  to restrict provisioning to specific topologies in most situations. However,
  if still required, allowedTopologies can be specified.This example demonstrates how to restrict the topology of provisioned volumes to specific
  zones and should be used as a replacement for the zone and zones parameters for the
  supported plugins.storage/storageclass/storageclass-topology.yaml
  apiVersion: storage.k8s.io/v1
  kind: StorageClass
  metadata:
   name: standard
  provisioner: example.com/example
  parameters:
   type: pd-standard
  volumeBindingMode: WaitForFirstConsumer
  allowedTopologies:
  - matchLabelExpressions:
   - key: topology.kubernetes.io/zone
   values:
   - us-central-1a
   - us-central-1b
  ParametersStorageClasses have parameters that describe volumes belonging to the storage
  class. Different parameters may be accepted depending on the provisioner.
  When a parameter is omitted, some default is used.There can be at most 512 parameters defined for a StorageClass.
  The total length of the parameters object including its keys and values cannot
  exceed 256 KiB.AWS EBSKubernetes 1.33 does not include a awsElasticBlockStore volume type.The AWSElasticBlockStore in-tree storage driver was deprecated in the Kubernetes v1.19 release
  and then removed entirely in the v1.27 release.The Kubernetes project suggests that you use the AWS EBS
  out-of-tree storage driver instead.Here is an example StorageClass for the AWS EBS CSI driver:storage/storageclass/storageclass-aws-ebs.yaml
  apiVersion: storage.k8s.io/v1
  kind: StorageClass
  metadata:
   name: ebs-sc
  provisioner: ebs.csi.aws.com
  volumeBindingMode: WaitForFirstConsumer
  parameters:
   csi.storage.k8s.io/fstype: xfs
   type: io1
   iopsPerGB: "50"
   encrypted: "true"
   tagSpecification_1: "key1=value1"
   tagSpecification_2: "key2=value2"
  allowedTopologies:
  - matchLabelExpressions:
   - key: topology.ebs.csi.aws.com/zone
   values:
   - us-east-2c
  tagSpecification: Tags with this prefix are applied to dynamically provisioned EBS volumes.AWS EFSTo configure AWS EFS storage, you can use the out-of-tree AWS_EFS_CSI_DRIVER.storage/storageclass/storageclass-aws-efs.yaml
  kind: StorageClass
  apiVersion: storage.k8s.io/v1
  metadata:
   name: efs-sc
  provisioner: efs.csi.aws.com
  parameters:
   provisioningMode: efs-ap
   fileSystemId: fs-92107410
   directoryPerms: "700"
  provisioningMode: The type of volume to be provisioned by Amazon EFS. Currently, only access point based provisioning is supported (efs-ap).fileSystemId: The file system under which the access point is created.directoryPerms: The directory permissions of the root directory created by the access point.For more details, refer to the AWS_EFS_CSI_Driver Dynamic Provisioning documentation.NFSTo configure NFS storage, you can use the in-tree driver or the
  NFS CSI driver for Kubernetes
  (recommended).storage/storageclass/storageclass-nfs.yaml
  apiVersion: storage.k8s.io/v1
  kind: StorageClass
  metadata:
   name: example-nfs
  provisioner: example.com/external-nfs
  parameters:
   server: nfs-server.example.com
   path: /share
   readOnly: "false"
  server: Server is the hostname or IP address of the NFS server.path: Path that is exported by the NFS server.readOnly: A flag indicating whether the storage will be mounted as read only (default false).Kubernetes doesn't include an internal NFS provisioner.
  You need to use an external provisioner to create a StorageClass for NFS.
  Here are some examples:NFS Ganesha server and external provisionerNFS subdir external provisionervSphereThere are two types of provisioners for vSphere storage classes:CSI provisioner: csi.vsphere.vmware.comvCP provisioner: kubernetes.io/vsphere-volumeIn-tree provisioners are deprecated.
  For more information on the CSI provisioner, see
  Kubernetes vSphere CSI Driver and
  vSphereVolume CSI migration.CSI ProvisionerThe vSphere CSI StorageClass provisioner works with Tanzu Kubernetes clusters.
  For an example, refer to the vSphere CSI repository.vCP ProvisionerThe following examples use the VMware Cloud Provider (vCP) StorageClass provisioner.Create a StorageClass with a user specified disk format.apiVersion: storage.k8s.io/v1
  kind: StorageClass
  metadata:
   name: fast
  provisioner: kubernetes.io/vsphere-volume
  parameters:
   diskformat: zeroedthick
  diskformat: thin, zeroedthick and eagerzeroedthick. Default: "thin".Create a StorageClass with a disk format on a user specified datastore.apiVersion: storage.k8s.io/v1
  kind: StorageClass
  metadata:
   name: fast
  provisioner: kubernetes.io/vsphere-volume
  parameters:
   diskformat: zeroedthick
   datastore: VSANDatastore
  datastore: The user can also specify the datastore in the StorageClass.
  The volume will be created on the datastore specified in the StorageClass,
  which in this case is VSANDatastore. This field is optional. If the
  datastore is not specified, then the volume will be created on the datastore
  specified in the vSphere config file used to initialize the vSphere Cloud
  Provider.Storage Policy Management inside kubernetesUsing existing vCenter SPBM policyOne of the most important features of vSphere for Storage Management is
  policy based Management. Storage Policy Based Management (SPBM) is a
  storage policy framework that provides a single unified control plane
  across a broad range of data services and storage solutions. SPBM enables
  vSphere administrators to overcome upfront storage provisioning challenges,
  such as capacity planning, differentiated service levels and managing
  capacity headroom.The SPBM policies can be specified in the StorageClass using the
  storagePolicyName parameter.Virtual SAN policy support inside KubernetesVsphere Infrastructure (VI) Admins will have the ability to specify custom
  Virtual SAN Storage Capabilities during dynamic volume provisioning. You
  can now define storage requirements, such as performance and availability,
  in the form of storage capabilities during dynamic volume provisioning.
  The storage capability requirements are converted into a Virtual SAN
  policy which are then pushed down to the Virtual SAN layer when a
  persistent volume (virtual disk) is being created. The virtual disk is
  distributed across the Virtual SAN datastore to meet the requirements.You can see Storage Policy Based Management for dynamic provisioning of volumes
  for more details on how to use storage policies for persistent volumes
  management.There are few
  vSphere examples
  which you try out for persistent volume management inside Kubernetes for vSphere.Ceph RBD (deprecated)Note:FEATURE STATE:
  Kubernetes v1.28 [deprecated]This internal provisioner of Ceph RBD is deprecated. Please use
  CephFS RBD CSI driver.storage/storageclass/storageclass-ceph-rbd.yaml
  apiVersion: storage.k8s.io/v1
  kind: StorageClass
  metadata:
   name: fast
  provisioner: kubernetes.io/rbd # This provisioner is deprecated
  parameters:
   monitors: 198.19.254.105:6789
   adminId: kube
   adminSecretName: ceph-secret
   adminSecretNamespace: kube-system
   pool: kube
   userId: kube
   userSecretName: ceph-secret-user
   userSecretNamespace: default
   fsType: ext4
   imageFormat: "2"
   imageFeatures: "layering"
  monitors: Ceph monitors, comma delimited. This parameter is required.adminId: Ceph client ID that is capable of creating images in the pool.
  Default is "admin".adminSecretName: Secret Name for adminId. This parameter is required.
  The provided secret must have type "kubernetes.io/rbd".adminSecretNamespace: The namespace for adminSecretName. Default is "default".pool: Ceph RBD pool. Default is "rbd".userId: Ceph client ID that is used to map the RBD image. Default is the
  same as adminId.userSecretName: The name of Ceph Secret for userId to map RBD image. It
  must exist in the same namespace as PVCs. This parameter is required.
  The provided secret must have type "kubernetes.io/rbd", for example created in this
  way:kubectl create secret generic ceph-secret --type="kubernetes.io/rbd" \
   --
  ```