Leitfaden zur Auswahl eines Ingress-Controllers, Teil 2: Risiken und Zukunftssicherheit

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
6. Leitfaden zur Auswahl eines Ingress-Controllers, Teil 2: Risiken und Zukunftssicherheit (dieser Beitrag)
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 .

In Teil 1 unseres Leitfadens zur Auswahl eines Ingress-Controllers haben wir erklärt, wie Sie Ihre Anforderungen ermitteln. Aber es ist noch nicht an der Zeit, Produkte zu testen! In diesem Beitrag erklären wir, wie der falsche Ingress-Controller Ihre Release-Geschwindigkeit verlangsamen und Sie sogar Kunden kosten kann. Wie bei jedem Tool können Ingress-Controller Risiken mit sich bringen und die zukünftige Skalierbarkeit beeinträchtigen. Sehen wir uns an, wie wir Entscheidungen ausschließen können, die möglicherweise mehr Schaden als Nutzen bringen.

Ingress Controller-Risiken

Bei der Einführung eines Verkehrsmanagement-Tools für Kubernetes sollten Sie drei besondere Risiken berücksichtigen: Komplexität, Latenz und Sicherheit. Diese Probleme hängen oft zusammen. Wenn eines davon auftritt, ist die Wahrscheinlichkeit groß, dass auch die anderen auftreten. Jedes kann durch einen Ingress-Controller eingeführt werden und es liegt an Ihrer Organisation, zu entscheiden, ob das Risiko tolerierbar ist. Die Verbraucher von heute sind wankelmütig und alles, was zu einer schlechten digitalen Erfahrung beiträgt, kann trotz eines überzeugenden Funktionsumfangs inakzeptabel sein.

Komplexität – Ist sie dem Zweck einer Microservices-Architektur zuwider?

Die besten Kubernetes-Tools sind diejenigen, die die Ziele der Microservices-Architektur erfüllen: leichtgewichtig und einfach im Design. Es ist möglich, einen Ingress-Controller mit sehr vielen Funktionen zu entwickeln, der diesen Prinzipien treu bleibt, aber das ist nicht immer die Norm. Einige Designer integrieren zu viele Funktionen oder verwenden komplizierte Skripts, um Fähigkeiten hinzuzufügen, die nicht nativ in der zugrunde liegenden Engine vorhanden sind. Das Ergebnis ist ein Ingress-Controller, der unnötig komplex ist.

Und warum ist das wichtig? In Kubernetes kann ein zu komplexes Tool die App-Leistung negativ beeinflussen und Ihre Möglichkeiten zur horizontalen Skalierung Ihrer Bereitstellung einschränken. Normalerweise erkennen Sie einen übermäßig komplexen Ingress-Controller an seiner Größe: Je größer der Platzbedarf, desto komplexer das Tool.

Latenz – Verlangsamt der Ingress Controller Ihre Apps?

Ingress-Controller können aufgrund von Ressourcennutzung, Fehlern und Timeouts zu Latenzen führen. Sehen Sie sich die bei statischen und dynamischen Bereitstellungen hinzugefügte Latenz an und eliminieren Sie Optionen, die basierend auf Ihren internen Anforderungen zu einer inakzeptablen Latenz führen. Weitere Einzelheiten dazu, wie sich Neukonfigurationen auf die App-Geschwindigkeit auswirken können, finden Sie unter Leistungstests von NGINX-Ingress-Controllern in einer dynamischen Kubernetes-Cloud-Umgebung in unserem Blog.

Sicherheit – Öffnet der Ingress Controller Hackern Tür und Tor?

Im heutigen Internet sind häufig Common Vulnerabilities and Exposures (CVEs) präsent und die Zeit, die Ihr Ingress-Controller-Anbieter benötigt, um einen CVE-Patch bereitzustellen, kann den Unterschied zwischen Sicherheit und einem Verstoß ausmachen. Abhängig von der Risikobereitschaft Ihres Unternehmens möchten Sie möglicherweise Lösungen ausschließen, deren Bereitstellung von Patches mehr als ein paar Tage (oder höchstens Wochen) dauert.

