Storage #

Verfügbare StorageClasses

AccessMode und Reclaim-Policy

Alle StorageClasses unterstützen ausschließlich den AccessMode ReadWriteOnce (RWO). Das bedeutet, dass ein Volume nur von einer einzigen Node gleichzeitig gemountet werden kann. ReadWriteMany (RWX) wird nicht unterstützt.

Die Reclaim-Policy bestimmt, was mit dem zugrundeliegenden Volume passiert, wenn das PVC gelöscht wird. Delete bedeutet, dass das Volume und die enthaltenen Daten zusammen mit dem PVC unwiderruflich gelöscht werden.

Falls Volumes auch nach dem Löschen des PVCs erhalten bleiben sollen, kann die Policy direkt auf dem PV nachträglich auf Retain gesetzt werden:

kubectl patch pv <pv-name> -p '{"spec":{"persistentVolumeReclaimPolicy":"Retain"}}'

Das Volume bleibt dann nach dem Löschen des PVCs bestehen und muss manuell aufgeräumt werden.

Default-StorageClass

Ihr Cluster verfügt über eine Default-StorageClass. Wenn Sie bei der Erstellung eines PVC keine StorageClass angeben, wird automatisch die Default-StorageClass „Premium“ verwendet.

PVC erstellen – Beispiel

apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: example-pvc
  namespace: example-namespace
spec:
  accessModes:
  - ReadWriteOnce
  resources:
    requests:
      storage: 10Gi

PVC-Status prüfen:

kubectl get pvc -n example-namespace

Volume Expansion

Vorhandene Persistent Volumes können nachträglich vergrößert werden. Setzen Sie dazu das neue Speicherlimit im PVC:

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

Die Vergrößerung erfolgt online – das Pod muss nicht neu gestartet werden.

Hinweis: Aus technischen Gründen können Volumes ausschließlich vergrößert, jedoch nicht verkleinert werden.

Snapshots

Volume Snapshots werden unterstützt. Die verfügbare VolumeSnapshotClass:

Beispiel:

apiVersion: snapshot.storage.k8s.io/v1
kind: VolumeSnapshot
metadata:
  name: example-snapshot
  namespace: example-namespace
spec:
  volumeSnapshotClassName: lightbits
  source:
    persistentVolumeClaimName: example-pvc

Service-IPs / LoadBalancer #

Externe IPs beziehen

Um einen Service von außerhalb des Clusters erreichbar zu machen, erstellen Sie einen Service vom Typ LoadBalancer. Die Umgebung weist dem Service automatisch eine externe IP zu:

apiVersion: v1
kind: Service
metadata:
  name: example-service
  namespace: example-namespace
spec:
  type: LoadBalancer
  selector:
    app: example-app
  ports:
  - port: 80
    targetPort: 8080
    protocol: TCP

Externe IP prüfen:

kubectl get svc -n example-namespace

Die externe IP erscheint in der Spalte EXTERNAL-IP.

Reservierung von IP-Adressen

Sobald einem Cluster eine externe IP-Adresse zugewiesen wurde, wird diese für Sie reserviert. Auch wenn das zugehörige Service gelöscht wird, bleibt diese Reservierung 14 Tage lang bestehen. Bei IP-Adress Ressourcenengpässen kann die IP neu vergeben werden, wird aber bevorzugt Ihrem Cluster zugeteilt.

Eine zuvor reservierte IP-Adresse kann über folgende Annotation angefragt werden, sofern sie noch verfügbar ist:

metadata:
  annotations:
    k8s.at/managed-loadbalancer-ip: <ihre-reservierte-ip>

DNS

Die interne Cluster-DNS-Auflösung wird über CoreDNS bereitgestellt. Pods können Services innerhalb des Clusters über ihren DNS-Namen erreichen:

<service>.<namespace>.svc.cluster.local

Ausgehende IP-Adresse (Outbound NAT IP)

Der gesamte ausgehende Traffic des Clusters erfolgt über eine gemeinsame IP-Adresse. Alle Nodes Ihres Clusters nutzen dieselbe ausgehende IP – unabhängig davon, auf welcher Node ein Pod läuft. Diese IP-Adresse ist ausschließlich Ihrem Cluster zugewiesen und wird nicht mit anderen Clustern geteilt, was zuverlässiges IP-Whitelisting bei externen Diensten ermöglicht.

