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 read or write speeds. By default, the storage class for Tier 3 is not present on the cluster and must be requested from OSC to be enabled on your shoot cluster. Once enabled, a slow storage class will appear, which can be used for Tier 3 storage.

kubectl get sc  
NAME                PROVISIONER      RECLAIMPOLICY   VOLUMEBINDINGMODE      ALLOWVOLUMEEXPANSION   AGE
default (default)   csi.onmetal.de   Delete          WaitForFirstConsumer   true                   19d
slow              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: slow
  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            slow          <unset>                 2m18s