Ein Leitfaden zur Auswahl eines Ingress-Controllers, Teil 1: Ermitteln Sie Ihre Anforderungen

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. Ein Leitfaden zur Auswahl eines Ingress-Controllers, Teil 1: Ermitteln Sie Ihre Anforderungen (dieser Beitrag)
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
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 bis zum Produktivbetrieb.

Wenn Unternehmen erste Erfahrungen mit Kubernetes sammeln, machen sie sich häufig nicht viele Gedanken über die Wahl eines Ingress-Controllers. Sie gehen möglicherweise davon aus, dass alle Ingress-Controller gleich sind und es für einen schnellen Einstieg am einfachsten ist, beim standardmäßigen Ingress-Controller des gewählten Kubernetes-Frameworks zu bleiben. Tatsächlich eignet sich nahezu jeder Ingress-Controller für Test- oder Produktionsumgebungen mit geringem Datenverkehr. Mit zunehmender Skalierung gewinnt die Wahl des Ingress-Controllers jedoch an Bedeutung. Denn Ingress-Controller können weit mehr leisten als nur die grundlegende Aufgabe, den Datenverkehr von Punkt A nach Punkt B weiterzuleiten.

Von erweitertem Traffic-Management über Transparenz bis hin zu integrierter Sicherheit kann ein Ingress-Controller eines der leistungsstärksten Tools in Ihrem Kubernetes-Stack sein. Tatsächlich betrachten wir bei F5 NGINX ihn als Grundlage jeder Kubernetes-Produktivumgebung. Viele Entwickler und Platform-Ops-Teams sind sich jedoch weder des vollen Potenzials eines Ingress-Controllers bewusst noch der Folgen, die die Wahl eines nicht skalierbaren Controllers mit sich bringt. Wenn Sie sich für einen Ingress-Controller entscheiden, der sich nicht gut skalieren lässt oder komplexe Umgebungen nicht schützt, kann dies verhindern, dass Sie Kubernetes aus der Testphase in den Produktivbetrieb überführen. In dieser Blogreihe möchten wir Ihnen die Grundlagen von Ingress-Controllern vermitteln und zeigen, wie Sie eine kluge Wahl treffen, die Ihnen heute und in Zukunft die benötigte Funktionalität und Sicherheit bietet.

Was ist ein Ingress-Controller?

Ein Ingress-Controller ist ein spezialisierter Load Balancer, der den in Kubernetes-Cluster eingehenden Datenverkehr auf Layer 4 und 7 und gegebenenfalls auch den aus ihnen ausgehenden Datenverkehr verwaltet. Damit wir alle vom Gleichen sprechen, finden Sie hier die Begriffe, die wir bei NGINX verwenden (und die branchenweit weitgehend identisch sind):

• Ingress-Datenverkehr – Datenverkehr, der in einen Kubernetes-Cluster gelangt
• Ausgehender Datenverkehr – Datenverkehr, der einen Kubernetes-Cluster verlässt
• Nord-Süd-Datenverkehr – Datenverkehr, der in einen Kubernetes-Cluster eintritt und ihn verlässt (auch als „Ingress-Egress-Datenverkehr“ bezeichnet)
• Ost-West-Datenverkehr – Datenverkehr zwischen Diensten innerhalb eines Kubernetes-Clusters (auch als Service-to-Service-Datenverkehr bezeichnet)
• Service Mesh – Ein Tool zur Verwaltung des Datenverkehrs, das den Datenverkehr zwischen Diensten weiterleitet und absichert

Warum benötigen Sie einen Ingress-Controller?

Standardmäßig sind Anwendungen, die in Kubernetes-Pods (Containern) ausgeführt werden, nicht über das externe Netzwerk erreichbar, sondern nur von anderen Pods innerhalb des Kubernetes-Clusters. Kubernetes verfügt über ein integriertes Konfigurationsobjekt für den HTTP-Lastenausgleich namens „Ingress“. Dieses legt fest, wie Entitäten außerhalb eines Kubernetes-Clusters eine Verbindung zu den Pods herstellen können, die durch einen oder mehrere Kubernetes-Services repräsentiert werden.

Wenn Sie externen Zugriff auf Ihre Kubernetes-Dienste ermöglichen müssen, erstellen Sie eine Ingress-Ressource, um die Verbindungsregeln festzulegen, einschließlich des URI-Pfads, des Namens des zugrunde liegenden Dienstes und weiterer Informationen. Für sich allein bewirkt die Ingress-Ressource jedoch nichts. Sie müssen eine Ingress-Controller-Anwendung bereitstellen und konfigurieren (mithilfe der Kubernetes-API), um die in den Ingress-Ressourcen definierten Regeln umzusetzen.

