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

Redakteur – Dieser Beitrag ist Teil einer 10-teiligen Serie:

1. Reduzieren Sie die Komplexität mit produktionsreifem Kubernetes
2. So verbessern Sie die Ausfallsicherheit in Kubernetes mit erweitertem Verkehrsmanagement
3. So verbessern Sie die Sichtbarkeit in Kubernetes
4. Sechs Möglichkeiten zur Sicherung von Kubernetes mit Traffic-Management-Tools
5. Leitfaden zur Auswahl eines Ingress-Controllers, Teil 1: Identifizieren Sie Ihre Anforderungen (dieser Beitrag)
6. Leitfaden zur Auswahl eines Ingress-Controllers, Teil 2: Risiken und Zukunftssicherheit
7. Leitfaden zur Auswahl eines Ingress-Controllers, Teil 3: Open Source vs. Standard vs. Kommerziell
8. Leitfaden zur Auswahl eines Ingress-Controllers, Teil 4: Optionen für den NGINX Ingress Controller
9. So wählen Sie ein Service Mesh aus
10. Leistungstests für NGINX-Ingress-Controller in einer dynamischen Kubernetes-Cloud-Umgebung

Sie können den kompletten Blogsatz auch als kostenloses E-Book herunterladen: Kubernetes vom Test zur Produktion bringen .

Wenn Organisationen zum ersten Mal mit Kubernetes experimentieren, denken sie häufig nicht viel über die Wahl des Ingress-Controllers nach. Sie denken vielleicht, dass alle Ingress-Controller gleich sind und dass es im Interesse einer schnellen Inbetriebnahme am einfachsten ist, beim Standard-Ingress-Controller für das von ihnen ausgewählte Kubernetes-Framework zu bleiben. Und es stimmt, dass praktisch jeder Ingress-Controller in Testumgebungen oder Produktionsumgebungen mit geringem Volumen gut geeignet ist. Aber mit der Skalierung wird Ihre Wahl des Ingress-Controllers wichtiger. Das liegt daran, dass Ingress-Controller viel mehr bieten können als die Grundfunktionalität, Ihren Datenverkehr von Punkt A nach Punkt B zu leiten.

Von erweitertem Verkehrsmanagement über Sichtbarkeit 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 es als Grundlage jeder produktionstauglichen Kubernetes- Bereitstellung. Viele Entwickler und Platform-Ops -Teams sind sich jedoch nicht der gesamten Leistungsfähigkeit eines Ingress-Controllers bewusst – oder der Konsequenzen, wenn sie sich für einen Controller entscheiden, der nicht skalierbar ist. Die Wahl eines Ingress-Controllers, der nicht gut skalierbar ist oder komplexe Umgebungen nicht schützt, kann dazu führen, dass Sie Kubernetes nicht aus der Testphase in die Produktion bringen können. In dieser Blogserie möchten wir Ihnen die Grundlagen von Ingress-Controllern vermitteln und Ihnen zeigen, wie Sie eine kluge Wahl treffen, die Ihnen die Funktionalität und Sicherheit bietet, die Sie heute und morgen brauchen.

Was ist ein Ingress-Controller?

Ein Ingress-Controller ist ein spezialisierter Lastenausgleich, der den in Kubernetes-Cluster eingehenden Layer-4- und Layer-7- Datenverkehr und möglicherweise auch den aus ihnen ausgehenden Datenverkehr verwaltet. Damit wir alle auf dem gleichen Stand sind, sind hier die Begriffe, die wir bei NGINX verwenden (und sie sind in der gesamten Branche weitgehend dieselben):

• Eingehender Datenverkehr – Datenverkehr, der in einen Kubernetes-Cluster eingeht
• Ausgehender Datenverkehr – Datenverkehr, der einen Kubernetes-Cluster verlässt
• Nord-Süd-Verkehr – Eingehender und ausgehender Datenverkehr in einem Kubernetes-Cluster (auch als Ingress-Egress- Verkehr bezeichnet)
• Ost-West-Verkehr – Verkehr, der zwischen Diensten innerhalb eines Kubernetes-Clusters fließt (auch Dienst-zu-Dienst- Verkehr genannt)
• Service Mesh – Ein Verkehrsmanagement-Tool zum Routing und Sichern des Service-zu-Service -Verkehrs

Warum benötigen Sie einen Ingress-Controller?

Standardmäßig sind Anwendungen, die in Kubernetes-Pods (Containern) ausgeführt werden, nicht vom externen Netzwerk aus zugänglich, sondern nur von anderen Pods innerhalb des Kubernetes-Clusters. Kubernetes verfügt über ein integriertes Konfigurationsobjekt für den HTTP-Lastausgleich namens Ingress , das definiert, wie Entitäten außerhalb eines Kubernetes-Clusters eine Verbindung zu den Pods herstellen können, die durch einen oder mehrere Kubernetes-Dienste dargestellt werden.

