default-storageclass.md

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.