instruction: Explain Ephemeral Volumes
output: You are viewing documentation for Kubernetes version: v1.32
  Kubernetes v1.32 documentation is no longer actively maintained. The version you are currently viewing is a static snapshot. For up-to-date information, see the
  latest version.
  Ephemeral Volumes
  This document describes
  ephemeral volumes
  in Kubernetes. Familiarity
  with
  volumes
  is suggested, in
  particular PersistentVolumeClaim and PersistentVolume.
  Some applications need additional storage but don't care whether that
  data is stored persistently across restarts. For example, caching
  services are often limited by memory size and can move infrequently
  used data into storage that is slower than memory with little impact
  on overall performance.
  Other applications expect some read-only input data to be present in
  files, like configuration data or secret keys.
  Ephemeral volumes
  are designed for these use cases. Because volumes
  follow the Pod's lifetime and get created and deleted along with the
  Pod, Pods can be stopped and restarted without being limited to where
  some persistent volume is available.
  Ephemeral volumes are specified
  inline
  in the Pod spec, which
  simplifies application deployment and management.
  Types of ephemeral volumes
  Kubernetes supports several different kinds of ephemeral volumes for
  different purposes:
  emptyDir
  : empty at Pod startup,
  with storage coming locally from the kubelet base directory (usually
  the root disk) or RAM
  configMap
  downwardAPI
  secret
  : inject different
  kinds of Kubernetes data into a Pod
  image
  : allows mounting container image files or artifacts,
  directly to a Pod.
  CSI ephemeral volumes
  similar to the previous volume kinds, but provided by special
  drivers
  which specifically
  support this feature
  generic ephemeral volumes
  , which
  can be provided by all storage drivers that also support persistent volumes
  emptyDir
  configMap
  downwardAPI
  secret
  are provided as
  local ephemeral
  storage
  They are managed by kubelet on each node.
  CSI ephemeral volumes
  must
  be provided by third-party CSI storage
  drivers.
  Generic ephemeral volumes
  be provided by third-party CSI storage
  drivers, but also by any other storage driver that supports dynamic
  provisioning. Some CSI drivers are written specifically for CSI
  ephemeral volumes and do not support dynamic provisioning: those then
  cannot be used for generic ephemeral volumes.
  The advantage of using third-party drivers is that they can offer
  functionality that Kubernetes itself does not support, for example
  storage with different performance characteristics than the disk that
  is managed by kubelet, or injecting different data.
  CSI ephemeral volumes
  FEATURE STATE:
  Kubernetes v1.25 [stable]
  Note:
  CSI ephemeral volumes are only supported by a subset of CSI drivers.
  The Kubernetes CSI
  Drivers list
  shows which drivers support ephemeral volumes.
  Conceptually, CSI ephemeral volumes are similar to
  configMap
  downwardAPI
  secret
  volume types: the storage is managed locally on each
  node and is created together with other local resources after a Pod has been
  scheduled onto a node. Kubernetes has no concept of rescheduling Pods
  anymore at this stage. Volume creation has to be unlikely to fail,
  otherwise Pod startup gets stuck. In particular,
  storage capacity
  aware Pod scheduling
  supported for these volumes. They are currently also not covered by
  the storage resource usage limits of a Pod, because that is something
  that kubelet can only enforce for storage that it manages itself.
  Here's an example manifest for a Pod that uses CSI ephemeral storage:
  kind
  apiVersion
  metadata
  name
  my-csi-app
  spec
  containers
  name
  my-frontend
  image
  busybox:1.28
  volumeMounts
  mountPath
  "/data"
  name
  my-csi-inline-vol
  command
  "sleep"
  "1000000"
  volumes
  name
  my-csi-inline-vol
  driver
  inline.storage.kubernetes.io
  volumeAttributes
  volumeAttributes
  determine what volume is prepared by the
  driver. These attributes are specific to each driver and not
  standardized. See the documentation of each CSI driver for further
  instructions.
  CSI driver restrictions
  CSI ephemeral volumes allow users to provide
  volumeAttributes
  directly to the CSI driver as part of the Pod spec. A CSI driver
  allowing
  volumeAttributes
  that are typically restricted to
  administrators is NOT suitable for use in an inline ephemeral volume.
  For example, parameters that are normally defined in the StorageClass
  should not be exposed to users through the use of inline ephemeral volumes.
  Cluster administrators who need to restrict the CSI drivers that are
  allowed to be used as inline volumes within a Pod spec may do so by:
  Removing
  Ephemeral
  from
  volumeLifecycleModes
  in the CSIDriver spec, which prevents the
  driver from being used as an inline ephemeral volume.
  Using an
  admission webhook
  to restrict how this driver is used.
  Generic ephemeral volumes
  FEATURE STATE:
  Kubernetes v1.23 [stable]
  Generic ephemeral volumes are similar to
  emptyDir
  volumes in the
  sense that they provide a per-pod directory for scratch data that is
  usually empty after provisioning. But they may also have additional
  features:
  Storage can be local or network-attached.
  Volumes can have a fixed size that Pods are not able to exceed.
  Volumes may have some initial data, depending on the driver and
  parameters.
  Typical operations on volumes are supported assuming that the driver
  supports them, including
  snapshotting
  cloning
  resizing
  storage capacity tracking
  Example:
  kind
  apiVersion
  metadata
  name
  my-app
  spec
  containers
  name
  my-frontend
  image
  busybox:1.28
  volumeMounts
  mountPath
  "/scratch"
  name
  scratch-volume
  command
  "sleep"
  "1000000"
  volumes
  name
  scratch-volume
  ephemeral
  volumeClaimTemplate
  metadata
  labels
  type
  my-frontend-volume
  spec
  accessModes
  "ReadWriteOnce"
  storageClassName
  "scratch-storage-class"
  resources
  requests
  storage
  Lifecycle and PersistentVolumeClaim
  The key design idea is that the
  parameters for a volume claim
  are allowed inside a volume source of the Pod. Labels, annotations and
  the whole set of fields for a PersistentVolumeClaim are supported. When such a Pod gets
  created, the ephemeral volume controller then creates an actual PersistentVolumeClaim
  object in the same namespace as the Pod and ensures that the PersistentVolumeClaim
  gets deleted when the Pod gets deleted.
  That triggers volume binding and/or provisioning, either immediately if
  StorageClass
  uses immediate volume binding or when the Pod is
  tentatively scheduled onto a node (
  WaitForFirstConsumer
  volume
  binding mode). The latter is recommended for generic ephemeral volumes
  because then the scheduler is free to choose a suitable node for
  the Pod. With immediate binding, the scheduler is forced to select a node that has
  access to the volume once it is available.
  In terms of
  resource ownership
  a Pod that has generic ephemeral storage is the owner of the PersistentVolumeClaim(s)
  that provide that ephemeral storage. When the Pod is deleted,
  the Kubernetes garbage collector deletes the PVC, which then usually
  triggers deletion of the volume because the default reclaim policy of
  storage classes is to delete volumes. You can create quasi-ephemeral local storage
  using a StorageClass with a reclaim policy of
  retain
  : the storage outlives the Pod,
  and in this case you need to ensure that volume clean up happens separately.
  While these PVCs exist, they can be used like any other PVC. In
  particular, they can be referenced as data source in volume cloning or
  snapshotting. The PVC object also holds the current status of the
  volume.
  PersistentVolumeClaim naming
  Naming of the automatically created PVCs is deterministic: the name is
  a combination of the Pod name and volume name, with a hyphen (
  ) in the
  middle. In the example above, the PVC name will be
  my-app-scratch-volume
  . This deterministic naming makes it easier to
  interact with the PVC because one does not have to search for it once
  the Pod name and volume name are known.
  The deterministic naming also introduces a potential conflict between different
  Pods (a Pod "pod-a" with volume "scratch" and another Pod with name
  "pod" and volume "a-scratch" both end up with the same PVC name
  "pod-a-scratch") and between Pods and manually created PVCs.
  Such conflicts are detected: a PVC is only used for an ephemeral
  volume if it was created for the Pod. This check is based on the
  ownership relationship. An existing PVC is not overwritten or
  modified. But this does not resolve the conflict because without the
  right PVC, the Pod cannot start.
  Caution:
  Take care when naming Pods and volumes inside the
  same namespace, so that these conflicts can't occur.
  Security
  Using generic ephemeral volumes allows users to create PVCs indirectly
  if they can create Pods, even if they do not have permission to create PVCs directly.
  Cluster administrators must be aware of this. If this does not fit their security model,
  they should use an
  admission webhook
  that rejects objects like Pods that have a generic ephemeral volume.
  The normal
  namespace quota for PVCs
  still applies, so even if users are allowed to use this new mechanism, they cannot use
  it to circumvent other policies.
  What's next
  Ephemeral volumes managed by kubelet
  local ephemeral storage
  CSI ephemeral volumes
  For more information on the design, see the
  Ephemeral Inline CSI volumes KEP
  For more information on further development of this feature, see the
  enhancement tracking issue #596
  Generic ephemeral volumes
  For more information on the design, see the
  Generic ephemeral inline volumes KEP
  Was this page helpful?
  Thanks for the feedback. If you have a specific, answerable question about how to use Kubernetes, ask it on
  Stack Overflow
  Open an issue in the
  GitHub Repository
  if you want to
  report a problem
  suggest an improvement
  Last modified September 14, 2024 at 12:01 AM PST:
  Update ephemeral-volumes.md (f04a552825)