Dynamische Bereitstellung von Speicher

Dynamische Storage-Bereitstellung automatisiert Volume-Bereitstellungsprozesse in OpenShift durch bedarfsgerechte Storage-Erstellung basierend auf Anwendungsanforderungen und Policy-Definitionen. Diese Self-Service Storage-Mechanismen reduzieren den administrativen Aufwand und ermöglichen Entwickler-Selbstständigkeit bei der Storage-Bereitstellung ohne Intervention des Infrastruktur-Teams.

36.1 Grundlagen der dynamischen Bereitstellung

Dynamic Provisioning-Controller überwachen PVC-Erstellungsereignisse und initiieren automatische PV-Erstellungs-Workflows basierend auf Storage-Class-Spezifikationen und Ressourcenanforderungen. Diese ereignisgesteuerte Bereitstellungsarchitektur gewährleistet Echtzeit-Storage-Ressourcenverfügbarkeit.

36.1.1 Funktionsweise des Dynamic Provisioning

Der grundlegende Workflow der dynamischen Storage-Bereitstellung folgt einem klaren Muster:

36.1.2 Provisioner-Plugin-Architektur

Die Provisioner-Plugin-Architektur ermöglicht storage-backend-spezifische Bereitstellungslogik durch modulare Treiber-Integration. Diese Plugin-System-Design unterstützt Anbieter-Vielfalt und ermöglicht benutzerdefinierte Storage-Integration ohne Core-System-Modifikationen.

apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: webapp-data
  namespace: production
spec:
  accessModes:
  - ReadWriteOnce
  resources:
    requests:
      storage: 50Gi
  storageClassName: fast-ssd  # Trigger für Dynamic Provisioning

Die API-Integration zwischen Kubernetes Control Plane und Storage-Backends implementiert bidirektionale Kommunikation für Volume-Lifecycle-Management. Diese API-basierte Integration gewährleistet konsistente Storage-Zustandsverwaltung zwischen Orchestrierungs-Layer und Storage-Infrastruktur.

36.2 Container Storage Interface (CSI) Integration

CSI-Treiber-Architektur standardisiert Storage-Bereitstellungs-Interfaces für anbieter-neutrale Storage-Integration. Diese Standardisierung ermöglicht interoperable Storage-Lösungen ohne Kubernetes-Core-Abhängigkeiten.

36.2.1 CSI-Treiber-Komponenten

CSI-Controller: Verwaltet Volume-Lifecycle-Operationen (Create, Delete, Expand)

apiVersion: apps/v1
kind: StatefulSet
metadata:
  name: csi-controller
spec:
  serviceName: csi-controller
  replicas: 2  # HA-Setup
  template:
    spec:
      serviceAccount: csi-controller-sa
      containers:
      - name: csi-provisioner
        image: k8s.gcr.io/sig-storage/csi-provisioner:v3.4.0
        args:
        - --csi-address=/var/lib/csi/sockets/pluginproxy/csi.sock
        - --volume-name-prefix=pv
        - --timeout=120s
        - --leader-election
      - name: csi-attacher
        image: k8s.gcr.io/sig-storage/csi-attacher:v4.1.0
      - name: csi-resizer
        image: k8s.gcr.io/sig-storage/csi-resizer:v1.7.0
      - name: storage-driver
        image: storage-vendor/csi-driver:latest

CSI-Node: Läuft als DaemonSet auf allen Nodes für Mount/Unmount-Operationen

apiVersion: apps/v1
kind: DaemonSet
metadata:
  name: csi-node
spec:
  template:
    spec:
      serviceAccount: csi-node-sa
      hostNetwork: true
      containers:
      - name: csi-node-driver-registrar
        image: k8s.gcr.io/sig-storage/csi-node-driver-registrar:v2.7.0
        args:
        - --csi-address=/csi/csi.sock
        - --kubelet-registration-path=/var/lib/kubelet/plugins/storage-vendor/csi.sock
      - name: storage-driver
        image: storage-vendor/csi-driver:latest
        securityContext:
          privileged: true

36.2.2 Volume-Lifecycle-Operationen

CSI-Treiber unterstützen umfassende Volume-Lifecycle-Operationen einschließlich Create, Delete, Attach, Detach, Mount und Unmount-Operationen für vollständiges Volume-Management. Diese umfassende Lifecycle-Unterstützung gewährleistet vollwertige Storage-Integration.

36.2.3 Topology-Aware Provisioning

