Nur 1–2 Personen kämpfen allein gegen alle Probleme an, und es gibt zahlreiche tödliche Bugs. Ingress NGINX kündigt an, dass es in 4 Monaten außer Dienst gestellt wird. Die Benutzer weltweit sind in Panik: Die verbleibende Zeit ist zu kurz.

Nach der kürzlich beendeten KubeCon Nordamerika diskutiert die Community über die Zukunft von eBPF, AI-nativem Infrastruktur und Cloud-nativem Sicherheitskonzept. Doch was die gesamte Community wirklich beunruhigt hat, war eine stillschweigend veröffentlichte Nachricht:

Kubernetes hat bekanntgegeben, dass Ingress NGINX im März 2026 offiziell eingestellt wird. Ab diesem Zeitpunkt wird die Wartung von Ingress NGINX vollständig eingestellt, d. h. "es werden keine Bugs mehr behoben, keine neuen Versionen veröffentlicht und das GitHub-Repository wird schreibgeschützt".

Mit anderen Worten: Dieser weit verbreitete Ingress NGINX, der in verschiedenen verwalteten Kubernetes-Plattformen und selbst aufgebauten Clustern eingesetzt wird und von Tausenden von Clustern genutzt wird, wird in vier Monaten endgültig "in den Ruhestand gehen".

Was ist Ingress NGINX und warum ist es wichtig?

Lassen Sie uns zunächst kurz Ingress NGINX einführen.

Ingress ist eine der ersten "benutzerfreundlichen" Methoden für den Datenverkehrseingang in Kubernetes, die dazu dient, externe Netzwerkanfragen auf Anwendungen innerhalb des Clusters zu leiten (Gateway API ist eine neuere Alternative). Um Ingress zu nutzen, muss in Ihrem Cluster ein Ingress Controller laufen.

Ingress NGINX ist einer der am häufigsten verwendeten Ingress Controller in Kubernetes-Clustern. Er ist dafür verantwortlich, externe HTTP/HTTPS-Datenströme an interne Dienste zu routen, basierend auf verschiedenen konfigurierbaren Ingress-Regeln. Es handelt sich quasi um einen Reverse Proxy: Er verteilt Anfragen an den richtigen Backend-Server basierend auf Pfaden, Domänennamen, TLS-Konfigurationen usw., führt Lastenausgleich durch und verwaltet den Randdatenverkehr.

Aufgrund seiner hohen Flexibilität, umfangreichen Funktionen und Unabhängigkeit von bestimmten Cloud-Plattformen hat Ingress NGINX seit seiner Entstehung schnell die Gunst vieler Entwickler gefunden. Selbst in der offiziellen Ankündigung der Einstellung von Ingress NGINX hat Kubernetes erwähnt:

"Ingress NGINX hat Milliarden von Anfragen in Rechenzentren und Heimlabors weltweit verarbeitet. In gewisser Weise gäbe es ohne Ingress NGINX heute keine Kubernetes-Ökosystem."

Dennoch wird dieses einst beliebte Projekt, das für seine Flexibilität und umfangreichen Funktionen bekannt war, zu einem "verlassenen Projekt" werden.

Sie mögen denken: "Was ist daran so bemerkenswert, dass eine Software eingestellt wird?" Tatsächlich ist dies nicht das erste Mal. Projekte wie dBase, Lotus 1-2-3, VisiCalc... waren einst sehr erfolgreich. Das Problem ist jedoch, dass Ingress NGINX derzeit noch von Tausenden von Clustern weltweit genutzt wird.

Der Wartungsalbtraum von Ingress NGINX: Akkumulierte technische Schulden und "keine Wartung"

Die offizielle Erklärung für die Einstellung von Ingress NGINX ist sehr direkt:

"Die starken Funktionen und Flexibilität von Ingress NGINX haben eine enorme Belastung für die nachträgliche Wartung verursacht."

Ein typisches Beispiel: Ingress NGINX ermöglicht es Benutzern, direkt über Anmerkungen beliebige NGINX-Konfigurationen (Snippets) hinzuzufügen. Dies galt in der Vergangenheit als Flexibilitätsvorteil, ist heute jedoch zu einer Sicherheitslücke geworden. Solche Funktionen zerstören von Grund auf die "Sicherheitsgrenze der Konfiguration" und machen die Laufzeitumgebung von NGINX fast unkontrollierbar. Angesichts der immer strenger werdenden Standards für Cloud-native Sicherheit ist dies heute eine "unvertretbare" Designlösung.

Es gibt nicht nur eine solche Funktion. Mit der Zunahme der Benutzerzahl haben sich diese historischen Belastungen allmählich zu schwer reparierbaren technischen Schulden akkumuliert.

Natürlich könnte ein komplexes Projekt auch funktionieren, wenn es von einem Team von 20 Personen gewartet wird. Aber Ingress NGINX hat nur 1-2 Wartungsmitarbeiter, die nur in ihrer Freizeit Zeit für die Wartung haben.

