Wanneer u een Kubernetes-cluster voor een specifieke toepassing start, moet u begrijpen wat de toepassing zelf, het bedrijf en de ontwikkelaars voor deze bron betekenen. Met deze informatie kunt u beginnen met het maken van een architectuurbeslissing en met name het kiezen van een specifieke Ingress-controller, waarvan er vandaag al een groot aantal zijn. Om een basisidee te krijgen van de beschikbare opties zonder veel artikelen/documentatie e.d. door te moeten spitten, hebben we dit overzicht opgesteld, inclusief de belangrijkste (productiegereede) Ingress-controllers.
We hopen dat het collega's zal helpen bij het kiezen van een architectonische oplossing - het zal in ieder geval een startpunt worden voor het verkrijgen van meer gedetailleerde informatie en praktische experimenten. Eerder hebben we andere soortgelijke materialen op internet bestudeerd en, vreemd genoeg, geen enkele min of meer volledige en vooral gestructureerde beoordeling gevonden. Dus laten we dat gat opvullen!
criteria
Om een vergelijking te maken en een bruikbaar resultaat te krijgen, moet u in principe niet alleen het vakgebied begrijpen, maar ook een specifieke lijst met criteria hebben die de onderzoeksvector bepalen. Zonder te pretenderen alle mogelijke gevallen van het gebruik van Ingress / Kubernetes te analyseren, hebben we geprobeerd de meest algemene vereisten voor controllers te benadrukken - wees erop voorbereid dat u in ieder geval al uw details en bijzonderheden afzonderlijk zult moeten bestuderen.
Maar ik zal beginnen met de kenmerken die zo vertrouwd zijn geworden dat ze in alle oplossingen worden geïmplementeerd en niet worden overwogen:
- dynamische ontdekking van services (service-ontdekking);
- SSL-beëindiging;
- werken met websockets.
Nu voor de punten van vergelijking:
Ondersteunde protocollen
Een van de fundamentele selectiecriteria. Uw software werkt mogelijk niet op standaard HTTP, of er moet mogelijk aan meerdere protocollen tegelijk worden gewerkt. Als uw geval niet-standaard is, houd dan rekening met deze factor, zodat u het cluster later niet opnieuw hoeft te configureren. Voor alle controllers varieert de lijst met ondersteunde protocollen.
programmatuur centraal
Er zijn verschillende variaties van toepassingen waarop de controller is gebaseerd. Populaire zijn nginx, traefik, haproxy, gezant. In het algemeen heeft het misschien niet veel invloed op de manier waarop verkeer wordt ontvangen en verzonden, maar het is altijd handig om de mogelijke nuances en kenmerken te kennen van wat zich "onder de motorkap" bevindt.
Verkeersroutering
Op basis waarvan kan een beslissing worden genomen over de verkeersrichting naar een bepaalde dienst? Meestal zijn dit host en pad, maar er zijn meer mogelijkheden.
Naamruimte binnen een cluster
Namespace (namespace) - de mogelijkheid om bronnen logisch te splitsen in Kubernetes (bijvoorbeeld op het podium, productie, etc.). Er zijn Ingress-controllers die afzonderlijk in elke naamruimte moeten worden geïnstalleerd (en dan kan het verkeer omleiden alleen naar de pods van deze ruimte). En er zijn er (en hun duidelijke meerderheid) die wereldwijd werken voor het hele cluster - daarin wordt het verkeer omgeleid naar elke pod van het cluster, ongeacht de naamruimte.
Monsters voor stroomopwaarts
Hoe wordt het verkeer omgeleid naar gezonde exemplaren van de toepassing, services? Er zijn opties met actieve en passieve controles, nieuwe pogingen, stroomonderbrekers (Zie voor meer details bijv. ), eigen implementaties van health checks (custom health checks), etc. Een zeer belangrijke parameter als u hoge eisen stelt aan beschikbaarheid en tijdige verwijdering van mislukte services uit balancering.
Balancerende algoritmen
Er zijn veel opties: van traditioneel naar het exotische , evenals individuele functies 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 ontwikkelaar (en/of alleen privé) loops zijn die toegankelijk zijn via Ingress.
Verkeersverdeling
Ondersteunt de controller veelgebruikte verkeersdistributiemechanismen als canary rollouts (canary), A/B-testen, traffic mirroring (mirroring/shadowing)? Dit is een heel pijnlijk onderwerp voor toepassingen die nauwkeurig en nauwkeurig verkeersbeheer vereisen voor productieve tests, het off-line debuggen van productbugs (of met minimaal verlies), verkeersanalyse, enzovoort.
Betaald abonnement
Is er een betaalde optie voor de controller, met geavanceerde functionaliteit en/of technische ondersteuning?
Grafische gebruikersinterface (Web UI)
Is er een GUI om de controllerconfiguratie te beheren? Voornamelijk voor "handigheid" en/of voor degenen die wat wijzigingen moeten aanbrengen aan de Ingress'a configuratie, maar het werken met "ruwe" sjablonen is onhandig. Het kan handig zijn als ontwikkelaars onderweg wat experimenten met verkeer willen uitvoeren.
JWT-validatie
De aanwezigheid van ingebouwde validatie van JSON-webtokens voor autorisatie en validatie van de gebruiker tot de eindtoepassing.
Mogelijkheden voor configuratieaanpassing
Sjabloonuitbreidbaarheid in de zin van mechanismen waarmee u uw eigen richtlijnen, vlaggen, enz. kunt toevoegen aan standaardconfiguratiesjablonen.
Basis DDOS-beveiligingsmechanismen
Eenvoudige snelheidslimietalgoritmen of complexere opties voor het filteren van verkeer op basis van adressen, witte lijsten, landen, enz.
Traceren aanvragen
De mogelijkheid om verzoeken van Ingresses naar specifieke services/pods te monitoren, te volgen en te debuggen, en idealiter ook tussen services/pods.
WAF
Ondersteunen .
Beheerders
De lijst met controllers is samengesteld op basis van и . We hebben enkele van hen uitgesloten van de beoordeling vanwege specificiteit of lage prevalentie (vroege ontwikkelingsfase). De rest wordt hieronder besproken. Laten we beginnen met een algemene beschrijving van de oplossingen en doorgaan met een overzichtstabel.
Inkomen vanuit Kubernetes
website:
Licentie: Apache 2.0
Dit is de officiële controller voor Kubernetes en wordt ontwikkeld door de community. Het is duidelijk uit de naam dat het gebaseerd is op nginx en wordt aangevuld met een andere set Lua-plug-ins die worden gebruikt om extra functies te implementeren. Vanwege de populariteit van nginx zelf en minimale aanpassingen eraan bij gebruik als controller, is deze optie misschien wel het gemakkelijkst en gemakkelijkst te configureren voor de gemiddelde ingenieur (met webervaring).
Ingress door NGINX Inc.
website:
Licentie: Apache 2.0
Het officiële product van de nginx-ontwikkelaars. Heeft een betaalde versie gebaseerd op . Het belangrijkste idee is een hoog niveau van stabiliteit, constante achterwaartse compatibiliteit, de afwezigheid van externe modules en de verklaarde verhoogde snelheid (vergeleken met de officiële controller), bereikt door de afwijzing van Lua.
De gratis versie is aanzienlijk gereduceerd, ook in vergelijking met de officiële controller (vanwege het ontbreken van dezelfde Lua-modules). Tegelijkertijd heeft de betaalde een vrij brede extra functionaliteit: real-time statistieken, JWT-validatie, actieve gezondheidscontroles en meer. Een belangrijk voordeel ten opzichte van NGINX Ingress is volledige ondersteuning voor TCP/UDP-verkeer (en ook in de community-versie!). min - verkeersdistributiefunctie, die echter "de hoogste prioriteit heeft voor ontwikkelaars", maar het kost tijd om te implementeren.
Kong ingang
website:
Licentie: Apache 2.0
Product ontwikkeld door Kong Inc. in twee versies: commercieel en gratis. Gebaseerd op nginx, dat is uitgebreid met een groot aantal Lua-modules.
Aanvankelijk was het gericht op het verwerken en routeren van API-verzoeken, d.w.z. als API Gateway, maar op dit moment is het een volwaardige Ingress-controller geworden. Belangrijkste voordelen: veel extra modules (ook die van externe ontwikkelaars) die eenvoudig te installeren en configureren zijn en waarmee een breed scala aan extra functies wordt geïmplementeerd. Ingebouwde functies bieden echter al veel mogelijkheden. Taakconfiguratie wordt uitgevoerd met behulp van CRD-bronnen.
Een belangrijk kenmerk van het product - werken binnen dezelfde contour (in plaats van cross-namespaced) is een controversieel onderwerp: voor sommigen zal het een nadeel lijken (je moet entiteiten produceren voor elke contour), en voor iemand is het een kenmerk ( BоHoger niveau van isolatie, zoals als een controller kapot is, is het probleem beperkt tot alleen het circuit).
Traefik
website:
Licentie: MIT
Een proxy die oorspronkelijk is gemaakt om te werken met aanvraagroutering voor microservices en hun dynamische omgeving. Vandaar veel handige functies: de configuratie bijwerken zonder opnieuw op te starten, ondersteuning voor een groot aantal balanceringsmethoden, webinterface, doorsturen van statistieken, ondersteuning voor verschillende protocollen, REST API, canary-releases en nog veel meer. Een andere leuke functie is ondersteuning voor Let's Encrypt-certificaten uit de doos. Het nadeel is dat om hoge beschikbaarheid (HA) te organiseren, de controller zijn eigen KV-opslag moet installeren en aansluiten.
HAProxy
website:
Licentie: Apache 2.0
HAProxy staat al lang bekend als een proxy en traffic balancer. Als onderdeel van een Kubernetes-cluster biedt het een "zachte" configuratie-update (zonder verlies van verkeer), servicedetectie op basis van DNS, dynamische configuratie met behulp van API. Het kan aantrekkelijk zijn om de configuratiesjabloon volledig aan te passen door de CM te vervangen, evenals de mogelijkheid om Sprig-bibliotheekfuncties erin te gebruiken. Over het algemeen ligt de nadruk van de oplossing op hoge snelheid, de optimalisatie ervan en efficiëntie in verbruikte bronnen. Het voordeel van de controller is de ondersteuning van een recordaantal verschillende balanceermethodes.
Reiziger
website:
Licentie: Apache 2.0
Gebaseerd op HAproxy-controller, die is gepositioneerd als een universele oplossing die een breed scala aan functies ondersteunt bij een groot aantal providers. Er wordt een mogelijkheid geboden om verkeer op L7 en L4 te balanceren, en het balanceren van TCP L4-verkeer als geheel kan een van de belangrijkste kenmerken van de oplossing worden genoemd.
Contour
website:
Licentie: Apache 2.0
Deze oplossing is niet alleen gebaseerd op Envoy: het is ontwikkeld door gezamenlijk met de auteurs van deze populaire proxy. Een belangrijk kenmerk is de mogelijkheid om het beheer van Ingress-resources te scheiden met behulp van IngressRoute CRD-resources. Voor organisaties met veel ontwikkelingsteams die hetzelfde cluster gebruiken, helpt dit om de veiligheid van het werken met verkeer in naburige loops te maximaliseren en hen te beschermen tegen fouten bij het wijzigen van Ingress-resources.
Het biedt ook een uitgebreide set balanceringsmethoden (er is spiegeling van verzoeken, automatische herhaling, beperking van de snelheid van verzoeken en nog veel meer), gedetailleerde monitoring van verkeersstroom en storingen. Misschien is het voor iemand een belangrijk nadeel dat er geen ondersteuning is voor plaksessies (hoewel het werk ).
Istio ingang
website:
Licentie: Apache 2.0
Een uitgebreide service mesh-oplossing die niet alleen een Ingress-controller is die inkomend verkeer van buitenaf beheert, maar ook al het verkeer binnen het cluster regelt. Onder de motorkap wordt Envoy gebruikt als zijspanproxy voor elke service. In wezen is dit een grote maaidorser die "alles kan", en het belangrijkste idee is maximale beheersbaarheid, uitbreidbaarheid, veiligheid en transparantie. Hiermee kunt u verkeersroutering, toegangsautorisatie tussen services, balanceren, monitoren, canary-releases en nog veel meer verfijnen. Lees meer over Istio in de artikelenreeks".
Ambassadeur
website:
Licentie: Apache 2.0
Een andere oplossing op basis van Envoy. Het heeft gratis en commerciële versies. Het is gepositioneerd als "volledig native to Kubernetes", wat de overeenkomstige voordelen met zich meebrengt (nauwe integratie met de methoden en entiteiten van het K8s-cluster).
vergelijkingstabel
Het hoogtepunt van het artikel is dus deze enorme tafel:
Het is klikbaar voor een beter zicht en is ook beschikbaar in het formaat .
Opsommen
Het doel van dit artikel is om een vollediger inzicht te geven (echter geenszins uitputtend!) van welke keuze u in uw specifieke geval moet maken. Zoals gewoonlijk heeft elke controller zijn eigen voor- en nadelen...
De klassieke Ingress van Kubernetes is goed vanwege zijn beschikbaarheid en betrouwbaarheid, rijk genoeg aan functies - in het algemeen zou het "genoeg voor de ogen" moeten zijn. Als er echter verhoogde vereisten zijn voor stabiliteit, het niveau van functies en ontwikkeling, moet u letten op Ingress met NGINX Plus en een betaald abonnement. Kong heeft de rijkste set plug-ins (en dus de mogelijkheden die ze bieden), en in de betaalde versie zijn er zelfs nog meer. Het heeft voldoende mogelijkheden om te werken als een API Gateway, dynamische configuratie op basis van CRD-resources, evenals basis Kubernetes-services.
Kijk eens naar Traefik en HAProxy met verhoogde vereisten voor balancerings- en autorisatiemethoden. Dit zijn Open Source-projecten, bewezen door de jaren heen, zeer stabiel en actief in ontwikkeling. Contour is nu al een paar jaar uit, maar het ziet er nog steeds te jong uit en heeft alleen basisfuncties bovenop Envoy toegevoegd. Als er vereisten zijn voor de aanwezigheid / inbedding van WAF voor de applicatie, moet u letten op dezelfde Ingress van Kubernetes of HAProxy.
En de rijkste qua functies zijn producten die bovenop Envoy zijn gebouwd, vooral Istio. Het lijkt een allesomvattende oplossing die "alles kan", wat echter ook een aanzienlijk hogere instapdrempel voor configuratie / lancering / beheer betekent dan andere oplossingen.
We hebben gekozen voor Ingress van Kubernetes en gebruiken dit nog steeds als standaardcontroller, die 80-90% van de behoeften dekt. Het is vrij betrouwbaar, eenvoudig te configureren en uit te breiden. Over het algemeen zou het, bij gebrek aan specifieke vereisten, geschikt moeten zijn voor de meeste clusters/toepassingen. Van dezelfde universele en relatief eenvoudige producten kunnen Traefik en HAProxy worden aanbevolen.
PS
Lees ook op onze blog:
- "Terug naar microservices met Istio": , , ;
- «";
- «.
Bron: www.habr.com