Topology-bewusste Bereitstellung berücksichtigt Node-Standort und Storage-Backend-Topologie für optimale Volume-Platzierung:

apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
  name: topology-aware-storage
provisioner: csi-driver.example.com
volumeBindingMode: WaitForFirstConsumer  # Kritisch für Topology-Awareness
allowedTopologies:
- matchLabelExpressions:
  - key: topology.kubernetes.io/zone
    values:
    - us-west-2a
    - us-west-2b
  - key: topology.kubernetes.io/region
    values:
    - us-west-2

36.3 Provisioning-Workflows und Zustandsverwaltung

36.3.1 PVC-Analyse und Backend-Auswahl

Die PVC-Analysephase untersucht Storage-Anforderungen, Zugriffsmuster und Performance-Charakteristika für optimale Bereitstellungsstrategie-Auswahl. Diese Anforderungsanalyse gewährleistet angemessene Storage-Ressourcenallokation.

apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: database-storage
  annotations:
    volume.beta.kubernetes.io/storage-class: "high-iops-ssd"
    # Erweiterte Anforderungen über Annotations
    storage.example.com/iops-requirement: "10000"
    storage.example.com/throughput-requirement: "500MB/s"
spec:
  accessModes:
  - ReadWriteOnce
  resources:
    requests:
      storage: 100Gi
  selector:
    matchLabels:
      performance-tier: premium
      encryption: required

Die Backend-Auswahllogik evaluiert verfügbare Storage-Backends basierend auf Kapazität, Performance-Fähigkeiten und Topologie-Einschränkungen. Diese intelligente Backend-Auswahl optimiert Ressourcennutzung und Performance-Bereitstellung.

36.3.2 Volume-Erstellungs-Orchestrierung

Die Volume-Erstellungs-Orchestrierung koordiniert mehrstufige Bereitstellungsprozesse einschließlich Backend-Volume-Erstellung, Dateisystem-Formatierung und Metadaten-Registrierung:

# Typischer CSI-Provisioning-Ablauf (vereinfacht)
1. CreateVolume-API-Aufruf an CSI-Driver
2. Backend-spezifische Volume-Erstellung
3. Volume-Formatierung mit gewünschtem Dateisystem
4. PersistentVolume-Objekt-Erstellung in Kubernetes
5. Automatisches PV-PVC-Binding

36.3.3 Binding-Automation

Die Binding-Automation implementiert automatische PV-zu-PVC-Zuordnung nach erfolgreicher Bereitstellungsabschluss. Diese automatische Bindung eliminiert manuelle administrative Schritte und beschleunigt Storage-Bereitstellung.

36.4 Capacity-Management und Ressourcen-Optimierung

36.4.1 Storage-Pool-Management

Storage-Pool-Management überwacht Backend-Kapazitätsnutzung und implementiert intelligentes Load-Balancing für Volume-Bereitstellung:

# Beispiel eines CSI-Storage-Pools mit Kapazitäts-Tracking
apiVersion: storage.k8s.io/v1
kind: CSIStorageCapacity
metadata:
  name: storage-pool-us-west-2a
  generateName: csi-driver-
spec:
  nodeTopology:
    matchLabels:
      topology.kubernetes.io/zone: us-west-2a
  storageClassName: fast-ssd
  capacity: 10Ti
  maximumVolumeSize: 16Ti

36.4.2 Thin Provisioning

Thin-Provisioning-Strategien ermöglichen Over-Subscription von Storage-Kapazität für verbesserte Ressourcennutzung:

apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
  name: thin-provisioned-storage
provisioner: thin-provisioner.example.com
parameters:
  # Thin Provisioning aktiviert
  provisioningType: thin
  # Over-subscription-Verhältnis 3:1
  overProvisionRatio: "3"
  # Automatische Expansion bei 80% Nutzung
  autoExpandThreshold: "80"
reclaimPolicy: Delete
allowVolumeExpansion: true

36.4.3 Auto-Scaling Integration

Auto-Scaling-Integration erweitert Storage-Backend-Kapazität bei hohen Auslastungsszenarien durch automatische Infrastruktur-Expansion:

apiVersion: v1
kind: ConfigMap
metadata:
  name: storage-autoscaler-config
data:
  config.yaml: |
    pools:
    - name: production-pool
      thresholds:
        scaleUpAt: 80%
        scaleDownAt: 30%
      scalingPolicy:
        scaleUpStep: 1Ti
        scaleDownStep: 500Gi
        cooldownPeriod: 15m

