Configuration of storage Tiers

Note

This feature might not be available in all regions. Contact OSC Support for more information about availability in your region or tenant.

The storage tier determines the underlying hardware. The tier is immutable after creation.

Tier	Storage	Use Case	IOPS (Input/Output operations)	TPS (Throughput per second)
Tier1	NVMe (fast)	Real-time processing, high-throughput applications, low-latency requirements	20000	320Mi
Tier3	HDD (slower)	Backups, archives, infrequently accessed data, cost-sensitive workloads	1000	90Mi

Usage of Tier1 storage

Tier 1 storage is represented by the storage class default, which is pre-created on the Shoot cluster. The manifest for this storage class is as follows:

apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
  name: default
provisioner: csi.onmetal.de
parameters:
  # Type field is defining which tier class should be used in this case fast represent tier1
  type: fast
  # volume_pool defines to which pool the volume belongs to
  volume_pool: {region}
reclaimPolicy: Delete
allowVolumeExpansion: true
volumeBindingMode: WaitForFirstConsumer

This storage class is configured as the default, which means that if you do not specify a storage class in the definition of your PVC (PersistentVolumeClaim), the default storage class will be used (Tier1).

Usage of Tier3 storage

Tier 3 storage, as mentioned in the table above, is primarily designed for data that is not sensitive to the speed of write/read operations. By default, a storage class representing Tier 3 is not present on the cluster and needs to be created additionally.

apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
  name: tier3
provisioner: csi.onmetal.de
parameters:
# Type field is defining which tier class should be used in this case slow for tier3
  type: slow 
# volume_pool defines to which pool the volume belongs to. To use Tier 3 storage needs to be specified volumepool with suffix -t3
  volume_pool: {region}-t3 
reclaimPolicy: Delete
allowVolumeExpansion: true
volumeBindingMode: WaitForFirstConsumer

{region} - this value represents the region, where the Shoot cluster is located. E.g (ffm,mdb...).

Using this storage class tier3 (name from example above) in the definition of your PVC will ensure that Tier 3 storage is used for the deployment of the volume.

Example:

Lets consider a region named dev. Then our storage class will look like following:

apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
  name: tier3
provisioner: csi.onmetal.de
parameters:
  type: slow
  volume_pool: dev-t3 
reclaimPolicy: Delete
allowVolumeExpansion: true
volumeBindingMode: WaitForFirstConsumer

kubectl get sc  
NAME                PROVISIONER      RECLAIMPOLICY   VOLUMEBINDINGMODE      ALLOWVOLUMEEXPANSION   AGE
default (default)   csi.onmetal.de   Delete          WaitForFirstConsumer   true                   19d
tier3               csi.onmetal.de   Delete          WaitForFirstConsumer   true                   58s

Then, the creation of a PVC with this new storage-class could take place. In the example bellow, a PVC is deployed together with a pod containing two containers. The init container will write text to the index.html file, and the main container will run a web server that serves the page specified in this index.html.

apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: pvc-tier3
spec:
  storageClassName: tier3
  accessModes:
    - ReadWriteOnce
  resources:
    requests:
      storage: 3Gi
---

apiVersion: v1
kind: Pod
metadata:
  name: pod-tier3
spec:
  volumes:
    - name: pvc-tier3
      persistentVolumeClaim:
        claimName: pvc-tier3
  containers:
    - name: pod-tier3
      image: nginx
      ports:
        - containerPort: 80
          name: "http-server"
      volumeMounts:
        - mountPath: "/usr/share/nginx/html"
          name: pvc-tier3
  initContainers:
  - name: init-myservice
    image: busybox:1.28
    command: ['sh', '-c', 'echo "This is my webpage" > /project/index.html' ]
    volumeMounts:
    - mountPath: "/project"
      name: pvc-tier3

Checking that all objects were created correctly:

kubectl get pod,pvc -n default
NAME              READY   STATUS    RESTARTS   AGE
pod/pod-tier3     1/1     Running   0          2m18s

NAME                                  STATUS   VOLUME                                     CAPACITY   ACCESS MODES   STORAGECLASS   VOLUMEATTRIBUTESCLASS   AGE
persistentvolumeclaim/pvc-tier3       Bound    pv--93a2b669-76d8-44cb-8496-40a6b3b0b6a9   3Gi        RWO            tier3          <unset>                 2m18s