Adding Storage to Apps

When running applications, you might need additional storage for either persistence or scratch/work space. The IT Common Platform provides a few mechanisms to attach additional storage to your applications.

Table of Storage Classes

Environment	Type	Description	Access Mode	Max Risk Category	Encryption	Storage Class Name
AWS	EBS	Elastic Block Storage	RWO	High	At Rest, In Flight	omitted or ebs-<nodepool>-delete
AWS	EFS	Elastic File System - upon request	RWX	High	At Rest, In Flight	efs-<nodepool>-delete
On-Prem	VSAN	VSAN Block Storage	RWO	Medium	None	omitted or vsan-<nodepool>-delete
On-Prem	NFS	Network File System - upon request	RWX	High	At Rest	nfs -<nodepool>-delete

AWS Storage Classes

In addition to storage we offer, you are also welcome to assume an IAM role to use S3 buckets or other storage from your own account.

EBS

The primary storage class in AWS for Common Platform is Amazon's EBS. It is already set as default in all tenant namespaces. The easiest way to use it is to omit the StorageClassName and the name will be defaulted in.

For posterity, the actual StorageClassName will depend on your node-pool with the pattern:

ebs-{{ node-pool name }}-delete

Notes about EBS Volumes

• EBS volumes are tied to a specific availability zone, so be mindful of how you deploy your application
• All volumes are automatically encrypted by default
• Volume resizing support is enabled. But note that AWS has a limit of one volume modification every 6 hours. Refer to the EBS documentation for more details

EFS

Amazon's EFS is the default read-write-many solution for EKS. Due to provisioning limitations, it is only available upon request.

Notes about EFS Volumes

• EFS volumes are available in all availability zones the Platform runs in
• The capacity/size of EFS is ignored, as EFS has no sizing and will grow/shrink as needed
• All data in transit is encrypted

On-prem EKS-A Storage Classes

vSAN block storage

The primary storage class for on-prem for Common Platform is vSAN block storage, a SAN built into the existing VMWare infrastructure. It is already set as default in all tenant namespaces. The easiest way to use it is to omit the StorageClassName and let it be defaulted for you.

For posterity, the actual StorageClassName will depend on your node-pool with the pattern:

vsan-{{ node-pool name }}-delete

NetApp NFS RWX storage

This storage can be used for RWX (read-write-many) purposes. It is encrypted at rest and is suitable for FERPA data. This storage class is only availabe upon request.

The StorageClassName will depend on your node-pool with the pattern:

nfs-{{ node-pool name }}-delete

Here is an example PVC manifest:

---
apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: example-nfs-pvc
  namespace: {{ tenant namespace }}
spec:
  storageClassName: nfs-{{ node-pool namespace }}-delete
  accessModes:
    - ReadWriteMany
  resources:
    requests:
      storage: 1Gi

Using Ephemeral Storage

If you wish to add additional storage to your running pods, you can use the Ephemeral Volume support built into Kubernetes. The following example will create a Pod that has a 1GB EBS volume and mounted at /scratch.

kind: Pod
apiVersion: v1
metadata:
  name: my-app
spec:
  containers:
    - name: app
      image: nginx:alpine
      volumeMounts:
      - mountPath: "/scratch"
        name: scratch-volume
  volumes:
    - name: scratch-volume
      ephemeral:
        volumeClaimTemplate:
          spec:
            accessModes: [ "ReadWriteOnce" ]
            resources:
              requests:
                storage: 1Gi

If used in a Deployment with multiple replicas, each Pod will get its own volume. When the pod is removed, the EBS volume is automatically removed.

Persistent Storage

If you want your storage to live beyond the lifespan of a Pod, you need to create a PersistentVolumeClaim (often abbreviated as PVC). When this object is declared, the volume will be configured (but may not be provisioned until first use) and can then be referenced in your pod specification.

The following example will create a 4GB EBS volume.

apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: example-ebs-claim
spec:
  accessModes:
    - ReadWriteOnce
  resources:
    requests:
      storage: 4Gi

Once you have the PVC defined, you can reference it in your Pod specification. The example below creates a Volume backed by the PVC and mounts it at /data. The container, while executing, will print out the current time to a file in /data/out.txt, storing it in the EBS volume.

apiVersion: v1
kind: Pod
metadata:
  name: app
spec:
  containers:
    - name: app
      image: centos
      command: ["/bin/sh"]
      args: ["-c", "while true; do echo $(date -u) >> /data/out.txt; sleep 5; done"]
      volumeMounts:
        - name: persistent-storage
          mountPath: /data
  volumes:
    - name: persistent-storage
      persistentVolumeClaim:
        claimName: example-ebs-claim