You can store app data in the containers where the apps are running, but this may cause some problems:
- When a container crashes,
kubeletrestarts it, but files are lost because the container starts clean.
- Other containers running in the same pod can't access data in the container.
We can solve these problems using Kubernetes volumes.
Volumes are stores shared by objects from different containers deployed in one or more pods. In the pod specification, users set the volumes to be included in the pod and the path that containers should mount them to.
To handle volumes, Kubernetes operates with the following Kubernetes API objects:
Volumes are classified by their life cycle:
- Temporary (
Volume) volumes have the same lifetime as the pods that contain them. These volumes are created along with the pod and saved when the container is restarted. When the pod is stopped or deleted, its volumes are destroyed.
- Persistent volumes (
PersistentVolume) have their own life cycle. The data in these volumes is preserved when the pod is deleted. The volume can be unmounted to move the data to another pod or node, for example.
There are different kinds of temporary and persistent volumes, depending on the storage. Read about the volume types that Kubernetes supports.
Working with persistent volumes
You can work with Kubernetes persistent volumes by using the
PersistentVolumeClaim API objects.
PersistentVolumes(PV) are Kubernetes cluster resources that exist independently of pods. This means that the disk and data provided in the PV continue to exist when you change the cluster and delete or re-create the pods.
PersistentVolumeresources can be created by the Kubernetes cluster administrator or dynamically provisioned using
PersistentVolumeClaims(PVC) are used to specify the
PersistentVolumesin the pod specification, since you can't specify
PersistentVolumeClaimsrequest a specific size, access mode, and storage class for the
PersistentVolume. If the
PersistentVolumethat satisfies the request exists or can be provisioned, the
PersistentVolumeClaimis linked to the necessary
PersistentVolume. The Kubernetes cluster mounts the
PersistentVolumeClaimas a volume for the pod.
Users often need
PersistentVolumes with different properties. Kubernetes cluster administrators can provide various
PersistentVolumes by using storage classes.
Modes for mounting persistent volumes
Kubernetes supports two
volumeModes for mounting
Filesystem (with a filesystem) and
Block (without a filesystem).
volumeMode parameter is omitted,
Filesystem is the default mode used.
A volume with a filesystem
If you specify
volumeMode: Filesystem in a
PersistentVolumeClaim, Kubernetes creates a filesystem on a block device before mounting it to a pod for the first time.
To learn how to provision a volume pod in
volumeMode: Filesystem, see Dynamic volume provisioning.
A volume without a filesystem
You can set
volumeMode: Block to mount a volume as block storage without creating a filesystem on it. The application running in the pod with this volume must know how to handle a storage device without a file system.
To learn how to provision a volume pod in
volumeMode: Block, see Mounting a volume in Block mode.
Compute Cloud disks are created in a specific availability zone. This affects where pods can be restarted.
When you delete a Kubernetes cluster,
PersistentVolumeClaims and Compute Cloud disks for dynamically and statically created
PersistentVolumes aren't deleted automatically.
Dynamic volume provisioning
In most cases, you don't need to create
PersistentVolumes or Compute Cloud disks manually. Instead, you can create your
PersistentVolumeClaims, and Kubernetes will automatically provision the relevant
PersistentVolume object and create a disk.
To learn how to dynamically provision a volume, see Dynamic volume provisioning.
Static volume provisioning
In addition to creating new disks for provisioning
PersistentVolumes, you can use existing Yandex.Cloud disks.
To learn more about static volume provisioning using cloud disks, see Static volume provisioning.
You can expand a Kubernetes volume after creating it. You can only resize a volume when the pod with this volume is no longer running.
To expand a volume:
- Make sure the
- Delete the pod with the volume to be resized.
- Edit the
PersistentVolumeClaimto request more space.
- Wait for the volume to expand.
- Create a pod to mount the volume to.
For information about how to expand a volume, see Expanding a volume.
Depending on the
PersistentVolumeClaim settings, volumes and disks can be deleted automatically or manually.
For dynamically provisioned volumes: after removing a
PersistentVolumeClaimbuilt on the
yc-network-ssdstorage classes, the applicable
PersistentVolumeand Compute Cloud disk are deleted.
For statically provisioned volumes: you can specify whether to delete the Compute Cloud disk when deleting the
PersistentVolumeClaim. To do this, use the
persistentVolumeReclaimPolicyparameter in the PersistentVolumeSpec. By default, the
Retainvalue is used for statically provisioned pods and the Compute Cloud disk is not deleted.
Learn more about volumes in the Kubernetes documentation.