Status
Für unsere Nine Kubernetes Engine (NKE) fiel die Wahl vor Jahren auf Ingress-NGINX, ganz einfach weil es der am breitesten eingesetzte und sicherste Ingress Controller war. Im November 2025 kam dann die Ankündigung: Die Maintainer gaben das Projekt auf, Zeit und Personal fehlten schlicht. Damit stand der meistgenutzte Ingress Controller überhaupt vor dem Aus, und für uns begann eine Reise über Traefik, HAProxy bis hin zu Gateway API. Genau diese Geschichte erzählte Sebastian Nickel, intern als Nick bekannt und Senior Engineer in unserem Platform-Team, unter dem Titel «Our Ingress Odyssey: Evaluating K8s Traffic Solutions After the Elephant Left the Room». Es war der erste von drei Vorträgen am TechTalk #29, eröffnet wie gewohnt mit einer kurzen Einführung von Thomas Hug, unserem CEO und Gründer.
Wo wir gestartet sind
Beim Aufbau unserer Nine Kubernetes Engine (NKE) fiel die Wahl auf Ingress-NGINX, weil es die damals meistgenutzte Lösung für Ingress war. Der Support für die zur Konfiguration genutzten Ingress-NGINX Annotations war bereits in vielen Helm Charts eingebaut. Da bei NKE grundsätzlich alles Self-Service ist, legen Kundinnen und Kunden selbst ein Ingress-NGINX-Objekt über unsere eigene API an. Unser Reconciler übernimmt dann den Rest: Er rendert daraus das offizielle Helm Chart, installiert es mit drei Replicas, und über unser eigenes BGP/MetalLB-Setup entsteht die öffentliche IP-Adresse. Sogar die Erreichbarkeit von aussen überwachen wir, nicht nur intern, und weil eben alles Self-Service läuft, muss dieser gesamte Ablauf vollständig automatisiert sein.
Die Deprecation
Jahrelang blieb das stabil, bis Nick und sein Team an der KubeCon einem Maintainer zuhörten, der offen einräumte: Nur noch ein bis zwei Personen pflegten Ingress-NGINX, in ihrer Freizeit, überwältigt von der schieren Menge an Problemen. Im November 2025 wurde es dann offiziell: Die Maintainer kündigten das Projektende an, Sicherheitsupdates sollte es nur noch bis März 2026 geben, danach nichts mehr. Wie verbreitet Ingress-NGINX zu diesem Zeitpunkt tatsächlich noch war, bestätigten später sogar die Steering- und Security-Response-Committees des Kubernetes-Projekts selbst, gestützt auf Datadog-Telemetriedaten: rund 50 Prozent aller Cloud-Native-Umgebungen setzten demnach noch darauf. Unsere Kundinnen und Kunden fragten uns geradeheraus, was jetzt unser Plan sei. Eine klare Antwort hatten wir zu diesem Zeitpunkt noch nicht.
Die Suche
Der offizielle Nachfolger heisst Gateway API, und dank einer eigenen Ingress-NGINX-Kompatibilitätsschicht wirkte zunächst Traefik wie der naheliegende Kandidat. In der Praxis deckte diese Schicht aber nur einen Bruchteil dessen ab, was unsere Kundinnen und Kunden tatsächlich einsetzten: Von damals rund 1'600 Ingresses nutzten etwa 80 Prozent Annotationen, die dieser Kompatibilitätsmodus schlicht nicht kannte. Diese sauber nachzuziehen, hätte bedeutet, Traefiks eigene CRDs zu übernehmen, spürbarer Mehraufwand für etwas, das heute eine einzige Ressource ist. Auch beim TLS-/ACME-Handling hakte es: Zuverlässig funktionierte das nur mit einer einzigen Replica, für alles andere brauchte es ein gemeinsames ReadWriteMany-Volume, in der Praxis also NFS, genau das wollten wir vermeiden. Dazu kam ein unabhängiger Gateway-API-Benchmark, der Traefik eine schwache Performance bescheinigte.
Aber auch Gateway API selbst hatte ein strukturelles Problem: Es trennt die Rollen Infrastructure Provider, Cluster Operator und Application Developer strikt voneinander und platziert die TLS-Konfiguration beim Cluster Operator, statt sie in der Ressource zu belassen, die Entwicklerinnen und Entwickler selbst kontrollieren. Für uns widersprach das direkt unserem Self-Service-Modell: Für jede Änderung an Hostnamen oder Zertifikaten hätten Kundinnen und Kunden sonst jedes Mal ein Ticket bei uns eröffnen müssen. Also entschied sich das Team bewusst fürs Zuwarten: Ingress-NGINX bis März 2026 weiter patchen und beobachten, wie sich das Ökosystem entwickelt, insbesondere ein Vorschlag namens ListenerSet, der es erlaubt, die eigentlich bei uns liegende Gateway-Definition kontrolliert zu erweitern, damit Kundinnen und Kunden selbst Hostnamen und Zertifikate für die TLS-Kommunikation anpassen können.
HAProxy
Den Ausschlag für die Entscheidung gab schliesslich eine eher unscheinbare Entdeckung: Ein Teammitglied stiess auf Hacker News auf ein kleines Tool des HAProxy-Ingress-Community-Projekts, das bestehende Ingress-NGINX-Definitionen automatisch in HAProxy-Äquivalente übersetzt. Damit stellten wir fest, dass HAProxy die meisten Einstellungen unterstützte, die wir bei Ingress-NGINX im Einsatz hatten, und testeten es daraufhin gezielt weiter: Wir prüften mit mehreren Konfigurationen, ob ein Bug, der uns bei Ingress-NGINX schon lange begleitete, auch bei HAProxy auftritt. Der Bug: Ein einzelner fehlerhafter Ingress, etwa durch einen Syntaxfehler in Annotationen, liess die Konfigurationsvalidierung scheitern. Ingress-NGINX servierte dann zwar unbemerkt weiter den letzten funktionierenden Stand, schrieb bei jedem gescheiterten Versuch aber trotzdem eine neue temporäre Datei, bis dem Node der Speicherplatz ausging, seine Pods evakuiert wurden und dieser letzte funktionierende Stand endgültig verloren war. Bei HAProxy fanden wir diesen Bug nicht: Es hielt stand, und wir entschieden uns dafür.
Weil HAProxys Annotationsmodell unserem bisherigen so nahe kam, entschieden wir uns, den HAProxy Ingress Controller in unserer API als Resource anzubieten. Kundinnen und Kunden konnten ihn daher als zusätzlichen Controller in ihren Clustern installieren. Dadurch war es möglich, einzelne Ingresses per DNS-Umstellung zu migrieren, ohne den gesamten Ingress-NGINX Controller einfach durch HAProxy ersetzen zu müssen.
WAF, und wieder Gateway API
Irgendwann kam von Kundinnen und Kunden der Wunsch nach einer Web Application Firewall auf. HAProxys eigene WAF-Unterstützung steckte noch im experimentellen Stadium, und auch ein von Kundenseite vorgeschlagenes kommerzielles Produkt überzeugte nicht: Sein Java-basierter Controller fügte komplette Stack-Traces direkt in den Status der zur Konfiguration verwendeten CRD-Ressourcen ein. Ausserdem schien der Reconciliation Loop nicht immer zu funktionieren, wodurch manche Änderungen gar keine Aktualisierung auslösten.
Ein weiteres Produkt, das getestet wurde, war Airlock Microgateway von Ergon. Es setzt ausschliesslich auf Gateway API und deckt neben den OWASP Top 10 eine breite Palette weiterer Security-Anforderungen ab. Das bedeutete allerdings, dass genau die Frage wieder auf dem Tisch lag, die wir eigentlich zurückgestellt hatten: der Umgang mit Gateway API statt klassischem Ingress. Zum Glück hatte sich inzwischen einiges getan: ListenerSet erreichte den Production-Readiness-Track von Gateway API, cert-manager brachte stabile Unterstützung dafür, und wir erhielten vorab Beta-Zugang zum entsprechenden Ergon-Release. Damit war auch das Ownership-Problem gelöst: die TLS-Konfiguration kann jetzt dort liegen, wo Entwicklerinnen und Entwickler sie erwarten.
Wo uns das hinbringt
HAProxy Ingress ist für uns der neue Standard für klassisches Ingress. Setzt du heute noch auf den Ingress-NGINX Controller, empfehlen wir dir, den Wechsel zeitnah anzugehen: Wie wir an anderer Stelle beschrieben haben, gibt es seit März 2026 keine Sicherheitsupdates für Ingress-NGINX mehr. Airlock Micro Gateway auf Gateway API testen wir aktuell mit einer begrenzten Anzahl Kundinnen und Kunden für WAF-Anwendungsfälle. Melde dich bei uns, falls das für dich interessant ist. Die Implementierung von Airlock Microgateway in unserer API liefert uns ausserdem eine Referenzarchitektur für weitere Gateway-API-Controller (mit ListenerSet-Support) in der Zukunft.
Zwei Erkenntnisse bleiben im Rückblick besonders hängen: Manchmal ist Abwarten tatsächlich die richtige Strategie, bis ein Ökosystem reif genug ist. Und jede Ablösung muss sich daran messen lassen, ob sie spürbar mehr Komplexität mitbringt, als Kundinnen und Kunden heute schon haben, das gilt es zu vermeiden.
Über die Einstellung des Ingress-NGINX-Projekts selbst hatten wir bereits im Dezember 2025 geschrieben, dieser Talk liefert das Update dazu, wohin uns die Suche letztlich geführt hat. Mehr zu NKE gibt’s auf unserer Produktseite. Hast du Fragen zu einem der Themen aus dem Talk? Melde dich bei uns. Den nächsten TechTalk kündigen wir wie gewohnt über unsere Kanäle an, unter anderem in unserer Meetup-Gruppe «TechTalk @ Nine».
