Volumes
You can store app data in the containers where the apps are running, but this may cause some problems:
- When a container crashes,
kubelet
restarts 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 APIVolume
, 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. 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
Working with persistent volumes
You can work with Kubernetes persistent volumes by using the PersistentVolume
and 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.PersistentVolume
resources can be created by the Kubernetes cluster administrator or dynamically provisioned usingPersistentVolumeClaims
. -
PersistentVolumeClaim
(PVC) are used to specify thePersistentVolumes
in the pod specification, since you can't specifyPersistentVolumes
directly.PersistentVolumeClaim
objects request a specific size, access mode, and storage class for thePersistentVolume
object. If thePersistentVolume
that satisfies the request exists or can be provisioned, thePersistentVolumeClaim
is linked to the necessaryPersistentVolume
. The Kubernetes cluster mounts thePersistentVolumeClaim
as a volume for the pod.
Users often need PersistentVolumes
with different properties. Kubernetes cluster administrators can provide various PersistentVolumes
by using storage classes.
Alert
When deleting a Managed Service for Kubernetes cluster, Compute Cloud disks attached to PersistentVolumes
are not deleted automatically.
Modes for mounting persistent volumes
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 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.
Provisioning volumes
In Managed Service for Kubernetes, you can use PersistentVolumes
built on disks in Compute Cloud. You can set the disk type and other parameters using applicable storage classes.
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 Nebius AI disks.
To learn more about static volume provisioning using cloud disks, see Static volume provisioning.
Expanding 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:
- Make sure the
StorageClass
description containsallowVolumeExpansion: true
. - Delete the pod with the volume to be resized.
- Edit the
PersistentVolumeClaim
to request more space. - Wait for the volume to expand.
- Create a pod to mount the volume to.
To learn how to expand a volume, see Expanding a pod volume.
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
built on theyc-network-ssd
storage , the applicablePersistentVolume
and 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 thepersistentVolumeReclaimPolicy
in PersistentVolumeSpec . By default, theRetain
value is used for statically provisioned pods and the Compute Cloud disk is not 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