Skip to main content

Storage Features

Three types of storage are available for workloads on centron Kubernetes: persistent volumes via CSI/PVC, the local NVMe storage on the worker nodes, and centron S3 Object Storage.

Overview​

Storage typeLifespanTypical use
Persistent volume (CSI/PVC)Independent of the pod and the nodeDatabases, stateful services, data that must be retained
Node’s local NVMe storageBound to the nodeContainer images, temporary files, caches
S3 Object StorageIndependent of the clusterBackups, media, archives, large volumes of data

Persistent volumes (CSI/PVC)​

Persistent volumes (CSI/PVC) are supported. You request storage through a PersistentVolumeClaim; the volume is provisioned dynamically and is retained when a pod restarts or is moved to a different node.

apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: data
spec:
  accessModes:
    - ReadWriteOnce
  resources:
    requests:
      storage: 20Gi

Mount the claim as a volume in the pod:

    spec:
      containers:
        - name: app
          image: postgres:16
          volumeMounts:
            - mountPath: /var/lib/postgresql/data
              name: data
      volumes:
        - name: data
          persistentVolumeClaim:
            claimName: data
Still to be confirmed

Available storage classes, per-volume size limits and snapshot behaviour will be added once the values have been finalised. [DS/Product to supply]

Local NVMe storage​

Each instance type comes with local NVMe storage – ranging from 25 GB (C0) to 400 GB (C8), depending on the type. This storage is used to hold container images and short-lived data.

A emptyDir volume uses this local storage:

    spec:
      containers:
        - name: app
          image: nginx:stable
          volumeMounts:
            - mountPath: /cache
              name: cache
      volumes:
        - name: cache
          emptyDir: {}
Warnung

A emptyDir only exists whilst the pod is running on the node. If the pod is restarted, migrated to another node or the node is reset, the data will be lost. Local storage is therefore not suitable for data that needs to be preserved.

You can find the available storage per instance type under Pricing & Limits.

S3 Object Storage​

For data that needs to be retained permanently, centron S3 Object Storage is currently the recommended solution. Access is via the S3 API directly from your application – not via the pod’s file system.

Store the login details as a secret:

kubectl create secret generic s3-credentials \
  --from-literal=access-key=<ihr-access-key> \
  --from-literal=secret-key=<ihr-secret-key>

In the deployment, you reference these as environment variables:

    spec:
      containers:
        - name: app
          image: registry.example.com/app:1.0
          env:
            - name: S3_ACCESS_KEY
              valueFrom:
                secretKeyRef:
                  name: s3-credentials
                  key: access-key
            - name: S3_SECRET_KEY
              valueFrom:
                secretKeyRef:
                  name: s3-credentials
                  key: secret-key

Stateful applications​

As no persistent block storage is available within the cluster, stateful components should currently be run outside the cluster:

  • Run databases as a StatefulSet with volumeClaimTemplates so that each replica gets its own volume.
  • Store files and objects in S3 Object Storage where access goes through the S3 API.
  • Configure caches and sessions so that their loss is not critical – local storage is sufficient for these.

Alternatively, you can still run a database on a ccloud³ VM within the same VPC network and access it from the cluster via the private IP address. All resources in a data centre are located within the same VPC and can be accessed via private IP addresses.

Hinweis

Anything a pod keeps only in its local storage is lost on restart. Data that must be retained belongs on a persistent volume or in S3 Object Storage.

Data backup​

Backup and recovery functions are not included in the Managed Kubernetes service. You are entirely responsible for backing up persistent volumes, cluster configurations and application data; you are obliged to implement and regularly review appropriate backup and recovery strategies.

For data outside the cluster – such as on a database VM – plan a separate backup strategy, for example, regular S3 Object Storage dumps.

The Managed Kubernetes service specification is the relevant document.

Last updated on