Die ausgehende IP-Adresse kann im Control Center unter IP Resources (Outbound NAT IP) eingesehen werden.

Zugriff auf die Kubernetes-API einschränken #

Der Zugriff auf die Kubernetes-API kann im Control Center unter Security eingeschränkt werden. Folgende Modi stehen zur Verfügung:

Backups #

Addon bestellen

Backups können als optionales kostenpflichtiges Addon über das Control Center gebucht werden. Das Backup-Addon basiert auf Velero. Im Zuge der Bestellung wird automatisch ein Backupspace bereitgestellt. Die Abrechnung erfolgt verbrauchsorientiert pro gespeichertem Gigabyte und Stunde.

Konfiguration

Die Backup-Konfiguration erfolgt im Control Center:

• Backup-Zeitplan (Cron) festlegen
• Speicherdauer der Backups
• E-Mail-Notifikation bei erfolgreichen oder fehlgeschlagenen Backups

Restore

Ein Restore wird über die Velero CLI durchgeführt. Eine ausführliche Anleitung finden Sie in der offiziellen Velero-Dokumentation. Die Installation der CLI ist in der Velero-Installationsanleitung beschrieben.

Vorhandene Backups auflisten:

velero backup get

Vollständiger Restore eines Backups:

velero restore create <restore-name> --from-backup <backup-name>

Restore eines einzelnen Namespaces aus einem Backup:

velero restore create <restore-name> \
  --from-backup <backup-name> \
  --include-namespaces example-namespace

Restore mit Namespace-Mapping (z.B. in einen neuen Namespace zur Verifikation):

velero restore create <restore-name> \
  --from-backup <backup-name> \
  --namespace-mappings example-namespace:example-namespace-restored

Restore nur bestimmter Ressourcen anhand eines Labels:

velero restore create <restore-name> \
  --from-backup <backup-name> \
  --selector app=example-app

Metrics #

Addon bestellen

Metrics können als optionales kostenpflichtiges Addon über das Control Center gebucht und eingesehen werden. Es umfasst mehrere Grafana Dashboards, welche den Status des Clusters auf einen Blick erkennbar machen, und speziell beim Troubleshooting hilfreich sein können. Zusätzlich können diese via Direktlink aufgerufen werden.

Metrics im Control Center

Nach der Buchung stehen Ihnen unter anderem folgende Metriken im Control Center zur Verfügung:

• CPU- und RAM-Auslastung der Worker Nodes und Pods
• Anzahl laufender Pods pro Node
• Netzwerk-Traffic
• Speicherverbrauch der Persistent Volumes

Hinweis

Auch ohne gebuchtes Metrics-Addon sammeln wir eine Reihe an Basisinformationen, welche wir für die Sicherstellung des Betriebs benötigen. Aus diesem Grund werden bereits bei der Clustererstellung einige Metrics-Komponenten provisioniert, welche auch nicht vom Cluster entfernt werden können.

Infrastructure as Code #

Verwendung von IaC-Tools

Sie können Ressourcen im Cluster wie gewohnt mit standard Infrastructure as Code-Tools wie Terraform oder Pulumi verwalten. Die Tools können direkt mit der exportierten Kubeconfig verwendet werden. Bitte beachten Sie jedoch, dass die vom Control Center exportierte Kubeconfig eine begrenzte Lebenszeit hat.

Best Practices für Automatisierung

Für den automatisierten Zugriff (z. B. über CI/CD-Pipelines) stehen Ihnen folgende Ansätze zur Verfügung:

• Nutzung von Variablen: Sie können die Kubeconfig als Variable in Ihrem IaC-Tool hinterlegen und bei Bedarf dynamisch austauschen.
• Eigener Service Account: Es kann sich lohnen, einen eigenen Service Account im Cluster für Ihre IaC-Tools einzurichten. Dies ermöglicht eine feingranulare Rechtevergabe über RBAC und bietet eine langlebige Authentifizierungsmethode. Siehe auch: Long Lived Kubeconfig