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

Brian EhlertDirektor für Produktmanagement

Im Oktober haben wir Version 2.0 von F5 NGINX Ingress Controller veröffentlicht (nginxinc/kubernetes-ingress) und damit Unterstützung für Kubernetes 1.22 sowie Version 1 der Ingress API (networking.k8s.io/v1) hinzugefügt. Vielleicht fragen Sie sich jetzt: Na und?

Die Antwort auf die Frage „Na und?“ ist vielschichtig. Wir nähern uns ihr, indem wir drei miteinander verknüpfte Fragen beantworten:

• Warum sind Kubernetes-Releases so wichtig?
• Was ist die Ingress-API und warum ist das Upgrade auf networking.k8s.io/v1 wichtig?
• Welche Auswirkungen hat NGINX Ingress Controller 2.0 auf bestehende Kunden?

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

Warum sind Kubernetes-Releases so wichtig?

Die Antwort auf diese Frage ist einfach und zugleich kompliziert. Das Kompatibilitätsmanagement für Kubernetes ist anspruchsvoll, da Kubernetes-Administratoren drei Kategorien der Versionierung verwalten müssen:

1. Die Kubernetes-Plattform selbst – Mit jeder neuen Version stellt das Kubernetes-Team die Wartung einer älteren Version ein. Eine solche Version weiterhin zu verwenden, ist für Ihre Risikomanagementstrategie problematisch und erschwert die Fehlerbehebung, da keine Unterstützung durch das Kubernetes-Team mehr verfügbar ist. Derzeit pflegt das Kubernetes-Projekt Release-Zweige für die drei neuesten Nebenversionen (1.20, 1.21 und 1.22). Kubernetes 1.19 und neuere Versionen erhalten etwa 1 Jahr lang Patch-Support, während Kubernetes 1.18 und ältere Versionen etwa 9 Monate lang Patch-Support erhielten. (Der kürzere Zeitraum für 1.18 und ältere Versionen ist darauf zurückzuführen, dass Kubernetes früher viermal statt wie heute dreimal pro Jahr veröffentlicht wurde).
2. Die Kubernetes-APIs – Mit jeder Kubernetes-Version kommen neue APIs hinzu und veraltete werden als überholt gekennzeichnet. Änderungen an APIs wirken sich auf die zugehörigen 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 dazu führen, dass Ihre Tools – beispielsweise ein Ingress-Controller – und die zugehörigen Ressourcen nicht mehr ordnungsgemäß funktionieren.

Sie müssen also drei Zeitpläne im Blick behalten: einen für Kubernetes, einen für die Ingress-API und einen für den NGINX Ingress Controller. Damit Kubernetes weiterhin funktioniert, müssen Sie den optimalen Punkt finden, an dem die Kubernetes-Version mit den APIs und dem NGINX Ingress Controller kompatibel ist. Wenn Sie eine der drei Komponenten aktualisieren, ohne zuvor die Kompatibilität zu prüfen, kann dies drastische Folgen haben. Wenn nicht alle drei Komponenten miteinander kompatibel sind … herzlichen Glückwunsch, Sie haben Ihre Anwendungen lahmgelegt!

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

Die Ingress-API ermöglicht es einem Ingress-Controller, Ihre Kubernetes-Anwendungen sicher zugänglich 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 automatisch eine Version als die jeweils andere dar. Diese im Hintergrund wirkende Kompatibilität der API-Versionen bietet Ihnen betriebliche Vorteile, kann jedoch Ihre Planung erschweren.

Mit der Veröffentlichung von Kubernetes 1.22 wurde v1 zur einzigen Version der Ingress-API. Das ist von Bedeutung, denn da Ingress-API v1 nun die maßgebliche Version ist, gelten alle Betaversionen (extensions/v1beta1 und networking.k8s.io/v1beta1) als veraltet. Für Organisationen, die Ingress-API v1 noch nicht eingeführt haben, ist das zwar mit Umstellungen verbunden, doch wir bei NGINX sehen diese Änderung als positives Zeichen. Dass die Ingress-API die Betaphase verlässt, signalisiert ihre Weiterentwicklung zu einer ausgereiften und vollständig umgesetzten API. Warum ist diese Änderung nun wichtig? Das hängt mit der Versionsverwaltung zusammen. Angenommen, Sie aktualisieren einen bestehenden Cluster auf Kubernetes 1.22, verwenden aber weiterhin v1beta1-Ressourcen für Ingress … herzlichen Glückwunsch, Sie haben Ihre Ingress-Ressourcen außer Funktion gesetzt!