Wenn Sie externen Zugriff auf Ihre Kubernetes-Dienste ermöglichen möchten, erstellen Sie eine Ingress-Ressource, die die Verbindungsregeln definiert – etwa den URI-Pfad, den Namen des zugrunde liegenden Dienstes und weitere Angaben. Allein bewirkt die Ingress-Ressource jedoch nichts. Wir empfehlen, eine Ingress-Controller-Anwendung über die Kubernetes-API bereitzustellen und zu konfigurieren, um die in der Ingress-Ressource festgelegten Regeln umzusetzen.

Was macht ein Ingress-Controller?

• Akzeptiert Datenverkehr von außerhalb der Kubernetes-Umgebung, ändert (formt) ihn ggf. und verteilt ihn an Pods, die innerhalb der Umgebung ausgeführt werden. Der Ingress-Controller ersetzt das standardmäßige Kube-Proxy- Verkehrsverteilungsmodell und bietet Ihnen zusätzliche Steuerelemente, wie sie Application Delivery Controller (ADCs) und Reverse-Proxys in Nicht-Kubernetes-Umgebungen bieten.
• Überwacht die einzelnen Pods eines Dienstes, gewährleistet intelligentes Routing und verhindert, dass Anfragen in ein „ Black Hole “ geraten.
• Implementiert Ausgangsregeln, um die Sicherheit mit gegenseitigem TLS (mTLS) zu verbessern oder den ausgehenden Datenverkehr von bestimmten Pods auf bestimmte externe Dienste zu beschränken.

Wenn Sie einen Ingress-Controller auswählen, reizt es oft, mit einer Funktionsliste zu starten. Doch dabei bekommen Sie möglicherweise einen Controller mit tollen Features, der Ihre geschäftlichen Anforderungen nicht erfüllt. Konzentrieren Sie sich stattdessen auf zwei zentrale Aspekte, die bestimmen, wie gut der Ingress-Controller für Ihr Team und Ihre Anwendungen funktioniert: Anwendungsfälle (welche Probleme er löst) und Ressourcen (wie Sie den Betrieb sichern). Diese beiden Themen behandeln wir im weiteren Verlauf dieses Blogs.

Welche Probleme soll der Ingress Controller lösen?

Der Hauptanwendungsfall für einen Ingress-Controller ist die Verkehrsverwaltung. Daher möchten Sie wahrscheinlich, dass der Ingress-Controller einen oder mehrere dieser gängigen Anwendungsfälle verarbeitet:

• Lastausgleich (HTTP2, HTTP/HTTPS, SSL/TLS-Terminierung, TCP/UDP, WebSocket, gRPC)
• Verkehrskontrolle (Ratenbegrenzung, Stromkreisunterbrechung, aktive Integritätsprüfungen)
• Verkehrsaufteilung (Debug-Routing, A/B-Tests, Canary-Bereitstellungen, Blue-Green-Bereitstellungen)

Sie müssen sich nicht mit einer „Ein-Trick-Lösung“ begnügen – die meisten Ingress-Controller können weit mehr als nur den Datenverkehr steuern. Indem Sie den Ingress-Controller für mehrere Aufgaben einsetzen, verringern Sie nicht nur die Größe und Komplexität Ihres Stacks, sondern entlasten auch Ihre Apps, indem Sie nicht-funktionale Anforderungen an den Ingress-Controller übertragen. Wir zeigen Ihnen vier unkonventionelle Einsatzmöglichkeiten für Ingress-Controller, die Ihre Kubernetes-Bereitstellungen sicherer, flexibler und skalierbarer machen und gleichzeitig Ihre Ressourcen effizienter nutzen.

Überwachung und Sichtbarkeit

Mangelnde Transparenz im Kubernetes-Cluster zählt zu den größten Herausforderungen in produktiven Umgebungen und erschwert Ihr Troubleshooting sowie die Resilienz. Ingress-Controller arbeiten am Rand Ihrer Kubernetes-Cluster und verarbeiten jeden einzelnen Datenverkehr. Damit liefern sie entscheidende Daten, mit denen Sie zwei häufige Probleme erkennen und beheben können: langsame Apps und Ressourcenengpässe im Kubernetes-Cluster oder in der Plattform. Damit Ingress-Controller die Transparenz erhöhen, müssen sie:

• Bereitstellung von Metriken in Echtzeit, damit Sie diagnostizieren können, was „gerade jetzt“ passiert
• Sie können Metriken in beliebte Sichtbarkeitstools wie Prometheus und Grafana exportieren, die Werte im Zeitverlauf darstellen, um Ihnen bei der Vorhersage von Verkehrsspitzen und anderen Trends zu helfen.

