In modernen IoT- und Echtzeitanwendungen spielt die zuverlässige Übertragung von Nachrichten eine zentrale Rolle. MQTT, als ein leichtgewichtiges Messaging-Protokoll, ist dabei aufgrund seiner geringen Anforderungen und vielseitigen Einsatzmöglichkeiten besonders beliebt. Eclipse Mosquitto, einer der bekanntesten MQTT Broker, wird häufig genutzt, um eine einfache und dennoch leistungsfähige Messaging-Plattform aufzubauen. Doch eine einzelne Mosquitto Instanz kann schnell an ihre Grenzen stoßen, vor allem wenn es um Hochverfügbarkeit und Ausfallsicherheit geht. Genau hier bietet Kubernetes in Kombination mit Mosquitto eine effiziente Lösung, um eine robuste und hochverfügbare MQTT Infrastruktur zu schaffen, die mit minimalen Ausfallzeiten überzeugt und zudem eine nahtlose Skalierbarkeit ermöglicht. Die Herausforderung, wenn Mosquitto in einem klassischen Kubernetes-Setup als einzelnes Pod läuft, liegt in der fehlenden schnellen Wiederherstellung.
Bei einem Node-Ausfall oder Problemen innerhalb des Pods kann Kubernetes zwar innerhalb weniger Minuten den Dienst wiederherstellen, aber gerade in zeitkritischen IoT-Szenarien sind Verzögerungen von bis zu fünf Minuten oft nicht akzeptabel. MQTT Clients verlieren in dieser Zeit die Verbindung, was zu Datenverlusten und Fehlfunktionen in vernetzten Systemen führt. Dieses Zeitfenster ist vor allem auf den Standardwert des sogenannten node-monitor-grace-period von Kubernetes zurückzuführen, welcher häufig auf rund 300 Sekunden (5 Minuten) eingestellt ist. Eine moderne, ausfallsichere Architektur mit Mosquitto auf Kubernetes richtet sich deshalb darauf aus, Ausfallzeiten auf wenige Sekunden zu reduzieren und gleichzeitig eine lückenlose Nachrichtenweitergabe sicherzustellen. Ein praktikabler Ansatz ist, zwei Mosquitto Broker in getrennten Pods auf unterschiedlichen Kubernetes Nodes laufen zu lassen – einen Primär- und einen Sekundärbroker.
Diese zwei Instanzen werden dauerhaft miteinander gebridgt, sodass alle Nachrichten beidseitig synchronisiert werden. Falls der Primärbroker ausfällt, übernimmt der Sekundärbroker innerhalb kürzester Zeit den MQTT Traffic, ohne dass Client-Konfigurationen angepasst werden müssen. Damit das Umschalten schnell und transparent funktioniert, wird in diesem Setup ein sogenannter failover Controller implementiert. Dieser ist als leichter Kubernetes Pod ausgelegt und überwacht kontinuierlich die Erreichbarkeit und Gesundheit des Primärbrokers. Bei einem Ausfall wird die Kubernetes Service-Konfiguration dynamisch geändert, sodass die External LoadBalancer-IP sofort auf den sekundären Broker umleitet. Die Umschaltung geschieht innerhalb von Sekunden, deutlich schneller als die native Node Recovery von Kubernetes.
Im Gegensatz zu komplexeren Lösungen benötigt dieser Controller keine zusätzlichen Operatoren oder CRDs, sondern nutzt einfache Kubernetes-API-Befehle, die über geeignete RBAC-Berechtigungen abgesichert sind. Wichtig für den reibungslosen Betrieb sind außerdem einige Details bei der Konfiguration der Mosquitto Broker. Beide Broker lauschen auf eigenen Listenports, wobei der primäre Broker neben dem Hauptport 1883 noch einen internen Port 2883 für die Bridge bereitstellt, mit dem sich der sekundäre Broker verbindet. Der sekundäre Broker wiederum nutzt seinen eigenen zweiten Port 3883. Durch interne MQTT Bridge-Konfigurationen werden alle Nachrichten bidirektional synchronisiert. Retained Messages werden dadurch ebenfalls geteilt, weswegen bei einem Failover keine Nachrichten verloren gehen. Anschließend müssen sich Clients lediglich erneut verbinden, was automatisiert durchgeführt werden kann, um eine möglichst unterbrechungsfreie Kommunikation sicherzustellen.
Die Kubernetes Ressourcen sind aus mehreren Komponenten aufgebaut. Namespace und ConfigMaps strukturieren die Umgebung und enthalten die jeweiligen Broker-Konfigurationen. Die Deployments definieren die einzelnen Pods mit ihren spezifischen Port- und Liveness-Checks. Services werden genutzt, um den LoadBalancer für die externe Adresse mit dynamischem Routing zu definieren. Die RBAC-Konfiguration stellt sicher, dass der failover Pod ausreichende Rechte hat, um im Notfall die Service-Selectoren anzupassen. Darüber hinaus werden IngressRouteTCP-Ressourcen von Traefik verwendet, um die MQTT Ports über den Ingress Mechanismus transparent zugänglich zu machen, was insbesondere beim Einsatz von k3s als Kubernetes-Distribution eine einfache Integration ermöglicht. Die Liveness-Probes sind bei diesem Setup besonders intelligent aufgebaut. Anstatt nur die Netzwerkverbindung auf einem Port zu prüfen, wird aktiv eine MQTT Nachricht auf einen definierten Gesundheits-Check-Topic publishiert.
So wird garantiert, dass der Broker nicht nur erreichbar, sondern auch voll funktionsfähig ist. Bei Änderung des Broker-Status reagiert der Failover-Pod innerhalb von wenigen Sekunden, indem er die Service-Selektoren entsprechend anpasst. Diese dynamische Anpassung ist der Schlüssel für das verzögerungsarme Umschalten und die hohe Stabilität des Systems. Die Verwendung von Traefik in k3s bringt einige Besonderheiten mit sich. Standardmäßig ist Traefik in k3s nur für HTTP(S) Traffic vorkonfiguriert. Um TCP basierende Dienste wie MQTT zu routen, müssen extra Ports in der Traefik HelmChartConfig explizit definiert und freigegeben werden. Diese Custom-Configuration verhindert, dass Traefik den MQTT Traffic blockiert und ermöglicht das vollständige Routing durch IngressRouteTCP Ressourcen. So kann MQTT bei Bedarf auch über externe IP-Adresse und standardisierte Ports wie 1883 oder 2883 erreichbar gemacht werden, was für Clients ideal ist.
In der Praxis zeigt sich, dass mit dieser Architektur Ausfallzeiten von fünf Minuten auf etwa fünf Sekunden reduziert werden können. Das wurde eindrucksvoll demonstriert, indem der Netzwerkzugang des Primärknotens künstlich unterbrochen wurde. Die MQTT Clients verloren kurzzeitig die Verbindung, konnten sich aber wenige Sekunden später automatisch zum Sekundärbroker verbinden und ohne weitere Eingriffe den Betrieb fortsetzen. Sobald das Primärpod wieder stabil lief, erfolgte eine automatische Rückumschaltung. Diese schnelle Recovery und transparente Umschaltung sorgen für maximale Betriebssicherheit besonders in kritischen Anwendungsfällen. Für Entwickler, Betreiber und DevOps-Teams ergeben sich zahlreiche Vorteile aus diesem Setup. Durch die Verwendung rein deklarativer Kubernetes Ressourcen inklusive der notwendigen RBAC-Rollen und ServiceAccounts lässt sich die Lösung in jeder k3s- oder Standard-Kubernetes-Umgebung einfach ausrollen und verwalten.
Die Modularität ermöglicht das gezielte Skalieren der Failover Pods, um auch den Ausfall einzelner Knoten im Cluster ohne Serviceunterbrechung abzufangen. Erweiterungen wie persistente Volumes zur Speicherung von Mosquitto Datenbanken oder Einbindung eigener Zertifikate sind problemlos machbar. Außerdem reduziert das Setup den Administrationsaufwand im Vergleich zu komplexen operatorbasierten Lösungen deutlich. Die einfache Shell-basierte Failover-Logik in Kombination mit Kubernetes-API-Aufrufen ist leicht verständlich, auditierbar und kann ohne Abhängigkeit von externen Komponenten angepasst und erweitert werden. Somit geht die Entwicklerfreundlichkeit nicht auf Kosten der Performance oder Zuverlässigkeit. Für IoT-Anwendungen, Industry 4. 0 Szenarien oder Microservice-Architekturen, bei denen MQTT als Backbone dient, bietet diese hochverfügbare Mosquitto Lösung auf Kubernetes eine ideale Grundlage.
Sie sichert die kontinuierliche Datenübertragung auch bei Knotenfehlern oder temporären Netzwerkproblemen, ohne dass Anwender oder Systeme manuell eingreifen müssen. Wer auf einfache, robuste und dennoch flexible MQTT Broker Infrastruktur setzen möchte, findet in Kubernetes und Mosquitto zusammen mit Traefik eine zukunftssichere Plattform, die modernen Anforderungen an Verfügbarkeit und Ausfallsicherheit gerecht wird. Die Kombination ist auf kleine IoT-Stacks ebenso gut anwendbar wie auf großflächige verteilte Umgebungen mit mehreren Tausend verbundenen Clients. Anpassungen an andere Ingress Controller als Traefik sind ebenfalls möglich, erfordern jedoch eine entsprechende Anpassung der Port-Konfigurationen. Zusammenfassend bietet diese Architektur eine bewährte Strategie für Unternehmen und Entwickler, um die Vorteile von Kubernetes als Orchestrator mit der Stabilität und Schnelligkeit von Mosquitto MQTT zu verbinden.
Durch intelligentes Failover, permanente Nachrichtenbrücke zwischen Brokern, und eine transparente Service Handhabung werden neue Maßstäbe bei der Hochverfügbarkeit von MQTT-Diensten gesetzt. Der Aufwand für die Inbetriebnahme ist überschaubar, offenen Quellcode und Dokumentationen erleichtern die schnelle Implementierung und den Betrieb in produktiven Umgebungen.
