Fundamentals of Kubernetes Storage

Explore this Page

Overview of Kubernetes Storage

Kubernetes has introduced several enhancements to support stateful workloads by providing essential abstractions for platform administrators (or cluster administrators) and application developers. These abstractions ensure that various types of file and block storage - whether ephemeral or persistent, local or remote are available wherever a container is scheduled. They facilitate operations such as provisioning, attaching, mounting, unmounting, detaching, deleting volumes, managing storage capacity (including ephemeral storage usage and volume resizing), influencing container scheduling based on data availability, and performing generic storage operations such as snapshotting.

Kubernetes User Roles

There are two primary user roles in Kubernetes storage management:

Cluster Administrators

Cluster administrators, also known as Platform Site Reliability Engineers (SRE), are responsible for managing the Kubernetes cluster life cycle. They have full access to cluster resources and define policies and roles for other users.

Administrators install DataCore Puls8 and configure StorageClasses that will be used by application owners.

Application Owners

Application owners manage the life cycle of containerized applications and typically have restricted access to specific Kubernetes namespaces. While they can view storage-related objects such as StorageClasses, they cannot modify or delete them.

Application owners have full control over application resources within their namespace, such as Deployments, StatefulSets, ConfigMaps, and Persistent Volume Claims (PVC). Administrators can define granular access permissions using Kubernetes Role-Based Access Control (RBAC).

Kubernetes Cluster Design Considerations

Cluster administrators must collaborate with platform or infrastructure teams to determine the optimal configuration for Kubernetes worker nodes, including RAM, CPU, network capabilities, and attached storage devices. These factors influence the selection of OpenEBS storage engines for stateful workloads.

Administrators must also decide on a deployment strategy:

  • Hyperconverged Mode: Stateful applications and storage volumes are co-located on the same nodes.
  • Disaggregated Mode: Stateful applications and storage volumes are hosted on separate node pools.

Container Storage Interface

The Container Storage Interface (CSI) is a standard that enables third-party storage providers to expose block and file storage systems to containerized workloads in Kubernetes. By using CSI, DataCore Puls8 can create and deploy plugins that expose new storage volumes, such as Local and Replicated Volumes, without modifying Kubernetes core code.

When you install DataCore Puls8, the required CSI driver components are deployed into the Kubernetes cluster to facilitate integration with Kubernetes storage management.

Storage Classes and Dynamic Provisioning

A StorageClass provides a way to define different types of storage with various attributes, such as performance levels, backup policies, or quality-of-service guarantees. StorageClass configurations ensure that you can request storage resources without needing to understand the underlying provisioning details.

Dynamic provisioning eliminates the need for pre-provisioning storage resources. Instead, Kubernetes automatically provisions storage as needed based on StorageClass definitions. Cluster administrators can create multiple StorageClass objects, each specifying a provisioner and associated parameters that determine how the storage is allocated.

When DataCore Puls8 is installed, it includes default Storage Classes that enable you to create either local or replicated volumes. You can enable storage engines and define Storage Classes for the required data engines.

Persistent Volumes

A PersistentVolume (PV) is the actual storage resource that backs a PVC. When a PVC is created, Kubernetes provisions a corresponding PV using the storage provider's dynamic provisioning mechanism.

PVs contain metadata and configurations necessary for Kubernetes to manage storage operations, including attachment, detachment, mounting, and unmounting of volumes. DataCore Puls8 control plane dynamically provisions both local and replicated volumes, ensuring seamless PV creation within the cluster.

Persistent Volume Claims

A PersistentVolumeClaim (PVC) is a request for storage resources made by an application. It specifies attributes such as the required storage capacity, access mode (Example: ReadWriteOnce, ReadOnlyMany), and associated StorageClass.

Beyond size and access mode, StorageClass definitions allow you to define additional attributes such as:

  • Storage type (Example: HDD vs. SSD)
  • Performance tier
  • Replication factors

StatefulSets and Deployments

Kubernetes provides workload management constructs such as StatefulSets and Deployments, allowing application developers to define how applications run on Kubernetes clusters.

For stateful applications, a Kubernetes Deployment or StatefulSet must be configured with a PVC to ensure persistent storage. For example, a MongoDB Deployment might reference a PVC with a defined StorageClass and size. Once the DataCore Puls8 control plane provisions the corresponding PV, Kubernetes mounts the storage and launches the MongoDB instance.

Learn More