Wenn Sie einen Kubernetes-Cluster für eine bestimmte Anwendung starten, sollten Sie wissen, welche Anforderungen die Anwendung selbst, das Unternehmen und die Entwickler an diese Ressource stellen. Wenn Sie über diese Informationen verfügen, können Sie eine architektonische Entscheidung treffen und insbesondere einen bestimmten Ingress-Controller auswählen, von dem es heute bereits eine große Anzahl gibt. Um eine grundlegende Vorstellung von den verfügbaren Optionen zu erhalten, ohne viele Artikel / Dokumentationen usw. studieren zu müssen, haben wir diese Überprüfung vorbereitet, indem wir die wichtigsten (produktionsbereiten) Ingress-Controller darin aufgenommen haben.
Wir hoffen, dass dies den Kollegen bei der Auswahl einer architektonischen Lösung hilft - zumindest als Ausgangspunkt für detailliertere Informationen und praktische Experimente. Zuvor haben wir andere ähnliche Materialien im Netzwerk untersucht und seltsamerweise keine einzige mehr oder weniger vollständige und vor allem strukturierte Überprüfung gefunden. Füllen Sie also diese Lücke!
Kriterien
Um im Prinzip einen Vergleich anstellen und nützliche Ergebnisse erzielen zu können, müssen Sie nicht nur den Themenbereich verstehen, sondern auch eine spezifische Liste von Kriterien haben, die den Forschungsvektor bestimmen. Ohne vorzugeben, 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 alle Ihre Besonderheiten und Einzelheiten in jedem Fall separat untersuchen müssen.
Aber ich beginne mit den Merkmalen, die so vertraut geworden sind, dass sie in allen Entscheidungen umgesetzt werden und nicht berücksichtigt werden:
- dynamische Erkennung von Diensten (Diensterkennung);
- SSL-Beendigung;
- Arbeit mit Websockets.
Nun zu den Vergleichspunkten:
Unterstützte Protokolle
Eines der grundlegenden Auswahlkriterien. Ihre Software funktioniert möglicherweise nicht mit Standard-HTTP, oder es müssen möglicherweise viele Protokolle gleichzeitig bearbeitet werden. Wenn Ihr Fall nicht dem Standard entspricht, müssen Sie diesen Faktor berücksichtigen, damit Sie den Cluster später nicht neu konfigurieren müssen. Für alle Controller variiert die Liste der unterstützten Protokolle.
Software-basiert
Es gibt verschiedene Anwendungsoptionen, auf denen der Controller basiert. Beliebte sind Nginx, Traefik, Haproxy, Gesandter. Im allgemeinen Fall hat dies möglicherweise keinen Einfluss auf die Art und Weise, wie Verkehr empfangen und gesendet wird. Es ist jedoch immer nützlich, die potenziellen Nuancen und Merkmale dessen zu kennen, was sich „unter der Haube“ befindet.
Verkehrsrouting
Auf der Grundlage dessen, was können wir über die Richtung des Verkehrs zu einem bestimmten Dienst entscheiden? Dies ist normalerweise Host und Pfad, es gibt jedoch zusätzliche Funktionen.
Cluster-Namespace
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 festgelegt werden müssen (und dann
nur den Datenverkehr zu den Pods dieses Bereichs leiten können). Und es gibt einige (und ihre überwältigende Mehrheit), die global für den gesamten Cluster arbeiten - in ihnen wird der Datenverkehr unabhängig vom Namespace an einen beliebigen Pod des Clusters geleitet.
Proben für Upstream
Wie wird der Datenverkehr auf fehlerfreie Instanzen der Anwendung und der Dienste geleitet? Es gibt Optionen mit aktiven und passiven Überprüfungen, Wiederholungsversuchen, Leistungsschaltern
(weitere Informationen finden Sie beispielsweise im Artikel über Istio ) , benutzerdefinierten Implementierungen
für Integritätsprüfungen usw. Ein sehr wichtiger Parameter, wenn Sie hohe Anforderungen an die Zugänglichkeit und die rechtzeitige Rücknahme fehlgeschlagener Dienste aus dem Kontostand haben.
Ausgleichsalgorithmen
Es gibt viele Optionen: vom traditionellen
Round-Robin bis zu exotischen wie
rdp-Cookies sowie einigen Funktionen wie
Sticky Sessions .
Authentifizierung
Welche Berechtigungsschemata unterstützt der Controller? Basic, Digest, Oauth, External-Auth - Ich denke, dass diese Optionen vertraut sein sollten. Dies ist ein wichtiges Kriterium, wenn Sie viele Schaltkreise für Entwickler (und / oder nur geschlossene) verwenden, auf die über Ingress zugegriffen wird.
Verkehrsverteilung
Unterstützt der Controller häufig verwendete Mechanismen für die Verkehrsverteilung wie kanarische Rollouts, A / B-Tests und Spiegelung des Verkehrs (Spiegeln / Abschatten)? Dies ist ein wirklich schmerzhaftes Thema für Anwendungen, die eine genaue und genaue Verkehrssteuerung für produktive Tests, das Debuggen von Produktfehlern, die nicht im Kampf (oder mit minimalen Verlusten sind), Verkehrsanalysen 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 Oberfläche zur Steuerung der Konfiguration des Controllers? Grundsätzlich ist es für "Handlichkeit" und / oder für diejenigen, die einige Änderungen an der Konfiguration von Ingress vornehmen müssen, aber unpraktisch, mit "rohen" Vorlagen zu arbeiten. Dies kann nützlich sein, wenn Entwickler Experimente mit dem Datenverkehr im laufenden Betrieb durchführen möchten.
JWT-Validierung
Das Vorhandensein einer integrierten JSON-Überprüfung von Web-Token zur Autorisierung und Benutzervalidierung der endgültigen Anwendung.
Funktionen zur Anpassung der Konfiguration
Erweiterbarkeit von Vorlagen im Sinne von Mechanismen zum Hinzufügen eigener Anweisungen, Flags usw. zu Standardkonfigurationsvorlagen
Grundlegende DDOS-Schutzmechanismen
Einfache Ratenbegrenzungsalgorithmen oder ausgefeiltere Optionen zum Filtern des Datenverkehrs anhand von Adressen, weißen Listen, Ländern usw.
Trace anfordern
Möglichkeiten zum Beobachten, Verfolgen und Debuggen von Anforderungen von Ingresss an bestimmte Services / Pods und im Idealfall auch zwischen Services / Pods.
WAF
Unterstützung für
Anwendungsfirewall .
Ingress Controller
Die Liste der Controller basierte auf der
offiziellen Kubernetes-Dokumentation und
dieser Tabelle . Wir haben einige von ihnen aufgrund ihrer Spezifität oder geringen Prävalenz (frühes Entwicklungsstadium) von der Überprüfung ausgeschlossen. Die übrigen werden unten diskutiert. Wir beginnen mit einer allgemeinen Beschreibung der Lösungen und fahren mit der Pivot-Tabelle fort.
Ingress von Kubernetes
Website: github.com/kubernetes/ingress-nginxLizenz: Apache 2.0Dies ist der offizielle Controller für Kubernetes, der von der Community entwickelt wird. Aus dem Namen geht hervor, dass es auf Nginx basiert und durch einen anderen Satz von Lua-Plugins ergänzt wird, mit denen zusätzliche Funktionen implementiert werden. Aufgrund der Beliebtheit von Nginx selbst und der minimalen Änderungen an Nginx als Controller ist diese Option möglicherweise der einfachste und verständlichste durchschnittliche Konfigurationsingenieur (mit Erfahrung im Web).
Ingress von NGINX Inc.
Website: github.com/nginxinc/kubernetes-ingressLizenz: Apache 2.0Das offizielle Produkt der Nginx-Entwickler. Es hat eine kostenpflichtige Version basierend auf
NGINX Plus . Die Hauptidee ist ein hohes Maß an Stabilität, konstante Abwärtskompatibilität, das Fehlen jeglicher Fremdmodule und die erklärte erhöhte Geschwindigkeit (im Vergleich zum offiziellen Controller), die durch die Ablehnung von Lua erreicht wird.
Die kostenlose Version wurde erheblich reduziert, auch im Vergleich zum offiziellen Controller (aufgrund des Fehlens der gleichen Lua-Module). Gleichzeitig bezahlt hat eine ziemlich breite zusätzliche Funktionalität: Echtzeitmetriken, JWT-Validierung, aktive Integritätsprüfungen und mehr. Ein wichtiger Vorteil gegenüber NGINX Ingress ist die vollständige Unterstützung des TCP / UDP-Verkehrs (und auch in der Community-Version!). Der Nachteil ist das
Fehlen von Funktionen für die Verkehrsverteilung, die jedoch "für Entwickler die höchste Priorität haben", deren Implementierung jedoch einige Zeit in Anspruch nimmt.
Kong Ingress
Website: github.com/Kong/kubernetes-ingress-controllerLizenz: Apache 2.0Produkt entwickelt von Kong Inc. in zwei Versionen: kommerziell und kostenlos. Es basiert auf nginx, dessen Funktionen durch eine große Anzahl von Modulen auf Lua erweitert werden.
Anfänglich konzentrierte es sich auf die Verarbeitung und Weiterleitung von API-Anforderungen, d.h. wie das API-Gateway, aber im Moment ist es ein vollwertiger Ingress-Controller geworden. Hauptvorteile: Viele zusätzliche Module (auch von Drittentwicklern), die einfach zu installieren und zu konfigurieren sind und mit denen eine Vielzahl zusätzlicher Funktionen implementiert werden. Die integrierten Funktionen bieten jedoch bereits viele Funktionen. Die Arbeitskonfiguration erfolgt mithilfe von CRD-Ressourcen.
Ein wichtiges Merkmal des Produkts - das Arbeiten innerhalb derselben Schaltung (anstelle von Kreuznamen) ist ein kontroverses Thema: Für einige scheint es ein Nachteil zu sein (Sie müssen Entitäten für jede Schaltung erstellen), und für jemanden ist es eine Eigenschaft (
ein höheres Maß an Isolation, weil Wenn ein Controller defekt ist, ist das Problem auf nur einen Stromkreis beschränkt.
Traefik
Website: github.com/containous/traefikLizenz: MITEin Proxy, der ursprünglich für das Routing von Anforderungen für Microservices und deren dynamische Umgebung erstellt wurde. Daher viele nützliche Funktionen: Aktualisieren Sie die Konfiguration vollständig ohne Neustart, unterstützen Sie eine große Anzahl von Ausgleichsmethoden, eine Webschnittstelle, Weiterleitungsmetriken, unterstützen Sie verschiedene Protokolle, REST-APIs, kanarische Releases und vieles mehr. Eine nette Funktion ist auch die sofortige Unterstützung von Let's Encrypt-Zertifikaten. Der Nachteil ist, dass der Controller für die Organisation von Hochverfügbarkeit (HA) seinen eigenen KV-Speicher installieren und anschließen muss.
HAProxy
Website: github.com/jcmoraisjr/haproxy-ingressLizenz: Apache 2.0HAProxy ist seit langem als Proxy und Traffic Balancer bekannt. Als Teil des Kubernetes-Clusters bietet es ein "weiches" Konfigurationsupdate (ohne Datenverkehrsverlust), eine DNS-basierte Diensterkennung und eine dynamische Konfiguration mithilfe der API. Eine vollständige Anpassung der Konfigurationsvorlage durch Ersetzen der CM'a sowie die Möglichkeit, die Funktionen der darin enthaltenen Sprig-Bibliothek zu verwenden, können attraktiv werden. Im Allgemeinen liegt der Schwerpunkt der Lösung auf hoher Geschwindigkeit, Optimismus und Effizienz bei den verbrauchten Ressourcen. Der Vorteil des Controllers ist die Unterstützung einer Rekordzahl verschiedener Auswuchtmethoden.
Voyager
Website: github.com/appscode/voyagerLizenz: Apache 2.0HAproxy-basierter Controller, der als universelle Lösung positioniert ist und breite Funktionen bei einer großen Anzahl von Anbietern unterstützt. Die Möglichkeit zum Ausgleich des Datenverkehrs auf L7 und L4 wird vorgeschlagen, und der Ausgleich des gesamten TCP-L4-Datenverkehrs kann als eines der Hauptmerkmale der Lösung bezeichnet werden.
Kontur
Website: github.com/heptio/contourLizenz: Apache 2.0Der Gesandte legte nicht nur den Grundstein für diese Lösung: Sie wurde
gemeinsam mit den Autoren dieses beliebten Proxys entwickelt. Ein wichtiges Merkmal ist die Möglichkeit, das Ingress-Ressourcenmanagement mithilfe von IngressRoute-CRD-Ressourcen aufzuteilen. Für Unternehmen mit vielen Entwicklungsteams, die einen einzelnen Cluster verwenden, hilft dies, die Sicherheit des Datenverkehrs in benachbarten Schaltkreisen zu maximieren und sie vor Fehlern beim Ändern von Ingress-Ressourcen zu schützen.
Es bietet auch eine erweiterte Reihe von Ausgleichsmethoden (es gibt Spiegelung von Anforderungen, automatische Wiederholungsversuche, Einschränkung der Anforderungsrate und vieles mehr), eine detaillierte Überwachung des Verkehrsflusses und von Fehlern. Vielleicht ist es für einige ein erheblicher Nachteil des Mangels an Unterstützung für Sticky-Sessions (obwohl
bereits gearbeitet wird ).
Isstio Eingang
Website: istio.io/docs/tasks/traffic-management/ingressLizenz: Apache 2.0Eine umfassende Service-Mesh-Lösung, bei der es sich nicht nur um einen Ingress-Controller handelt, der eingehenden Datenverkehr von außen steuert, sondern auch den gesamten Datenverkehr innerhalb des Clusters. Unter der Haube wird Envoy als Beiwagen-Proxy für jeden Dienst verwendet. Im Wesentlichen handelt es sich um einen großen Mähdrescher, der „alles kann“. Seine Hauptidee ist maximale Verwaltbarkeit, Erweiterbarkeit, Sicherheit und Transparenz. Damit können Sie das Routing des Datenverkehrs, die Autorisierung des Zugriffs zwischen Diensten, das Balancing, die Überwachung, kanarische Veröffentlichungen und vieles mehr optimieren. Weitere Informationen zu Istio finden Sie in der Artikelserie
Back to Microservices with Istio .
Botschafter
Website: github.com/datawire/ambassadorLizenz: Apache 2.0Eine weitere Lösung basierend auf Envoy. Hat eine kostenlose und kommerzielle Version. Es ist als „vollständig in Kubernetes beheimatet“ positioniert, was entsprechende Vorteile mit sich bringt (enge Integration mit Methoden und Entitäten des K8s-Clusters).
Vergleichstabelle
Der Höhepunkt des Artikels ist also dieser riesige Tisch:
Es kann zur detaillierteren Anzeige angeklickt werden und ist auch im
Google Sheets- Format verfügbar.
Zusammenfassend
Der Zweck des Artikels besteht darin, ein umfassenderes Verständnis (jedoch absolut nicht erschöpfend!) Zu vermitteln, welche Wahl in Ihrem speziellen Fall zu treffen ist. Wie immer hat jeder Controller seine Vor- und Nachteile ...
Der klassische Kubernetes Ingress ist gut für seine Zugänglichkeit und Provenienz, reich an Fähigkeiten - im Allgemeinen sollte er "genug für die Augen" sein. Wenn jedoch erhöhte Anforderungen an Stabilität, Funktionsumfang und Entwicklung gestellt werden, sollten Sie auf Ingress mit NGINX Plus und ein kostenpflichtiges Abonnement achten. Kong verfügt über eine Vielzahl von Plugins (und dementsprechend über die von ihnen bereitgestellten Funktionen), und in der kostenpflichtigen Version gibt es noch mehr davon. Es bietet zahlreiche Möglichkeiten, als API-Gateway zu arbeiten, dynamisch basierend auf CRD-Ressourcen sowie grundlegenden Kubernetes-Diensten zu konfigurieren.
Werfen Sie einen Blick auf Traefik und HAProxy, da die Anforderungen an Ausgleichs- und Autorisierungsmethoden gestiegen sind. Dies sind Open Source-Projekte, die sich im Laufe der Jahre bewährt haben, sehr stabil sind und sich aktiv weiterentwickeln. Contour gibt es schon seit ein paar Jahren, aber es sieht noch zu jung aus und verfügt nur über grundlegende Funktionen, die zusätzlich zu Envoy hinzugefügt wurden. Wenn es Anforderungen für das Vorhandensein / die Einbettung von WAF vor der Anwendung gibt, sollten Sie auf denselben Ingress von Kubernetes oder HAProxy achten.
Und die reichhaltigsten Funktionen sind Produkte, die auf der Basis von Envoy hergestellt wurden, insbesondere Istio. Es scheint eine komplexe Lösung zu sein, die „alles kann“, was jedoch auch eine deutlich höhere Einstiegsschwelle für Konfiguration / Start / Verwaltung bedeutet als andere Lösungen.
Wir haben Kubernetes Ingress als Standard-Controller ausgewählt und verwenden es weiterhin, das 80-90% des Bedarfs abdeckt. Es ist sehr zuverlässig, einfach zu konfigurieren und zu erweitern. Im Allgemeinen sollte es mangels spezifischer Anforderungen für die meisten Cluster / Anwendungen geeignet sein. Von den gleichen vielseitigen und relativ einfachen Produkten können Traefik und HAProxy empfohlen werden.
PS
Lesen Sie auch in unserem Blog: