Container-Plattformen fuer Energieversorger und Stadtwerke

TL;DR

• Kubernetes loest das Kernproblem der Energiebranche: monolithische Legacy-Systeme, die mit der Geschwindigkeit der Energiewende nicht mithalten.
• Eine Referenzarchitektur mit zentralem Cluster plus K3s-Edge-Nodes deckt sowohl Rechenzentrum als auch Umspannwerk ab.
• cert-manager, Network Policies und RBAC sind keine Extras, sondern Pflicht, wenn DSGVO und BSI-Grundschutz gelten.
• Ein realistischer Einstieg dauert 90 Tage -- vom PoC bis zum ersten produktiven Workload.
• Die hoehere Ressourcenauslastung durch Container rechnet sich ab dem zweiten Jahr messbar gegenueber klassischen VM-Stacks.

Ausgangslage: Warum die klassische IT nicht mehr reicht

Stadtwerke und regionale Energieversorger betreiben haeufig noch monolithische Java-Applikationen auf dedizierten VMs. Neue Anforderungen -- Smart Meter Rollout, Ladeinfrastruktur, dynamische Tarife -- erfordern aber kurze Release-Zyklen und horizontale Skalierung. Genau das liefert eine Container-Plattform.

Die entscheidenden Argumente aus der Praxis:

Das bedeutet nicht, dass jede Applikation sofort migriert werden muss. Aber fuer neue Services -- Zaehlerdaten-Pipelines, Kundenportale, Prognose-APIs -- ist ein Container-first-Ansatz sinnvoll.

Referenzarchitektur

Die folgende Architektur hat sich fuer mittlere Stadtwerke (50-200 IT-Nutzer) bewaehrt. Sie laesst sich sowohl on-premise als auch in einer Private Cloud betreiben.

Zentrale Komponenten:

• Control Plane: 3 Master-Nodes (HA), etcd als Cluster-Store
• Worker Nodes: 4-8 Nodes, aufgeteilt in Pools (general-purpose, memory-optimized fuer Zeitreihen-DBs)
• CNI: Calico fuer Network Policies und Netzwerksegmentierung
• CSI: Rook-Ceph oder NetApp Trident fuer persistenten Storage
• Ingress: NGINX Ingress Controller mit TLS-Terminierung via cert-manager
• Monitoring: Prometheus + Grafana (siehe auch Kubernetes Monitoring: Kosten senken mit Open Source)
• Logging: Loki oder ELK-Stack fuer zentrales Log-Management
• CI/CD: GitLab CI oder Argo CD fuer deklarative Deployments

Edge Layer (optional, empfohlen fuer Smart Grid):

K3s auf ARM-basierten Gateways in Umspannwerken oder bei Grosskunden. Diese Edge-Nodes fuehren Vorverarbeitung und Filterung durch und senden aggregierte Daten ueber MQTT/Kafka an den zentralen Cluster.

Deployment-Beispiel: Smart Meter Parser

apiVersion: apps/v1
kind: Deployment
metadata:
  name: smart-meter-parser
  namespace: metering
  labels:
    app: smart-meter-parser
    team: data-engineering
spec:
  replicas: 3
  selector:
    matchLabels:
      app: smart-meter-parser
  template:
    metadata:
      labels:
        app: smart-meter-parser
    spec:
      containers:
      - name: parser
        image: registry.internal/metering/smart-meter-parser:2.4.1
        ports:
        - containerPort: 8080
        resources:
          requests:
            memory: "128Mi"
            cpu: "100m"
          limits:
            memory: "256Mi"
            cpu: "250m"
        env:
        - name: KAFKA_BROKERS
          value: "kafka.messaging.svc.cluster.local:9092"
        - name: DB_HOST
          valueFrom:
            secretKeyRef:
              name: timescaledb-credentials
              key: host
        livenessProbe:
          httpGet:
            path: /healthz
            port: 8080
          initialDelaySeconds: 10
          periodSeconds: 15
        readinessProbe:
          httpGet:
            path: /ready
            port: 8080
          initialDelaySeconds: 5
          periodSeconds: 10
