MQTT-Broker auf Kubernetes betreiben oder einen verwalteten MQTT-Broker nutzen?

Einen MQTT-Broker auf Kubernetes zu betreiben liegt nahe, wenn Ihr Team ohnehin alles andere dort deployt. Dieser Artikel vergleicht diesen Weg mit einem verwalteten MQTT-Broker hinsichtlich Aufwand, Upgrades, Zuverlässigkeit und Kostentreibern und liefert Ihnen ein funktionierendes Manifest zum Ausprobieren. Danach wissen Sie, was Kubernetes für einen Broker löst, was nicht, und welche Option zu Ihrem Team passt.

Warum Teams Kubernetes für MQTT in Betracht ziehen

Kubernetes bietet deklarative Deployments, selbstheilende Pods, Rolling Updates, Secrets-Management und eine einheitliche Toolchain. Wenn Ihre Backend-Services, Datenbanken und Ihr Observability-Stack bereits in einem Cluster laufen, bleibt mit dem Broker dort alles an einem Ort, und Subscriber erreichen ihn über das Cluster-Netzwerk.

Ein MQTT-Broker ist jedoch kein typischer zustandsloser Webservice. Wer versteht, was ein MQTT-Broker tut, erkennt den Grund: Er hält langlebige TCP-Verbindungen, speichert den Sitzungszustand für Offline-Clients, verwaltet Retained Messages und verteilt jede Nachricht an alle passenden Subscriber. Diese Eigenschaften kollidieren mit mehreren Grundannahmen von Kubernetes.

Ein minimaler MQTT-Broker auf Kubernetes

Hier ist ein kleines, aber funktionierendes Mosquitto-Deployment mit Passwort-Authentifizierung. Es eignet sich für einen Labor-Cluster und ist ein guter Weg, die beweglichen Teile kennenzulernen.

Erstellen Sie zuerst eine Passwortdatei und speichern Sie sie als Secret:

mosquitto_passwd -c -b passwd device01 'change-this-password'
kubectl create namespace mqtt
kubectl -n mqtt create secret generic mosquitto-passwd --from-file=passwd

Wenden Sie anschließend Konfiguration, Deployment und Service an:

apiVersion: v1
kind: ConfigMap
metadata:
  name: mosquitto-config
  namespace: mqtt
data:
  mosquitto.conf: |
    listener 1883
    allow_anonymous false
    password_file /mosquitto/secret/passwd
    persistence true
    persistence_location /mosquitto/data/
---
apiVersion: apps/v1
kind: StatefulSet
metadata:
  name: mosquitto
  namespace: mqtt
spec:
  serviceName: mosquitto
  replicas: 1
  selector:
    matchLabels:
      app: mosquitto
  template:
    metadata:
      labels:
        app: mosquitto
    spec:
      terminationGracePeriodSeconds: 30
      containers:
        - name: mosquitto
          image: eclipse-mosquitto:2
          ports:
            - containerPort: 1883
          volumeMounts:
            - name: config
              mountPath: /mosquitto/config
            - name: passwd
              mountPath: /mosquitto/secret
            - name: data
              mountPath: /mosquitto/data
          resources:
            requests:
              cpu: 100m
              memory: 64Mi
            limits:
              memory: 256Mi
      volumes:
        - name: config
          configMap:
            name: mosquitto-config
        - name: passwd
          secret:
            secretName: mosquitto-passwd
  volumeClaimTemplates:
    - metadata:
        name: data
      spec:
        accessModes: ["ReadWriteOnce"]
        resources:
          requests:
            storage: 1Gi
---
apiVersion: v1
kind: Service
metadata:
  name: mosquitto
  namespace: mqtt
spec:
  type: LoadBalancer
  selector:
    app: mosquitto
  ports:
    - name: mqtt
      port: 1883
      targetPort: 1883

Testen Sie von außerhalb des Clusters, sobald der Load Balancer eine Adresse hat:

mosquitto_sub -h <LOAD_BALANCER_IP> -p 1883 -u device01 -P 'change-this-password' -i k8s-sub -t 'test/#' -v

Das funktioniert, aber beachten Sie, was fehlt: TLS, Zertifikatserneuerung, Monitoring, Alerting, Backups und jede Form von Hochverfügbarkeit. Genau dort liegt der eigentliche Aufwand.