36.5 Performance-Optimierung und Quality-of-Service

36.5.1 IOPS-Allocation-Management

IOPS-Allocation-Management verteilt verfügbare Performance-Kapazität zwischen dynamisch bereitgestellten Volumes basierend auf QoS-Anforderungen:

apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
  name: performance-guaranteed
provisioner: performance-csi.example.com
parameters:
  # Garantierte IOPS pro Volume
  guaranteedIOPS: "5000"
  # Burst-IOPS-Limit
  burstIOPS: "15000"
  # Latenz-SLA
  maxLatencyMs: "1"
  # QoS-Priorität
  qosPriority: "high"

36.5.2 Bandwidth-Throttling

Bandwidth-Throttling-Integration implementiert Traffic-Shaping für faire Storage-Ressourcen-Teilung zwischen Anwendungen:

# Beispiel einer QoS-Policy für Storage-Bandwidth
apiVersion: v1
kind: ConfigMap
metadata:
  name: storage-qos-policy
data:
  policy.yaml: |
    bandwidthLimits:
      guaranteed: 100MB/s
      maximum: 500MB/s
      burstDuration: 30s
    priorityClasses:
      high: 80%
      medium: 60%
      low: 40%

36.6 Security-Integration

36.6.1 Verschlüsselungs-Key-Management

Encryption-Key-Management für dynamisch bereitgestellte Volumes implementiert automatische Verschlüsselungs-Key-Generierung und -Verteilung:

apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
  name: encrypted-dynamic-storage
provisioner: encrypted-csi.example.com
parameters:
  # Automatische Verschlüsselung aktiviert
  encryption: "enabled"
  # Key Management Service Integration
  kmsProvider: "vault"
  kmsEndpoint: "https://vault.example.com:8200"
  # Key-Rotation-Policy
  keyRotationDays: "90"
  # Per-Volume-Keys für maximale Sicherheit
  perVolumeKeys: "true"

36.6.2 Access-Control-Integration

Access-Control-Integration mit RBAC-Systemen ermöglicht automatische Security-Policy-Anwendung für neu bereitgestellte Volumes:

# RBAC für Dynamic Provisioning
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
  name: dynamic-provisioner
rules:
- apiGroups: [""]
  resources: ["persistentvolumes"]
  verbs: ["get", "list", "watch", "create", "delete"]
- apiGroups: [""]
  resources: ["persistentvolumeclaims"]
  verbs: ["get", "list", "watch", "update"]
- apiGroups: ["storage.k8s.io"]
  resources: ["storageclasses"]
  verbs: ["get", "list", "watch"]
- apiGroups: [""]
  resources: ["events"]
  verbs: ["list", "watch", "create", "update", "patch"]

36.7 Fehlerbehandlung und Resilienz

36.7.1 Retry-Logik für fehlgeschlagene Bereitstellung

Retry-Logik für fehlgeschlagene Bereitstellungsversuche implementiert exponentielles Backoff und Circuit-Breaker-Patterns für robuste Fehlerwiederherstellung:

apiVersion: v1
kind: ConfigMap
metadata:
  name: provisioner-retry-config
data:
  config.yaml: |
    retryPolicy:
      maxRetries: 5
      backoffStrategy: exponential
      initialDelay: 1s
      maxDelay: 300s
      backoffMultiplier: 2.0
    circuitBreaker:
      failureThreshold: 3
      recoveryTimeout: 60s
      halfOpenMaxCalls: 1

36.7.2 Fallback-Provisioner-Konfiguration

Fallback-Provisioner-Konfiguration ermöglicht alternative Storage-Backend-Nutzung bei primären Provisioner-Ausfällen:

apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
  name: resilient-storage
  annotations:
    # Fallback-Provisioner definieren
    storage.kubernetes.io/fallback-provisioner: "backup-csi.example.com"
    storage.kubernetes.io/fallback-parameters: '{"type":"standard","replication":"2"}'
provisioner: primary-csi.example.com
parameters:
  type: premium
  replication: 3

36.7.3 Partial-Failure-Recovery

Partial-Failure-Recovery implementiert Cleanup-Mechanismen für unvollständige Bereitstellungsoperationen:

# Beispiel-Cleanup-Script für failed provisioning
#!/bin/bash

# Orphaned PVs ohne PVC finden und bereinigen
kubectl get pv --no-headers | \
  awk '$5=="Failed" && $6=="" {print $1}' | \
  xargs -r kubectl delete pv

