Redakteur – Dieser Beitrag ist Teil einer 10-teiligen Serie:
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.
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):
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.
Kube-Proxy-
Verkehrsverteilungsmodell und bietet Ihnen zusätzliche Steuerelemente, wie sie Application Delivery Controller (ADCs) und Reverse-Proxys in Nicht-Kubernetes-Umgebungen bieten.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.
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:
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.
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:
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.
Durch das Auslagern der Authentifizierung von Anmeldeinformationen von Ihren Kubernetes-Diensten auf Ihren Ingress-Controller können zwei Probleme gelöst werden.
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.
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.
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:
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.
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:
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.
„Dieser Blogbeitrag kann auf Produkte verweisen, die nicht mehr verfügbar und/oder nicht mehr unterstützt werden. Die aktuellsten Informationen zu verfügbaren F5 NGINX-Produkten und -Lösungen finden Sie in unserer NGINX-Produktfamilie . NGINX ist jetzt Teil von F5. Alle vorherigen NGINX.com-Links werden auf ähnliche NGINX-Inhalte auf F5.com umgeleitet."