Was Kubernetes für MQTT nicht löst

Langlebige Verbindungen und Rolling Updates

Ein Rolling Update ersetzt Pods nacheinander. Bei einem HTTP-Service merkt das niemand. Bei einem Broker trennt jeder Pod-Neustart alle seine Clients auf einmal, und diese verbinden sich gleichzeitig neu. Node-Drains, Cluster-Upgrades und die Konsolidierung durch den Autoscaler lösen denselben Effekt aus. Sie brauchen Geräte mit zufälligem exponentiellem Backoff, ein PodDisruptionBudget und Wartungsfenster für Änderungen am Broker.

Zustand und Speicher

Persistente Sitzungen und Retained Messages benötigen Speicher, der ein Rescheduling des Pods übersteht. Ein StatefulSet mit Persistent Volumes erledigt das für einen einzelnen Knoten, doch Volumes sind meist an eine Availability Zone gebunden, was einschränkt, wohin der Pod bei einem Ausfall wandern kann.

Load Balancing ist kein Clustering

Einen Single-Node-Broker hinter einem Load Balancer auf drei Replikas zu skalieren, ergibt keinen Cluster. Jede Replika wäre ein unabhängiger Broker, und ein Publisher auf der einen würde keinen Subscriber auf einer anderen erreichen. Echte horizontale Skalierung erfordert einen Broker, der für Clustering ausgelegt ist und meist per Helm-Chart oder Kubernetes-Operator des Herstellers deployt wird. Der Vergleich der Open-Source-MQTT-Broker zeigt, welche Projekte das unterstützen.

TLS am Rand des Clusters

Sie können TLS am Cloud-Load-Balancer oder am Broker terminieren. Die Terminierung am Broker erhält die Ende-zu-Ende-Verschlüsselung, bedeutet aber, Zertifikate zu mounten und bei der Erneuerung neu zu laden, typischerweise mit cert-manager. Die Terminierung am Load Balancer ist einfacher, erfordert aber Sorgfalt, wenn Sie auf Client-Zertifikate setzen.

Observability

Sie müssen Broker-Metriken in Ihren Monitoring-Stack exportieren, Dashboards bauen und Alarme für Verbindungsabbrüche, Nachrichtenraten und Ressourcenverbrauch definieren. Unter MQTT-Broker-Monitoring finden Sie die Metriken, auf die es ankommt.

Kubernetes vs. verwalteter MQTT-Broker im direkten Vergleich

Die Kostentreiber verstehen

Ein ehrlicher Kostenvergleich blickt über die Compute-Rechnung hinaus. Bei einem auf Kubernetes gehosteten Broker umfassen die Kosten:

1. Infrastruktur: für Broker-Pods reservierte Knotenkapazität, Persistent Volumes und Load Balancer mit öffentlichen IPs.
2. Datentransfer: Egress Ihres Cloud-Anbieters für Nachrichten an Clients außerhalb der Cloud.
3. Engineering-Zeit für den Aufbau: Manifeste oder Helm-Values, TLS-Automatisierung, Authentifizierung, Dashboards und Alarme.
4. Engineering-Zeit für den Betrieb: Upgrades, Sicherheitspatches, Kapazitätsprüfungen, Incident Response und Rufbereitschaft.
5. Risiko: die Kosten eines Ausfalls oder Sicherheitsvorfalls infolge einer Fehlkonfiguration.

Bei einem verwalteten MQTT-Broker wie einem Dedicated-Cluster wandern die Punkte 3 bis 5 größtenteils ins Abonnement, und Sie zahlen für den Plan statt für die zugrunde liegende Infrastruktur. Eine nützliche Übung: Schätzen Sie die Stunden, die Ihr Team monatlich für die Punkte 3 und 4 aufwenden würde, multiplizieren Sie sie mit einem voll belasteten Stundensatz und addieren Sie das Ergebnis zur Infrastrukturposition. Vergleichen Sie diese Summe dann mit den Plankosten oder dem Angebot für eine verwaltete Option wie ConnectMQ Dedicated. Unser Leitfaden zu den Gesamtbetriebskosten eines MQTT-Brokers führt Sie durch diese Rechnung.

