BLOG | NGINX

NGINX Ingress Controller Version 2.0: Was Sie wissen müssen

NGINX-Teil-von-F5-horiz-schwarz-Typ-RGB
Brian Ehlert Miniaturbild
Brian Ehlert
Veröffentlicht am 27. Dezember 2021

Im Oktober haben wir F5 NGINX Ingress Controller Version 2.0 ( nginxinc/kubernetes-ingress ) eingeführt und Unterstützung für Kubernetes 1.22 und Version 1 der Ingress API ( networking.k8s.io/v1 ) hinzugefügt. Sie fragen sich vielleicht: Na und?

Dieses „Na und?“ ist eine differenzierte Frage, die wir anhand von drei miteinander verbundenen Fragen beantworten werden:

Lesen Sie weiter, um die Antworten zu erfahren, und schalten Sie ein für „Ihr Schlachtplan für den Fall, dass Kubernetes-Versionen am 11. Januar 2022 angreifen“.

Warum sind Kubernetes-Releases eine große Sache?

Die Antwort auf diese Frage ist einfach und zugleich kompliziert. Das Kompatibilitätsmanagement für Kubernetes ist eine Herausforderung, da Kubernetes-Operatoren drei Versionskategorien verwalten müssen:

  1. Die Kubernetes-Plattform selbst – Bei jeder neuen Version stellt das Kubernetes-Team die Wartung einer älteren Version ein. Die weitere Verwendung einer solchen Version ist für Ihre Risikomanagementstrategie problematisch und erschwert die Fehlerbehebung, da keine Hilfe vom Kubernetes-Team mehr verfügbar ist. Derzeit unterhält das Kubernetes-Projekt Release-Zweige für die letzten drei Nebenversionen (1.20, 1.21 und 1.22). Kubernetes 1.19 und höher erhalten ungefähr 1 Jahr Patch-Support, während 1.18 und früher ungefähr 9 Monate Patch-Support erhielten. (Der kürzere Zeitraum für 1.18 und früher liegt daran, dass Kubernetes früher viermal pro Jahr veröffentlicht wurde und nicht wie bisher dreimal).

  2. Die Kubernetes-APIs – Mit jeder Kubernetes-Version werden neue APIs geboren und veraltete APIs verworfen, und die Änderungen an den APIs wirken sich auf die entsprechenden Ressourcen und Tools aus. Wenn Sie Ihre Kubernetes-Plattform aktualisieren, müssen Sie möglicherweise auch die APIs aktualisieren.

  3. Die Tools, die Sie in Kubernetes bereitgestellt haben – Eine wesentliche Änderung an Kubernetes oder seinen APIs kann Auswirkungen darauf haben, ob Ihre Tools – beispielsweise ein Ingress-Controller – und die entsprechenden Ressourcen weiterhin ordnungsgemäß funktionieren.

Sie müssen also drei Zeitpläne verfolgen – einen für Kubernetes, einen für die Ingress-API und einen für den NGINX Ingress Controller. Um zu vermeiden, dass Kubernetes beschädigt wird, müssen Sie den Sweet Spot finden, an dem die Kubernetes-Version mit den APIs und dem NGINX Ingress Controller kompatibel ist. Das Upgrade einer der drei Komponenten ohne Überprüfung der Kompatibilität kann drastische Folgen haben. Wenn alle drei Komponenten nicht miteinander kompatibel sind … herzlichen Glückwunsch, Ihre Apps sind kaputt!

Was ist die Ingress-API und warum ist networking.k8s.io/v1 wichtig?

Die Ingress-API ermöglicht es einem Ingress-Controller, Ihre Kubernetes-Apps sicher verfügbar zu machen. Die networking.k8s.io/v1 API (auch bekannt als Ingress API v1) wurde mit Kubernetes 1.19 eingeführt. Zu diesem Zeitpunkt unterstützte Kubernetes sowohl v1beta1 als auch v1 – und stellte eine Version automatisch als die andere dar. Diese „unter der Oberfläche“ erfolgende Kompatibilität der API-Versionen ist für Sie betrieblich von Vorteil, kann jedoch Ihre Planungsbemühungen behindern.

Mit der Veröffentlichung von Kubernetes 1.22 wurde v1 zur einzigen Version der Ingress-API. Dies ist von Bedeutung, da mit der Einführung der Ingress-API v1 alle Betaversionen ( extensions/v1beta1 und networking.k8s.io/v1beta1 ) veraltet sind. Obwohl dies für Organisationen, die Ingress API v1 noch nicht übernommen haben, störend ist, betrachten wir bei NGINX diese Änderung als ein gutes Zeichen. Die Beförderung der Ingress-API aus der Betaphase signalisiert den Übergang zu einer ausgereiften und vollständig realisierten API. Warum ist diese Änderung nun wichtig? Nun, das bezieht sich wieder auf die Versionsverwaltung. Angenommen, Sie aktualisieren einen vorhandenen Cluster auf Kubernetes 1.22, verwenden aber weiterhin Ingress-bezogene Ressourcen der Version v1beta1 … Glückwunsch, Sie haben Ihre Ingress-Ressourcen beschädigt!

