Überblick und Vergleich von Ingress-Controllern für Kubernetes

Beim Start eines Kubernetes-Clusters für eine bestimmte Anwendung sollte man verstehen, welche Anforderungen die Anwendung, das Unternehmen und die Entwickler an diese Ressource stellen. Mit diesen Informationen kann man mit der architektonischen Entscheidungsfindung beginnen, insbesondere mit der Auswahl eines spezifischen Ingress-Controllers, von denen es heutzutage bereits viele gibt. Um eine grundlegende Vorstellung von den verfügbaren Optionen zu erhalten, ohne eine Vielzahl von Artikeln/Dokumentationen usw. durchlesen zu müssen, haben wir diesen Überblick vorbereitet und dabei die wichtigsten (produktionsbereiten) Ingress-Controller aufgenommen.

Wir hoffen, dass er den Kollegen bei der Auswahl der architektonischen Lösung hilft — zumindest als Ausgangspunkt für detailliertere Informationen und praktische Experimente dient. Vorab haben wir andere ähnliche Materialien im Netz untersucht und, merkwürdigerweise, kein einziges umfassendes, vor allem aber strukturiertes, Review gefunden. Lassen Sie uns also diese Lücke füllen!

Kriterien

Um überhaupt einen Vergleich anzustellen und ein einigermaßen nützliches Ergebnis zu erzielen, muss man nicht nur das Fachgebiet verstehen, sondern auch eine konkrete Liste von Kriterien haben, die den Forschungsschwerpunkt bestimmen. Ohne den Anspruch, alle möglichen Anwendungsfälle von Ingress/Kubernetes zu analysieren, haben wir versucht, die allgemeinsten Anforderungen an Controllers herauszuarbeiten — seien Sie darauf vorbereitet, dass Sie alle spezifischen Details und Besonderheiten dennoch separat studieren müssen.

Ich werde jedoch mit den Merkmalen beginnen, die so vertraut geworden sind, dass sie in allen Lösungen implementiert sind und nicht weiter betrachtet werden:

• dynamische Service-Erkennung (service discovery);
• SSL-Terminierung;
• Arbeiten mit Websockets.

Jetzt zu den Vergleichspunkten:

Unterstützte Protokolle

Eines der grundlegenden Kriterien für die Auswahl. Ihre Software arbeitet möglicherweise nicht mit dem Standard-HTTP oder erfordert die gleichzeitige Nutzung mehrerer Protokolle. Wenn Ihr Fall nicht standardisiert ist, sollten Sie diesen Faktor unbedingt berücksichtigen, um späteren Aufwand bei der Neukonfiguration des Clusters zu vermeiden. Bei allen Controllern variiert die Liste der unterstützten Protokolle.

Software im Kern

Es gibt mehrere Varianten von Anwendungen, auf denen der Controller basiert. Beliebte sind nginx, traefik, haproxy, envoy. Im Allgemeinen hat dies möglicherweise keinen wesentlichen Einfluss darauf, wie der Datenverkehr empfangen und übertragen wird, jedoch ist es immer nützlich, die potenziellen Nuancen und Besonderheiten zu kennen, die „unter der Haube“ verborgen sind.

Datenverkehrsweiterleitung

Auf welcher Basis kann man entscheiden, in welchen Dienst der Datenverkehr geleitet wird? Normalerweise sind dies host und path, aber es gibt auch zusätzliche Möglichkeiten.

Namensraum innerhalb des Clusters

Ein Namensraum (namespace) ist die Möglichkeit, Ressourcen in Kubernetes logisch zu organisieren (zum Beispiel in stage, production usw.). Es gibt Ingress-Controller, die separat in jeden Namensraum installiert werden müssen (und dann kann er den Datenverkehr nur in die Pods dieses Namensraums lenken). Es gibt jedoch auch solche (und die sind eindeutig in der Mehrheit), die global für das gesamte Cluster arbeiten — in ihnen wird der Datenverkehr an jeden Pod im Cluster geleitet, unabhängig vom Namensraum.

Health Checks für Upstreams

Wie wird sichergestellt, dass der Datenverkehr an gesunde Instanzen von Anwendungen und Diensten geleitet wird? Es gibt Optionen mit aktiven und passiven Überprüfungen, Wiederholungen (retries), circuit breakers (mehr dazu siehe zum Beispiel in dem Artikel über Istio), eigenen Implementierungen von Statusprüfungen (custom health checks) usw. Ein äußerst wichtiger Parameter, wenn Sie hohe Anforderungen an die Verfügbarkeit und zum rechtzeitigen Ausschluss ausgefallener Dienste haben.

Lastenausgleichsalgorithmen

