Ein Leitfaden zur Auswahl eines Ingress-Controllers, Teil 4: Optionen für den NGINX Ingress Controller

Jenn GileLeiter Produktmarketing, NGINX

Redaktion – Dieser Beitrag ist Teil einer zehnteiligen Serie:

1. Komplexität reduzieren mit Kubernetes für den Produktionseinsatz
2. So verbessern Sie die Ausfallsicherheit in Kubernetes mit erweitertem Traffic-Management
3. So verbessern Sie die Transparenz in Kubernetes
4. Sechs Möglichkeiten, Kubernetes mithilfe von Traffic-Management-Tools abzusichern
5. Leitfaden zur Auswahl eines Ingress-Controllers, Teil 1: Ermitteln Sie Ihre Anforderungen
6. Leitfaden zur Auswahl eines Ingress-Controllers, Teil 2: Risiken und Zukunftssicherheit
7. Ein Leitfaden zur Auswahl eines Ingress-Controllers, Teil 3: Open Source vs. Standardlösung vs. kommerzielle Lösung
8. Ein Leitfaden zur Auswahl eines Ingress-Controllers, Teil 4: Optionen für NGINX Ingress Controller (dieser Beitrag)
9. So wählen Sie ein Service Mesh aus
10. Leistungstests von NGINX Ingress Controllern in einer dynamischen Kubernetes-Cloud-Umgebung

Sie können die vollständige Blogreihe auch als kostenloses E-Book herunterladen: „Kubernetes von der Testumgebung in die Produktion überführen“.

Laut der Umfrage 2020 der Cloud Native Computing Foundation (CNCF) ist NGINX die am häufigsten verwendete Datenebene in Ingress-Controllern für Kubernetes – aber wussten Sie, dass es mehr als einen „NGINX Ingress Controller“ gibt?

Eine frühere Version dieses Blogbeitrags, die 2018 unter dem Titel „Moment mal, welchen NGINX Ingress Controller für Kubernetes verwende ich eigentlich?“ veröffentlicht wurde, entstand aus einem Gespräch mit einem Mitglied der Community über die Existenz zweier beliebter Ingress Controller, die NGINX verwenden.

Es ist leicht nachzuvollziehen, warum es Verwirrung gab (und immer noch gibt). Beide Ingress-Controller sind:

• Werden als „NGINX Ingress Controller“ bezeichnet
• Open Source
• Auf GitHub unter sehr ähnlichen Repository-Namen gehostet
• Das Ergebnis von Projekten, die ungefähr zur gleichen Zeit gestartet wurden

Und natürlich besteht die größte Gemeinsamkeit darin, dass sie dieselbe Funktion implementieren.

NGINX vs. Kubernetes-Community-Ingress-Controller

Zur besseren Übersicht unterscheiden wir die beiden Versionen wie folgt:

• Community-Version – Die Community-Version des Ingress-Controllers ist im kubernetes/ingress-nginx-Repository auf GitHub zu finden, basiert auf NGINX Open Source und ist auf Kubernetes.io dokumentiert. Sie wird von der Kubernetes-Community gepflegt.
• NGINX-Version – Zu finden im nginxinc/kubernetes-ingress-Repository auf GitHub. Der NGINX Ingress Controller wird von F5 NGINX entwickelt und gepflegt. Die Dokumentation ist unter docs.nginx.com verfügbar. Er ist in zwei Editionen erhältlich:
  • Auf NGINX Open Source basierend (kostenlose Open-Source-Option)
  • NGINX Plus-basiert (kommerzielle Option)

Es gibt außerdem eine Reihe weiterer NGINX-basierter Ingress-Controller wie Kong, deren Namen sich glücklicherweise leicht unterscheiden lassen. Wenn Sie nicht sicher sind, welchen NGINX Ingress Controller Sie verwenden, überprüfen Sie das Container-Image des laufenden Ingress-Controllers und vergleichen Sie anschließend den Namen des Docker-Images mit den oben aufgeführten Repositorys.

Ziele und Prioritäten des NGINX Ingress Controllers

Ein wesentlicher Unterschied zwischen dem NGINX Ingress Controller und dem Community Ingress Controller (sowie anderen auf NGINX Open Source basierenden Ingress Controllern) liegt in ihren Entwicklungs- und Bereitstellungsmodellen, denen wiederum unterschiedliche Ziele und Prioritäten zugrunde liegen.

• Entwicklungsphilosophie – Unsere oberste Priorität bei allen NGINX-Projekten und -Produkten ist es, ein schnelles, schlankes Tool mit langfristiger Stabilität und Konsistenz bereitzustellen. Wir setzen alles daran, Verhaltensänderungen zwischen den Versionen zu vermeiden, insbesondere solche, die die Abwärtskompatibilität beeinträchtigen. Wir versprechen Ihnen, dass Sie bei einem Upgrade keine unerwarteten Überraschungen erleben werden. Außerdem ist uns Wahlfreiheit wichtig. Daher können alle unsere Lösungen auf jeder Plattform bereitgestellt werden, einschließlich Bare-Metal-Systemen, Containern, VMs sowie öffentlichen, privaten und hybriden Clouds.
• Integrierte Codebasis – NGINX Ingress Controller verwendet für den Lastenausgleich eine zu 100 % reine Instanz von NGINX Open Source oder NGINX Plus und setzt dabei ausschließlich auf eine Best-Practice-Konfiguration mit nativen NGINX-Funktionen. Er ist weder von Drittanbietermodulen noch von Lua-Code abhängig, die nicht unseren Interoperabilitätstests unterzogen wurden. Wir setzen unseren Ingress Controller nicht aus zahlreichen Drittanbieter-Repositorys zusammen, sondern entwickeln und pflegen den Load Balancer (NGINX und NGINX Plus) sowie die Ingress-Controller-Software (eine Go-Anwendung) selbst. Wir sind die alleinige Instanz für sämtliche Komponenten unseres Ingress Controllers.
• Erweitertes Traffic-Management – Eine der Einschränkungen der standardmäßigen Kubernetes-Ingress-Ressource besteht darin, dass Sie zusätzliche Funktionen wie Annotationen, ConfigMaps und benutzerdefinierte Vorlagen verwenden müssen, um sie um erweiterte Funktionen zu ergänzen. NGINX-Ingress-Ressourcen bieten einen nativen, typsicheren und eingerückten Konfigurationsstil, der die Implementierung von Funktionen für den Ingress-Lastenausgleich vereinfacht, darunter TCP/UDP, Circuit Breaking, A/B-Tests, Blue-Green-Deployments, Header-Manipulation, gegenseitige TLS-Authentifizierung (mTLS) und Web Application Firewall (WAF).
• Kontinuierliche Produktionsreife – Jede Version wird nach einem supportfähigen Produktionsstandard entwickelt und gepflegt. Von diesem Fokus auf „Enterprise-Niveau“ profitieren Sie gleichermaßen, unabhängig davon, ob Sie die auf NGINX Open Source basierende oder die auf NGINX Plus basierende Edition verwenden. Nutzer von NGINX Open Source können ihre Fragen auf GitHub von unserem Entwicklungsteam beantworten lassen, während Abonnenten von NGINX Plus erstklassigen Support erhalten. In jedem Fall ist es so, als hätten Sie einen NGINX-Entwickler in Ihrem DevOps-Team!

NGINX Open Source vs. NGINX Plus – Warum sollten Sie auf unsere kommerzielle Edition upgraden?

Und wenn wir schon dabei sind, sehen wir uns einige der wichtigsten Vorteile des auf NGINX Plus basierenden NGINX Ingress Controllers an. Wie bereits in So wählen Sie einen Kubernetes Ingress Controller aus, Teil 3: Open Source vs. Standard vs. kommerziell erläutert, gibt es erhebliche Unterschiede zwischen Open-Source- und kommerziellen Ingress Controllern. Wenn Sie große Kubernetes-Bereitstellungen und komplexe Anwendungen für den Produktivbetrieb planen, werden Sie feststellen, dass Sie mit unserem kommerziellen Ingress Controller in einigen wichtigen Bereichen Zeit und Geld sparen.

Sicherheit und Compliance

Einer der Hauptgründe, warum es vielen Unternehmen nicht gelingt, Kubernetes-Anwendungen in der Produktion bereitzustellen, ist die Schwierigkeit, deren Sicherheit und Compliance zu gewährleisten. Der auf NGINX Plus basierende NGINX Ingress Controller ermöglicht fünf Anwendungsfälle, die für den Schutz Ihrer Anwendungen und Kunden von entscheidender Bedeutung sind.

• Den Netzwerkrand absichern – In einer gut konzipierten Kubernetes-Bereitstellung ist der Ingress-Controller der einzige Zugangspunkt für Datenverkehr auf der Datenebene, der zu den in Kubernetes ausgeführten Diensten fließt. Damit ist er der ideale Ort für eine Web Application Firewall (WAF). NGINX App Protect lässt sich in NGINX Ingress Controller<.htmla> integrieren, um Ihre Kubernetes-Anwendungen vor den OWASP Top 10 und vielen weiteren Schwachstellen zu schützen, gewährleistet PCI-DSS-Konformität und übertrifft ModSecurity.
• Authentifizierung und Autorisierung zentralisieren – Sie können am Eingangspunkt eine Authentifizierungs- und Single-Sign-on-Schicht (SSO) mit OpenID Connect (OIDC) – basierend auf dem OAuth-2.0-Framework – und JSON-Web-Token-Authentifizierung (JWT) implementieren.
• Ende-zu-Ende-Verschlüsselung implementieren – Wenn Sie den Datenverkehr zwischen Diensten absichern müssen, werden Sie wahrscheinlich ein Service Mesh in Betracht ziehen. Das dauerhaft kostenlose NGINX Service Mesh lässt sich nahtlos in den NGINX Ingress Controller integrieren und ermöglicht Ihnen, sowohl eingehenden als auch ausgehenden mTLS-Datenverkehr effizient und mit geringerer Latenz als bei anderen Service Meshes zu steuern.
• Erhalten Sie zeitnahe und proaktive Benachrichtigungen über Patches – Wenn CVEs gemeldet werden, werden Abonnenten proaktiv informiert und erhalten zeitnah Patches. Sie können die Patches sofort anwenden, um das Risiko einer Ausnutzung zu verringern, anstatt selbst auf GitHub nach Updates suchen oder wochenlang (oder sogar monatelang) auf die Veröffentlichung eines Patches warten zu müssen.
• FIPS-Konformität gewährleisten – Sie können den FIPS-Modus aktivieren, um sicherzustellen, dass Clients bei der Kommunikation mit NGINX Plus eine starke Verschlüsselung mit einer vertrauenswürdigen Implementierung verwenden.

Erfahren Sie, wie der deutsche Automobilkonzern Audi seine Red Hat OpenShift-Apps absicherte – in „Audi macht seine technologische Vision und App-Innovationen mit NGINX zukunftssicher“.

Anwendungsleistung und Ausfallsicherheit

Verfügbarkeit und Anwendungsgeschwindigkeit sind für Entwickler und Platform-Ops-Teams häufig wichtige Leistungskennzahlen (KPIs). Der auf NGINX Plus basierende NGINX Ingress Controller ermöglicht fünf Anwendungsfälle, mit denen Sie die Versprechen von Kubernetes einlösen können.

• Live-Monitoring nutzen – Das NGINX Plus-Dashboard zeigt Hunderte wichtiger Last- und Leistungsmetriken an, sodass Sie die Ursache langsamer (oder ausgefallener!) Anwendungen schnell ermitteln können.
• Ausfälle schneller erkennen und beheben – Implementieren Sie einen Schutzschalter mit aktiven Zustandsprüfungen, der den Zustand Ihrer TCP- und UDP-Upstream-Server proaktiv überwacht.
• Neukonfiguration ohne Neustarts – Eine schnellere, unterbrechungsfreie Neukonfiguration stellt sicher, dass Sie Anwendungen mit gleichbleibender Leistung und Ressourcennutzung sowie geringerer Latenz als bei den Open-Source-Alternativen bereitstellen können.
• Neue Funktionen und Deployments gründlich testen – Vereinfachen Sie A/B-Tests und Blue-Green-Deployments, indem Sie die Prozentwerte mithilfe des Key-Value-Stores ohne erneutes Laden ändern.
• Supportanfragen schnell klären – Vertraulicher, kommerzieller Support ist für Unternehmen unerlässlich, die nicht darauf warten können, dass die Community ihre Fragen beantwortet, oder die es nicht riskieren können, sensible Daten offenzulegen. Der NGINX-Support ist in mehreren, auf Ihre Anforderungen zugeschnittenen Stufen verfügbar und umfasst Unterstützung bei Installation, Bereitstellung, Fehlerdiagnose und Fehlerbehebung. Sie erhalten sogar Hilfe, wenn etwas einfach nicht „richtig“ zu sein scheint.

Erfahren Sie, wie das Unternehmen für geschäftliche Textnachrichten Zipwhip eine Verfügbarkeit von 99,99 % für seine SaaS-Anwendungen erreicht hat – in „Sicherheit und Einblick in den Datenverkehr auf Amazon EKS mit NGINX verbessern“.

Nächster Schritt: NGINX Ingress Controller ausprobieren

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

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

Über den Autor

Jenn GileLeiter Produktmarketing, NGINX

Weitere Blogbeiträge von Jenn Gile