Configuration / Storage · Stand 2026-07-07

05 ConfigMaps, Secrets, Storage und PVC

ConfigMaps speichern nicht-sensitive Konfiguration, Secrets sensible Werte, PVCs fordern persistente Volumes an. Dynamic Provisioning erzeugt Volumes über StorageClasses bedarfsgerecht.

Diagramm zu 05 ConfigMaps, Secrets, Storage und PVC
Kompakte fachliche und technische Darstellung.

Fachliche Erklärung

Container sind vergänglich. Alles, was dauerhaft bleiben muss, gehört nicht in den Container-Layer, sondern in Datenbank, Object Storage, Queue oder ein Persistent Volume.

Konfiguration gehört nicht fest ins Image. Dasselbe Image soll in Dev, Test und Prod laufen können. Unterschiede kommen aus ConfigMaps, Secrets, Environment und GitOps-Werten.

Storage-Entscheidungen

ReadWriteOnce passt oft für Datenbanken oder einzelne Writer.

ReadWriteMany wird benötigt, wenn mehrere Pods gleichzeitig schreiben müssen, ist aber backendabhängig.

Logs gehören normalerweise nach stdout/stderr, nicht auf ein PVC.

Exports, temporäre Dateien und Batch-Artefakte brauchen Retention-Regeln.

Secret-Grundregel

Kubernetes Secrets sind nicht automatisch ein vollständiger Vault-Ersatz.

In Enterprises nutzt man oft External Secrets, Vault, SealedSecrets oder Cloud-KMS-Integration.

Secrets niemals in Git im Klartext ablegen.

Ausführliches Enterprise-Beispiel

Das Beispiel folgt einer fiktiven Shop-Landschaft mit order-api, billing-api, payment-api, portal-ui, Batch-Export und Messaging. Der Fokus liegt auf sauberem Verständnis statt auf blindem Kopieren.

Fachlicher Ablauf

  1. Kunde bestellt über Portal.
  2. order-api validiert Auftrag.
  3. billing-api erzeugt Rechnung.
  4. payment-api prüft Zahlung.
  5. Events informieren Lager und Reporting.

Technischer Ablauf

  1. Route nimmt HTTPS an.
  2. Service verteilt auf Pods.
  3. Pods lesen ConfigMaps und Secrets.
  4. Readiness schützt Rollout.
  5. Monitoring misst Fehlerquote und Latenz.

Konfigurations- und Codebeispiele

YAML

apiVersion: v1
kind: ConfigMap
metadata:
  name: order-api-config
data:
  application.yaml: |
    payment:
      base-url: https://payment-api.shop.svc:8443
    feature:
      invoice-v2: "true"
---
apiVersion: v1
kind: Secret
metadata:
  name: order-api-secret
type: Opaque
stringData:
  datasource.username: order_user
  datasource.password: change-me-via-external-secret
---
apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: order-export-pvc
spec:
  accessModes: ["ReadWriteOnce"]
  storageClassName: fast-csi
  resources:
    requests:
      storage: 20Gi

BASH

oc -n shop create configmap order-api-config --from-file=application.yaml
oc -n shop create secret generic order-api-secret --from-literal=datasource.password=***
oc -n shop get pvc,pv
oc -n shop describe pvc order-export-pvc

Typische Fehlerbilder und Diagnose

Pending Pods

Prüfe Ressourcen, Node-Selector, Taints, PVC und Quotas. Nicht sofort am Java-Code suchen.

CrashLoopBackOff

Prüfe Logs des vorherigen Containers, Config/Secrets, Port, JVM Memory und Health Endpoints.

Route erreichbar, App nicht

Prüfe Service-Selector, Endpoints, Readiness, TLS-Termination und NetworkPolicy.

Praxisaufgabe

Entscheide für eine Billing-App: Was ist Konfiguration, was ist Secret, was ist Datenbankinhalt, was ist temporärer Export?

Merksätze

  • Deklarativer Zustand ist wichtiger als manuelle Serveränderung.
  • Security und Betrieb gehören von Anfang an zum Deployment.
  • Jede YAML-Datei ist Architekturentscheidung und sollte reviewbar sein.
  • Produktionsreife entsteht durch Messbarkeit, Rollback und klare Ownership.