API-Gateway

Sofern Sie keine Anforderungs-Antwort-Manipulation in Kubernetes durchführen möchten, ist es sehr wahrscheinlich, dass der Ingress-Controller auch als Ihr API-Gateway fungieren kann. Je nach Funktionsumfang kann ein Ingress-Controller möglicherweise grundlegende API-Gateway-Funktionen bereitstellen, darunter TLS-Terminierung, Client-Authentifizierung, Ratenbegrenzung, feinkörnige Zugriffskontrolle und Anforderungsrouting auf den Ebenen 4 bis 7.

Authentifizierung und Single Sign-On

Durch das Auslagern der Authentifizierung von Anmeldeinformationen von Ihren Kubernetes-Diensten auf Ihren Ingress-Controller können zwei Probleme gelöst werden.

• Ermöglichen Sie Benutzern die Anmeldung bei mehreren Apps mit einem einzigen Satz Anmeldeinformationen, indem Sie Single Sign-On (SSO) mit OpenID Connect (OIDC) implementieren.
• Sie müssen nicht mehr in jede Anwendung eine Authentifizierungsfunktion integrieren, sodass 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 eine Web Application Firewall (WAF) ersetzt, sondern dass Sie die WAF mit dem Ingress-Controller zusammenfassen können. Zwar lässt sich eine WAF an vielen Stellen außerhalb sowie innerhalb von Kubernetes einsetzen, doch für die meisten Organisationen ist der effizienteste und wirkungsvollste Standort im gleichen Pod wie der Ingress-Controller. Dieser Anwendungsfall ist ideal, wenn SecOps oder DevSecOps die Sicherheitsrichtlinien steuern und Sie eine fein abgestimmte Lösung pro Dienst oder URI benötigen. So lassen sich Richtlinien per Kubernetes-API definieren und gezielt mit Diensten verknüpfen. Zudem ermöglicht die rollenbasierte Zugriffskontrolle (RBAC) des Ingress-Controllers SecOps, Richtlinien pro Listener durchzusetzen, während DevOps Anwender Richtlinien pro Ingress-Ressource setzen.

Wie werden Sie den Ingress-Controller mit Serverressourcen ausstatten?

Jeder Ingress-Controller hat seinen Preis, sogar die kostenlosen Open Source-Produkte (vielleicht haben Sie schon einmal den Ausdruck „kostenlos wie ein Welpe“ gehört). Einigen Kosten können vorhersehbare Dollarbeträge als Einzelposten in Ihrem Budget zugewiesen werden, während andere davon abhängen, wie viel Zeit Ihr Team darauf verwenden muss, sich mit den Konsequenzen des gewählten Ingress-Controllers auseinanderzusetzen (erhöhte Komplexität, mangelnde Portabilität usw.). Sehen wir uns die Kosten – sowohl in Bezug auf Zeit als auch Geld – an, die bei der Budgetierung für einen Ingress-Controller zu berücksichtigen sind: Zeit und Geld.

Budgetierung von Zeitkosten

Die Personalplanung ist oft deutlich komplizierter als die Planung fester Kosten, besonders wenn Sie ein Projekt in einem unbekannten Bereich mit Ressourcen ausstatten. Dabei sollten Sie sich folgende Fragen stellen:

• Wer konfiguriert und verwaltet den Ingress-Controller? Ist es Teil ihrer Vollzeitbeschäftigung (beispielsweise als Mitglieder Ihres Platform Ops-Teams) oder übernehmen sie es als zusätzliche Verantwortung (als Entwickler)?
• Können Sie sich die Zeit nehmen, Ihren Mitarbeitern eine formelle Schulung zu ermöglichen? Oder muss das Tool einfach genug sein, um es im Job schnell und problemlos zu erlernen?
• Sind Sie bereit, dass Mitarbeiter jedes Mal, wenn eine neue Funktion benötigt wird, daran herumbasteln oder bei Problemen viel Zeit mit der Fehlersuche verbringen? Oder benötigen Sie sie, um einen anderen Geschäftswert zu erzielen?

Ein Hinweis zum Besitz von Kubernetes-Tools

