Redaktion – Dieser Beitrag ist Teil einer zehnteiligen Serie:
- Komplexität reduzieren mit Kubernetes für den Produktionseinsatz
- So verbessern Sie die Ausfallsicherheit in Kubernetes mit erweitertem Traffic-Management
- So verbessern Sie die Transparenz in Kubernetes
- Sechs Möglichkeiten, Kubernetes mithilfe von Traffic-Management-Tools abzusichern
- Leitfaden zur Auswahl eines Ingress-Controllers, Teil 1: Ermitteln Sie Ihre Anforderungen
- Ein Leitfaden zur Auswahl eines Ingress-Controllers, Teil 2: Risiken und Zukunftssicherheit
- Ein Leitfaden zur Auswahl eines Ingress-Controllers, Teil 3: Open Source vs. Standard vs. kommerziell (dieser Beitrag)
- Leitfaden zur Auswahl eines Ingress-Controllers, Teil 4: Optionen für NGINX Ingress Controller
- So wählen Sie ein Service Mesh aus
- 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 Test- in die Produktionsumgebung überführen.
Herzlichen Glückwunsch! Nachdem Sie die ersten beiden Teile unseres Leitfadens zur Auswahl eines Ingress-Controllers gelesen haben, sind Sie fast bereit, sich für einen zu entscheiden. Fassen wir noch einmal zusammen, was wir bisher behandelt haben:
- In Teil 1 erläutern wir, wie Sie Ihre Anforderungen ermitteln, unter anderem in Bezug auf Leistung, Budget, Anwendungsfälle, Architektur und Verantwortlichkeiten.
- In Teil 2, sprechen wir über Risiken, die durch die Wahl des falschen Ingress-Controllers entstehen können, und zeigen wichtige Bereiche auf, in denen Sie Ihre Entscheidung zukunftssicher gestalten können.
Ingress-Controller lassen sich in drei Kategorien einteilen: Open Source, Standard und kommerziell. Jede Kategorie hat ihre eigenen Anwendungsfälle. Daher sollten Sie sich vor der Auswahl über Ihre kurz- und langfristigen Anforderungen im Klaren sein. In diesem Blogbeitrag beleuchten wir die Vor- und Nachteile der einzelnen Kategorien.
Open-Source-Ingress-Controller
Viele Open-Source-Ingress-Controller werden von einer Community aus Benutzern und freiwilligen Entwicklern gepflegt, einige verfügen jedoch auch über eigene Entwicklungsteams. Zwei der beliebtesten Open-Source-Ingress-Controller basieren auf NGINX – einer wird von der Kubernetes-Community gepflegt, während der andere vom NGINX-Kernentwicklungsteam geleitet und als Open Source bereitgestellt wird. Einen ausführlicheren Vergleich NGINX-basierter Ingress-Controller finden Sie in Teil 4 unserer Reihe.

- Vorteile:
- Kostenlos und von der Community getragen – Viele Menschen und Organisationen entscheiden sich nicht nur wegen des unschlagbaren Preises (kostenlos!) für Open-Source-Projekte, sondern auch, weil sie von der Community entwickelte Technologien bevorzugen.
- Geschwindigkeit der Funktionsentwicklung – Diese Ingress-Controller gehören mit größerer Wahrscheinlichkeit zu den Vorreitern bei der Entwicklung innovativer Funktionen.
- Nachteile (wie bei Open-Source-Projekten im Allgemeinen):
- Kosten (Zeit) – Es fehlen sofort einsatzbereite Tools für eine einfache Einrichtung und Skalierbarkeit, sodass Sie Zeit in Anpassungen und Behelfslösungen für Ihre spezifischen Anforderungen investieren müssen.
- Riskant – Es kann Probleme mit der Stabilität, Sicherheit und Zuverlässigkeit geben (aufgrund des Schwerpunkts auf einer schnellen Bereitstellung neuer Funktionen und der ehrenamtlichen Tätigkeit der Mitwirkenden). Patches für allgemeine Schwachstellen und Sicherheitslücken (Common Vulnerabilities and Exposures, CVEs) werden möglicherweise nie veröffentlicht oder treffen möglicherweise erst Monate nach der öffentlichen Bekanntgabe der CVE ein, sodass Hacker reichlich Zeit haben, Ihren Ingress-Controller anzugreifen.
- Minimale oder gar keine Unterstützung – Bei den meisten gilt: „Selbst ist der Nutzer“ … Sie sind auf sich allein gestellt und haben nur die Dokumentation. Wenn Sie auf Probleme stoßen, die Sie nicht selbst lösen können, kann es schwierig (oder unmöglich) sein, Hilfe zu bekommen – Ihnen bleibt praktisch nur, Ihr Problem in Community-Foren zu posten und zu hoffen, dass andere Mitglieder der Community (a) sich die Mühe machen zu antworten und (b) eine Lösung kennen.
- Zusammenfassung: Wenn Unternehmen erste Erfahrungen mit Kubernetes sammeln, entscheiden sie sich häufig für einen Open-Source-Ingress-Controller – entweder aus Bequemlichkeit oder weil die Dokumentation verspricht, dass sie damit schnell und kostenlos loslegen können. Für den Einstieg, für Tests oder für Produktivumgebungen mit geringem Datenverkehr kann das hervorragend funktionieren.
Standardmäßige Ingress-Controller
Obwohl viele standardmäßige Ingress-Controller auf Open-Source-Technologie basieren, ordnen wir sie einer eigenen Kategorie zu, da sie von einem Unternehmen entwickelt und gepflegt werden, das eine vollständige Kubernetes-Plattform bereitstellt (und häufig auch Unterstützung bei deren Verwaltung bietet). Beispiele aus dieser Kategorie sind Ingress-Controller für öffentliche Clouds, Rancher und der Red Hat OpenShift Router.