Wann Kubernetes die richtige Wahl ist

Den Broker selbst auf Kubernetes zu betreiben ist sinnvoll, wenn:

• Sie ein Plattform-Team haben, das zustandsbehaftete Workloads bereits gut betreibt.
• Sie Broker-Plugins oder Anpassungen benötigen, die ein verwalteter MQTT-Broker nicht bietet.
• der Broker in einem Air-Gapped- oder On-Premises-Cluster laufen muss, etwa auf einem Edge-Cluster im Werk, der den lokalen Teil eines Unified Namespace (UNS) trägt. Die Topic-Struktur folgt dann typischerweise der ISA-95-Hierarchie aus Enterprise, Site, Area, Line und Cell, zum Beispiel acme/werk-stuttgart/montage/linie-1/zelle-3/temperatur; mehr dazu unter Sparkplug B und Unified Namespace.
• Ihre Geräteanzahl stabil und gut bekannt ist.

Ein verwalteter MQTT-Broker passt meist besser, wenn Ihr Team klein ist, etwa in einem mittelständischen Betrieb ohne eigenes Plattform-Team, MQTT kritisch, aber nicht Ihr Kernprodukt ist, oder Sie schnell produktionsreif sein müssen.

Der Mittelweg: verwaltet, aber in Ihrer Cloud

Wenn Sie an Kubernetes vor allem reizt, den Broker in Ihrer eigenen Cloud-Umgebung zu halten, gibt es eine dritte Option. ConnectMQ BYOC betreibt den Broker in Ihrem Cloud-Account und ConnectMQ verwaltet ihn: Die Infrastruktur bleibt Ihre, während Upgrades, Zertifikate und das Monitoring des Brokers für Sie erledigt werden. Ein Dedicated-Plan bietet einen isolierten Cluster ganz ohne Infrastrukturarbeit auf Ihrer Seite. Beide stellen Standard-Endpunkte bereit: TCP 1883, TLS 8883, WebSocket 8083 und Secure WebSocket 8084 unter /mqtt, mit Let's-Encrypt-Zertifikaten, für Clients mit MQTT 3.1.1 und 5.0.

Starten Sie mit ConnectMQ

Bevor Sie die nächste Helm-Values-Datei schreiben, testen Sie einen verwalteten MQTT-Broker kostenlos. Legen Sie unter app.connectmq.com einen Serverless-Broker an, ganz ohne Kreditkarte, und richten Sie dieselben Clients darauf aus, die Sie auf Kubernetes getestet haben. Sie können auch sofort auf dem Öffentlichen MQTT-Broker experimentieren, der für Tests und Prototypen gedacht ist, nicht für Produktionsdaten, und im Leitfaden zum Cloud-MQTT-Broker einen breiteren Überblick über Hosting-Modelle gewinnen.

Häufig gestellte Fragen

Kann ich Mosquitto auf Kubernetes durch zusätzliche Replikas skalieren?

Nein. Jede Replika wäre ein unabhängiger Broker, sodass Nachrichten nicht zwischen ihnen fließen würden. Horizontale Skalierung erfordert einen Broker, der für Clustering gebaut ist.

Warum trennen sich meine MQTT-Clients bei Kubernetes-Upgrades?

Pod-Neustarts und Node-Drains schließen jede Verbindung auf dem betroffenen Pod. Nutzen Sie PodDisruptionBudgets, Wartungsfenster und clientseitigen Reconnect-Backoff mit Jitter.

Sollte ich TLS am Load Balancer oder am Broker terminieren?

Die Terminierung am Broker erhält die Ende-zu-Ende-Verschlüsselung und die Authentifizierung per Client-Zertifikat; die Terminierung am Load Balancer ist einfacher zu verwalten. Entscheiden Sie anhand Ihres Authentifizierungsmodells.

Ist ein verwalteter MQTT-Broker teurer als Kubernetes?

Vergleichen Sie die Gesamtkosten einschließlich der Engineering-Zeit für Setup, Upgrades und Rufbereitschaft, nicht nur die Compute-Kosten. Für viele kleine Teams ist die verwaltete Option insgesamt günstiger.