Skip to Content
Low-CodeDeploymentKubernetes Deployment

Kubernetes Deployment

LowCode lässt sich in Kubernetes-Clustern betreiben. Diese Anleitung zeigt die notwendigen Ressourcen: Deployment, Service, Ingress und PersistentVolumeClaim.

Voraussetzungen

  • Kubernetes-Cluster (1.24+)
  • kubectl konfiguriert
  • Ingress Controller installiert (z.B. NGINX Ingress)
  • Zugriff auf das Docker Image (marketplace.processcube.io/processcube-io/processcube_lowcode:latest)

Namespace erstellen

kubectl create namespace processcube

ConfigMap für Umgebungsvariablen

Speichern Sie die Konfiguration in einer ConfigMap:

configmap.yaml
apiVersion: v1
kind: ConfigMap
metadata:
  name: lowcode-config
  namespace: processcube
data:
  NODERED_PORT: "1880"
  NODERED_NAME: "ProcessCube LowCode"
  NODERED_BASE_URL: "https://lowcode.example.com"
  NODERED_THEME: "processcube"
  ENGINE_URL: "http://engine-service:8000"
  NODERED_AUTHORITY_URL: "https://authority.example.com"
  NODERED_CLIENT_ID: "NodeRedEditorClient"
  NODERED_AUTH_ADDITIONAL_SCOPES: "lanes engine_read engine_write"
  NODERED_DASHBOARD_CLIENT_ID: "NodeRedDashboardClient"
  NODERED_DASHBOARD_AUTH_ADDITIONAL_SCOPES: "lanes engine_read engine_write"
  NODERED_FLOW_STORAGE_OUTPUT_FORMAT: "yaml"
  NODERED_FLOW_STORAGE_SAVE_BY_NODE: "false"
  NODERED_LOG_LEVEL: "warn"
  PROMETHEUS_COLLECT_DEFAULT_METRICS: "true"

Secret für sensible Daten

kubectl create secret generic lowcode-secrets \
  --namespace processcube \
  --from-literal=NODERED_CREDENTIAL_SECRET="$(openssl rand -base64 48)" \
  --from-literal=NODERED_CLIENT_SECRET="editor-secret" \
  --from-literal=NODERED_DASHBOARD_CLIENT_SECRET="dashboard-secret"

Alternativ als YAML-Datei (base64-kodiert):

secret.yaml
apiVersion: v1
kind: Secret
metadata:
  name: lowcode-secrets
  namespace: processcube
type: Opaque
data:
  NODERED_CREDENTIAL_SECRET: <base64-kodierter-wert>
  NODERED_CLIENT_SECRET: <base64-kodierter-wert>
  NODERED_DASHBOARD_CLIENT_SECRET: <base64-kodierter-wert>

PersistentVolumeClaim

LowCode benötigt persistenten Speicher für Flows, Credentials und statische Dateien:

pvc.yaml
apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: lowcode-data
  namespace: processcube
spec:
  accessModes:
    - ReadWriteOnce
  storageClassName: standard
  resources:
    requests:
      storage: 5Gi

Hinweis: Passen Sie die storageClassName an Ihren Cluster an (z.B. gp3 für AWS, managed-premium für Azure, standard für lokale Cluster).

Deployment

deployment.yaml
apiVersion: apps/v1
kind: Deployment
metadata:
  name: lowcode
  namespace: processcube
  labels:
    app: lowcode
spec:
  replicas: 1
  selector:
    matchLabels:
      app: lowcode
  template:
    metadata:
      labels:
        app: lowcode
      annotations:
        prometheus.io/scrape: "true"
        prometheus.io/port: "1880"
        prometheus.io/path: "/metrics"
    spec:
      containers:
        - name: lowcode
          image: marketplace.processcube.io/processcube-io/processcube_lowcode:latest
          ports:
            - containerPort: 1880
              name: http
              protocol: TCP
          envFrom:
            - configMapRef:
                name: lowcode-config
            - secretRef:
                name: lowcode-secrets
          readinessProbe:
            httpGet:
              path: /readiness
              port: 1880
            initialDelaySeconds: 15
            periodSeconds: 10
            timeoutSeconds: 5
            failureThreshold: 3
          livenessProbe:
            httpGet:
              path: /readiness
              port: 1880
            initialDelaySeconds: 30
            periodSeconds: 30
            timeoutSeconds: 5
            failureThreshold: 5
          resources:
            requests:
              memory: "512Mi"
              cpu: "500m"
            limits:
              memory: "1Gi"
              cpu: "1000m"
          volumeMounts:
            - name: data
              mountPath: /data
      volumes:
        - name: data
          persistentVolumeClaim:
            claimName: lowcode-data

Probes im Detail

ProbeEndpunktZweck
ReadinessGET /readinessPrüft, ob Node-RED gestartet und bereit ist. Der Endpunkt wird von der Runtime Extension bereitgestellt.
LivenessGET /readinessPrüft, ob der Container noch reagiert. Bei wiederholtem Fehler wird der Container neugestartet.

Die Readiness Probe sorgt dafür, dass erst Traffic an den Pod geleitet wird, wenn Node-RED vollständig initialisiert ist. Die Liveness Probe startet den Container bei Hängern automatisch neu.

Resource Limits

Passen Sie die Ressourcen an Ihre Workload an:

WorkloadCPU RequestCPU LimitMemory RequestMemory Limit
Klein (wenige Flows)250m500m256Mi512Mi
Mittel (Standard)500m1000m512Mi1Gi
Gross (viele Flows, Dashboard)1000m2000m1Gi2Gi

Service

service.yaml
apiVersion: v1
kind: Service
metadata:
  name: lowcode-service
  namespace: processcube
  labels:
    app: lowcode
spec:
  type: ClusterIP
  ports:
    - port: 1880
      targetPort: 1880
      protocol: TCP
      name: http
  selector:
    app: lowcode

Ingress

ingress.yaml
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: lowcode-ingress
  namespace: processcube
  annotations:
    nginx.ingress.kubernetes.io/proxy-read-timeout: "300"
    nginx.ingress.kubernetes.io/proxy-send-timeout: "300"
    nginx.ingress.kubernetes.io/proxy-connect-timeout: "60"
    # WebSocket-Unterstützung (erforderlich für Node-RED Editor)
    nginx.ingress.kubernetes.io/proxy-http-version: "1.1"
    nginx.ingress.kubernetes.io/configuration-snippet: |
      proxy_set_header Upgrade $http_upgrade;
      proxy_set_header Connection "upgrade";
    # Optional: cert-manager fuer automatische TLS-Zertifikate
    cert-manager.io/cluster-issuer: "letsencrypt-prod"
spec:
  ingressClassName: nginx
  tls:
    - hosts:
        - lowcode.example.com
      secretName: lowcode-tls
  rules:
    - host: lowcode.example.com
      http:
        paths:
          - path: /
            pathType: Prefix
            backend:
              service:
                name: lowcode-service
                port:
                  number: 1880

Wichtig: Die WebSocket-Konfiguration in den Ingress-Annotations ist für den Node-RED-Editor zwingend erforderlich. Ohne WebSocket-Unterstützung funktioniert der Editor nicht korrekt.

Alle Ressourcen anwenden

# Alle YAML-Dateien anwenden
kubectl apply -f configmap.yaml
kubectl apply -f pvc.yaml
kubectl apply -f deployment.yaml
kubectl apply -f service.yaml
kubectl apply -f ingress.yaml
 
# Status prüfen
kubectl get pods -n processcube
kubectl get svc -n processcube
kubectl get ingress -n processcube

Skalierungshinweise

Node-RED ist grundsätzlich als Single-Instance-Anwendung konzipiert. Das bedeutet:

  • Replicas = 1: Setzen Sie in der Regel nur eine Replica ein
  • Kein horizontales Scaling: Mehrere Replicas würden zu Konflikten bei der Flow-Verwaltung führen
  • Vertikales Scaling: Erhöhen Sie bei Bedarf die Resource Limits

Wenn Sie mehrere unabhängige LowCode-Instanzen benötigen (z.B. pro Mandant), deployen Sie separate Deployments mit eigenen PVCs:

# Deployment fuer Mandant A
metadata:
  name: lowcode-mandant-a
spec:
  template:
    spec:
      volumes:
        - name: data
          persistentVolumeClaim:
            claimName: lowcode-data-mandant-a

Troubleshooting

Pod startet nicht

# Pod-Status prüfen
kubectl describe pod -l app=lowcode -n processcube
 
# Logs anzeigen
kubectl logs -l app=lowcode -n processcube
 
# Events prüfen
kubectl get events -n processcube --sort-by='.lastTimestamp'

Readiness Probe schlägt fehl

  • Erhöhen Sie initialDelaySeconds, wenn Node-RED mehr Zeit zum Starten benötigt
  • Prüfen Sie, ob die Runtime Extensions korrekt installiert sind
  • Prüfen Sie die Container-Logs auf Startfehler

Volume-Berechtigungen

Node-RED läuft als User node-red (UID 1000). Stellen Sie sicher, dass das PersistentVolume die korrekten Berechtigungen hat:

spec:
  template:
    spec:
      securityContext:
        runAsUser: 1000
        runAsGroup: 1000
        fsGroup: 1000

Nächste Schritte

Eigenes Docker Image erstellenProduktiv-Konfiguration