Hier gibt es viele Optionen: von traditionellen round-robin bis hin zu exotischen wie rdp-cookie, sowie separate Möglichkeiten wie Sticky Sessions.

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 mehrere Konturen für Entwickler (und/oder einfach geschlossene) verwendet werden, auf die über Ingress zugegriffen wird.

Verteilung des Datenverkehrs

Unterstützt der Controller gängige Mechanismen zur Verteilung des Datenverkehrs wie Canary-Deployments, A/B-Tests, Datenverkehrs-Mirroring (mirroring/shadowing)? Dies ist ein wirklich schwieriges Thema für Anwendungen, die präzise und sorgfältige Datenverkehrssteuerung für produktive Tests, Produktfehlerdebugging ohne Produktionsausfälle (oder mit minimalen Verlusten), Datenverkehrsanalyse usw. erfordern.

Bezahltes Abonnement

Gibt es eine kostenpflichtige Variante des Controllers mit erweiterten Funktionalitäten und/oder technischem Support?

Grafische Benutzeroberfläche (Web-UI)

Gibt es eine grafische Benutzeroberfläche zur Verwaltung der Controller-Konfiguration? Vor allem für die „Benutzerfreundlichkeit“ und/oder für diejenigen, die Änderungen an der Ingress-Konfiguration vornehmen müssen, während die Arbeit mit „rohen“ Vorlagen unangenehm ist. Könnte nützlich sein, wenn Entwickler in Echtzeit mit dem Verkehr experimentieren wollen.

JWT-Validierung

Vorhandensein einer integrierten Prüfung von JSON-Web-Token zur Autorisierung und Validierung von Benutzern im Endanwendung.

Anpassungsmöglichkeiten der Konfiguration

Erweiterbarkeit der Vorlagen hinsichtlich des Vorhandenseins von Mechanismen, die das Hinzufügen eigener Direktiven, Flags usw. zu den Standardkonfigurationsvorlagen ermöglichen.

Grundlegende DDoS-Schutzmechanismen

Einfache Rate-Limitierungsalgorithmen oder komplexere Varianten zur Filterung des Verkehrs basierend auf Adressen, White-Listen, Ländern usw.

Anforderungsverfolgung

Beobachtungs-, Überwachungs- und Debugging-Möglichkeiten für Anforderungen von Ingress zu bestimmten Diensten/Pods und idealerweise auch zwischen Diensten/Pods.

WAF

Bestellen Anwendungsfirewall.

Ingress-Controller

Die Liste der Controller wurde auf Basis von offiziellen Kubernetes-Dokumentation und dieser Tabelle. Einige von ihnen haben wir aus der Übersicht ausgeschlossen aufgrund ihrer Spezifität oder geringen Verbreitung (frühe Entwicklungsphase). Die verbleibenden werden nachfolgend behandelt. Wir beginnen mit einer allgemeinen Beschreibung der Lösungen und setzen die Zusammenfassung in einer Tabelle fort.

Ingress von Kubernetes

Website: github.com/kubernetes/ingress-nginx
Lizenz: Apache 2.0

Dies ist der offizielle Controller für Kubernetes, der von der Community entwickelt wird. Offensichtlich aus dem Namen, basiert er auf Nginx und wird durch eine Vielzahl von Lua-Plugins ergänzt, die zur Implementierung zusätzlicher Funktionen verwendet werden. Aufgrund der Popularität von Nginx und der minimalen Modifikationen, die bei der Verwendung als Controller vorgenommen werden, kann diese Variante die einfachste und verständlichste Konfiguration für einen durchschnittlichen Ingenieur (mit Web-Erfahrung) sein.

Ingress von NGINX Inc

Website: github.com/nginxinc/kubernetes-ingress
Lizenz: Apache 2.0

Offizielles Produkt der Nginx-Entwickler. Hat eine kostenpflichtige Version, die auf NGINX Plus. Die Hauptidee ist ein hohes Maß an Stabilität, ständige Abwärtskompatibilität, das Fehlen von Fremdmodulen und die angekündigte erhöhte Geschwindigkeit (im Vergleich zum offiziellen Controller), die durch den Verzicht auf Lua erreicht wurde.

Die kostenlose Version ist erheblich eingeschränkt, selbst im Vergleich zum offiziellen Controller (aufgrund des Fehlens der gleichen Lua-Module). Die kostenpflichtige Version bietet hingegen eine ziemlich breite zusätzliche Funktionalität: Echtzeit-Metriken, JWT-Validierung, aktive Health Checks und mehr. Ein wichtiges Vorteil gegenüber NGINX Ingress ist die vollständige Unterstützung von TCP/UDP-Verkehr (auch in der Community-Version!). Nachteil — das Fehlen von Funktionen zur Verkehrsverteilung, was jedoch „höchste Priorität für die Entwickler hat“, aber Zeit zur Umsetzung erfordert.

