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 zu containerisieren und auf einem Kubernetes-Cluster zu betreiben und 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- 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: