Jahresrückblick 2025 – unser neuer Blogbeitrag ist online! ✨

[UncleSam]

Seit einiger Zeit (es sind schon ein paar Jahre) denke ich darüber nach, was es braucht um ioBroker nativ in Kubernetes laufen zu lassen, damit wir ioBroker hochverfügbar betreiben können.

Sehr einfach gesagt, soll js-controller durch einen k8s-controller ersetzt werden und jeder Adapter in einem eigenen Pod laufen.

Einen ersten "Proof of Concept" (PoC) habe ich im Developer Meeting vorgestellt:

1. Vorkonfigurierten k3s mit curl -sfL https://iobroker-k8s.github.io/install.sh | sh - installieren
2. Warten bis ioBroker.admin auf dem gewohnten Port 8081 verfügbar ist
3. Adapter installieren (im PoC geht nur genau der Loxone Adapter!)
4. Adapter konfigurieren und starten

Das Projekt steht ganz am Anfang und bevor ich viel Zeit darin investiere, möchte ich verstehen:

• Gibt es ein Interesse am Projekt?
• Gibt es weitere Entwickler, die unterstützen würden?
• Gibt es erfahrene User, die das Projekt testen und irgendwann auch mal produktiv in Einsatz nehmen möchte?
• Hat jemand schon etwas ähnliches versucht?

Ohne breite(re) Unterstützung werde ich das Projekt nicht weiter verfolgen, auch wenn ich es sehr gerne bei mir zu Hause mit 3-4 Raspberry Pi 5 (8G) einsetzen würde.

[UncleSam]

Wenn ihr mehr Details zur Architektur haben möchtet, kann ich euch gerne hier mehr erklären. Ich wollte einfach nicht den ursprünglichen Beitrag zu gross machen.

[OliverIO]

@unclesam

Wenn du sagst das nur der loosen Adapter geht, muss man dann wahrscheinlich Anpassungen vornehmen.

Wie umfangreich wird das?
Bleibt die Kompatibilität zum bisherigen Controller erhalten.
Oder lässt sich das standardisieren, so das nur bei Besonderheiten (besondere Ports, besondere deviceszugriffe oder Dateien) eine Anpassung notwendig ist?

Das sind sicherlich Stellschrauben für die Verfügbarkeit von Adapter

[UncleSam]

Wenn du sagst das nur der loosen Adapter geht, muss man dann wahrscheinlich Anpassungen vornehmen.

Am Adapter selbst muss nichts angepasst werden, aber für jeden Adapter werden wir ein Docker Image sowie einen Helm Chart generieren müssen. Beides kann automatisch geschehen mit Ausnahmen für Adapter mit speziellen Anforderungen.

Wie umfangreich wird das?

Für die meisten Adapter gibt das nichts zu tun, sobald die nötigen Dateien generiert werden können. Zu Beginn wird es wohl eine Whitelist sein, später hoffentlich nur noch eine Blacklist. Somit sollten dann neue Adapter automatisch aufgenommen werden können.

Bleibt die Kompatibilität zum bisherigen Controller erhalten.

Ja, unbedingt. Es wird nicht ein Fork sondern ein Tracking der Funktionalität. Viele Feature werden automatisch übernommen, da k8s-controller den js-controller als Abhängigkeit drin hat. Bis jetzt beschränken sich alle Änderungen auf eine einzige Datei.

Oder lässt sich das standardisieren, so das nur bei Besonderheiten (besondere Ports, besondere deviceszugriffe oder Dateien) eine Anpassung notwendig ist?

Der Helm Chart hat als Variable die ganze Instanz-Konfiguration. Damit kann der Adapter vom User wie bisher konfiguriert werden und die Einstellungen werden in die Kubernetes-Konfiguration übernommen. Beispiel: Admin Port

