Bij het opzetten van een Kubernetes-cluster voor een specifieke applicatie is het belangrijk om te begrijpen welke vereisten de applicatie, het bedrijf en de ontwikkelaars aan deze resource stellen. Met deze informatie kan worden begonnen met het nemen van architecturale beslissingen, en in het bijzonder met de keuze van een specifieke Ingress-controller, waarvan er tegenwoordig al veel zijn. Om een basisbegrip te krijgen van de beschikbare opties zonder talloze artikelen/documentatie te hoeven doornemen, hebben we deze samenvatting opgesteld, waarin we de belangrijkste (production ready) Ingress-controllers hebben opgenomen.
We hopen dat het onze collega's helpt bij het maken van architecturale keuzes ā in ieder geval als een startpunt voor het verkrijgen van meer gedetailleerde informatie en praktische experimenten. We hebben voorafgaand andere vergelijkbare materialen op het web bestudeerd en, tot onze verbazing, geen enkele redelijk volledige, en vooral gestructureerde, overzichten gevonden. Laten we dus deze leemte vullen!
Criteria
Om Ć¼berhaupt een vergelijking te kunnen maken en een bruikbaar resultaat te behalen, moet men niet alleen de subjectieveé¢å begrijpen, maar ook over een concrete lijst van criteria beschikken die de onderzoeksrichting bepalen. Zonder pretenties te hebben voor het analyseren van alle mogelijke gevallen van gebruik van Ingress/Kubernetes, hebben we geprobeerd de meest algemene eisen aan controllers te benadrukken ā wees voorbereid dat al hun specifieke details in ieder geval apart bestudeerd moeten worden.
Ik begin echter met de kenmerken die zo gebruikelijk zijn dat ze in alle oplossingen zijn geĆÆmplementeerd en niet worden overwogen:
- dynamische service ontdekking (service discovery);
- SSL-terminatie;
- werken met websocket-verbindingen.
Laten we nu over de vergelijkingspunten spreken:
ondersteunde protocollen
Een van de fundamenten criteria voor uw keuze. Uw software kan niet volgens de standaard HTTP werken of vereist misschien ondersteuning voor meerdere protocollen tegelijkertijd. Als uw situatie niet standaard is, houd dan rekening met deze factor om te voorkomen dat het cluster later opnieuw moet worden geconfigureerd. Bij alle controllers varieert de lijst van ondersteunde protocollen.
Basissoftware
Er zijn verschillende soorten applicaties waarop de controller is gebaseerd. Populaire keuzes zijn nginx, traefik, haproxy, envoy. Over het algemeen beĆÆnvloedt dit misschien niet te veel hoe het verkeer wordt ontvangen en verzonden, maar het is altijd nuttig om potentiĆ«le nuances en kenmerken te kennen van wat er 'achter de schermen' gebeurt.
Verkeersroutering
Op basis waarvan kan een beslissing worden genomen over de richting van verkeer naar een bepaalde service? Meestal is dit host en pad, maar er kunnen ook aanvullende mogelijkheden zijn.
Naamruimte binnen het cluster
Een namespace is een mogelijkheid om middelen logisch te splitsen in Kubernetes (bijvoorbeeld op stage, productie, enz.). Er zijn Ingress-controllers die apart in elke namespace moeten worden geĆÆnstalleerd (en dan kan hij verkeer richting pods in deze namespace sturen). Er zijn echter ook controllers (en dat zijn er duidelijk de meeste) die globaal werken in het hele cluster ā in deze gevallen wordt verkeer gestuurd naar elke pod in het cluster, ongeacht de namespace. van pod's van die namespace). En er zijn controllers (en dat zijn er duidelijk de meeste) die globaal werken in het hele cluster ā hierin wordt verkeer gestuurd naar elke pod in het cluster, ongeacht de namespace.
Checks voor upstreams
Op welke manier wordt ervoor gezorgd dat verkeer naar gezonde instanties van applicaties en services wordt geleid? Er zijn opties met actieve en passieve controles, herhaalgpogingen (retries), circuit breakers (zie bijvoorbeeld meer over hen in de ), eigen implementaties van statuscontroles (custom health checks) enzovoort. Dit is een zeer belangrijke parameter als u hoge eisen stelt aan beschikbaarheid en tijdige uitschakeling van falende services.
Load-balancing algoritmes
Er zijn veel opties: van traditionele tot exotische zoals , evenals aparte mogelijkheden zoals .
Authenticatie
Welke autorisatieschema's ondersteunt de controller? Basic, digest, oauth, external-auth ā ik denk dat deze opties bekend moeten zijn. Dit is een belangrijk criterium als er veel omgevingen voor ontwikkelaars (en/of gewoon gesloten omgevingen) worden gebruikt, waarvoor toegang via Ingress wordt verkregen.
Verkeersverdeling
Ondersteunt de controller vaak gebruikte mechanismen voor verkeersverdeling, zoals canary releases, A/B-testen, en verkeersspiegeling (mirroring/shadowing)? Dit is een echt pijnlijk onderwerp voor applicaties die nauwkeurige en zorgvuldige verkeersbeheersing vereisen voor producttests, foutopsporing zonder impact (of met minimale verliezen), verkeersanalyse enzovoort.
Betaald abonnement
Is there a paid version of the controller with extended functionalities and/or technical support?
Graphical Interface (Web UI)
Is there any graphical interface for managing the controller's configuration? Mainly for convenience and/or for those who need to make changes to the Ingress configuration but find working with raw templates inconvenient. It might be useful if developers want to conduct experiments with traffic on the fly.
JWT Validation
The presence of built-in checks for JSON web tokens for authorizing and validating users for the end application.
Customization Options for Configuration
Extensibility of templates in terms of having mechanisms that allow adding custom directives, flags, etc., to standard configuration templates.
Basic DDOS Protection Mechanisms
Simple rate-limiting algorithms or more complex variants for filtering traffic based on addresses, whitelists, countries, etc.
Request Tracing
The ability to monitor, trace, and debug requests from Ingress controllers to specific services/pods, and ideally ā also between services/pods.
WAF
Ondersteuning .
Ingress Controllers
The list of controllers was compiled based on en . Some of them were excluded from the review due to their specificity or low prevalence (early development stage). The remaining ones are discussed below. We'll start with a general description of the solutions and continue with a summary table.
Ingress from Kubernetes
Website:
Licentie: Apache 2.0
This is the official controller for Kubernetes, developed by the community. As the name suggests, it is based on nginx and supplemented with various Lua plugins used to implement additional functionalities. Due to the popularity of nginx itself and minimal modifications made when used as a controller, this option may be the simplest and most understandable in terms of configuration for an average engineer (with web experience).
Ingress from NGINX Inc
Website:
Licentie: Apache 2.0
The official product from the developers of nginx. It has a paid version based on . Het belangrijkste idee is een hoog niveau van stabiliteit, constante achterwaartse compatibiliteit, het ontbreken van externe modules en een geclaimde verhoogde snelheid (in vergelijking met de officiƫle controller), bereikt door het afzien van Lua.
De gratis versie is sterk beperkt, zelfs in vergelijking met de officiƫle controller (door het gebrek aan dezelfde Lua-modules). De betaalde versie biedt daarentegen een vrij brede extra functionaliteit: realtime metrics, JWT-validatie, actieve health checks en meer. Een belangrijk voordeel ten opzichte van NGINX Ingress is de volledige ondersteuning voor TCP/UDP-verkeer (ook in de community-versie!). Nadelen zijn functies voor verkeersverspreiding, wat echter 'maximale prioriteit heeft voor ontwikkelaars', maar tijd kost om te implementeren.
Kong Ingress
Website:
Licentie: Apache 2.0
Een product ontwikkeld door Kong Inc. in twee varianten: commercieel en gratis. Gebaseerd op nginx, wiens mogelijkheden zijn uitgebreid met een groot aantal Lua-modules.
Oorspronkelijk gericht op het verwerken en routeren van API-aanvragen, dus als API Gateway, is het inmiddels uitgegroeid tot een volwaardige Ingress-controller. Belangrijkste voordelen: vele extra modules (ook van externe ontwikkelaars), die gemakkelijk te installeren en configureren zijn en waarmee een breed scala aan extra mogelijkheden kan worden gerealiseerd. Echter, ingebouwde functies bieden al veel mogelijkheden. De configuratie gebeurt via CRD-resources.
Een belangrijke eigenschap van het product is dat werken binnen ƩƩn contour (in plaats van cross-namespaced) een omstreden onderwerp is: sommigen beschouwen het als een tekortkoming (je moet entiteiten creƫren voor elke contour), terwijl anderen het als een functie beschouwen (een groter niveau van isolatie, aangezien als ƩƩn controller defect is, het probleem beperkt blijft tot slechts ƩƩn contour).groter publiek.hogere mate van isolatie, omdat als ƩƩn controller faalt, het probleem beperkt is tot slechts ƩƩn contour).
Traefik
Website:
Licentie: MIT
Een proxy die oorspronkelijk is ontworpen voor het beheer van verzoekroutering in microservices en hun dynamische omgeving. Dit resulteert in vele nuttige mogelijkheden: het bijwerken van de configuratie zonder herstart, ondersteuning voor een groot aantal load balancing methoden, een webinterface, metrics forwarding, ondersteuning voor verschillende protocollen, een REST API, canary releases en nog veel meer. Een aangenaam kenmerk is ook de ondersteuning voor Letās Encrypt-certificaten out-of-the-box. Een nadeel is dat voor het organiseren van hoge beschikbaarheid (HA) de controller een eigen KV-opslag moet installeren en aansluiten.
HAProxy
Website:
Licentie: Apache 2.0
HAProxy is al lange tijd bekend als proxy en traffic balancer. Binnen een Kubernetes-cluster biedt het "zachte" configuratie-updates (zonder verkeersverlies), service discovery op basis van DNS en dynamische configuratie via API. Een aantrekkelijke eigenschap is de volledige aanpassing van sjablonen door gebruik te maken van de CM, evenals de mogelijkheden om functies van de Sprig-bibliotheek te gebruiken. Over het algemeen ligt de focus van de oplossing op hoge snelheid, optimale prestaties en efficiƫntie in het gebruik van bronnen. Een voordeel van de controller is de ondersteuning voor een record aantal verschillende load balancing methoden.
Voyager
Website:
Licentie: Apache 2.0
Een op HAproxy gebaseerde controller die wordt gepositioneerd als een universele oplossing, die brede mogelijkheden ondersteunt op een groot aantal providers. Er is de mogelijkheid voor traffic balancing op L7 en L4, waarbij de load balancing van TCP L4-verkeer over het algemeen kan worden beschouwd als een van de belangrijkste functies van de oplossing.
Contour
Website:
Licentie: Apache 2.0
Deze oplossing is niet alleen gebaseerd op Envoy: het is ontwikkeld in samenwerking met de auteurs van deze populaire proxy. Een belangrijk kenmerk is de mogelijkheid om het beheer van Ingress-resources te scheiden met behulp van CRD-resources IngressRoute. Voor organisaties met meerdere ontwikkelteams die Ć©Ć©n cluster gebruiken, helpt dit om de werking met verkeer in aangrenzende omgevingen tot een minimum te beperken en te beschermen tegen fouten bij het wijzigen van Ingress-resources.
Er wordt ook een uitgebreid scala aan balancing-methoden aangeboden (inclusief request mirroring, automatische herhalingen, rate limiting van verzoeken en nog veel meer), gedetailleerde monitoring van verkeersstromen en storingen. Voor sommigen kan het ontbreken van ondersteuning voor sticky sessions een aanzienlijke tekortkoming zijn (hoewel er al werkzaamheden aan de gang zijn) ).
Istio Ingress
Website:
Licentie: Apache 2.0
Een allesomvattende service mesh-oplossing die niet alleen dienstdoet als Ingress-controller om binnenkomend extern verkeer te regelen, maar ook al het verkeer binnen het cluster beheert. āOnder de motorkapā wordt Envoy gebruikt als sidecar-proxy voor elke service. Eigenlijk is het een grote combinatie die āalles kanā, en het belangrijkste idee is maximale beheersbaarheid, uitbreidbaarheid, veiligheid en transparantie. Hiermee kunt u verkeerrouting, toegangsautorisatie tussen diensten, load balancing, monitoring, canary-releases en nog veel meer gedetailleerd instellen. Meer over Istio leest u in de serie artikelen āĀ».
Ambassador
Website:
Licentie: Apache 2.0
Een andere oplossing gebaseerd op Envoy. Heeft gratis en commerciĆ«le versies. Wordt gepositioneerd als āvolledig native voor Kubernetesā, wat de bijbehorende voordelen met zich meebrengt (nauwkeurige integratie met de methoden en entiteiten van het K8s-cluster).
Vergelijkende tabel
Dus, de climax van het artikel ā deze enorme tabel:
Deze is klikbaar voor een gedetailleerdere weergave en ook beschikbaar in het formaat .
Laten we de conclusies samenvatten
Het doel van het artikel is om een completer begrip te bieden (hoewel absoluut niet uitputtend!) van welke keuze u moet maken in uw specifieke geval. Zoals gewoonlijk heeft elke controller zijn eigen voor- en nadelen...
De klassieke Ingress van Kubernetes is goed vanwege zijn beschikbaarheid en betrouwbaarheid, met relatief rijke mogelijkheden ā in het algemeen zou het 'voldoende moeten zijn'. Echter, als er hogere eisen zijn aan stabiliteit, niveau van functies en ontwikkeling, is het de moeite waard om naar Ingress met NGINX Plus en een betaald abonnement te kijken. Kong heeft een rijke set aan plugins (en de bijbehorende mogelijkheden), en in de betaalde versie zijn er zelfs meer. Het biedt uitgebreide mogelijkheden als API Gateway, dynamische configuratie op basis van CRD-resources en basisservices van Kubernetes.
Als er hogere eisen zijn aan load balancing en autorisatiemethoden, overweeg dan Traefik en HAProxy. Dit zijn Open Source-projecten, die door de jaren heen zijn getest, zeer stabiel en actief in ontwikkeling. Contour bestaat al een paar jaar, maar ziet er nog steeds te jong uit en heeft slechts basisfunctionaliteiten die bovenop Envoy zijn toegevoegd. Als er eisen zijn voor de aanwezigheid/integratie van WAF vĆ³Ć³r de toepassing, is het de moeite waard om dezelfde Ingress van Kubernetes of HAProxy te overwegen.
De producten die de meeste functies bieden, zijn die gebaseerd op Envoy, vooral Istio. Het wordt gepresenteerd als een uitgebreide oplossing die 'alles kan', wat echter ook betekent dat er een aanzienlijk hogere leercurve is voor configuratie/opstarten/beheer dan bij andere oplossingen.
Wij hebben gekozen voor en gebruiken nog steeds Ingress van Kubernetes als standaardcontroller, die 80-90% van de behoeften dekt. Het is behoorlijk betrouwbaar, gemakkelijk te configureren en uitbreidbaar. In het algemeen, bij gebrek aan specifieke eisen, zou het geschikt moeten zijn voor de meeste clusters/toepassingen. Van dergelijke universele en relatief eenvoudige producten kunnen Traefik en HAProxy worden aanbevolen.
P.S.
Lees ook op onze blog:
- Ā«Terug naar microservices met IstioĀ»: , , ;
- Ā«Ā»;
- Ā«Ā».
Bron: habr.com