Was macht ein Ingress-Controller?

• Akzeptiert Datenverkehr von außerhalb der Kubernetes-Umgebung, kann ihn gegebenenfalls modifizieren (formen) und verteilt ihn an Pods, die innerhalb der Umgebung ausgeführt werden. Der Ingress-Controller ersetzt das standardmäßige Datenverkehrsverteilungsmodell von „kube-proxy“, wodurch Sie zusätzliche Steuerungsmöglichkeiten erhalten, wie sie Anwendungsbereitstellungscontroller (ADCs) und Reverse-Proxys in Nicht-Kubernetes-Umgebungen bieten.
• Überwacht die einzelnen Pods eines Dienstes, gewährleistet intelligentes Routing und verhindert, dass Anfragen „ins Leere laufen“.
• Implementiert Egress-Regeln, um die Sicherheit durch gegenseitiges TLS (mTLS) zu erhöhen oder den ausgehenden Datenverkehr bestimmter Pods auf bestimmte externe Dienste zu beschränken.

Wenn es an der Zeit ist, einen Ingress-Controller auszuwählen, liegt es nahe, zunächst die verfügbaren Funktionen zu vergleichen. Dabei könnten Sie jedoch bei einem Ingress-Controller landen, der zwar fantastische Funktionen bietet, aber Ihre geschäftlichen Anforderungen nicht erfüllt. Prüfen Sie stattdessen zwei Aspekte, die maßgeblich beeinflussen, wie gut der Ingress-Controller für Ihr Team und Ihre Anwendungen geeignet ist: Anwendungsfälle (welche Probleme er löst) und Ressourcenbedarf (wie Sie dafür „bezahlen“). Mit diesen beiden Themen befassen wir uns im weiteren Verlauf dieses Blogbeitrags.

Welche Probleme soll der Ingress-Controller lösen?

Der zentrale Anwendungsfall für einen Ingress-Controller ist die Verwaltung des Datenverkehrs. Daher soll der Ingress-Controller wahrscheinlich einen oder mehrere der folgenden gängigen Anwendungsfälle abdecken:

• Lastverteilung (HTTP2, HTTP/HTTPS, SSL/TLS-Terminierung, TCP/UDP, WebSocket, gRPC)
• Datenverkehrssteuerung (Ratenbegrenzung, Circuit Breaking, aktive Zustandsprüfungen)
• Traffic-Aufteilung (Debug-Routing, A/B-Tests, Canary-Deployments, Blue-Green-Deployments)

Es gibt jedoch keinen Grund, sich mit einem „One-Trick-Pony“ zufriedenzugeben – die meisten Ingress-Controller können mehr als nur den Datenverkehr verwalten. Wenn Sie den Ingress-Controller zur Lösung mehrerer Probleme einsetzen, reduzieren Sie nicht nur den Umfang und die Komplexität Ihres Stacks, sondern können auch nichtfunktionale Anforderungen von den Anwendungen auf den Ingress-Controller auslagern. Sehen wir uns vier unkonventionelle Anwendungsfälle für Ingress-Controller an, mit denen Sie Ihre Kubernetes-Bereitstellungen sicherer, agiler und skalierbarer gestalten und gleichzeitig Ihre Ressourcen effizienter nutzen können.

Überwachung und Transparenz

Mangelnde Transparenz im Kubernetes-Cluster ist eine der größten Herausforderungen in Produktionsumgebungen und erschwert sowohl die Fehlerbehebung als auch die Ausfallsicherheit. Da Ingress-Controller am Rand Ihrer Kubernetes-Cluster arbeiten und mit dem gesamten Datenverkehr in Berührung kommen, sind sie bestens dafür geeignet, Daten bereitzustellen, mit denen Sie zwei häufige Probleme beheben (oder sogar vermeiden) können: langsame Anwendungen und Ressourcenengpässe im Kubernetes-Cluster oder auf der Plattform. Um die Transparenz zu verbessern, muss ein Ingress-Controller Folgendes leisten:

• Metriken in Echtzeit bereitstellen, damit Sie diagnostizieren können, was „gerade jetzt“ passiert
• Metriken in gängige Monitoring-Tools wie Prometheus und Grafana exportieren können, die Werte im Zeitverlauf darstellen, um Verkehrsspitzen und andere Trends vorherzusagen

API-Gateway

Sofern Sie in Kubernetes keine Manipulation von Anfragen und Antworten durchführen möchten, kann der Ingress-Controller sehr wahrscheinlich zugleich als Ihr API-Gateway fungieren. Je nach Funktionsumfang kann ein Ingress-Controller zentrale API-Gateway-Funktionen bereitstellen, darunter TLS-Terminierung, Client-Authentifizierung, Ratenbegrenzung, fein abgestufte Zugriffskontrolle und die Weiterleitung von Anfragen auf den Schichten 4 bis 7.

