instruction: Configure Kubernetes persistent volume storage with subPath
output: ```dockerfile
  from how it is consumed.
  To do this, we introduce two new API resources: PersistentVolume and PersistentVolumeClaim.A PersistentVolume (PV) is a piece of storage in the cluster that has been
  provisioned by an administrator or dynamically provisioned using
  Storage Classes. It is a resource in
  the cluster just like a node is a cluster resource. PVs are volume plugins like
  Volumes, but have a lifecycle independent of any individual Pod that uses the PV.
  This API object captures the details of the implementation of the storage, be that
  NFS, iSCSI, or a cloud-provider-specific storage system.A PersistentVolumeClaim (PVC) is a request for storage by a user. It is similar
  to a Pod. Pods consume node resources and PVCs consume PV resources. Pods can
  request specific levels of resources (CPU and Memory). Claims can request specific
  size and access modes (e.g., they can be mounted ReadWriteOnce, ReadOnlyMany,
  ReadWriteMany, or ReadWriteOncePod, see AccessModes).While PersistentVolumeClaims allow a user to consume abstract storage resources,
  it is common that users need PersistentVolumes with varying properties, such as
  performance, for different problems. Cluster administrators need to be able to
  offer a variety of PersistentVolumes that differ in more ways than size and access
  modes, without exposing users to the details of how those volumes are implemented.
  For these needs, there is the StorageClass resource.See the detailed walkthrough with working examples.Lifecycle of a volume and claimPVs are resources in the cluster. PVCs are requests for those resources and also act
  as claim checks to the resource. The interaction between PVs and PVCs follows this lifecycle:ProvisioningThere are two ways PVs may be provisioned: statically or dynamically.StaticA cluster administrator creates a number of PVs. They carry the details of the
  real storage, which is available for use by cluster users. They exist in the
  Kubernetes API and are available for consumption.DynamicWhen none of the static PVs the administrator created match a user's PersistentVolumeClaim,
  the cluster may try to dynamically provision a volume specially for the PVC.
  This provisioning is based on StorageClasses: the PVC must request a
  storage class and
  the administrator must have created and configured that class for dynamic
  provisioning to occur. Claims that request the class "" effectively disable
  dynamic provisioning for themselves.To enable dynamic storage provisioning based on storage class, the cluster administrator
  needs to enable the DefaultStorageClass
  admission controller
  on the API server. This can be done, for example, by ensuring that DefaultStorageClass is
  among the comma-delimited, ordered list of values for the --enable-admission-plugins flag of
  the API server component. For more information on API server command-line flags,
  check kube-apiserver documentation.BindingA user creates, or in the case of dynamic provisioning, has already created,
  a PersistentVolumeClaim with a specific amount of storage requested and with
  certain access modes. A control loop in the control plane watches for new PVCs, finds
  a matching PV (if possible), and binds them together. If a PV was dynamically
  provisioned for a new PVC, the loop will always bind that PV to the PVC. Otherwise,
  the user will always get at least what they asked for, but the volume may be in
  excess of what was requested. Once bound, PersistentVolumeClaim binds are exclusive,
  regardless of how they were bound. A PVC to PV binding is a one-to-one mapping,
  using a ClaimRef which is a bi-directional binding between the PersistentVolume
  and the PersistentVolumeClaim.Claims will remain unbound indefinitely if a matching volume does not exist.
  Claims will be bound as matching volumes become available. For example, a
  cluster provisioned with many 50Gi PVs would not match a PVC requesting 100Gi.
  The PVC can be bound when a 100Gi PV is added to the cluster.UsingPods use claims as volumes. The cluster inspects the claim to find the bound
  volume and mounts that volume for a Pod. For volumes that support multiple
  access modes, the user specifies which mode is desired when using their claim
  as a volume in a Pod.Once a user has a claim and that claim is bound, the bound PV belongs to the
  user for as long as they need it. Users schedule Pods and access their claimed
  PVs by including a persistentVolumeClaim section in a Pod's volumes block.
  See Claims As Volumes for more details on this.Storage Object in Use ProtectionThe purpose of the Storage Object in Use Protection feature is to ensure that
  PersistentVolumeClaims (PVCs) in active use by a Pod and PersistentVolume (PVs)
  that are bound to PVCs are not removed
  ```