Storage Features

Für Workloads in centron Kubernetes stehen drei Speicherarten zur Verfügung: Persistent Volumes über CSI/PVC, der lokale NVMe-Speicher der Worker Nodes und centron S3 Object Storage.

Überblick

Speicherart	Lebensdauer	Typischer Einsatz
Persistent Volume (CSI/PVC)	Unabhängig vom Pod und vom Node	Datenbanken, zustandsbehaftete Dienste, dauerhaft benötigte Daten
Lokaler NVMe-Speicher des Nodes	An den Node gebunden	Container-Images, temporäre Dateien, Caches
S3 Object Storage	Unabhängig vom Cluster	Backups, Medien, Archive, große Dateimengen

Persistent Volumes (CSI/PVC)

Persistent Volumes (CSI/PVC) sind verfügbar. Sie fordern Speicher über einen PersistentVolumeClaim an; das Volume wird dynamisch bereitgestellt und bleibt erhalten, wenn ein Pod neu startet oder auf einen anderen Node verlagert wird.

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

Im Pod binden Sie den Claim als Volume ein:

    spec:
      containers:
        - name: app
          image: postgres:16
          volumeMounts:
            - mountPath: /var/lib/postgresql/data
              name: daten
      volumes:
        - name: daten
          persistentVolumeClaim:
            claimName: daten

Noch offen

Verfügbare Storage-Klassen, Größenlimits je Volume und das Verhalten bei Snapshots ergänzen wir, sobald die Werte final abgestimmt sind. [DS/Produkt liefert]

Lokaler NVMe-Speicher

Jeder Instance-Typ bringt lokalen NVMe-Speicher mit – je nach Typ zwischen 25 GB (C0) und 400 GB (C8). Dieser Speicher nimmt die Container-Images sowie kurzlebige Daten auf.

Ein emptyDir-Volume nutzt diesen lokalen Speicher:

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

Warnung

Ein emptyDir existiert nur, solange der Pod auf dem Node läuft. Wird der Pod neu gestartet, auf einen anderen Node verlagert oder der Node neu aufgesetzt, sind die Daten verloren. Lokaler Speicher eignet sich daher nicht für Daten, die erhalten bleiben müssen.

Den verfügbaren Speicher je Instance-Typ finden Sie unter Pricing & Limits.

S3 Object Storage

Für große Dateimengen, Backups und Archive eignet sich centron S3 Object Storage. Der Zugriff erfolgt über die S3-API direkt aus Ihrer Anwendung heraus – nicht über das Dateisystem des Pods.

Hinterlegen Sie die Zugangsdaten als Secret:

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

Im Deployment referenzieren Sie diese als Umgebungsvariablen:

    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

Zustandsbehaftete Anwendungen

Zustandsbehaftete Komponenten betreiben Sie im Cluster mit einem Persistent Volume:

• Datenbanken als StatefulSet mit volumeClaimTemplates betreiben, damit jede Replik ihr eigenes Volume erhält.
• Dateien und Objekte in S3 Object Storage ablegen, wenn der Zugriff über die S3-API erfolgt.
• Caches und Sessions so auslegen, dass ihr Verlust unkritisch ist – dafür genügt lokaler Speicher.

Alternativ können Sie eine Datenbank weiterhin auf einer ccloud³ VM im selben VPC-Netzwerk betreiben und aus dem Cluster über die private IP-Adresse ansprechen. Alle Ressourcen eines Rechenzentrums liegen im selben VPC und erreichen sich über private IP-Adressen.

Hinweis

Alles, was ein Pod nur in seinem lokalen Speicher ablegt, geht beim Neustart verloren. Daten, die erhalten bleiben müssen, gehören auf ein Persistent Volume oder in S3 Object Storage.

Datensicherung

Backup- und Wiederherstellungsfunktionen sind nicht Bestandteil des Managed-Kubernetes-Dienstes. Die Sicherung von persistenten Volumes, Cluster-Konfigurationen und Anwendungsdaten liegt vollständig in Ihrer Verantwortung; Sie sind verpflichtet, geeignete Backup- und Wiederherstellungsstrategien zu implementieren und regelmäßig zu überprüfen.

Planen Sie für Daten außerhalb des Clusters – etwa auf einer Datenbank-VM – eine eigene Sicherungsstrategie ein, beispielsweise regelmäßige Dumps nach S3 Object Storage.

Maßgeblich ist der Leistungsschein Managed Kubernetes.

Verwandte Themen

• Plan auswählen
• Pricing & Limits
• Features