openDesk-Betrieb: HAProxy-Ingress statt NGINX – was Betreiber jetzt tun sollten

Was sich geändert hat

Die offizielle openDesk-Betriebsdokumentation listet aktuell zwei unterstützte Ingress-Controller. Empfohlen ist haproxy-ingress, der seit openDesk 1.13 verfügbar ist. Der bisher übliche Ingress-NGINX-Controller bleibt zwar weiterhin lauffähig, ist aber als deprecated markiert. Die Begründung ist nicht openDesk-spezifisch, sondern liegt im Upstream: das Ingress-NGINX-Projekt selbst wird vom Kubernetes-Ökosystem nicht weiter gepflegt und erhält keine kontinuierlichen Sicherheitsupdates mehr.

Für openDesk-Betreiber heißt das: HAProxy-Ingress ist nicht „nur eine Alternative", sondern wird die strategisch tragfähige Variante für künftige Releases. Wer heute eine neue openDesk-Umgebung aufsetzt, sollte direkt HAProxy einsetzen.

Warum NGINX-Ingress nicht einfach weiterläuft

Auch wenn der bestehende Cluster mit Ingress-NGINX im Moment funktioniert, entstehen drei Risiken, sobald upstream Wartung wegfällt:

• Sicherheitslücken in NGINX selbst oder im Ingress-Controller-Code werden nicht mehr zeitnah gepatcht. Bei einem öffentlich erreichbaren Cluster ist das ein wachsendes Compliance- und IT-Sicherheitsrisiko.
• Kompatibilität mit neueren Kubernetes-Versionen verschlechtert sich. Was heute mit Kubernetes 1.30 läuft, kann in 1.33 oder 1.34 brechen, ohne dass jemand den Fix nachreicht.
• openDesk-Updates werden auf neuen Cluster-Setups verstärkt gegen HAProxy getestet. Edge-Cases mit NGINX werden mit der Zeit häufiger durchrutschen.

In der Praxis bedeutet das: NGINX-Ingress weiterzubetreiben ist ab sofort technische Schuld mit definitivem Verfallsdatum.

Konkrete Anforderungen laut openDesk-Doku

Die Betriebsdokumentation nennt zwei Punkte, die in Migrationsprojekten oft übersehen werden.

Wer NGINX-Ingress während der Übergangszeit weiterbetreibt, muss mindestens auf Version 1.11.5 oder 1.12.1 sein. Ältere Versionen enthalten bekannte Sicherheitslücken, die das openDesk-Setup direkt angreifbar machen. Für Versionen ab 1.12.0 sind zusätzlich zwei Konfigurations-Settings zwingend erforderlich:

• annotations-risk-level auf den Wert Critical
• strict-validate-path-type auf false

Diese Settings sind kein Komfort-Tuning, sondern Voraussetzung dafür, dass openDesk-Komponenten überhaupt korrekt durchgereicht werden.

Für HAProxy-Ingress gibt es eine andere Stolperfalle: openDesk bringt zahlreiche Komponenten mit, deren Anzahl in einer typischen Installation die Default-Buffer-Limits eines Standard-HAProxy-Deployments überschreiten kann. Ohne angepasste Buffer-Konfiguration treten dann diffuse Routing-Fehler auf, die schwer zu reproduzieren sind. Die Dokumentation nennt empfohlene Tuning-Werte – diese gehören in jedes Helm-Values-File einer Produktivinstallation.

Migrationsvorgehen in der Praxis

Eine offizielle Schritt-für-Schritt-Migration ist von ZenDiS aktuell nicht dokumentiert. In der Praxis hat sich folgendes Vorgehen bewährt:

1. Bestandsaufnahme der aktuellen NGINX-Konfiguration. Welche Annotations sind im Einsatz, welche Pfade haben Sonderbehandlungen, wo greifen Rate-Limits oder Auth-Schichten?
2. Mapping auf HAProxy-Annotations. Die meisten kubernetes.io/ingress-class-Annotations und Standard-Routing-Regeln sind übertragbar, einige NGINX-spezifische Annotations brauchen ein HAProxy-Äquivalent oder eine Backend-Anpassung.
3. Parallelinstallation von HAProxy-Ingress mit eigener IngressClass. So bleibt der bestehende NGINX-Controller produktiv aktiv, während HAProxy für eine ausgewählte Subdomain getestet wird.
4. Schrittweise Umstellung der openDesk-Ingress-Objekte. Erst weniger kritische Dienste, dann die zentralen Dienste wie Nextcloud, Collabora und Element/Matrix.
5. Cutover mit DNS-Wechsel oder Service-Patch, abschließend der Rückbau des alten NGINX-Controllers nach einer Beobachtungsphase.
6. Validierung der TLS-Konfiguration. cert-manager-Annotations laufen auch auf HAProxy, aber die Reihenfolge der ClusterIssuer-Bindings sollte bei der Migration verifiziert werden.

Wichtig: vor jedem Schritt einen Plan für den Rollback haben. Ingress-Wechsel sind Eingriffe in den Datenpfad – Fehler sind sofort für alle Endnutzer sichtbar.

Ausblick: Gateway-API als nächste Stufe

Die openDesk-Dokumentation nennt als langfristiges Ziel die Migration zur Kubernetes Gateway API, idealerweise bis Ende 2026. Die Gateway API ist der offizielle Nachfolger der klassischen Ingress-Ressource und entkoppelt das Routing-Modell vom konkreten Controller. Für Betreiber bedeutet das: wer heute auf HAProxy umstellt, baut keine Sackgasse, sondern eine sinnvolle Zwischenstufe. HAProxy-Ingress unterstützt parallel die klassische Ingress-API und Gateway-API-Erweiterungen, sodass ein zweiter Schritt 2026 auf der gleichen Daten-Pfad-Komponente erfolgen kann.

Empfehlung

Drei Handlungsstränge, je nach Lage:

• Neue openDesk-Einführung: direkt mit HAProxy-Ingress starten, NGINX-Ingress bewusst überspringen.
• Bestehender Cluster mit NGINX-Ingress: Migration zu HAProxy planen und in einem Wartungsfenster der nächsten ein bis zwei Quartale umsetzen, bevor weitere Sicherheitsfragen auflaufen.
• Bestehender Cluster mit veralteter NGINX-Version: zuerst auf 1.11.5 bzw. 1.12.1 plus die geforderten Settings heben, parallel die HAProxy-Migration vorbereiten – nicht beides in eine einzige Aktion bündeln.