What is Kubernetes Storage?
Storage has always been a challenge for IT practitioners, with issues like integrity, retention, replication and migration of large data sets. These challenges are not new, and with modern, decentralized systems based on containers, they haven’t gone away.
Kubernetes is the most popular orchestrator for containerized workloads. Because containers are ephemeral, they erase all stored data by default, causing major challenges for many types of workloads. However, Kubernetes provides several capabilities that help mitigate this problem, and support stateful workloads in a containerized environment.
Kubernetes handles all aspects of the container lifecycle, including creation, management, automation, load balancing, and hardware interfaces, as well as interfaces to storage devices. Kubernetes introduces the concept of Persistent Volumes, which exist independently of containers, survive even after containers shut down, and can be requested and consumed by containerized workloads.
In this article, you will learn:
- How Does Kubernetes Storage Work?
- Volumes
- Non-Persistent Storage
- Persistent Storage
- Persistent Volumes (PV) and Persistent Volume Claims (PVC)
- Deployments and Stateless Sets
- StorageClasses
- Volume Management in Kubernetes
- Kubernetes Storage Best Practices
- Persistent Volume Settings
- Resource Quotas for Namespaces
- Support High Performance with Quality of Service Definitions
- Kubernetes Storage with NetApp Cloud Volumes ONTAP
How Does Kubernetes Storage Work?
The Kubernetes storage architecture is based on Volumes as a central abstraction. Volumes can be persistent or non-persistent, and Kubernetes allows containers to request storage resources dynamically, using a mechanism called volume claims.
Volumes
Volumes are the basic entity containers use to access storage in Kubernetes. They can support any type of storage infrastructure, including local storage devices, NFS and cloud storage services. Developers can create their own storage plugins to support specific storage systems. Volumes can be accessed directly from pods or Persistent Volumes (defined below).
Non-Persistent Storage
By default, Kubernetes storage is temporary (non-persistent). Any storage defined as part of a container in a Kubernetes Pod, is held in the host’s temporary storage space, which exists as long as the pod exists, and is then removed. Container storage is portable, but not durable.
Persistent Storage
Kubernetes also supports a variety of persistent storage models, including files, block storage, object storage, and cloud services belonging to these and additional categories. Storage can also be defined as a data service, commonly a database.
Storage can be referenced directly from within a pod, but this violates the pod’s portability principles and is not recommended. Instead, pods should use Persistent Volumes and Persistent Volume Claims (PV/PVC) to define the storage requirements of their applications.
Persistent Volumes (PV) and Persistent Volume Claims (PVC)
PV and PVC separate storage implementations from functionality and allow pods to use storage in a portable way. It also separates users and applications from storage configuration requirements.
Administrators can define storage resources, together with their performance, capacity and cost parameters, in a PV. A PV also defines details like routes, IP addresses, credentials, and a lifecycle policy for the data. PVs are not portable between Kubernetes clusters.
A PVC, on the other hand, is used by users or developers to describe the storage required by the application. They are portable and can be moved together with an application. Kubernetes identifies the storage available in the defined PV, and if it matches the requirements in the PVC, binds the PVC to that storage.
The PVC can specify some or all of the storage parameters defined in the PV. If, for example, the PVC defines only capacity and storage tier, it can be bounded to a larger variety of PVs (any that meet those criteria).
Deployments and Stateless Sets
Kubernetes provides a construct called a deployment, which comprises several cloned pods, which share the same PVC. This can lead to stability issues. A better option is to run pods as stateless sets, which allows you to clone PVCs between containers.
StorageClasses
Kubernetes administrators can define StorageClasses and assign PVs to them. Each StorageClass represents a type of storage—for example, fast SSD storage vs regular magnetic drives or remote cloud storage. This allows a Kubernetes cluster to provision different types of storage depending on the changing requirements of its workload.
A StorageClass is a Kubernetes application programming interface (API) for setting storage parameters. It is a dynamic configuration method that creates new volumes on demand. The StorageClass specifies the name of the volume plugin used, an external provider if any, and a Container Storage Interface (CSI) driver, which allows containers to interact with storage devices.