- Vorteile:
- Kostenlos oder kostengünstig – Der niedrige Preis ist ein überzeugender Grund, diese Produkte zu nutzen. Sie sind bereits in die Plattform integriert, was gerade am Anfang definitiv Zeit spart.
- Zuverlässig und mit Support – Da sie von einem spezialisierten Entwicklungsteam gepflegt werden, sind sie möglicherweise zuverlässiger als von der Community gepflegte Ingress-Controller. Kommerzieller Support ist in der Regel inbegriffen oder gegen Aufpreis erhältlich.
- Nachteile:
- Infrastrukturabhängigkeit – Standardmäßige Ingress-Controller sind nicht infrastrukturunabhängig. Daher können Sie weder diese noch Ihre Konfigurationen von einer Cloud in eine andere übertragen. Das bedeutet, dass Sie für jede Bereitstellungsumgebung unterschiedliche Ingress-Controller benötigen. Dies führt zu einer unübersichtlichen Tool-Landschaft, erhöht den Einarbeitungsaufwand für Ihre Teams und erschwert die Absicherung des Ingress-Controllers.
- Grundlegende Funktionen – Ihnen fehlen in der Regel die erweiterten Funktionen für Traffic-Management und Sicherheit, die für groß angelegte Bereitstellungen erforderlich sind.
- Unvorhersehbare Kosten (Zeit und Geld) – Auch wenn die anfänglichen Kosten bei null liegen oder gering sind, können sie mit dem Wachstum Ihrer Anwendung drastisch und unvorhersehbar steigen. Dies kann sich etwa in dem Zeitaufwand äußern, der erforderlich ist, um Funktionen in Ihre App zu integrieren, die im minimalen Funktionsumfang des Ingress-Controllers fehlen – und natürlich müssen Sie diese Funktionen bei jeder Aktualisierung der App erneut auf Regressionen testen. Ein weiterer Nachteil einiger Standardtools sind enorme Sprünge bei Ihrer Cloud-Rechnung, wenn Ihre App beliebter wird. Ursache dafür sind Durchsatzgebühren, die zunächst harmlos erscheinen.
- Zusammenfassung: Ein standardmäßiger Ingress-Controller ist eine beliebte Wahl für Teams, die noch wenig Erfahrung mit Kubernetes haben und eine verwaltete Plattform wie Amazon Elastic Kubernetes Service (EKS), Google Kubernetes Engine (GKE), Microsoft Azure Kubernetes Service (AKS), Rancher oder die Red Hat OpenShift Container Platform nutzen. Wenn ihre Anwendungen ausgereifter und die Teams größer werden, entscheiden sich Unternehmen häufig dafür, ihren Technologie-Stack um einen Ingress-Controller der Enterprise-Klasse zu ergänzen, anstatt das Standardtool zu ersetzen.
Kommerzielle Ingress-Controller
Diese Ingress-Controller sind lizenzierte Produkte, die für große Produktivumgebungen ausgelegt sind. Ein Beispiel ist die auf NGINX Plus basierende Version des F5 NGINX Ingress Controller, auf die wir in Teil 4 näher eingehen werden.

- Vorteile:
- Großer Funktionsumfang – Kommerzielle Ingress-Controller bieten einen robusten Funktionsumfang, der ein erweitertes Traffic-Management und die Skalierbarkeit großer Bereitstellungen unterstützt. Möglicherweise sind Integrationen mit anderen für den Produktionseinsatz geeigneten Produkten wie einer WAF oder einem Service Mesh verfügbar.
- Skalierbar – Unternehmen stellen häufig fest, dass diese Optionen Zeit sparen, da sie in der Regel mehr sofort einsatzbereite Funktionen bieten, die weder Anpassungen noch Behelfslösungen erfordern. Sie lassen sich problemlos in Automatisierungspipelines integrieren, sodass Ihre Infrastruktur nach Bedarf wachsen kann.
- Zuverlässig und mit Support – Einer der Hauptvorteile kommerzieller Produkte ist ihre Stabilität. Das bedeutet, dass sie bei jeder Veröffentlichung umfassend getestet werden und regelmäßig Softwareupdates sowie bei Bedarf Sicherheitspatches erhalten. Umfassender kommerzieller Support ist in der Regel in verschiedenen Stufen verfügbar, sodass Sie bei einem kritischen Problem oft innerhalb von Minuten oder Stunden vertrauliche Hilfe erhalten können.
- Nachteile:
- Langsamere Entwicklung – Da Stabilität für kommerzielle Ingress-Controller wichtig ist, kann die Entwicklung neuer Funktionen etwas langsamer voranschreiten als bei ihren Open-Source-Pendants.
- Kosten (Geld) – Kommerzielle Produkte kosten nun einmal Geld. Für Unternehmen, die mehr Entwicklungskapazitäten als finanzielle Mittel haben, können die Kosten ein Ausschlusskriterium sein, bis sich diese Situation ändert.
- Zusammenfassung: Mit zunehmender Größe von Organisationen gewinnt die Wahl des Ingress-Controllers angesichts der Komplexität ihrer Teams und Anwendungen an Bedeutung. Sobald eine Organisation einen hohen Komplexitätsgrad erreicht, ist ein kommerzieller Ingress-Controller sinnvoll, da er den Verwaltungsaufwand reduzieren und die Markteinführung neuer Produktfunktionen beschleunigen kann.
Nächster Schritt: Optionen bewerten
An diesem Punkt sind Sie bereit, einige Ingress-Controller zum Ausprobieren auszuwählen, indem Sie Optionen ausschließen, die Ihre Anforderungen nicht erfüllen. Ein guter Ausgangspunkt für einen allgemeinen Funktionsvergleich ist learnk8s, wo Sie eine kostenlose Vergleichstabelle der dort bewerteten Ingress-Controller finden.
Bei Ihrer Recherche zu Ingress-Controllern werden Sie wahrscheinlich feststellen, dass viele Optionen auf NGINX basieren. Einen Überblick über die NGINX-basierten Optionen erhalten Sie im letzten Blogbeitrag dieser Reihe: „Leitfaden zur Auswahl eines Ingress-Controllers, Teil 4: Optionen für NGINX Ingress Controller“, der in Kürze erscheint.
Über den Autor

Ähnliche Blogbeiträge
Die Zukunft von NGINX: Zurück zu unseren Open-Source-Wurzeln
Beim NGINX Sprint 2022 besinnen wir uns auf unsere Open-Source-Wurzeln. Erfahren Sie mehr über die Initiativen, die wir im kommenden Jahr verfolgen, und teilen Sie uns mit, was Sie sich wünschen.

Ein Leitfaden zur Auswahl eines Ingress-Controllers, Teil 1: Ermitteln Sie Ihre Anforderungen
Ein Ingress-Controller kann eines der leistungsstärksten Tools in Ihrem Kubernetes-Stack sein. Erfahren Sie, wie Sie Ihre Ingress-Anforderungen ermitteln, um die beste Option auszuwählen.
Bereitstellung des NGINX Ingress Controllers auf Amazon EKS: So haben wir getestet
Wir haben kürzlich den Lösungsleitfaden zum NGINX Ingress Controller um Empfehlungen zur Dimensionierung für Amazon Elastic Kubernetes Service (EKS) ergänzt. In diesem Blogbeitrag erläutern wir, wie wir diese Empfehlungen erarbeitet haben, und stellen Ihnen alle Informationen zur Verfügung, die Sie benötigen, um selbst ähnliche Tests durchzuführen.

Protokollierung des Datenverkehrs zwischen NGINX und Upstream-Servern bei CDN77
Bei der Fehlersuche bei Datenverkehrsproblemen zwischen NGINX und Upstream-Servern konnte CDN77 die benötigten Daten nur aus dem Fehlerprotokoll mit aktivierter Debug-Ausgabe beziehen, was die Leistung beeinträchtigt und riesige Dateien erzeugt. Daher entwickelte das Team ein neues benutzerdefiniertes Modul, das ausschließlich die benötigten Daten protokolliert.
Ankündigung von NGINX Plus R16
NGINX Plus R16 ist eine einheitliche, elastische Ingress- und Egress-Schicht für Anwendungen, die die Funktionen eines Load Balancers, API-Gateways und einer WAF vereint und neue Features wie clusterfähige Ratenbegrenzung, Schlüssel-Wert-Speicher, „Random with Two Choices“, verbessertes UDP-Load-Balancing und vieles mehr bietet.
5 Gründe für den Umstieg auf softwarebasiertes Load Balancing
Entdecken Sie fünf Gründe für den Wechsel zu einem softwarebasierten Load Balancer wie NGINX Plus, darunter Kosteneinsparungen, die Einführung von DevOps und eine einheitliche Lösung für alle Umgebungen.