Volume

You can store container application data in the containers themselves but this may cause some issues:

• When a container crashes, kubelet restarts it, but the files are lost because the container starts clean.
• The data in the container cannot be accessed by other containers running in the same pod.

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 process volumes, Kubernetes uses the following Kubernetes API objects: Volume, PersistentVolume, PersistentVolumeClaim, and StorageClass.

Volumes are classified according to their lifecycle:

• 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 a lifecycle of their own. 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 operate Kubernetes persistent volumes with the help of 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.

  The resources of PersistentVolume can be dynamically provisioned with the help of PersistentVolumeClaims or created beforehand by the Managed Service for Kubernetes cluster administrator.

• The PersistentVolumeClaim (PVC) objects are used to specify PersistentVolumes in the pod specification because PersistentVolumes cannot be specified directly.

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

Users often need PersistentVolumes with various properties. The Managed Service for Kubernetes cluster administrators can supply various PersistentVolumes thanks to storage classes.

Persistent volume mounting modesPersistent volume mounting modes

Managed Service for Kubernetes supports two persistent volume (PersistentVolume) mounting modes (volumeMode): with a filesystem (Filesystem) and without a filesystem (Block).

If volumeMode is not set, the default value is Filesystem.

Volume with a filesystemVolume with a filesystem

You can specify volumeMode: Filesystem in PersistentVolumeClaim, in which case Managed Service for Kubernetes will create a file system on the block storage 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.

Volume without a filesystemVolume without a filesystem

You can set volumeMode: Block to mount a volume as block storage without creating a file system. 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; SSD network block storage.
• Network HDD (network-hdd): Standard network drive; HDD network block storage.
• Non-replicated SSD (network-ssd-nonreplicated): Enhanced performance network drive 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 and Compute Cloud disks manually. Instead, you can create your PersistentVolumeClaim objects, 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 to provision PersistentVolumes, you can also 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 object 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 the PersistentVolumeClaim object based on yc-network-hdd or yc-network-ssd, the relevant PersistentVolume object and Compute Cloud disk will be deleted.
• For statically provisioned volumes, the PersistentVolumeSpec specification always uses persistentVolumeReclaimPolicy: Retain, 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 relevant Kubernetes guides.