Wenn Sie einen Kubernetes-Cluster für eine bestimmte Anwendung starten, müssen Sie verstehen, welche Auswirkungen die Anwendung selbst, das Unternehmen und die Entwickler auf diese Ressource haben. Mit diesen Informationen können Sie beginnen, eine Architekturentscheidung zu treffen und insbesondere einen bestimmten Ingress-Controller auszuwählen, von dem es heute bereits eine große Anzahl gibt. Um einen grundlegenden Überblick über die verfügbaren Optionen zu bekommen, ohne viele Artikel/Dokumentationen usw. durchgehen zu müssen, haben wir diese Übersicht erstellt, einschließlich der wichtigsten (produktionsbereiten) Ingress-Controller.
Wir hoffen, dass es den Kollegen bei der Auswahl einer architektonischen Lösung hilft – zumindest wird es ein Ausgangspunkt für detailliertere Informationen und praktische Experimente sein. Zuvor haben wir andere ähnliche Materialien im Internet studiert und seltsamerweise keine einzige mehr oder weniger vollständige und vor allem strukturierte Rezension gefunden. Also lasst uns diese Lücke füllen!
Kriterien
Um einen Vergleich anzustellen und ein brauchbares Ergebnis zu erhalten, müssen Sie grundsätzlich nicht nur das Fachgebiet verstehen, sondern auch über eine spezifische Liste von Kriterien verfügen, die den Forschungsvektor festlegen. Ohne den Anspruch zu erheben, alle möglichen Fälle der Verwendung von Ingress/Kubernetes zu analysieren, haben wir versucht, die allgemeinsten Anforderungen an Controller hervorzuheben – seien Sie darauf vorbereitet, dass Sie in jedem Fall alle Ihre Besonderheiten und Besonderheiten separat studieren müssen.
Aber ich beginne mit den Eigenschaften, die so vertraut geworden sind, dass sie in allen Lösungen implementiert sind und nicht berücksichtigt werden:
- dynamische Erkennung von Diensten (Service Discovery);
- SSL-Terminierung;
- Arbeiten mit WebSockets.
Nun zu den Vergleichspunkten:
Unterstützte Protokolle
Eines der grundlegenden Auswahlkriterien. Möglicherweise funktioniert Ihre Software nicht mit Standard-HTTP oder es müssen mehrere Protokolle gleichzeitig bearbeitet werden. Wenn Ihr Fall nicht dem Standard entspricht, berücksichtigen Sie diesen Faktor unbedingt, damit Sie den Cluster später nicht neu konfigurieren müssen. Für alle Controller variiert die Liste der unterstützten Protokolle.
Software im Mittelpunkt
Es gibt verschiedene Anwendungsvarianten, auf denen der Controller basiert. Beliebte sind Nginx, Traefik, Haproxy und Envoy. Im Allgemeinen hat es möglicherweise keinen großen Einfluss darauf, wie Datenverkehr empfangen und übertragen wird, aber es ist immer nützlich, die möglichen Nuancen und Merkmale dessen zu kennen, was sich „unter der Haube“ verbirgt.
Verkehrsführung
Auf welcher Grundlage kann eine Entscheidung über die Richtung des Verkehrs zu einem bestimmten Dienst getroffen werden? Normalerweise sind dies Host und Pfad, es gibt jedoch noch weitere Möglichkeiten.
Namespace innerhalb eines Clusters
Namespace (Namespace) – die Möglichkeit, Ressourcen in Kubernetes logisch aufzuteilen (z. B. auf der Bühne, in der Produktion usw.). Es gibt Ingress-Controller, die in jedem Namespace separat installiert werden müssen (und dann den Datenverkehr leiten können). nur zu den Pods dieses Raumes). Und es gibt solche (und ihre deutliche Mehrheit), die global für den gesamten Cluster funktionieren – bei ihnen wird der Datenverkehr unabhängig vom Namespace an jeden Pod des Clusters weitergeleitet.
Beispiele für Upstreams
Wie wird der Datenverkehr an fehlerfreie Instanzen der Anwendung und Dienste weitergeleitet? Es gibt Optionen mit aktiven und passiven Prüfungen, Wiederholungsversuchen und Leistungsschaltern (Weitere Einzelheiten finden Sie beispielsweise unter ), eigene Implementierungen von Gesundheitschecks (Custom Health Checks) usw. Ein sehr wichtiger Parameter, wenn Sie hohe Anforderungen an die Verfügbarkeit und rechtzeitige Entfernung ausgefallener Dienste aus dem Balancing haben.
Ausgleichsalgorithmen
Es gibt viele Möglichkeiten: von traditionell zum Exotischen , sowie einzelne Features wie .
Authentifizierung
Welche Autorisierungsschemata unterstützt der Controller? Basic, Digest, Oauth, External-Auth – ich denke, diese Optionen sollten bekannt sein. Dies ist ein wichtiges Kriterium, wenn es viele Entwicklerschleifen (und/oder nur private Schleifen) gibt, auf die über Ingress zugegriffen wird.
Verkehrsverteilung
Unterstützt der Controller häufig verwendete Verkehrsverteilungsmechanismen wie Canary-Rollouts (Canary), A/B-Tests und Verkehrsspiegelung (Mirroring/Shadowing)? Dies ist ein wirklich heikles Thema für Anwendungen, die eine genaue und präzise Verkehrsverwaltung für produktive Tests, die Offline-Fehlerbehebung (oder mit minimalem Verlust) von Produktfehlern, die Verkehrsanalyse usw. erfordern.
Bezahltes Abonnement
Gibt es eine kostenpflichtige Option für den Controller mit erweiterten Funktionen und/oder technischem Support?
Grafische Benutzeroberfläche (Web UI)
Gibt es eine grafische Benutzeroberfläche zum Verwalten der Controller-Konfiguration? Hauptsächlich aus „Handlichkeitsgründen“ und/oder für diejenigen, die einige Änderungen an der Ingress-Konfiguration vornehmen müssen, aber die Arbeit mit „rohen“ Vorlagen ist unpraktisch. Dies kann nützlich sein, wenn Entwickler spontan einige Experimente mit dem Datenverkehr durchführen möchten.
JWT-Validierung
Das Vorhandensein einer integrierten Validierung von JSON-Web-Tokens zur Autorisierung und Validierung des Benutzers gegenüber der Endanwendung.
Möglichkeiten zur Konfigurationsanpassung
Vorlagenerweiterbarkeit im Sinne von Mechanismen, die es Ihnen ermöglichen, Ihre eigenen Anweisungen, Flags usw. zu Standardkonfigurationsvorlagen hinzuzufügen.
Grundlegende DDOS-Schutzmechanismen
Einfache Ratenbegrenzungsalgorithmen oder komplexere Optionen zur Verkehrsfilterung basierend auf Adressen, Whitelists, Ländern usw.
Trace anfordern
Die Möglichkeit, Anfragen von Ingresses an bestimmte Dienste/Pods und idealerweise auch zwischen Diensten/Pods zu überwachen, zu verfolgen und zu debuggen.
WAF
Unterstützen .
Controller
Die Liste der Verantwortlichen wurde auf Grundlage erstellt и . Einige von ihnen haben wir aufgrund ihrer Spezifität oder geringen Prävalenz (frühes Entwicklungsstadium) von der Überprüfung ausgeschlossen. Der Rest wird weiter unten besprochen. Beginnen wir mit einer allgemeinen Beschreibung der Lösungen und fahren mit einer Übersichtstabelle fort.
Eingang von Kubernetes
Website:
Lizenz: Apache 2.0
Dies ist der offizielle Controller für Kubernetes und wird von der Community entwickelt. Aus dem Namen geht hervor, dass es auf Nginx basiert und durch einen anderen Satz von Lua-Plugins ergänzt wird, die zur Implementierung zusätzlicher Funktionen verwendet werden. Aufgrund der Beliebtheit von Nginx selbst und der minimalen Änderungen daran, wenn es als Controller verwendet wird, ist diese Option möglicherweise die einfachste und am einfachsten zu konfigurierende für den durchschnittlichen Ingenieur (mit Web-Erfahrung).
Eingang durch NGINX Inc.
Website:
Lizenz: Apache 2.0
Das offizielle Produkt der Nginx-Entwickler. Hat eine kostenpflichtige Version basierend auf . Der Grundgedanke ist ein hohes Maß an Stabilität, ständige Abwärtskompatibilität, das Fehlen jeglicher Fremdmodule und die deklarierte höhere Geschwindigkeit (im Vergleich zum offiziellen Controller), die durch die Ablehnung von Lua erreicht wird.
Die kostenlose Version ist deutlich reduziert, auch im Vergleich zum offiziellen Controller (aufgrund des Fehlens der gleichen Lua-Module). Gleichzeitig verfügt die kostenpflichtige Version über eine recht umfangreiche Zusatzfunktionalität: Echtzeitmetriken, JWT-Validierung, aktive Gesundheitsprüfungen und mehr. Ein wichtiger Vorteil gegenüber NGINX Ingress ist die volle Unterstützung für TCP/UDP-Verkehr (und auch in der Community-Version!). Minus - Traffic-Verteilungsfunktion, die zwar „höchste Priorität für Entwickler hat“, deren Implementierung jedoch Zeit in Anspruch nimmt.
Kong Ingress
Website:
Lizenz: Apache 2.0
Von Kong Inc. entwickeltes Produkt. in zwei Versionen: kommerziell und kostenlos. Basierend auf Nginx, das um eine Vielzahl von Lua-Modulen erweitert wurde.
Zunächst lag der Schwerpunkt auf der Verarbeitung und Weiterleitung von API-Anfragen, d. h. als API-Gateway, aber im Moment ist es ein vollwertiger Ingress-Controller. Hauptvorteile: viele Zusatzmodule (auch von Drittentwicklern), die einfach zu installieren und zu konfigurieren sind und mit deren Hilfe vielfältige Zusatzfunktionen umgesetzt werden. Integrierte Funktionen bieten jedoch bereits viele Möglichkeiten. Die Jobkonfiguration erfolgt mithilfe von CRD-Ressourcen.
Ein wichtiges Merkmal des Produkts – das Arbeiten innerhalb derselben Kontur (anstatt über mehrere Namensräume hinweg) ist ein kontroverses Thema: Für einige wird es wie ein Nachteil erscheinen (Sie müssen Entitäten für jede Kontur erstellen), und für andere ist es eine Funktion ( BоHöheres Maß an Isolation, wie Wenn ein Controller defekt ist, beschränkt sich das Problem nur auf den Stromkreis.
Traefik
Website:
Lizenz: MIT
Ein Proxy, der ursprünglich für die Arbeit mit der Anforderungsweiterleitung für Microservices und deren dynamische Umgebung erstellt wurde. Daher viele nützliche Funktionen: Aktualisierung der Konfiguration ohne Neustart, Unterstützung einer großen Anzahl von Ausgleichsmethoden, Webschnittstelle, Metrikweiterleitung, Unterstützung verschiedener Protokolle, REST-API, Canary-Releases und vieles mehr. Ein weiteres nettes Feature ist die standardmäßige Unterstützung von Let's Encrypt-Zertifikaten. Der Nachteil besteht darin, dass der Controller zur Organisation einer Hochverfügbarkeit (HA) einen eigenen KV-Speicher installieren und anschließen muss.
HAProxy
Website:
Lizenz: Apache 2.0
HAProxy ist seit langem als Proxy und Traffic Balancer bekannt. Als Teil eines Kubernetes-Clusters bietet es ein „sanftes“ Konfigurationsupdate (ohne Verkehrsverlust), Diensterkennung auf Basis von DNS und dynamische Konfiguration über API. Es kann attraktiv sein, die Konfigurationsvorlage durch Ersetzen des CM vollständig anzupassen und die Möglichkeit zu haben, Sprig-Bibliotheksfunktionen darin zu verwenden. Im Allgemeinen liegt der Schwerpunkt der Lösung auf hoher Geschwindigkeit, deren Optimierung und Effizienz bei den verbrauchten Ressourcen. Der Vorteil des Controllers liegt in der Unterstützung einer Rekordzahl verschiedener Auswuchtmethoden.
Reise
Website:
Lizenz: Apache 2.0
Basierend auf dem HAproxy-Controller, der als universelle Lösung positioniert ist, die eine breite Palette von Funktionen bei einer großen Anzahl von Anbietern unterstützt. Es bietet sich die Möglichkeit, den Verkehr auf L7 und L4 auszugleichen, und der Ausgleich des gesamten TCP-L4-Verkehrs kann als eines der Hauptmerkmale der Lösung bezeichnet werden.
Kontur
Website:
Lizenz: Apache 2.0
Diese Lösung basiert nicht nur auf Envoy: Sie wurde von entwickelt gemeinsam mit den Autoren dieses beliebten Proxys. Eine wichtige Funktion ist die Möglichkeit, die Kontrolle über Ingress-Ressourcen mithilfe von IngressRoute-CRD-Ressourcen zu trennen. Für Organisationen mit vielen Entwicklungsteams, die denselben Cluster verwenden, trägt dies dazu bei, die Sicherheit beim Arbeiten mit Datenverkehr in benachbarten Schleifen zu maximieren und sie vor Fehlern bei der Änderung von Ingress-Ressourcen zu schützen.
Es bietet außerdem einen erweiterten Satz an Ausgleichsmethoden (es gibt Anforderungsspiegelung, automatische Wiederholung, Begrenzung der Anforderungsrate und vieles mehr) sowie eine detaillierte Überwachung des Verkehrsflusses und von Ausfällen. Vielleicht ist es für jemanden ein erheblicher Nachteil, dass Sticky Sessions nicht unterstützt werden (obwohl die Arbeit ).
Istio Ingress
Website:
Lizenz: Apache 2.0
Eine umfassende Service-Mesh-Lösung, die nicht nur ein Ingress-Controller ist, der den von außen eingehenden Datenverkehr verwaltet, sondern auch den gesamten Datenverkehr innerhalb des Clusters steuert. Unter der Haube wird Envoy als Sidecar-Proxy für jeden Dienst verwendet. Im Wesentlichen handelt es sich hierbei um einen großen Mähdrescher, der „alles kann“, und dessen Hauptidee maximale Verwaltbarkeit, Erweiterbarkeit, Sicherheit und Transparenz ist. Damit können Sie das Traffic-Routing, die Zugriffsberechtigung zwischen Diensten, den Ausgleich, die Überwachung, Canary-Releases und vieles mehr optimieren. Lesen Sie mehr über Istio in der Artikelserie „".
Ambassador
Website:
Lizenz: Apache 2.0
Eine weitere Lösung basierend auf Envoy. Es gibt kostenlose und kommerzielle Versionen. Es ist als „vollständig nativ für Kubernetes“ positioniert, was entsprechende Vorteile mit sich bringt (enge Integration mit den Methoden und Entitäten des K8s-Clusters).
Vergleichstabelle
Der Höhepunkt des Artikels ist diese riesige Tabelle:
Zur näheren Betrachtung ist es anklickbar und auch im Format verfügbar .
Summieren
Der Zweck dieses Artikels besteht darin, ein umfassenderes Verständnis (jedoch keineswegs erschöpfend!) darüber zu vermitteln, welche Entscheidung Sie in Ihrem speziellen Fall treffen sollten. Wie üblich hat jeder Controller seine eigenen Vor- und Nachteile…
Der klassische Ingress von Kubernetes zeichnet sich durch seine Verfügbarkeit und Bewährtheit aus und ist reich an Funktionen – im Allgemeinen sollte er „ausreichend für die Augen“ sein. Wenn jedoch erhöhte Anforderungen an die Stabilität, den Funktionsumfang und die Entwicklung bestehen, sollten Sie auf Ingress mit NGINX Plus und einem kostenpflichtigen Abonnement achten. Kong verfügt über den umfangreichsten Satz an Plug-Ins (und dementsprechend über die Möglichkeiten, die sie bieten), und in der kostenpflichtigen Version gibt es sogar noch mehr davon. Es verfügt über zahlreiche Möglichkeiten, als API-Gateway, dynamische Konfiguration auf Basis von CRD-Ressourcen sowie grundlegende Kubernetes-Dienste zu arbeiten.
Werfen Sie einen Blick auf Traefik und HAProxy, da die Anforderungen an Ausgleichs- und Autorisierungsmethoden gestiegen sind. Dabei handelt es sich um Open-Source-Projekte, die sich über die Jahre bewährt haben, sehr stabil sind und sich aktiv weiterentwickeln. Contour gibt es schon seit ein paar Jahren, aber es sieht immer noch zu jung aus und verfügt nur über grundlegende Funktionen, die zusätzlich zu Envoy hinzugefügt wurden. Wenn Anforderungen an die Anwesenheit/Einbettung von WAF vor der Anwendung bestehen, sollten Sie auf den gleichen Ingress von Kubernetes oder HAProxy achten.
Und am umfangreichsten an Funktionen sind Produkte, die auf Envoy basieren, insbesondere Istio. Es scheint sich um eine umfassende Lösung zu handeln, die „alles kann“, was allerdings auch eine deutlich höhere Einstiegsschwelle für Konfiguration/Start/Administration als andere Lösungen bedeutet.
Wir haben uns für Ingress von Kubernetes als Standard-Controller entschieden und nutzen ihn noch immer, was 80-90 % des Bedarfs abdeckt. Es ist recht zuverlässig, einfach zu konfigurieren und zu erweitern. Im Allgemeinen sollte es, sofern keine spezifischen Anforderungen vorliegen, für die meisten Cluster/Anwendungen geeignet sein. Von den gleichen universellen und relativ einfachen Produkten können Traefik und HAProxy empfohlen werden.
PS
Lesen Sie auch auf unserem Blog:
- „Zurück zu Microservices mit Istio“: , , ;
- «";
- «".
Source: habr.com