Welche Auswirkungen hat NGINX Ingress Controller 2.0 auf bestehende Kunden?

Da der NGINX Ingress Controller eng mit der Ingress-API verknüpft ist, hatte die Veröffentlichung von Version 1 erhebliche Auswirkungen auf uns als Produkt – und auch auf Sie als unsere Kunden – weshalb wir die Versionsnummer des NGINX Ingress Controllers von 1. x auf 2. x geändert haben. Wir haben die Architektur von NGINX Ingress Controller 2.0 überarbeitet, um die Ingress API v1 zu nutzen und ihn vollständig mit Kubernetes 1.22 kompatibel zu machen.

Wenn Sie NGINX Ingress Controller verwenden, müssen Sie sofort einige versionsabhängige Maßnahmen ergreifen, um eine Beschädigung von Kubernetes, Ihrer Ingress-Ressourcen oder des NGINX Ingress Controllers zu vermeiden:

  • Kubernetes 1.18 und früher:

    • Stellen Sie sicher, dass Sie NGINX Ingress Controller 1.12 verwenden, damit Sie den größtmöglichen Funktionsumfang nutzen können. (Wenn Sie auf NGINX Ingress Controller 2.0 aktualisieren, müssen Sie auch auf Kubernetes 1.19 oder höher aktualisieren.)

    • Machen Sie einen Plan für die Migration auf eine neuere Version von Kubernetes (und NGINX Ingress Controller) innerhalb der nächsten Monate, da Kubernetes 1.18 nach der nächsten Kubernetes-Version nicht mehr unterstützt wird.

  • Kubernetes 1.19–1.21:

    • Upgrade auf NGINX Ingress Controller 2.0.

    • Wenn Sie Ihre Ingress-bezogenen Ressourcen noch nicht nach networking.k8s.io/v1 migriert haben (siehe Versionshinweise zu NGINX Ingress Controller 2.0 ), erstellen Sie jetzt Ihren Plan. Kubernetes 1.19–1.21 unterstützt alle aktuellen Versionen der Ingress-API (sowohl v1beta1 als auch v1 ) und gibt Ihnen die Möglichkeit, direkt zu konvertieren.

    • Falls Sie dies noch nicht getan haben, verschieben Sie Ihre Ingress- und IngressClass-Ressourcen sofort nach networking.k8s.io/v1 .

      • Wenn Sie in Ihren Ingress-Ressourcen die veraltete Annotation kubernetes.io/ingress.class verwenden, empfehlen wir, zum Feld ingressClassName zu wechseln.

      • Verwenden Sie unsere Dokumentation und Beispiele (verfügbar unter networking.k8s.io/v1 und dem Feld ingressClassName der Ingress-Ressource), um Ihre Updates zu planen.

  • Kubernetes 1.22:

    • Stellen Sie sicher, dass Sie bereits NGINX Ingress Controller 2.0 ausführen, da frühere Versionen von NGINX Ingress Controller nicht mit Kubernetes 1.22 kompatibel sind und Ingress API v1 nicht unterstützen.

Eine (nicht ganz so) kurze Geschichte des NGINX Ingress Controllers

Seit seiner ersten Veröffentlichung im Jahr 2016 hat sich NGINX Ingress Controller von einem neuen Tool zu einem Kraftpaket für Kubernetes-Netzwerke entwickelt. Hier ist ein Blick auf die Entwicklung von der Einführung bis heute.

2016 ( v0.5.0 )

Der NGINX-Ingenieur Michael Pleshakov veröffentlicht den ersten Eintrag in unserem GitHub-Repository ( nginxinc/kubernetes-ingress ) , der es ermöglicht, NGINX und F5 NGINX Plus als Kubernetes Ingress Controller (KIC) zu verwenden.

NGINX Ingress Controller tritt erstmals öffentlich auf der KubeCon EU 2016 auf. Schauen Sie sich die Aufzeichnung an: Tag 1, Erstellen einer erweiterten Lastausgleichslösung für Kubernetes mit NGINX; KubeCon EU 2016 .

2017 ( v1.0.0 )

Das Projekt erreicht Produktionsreife, einschließlich wichtiger Unterstützung für JSON Web Tokens (JWTs) in der auf NGINX Plus basierenden Version.

