Kubernetes Storage Classes
DataStax Mission Control is current in Private Preview. It is subject to the beta agreement executed between you and DataStax. DataStax Mission Control is not intended for production use, has not been certified for production workloads, and might contain bugs and other functional issues. There is no guarantee that DataStax Mission Control will ever become generally available. DataStax Mission Control is provided on an “AS IS” basis, without warranty or indemnity of any kind.
If you are interested in trying out DataStax Mission Control please contact your DataStax account team.
Volumes are added to pods and provide storage for containers in the pod. There are many different volume types in Kubernetes, providing both durable and non-durable storage.
Persistent Volumes (PVs) provide durable storage. For instance, the contents under
/var/lib/cassandra are stored in a PV. Depending on the environment, a PV is either dynamically or statically provisioned. It has a lifecycle that is independent of the pod(s) which use it. That means that while a pod that uses a PV may be terminated, the PV remains intact.
Kubernetes (k8s) provides a storage mechanism that administrators use to dynamically provision Persistent Volumes (PVs) in a Kubernetes (k8s) cluster.
After one or more classes of storage are defined, pods can then dynamically request the specific type of storage that they require.
A PVC is a request for storage. It specifies the minimal size criteria for the storage. In the following sample DSECluster YAML file, the
storage: request size is 10 gigabytes:
storageConfig: cassandraDataVolumeClaimSpec: storageClassName: premium-rwo accessModes: - ReadWriteOnce resources: requests: storage: 10Gi
Cloud vendors provide different types of storage with varying performance characteristics and varying costs. StorageClasses are the way to specify the type of PersistentVolume that is needed. The sample DSECluster YAML file specifies
premium-rwo. Check the documentation of your cloud provider for details on the StorageClasses that they provide.
In the DSECluster YAML file, the
storageClassName field must specify a storage class set up with
reclaimPolicy: Delete then the PVs are deleted when the PVCs are deleted. When a cluster is deleted the associated PVCs are deleted as well. Without this parameter the deletion would cascade to the Persistent Volumes.
The following example uses the
premium-rwo storage class and also retains PVs after the DSE cluster is deleted.
premium-rwoto a file with this command:
kubectl get storageclass premium-rwo -o yaml > storageclass.yaml
Then modify the contents as follows:
allowVolumeExpansion: true apiVersion: storage.k8s.io/v1 kind: StorageClass metadata: annotations: components.gke.io/component-name: pdcsi components.gke.io/component-version: 0.11.8 components.gke.io/layer: addon labels: addonmanager.kubernetes.io/mode: EnsureExists k8s-app: gcp-compute-persistent-disk-csi-driver name: premium-rwo-retain parameters: type: pd-ssd provisioner: pd.csi.storage.gke.io reclaimPolicy: Retain volumeBindingMode: WaitForFirstConsumer
DataStax Mission Control requires a StorageClass setting of
Failure to set this may bind a volume on a node where the pod may not be scheduled, resulting in a deadlock or a stuck Pending pod status.
With this file defined we can now submit it to the cluster with
---- kubectl apply -f storageclass.yaml ----
When you create a DSECluster use the new storage class,
storageConfig: cassandraDataVolumeClaimSpec: storageClassName: premium-rwo-retain accessModes: - ReadWriteOnce resources: requests: storage: 10Gi
This specification indicates that when the DSECluster is deleted, the PVs remain intact.