Zudem habe ich angedacht, ein Konfigurations-Tab in Admin zu haben, wo z.B. Services auch als Ingress zur Verfügung gestellt werden können (also z.B: wenn du Admin unter https://admin.my-home-lab.something aufrufen willst). Aber das kommt frühestens in Version 2 ;-)

[MartinP]

@unclesam

• Was wäre das Ziel der Entwicklung?
• Was für Vorteile gibt es dadurch?
• Wer profitiert?

Klingt ja durchaus danach, dass man dadurch skalierbarer wird, und dann auch sehr große Projekte stemmen kann.
Auf der anderen Seite sollte ein Augenmerk darauf gehalten werden, dass eine iobroker Installation auch auf einen einzigen Raspberry Pi passen sollte ...

[ticaki]

Ich hab keinen Plan von Docker jedoch wäre eine Hochverfügbarkeitslösung schon was feines. Wenns was zum testen gibt, beteilige ich mich gerne. Egal ob alpha/beta oder stable, vielleicht nen weitverbreiteten Adapter mit aufnehmen (Shelly oder Sonoff).

[UncleSam]

Was wäre das Ziel der Entwicklung?

Für mich gibt es aktuell zwei Ziele:

1. ioBroker echt hochverfügbar zu machen (fällt ein Node aus, werden Adapter wenn nötig auf einem anderen Node gestartet)
2. Die Komplexität von Multihost (was ist wo installiert und muss upgedatet werden) zu reduzieren

Was für Vorteile gibt es dadurch?

Im Moment sehe ich folgende wichtigen Vorteile:

• Systeme können upgedatet werden, ohne dass alle Adapter, die darauf laufen, ausfallen
• Adapter laufen in einem Pod, der genau das drin hat, was sie brauchen (z.B. spezifische Versionen von Paketen oder sogar Node.js)
• Adapter mit externen Abhängigkeiten können diese gleich mitliefern (z.B. InfluxDB)
• Adapter laufen dort wo es noch Ressourcen hat und nicht dort wo sie mal installiert wurden

• Wer profitiert?

Grössere Installationen mit mehreren Nodes (heute Multihost) sowie User mit Adaptern die komplexe Abhängigkeiten haben.

Auf der anderen Seite sollte ein Augenmerk darauf gehalten werden, dass eine iobroker Installation auch auf einen einzigen Raspberry Pi passen sollte ...

Das wird wie heute weiter möglich sein. Es geht nicht darum, nur noch iobroker-k8s anzubieten, sondern drei Varianten der Installation: Single-Host wie bisher, Multihost wie bisher oder Kubernetes

[MartinP]

@unclesam Wenn man iobroker zu einem verteilten System mit Redundanzen macht, ist das sicherlich zu begrüßen.

3-4 Raspberry Pi 5 (8G, BCM2712) einsetzen würde

Das ist aber schon ein ordentlicher Kostenfaktor ... aber auch nicht zu teuer ...

Wenn es kleinere Pi wären, und dafür ein paar Mehr, wäre es vielleicht noch interessanter ...

oder auf refurbished Thin Clients mit stromsparenden 6...15 Watt TDP-Prozessoren ...
Habe neulich bei Ebay einen Futro 920S mit AMD GX222GC (?) für 29 € geschossen, 20% schneller, wie ein Pi4 (BCM2711)

https://www.cpubenchmark.net/compare/index.php?remove=4671

[ticaki]

@martinp sagte in Neues Projekt: ioBroker nativ in Kubernetes:

@unclesam Wenn man iobroker zu einem verteilten System mit Redundanzen macht, ist das sicherlich zu begrüßen.

3-4 Raspberry Pi 5 (8G, BCM2712) einsetzen würde

Das ist aber schon ein ordentlicher Kostenfaktor ... aber auch nicht zu teuer ...

Wenn es kleinere Pi wären, und dafür ein paar Mehr, wäre es vielleicht noch interessanter ...

Wieso versteifst du dich so auf die ausführende Hardware. Hier das Projekt soll wohl eher nicht dafür sorgen, das du auf Hardware die eigentlich zu schwach für iobroker ist, einer verwendung zu zu führen. Sondern das ein ausfallender Rechner den laufenden Betrieb nur für sehr kurze Zeit stört und das auch nur für Adapter die auf diesem Rechner laufen.

Mit Proxmox dauert eine Restart des iobrokers bei mir ca. 3 Minuten bis wieder alles rennt. Mit diesem Projekt würde diese Zeit deutlich fallen. Außerdem könnte der vorhandene PI tatsächlich zur Ausfallsicherheit beitragen und nicht nur als voter dienen.

[mcpovel]

Hallo,
auch ich hätte Interesse an so einer Kubernetes Lösung, solange die Adapter unverändert genutzt werden können. Ob natürlich ein Pod pro Adapter am Ende so toll sein wird, muss sich zeigen.
Ich versuche gerade meinen bare metal iobroker in den k3s Cluster zu verlegen mit Multihost, damit zumindest der RFLink auf der richtigen HW landet. Alle anderen Adapter bei mir sind eh nur Software. (Modbus für Wallbox und Wärmepumpe, CCU, MQTT, Bluelink, Zoe, und noch viele mehr.)
Die Datenbanken sind eh schon im Cluster.