Default Storage Class Prerequisiteπ
- BigBang assumes the cluster youβre deploying to supports dynamic volume provisioning.
- A BigBang Cluster should have 1 Storage Class annotated as the default SC.
- For Production Deployments it is recommended to leverage a Storage Class that supports the creation of volumes that support ReadWriteMany Access Mode, as there are a few BigBang Addons, where an HA application configuration requires a storage class that supports ReadWriteMany.
How Dynamic Volume Provisioning Works in a Nut Shellπ
- StorageClass + PersistentVolumeClaim = Dynamically Created Persistent Volume
- A PersistentVolumeClaim that does not reference a specific StorageClass will leverage the default StorageClass. (Of which there should only be 1, identified using kubernetes annotations.) Some Helm Charts allow a storage class to be explicitly specified so that multiple storage classes can be used simultaneously.
How To Check What Storage Classes Are Installed on Your Clusterπ
kubectl get storageclass
can be used to see what storage classes are available on a cluster, the default will be marked as such.- Note: You can have multiple storage classes, but you should only have 1 default storage class.
kubectl get storageclass
# NAME PROVISIONER RECLAIMPOLICY VOLUMEBINDINGMODE ALLOWVOLUMEEXPANSION AGE
# local-path (default) rancher.io/local-path Delete WaitForFirstConsumer false 47h
AWS Specific Notesπ
Example AWS Storage Class Configurationπ
kind: StorageClass
apiVersion: storage.k8s.io/v1
metadata:
name: gp2
annotations:
storageclass.kubernetes.io/is-default-class: 'true'
provisioner: kubernetes.io/aws-ebs
parameters:
type: gp2 #gp3 isn't supported by the in-tree plugin
fsType: ext4
# encrypted: 'true' #requires kubernetes nodes have IAM rights to a KMS key
# kmsKeyId: 'arn:aws-us-gov:kms:us-gov-west-1:110518024095:key/b6bf63f0-dc65-49b4-acb9-528308195fd6'
reclaimPolicy: Retain
allowVolumeExpansion: true
AWS EBS Volumesπ
- AWS EBS Volumes have the following limitations:
- An EBS volume can only be attached to a single Kubernetes Node at a time, thus ReadWriteMany Access Mode isnβt supported.
- An EBS PersistentVolume in AZ1 (Availability Zone 1), cannot be mounted by a worker node in AZ2.
AWS EFS Volumesπ
- An AWS EFS Storage Class can be installed according to the vendors docs.
- AWS EFS Storage Class supports ReadWriteMany Access Mode.
- AWS EFS Persistent Volumes can be mounted by worker nodes in multiple AZs.
- AWS EFS is basically NFS(NetworkFileSystem) as a Service. NFS cons like latency apply equally to EFS, thus itβs not a good fit for for databases.
Azure Specific Notesπ
Azure Disk Storage Class Notesπ
- The Kubernetes Docs offer an Example Azure Disk Storage Class
- An Azure disk can only be mounted with Access mode type ReadWriteOnce, which makes it available to one node in AKS.
- An Azure Disk PersistentVolume in AZ1, can be mounted by a worker node in AZ2 (although some additional lag is involved in such transitions).
Bare Metal/Cloud Agnostic Store Class Notesπ
- The BigBang Product team put together a Comparison Matrix of a few Cloud Agnostic Storage Class offerings
- Note: No storage class specific container images exist in IronBank at this time.
- Approved IronBank Images will show up in https://registry1.dso.mil
- https://repo1.dso.mil/dsop can be used to check status of IronBank images.
Last update:
2022-08-05 by Ryan Thompson