Skip to content

Kubernetes Storage Class

Estimated time to read: 3 minutes

Our Managed Kubernetes platform comes with default StorageClasses that provision storage in the underlying cloud, below these default StorageClasses will be explored, the possibilities of creating your own custom StorageClasses are discussed along with the impact of the underlying storage platform tiers that are given when creating or using StorageClasses in Kubernetes.

EMK - Storage Classes

When you create a Kubernetes Cluster within our platform it is given three StorageClasses by default, these are listed below.

Default Kubernetes Storage Classes

  • default - the default StorageClass consumed by volume resources in Kubernetes, same as the tier-2 StorageClass
  • tier-1 - the default tier-1 StorageClass, this uses tier-1 storage in the underlying cloud platform for volume resources
  • tier-2 - the default tier-2 StorageClass, this uses tier-2 storage in the underlying cloud platform for volume resources

These default resources are managed by our EMK service and can not be edited , during Cluster reconciliation any changes are reverted. The 'default' StorageClass is the default used for volume resources in Kubernetes unless otherwise specified.

You can create your own Kubernetes Storage Classes. This is useful to do if you have specific parameters or settings you want to make use of within the StorageClass object. Examples are: changing the volumeBindingMode, disallowing VolumeExpansion or changing your in-cluster reclaim policy. The only requirement is that the Parameters: portion of the StorageClass YAML contains the tier type used in the underlying platform, an example of a valid resource is given below.

apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
  name: customstorage
  annotations:
    storageclass.kubernetes.io/is-default-class: "false"
provisioner: cinder.csi.openstack.org
parameters:
  type: tier-1
allowVolumeExpansion: true
reclaimPolicy: Delete
volumeBindingMode: Immediate

This StorageClass can then, for example, be used in a PersistentVolumeClaim and be consumed by a pod hosting your application or microservice, an example is given below for the above defined 'customstorage' StorageClass.

---
apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: ubuntu-pvc
spec:
  storageClassName: customstorage
  accessModes:
    - ReadWriteOnce
  resources:
    requests:
      storage: 10Gi

---
apiVersion: v1
kind: Pod
metadata:
  name: ubuntu-pod
  labels:
    app: ubuntu
spec:
  containers:
  - name: ubuntu
    image: ubuntu:latest
    command: ["/bin/bash"]
    args: ["-c", "while true; do sleep 30; done"]
    volumeMounts:
    - name: ubuntu-storage
      mountPath: /data
  volumes:
  - name: ubuntu-storage
    persistentVolumeClaim:
      claimName: ubuntu-pvc
  restartPolicy: Always

The parameter 'type: tier-1' is crucial to your performance and billing and is explained below.

EMK - Underlying Storage Platform Tiers

The Managed Kubernetes service uses underlying platform-level tiers for determining the performance and price of storage, these are 1:1 with what is offered in our cloud platform and can be viewed here under the header 'Storage'.

The available pool of storage tiers consists of regular storage and 'multi-attach' i.e 'tier-1m' storage. The tiers differ in price and IOPS per GB. Some tiers scale faster, but depend on the size of the volume to be faster. A detailed explanation for comparing performance between tiers is given in our disk benchmark guide.

It is important to note that multi-attach storage does not work for RWX filesystems (at this moment) and is thus only applicable for niche use-cases at the moment.