Über CVEs hinaus setzen Sie einige Ingress-Controller einer weiteren potenziellen Sicherheitslücke aus. Stellen Sie sich folgendes Szenario vor: Sie arbeiten für einen Online-Händler und benötigen Hilfe bei der Fehlerbehebung bei der Konfiguration Ihres Open-Source-Ingress-Controllers. Da kein kommerzieller Support verfügbar ist, posten Sie das Problem in einem Forum wie Stack Overflow. Jemand bietet seine Hilfe an und möchte in den Konfigurations- und Protokolldateien des Ingress-Controllers und anderer Kubernetes-Komponenten nach Problemen suchen. Sie stehen unter Druck, das Problem schnell zu lösen und geben die Dateien frei.

Der „barmherzige Samariter“ hilft Ihnen, Ihr Problem zu lösen, doch sechs Monate später entdecken Sie einen Verstoß: Kreditkartennummern wurden aus Ihren Kundendaten gestohlen. Hoppla. Es stellte sich heraus, dass die von Ihnen freigegebenen Dateien Informationen enthielten, die zum Infiltrieren Ihrer App verwendet wurden. Dieses Szenario veranschaulicht einen der Hauptgründe, warum Unternehmen sich dafür entscheiden, für Support zu bezahlen: Er garantiert Vertraulichkeit.

Ein Hinweis zu OpenResty-basierten Ingress-Controllern

OpenResty ist eine auf NGINX Open Source basierende Webplattform, die LuaJIT, Lua-Skripte und NGINX-Module von Drittanbietern enthält, um die Funktionalität in NGINX Open Source zu erweitern. Andererseits gibt es mehrere auf OpenResty basierende Ingress-Controller, die unserer Ansicht nach im Vergleich zu unseren auf NGINX Open Source und NGINX Plus basierenden Ingress-Controllern möglicherweise zwei Risiken mit sich bringen:

• Timeouts – Wie bereits erwähnt, verwendet OpenResty Lua-Skripting, um erweiterte Funktionen wie die in unserem kommerziellen NGINX Plus-basierten Ingress Controller zu implementieren. Eine solche Funktion ist die dynamische Neukonfiguration, die eine NGINX Open Source-Anforderung eliminiert, die die Verfügbarkeit verringert – nämlich, dass die NGINX-Konfiguration neu geladen werden muss, wenn sich die Service-Endpunkte ändern. Um eine dynamische Neukonfiguration mit OpenResty durchzuführen, wählt der Lua-Handler aus, an welchen Upstream-Dienst die Anfrage weitergeleitet werden soll, wodurch das Neuladen der NGINX-Konfiguration entfällt.

  Lua muss jedoch kontinuierlich nach Änderungen an den Backends suchen, was Ressourcen verbraucht. Die Bearbeitung eingehender Anfragen dauert länger, was dazu führt, dass einige Anfragen ins Stocken geraten, was wiederum die Wahrscheinlichkeit von Zeitüberschreitungen erhöht. Wenn Sie auf mehr Benutzer und Dienste skalieren, vergrößert sich die Lücke zwischen der Anzahl eingehender Anfragen pro Sekunde und der Anzahl, die Lua verarbeiten kann, exponentiell. Die Folgen sind Latenz, Komplexität und höhere Kosten.

  Lesen Sie Leistungstests von NGINX-Ingress-Controllern in einer dynamischen Kubernetes-Cloud-Umgebung, um zu sehen, wie viel Latenz Lua hinzufügen kann.

• Verzögerungen beim Patchen von CVE – Im Vergleich zu den Ingress-Controllern von NGINX dauert es zwangsläufig länger, bis Patches für CVEs in Ingress-Controllern verfügbar sind, die auf Tools wie OpenResty basieren, die wiederum auf NGINX Open Source basieren. Wie wir in „Sicherheitslücken schnell und einfach mit NGINX Plus beheben“ ausführlich erläutern, werden wir als Anbieter im Allgemeinen informiert, wenn eine CVE in NGINX entdeckt wird, bevor die CVE öffentlich bekannt gegeben wird. Dadurch können wir einen Patch für NGINX Open Source und NGINX Plus veröffentlichen, sobald der CVE bekannt gegeben wird.

  Technologien, die auf NGINX Open Source basieren, erfahren möglicherweise erst zu diesem Zeitpunkt von der CVE, und unserer Erfahrung nach hinken die OpenResty-Patches unseren um eine beträchtliche Zeit hinterher – in einem aktuellen Fall sogar vier Monate . Patches für einen Ingress-Controller auf Basis von OpenResty nehmen zwangsläufig noch mehr Zeit in Anspruch und geben böswilligen Akteuren reichlich Gelegenheit, die Sicherheitslücke auszunutzen.

