Wir arbeiten derzeit an einer geeigneten Strategie für die bevorstehende Einstellung des ingress-nginx-Projekts, die für März 2026 geplant ist. Trotz des eher knappen Zeitrahmens haben wir noch keine endgültige Entscheidung über unsere langfristige Ersatzstrategie getroffen. Derzeit scheinen sich häufig neue Entwicklungen zu diesem Thema abzuzeichnen. Aus diesem Grund untersuchen wir verschiedene Möglichkeiten und möchten unsere bisherigen Erkenntnisse kommunizieren.

Einführung eines anderen «reinen» Ingress-Controllers

Da wäre die Möglichkeit, einen anderen Ingress-Controller zu installieren und Kund*innen die Option zu geben, aktuelle Ingress-Ressourcen auf diesen neuen Controller umzustellen. Das klingt zwar nach einer attraktiven Lösung, erfordert aber dennoch einige Migrationsarbeiten (und eine DNS-Änderung, da der neue Controller eine andere öffentliche IPv4-Adresse verwenden würde). Das ingress-nginx-Projekt ermöglicht die Konfiguration über spezifische Annotations auf der Ingress-Ressource selbst. Diese Annotations werden vom neuen, alternativen Ingress-Controller nicht unterstützt. Einige Projekte haben diesbezüglich ein paar Hilfestellungen vorbereitet. HAProxy bietet beispielsweise eine Migrationshilfe-Website, mit der überprüft werden kann, ob für eine ingress-nginx Annotation eine HAProxy-spezifische Annotation verfügbar ist. Das Traefik-Projekt hat eine Art Kompatibilitätsschicht entwickelt, die es ermöglicht, einige ingress-nginx Annotations direkt zu verwenden (sie werden intern übersetzt).

Wir haben die Kompatibilität der derzeit in unseren Clustern verwendeten ingress-nginx Annotations mit einigen dieser Optionen getestet und sind der Meinung, dass die meisten Kund*innen trotzdem einiges an Arbeit aufwenden müssten, um ihre Konfiguration neu zu schreiben, damit die gleiche Funktionalität erhalten bleiben würde. Darüber hinaus haben die meisten Controller spezifische CRDs eingeführt, um die «Annotationskonfiguration» in controllerspezifische Typen auszulagern. Bei Traefik müssen Kunden beispielsweise möglicherweise eine «Middleware-Ressource» erstellen, um eine Konfiguration zu erreichen, die mit Annotations mit ingress-nginx möglich war. Darüber hinaus wird es für einige Funktionen (zum Beispiel «modsecurity») höchstwahrscheinlich in keinem Controller einen Ersatz geben.

Zusammenfassend lässt sich sagen, dass die Migration zu einem anderen Ingress-Controller viele Ressourcen erfordert und möglicherweise mehr als nur eine reine Neufassung der Annotations umfasst. Da GatewayAPI zudem die Zukunft der Ingress-Definition bestimmt (siehe unten), halten wir eine Umstellung auf einen Gateway-Controller in Zukunft für unvermeidlich. Im schlimmsten Fall würde dies zwei Migrationen bedeuten. Die erste zu dem neuen alternativen Ingress-Controller und die zweite zu einem GatewayAPI-basierten Controller.

Migration zu einem GatewayAPI-basierten Controller

GatewayAPI wurde 2023 allgemein verfügbar und ist der offizielle Nachfolger der Ingress-API in Kubernetes. Es bietet alle Funktionen der Ingress-Ressource und ermöglicht die Konfiguration Gateway Controller-spezifischer Funktionen auf eine einheitliche, aussagekräftigere Weise, anstatt sich auf Annotations zu verlassen. Dadurch werden neue Ressourcen eingeführt und die Ingress-Konfiguration auf diese aufgeteilt. Für einfache Anwendungsfälle mag die Aufteilung der Konfiguration auf mehrere Ressourcen «übertrieben» erscheinen, aber sie ermöglicht sicherlich mehr Konfigurationsanwendungsfälle als die Ingress-basierte API. Ausserdem verfügt mittlerweile fast jeder der im Open-Source-Bereich verfügbaren Controller über eine Implementierung für die Gateway-API. Kurz gesagt, es wirkt so, als wäre GatewayAPI die Zukunft.

GatewayAPI hat jedoch auch verschiedene Rollen beziehungsweise Personas eingeführt, um verschiedene Bereiche von Konfigurationen auf unterschiedliche Berechtigungsebenen beziehungsweise Personengruppen aufzuteilen. Insbesondere unterscheidet GatewayAPI zwischen «Infrastrukturanbietern», «Cluster-Betreibern» und «Entwicklern». Ohne zu sehr ins Detail zu gehen, ändert dies die derzeitigen Verantwortlichkeiten für die Verwaltung von TLS-Zertifikaten. Bei der Arbeit mit Ingress-Ressourcen können Entwickler*innen Hostnamen, Pfadkonfigurationen, verschiedene andere spezifische Konfigurationen und auch TLS-Zertifikate verwalten. In der aktuellen stabilen Version von GatewayAPI ist die Verwaltung von TLS-Zertifikaten Teil der Rolle «Cluster-Betreiber». Dies ist eine erhebliche Änderung in der Arbeitsweise von Entwickler*innen, da beispielsweise das Self-Provisioning von LetsEncrypt-Zertifikaten nicht mehr möglich ist. Sicherlich gibt es bereits Lösungen wie Wildcard-Zertifikate oder die Zusammenführung der Rollen «Cluster-Betreiber» und «Entwickler» zu einer einzigen, aber all dies sind nur Workarounds, die mit Nachteilen verbunden sind. Um die Situation wirklich nachhaltig zu verbessern, wurde ein entsprechender Vorschlag erstellt. In diesem Vorschlag würde es eine neue Ressource namens «ListenerSet» Entwickler*innen ermöglichen, TLS-Zertifikate selbst zu verwalten. Da die «ListenerSet»-Ressource noch als experimentell gekennzeichnet ist, wird diese Funktion derzeit noch nicht flächendeckend eingesetzt, aber wir sind der Meinung, dass sich der Arbeitsablauf für Entwickler*innen erheblich verbessern wird, sobald Gateway-Controller und Projekte wie cert-manager die «ListenerSet»-Ressource unterstützen. Derzeit können wir jedoch noch nicht abschätzen, wann dies der Fall sein wird.

Wir haben uns auch das Ökosystem der Gateway-Controller angesehen, aber die Auswahl des «richtigen» Controllers scheint ebenfalls keine leichte Aufgabe zu sein, da es unterschiedliche Implementierungsstufen gibt.

Zusammenfassung

Angesichts der aktuellen Entwicklungen in Bezug auf ingress-nginx sind wir der Meinung, dass wir noch etwas mehr Zeit benötigen, um eine fundierte strategische Entscheidung zu treffen. Wie oben erwähnt, ist GatewayAPI die Zukunft, aber wir glauben, dass es noch nicht bereit ist, die gleiche Betriebserfahrung zu bieten, wie sie Entwickler*innen gewohnt sind. Wir werden unsere aktuellen ingress-nginx Deployments weiterhin aufrechterhalten und sicherstellen, dass wir immer die neuesten Versionen verwenden, um Sicherheitsrisiken zu minimieren und die Stabilität zu gewährleisten, bis ein Migrationspfad ausgewählt wurde.

Falls es Unklarheiten oder Bedenken Ihrerseits bezüglich der Thematik gibt, dürfen Sie uns gerne kontaktieren.