Ja, Sie haben richtig gehört. Dieser Komponent, der als Einstiegspunkt für Milliarden von Datenströmen beliebt ist und von unzähligen Produktionsclustern abhängt, wird seit Jahren nur von 1-2 Personen gewartet. Sie müssen in ihrer Freizeit, abends und an Wochenenden Zeit finden, um Bugs zu beheben, während gleichzeitig die Komplexität des Projekts und die Sicherheitsanforderungen ständig steigen.

Tatsächlich hat der Wartungsmitarbeiter von Ingress NGINX bereits letztes Jahr öffentlich erklärt, dass er vorhat, Ingress NGINX schrittweise aufzugeben und versucht hat, mit der Gateway API-Community zusammenzuarbeiten, um eine Alternative namens InGate zu entwickeln. Aber selbst nach der Vorankündigung der Einstellung konnte keine zusätzlichen Beitragenden für die Wartung gewonnen werden. InGate hat es sogar nicht in die Reifezeit gebracht und wird zusammen mit Ingress NGINX eingestellt.

Das "letzte Strohhalm" für Ingress NGINX: Ein fatales Sicherheits-Bug

Die Schwäche der Wartung von Ingress NGINX war bereits seit Jahren offensichtlich. Was Kubernetes schließlich dazu bewogen hat, die "Einstellungs-Schaltfläche" zu drücken, war ein schwerwiegender Bug, den das Sicherheitsunternehmen Wix im März dieses Jahres entdeckt hat.

Wie schwerwiegend war es? Wix hat es so ausgedrückt:

"Angreifer können diesen Bug nutzen, um beliebigen Code auszuführen und alle Cluster-Schlüssel in allen Namespaces zu erhalten, um so den gesamten Cluster vollständig zu übernehmen."

Offensichtlich ist ein Bug dieser Art ausreichend, um alle betroffenen Projekte direkt in einen "hochgefährdeten Zustand" zu bringen.

Wut der Community-Benutzer: Zu wenig Zeit übrig!

Nachdem diese Nachricht bekannt wurde, haben viele Benutzer auf Reddit, Slack und GitHub Wut und sogar Panik gezeigt.

Einige haben sich beschwert: "Bei einer so wichtigen Komponente hätten wir mindestens ein Jahr Zeit zur Migration benötigt. Nur das Überschreiben aller Dokumentationen würde länger als 4 Monate dauern."

Auf diese Kritik hat Tim Hockin, ein Kernwartungsmitarbeiter von Kubernetes, recht direkt geantwortet:

"Bitten Sie nicht mit einer selbstverständlichen Einstellung. Die Leute, die Ingress NGINX warten, tun dies kostenlos und werden nur von ihrer Verantwortung getragen. In den letzten zwei Jahren war fast niemand bereit, sich an der Wartung zu beteiligen. Die Schließung des Projekts war unvermeidlich."

Diese Worte enthüllen erneut die harte Wahrheit in der gesamten Open-Source-Branche: Viele wichtige Open-Source-Software werden von der Community stark abhängig genutzt, aber die Wartungsmitarbeiter erhalten keine Entlohnung.

Wird Ingress NGINX nicht der letzte sein, der zusammenbricht?

Ehrlich gesagt ist es nicht ungewöhnlich, dass Software schwerwiegende Sicherheits-Bugs hat. Windows hat fast jeden Monat einen "Explosions-Patch-Tag". Wie oben erwähnt, ist der Hauptgrund für die Einstellung von Ingress NGINX nicht der Bug, sondern: Es ist eine Kerninfrastruktur-Software, aber es gibt keine nachhaltigen Wartungsfinanzen.

William Morgan, CEO von Buoyant und Autor von Linkerd, hat bei einer Diskussion auf LinkedIn dazu gesagt: "Die CNCF-Ökosystem ist nicht wirklich geeignet für die Wartung durch Freiwillige. Die Einstellung dieser Community gegenüber Open-Source ist eher wie 'Konsum' als 'Beitrag'."

Diese Worte treffen den Nagel auf den Kopf. Ob FFmpeg, log4j, OpenSSL, SQLite oder cURL, all diese wichtigen Projekte, die das Internet stützen, sind ähnlich: Sie haben einen großen Einfluss, werden von Unternehmen stark abhängig genutzt, aber nur wenige Personen warten sie stillschweigend.

Wenn man weiterhin die "kostenlose Nutzung von Open-Source" wählt und nicht bereit ist, für die Kerninfrastruktur zu bezahlen, zu unterstützen und beizutragen, dann wird Ingress NGINX sicher nicht der letzte wichtige Bestandteil sein, der zusammenbricht. Die Lösung für dieses Problem könnte sein, wie William Morgan sagte: "Die einfachste Lösung ist, die Wartungsmitarbeiter zu bezahlen."

Dieser Artikel stammt aus dem WeChat-Account "CSDN", Verfasser: Zheng Liyuan, veröffentlicht von 36Kr mit Genehmigung.