# Stuck PVCs mit Provisioning-Fehlern identifizieren
kubectl get pvc --all-namespaces --no-headers | \
  awk '$4=="Pending"' | \
  while read namespace pvc; do
    kubectl describe pvc -n $namespace $pvc | \
      grep -q "ProvisioningFailed" && \
      echo "Failed PVC: $namespace/$pvc"
  done

36.8 Multi-Tenancy und Isolation

36.8.1 Namespace-basierte Storage-Isolation

Namespace-basierte Storage-Isolation implementiert mandanten-spezifische Storage-Bereitstellungs-Policies und Ressourcenquoten:

# Namespace-spezifische Storage-Quota
apiVersion: v1
kind: ResourceQuota
metadata:
  name: storage-quota
  namespace: tenant-a
spec:
  hard:
    requests.storage: 1Ti
    persistentvolumeclaims: 50
    fast-ssd.storageclass.storage.k8s.io/requests.storage: 500Gi
    standard.storageclass.storage.k8s.io/requests.storage: 500Gi

---
# NetworkPolicy für Storage-Traffic-Isolation
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: storage-isolation
  namespace: tenant-a
spec:
  podSelector: {}
  policyTypes:
  - Ingress
  - Egress
  egress:
  - to:
    - namespaceSelector:
        matchLabels:
          name: storage-system
    ports:
    - protocol: TCP
      port: 443  # Storage-API-Port

36.8.2 Storage-Class-RBAC-Integration

Storage-Class-RBAC-Integration beschränkt dynamische Bereitstellungsfähigkeiten basierend auf Benutzerrollen:

# Role für beschränkte Storage-Class-Nutzung
apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
  namespace: development
  name: dev-storage-user
rules:
- apiGroups: [""]
  resources: ["persistentvolumeclaims"]
  verbs: ["create", "get", "list", "delete"]
# Nur bestimmte Storage Classes erlaubt
- apiGroups: ["storage.k8s.io"]
  resources: ["storageclasses"]
  resourceNames: ["standard", "development"]
  verbs: ["get"]

36.9 Integration mit Anwendungszyklen

36.9.1 Application-Deployment-Integration

Application-Deployment-Integration koordiniert Storage-Bereitstellung mit Anwendungsbereitstellungs-Workflows für synchronisierte Ressourcenverfügbarkeit:

# Deployment mit dynamischem Storage
apiVersion: apps/v1
kind: Deployment
metadata:
  name: webapp-with-storage
spec:
  replicas: 3
  template:
    spec:
      containers:
      - name: webapp
        image: webapp:latest
        volumeMounts:
        - name: app-data
          mountPath: /var/lib/webapp
        - name: app-cache
          mountPath: /tmp/cache
      volumes:
      - name: app-data
        persistentVolumeClaim:
          claimName: webapp-data-pvc
      - name: app-cache
        persistentVolumeClaim:
          claimName: webapp-cache-pvc

---
# Entsprechende PVCs für dynamische Bereitstellung
apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: webapp-data-pvc
spec:
  accessModes: [ReadWriteOnce]
  resources:
    requests:
      storage: 10Gi
  storageClassName: standard-ssd

---
apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: webapp-cache-pvc
spec:
  accessModes: [ReadWriteMany]
  resources:
    requests:
      storage: 5Gi
  storageClassName: fast-cache

36.9.2 StatefulSet-Integration

StatefulSet-Integration für geordnete Storage-Bereitstellung gewährleistet sequenzielle Volume-Erstellung für zustandsbehaftete Anwendungen:

apiVersion: apps/v1
kind: StatefulSet
metadata:
  name: database-cluster
spec:
  serviceName: database
  replicas: 3
  template:
    spec:
      containers:
      - name: database
        image: postgresql:13
        volumeMounts:
        - name: data
          mountPath: /var/lib/postgresql/data
  # Volume Claim Templates für dynamische Bereitstellung
  volumeClaimTemplates:
  - metadata:
      name: data
    spec:
      accessModes: [ReadWriteOnce]
      resources:
        requests:
          storage: 100Gi
      storageClassName: database-ssd

36.10 Monitoring und Observability

36.10.1 Provisioning-Metriken

Provisioning-Metriken-Sammlung verfolgt Volume-Erstellungszeiten, Erfolgsraten und Fehlermuster für Performance-Analyse:

# ServiceMonitor für Dynamic Provisioning Metriken
apiVersion: monitoring.coreos.com/v1
kind: ServiceMonitor
metadata:
  name: storage-provisioner-metrics
