[Yandex Cloud documentation](../../index.md) > [Yandex Managed Service for Kubernetes](../index.md) > [Concepts](index.md) > Using Kubernetes API objects > Volume

# Volume

You can store container application data directly in the containers 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 on the same [pod](index.md#pod).

We can fix these issues 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 work with volumes, Kubernetes uses the following [Kubernetes API](https://kubernetes.io/docs/reference/kubernetes-api/) objects: `Volume`, `PersistentVolume`, `PersistentVolumeClaim`, and `StorageClass`.

Volumes are classified by their lifecycle:
* Temporary volumes (`Volume`) have the same lifetime as the pods that contain them. These volumes are created along with the pod and retained when the container is restarted. When the pod is stopped or deleted, its volumes are destroyed.
* Persistent volumes (`PersistentVolume`) have their own lifecycle. The data in these volumes is retained when the pod is deleted. You can unmount a volume, e.g., to migrate data to another pod or [Managed Service for Kubernetes](index.md#node-group) node.

There are different kinds of temporary and persistent volumes, depending on the storage. Check out the [volume types](https://kubernetes.io/docs/concepts/storage/volumes/#types-of-volumes) that Kubernetes supports.

## Working with persistent volumes {#persistent-volume}


You operate Kubernetes persistent volumes with the help of the `PersistentVolume` and `PersistentVolumeClaim` API objects.
* `PersistentVolumes` (PVs) are [Managed Service for Kubernetes](index.md#kubernetes-cluster) cluster resources that exist independently of pods. This means that the [disk](../../compute/concepts/disk.md) 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 a `PersistentVolume` can be dynamically provisioned with the help of `PersistentVolumeClaims` or created beforehand by the Managed Service for Kubernetes cluster administrator.
* `PersistentVolumeClaim` (PVC) objects are used to specify `PersistentVolumes` in the pod specification because `PersistentVolumes` cannot be specified directly.

  `PersistentVolumeClaim` objects request a specific size, access mode, and storage class for a `PersistentVolume`. If a `PersistentVolume` that matches 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](../operations/volumes/manage-storage-class.md).

{% note alert %}

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

{% endnote %}

## Persistent volume mounting modes {#volume-mode}

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

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

### Volume with a file system {#filesystem}

You can specify `volumeMode: Filesystem` in a `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](../operations/volumes/dynamic-create-pv.md).

### Volume without a file system {#block}

You can set `volumeMode: Block` to mount a volume as a block storage without creating a file system. The application running on the pod with this volume must know how to work with 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](../operations/volumes/mode-block.md).

## Provisioning volumes {#provisioning-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 [storage classes](../operations/volumes/manage-storage-class.md).

The following [disk types](../../compute/concepts/disk.md##disks-types) are available in Managed Service for Kubernetes: {#disks-types}

* 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.

{% note alert %}

Compute Cloud disks are created in a specific [availability zone](../../overview/concepts/geo-scope.md). This affects where pods can be restarted.

{% endnote %}

### Dynamic volume provisioning {#dynamic-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` and create a disk.

Learn how to dynamically provision a volume in [Dynamic volume provisioning](../operations/volumes/dynamic-create-pv.md).

### Static volume provisioning {#static-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](../operations/volumes/static-create-pv.md).

## Expanding volumes {#volume-expansion}

Managed Service for Kubernetes supports online volume expansion with `PersistentVolumeClaim` which does not require restarting the pods that are using the volumes.

For more information, see [Expanding a volume for pods](../operations/volumes/volume-expansion.md).

## Deleting volumes {#deleting-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 `yc-network-hdd` or `yc-network-ssd`, the relevant `PersistentVolume` and Compute Cloud disk **will be deleted**.
* For statically provisioned volumes, the [PersistentVolumeSpec](https://kubernetes.io/docs/reference/kubernetes-api/config-and-storage-resources/persistent-volume-v1/#PersistentVolumeSpec) specification always uses `persistentVolumeReclaimPolicy: Retain`, and the Compute Cloud disk **is not deleted** when deleting a `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 [this Kubernetes guide](https://kubernetes.io/docs/concepts/storage/persistent-volumes/).

## Using encrypted disks {#encrypted-disks}

Managed Service for Kubernetes supports the use of Compute Cloud disks [encrypted](../../compute/concepts/encryption.md) with custom Yandex Key Management Service [symmetric keys](../../kms/concepts/key.md) for persistent volumes.

{% note info %}

To use encrypted disks, the [cloud service account](index.md#service-accounts) attached to your Managed Service for Kubernetes cluster must have the `kms.keys.encrypterDecrypter` [role](../../kms/security/index.md#kms-keys-encrypterDecrypter) for the key or folder.

{% endnote %}

For [static volume provisioning](#static-provisioning), you can use an existing encrypted disk in the same way as a regular Compute Cloud disk.

For [dynamic volume provisioning](#dynamic-provisioning), you will need to create a new `StorageClass` and specify the symmetric key ID in the `parameters:kmsKeyId` field.

Here is a manifest for an encrypted storage class:

```yaml
kind: StorageClass
apiVersion: storage.k8s.io/v1
metadata:
  name: <storage_class_name>
provisioner: disk-csi-driver.mks.ycloud.io
volumeBindingMode: WaitForFirstConsumer
parameters:
  type: <disk_type>
  csi.storage.k8s.io/fstype: ext4
  kmsKeyId: <symmetric_key_ID>
allowVolumeExpansion: true
reclaimPolicy: Delete
```

Where:
* `metadata:name`: Any storage class name.
* `parameters:type`: [Disk type](volume.md#disks-types) in Compute Cloud. The possible values are:
  * `network-ssd`: Network SSD.
  * `network-hdd`: Network HDD.
  * `network-ssd-nonreplicated`: Non-replicated SSD.
  * `network-ssd-io-m3`: Ultra high-speed network storage with three replicas (SSD).
* `parameters:kmsKeyId`: Symmetric key ID.

For more information on using encrypted disks, see [Using encrypted disks for persistent volumes](../operations/volumes/encrypted-disks.md).

## Use cases {#examples}

* [Backing up a Managed Service for Kubernetes cluster to Object Storage](../tutorials/kubernetes-backup.md)