Volumes

You can store application data in the containers where the applications are running, but this may cause issues:

• When a container crashes, kubelet restarts it, but files are lost because the container starts clean.
• Other containers running in the same pod cannot access data in the container.

We can solve these problems using Kubernetes volumes.

A volume is a storage for shared use of objects in different containers deployed within one or more pods. In the pod specification, users specify the volumes to contain the pod and the path for the containers to mount those volumes to.

To handle volumes, Kubernetes uses the following Kubernetes API objects: Volume, PersistentVolume, PersistentVolumeClaim, and StorageClass.

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. You can unmount a volume, for example, to move data to another pod or Managed Service for Kubernetes node.

There are different kinds of temporary and persistent volumes, depending on the storage. Check out the volume types that Kubernetes supports.

Working with persistent volumesWorking with persistent volumes

You can work with Kubernetes persistent volumes by using the PersistentVolume and PersistentVolumeClaim API objects.

• PersistentVolumes (PV) are Managed Service for 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 Managed Service for Kubernetes cluster and delete or recreate the pods.

  PersistentVolume resources can be created by the cluster Managed Service for Kubernetes administrator or dynamically provisioned using PersistentVolumeClaims.

• PersistentVolumeClaims (PVC) are used to specify the PersistentVolumes in the pod specification, since you cannot specify PersistentVolumes directly.

  PersistentVolumeClaim objects request a specific size, access mode, and storage class for the PersistentVolume object. If the PersistentVolume that satisfies the request exists or can be provisioned, the PersistentVolumeClaim is linked to the required PersistentVolume. The Managed Service for Kubernetes cluster mounts the PersistentVolumeClaim as a volume for the pod.

Users often need PersistentVolumes with different properties. Managed Service for Kubernetes cluster administrators can provide various PersistentVolumes by using storage classes.

Modes for mounting persistent volumesModes for mounting persistent volumes

Managed Service for Kubernetes supports two volumeModes for mounting PersistentVolumes: Filesystem (with a filesystem) and Block (without a filesystem).

If the volumeMode parameter is omitted, Filesystem is the default mode used.

A volume with a filesystemA volume with a filesystem

If you specify volumeMode: Filesystem in a PersistentVolumeClaim, Managed Service for 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 filesystemA 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.

Provisioning volumesProvisioning volumes

In Managed Service for Kubernetes, you can use PersistentVolumes based on Yandex Compute Cloud disks. You can set the disk type and other parameters using applicable storage classes.

The following disk types are available in Managed Service for Kubernetes:

• Network SSD (network-ssd): Fast network drive, which is an SSD based network block storage.
• Network HDD (network-hdd): Standard network drive, which is an HDD based network block storage.
• Non-replicated SSD (network-ssd-nonreplicated): Network drive with enhanced performance without redundancy.
• Ultra high-speed network storage with three replicas (SSD) (network-ssd-io-m3): High-performance SSD offering the same speed as network-ssd-nonreplicated, plus redundancy.

Dynamic volume provisioningDynamic volume provisioning

In most cases, you do not need to create PersistentVolumes or Compute Cloud disks manually. Instead, you can create your PersistentVolumeClaims, and Managed Service for 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 provisioningStatic 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.

Expanding volumesExpanding volumes

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:

1. Make sure the StorageClass description contains allowVolumeExpansion: true.
2. Delete the pod with the volume to be resized.
3. Edit the PersistentVolumeClaim to request more space.
4. Wait for the volume to expand.
5. Create a pod to mount the volume to.

To learn how to expand a volume, see Expanding a pod volume.

Deleting volumesDeleting volumes

Depending on the PersistentVolume and PersistentVolumeClaim settings, volumes and disks can be deleted automatically or manually.

• For dynamically provisioned volumes, after removing a PersistentVolumeClaim based on the yc-network-hdd or yc-network-ssd storage classes, the applicable PersistentVolume and Compute Cloud disk are deleted.
• For statically provisioned volumes, the PersistentVolumeSpec specification always uses the persistentVolumeReclaimPolicy: Retain parameter value and the Compute Cloud disk is not deleted when deleting PersistentVolumeClaim. If the Delete parameter value is set manually, the disk will not be deleted.

When deleting a Managed Service for Kubernetes cluster, Compute Cloud disks attached to PersistentVolumes are not deleted automatically.

Learn more about volumes in the Kubernetes documentation.