---
apiVersion: v1
kind: Service
metadata:
  name: smart-meter-parser
  namespace: metering
spec:
  selector:
    app: smart-meter-parser
  ports:
  - protocol: TCP
    port: 80
    targetPort: 8080

Wichtig: Liveness- und Readiness-Probes sind kein Nice-to-have. Ohne sie kann Kubernetes nicht sauber zwischen "Applikation haengt" und "Applikation startet noch" unterscheiden.

Network Policy: Isolation der Metering-Namespace

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: restrict-metering-ingress
  namespace: metering
spec:
  podSelector: {}
  policyTypes:
  - Ingress
  ingress:
  - from:
    - namespaceSelector:
        matchLabels:
          purpose: data-ingestion
    - podSelector:
        matchLabels:
          role: kafka-consumer
    ports:
    - protocol: TCP
      port: 8080

Diese Policy erlaubt eingehenden Traffic in den metering-Namespace nur aus dem Data-Ingestion-Namespace und nur an Port 8080. Alles andere wird blockiert. In einer Umgebung mit SCADA-Anbindung ist diese Segmentierung nicht optional.

HPA fuer lastabhaengige Skalierung

apiVersion: autoscaling/v2
kind: HorizontalPodAutoscaler
metadata:
  name: smart-meter-parser-hpa
  namespace: metering
spec:
  scaleTargetRef:
    apiVersion: apps/v1
    kind: Deployment
    name: smart-meter-parser
  minReplicas: 3
  maxReplicas: 12
  metrics:
  - type: Resource
    resource:
      name: cpu
      target:
        type: Utilization
        averageUtilization: 65

Damit skaliert der Parser automatisch hoch, wenn die CPU-Last steigt -- etwa beim morgendlichen Batch-Import von Smart-Meter-Daten.

OT-Integration: Was geht, was nicht

Eine haeufige Frage: Kann Kubernetes direkt mit SCADA-Systemen kommunizieren? Die kurze Antwort: Nein, und das sollte es auch nicht.

SCADA-Systeme unterliegen anderen Echtzeitanforderungen und Sicherheitszertifizierungen (IEC 62443). Kubernetes dient als Datenplattform oberhalb der OT-Schicht. Daten fliessen ueber spezialisierte Gateways (OPC-UA-Server, MQTT-Broker) vom Feld in den Cluster. Dort werden sie in containerisierten Pipelines verarbeitet -- fuer Analysen, Prognosen oder Dashboards. Die Steuerung kritischer Infrastruktur bleibt in der OT-Welt.

DSGVO und BSI-Grundschutz

Fuer Energieversorger gelten erhoehte Anforderungen, insbesondere wenn sie als KRITIS-Betreiber eingestuft sind. Die wichtigsten Massnahmen auf Kubernetes-Ebene:

• Datenlokalitaet: Cluster on-premise oder in einem Rechenzentrum innerhalb der EU betreiben. Damit bleiben personenbezogene Daten (Kundenstammdaten, Verbrauchsprofile) unter Kontrolle.
• RBAC: Granulare Rechtevergabe. Entwickler bekommen Zugriff auf Dev-Namespaces, nicht auf Production. Siehe Kubernetes Security Hardening fuer Details.
• Network Policies: Wie oben gezeigt -- jede Namespace-Grenze ist eine Sicherheitsgrenze.
• Image Scanning: Trivy oder Grype in der CI/CD-Pipeline, bevor ein Image in die Registry kommt.
• Audit Logging: API-Server Audit Logs aktivieren und an das zentrale SIEM weiterleiten.
• Verschluesselung: etcd-Encryption-at-Rest, TLS fuer alle internen Kommunikationspfade via cert-manager und PKI.

90-Tage-Plan: Vom PoC zum ersten Workload

Woche 1-4: Fundament legen

• Kick-off mit IT-Leitung und Fachbereichen: Use Cases priorisieren (nicht alles auf einmal)
• Kernteam schulen: Docker-Grundlagen, kubectl, Kubernetes-Objekte
• Hardware/Cloud evaluieren: On-premise vs. Managed Kubernetes (Kostenvergleich siehe Kubernetes Hosting Kosten)
• PoC-Cluster aufsetzen (K3s oder kubeadm auf 3 Nodes)
• Erste Container-Images bauen: Dockerfiles, Multi-Stage Builds, Image-Scanning

Woche 5-8: Pilotprojekt umsetzen

• Eine nicht-kritische Applikation containerisieren (z.B. internes Reporting-Tool oder Kundenportal-API)
• CI/CD-Pipeline einrichten (GitLab CI oder Argo CD)
• Monitoring deployen: Prometheus, Grafana, erste Alerting-Regeln
• Zentrales Logging aufsetzen
• Network Policies und RBAC fuer den Pilot-Namespace konfigurieren

Woche 9-12: Haerten und dokumentieren

• Lasttests durchfuehren, Ressourcen-Requests/Limits feinjustieren
• Backup-Strategie implementieren (Velero fuer Cluster-Backups, separate DB-Backups)
• Disaster Recovery testen: Node-Ausfall simulieren, Recovery-Zeit messen
• Dokumentation erstellen: Architektur, Runbooks, Troubleshooting-Guides
• Review: Was lief gut, was muss fuer den naechsten Workload angepasst werden?

Kosten: Was ist realistisch?

Die Kosten haengen stark davon ab, ob on-premise oder managed Cloud gewaehlt wird. Eine grobe Orientierung fuer einen mittleren Stadtwerk-Cluster:

Ab dem zweiten Jahr sinken die Kosten deutlich, da Schulung und Setup entfallen. Die Einsparungen durch hoehere Ressourcenauslastung (weniger Server), schnellere Deployments (weniger Personalaufwand) und weniger Ausfaelle machen sich ab Monat 12-18 bemerkbar.

Detaillierte Vergleichsrechnung: Kubernetes Hosting Kosten: Cloud vs. On-Premise.

Typische Stolpersteine

Storage unterschaetzt: Zeitreihen-Datenbanken (TimescaleDB, InfluxDB) brauchen performanten persistenten Storage. Rook-Ceph funktioniert, erfordert aber eigenes Know-how. Bei kleinen Teams kann ein NFS-Provisioner fuer den Anfang reichen.

Zu viel auf einmal migrieren: Starten Sie mit einem neuen Service, nicht mit dem ERP-System. Der Lerneffekt ist groesser, das Risiko kleiner.

Monitoring als Nachgedanke: Prometheus und Grafana gehoeren vom Tag 1 in den Cluster. Ohne Observability fliegen Sie blind.

RBAC ignoriert: "Erstmal alle als cluster-admin" ist der schnellste Weg zu einem Sicherheitsvorfall. Investieren Sie frueh in ein durchdachtes Rollenkonzept.

Fazit

Container-Plattformen mit Kubernetes sind kein Hype-Thema mehr, sondern eine pragmatische Antwort auf die IT-Anforderungen der Energiewende. Die Kombination aus zentralem Cluster und Edge-Nodes passt zur dezentralen Struktur der Energiewirtschaft. Der Einstieg muss nicht mit einem Big-Bang erfolgen -- ein fokussierter 90-Tage-Plan mit einem konkreten Pilotprojekt liefert schnelle Ergebnisse und baut internes Know-how auf.

Wenn Sie Unterstuetzung bei der Planung oder Umsetzung brauchen -- von der Architekturberatung bis zum Hands-on-Workshop -- sprechen Sie uns an unter /kontakt.