Wir beobachten in der Branche einen Trend zur Konsolidierung von Tools und Eigentumsverhältnissen in der Domäne der NetOps-Teams. Dies kann zwar einen großen Beitrag zur Vereinfachung Ihres Stacks und zur Verbesserung der Sicherheit leisten, wir plädieren jedoch für eine durchdachte Duplizierung von Tools auf der Grundlage der Teamziele . Es ist sinnvoll, die Perimeter-Tools (wie externe Lastverteiler) vom NetOps-Team verwalten zu lassen, da dieses sich auf die breitere Plattform konzentriert. DevOps-Teams interessieren sich jedoch vor allem für die Dienste, die in der Nähe des App-Codes bereitgestellt werden, und benötigen daher mehr Flexibilität und eine feinere Kontrolle, als sie von NetOps-Tools erhalten. Kubernetes-Tools, einschließlich des Ingress-Controllers, haben die besten Erfolgschancen, wenn sie von DevOps ausgewählt werden. Das heißt aber nicht, dass Sie Entwicklern völlige Freiheit bei der Auswahl der Tools einräumen müssen! Eine teilweise drastische Standardisierung der Werkzeuge innerhalb von Kubernetes ist nach wie vor eine bewährte Vorgehensweise.

Budgetierung der Kapitalkosten

Wenn Sie erstmals mit Kubernetes arbeiten, planen Sie oft kaum Budget für Tools oder Support ein. Haben Sie das nötige Personal, um einen Ingress-Controller intensiv zu betreuen, ist ein finanzielles Budget vorerst nicht erforderlich. Steigt Ihre Investition in Kubernetes, stoßen Sie möglicherweise an die Grenzen der Tool-Funktionen oder möchten Ihr Team auf andere Aufgaben fokussieren. Dann lohnt es sich, auf ein einfacher zu bedienendes, stabileres Tool mit Enterprise-Features und Support umzusteigen.

Wenn Sie bereit sind, für einen Ingress-Controller zu bezahlen, beachten Sie, dass das Lizenzmodell wichtig ist. Basierend auf traditionellen Preismodellen außerhalb von Kubernetes erfolgt die Preisgestaltung für Ingress-Controller häufig „pro Instanz“ oder „pro Ingress-Proxy“. Obwohl es Anwendungsfälle gibt, in denen dies in Kubernetes immer noch sinnvoll ist, bedeutet die Lizenzierung eines Ingress-Controllers auf „Pro-Cluster“-Basis, dass Sie auf Basis der Anwendungsdauer und nicht der „Anzahl der Proxys“ bezahlen.

Hier sind unsere Empfehlungen für verschiedene Szenarien:

• Neu bei Kubernetes? Wählen Sie die Lizenzierung pro Cluster.
  Wenn Sie keine Erfahrung mit Kubernetes haben, ist es sehr schwierig, die Anzahl der benötigten Ingress-Controller-Instanzen genau vorherzusagen. Wenn Sie gezwungen sind, eine bestimmte Anzahl von Instanzen auszuwählen, kann es sein, dass Sie den Aufwand zu niedrig ansetzen – was das Erreichen Ihrer Ziele erschwert – oder Sie überschätzen und Geld verschwenden, das Sie besser in andere Teile des Kubernetes-Projekts investieren würden. Die Aushandlung eines relativ niedrigen Festpreises für einen „kleinen Cluster“ erhöht Ihre Erfolgschancen.
• Skalieren Sie Kubernetes? Entscheiden Sie sich für eine pro Cluster basierte Lizenzierung.
  Es ist nahezu unmöglich vorherzusagen, wie viel und wie oft Sie Kubernetes-Ressourcen skalieren müssen – sei es kurzfristiges Hoch- oder Herunterskalieren. Die Preisgestaltung pro Instanz zwingt Ihr Team dazu, willkürliche Grenzen festzulegen, um innerhalb der Lizenzlimits zu bleiben. Mit der Cluster-Lizenzierung müssen Sie keine einzelnen Ingress-Container verfolgen. Je nach Anbieter, etwa NGINX, ist Bursting oft ohne zusätzliche Kosten enthalten.
• Erweiterte oder statische Bereitstellungen? Wählen Sie die Lizenzierung pro Instanz.
  Wenn Sie sich mit Kubernetes gut genug auskennen und genau wissen, wie Sie den Ingress-Controller verwenden werden, und Sie vorhaben, pro Cluster eine kleine Anzahl von Ingress-Proxys zu verwenden, und Sie keine gebündelten Dienste benötigen, die möglicherweise mit dem Tool mitgeliefert werden, kann die Preisgestaltung pro Instanz eine gute Wahl sein.

Nächste Schritte: Risikotoleranz und Zukunftssicherheit

Nachdem Sie nun Ihre Anforderungen kennen, besteht der nächste Schritt darin, als Team zu entscheiden, wie hoch Ihre Toleranz gegenüber den Risiken ist, die ein Ingress-Controller mit sich bringen kann, und herauszufinden, wie der Ingress-Controller skaliert werden muss, wenn Sie Ihre Kubernetes-Bereitstellung erweitern. Diese Themen greifen wir in Teil 2 auf.