Authentifizierung und Single Sign-on

Die Auslagerung der Authentifizierung von Anmeldedaten aus Ihren Kubernetes-Diensten auf Ihren Ingress-Controller kann zwei Probleme lösen.

• Ermöglichen Sie Benutzern durch die Implementierung von Single Sign-on (SSO) mit OpenID Connect (OIDC), sich mit einem einzigen Satz von Anmeldedaten bei mehreren Anwendungen anzumelden.
• Machen Sie die Entwicklung von Authentifizierungsfunktionen für jede einzelne Anwendung überflüssig, damit sich Ihre Entwickler auf die Geschäftslogik ihrer Apps konzentrieren können.

Integration einer Web Application Firewall

Es geht nicht darum, dass ein Ingress-Controller als Web Application Firewall (WAF) fungieren kann, sondern vielmehr darum, die WAF mit dem Ingress-Controller zu konsolidieren. Eine WAF kann zwar an vielen Stellen außerhalb und innerhalb von Kubernetes bereitgestellt werden, doch für die meisten Unternehmen ist der effizienteste und effektivste Ort derselbe Pod wie der Ingress-Controller. Dieser Anwendungsfall eignet sich ideal, wenn Sicherheitsrichtlinien von SecOps oder DevSecOps verwaltet werden und ein granularer Ansatz pro Service oder URI erforderlich ist. So können Sie über die Kubernetes-API Richtlinien definieren und sie Services zuordnen. Darüber hinaus ermöglicht die rollenbasierte Zugriffskontrolle (RBAC) des Ingress-Controllers SecOps, Richtlinien pro Listener durchzusetzen, während DevOps-Benutzer Richtlinien pro Ingress-Ressource festlegen.

Wie werden Sie den Ingress-Controller mit Ressourcen ausstatten?

Jeder Ingress-Controller verursacht Kosten – selbst diejenigen, die kostenlos und quelloffen sind (vielleicht kennen Sie den Ausdruck „kostenlos wie ein geschenkter Welpe“). Einige Kosten lassen sich als vorhersehbare Beträge in Ihrem Budget einplanen, während andere davon abhängen, wie viel Zeit Ihr Team für die Folgen der Wahl eines bestimmten Ingress-Controllers aufwenden muss (höhere Komplexität, mangelnde Portabilität und so weiter). Sehen wir uns an, welche zeitlichen und finanziellen Kosten Sie bei der Budgetplanung für einen Ingress-Controller berücksichtigen sollten.

Zeitaufwand einplanen

Die Budgetplanung für den Personalbedarf kann weitaus schwieriger sein als für Positionen mit festen Kosten – insbesondere, wenn Sie versuchen, ein Projekt in einem Ihnen unbekannten Bereich personell auszustatten. Dabei müssen Sie sich Fragen stellen wie:

• Wer wird den Ingress-Controller konfigurieren und verwalten? Gehört dies zu den regulären Aufgaben dieser Personen (beispielsweise als Mitglieder Ihres Platform-Ops-Teams), oder übernehmen sie diese Aufgabe zusätzlich (als Entwickler)?
• Können Sie Ihren Mitarbeitern Zeit für formelle Schulungen einräumen? Oder muss das Tool so einfach sein, dass es sich schnell und unkompliziert bei der Arbeit erlernen lässt?
• Sind Sie bereit, Ihre Mitarbeiter jedes Mal daran herumbasteln zu lassen, wenn eine neue Funktion benötigt wird, oder viel Zeit in die Fehlerbehebung zu investieren, wenn ein Problem auftritt? Oder sollen sie anderweitig zum Geschäftserfolg beitragen?

Ein Hinweis zur Zuständigkeit für Kubernetes-Tools

Wir beobachten in der Branche einen Trend, Tools und die Zuständigkeit dafür im Verantwortungsbereich von NetOps-Teams zu bündeln. Dies kann zwar erheblich dazu beitragen, Ihren Stack zu vereinfachen und die Sicherheit zu verbessern, wir plädieren jedoch für eine wohlüberlegte Duplizierung von Tools entsprechend den Zielen der Teams. Es ist sinnvoll, dass das NetOps-Team Perimeter-Tools (wie externe Load Balancer) verwaltet, da es die übergeordnete Plattform im Blick hat. DevOps-Teams hingegen interessieren sich vor allem für die Dienste, die in unmittelbarer Nähe zum Anwendungscode bereitgestellt werden, und benötigen mehr Agilität und eine feiner abgestufte Kontrolle, als NetOps-Tools ihnen bieten. Kubernetes-Tools, einschließlich des Ingress-Controllers, haben die besten Erfolgsaussichten, wenn sie von DevOps ausgewählt werden. Das bedeutet nicht, dass Sie Entwicklern bei der Auswahl von Tools völlig freie Hand lassen müssen! Eine gewisse rigorose Standardisierung der Tools innerhalb von Kubernetes gilt nach wie vor als Best Practice.