Machen Sie Ihren Ingress-Controller zukunftssicher

Auch wenn Sie gerade erst anfangen, sich mit Kubernetes zu beschäftigen, besteht eine gute Chance, dass Sie es eines Tages in die Produktion einführen möchten. Es gibt vier Hauptbereiche, in denen Ihre Anforderungen mit der Zeit wahrscheinlich wachsen: Infrastruktur, Sicherheit, Support und Mandantenfähigkeit.

Infrastruktur – Werden Sie Kubernetes in Hybrid- oder Multi-Cloud-Umgebungen verwenden?

Es kommt selten vor, dass sich eine Organisation vollständig und dauerhaft auf einen einzigen Umgebungstyp festlegt. In der Regel verwenden Unternehmen eine Mischung aus lokalen Lösungen und Cloud-Umgebungen, die private, öffentliche, Hybrid-Cloud- und Multi-Cloud-Umgebungen umfassen können. (Um tiefer in die Unterschiede zwischen diesen Umgebungen einzutauchen, lesen Sie Was ist der Unterschied zwischen Multi-Cloud und Hybrid-Cloud? ).

Wie wir in Teil 1 dieser Reihe erwähnt haben, ist es verlockend, Tools auszuwählen, die standardmäßig in jeder Umgebung enthalten sind. Es gibt jedoch eine Reihe spezifischer Probleme mit Standard-Ingress-Controllern. Wir werden in Teil 3 der Reihe auf alle Nachteile eingehen, aber das für die Zukunftssicherheit relevanteste Problem ist die Abhängigkeit von einem bestimmten Anbieter – Sie können nicht in allen Ihren Umgebungen einen Cloud-spezifischen Ingress-Controller verwenden. Die Verwendung standardmäßiger Cloud-spezifischer Tools beeinträchtigt Ihre Skalierbarkeit, da Ihnen nur zwei unattraktive Alternativen bleiben:

1. Versuchen Sie, die vorhandene Cloud für alle Ihre Anforderungen nutzbar zu machen
2. Schreiben Sie alle Ihre Konfigurationen – nicht nur den Lastausgleich, sondern auch die Sicherheit! – für den Ingress-Controller in jeder neuen Umgebung neu

Während die erste Alternative aus geschäftlichen Gründen oft nicht umsetzbar ist, ist auch die zweite Alternative schwierig, da sie zu einer unkontrollierten Nutzung von Tools führt, neue Sicherheitslücken öffnet und von Ihren Mitarbeitern eine steile Lernkurve verlangt. Die dritte und effizienteste Alternative besteht darin, von Anfang an einen infrastrukturunabhängigen Ingress-Controller auszuwählen, sodass Sie in allen Ihren Umgebungen dasselbe Tool verwenden können.

Wenn es um die Infrastruktur geht, muss noch ein weiteres Element berücksichtigt werden: Zertifizierungen. Verwenden wir das Beispiel der Red Hat OpenShift Container Platform (OCP). Wenn Sie ein OCP-Benutzer sind, wissen Sie wahrscheinlich bereits, dass der Red Hat Marketplace zertifizierte Operatoren für OCP anbietet, darunter den NGINX Ingress Operator . Dank der Zertifizierungsstandards von Red Hat können Sie sich darauf verlassen, dass das Tool mit Ihrer Bereitstellung funktioniert und möglicherweise sogar gemeinsamen Support von Red Hat und dem Anbieter umfasst. In vielen Organisationen besteht aus Sicherheits- und Stabilitätsgründen die Anforderung, zertifizierte Tools zu verwenden. Selbst wenn Sie sich derzeit nur in der Testphase befinden, lohnt es sich daher, die Anforderungen Ihres Unternehmens an Produktionsumgebungen im Hinterkopf zu behalten.

Sicherheit – Wie sichern Sie Kubernetes von innen?

Vorbei sind die Zeiten, in denen Perimeterschutz allein ausreichte, um Apps und Kunden zu schützen. Kubernetes-Apps sind am besten geschützt, wenn die Sicherheit – einschließlich Authentifizierung und Autorisierung – nahe an den Apps liegt. Und da Unternehmen zunehmend eine Ende-zu-Ende -Verschlüsselung vorschreiben und ein Zero-Trust-Netzwerkmodell innerhalb von Kubernetes einführen, könnte ein Service Mesh Ihre Zukunft sein.

Was hat das alles mit Ihrem Ingress-Controller zu tun? Eine Menge! Die Zentralisierung der Sicherheit (Authentifizierung, Autorisierung, DoS-Schutz, Web Application Firewall) am Ingress-Punkt ist sowohl aus Kosten- als auch aus Effizienzgründen sehr sinnvoll. Und obwohl die meisten Service Meshes in die meisten Ingress-Controller integriert werden können, ist die Art und Weise der Integration von großer Bedeutung. Ein Ingress-Controller, der auf Ihre Sicherheitsstrategie abgestimmt ist, kann Ihnen bei der Entwicklung Ihrer App große Kopfschmerzen ersparen.

Weitere Einzelheiten zu den Risiken der Bereitstellung Cloud-nativer Apps finden Sie in den Artikeln „Sichern von Cloud-nativen Apps ohne Geschwindigkeitsverlust“, und „Bereitstellen von Anwendungsdiensten in Kubernetes, Teil 2“, um mehr über die Faktoren zu erfahren, die den besten Standort für Sicherheitstools bestimmen.

Unterstützung – Wie sehr können Sie es sich leisten, „auf sich allein gestellt“ zu sein?

Wenn Teams nur mit Kubernetes experimentieren, hat Support – sei es von der Community oder einem Unternehmen – oft nicht die höchste Priorität. Dies ist in Ordnung, wenn Ihre Teams viel Zeit haben, um eigene Lösungen und Workarounds zu entwickeln, aber es ist nicht nachhaltig, wenn Sie mit der Produktion beginnen. Auch wenn Sie heute keinen Support benötigen, kann es sinnvoll sein, einen Ingress-Controller zu wählen, bei dem Sie später Support hinzufügen können – oder der über eine günstige Supportstufe verfügt, die bei Bedarf aktualisiert werden kann.

Multi-Tenancy – Wie können mehrere Teams und Apps eine Containerumgebung sicher gemeinsam nutzen?

Am Anfang gab es ein Team und eine App … beginnt nicht jede Geschichte so? Die Geschichte geht oft damit weiter, dass ein Team seine eigene Kubernetes-App erfolgreich entwickelt, was dazu führt, dass die Organisation mehr Dienste auf Kubernetes betreibt. Und natürlich gilt: mehr Dienste = mehr Teams = mehr Komplexität.

Um maximale Effizienz zu erreichen, führen Unternehmen Multi-Tenancy ein und nutzen ein Kubernetes-Modell, das den von ihren Geschäftsprozessen geforderten Zugriff und die Isolierung unterstützt und gleichzeitig die Transparenz und Kontrolle bietet, die ihre Betreiber brauchen. Einige Ingress-Controller können Ihnen mithilfe einer Reihe von Funktionen und Konzepten dabei helfen, diese Cluster aufzuteilen: mehrere Ingresse, Klassen, Namespaces und bereichsbezogene Ressourcen, die das Festlegen rollenbasierter Zugriffskontrollen (RBAC) unterstützen.

Nächster Schritt: Optionen eingrenzen

Nachdem Sie nun über Ihre Anforderungen, Ihre Risikotoleranz und Ihre Zukunftssicherheit nachgedacht haben, verfügen Sie über genügend Informationen, um das sehr breite Feld der Ingress-Controller einzugrenzen. Wenn Sie das Feld nach Kategorien aufschlüsseln, können Sie diesen Schritt schneller erledigen. In Teil 3 unserer Serie untersuchen wir drei unterschiedliche Kategorien von Ingress-Controllern und betrachten ihre jeweiligen Vor- und Nachteile.