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 gewähren müssen, erstellen Sie eine Ingress-Ressource , um die Konnektivitätsregeln zu definieren, einschließlich des URI-Pfads, des Namens des zugrunde liegenden Dienstes und anderer Informationen. Für sich genommen bewirkt die Ingress-Ressource allerdings nichts. Sie müssen eine Ingress-Controller-Anwendung bereitstellen und konfigurieren (mithilfe der Kubernetes-API), um die in den Ingress-Ressourcen definierten Regeln zu implementieren.

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.

Bei der Auswahl eines Ingress-Controllers ist es möglicherweise verlockend, mit einer Funktionsliste zu beginnen. Sie könnten jedoch am Ende einen Ingress-Controller mit fantastischen Funktionen erhalten, der Ihren Geschäftsanforderungen jedoch nicht gerecht wird. Stellen Sie stattdessen sicher, dass Sie zwei Elemente untersuchen, die Einfluss darauf haben, wie gut der Ingress-Controller für Ihr Team und Ihre Apps funktioniert: Anwendungsfälle (welche Probleme er löst) und Ressourcen (wie Sie dafür „bezahlen“). Wir werden diese beiden Themen im weiteren Verlauf dieses Blogs behandeln.

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)

Es gibt jedoch keinen Grund, sich mit einem „One-Trick-Pony“ zufrieden zu geben – die meisten Ingress-Controller können mehr als nur den Datenverkehr verwalten. Indem Sie den Ingress-Controller zum Lösen mehrerer Probleme verwenden, reduzieren Sie nicht nur die Größe und Komplexität Ihres Stacks, sondern können auch nicht-funktionale Anforderungen von den Apps auf den Ingress-Controller auslagern. Sehen wir uns vier nicht traditionelle Anwendungsfälle für Ingress-Controller an, die dazu beitragen können, Ihre Kubernetes-Bereitstellungen sicherer, agiler und skalierbarer zu machen und gleichzeitig Ihre Ressourcen effizienter zu nutzen.

Überwachung und Sichtbarkeit

Eine der größten Herausforderungen in Produktionsumgebungen ist die mangelnde Transparenz des Kubernetes-Clusters, die zu Schwierigkeiten bei der Fehlerbehebung und Ausfallsicherheit beiträgt. Da Ingress-Controller am Rand Ihres Kubernetes-Clusters arbeiten und mit jedem Datenverkehr in Berührung kommen, sind sie bestens dafür geeignet, Daten bereitzustellen, die Ihnen bei der Behebung (und sogar Vermeidung) zweier häufiger Probleme helfen können: langsame Apps und Ressourcenerschöpfung im Kubernetes-Cluster oder auf der Kubernetes-Plattform. Damit der Ingress-Controller die Sichtbarkeit verbessern kann, muss er:

• 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 als Web Application Firewall (WAF) dienen kann, sondern vielmehr darum, dass die WAF mit dem Ingress-Controller konsolidiert werden kann. Obwohl eine WAF an vielen Stellen außerhalb und innerhalb von Kubernetes bereitgestellt werden kann, befindet sich der effizienteste und effektivste Standort für die meisten Organisationen im selben Pod wie der Ingress-Controller. Dieser Anwendungsfall ist perfekt, wenn Sicherheitsrichtlinien unter der Leitung von SecOps oder DevSecOps stehen und ein feinkörniger Ansatz pro Dienst oder pro URI erforderlich ist. Das bedeutet, dass Sie die Kubernetes-API verwenden können, um Richtlinien zu definieren und sie Diensten zuzuordnen. Darüber hinaus kann die rollenbasierte Zugriffskontrollfunktion (RBAC) des Ingress-Controllers es SecOps ermöglichen, Richtlinien pro Listener durchzusetzen, während DevOps-Benutzer Richtlinien pro Ingress-Ressource festlegen.

Wie werden Sie den Ingress-Controller mit Ressourcen versorgen?

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 Budgetierung von Mitarbeitern kann weitaus anspruchsvoller sein als die von Fixkostenpositionen, insbesondere wenn Sie versuchen, die Ressourcen für ein Projekt in einem unbekannten Bereich bereitzustellen. Sie müssen Fragen stellen wie:

• 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 Unternehmen zum ersten Mal mit Kubernetes experimentieren, steht ihnen häufig kein großes Budget für Tools oder Support zur Verfügung. Wenn Sie über die personellen Ressourcen verfügen, um einen Ingress-Controller, der mehr Unterstützung benötigt, wirklich zu unterstützen, dann ist kein Geldbudget in Ordnung … zunächst einmal. Doch mit zunehmender Investition in Kubernetes werden Sie möglicherweise feststellen, dass Ihnen die Funktionen des Tools Grenzen setzen oder Sie Ihr Team anderen Prioritäten widmen möchten. Dann neigt man eher dazu, für ein benutzerfreundlicheres und stabileres Tool mit Enterprise-Funktionen und -Support zu bezahlen.

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.
• Kubernetes skalieren? Wählen Sie die Lizenzierung pro Cluster.
  Es ist nahezu unmöglich vorherzusagen, wie stark und wie oft Sie die Kubernetes-Ressourcen hoch- und herunterskalieren müssen (Bursting und Collapse). Durch die Preisgestaltung pro Instanz ist Ihr Team gezwungen, willkürliche Schwellenwerte festzulegen, um die Lizenzobergrenzen einzuhalten. Bei der Lizenzierung pro Cluster müssen Sie keine einzelnen Ingress-Container verfolgen und je nach Anbieter (z. B. NGINX) ist Bursting möglicherweise 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.