Budgetierung von Investitionskosten

Wenn Unternehmen erste Erfahrungen mit Kubernetes sammeln, planen sie häufig nur ein geringes Budget für Tools oder Support ein. Wenn Sie über genügend Personal verfügen, um einen Ingress-Controller zu betreuen, der mehr Unterstützung erfordert, ist es zunächst in Ordnung, dafür kein Geld einzuplanen. Doch mit zunehmenden Investitionen in Kubernetes stellen Sie möglicherweise fest, dass die Funktionen des Tools nicht mehr ausreichen oder dass Sie Ihr Team für andere Prioritäten einsetzen möchten. Dann lohnt es sich, für ein benutzerfreundlicheres, stabileres Tool mit Enterprise-Funktionen und Support zu bezahlen.

Wenn Sie bereit sind, für einen Ingress-Controller zu bezahlen, sollten Sie bedenken, dass das Lizenzmodell eine wichtige Rolle spielt. In Anlehnung an traditionelle Preismodelle außerhalb von Kubernetes werden Ingress-Controller häufig „pro Instanz“ oder „pro Ingress-Proxy“ abgerechnet. Auch wenn dies in bestimmten Kubernetes-Anwendungsfällen weiterhin sinnvoll ist, zahlen Sie bei einer Lizenzierung des Ingress-Controllers „pro Cluster“ stattdessen auf Grundlage der Anwendungsmandanten und nicht nach der „Anzahl der Proxys“.

Hier sind unsere Empfehlungen für verschiedene Szenarien:

• Neu bei Kubernetes? Entscheiden Sie sich für eine Lizenzierung pro Cluster.
  Wenn Sie noch wenig Erfahrung mit Kubernetes haben, ist es sehr schwierig, die benötigte Anzahl an Ingress-Controller-Instanzen genau vorherzusagen. Müssen Sie sich auf eine bestimmte Anzahl von Instanzen festlegen, setzen Sie diese möglicherweise zu niedrig an – was das Erreichen Ihrer Ziele erschwert – oder zu hoch und verschwenden dadurch Geld, das besser in andere Bereiche des Kubernetes-Projekts investiert wäre. Ein relativ niedriger Festpreis für einen „kleinen Cluster“ erhöht Ihre Erfolgschancen.
• Kubernetes skalieren? Entscheiden Sie sich für eine Lizenzierung pro Cluster.
  Es ist nahezu unmöglich vorherzusagen, in welchem Umfang und wie häufig Sie Kubernetes-Ressourcen hoch- und herunterskalieren müssen (Bursting und Collapsing). Bei einer Preisgestaltung pro Instanz ist Ihr Team gezwungen, willkürliche Schwellenwerte festzulegen, um die Lizenzobergrenzen einzuhalten. Bei einer Lizenzierung pro Cluster müssen Sie einzelne Ingress-Container nicht nachverfolgen, und je nach Anbieter (z. B. NGINX) kann Bursting ohne zusätzliche Kosten inbegriffen sein.
• Fortgeschrittene oder statische Bereitstellungen? Entscheiden Sie sich für eine Lizenzierung pro Instanz.
  Wenn Sie sich mit Kubernetes gut genug auskennen, um genau zu wissen, wie Sie den Ingress-Controller einsetzen werden, nur eine geringe Anzahl von Ingress-Proxys pro Cluster verwenden möchten und keine gebündelten Dienste benötigen, die möglicherweise im Lieferumfang des Tools enthalten sind, kann eine Preisgestaltung pro Instanz eine ausgezeichnete Wahl sein.

Nächste Schritte: Risikobereitschaft und Zukunftssicherheit

Nachdem Sie nun Ihre Anforderungen kennen, sollten Sie im nächsten Schritt gemeinsam im Team entscheiden, in welchem Maß Sie bereit sind, die Risiken zu akzeptieren, die ein Ingress-Controller mit sich bringen könnte. Außerdem gilt es herauszufinden, wie der Ingress-Controller mit der zunehmenden Größe Ihrer Kubernetes-Bereitstellung skalieren muss. Mit diesen Themen befassen wir uns in Teil 2.

Über den Autor

Jenn GileLeiter Produktmarketing, NGINX

Weitere Blogbeiträge von Jenn Gile