spec:
  selector:
    matchLabels:
      app: csi-provisioner
  endpoints:
  - port: metrics
    interval: 30s
    path: /metrics

Wichtige Provisioning-Metriken: - Volume-Erstellungszeit (Durchschnitt und 95. Perzentil) - Bereitstellungs-Erfolgsrate nach Storage-Class - Fehlerverteilung nach Fehlertyp - Backend-Kapazitätsauslastung - Queue-Tiefe für ausstehende Bereitstellungsanfragen

36.10.2 Capacity-Trending-Analyse

Capacity-Trending-Analyse überwacht Storage-Wachstumsmuster für proaktive Kapazitätsplanung:

# PrometheusRule für Storage-Capacity-Alerting
apiVersion: monitoring.coreos.com/v1
kind: PrometheusRule
metadata:
  name: storage-capacity-alerts
spec:
  groups:
  - name: storage-capacity
    rules:
    - alert: StoragePoolNearFull
      expr: |
        (
          (storage_pool_capacity_bytes - storage_pool_available_bytes) / 
          storage_pool_capacity_bytes
        ) > 0.80
      for: 5m
      annotations:
        summary: "Storage pool {{ $labels.pool_name }} is {{ $value | humanizePercentage }} full"
    
    - alert: StorageProvisioningFailing
      expr: |
        rate(storage_provisioning_failures_total[5m]) > 0.1
      for: 2m
      annotations:
        summary: "Storage provisioning failing at {{ $value }} failures/second"

36.10.3 Cost-Tracking

Cost-Tracking für dynamisch bereitgestellten Storage ermöglicht nutzungsbasierte Kostenzuordnung:

# ConfigMap für Cost-Tracking-Konfiguration
apiVersion: v1
kind: ConfigMap
metadata:
  name: storage-cost-config
data:
  pricing.yaml: |
    storageclasses:
      premium-ssd:
        costPerGBMonth: 0.25
        costPerIOPS: 0.006
      standard:
        costPerGBMonth: 0.10
        costPerIOPS: 0.002
      archive:
        costPerGBMonth: 0.05
        costPerIOPS: 0.001
    # Chargeback-Labels für Kostenzuordnung
    chargebackLabels:
    - team
    - project
    - environment

36.11 Single-Node Dynamic Provisioning

36.11.1 Local-Storage-Optimierung

Local-Storage-Dynamic-Provisioning in Single-Node-Umgebungen nutzt Host-Storage-Ressourcen für automatische Volume-Erstellung ohne externe Abhängigkeiten:

# Local Storage Class für Single-Node
apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
  name: local-dynamic
provisioner: rancher.io/local-path
parameters:
  # Host-Pfad für Volume-Erstellung
  nodePath: /opt/local-path-provisioner
  # Berechtigung für erstellte Directories
  permission: "0755"
reclaimPolicy: Delete
volumeBindingMode: WaitForFirstConsumer

36.11.2 Ressourcen-Constraint-Bewusstsein

Resource-Constraint-Awareness in Single-Node-Deployments implementiert intelligente Ressourcenallokation basierend auf verfügbaren Host-Ressourcen:

# ResourceQuota für Single-Node-Umgebungen
apiVersion: v1
kind: ResourceQuota
metadata:
  name: single-node-storage-quota
spec:
  hard:
    # Begrenzte Storage-Kapazität
    requests.storage: 100Gi
    # Begrenzte Anzahl von PVCs
    persistentvolumeclaims: 20
    # Storage-Class-spezifische Limits
    local-dynamic.storageclass.storage.k8s.io/requests.storage: 80Gi

36.11.3 Development-optimierte Workflows

Schnelle Bereitstellungsoptimierung für Entwicklungszyklen minimiert Storage-Bereitstellungslatenz für verbesserte Entwicklererfahrung:

# Fast-Provisioning Storage Class für Entwicklung
apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
  name: dev-fast
  annotations:
    storageclass.kubernetes.io/is-default-class: "true"
provisioner: hostpath.csi.k8s.io
parameters:
  # Schnelle Bereitstellung ohne Formatierung
  fsType: ""
  # Keine Verschlüsselung für bessere Performance
  encryption: "false"
reclaimPolicy: Delete
volumeBindingMode: Immediate  # Sofortige Bereitstellung
allowVolumeExpansion: true

36 Dynamische Bereitstellung von Speicher