Kubernetes storage enables administrators to maintain both persistent and non-persistent data in a cluster, supporting the creation and allocation of dynamic storage resources that are suitable for various types of applications. Understanding how storage works in Kubernetes – and the different components of a Kubernetes storage system – is essential for proper management of your Kubernetes environment.
Kasten by Veeam recently released its Gorilla Guide to Storage and Applications in Kubernetes, which describes how the Kubernetes storage system is architected, and how it can be leveraged to implement sound data protection practices. This post summarizes some key points explored in the Guide.
Understanding the Container Storage Interface (CSI)
The CSI is a standard for exposing file and block storage systems with Kubernetes. This interface provides a way for storage providers to create plugins that allow for the use of different storage systems within Kubernetes managed volumes. When a CSI storage plugin is installed, the corresponding storage system can be made available using Kubernetes storage mechanisms, including PersistentVolumes, PersistentVolumeClaims, and StorageClasses.
With CSI volumes, data can be preserved independently of Pods and made available to subsequently created pods. What’s more, CSI helps to solve the problem of how to share persistent data between Pods by enabling persistent storage volumes to be configured as temporary storage, long-term block storage, shared storage, and backup and recovery storage. CSI also enables the use of cloud storage systems within a Kubernetes cluster.
Different Types of Storage Volumes
Kubernetes uses a variety of storage abstractions to implement volumes with varying properties:
- Ephemeral Volumes: These storage mechanisms are associated with a Pod and follow its lifecycle. In other words, they’re created with the Pod and deleted when the Pod is deleted. Ephemeral volumes are handy for storing data temporarily, for example, a cache. Different types of ephemeral volumes include EmptyDir, Generic Ephemeral Volumes, ConfigMap, downwardAPI volumes and Secrets. More information about these distinct types of Ephemeral Volumes can be found in the Guide.
- PersistentVolumes: Not to be confused with “persistent volumes,” a generic term for a type of storage device, PersistentVolumes are storage units that are allocated in a cluster and do not follow the Pod’s lifecycle. They’re used to keep data available for applications and services running in a cluster. Pods use PersistentVolumeClaims to access data stored on PersistentVolumes. Once a process on a PersistentVolume completes, the unit may be retained, recycled, or deleted. There are multiple access modes, including ReadWriteOnce, ReadWriteMany, ReadOnlyMany or ReadWriteOncePod.
- ProjectedVolumes: These storage units map one or more existing volume sources to the same directory and are often used with Secrets, downward APIs, configMaps and serviceAccountTokens.
VolumeSnapshots and Backups
Protecting your Kubernetes data and apps is critical, particularly as Ransomware and other attacks against Kubernetes environments are on the rise. Snapshots help to address this critical need. Supported only on CSI storage volumes, Snapshots are used to create backups of storage volumes, to protect Kubernetes data and applications. Snapshots can be pre-provisioned by administrators or dynamically provisioned from a PersistentVolumeClaim.
Using Kubernetes storage services such as snapshots, Kasten K10 by Veeam can back up and restore Kubernetes data with minimal DevOps overhead. This comes in handy when something happens to the data, for example, if data is deleted accidentally or intentionally, or if an application damages or destroys it.
To understand how this works, and to read an example of a failure scenario and how Kasten K10 backups can be used to restore applications that have been deleted or exist within the cluster at the time of recovery, download the full guide.