Wie wirkt sich NGINX Ingress Controller 2.0 auf bestehende Kunden aus?

Da der NGINX Ingress Controller eng mit der Ingress API verknüpft ist, hatte die Veröffentlichung von v1 erhebliche Auswirkungen auf unser Produkt – und damit auch auf Sie als unsere Kunden –, weshalb wir bei der Versionsnummer des NGINX Ingress Controllers von 1.x auf 2.x gesprungen sind. Wir haben die Architektur des NGINX Ingress Controllers 2.0 überarbeitet, um die Ingress API v1 zu nutzen und vollständige Kompatibilität mit Kubernetes 1.22 zu gewährleisten.

Wenn Sie den NGINX Ingress Controller verwenden, müssen Sie umgehend einige versionsabhängige Maßnahmen ergreifen, um zu verhindern, dass Kubernetes, Ihre Ingress-Ressourcen oder der NGINX Ingress Controller nicht mehr funktionieren:

• Kubernetes 1.18 und früher:
  • Stellen Sie sicher, dass Sie NGINX Ingress Controller 1.12 verwenden, damit Ihnen der größtmögliche Funktionsumfang zur Verfügung steht. (Wenn Sie ein Upgrade auf NGINX Ingress Controller 2.0 durchführen, müssen Sie auch ein Upgrade auf Kubernetes 1.19 oder höher durchführen.)
  • Erstellen 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:
  • Führen Sie ein Upgrade auf NGINX Ingress Controller 2.0 durch.
  • Wenn Sie Ihre Ingress-bezogenen Ressourcen noch nicht zu networking.k8s.io/v1 migriert haben (siehe die Versionshinweise zu NGINX Ingress Controller 2.0), sollten Sie jetzt einen Plan dafür erstellen. Kubernetes 1.19–1.21 unterstützt alle aktuellen Versionen der Ingress-API (sowohl v1beta1 als auch v1). Dadurch haben Sie die Möglichkeit, die Ressourcen direkt zu konvertieren.
  • Falls noch nicht geschehen, migrieren Sie Ihre Ingress- und IngressClass-Ressourcen umgehend zu networking.k8s.io/v1.
    • Wenn Sie die veraltete Annotation „kubernetes.io/ingress.class“ in Ihren Ingress-Ressourcen verwenden, empfehlen wir Ihnen, zum Feld „ingressClassName“ zu wechseln.
    • Nutzen Sie unsere Dokumentation und Beispiele (verfügbar mit networking.k8s.io/v1 und dem Feld ingressClassName der Ingress-Ressource), um Ihre Aktualisierungen zu planen.
• Kubernetes 1.22:
  • Stellen Sie sicher, dass Sie bereits NGINX Ingress Controller 2.0 verwenden, da frühere Versionen von NGINX Ingress Controller nicht mit Kubernetes 1.22 kompatibel sind und die 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 der NGINX Ingress Controller von einem noch jungen Tool zu einer leistungsstarken Lösung für Kubernetes-Netzwerke entwickelt. Werfen wir einen Blick auf seine Entwicklung von der Markteinführung bis heute.

2016 (v0.5.0)

NGINX-Ingenieur Michael Pleshakov veröffentlicht den ersten Eintrag in unserem GitHub-Repository (nginxinc/kubernetes-ingress), wodurch NGINX und F5 NGINX Plus als Kubernetes-Ingress-Controller (KIC) eingesetzt werden können.

Der NGINX Ingress Controller hat auf der KubeCon EU 2016 seinen ersten öffentlichen Auftritt. Sehen Sie sich die Aufzeichnung an: Tag 1: Entwicklung einer fortschrittlichen Load-Balancing-Lösung für Kubernetes mit NGINX; KubeCon EU 2016.

2017 (v1.0.0)

Das Projekt erreicht die Produktionsreife und bietet in der auf NGINX Plus basierenden Version unter anderem wichtige Unterstützung für JSON Web Tokens (JWTs).

Auf der NGINX Conf 2017 demonstriert Michael Pleshakov produktionsreife Funktionen, darunter erweitertes Load Balancing, in „NGINX Plus als Ingress-Controller für das Load Balancing von Anwendungen auf Kubernetes verwenden“.

2018

Der NGINX Ingress Controller erhält umfassende Verbesserungen in den Bereichen Transparenz, Benutzerfreundlichkeit und Flexibilität:

• Mai (v1.2.0) – Das Projekt übernimmt die neue NGINX Plus API, und die nginx-ingress-Images werden in den offiziellen NGINX Docker Hub verschoben. Diese Version bietet erstmals Unterstützung für gRPC, passive Integritätsprüfungen, Helm-Charts und Prometheus.
• August (v1.3.0) – Kunden von NGINX Plus können jetzt Metriken nach Prometheus exportieren und aktive Integritätsprüfungen nutzen. Darüber hinaus profitieren alle von Verbesserungen an Helm-Charts und zusammenführbaren Ingress-Ressourcen sowie von einer einfacheren Verwaltung benutzerdefinierter Vorlagen (siehe „Ankündigung von NGINX Ingress Controller für Kubernetes Version 1.3.0“).
• November (v1.4.0) – Unterstützung für TCP/UDP wurde hinzugefügt und ermöglicht die Verwaltung von Datenverkehr auf Layer 4. Weitere Funktionen umfassen die einfachere Entwicklung benutzerdefinierter Annotationen und die Unterstützung des Lastverteilungsalgorithmus „Random with Two Choices“ (siehe „Ankündigung von NGINX Ingress Controller für Kubernetes Version 1.4.0“).

Auf der NGINX Conf 2018 betritt Michael Pleshakov die Bühne für seinen Vortrag „NGINX als Kubernetes Ingress Controller verwenden“. Darin zeigt er, wie man den NGINX Ingress Controller mit Helm bereitstellt, den HTTP- und TCP/UDP-Lastenausgleich konfiguriert, die Umgebung mit Prometheus überwacht und Fehler behebt.

2019

Wir stellen unsere Alternative zu den standardmäßigen Kubernetes-Ingress-Ressourcen vor, mit der sich erweiterte Funktionen einfacher und zuverlässiger umsetzen lassen.

• Mai (v1.5.0) – Die Ressourcen VirtualServer und VirtualServerRoute (VS/VSR) werden als neuer Konfigurationsansatz eingeführt. VS/VSR sind die ersten NGINX-Ingress-Ressourcen, die einen nativen, typsicheren und eingerückten Konfigurationsstil bieten, der die Implementierung des Ingress-Lastenausgleichs vereinfacht (siehe „Ankündigung von NGINX Ingress Controller für Kubernetes Version 1.5.0<.htmla>“).
• Dezember (v1.6.0) – Die Dokumentation wird auf docs.nginx.com bereitgestellt. Die VS/VSR-Ressourcen erhalten umfassendere Unterstützung für den Lastenausgleich und erreichen Produktionsreife. Zur besseren Überwachung und Fehlerbehebung wird OpenTracing-Unterstützung hinzugefügt. Außerdem kann der Controller nun zur Verbesserung der Sicherheit als Benutzer ohne root-Berechtigungen ausgeführt werden (siehe Ankündigung von NGINX Ingress Controller für Kubernetes Version 1.6.0).

In „The Next Generation of NGINX Ingress Controller“ kehrt Michael Pleshakov zur NGINX Conf 2019 zurück, um VS/VSR für Anwendungsfälle wie Blue-Green-Deployments und A/B-Tests zu demonstrieren.

2020

Neben zahlreichen Verbesserungen an NGINX-Ingress-Ressourcen liegt der Schwerpunkt in diesem Jahr auf der Integration mit Tools aus dem Ökosystem und NGINX-Produkten.

• April (v1.7.0) – Wir veröffentlichen den NGINX Ingress Operator, um eine schnelle, einfache und zertifizierte Möglichkeit zur Bereitstellung des NGINX Ingress Controllers in OpenShift 4.x-Umgebungen zu bieten. Die NGINX Ingress-Ressourcen werden weiterhin um die Unterstützung zusätzlicher Protokolle und Leistungsschalter sowie um verbesserte Validierungs- und Berichtsfunktionen erweitert (siehe „Ankündigung von NGINX Ingress Controller für Kubernetes, Version 1.7.0“).
• Juli (v1.8.0) – Die Integration mit F5 NGINX App Protect WAF ermöglicht es Kunden, eine schlanke, flexible WAF im selben Container wie den Ingress Controller bereitzustellen. Zudem können NGINX-Ingress-Ressourcen nun über Snippets oder benutzerdefinierte Vorlagen angepasst werden. Funktionen wie URI-Umschreibungen und Zugriffssteuerungslisten ermöglichen eine präzisere Steuerung (siehe „Ankündigung von NGINX Ingress Controller für Kubernetes Version 1.8.0“).
• Oktober (v1.9.0) – Die Integration mit F5 NGINX Service Mesh ermöglicht die Verwaltung des Nord-Süd- und Ost-West-Datenverkehrs in derselben Konfiguration. Grafana-Dashboards erleichtern die Visualisierung historischer Daten (siehe Ankündigung von NGINX Ingress Controller Version 1.9.0).

In „Produktionsanwendungen mit NGINX und OpenShift absichern“ zeigt Technical Marketing Engineer Amir Rawdat, wie sich der NGINX Ingress Operator einsetzen, die rollenbasierte Zugriffskontrolle (RBAC) für die funktionsübergreifende Bereitstellung nutzen, containerisierte Anwendungen mit NGINX App Protect absichern und Clients mithilfe von JWTs validieren lassen.

2021

Sicherheit ist ein zentrales Thema, ebenso wie weitere Integrationen in das Ökosystem.

• Februar (v1.10.0) – Die wichtigste Neuerung ist die OpenID-Connect-Authentifizierung (OIDC), mit der sich die JWT-Authentifizierung einfach für eine robuste Single-Sign-on-Lösung (SSO) nutzen lässt (siehe „Einfaches und robustes Single Sign-on mit OpenID Connect und dem NGINX Ingress Controller“).
• März (v1.11.0) – Wesentliche Verbesserungen an den WAF- und Lastverteilungsrichtlinien sorgen für zusätzliche Leistungsfähigkeit und Flexibilität, einschließlich Zustandsprüfungen und Statusberichten (siehe „Verbesserte TCP/UDP-Lastverteilung und WAF-Konfiguration mit dem NGINX Ingress Controller“).
• Juli (v1.12.0) – Bei den Highlights dieser Version dreht sich alles um eine einfache Bereitstellung. Neben dem Kauf über den AWS Container Marketplace ermöglichen wir es, vorgefertigte Images abzurufen aus der F5 Container Registry (siehe NGINX ist im AWS Marketplace for Containers verfügbar).
• Oktober (v2.0.3) – Obwohl dieses Release hinsichtlich des Funktionsumfangs keinen großen Meilenstein darstellt, markiert es einen wichtigen Schritt für die Interoperabilität mit der Kubernetes-API und die Weiterentwicklung des Ingress-Objekts. Diese Änderung bedeutet, dass NGINX Ingress Controller 2.0 (und höher) mit Kubernetes 1.19 und höher kompatibel ist. NGINX Ingress Controller 2.0 ist außerdem die einzige Version, die mit Kubernetes 1.22 und höher bereitgestellt werden kann.

In seiner NGINX-Sprint-2.0-Session „Microservices mit End-to-End-Verschlüsselung meistern“ zeigt Softwareentwickler Aidan Carson, wie sich der Netzwerkrand mit dem NGINX Ingress Controller absichern, eine sichere Zugriffskontrolle zwischen Diensten mit NGINX Service Mesh einrichten und der ausgehende Datenverkehr mithilfe beider Produkte durch mTLS schützen lässt.

Nächster Schritt: Testen Sie den NGINX Ingress Controller

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

Für große Produktionsumgebungen empfehlen wir Ihnen, unseren kommerziellen, auf NGINX Plus basierenden NGINX Ingress Controller auszuprobieren. Er ist im Rahmen einer kostenlosen 30-tägigen Testversion erhältlich, die NGINX App Protect umfasst.

Über den Autor

Brian EhlertDirektor für Produktmanagement

Weitere Blogbeiträge von Brian Ehlert