Beim Start eines Kubernetes-Clusters für eine spezifische Anwendung ist es wichtig, die Anforderungen zu verstehen, die die Anwendung sowie das Geschäft und die Entwickler an diese Ressource stellen. Mit diesen Informationen kann man mit der architektonischen Entscheidung beginnen und insbesondere den passenden Ingress-Controller auswählen, von denen es mittlerweile eine Vielzahl gibt. Um einen grundlegenden Überblick über die verfügbaren Optionen zu erhalten, ohne zahlreiche Artikel/Dokumentationen und Ähnliches durchforsten zu müssen, haben wir diesen Überblick erstellt, der die wichtigsten (produktionsbereiten) Ingress-Controller umfasst.
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. Zuvor haben wir ähnliche Materialien im Netz untersucht und erstaunlicherweise kein einziges umfassendes und vor allem strukturiertes Review gefunden. Lassen Sie uns also diese Lücke schließen!
Kriterien
Um überhaupt einen sinnvollen Vergleich anstellen zu können, ist es wichtig, nicht nur das Fachgebiet zu verstehen, sondern auch eine spezifische Liste von Kriterien zu haben, die die Richtung der Untersuchung vorgeben. Ohne den Anspruch, alle möglichen Anwendungsfälle von Ingress/Kubernetes zu analysieren, haben wir versucht, die wichtigsten Anforderungen an die Controller herauszustellen — seien Sie darauf vorbereitet, dass Sie alle spezifischen Besonderheiten in jedem Fall separat untersuchen müssen.
Ich beginne jedoch mit Merkmalen, die so vertraut geworden sind, dass sie in allen Lösungen implementiert werden und daher nicht in Betracht gezogen werden:
- dynamisches Service-Discovery;
- SSL-Terminierung;
- Arbeiten mit WebSockets.
Nun zu den Vergleichspunkten:
Unterstützte Protokolle
Eines der grundlegendsten Kriterien für die Auswahl. Ihre Software könnte nicht im Standard-HTTP arbeiten oder die gleichzeitige Verarbeitung mehrerer Protokolle erfordern. Wenn Ihr Fall nicht standardisiert ist, sollten Sie diesen Faktor unbedingt berücksichtigen, damit Sie das Cluster später nicht neu konfigurieren müssen. Bei allen Controllern variiert die Liste der unterstützten Protokolle.
Software im Hintergrund
Es gibt mehrere Arten von Anwendungen, auf denen der Controller basiert. Zu den beliebtesten gehören nginx, traefik, haproxy und envoy. Im Allgemeinen hat dies möglicherweise keinen großen Einfluss darauf, wie der Datenverkehr empfangen und übertragen wird, aber es ist immer nützlich, die potenziellen Nuancen und Besonderheiten des „Unter der Haube“ zu kennen.
Traffic-Routing
Worauf kann man basierend entscheiden, wohin der Datenverkehr in einen bestimmten Service geleitet wird? Normalerweise sind das Host und Pfad, aber es gibt auch zusätzliche Möglichkeiten.
Namespace innerhalb des Clusters
Ein Namespace bietet die Möglichkeit, Ressourcen in Kubernetes logisch zu gliedern (zum Beispiel in Stage, Produktion usw.). Es gibt Ingress-Controller, die separat in jedem Namespace installiert werden müssen (und dann den Verkehr nur in die Pods dieses Namespace leiten können). Es gibt jedoch auch solche (und das sind eindeutig die meisten), die global für das gesamte Cluster arbeiten – hierbei wird der Verkehr in jeden Pod des Clusters geleitet, unabhängig vom Namespace.
Health Checks für Upstreams
Wie wird sichergestellt, dass der Verkehr an gesunde Instanzen von Anwendungen oder Diensten weitergeleitet wird? Es gibt Optionen mit aktiven und passiven Prüfungen, erneuten Versuchen (Retries) und Circuit Breakers. (weitere Informationen finden Sie beispielsweise in ), eigene Implementierungen von Gesundheitsprüfungen (custom health checks) usw. Dies ist ein sehr wichtiger Parameter, wenn Sie hohe Anforderungen an die Verfügbarkeit und an das zeitnahe Herausnehmen ausgefallener Dienste aus der Lastverteilung haben.
Lastverteilungsalgorithmen
Es gibt viele Optionen: von traditionellen bis hin zu exotischen wie , sowie spezielle Optionen wie .
Authentifizierung
Welche Authentifizierungsschemata unterstützt der Controller? Basic, Digest, OAuth, External-Auth – ich denke, diese Optionen sollten vertraut sein. Dies ist ein wichtiges Kriterium, wenn viele Kanäle für Entwickler (und/oder einfach geschützte) verwendet werden, auf die über Ingress zugegriffen wird.
Trafficverteilung
Unterstützt der Controller gängige Mechanismen zur Trafficverteilung, wie Canary-Deployments, A/B-Tests, Traffic-Mirroring/Shadowing? Dies ist ein wirklich sensibles Thema für Anwendungen, die eine sorgfältige und präzise Steuerung des Traffics für produktives Testen, das Debuggen von Produkfehlern ohne Ausfall (oder mit minimalen Verlusten), Traffic-Analyse usw. benötigen.
Bezahltes Abonnement
Gibt es eine kostenpflichtige Version des Controllers mit erweiterten Funktionen und/oder technischer Unterstützung?
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öchten, aber mit 'rohen' Vorlagen nicht zurechtkommen. Dies könnte nützlich sein, wenn Entwickler Experimente mit dem Datenverkehr durchführen wollen.
JWT-Validierung
Vorhandensein einer integrierten Überprüfung von JSON-Web-Token zur Autorisierung und Validierung von Benutzern in der Anwendung.
Anpassungsmöglichkeiten des Konfigs
Erweiterbarkeit der Vorlagen hinsichtlich der Verfügbarkeit von Mechanismen, die es ermöglichen, eigene Direktiven, Flags usw. in die Standardkonfigurationsvorlagen einzufügen.
Grundlegende Schutzmechanismen gegen DDoS
Einfache Rate-Limit-Algorithmen oder komplexere Varianten zur Filterung von Datenverkehr basierend auf Adressen, Whitelists, Ländern usw.
Anfragenverfolgung
Überwachungs-, Verfolgungs- und Debuggingmöglichkeiten von Anfragen von Ingress zu bestimmten Services/Pods und idealerweise auch zwischen den Services/Pods.
WAF
Support .
Ingress-Controller
Die Liste der Controller wurde basierend auf und . Einige von ihnen haben wir aufgrund ihrer Spezifität oder geringen Verbreitung (frühe Entwicklungsphase) aus der Übersicht ausgeschlossen. Die verbleibenden werden im Folgenden betrachtet. Wir beginnen mit einer allgemeinen Beschreibung der Lösungen und fahren mit einer zusammenfassenden Tabelle fort.
Ingress von Kubernetes
Website:
Lizenz: Apache 2.0
Dies ist der offizielle Controller für Kubernetes, der von der Community entwickelt wird. Offensichtlich basierend auf nginx, ist er um eine Vielzahl von Lua-Plugins ergänzt, die zur Implementierung zusätzlicher Funktionen verwendet werden. Dank der Popularität von nginx und der minimalen Modifikationen bei seiner Verwendung als Controller kann diese Option die einfachste und verständlichste для einen durchschnittlichen Ingenieur (mit Erfahrung im Web) sein.
Ingress von NGINX Inc
Website:
Lizenz: Apache 2.0
Ein offizielles Produkt der nginx-Entwickler. Es gibt eine kostenpflichtige Version, die auf . Die Hauptidee ist ein hohes Maß an Stabilität, ständige Abwärtskompatibilität, das Fehlen jeglicher externen Module und die angegebene höhere Geschwindigkeit (im Vergleich zum offiziellen Controller), erreicht durch den Verzicht auf Lua.
Die kostenlose Version ist stark eingeschränkt, selbst im Vergleich zum offiziellen Controller (aufgrund des Fehlens derselben Lua-Module). Die kostenpflichtige Version bietet hingegen eine recht umfangreiche zusätzliche Funktionalität: Echtzeitmetriken, JWT-Validierung, aktive Health Checks und mehr. Ein wichtiges Plus gegenüber NGINX Ingress ist die vollständige Unterstützung für TCP/UDP-Verkehr (auch in der Community-Version!). Nachteil ist die begrenzte Funktionalität zur Lastverteilung, was jedoch 'oberste Priorität für die Entwickler hat', jedoch Zeit für die Implementierung benötigt.
Kong Ingress
Website:
Lizenz: Apache 2.0
Ein Produkt, das von der Firma Kong Inc. in zwei Varianten entwickelt wird: kommerziell und kostenlos. Basierend auf Nginx, dessen Möglichkeiten durch eine Vielzahl von Lua-Modulen erweitert werden.
Ursprünglich war es auf die Verarbeitung und Weiterleitung von API-Anfragen ausgerichtet, also als API-Gateway, hat sich jedoch mittlerweile zu einem vollwertigen Ingress-Controller entwickelt. Zu den Hauptvorteilen gehören zahlreiche zusätzliche Module (auch von Drittanbietern), die sich leicht installieren und konfigurieren lassen und mit denen eine breite Palette an zusätzlichen Funktionen realisiert werden kann. Dennoch bieten die integrierten Funktionen bereits viele Möglichkeiten.
Ein wichtiges Merkmal des Produkts ist die Funktionsweise innerhalb eines einzelnen Kontextes (anstatt cross-namespaced), was ein umstrittenes Thema darstellt: Für einige ist es ein Nachteil (man muss Entities für jeden Kontext schaffen), für andere ist es eine nützliche Funktion (höhere Isolationsstufe, da, wenn ein Controller ausfällt, das Problem auf nur einen Kontext beschränkt ist).größtenTraefik
github.com/containous/traefik
Website:
Lizenz: MIT
Ein Proxy, der ursprünglich für die Anfragenweiterleitung in Mikrodiensten und deren dynamischer Umgebung entwickelt wurde. Dies bringt eine Vielzahl nützlicher Funktionen mit sich: Konfigurationsupdates ohne Neustarts, Unterstützung für zahlreiche Lastverteilungs-Methoden, eine Weboberfläche, Metriken-Transparenz, Unterstützung verschiedener Protokolle, REST API, Canary Releases und vieles mehr. Ein weiterer Vorteil ist die native Unterstützung von Let's Encrypt-Zertifikaten. Ein Nachteil ist, dass zur Gewährleistung hoher Verfügbarkeit (HA) ein eigenes KV-Speicher eingerichtet und angeschlossen werden muss.
HAProxy
Website:
Lizenz: Apache 2.0
HAProxy ist seit langem als Proxy und Lastenausgleich bekannt. Innerhalb eines Kubernetes-Clusters bietet es ein "sanftes" Update der Konfiguration (ohne Verkehrsverlust), DNS-basierte Service-Discovery und dynamische Konfiguration über die API. Die vollständige Anpassbarkeit der Konfigurationsvorlagen durch die Ersetzung des CM sowie die Nutzung der Funktionen der Sprig-Bibliothek sind ebenfalls attraktiv. Insgesamt liegt der Hauptfokus der Lösung auf hoher Arbeitsgeschwindigkeit, Optimierung und Ressourceneffizienz. Ein Vorteil des Controllers ist die Unterstützung einer rekordverdächtigen Anzahl verschiedener Lastenausgleichsverfahren.
Voyager
Website:
Lizenz: Apache 2.0
Ein auf HAProxy basierender Controller, der als universelle Lösung positioniert wird und umfangreiche Möglichkeiten bei einer Vielzahl von Anbietern unterstützt. Es wird die Möglichkeit geboten, den Datenverkehr auf L7 und L4 auszugleichen, wobei der TCP L4-Datenverkehr insgesamt als eine der Hauptfunktionen der Lösung bezeichnet werden kann.
Contour
Website:
Lizenz: Apache 2.0
Dieses Konzept basiert nicht nur auf Envoy: Es wurde gemeinsam entwickelt mit den Entwicklern dieses beliebten Proxys. Eine wichtige Funktion ist die Möglichkeit, das Management der Ingress-Ressourcen mithilfe von CRD-Ressourcen IngressRoute zu teilen. Für Organisationen mit vielen Entwicklungsteams, die denselben Cluster nutzen, hilft dies, den Datenverkehr in benachbarten Umgebungen maximal abzusichern und sie vor Fehlern bei der Änderung der Ingress-Ressourcen zu schützen.
Es wird auch ein erweitertes Set an Balancierungsmethoden angeboten (einschließlich Anfragen-Spiegelung, automatische Wiederholungen, Limitierung der Anfrage-Rate und vieles mehr), detailliertes Monitoring des Datenverkehrs und von Ausfällen. Vielleicht wird das Fehlen von Sticky Sessions für einige ein wesentlicher Nachteil sein (obwohl die Arbeiten daran ).
Istio Ingress
Website:
Lizenz: Apache 2.0
Eine umfassende Service-Mesh-Lösung, die nicht nur als Ingress-Controller fungiert, der den eingehenden Datenverkehr von außen verwaltet, sondern auch den gesamten Datenverkehr innerhalb des Clusters kontrolliert. ‘Unter der Haube’ wird Envoy als Sidecar-Proxy für jeden Dienst verwendet. Im Grunde genommen handelt es sich um eine große Kombination, die ‘alles kann’, wobei der Hauptgedanke maximale Steuerbarkeit, Erweiterbarkeit, Sicherheit und Transparenz ist. Mit seiner Hilfe können Sie die Verkehrsrouting, die Zugriffautorisierung zwischen den Diensten, Lastverteilung, Überwachung, Canary-Releases und vieles mehr im Detail anpassen. Weitere Informationen über Istio finden Sie in einer Reihe von Artikeln.».
Ambassador
Website:
Lizenz: Apache 2.0
Eine weitere Lösung, die auf Envoy basiert. Sie bietet sowohl kostenlose als auch kommerzielle Versionen und wird als ‘vollständig identisch mit Kubernetes’ positioniert, was entsprechende Vorteile mit sich bringt (enge Integration mit den Methoden und Entitäten des K8s-Clusters).
Vergleichstabelle
Die Kulmination des Artikels ist diese umfangreiche Tabelle:
Sie ist klickbar, um eine detailliertere Ansicht zu ermöglichen, und auch im Format .
Zusammenfassend
Das Ziel dieses Artikels ist es, ein umfassenderes Verständnis dafür zu bieten, welche Wahl in Ihrem speziellen Fall getroffen werden sollte. Wie so oft hat jeder Controller seine eigenen Vorzüge und Nachteile...
Der klassische Ingress von Kubernetes überzeugt durch seine Verfügbarkeit und Zuverlässigkeit sowie durch ein reichhaltiges Funktionsspektrum — im Regelfall sollte er vollkommen ausreichend sein. Wenn jedoch höhere Anforderungen an Stabilität, Feature-Level und Entwicklung gestellt werden, lohnt es sich, Ingress mit NGINX Plus und einem kostenpflichtigen Abonnement in Betracht zu ziehen. Kong bietet eine Vielzahl an Plugins (und somit an Funktionen), wobei in der kostenpflichtigen Version sogar noch mehr zur Verfügung stehen. Zudem bietet es umfassende Möglichkeiten, als API Gateway zu fungieren, dynamische Konfigurationen auf der Basis von CRD-Ressourcen durchzuführen und grundlegende Kubernetes-Dienste anzubieten.
Wenn Sie hohe Anforderungen an das Load Balancing und die Autorisierungsmethoden haben, sollten Sie sich Traefik und HAProxy ansehen. Diese Open Source-Projekte sind jahrzehntelang erprobt, äußerst stabil und entwickeln sich aktiv weiter. Contour ist seit ein paar Jahren auf dem Markt, wirkt jedoch noch ziemlich jung und bietet nur grundlegende Funktionen, die auf Envoy aufgebaut sind. Wenn es Anforderungen an das Vorhandensein/Einschließen eines WAF vor der Anwendung gibt, sollten Sie auch das Ingress von Kubernetes oder HAProxy in Betracht ziehen.
Die funktional reichhaltigsten Produkte sind die, die auf Envoy basieren, insbesondere Istio. Es stellt eine umfassende Lösung dar, die „alles kann“, was jedoch auch bedeutet, dass der Einstieg hinsichtlich Konfiguration/Start/Administration deutlich komplexer ist als bei anderen Lösungen.
Wir haben als Standard-Controller Ingress von Kubernetes ausgewählt, der nach wie vor verwendet wird und etwa 80–90 % der Anforderungen abdeckt. Er ist zuverlässig, einfach zu konfigurieren und skalierbar. Im Allgemeinen sollte er den meisten Clustern/Aus Anwendungen genügen, wenn keine spezifischen Anforderungen bestehen. Als weitere universelle und relativ einfache Produkte können Traefik und HAProxy empfohlen werden.
P.S.
Lesen Sie auch in unserem Blog:
- „Zurück zu Microservices mit Istio“: , , ;
- «»;
- «».
Quelle: habr.com