Kong Ingress

Website: github.com/Kong/kubernetes-ingress-controller
Lizenz: Apache 2.0

Ein Produkt, das von der Firma Kong Inc. in zwei Varianten entwickelt wird: kommerziell und kostenlos. Es basiert auf NGINX, dessen Möglichkeiten durch eine große Anzahl an Lua-Modulen erweitert werden.

Ursprünglich war es auf die Verarbeitung und das Routing von API-Anfragen, d.h. als API Gateway, ausgelegt, hat sich jedoch inzwischen zu einem vollwertigen Ingress-Controller entwickelt. Zu den Hauptvorteilen gehören zahlreiche zusätzliche Module (auch von Drittanbietern), die leicht installiert und konfiguriert werden können und mit denen ein breites Spektrum zusätzlicher Funktionen realisiert werden kann. Dennoch bieten die eingebauten Funktionen bereits viele Möglichkeiten. Die Konfiguration erfolgt über CRD-Ressourcen.

Ein wichtiges Merkmal des Produkts ist die Arbeit innerhalb eines einzelnen Kontexts (anstatt cross-namespaced), was ein strittiges Thema ist: Manche werden es als Nachteil empfinden (man muss Entitäten für jeden Kontext erstellen), während es für andere ein Feature ist (größere Isolation, da, wenn ein Controller ausfällt, das Problem nur auf einen einzigen Kontext beschränkt ist).ogithub.com/containous/traefik

Traefik

Website: github.com/containous/traefik
Lizenz: MIT

Ein Proxy, der ursprünglich für die Bearbeitung von Anfragen und das Routing für Microservices und deren dynamische Umgebung entwickelt wurde. Daher auch viele nützliche Funktionen: Konfigurationsupdates völlig ohne Neustarts, Unterstützung zahlreicher Lastverteilungsmethoden, Web-Interface, Durchreichen von Metriken, Unterstützung verschiedener Protokolle, REST API, Canary-Releases und vieles mehr. Ein angenehmer Aspekt ist auch die Unterstützung von Let’s Encrypt-Zertifikaten out of the box. Nachteil – für die Gewährleistung von hoher Verfügbarkeit (HA) muss der Controller ein eigenes KV-Speicher einrichten und verbinden.

HAProxy

Website: github.com/jcmoraisjr/haproxy-ingress
Lizenz: Apache 2.0

HAProxy ist seit langem als Proxy und Lastverteiler bekannt. Im Rahmen des Kubernetes-Clusters wird ein "sanftes" Konfigurationsupgrade (ohne Traffic-Verlust) angeboten, Service Discovery auf Basis von DNS, dynamische Konfiguration über API. Besonders attraktiv ist die vollständige Anpassung des Konfigurationsmusters durch Ersetzen der CM sowie die Möglichkeit, Funktionen aus der Sprig-Bibliothek zu nutzen. Insgesamt liegt der Hauptfokus der Lösung auf hoher Geschwindigkeit, Optimierung und Effizienz im Ressourcenverbrauch. Ein Vorteil des Controllers ist die Unterstützung einer Rekordzahl verschiedener Lastverteilungsverfahren.

Voyager

Website: github.com/appscode/voyager
Lizenz: Apache 2.0

Ein auf HAProxy basierender Controller, der als universelle Lösung positioniert ist und umfangreiche Funktionen auf einer Vielzahl von Anbietern unterstützt. Er bietet die Möglichkeit, den Traffic auf L7 und L4 zu balancieren, wobei die Balance von TCP L4-Traffic insgesamt als eines der Hauptmerkmale der Lösung bezeichnet werden kann.

Contour

Website: github.com/heptio/contour
Lizenz: Apache 2.0

Dieses Konzept basiert nicht nur auf Envoy: es wurde entwickelt gemeinsam von den Autoren dieses beliebten Proxys. Ein wichtiges Merkmal ist die Möglichkeit, die Verwaltung der Ingress-Ressourcen mithilfe von CRD-Ressourcen IngressRoute zu trennen. Für Organisationen mit zahlreichen Entwicklungsteams, die einen Cluster nutzen, hilft dies, den Umgang mit Traffic in benachbarten Containern maximal abzusichern und sie vor Fehlern bei der Änderung von Ingress-Ressourcen zu schützen.

Es wird auch ein erweitertes Set an Methoden zur Lastverteilung angeboten (einschließlich Anfragen-Spiegelung, automatische Wiederholungen, Ratenbegrenzung und vieles mehr), detaillierte Überwachung des Datenverkehrs und von Ausfällen. Für einige könnte das Fehlen der Unterstützung von Sticky Sessions ein wesentlicher Nachteil sein (obwohl bereits daran gearbeitet wird. Es werden bereits Arbeiten durchgeführt.).

