Simulator · Kubernetes Deployment

Kontext & Motivation

Das ursprüngliche BHKW-Testprojekt simulierte einen Anlagenregler über Modbus TCP und REST API. Ziel dieser Erweiterung war es, diesen Simulator professionell zu containerisieren und auf einem Kubernetes-Cluster zu betreiben — mit automatischem Neustart bei Ausfällen (Self-Healing) und Health Checks, wie es in echten Produktionsumgebungen üblich ist.

1 — Architektur

Vom Code bis zum laufenden, überwachten Pod im Cluster:

2 — Kubernetes Manifeste

Deployment — Pod-Verwaltung & Health Checks

apiVersion: apps/v1
kind: Deployment
metadata:
  name: bhkw-simulator
spec:
  replicas: 1
  template:
    spec:
      containers:
        - name: bhkw-simulator
          image: bhkw-simulator:v2
          ports:
            - containerPort: 5020
            - containerPort: 8080
          livenessProbe:
            httpGet:
              path: /health
              port: 8080
            initialDelaySeconds: 5
            periodSeconds: 10
          readinessProbe:
            httpGet:
              path: /health
              port: 8080
            initialDelaySeconds: 3
            periodSeconds: 5

Service — Stabile Netzwerk-Erreichbarkeit

apiVersion: v1
kind: Service
metadata:
  name: bhkw-simulator-service
spec:
  type: NodePort
  ports:
    - name: modbus
      port: 5020
      nodePort: 30020
    - name: rest-api
      port: 8080
      nodePort: 30080

3 — Realer Bug während der Entwicklung

Diagnose: Der Container selbst lief fehlerfrei — ein direkter Test mit kubectl exec bestätigte, dass die REST API innerhalb des Containers korrekt antwortete.

Root Cause: uvicorn und der Modbus-Server waren auf localhost gebunden. Kubernetes Health Probes greifen jedoch über die Pod-IP von außerhalb des Containers zu — localhost ist aus dieser Perspektive nicht erreichbar.

# Vorher (funktioniert nicht in Kubernetes)
start_api(simulator, host='localhost', port=8080)

# Nachher (funktioniert)
start_api(simulator, host='0.0.0.0', port=8080)

4 — End-to-End Validierung

Drei neue Robot Framework Tests validieren das komplette deployte System — exakt dieselbe Testbibliothek wie im Original-Projekt, nur gegen die Kubernetes-Service-Endpunkte gerichtet:

5 — Zusammenfassung

6 — Ausblick

• 1
  Helm Chart
  Verpackung des Deployments als Helm Chart für wiederverwendbares, parametrisierbares Deployment.
• 2
  CI/CD Integration
  GitHub Actions Pipeline, die automatisch baut, auf ein Cluster deployed und die Robot Framework Tests ausführt.
• 3
  Horizontal Pod Autoscaling
  Automatische Skalierung mehrerer Simulator-Instanzen je nach Lastanforderung.
• 4
  Cloud-Cluster (GKE/AKS)
  Migration vom lokalen Minikube zu einem echten Cloud-Kubernetes-Cluster.