Auf der NGINX Conf 2017 demonstriert Michael Pleshakov Produktionsfunktionen, darunter erweitertes Lastenausgleichsverfahren bei der Verwendung von NGINX Plus als Ingress-Controller für Lastenausgleichsanwendungen auf Kubernetes .

2018

NGINX Ingress Controller weist große Verbesserungen in den Bereichen Sichtbarkeit, Benutzerfreundlichkeit und Flexibilität auf:

  • Mai ( v1.2.0 ) – Das Projekt übernimmt die neue NGINX Plus API und die Nginx-Ingress -Images werden zum offiziellen NGINX Docker Hub verschoben. Diese Version bietet erstmals Unterstützung für gRPC, passive Integritätsprüfungen, Helm-Diagramme und Prometheus.
  • August ( v1.3.0 ) – NGINX Plus-Kunden können jetzt Metriken nach Prometheus exportieren und aktive Integritätsprüfungen nutzen. Darüber hinaus profitieren alle von Verbesserungen bei Helm-Diagrammen, zusammenführbaren Ingress-Ressourcen und einer einfacheren Verwaltung benutzerdefinierter Vorlagen (siehe „Ankündigung des NGINX Ingress Controller für Kubernetes Release 1.3.0 “).
  • November ( v1.4.0 ) – Unterstützung für TCP/UDP wird hinzugefügt, wodurch Layer 4-Verkehrsmanagement möglich wird. Zu den weiteren Funktionen gehören eine einfachere Entwicklung benutzerdefinierter Anmerkungen und Unterstützung für den Lastausgleichsalgorithmus „Random with Two Choices“ (siehe Ankündigung von NGINX Ingress Controller für Kubernetes Release 1.4.0 ).

Auf der NGINX Conf 2018 betritt Michael Pleshakov die Bühne mit dem Vortrag „NGINX als Kubernetes-Ingress-Controller verwenden“ . Dort erklärt er, wie man den NGINX-Ingress-Controller mit Helm bereitstellt, HTTP- und TCP/UDP-Lastausgleich konfiguriert, mit Prometheus überwacht und Fehler behebt.

2019

Wir stellen unsere Alternative zu den standardmäßigen Kubernetes-Ingress-Ressourcen vor, die die Ausführung erweiterter Funktionen einfacher und zuverlässiger macht.

In „Die nächste Generation des NGINX Ingress Controllers“ kehrt Michael Pleshakov zur NGINX Conf 2019 zurück, um VS/VSR für Anwendungsfälle wie Blue-Green-Bereitstellungen und A/B-Tests zu demonstrieren.

2020

Neben zahlreichen Verbesserungen der NGINX Ingress-Ressourcen ist das Hauptthema in diesem Jahr die Integration mit Ökosystem-Tools und NGINX-Produkten.

In „Secure Production Apps with NGINX and OpenShift“ demonstriert der technische Marketingingenieur Amir Rawdat, wie man den NGINX Ingress Operator verwendet, die rollenbasierte Zugriffskontrolle (RBAC) für die funktionsübergreifende Bereitstellung nutzt, containerisierte Apps mit NGINX App Protect sichert und Clients mit JWTs validiert.

2021

Sicherheit ist neben der stärkeren Integration von Ökosystemen ein Hauptthema.

In seiner NGINX Sprint 2.0- Sitzung „Master Microservices mit End-to-End -Verschlüsselung “ demonstriert der Softwareentwickler Aidan Carson, wie man den Rand mit NGINX Ingress Controller sichert, eine sichere Zugriffskontrolle zwischen Diensten mit NGINX Service Mesh einrichtet und beide Produkte verwendet, um ausgehenden Datenverkehr mit mTLS zu sichern.

Nächster Schritt: Testen Sie NGINX Ingress Controller

Wenn Sie sich für einen Open-Source-Ingress-Controller als richtige Wahl für Ihre Apps entschieden haben, können Sie schnell mit dem auf Open Source basierenden NGINX Ingress Controller in unserem GitHub-Repository loslegen.

Wir hoffen, dass Sie für große Produktionsbereitstellungen unseren kommerziellen NGINX Ingress Controller basierend auf NGINX Plus ausprobieren. Es ist als kostenlose 30-Tage-Testversion verfügbar, die NGINX App Protect umfasst.

Weitere Blogbeiträge zu F5 NGINX lesen ›

„Dieser Blogbeitrag kann auf Produkte verweisen, die nicht mehr verfügbar und/oder nicht mehr unterstützt werden. Die aktuellsten Informationen zu verfügbaren F5 NGINX-Produkten und -Lösungen finden Sie in unserer NGINX-Produktfamilie . NGINX ist jetzt Teil von F5. Alle vorherigen NGINX.com-Links werden auf ähnliche NGINX-Inhalte auf F5.com umgeleitet."