Istio Ingress

Website: istio.io/docs/tasks/traffic-management/ingress
Lizenz: Apache 2.0

Eine umfassende Service-Mesh-Lösung, die nicht nur als Ingress-Controller fungiert, der den eingehenden Verkehr von außen verwaltet, sondern auch den gesamten Verkehr innerhalb des Clusters kontrolliert. 'Unter der Haube' wird Envoy als Sidecar-Proxy für jeden Dienst verwendet. Essenziell ist dies ein großes Kraftpaket, das 'alles kann', und seine Hauptidee besteht darin, maximalen Einfluss, Erweiterbarkeit, Sicherheit und Transparenz zu bieten. Mit seiner Hilfe können Sie die Datenverkehrsroute, den Zugriff zwischen den Diensten, die Lastverteilung, das Monitoring, Canary-Releases und vieles mehr bis ins kleinste Detail konfigurieren. Weitere Informationen zu Istio finden Sie in der Artikelreihe „Zurück zu Mikrodiensten mit Istio».

Ambassador

Website: github.com/datawire/ambassador
Lizenz: Apache 2.0

Eine weitere Lösung auf Basis von Envoy. Verfügbar in kostenlosen und kommerziellen Versionen. Positioniert sich als 'vollständig nativ für Kubernetes', was entsprechende Vorteile mit sich bringt (enge Integration mit den Methoden und Entitäten des K8s-Clusters).

Vergleichstabelle

Die Höhepunkt des Artikels ist diese riesige Tabelle:

Sie ist klickbar, um eine detailliertere Ansicht zu ermöglichen, und steht auch im Format Google Sheets.

Lassen Sie uns zusammenfassen

Ziel des Artikels ist es, ein umfassenderes Verständnis zu vermitteln (wenn auch nicht vollständig!), welche Wahl Sie in Ihrem speziellen Fall treffen sollten. Wie üblich hat jeder Controller seine Vor- und Nachteile...

Der klassische Ingress von Kubernetes überzeugt durch seine Verfügbarkeit und Verlässlichkeit sowie durch recht umfangreiche Funktionen – in den meisten Fällen sollte er „ausreichend sein“. Wenn jedoch höhere Anforderungen an Stabilität, Feature-Stufen und Entwicklung bestehen, ist es ratsam, sich Ingress mit NGINX Plus und einem kostenpflichtigen Abonnement anzusehen. Kong bietet eine sehr umfangreiche Sammlung von Plugins (und damit verbundenen Möglichkeiten), wobei in der kostenpflichtigen Version sogar noch mehr vorhanden sind. Er hat weitreichende Funktionen als API-Gateway, dynamische Konfiguration basierend auf CRD-Ressourcen sowie grundlegende Kubernetes-Dienste.

Bei höheren Anforderungen an das Lastenausgleich und die Autorisierungsmethoden sollten Sie sich Traefik und HAProxy genauer ansehen. Diese Open-Source-Projekte sind seit Jahren erprobt, sehr stabil und werden aktiv weiterentwickelt. Contour existiert seit einigen Jahren, wirkt aber immer noch zu jung und hat nur grundlegende Funktionen, die auf Envoy aufgebaut sind. Wenn es Anforderungen an das Vorhandensein/Integration eines WAF vor der Anwendung gibt, sollte man ebenfalls auf Ingress von Kubernetes oder HAProxy achten.

Die funktional reichhaltigsten Produkte basieren auf Envoy, insbesondere Istio. Es präsentiert sich als umfassende Lösung, die „alles kann“, was allerdings auch einen bedeutend höheren Konfigurations- und Administrationsaufwand im Vergleich zu anderen Lösungen bedeutet.

Wir haben als Standard-Controller den Ingress von Kubernetes ausgewählt, der weiterhin verwendet wird und 80–90 % der Anforderungen abdeckt. Er ist zuverlässig, einfach zu konfigurieren und zu erweitern. In den meisten Fällen sollte er ohne spezifische Anforderungen für die meisten Cluster/Anwendungen geeignet sein. Aus ähnlichen universellen und relativ einfachen Produkten können Traefik und HAProxy empfohlen werden.

P.S.

Lesen Sie auch in unserem Blog:

• Teil 1 (Eintreffen auf die grundlegenden Möglichkeiten) Teil 3 (Authentifizierung und Autorisierung), Teil 2 (Routing, Verkehrsmanagement), Conduit - ein leichtgewichtiger Service Mesh für Kubernetes;
• «Kubernetes Tipps & Tricks: personalisierte Fehlerseiten in NGINX Ingress»;
• «Kubernetes Tipps & Tricks: Zugang zu Entwicklungsplattformen».

Quelle: habr.com