Når du starter en Kubernetes-klynge til en specifik applikation, skal du forstå, hvad applikationen selv, virksomheden og udviklerne stiller til denne ressource. Med disse oplysninger kan du begynde at tage en arkitektonisk beslutning og i særdeleshed vælge en specifik Ingress-controller, som der allerede er et stort antal af i dag. For at få en grundlæggende idé om de tilgængelige muligheder uden at skulle gennemgå en masse artikler/dokumentation osv., har vi udarbejdet denne oversigt, inklusive de vigtigste (produktionsklare) Ingress-controllere.
Vi håber, at det vil hjælpe kollegerne med at vælge en arkitektonisk løsning – i det mindste bliver det et udgangspunkt for at indhente mere detaljerede oplysninger og praktiske eksperimenter. Tidligere undersøgte vi andre lignende materialer på nettet og fandt mærkeligt nok ikke en eneste mere eller mindre komplet og vigtigst af alt - struktureret - anmeldelse. Så lad os udfylde det hul!
kriterier
I princippet, for at foretage en sammenligning og få et brugbart resultat, skal du ikke kun forstå emneområdet, men også have en specifik liste over kriterier, der vil sætte forskningsvektoren. Uden at foregive at analysere alle mulige tilfælde af brug af Ingress / Kubernetes, forsøgte vi at fremhæve de mest generelle krav til controllere - vær forberedt på, at du under alle omstændigheder bliver nødt til at studere alle dine detaljer og detaljer separat.
Men jeg starter med de egenskaber, der er blevet så velkendte, at de er implementeret i alle løsninger og ikke tages i betragtning:
- dynamisk opdagelse af tjenester (serviceopdagelse);
- SSL opsigelse;
- arbejder med websockets.
Nu til sammenligningspunkterne:
Understøttede protokoller
Et af de grundlæggende udvælgelseskriterier. Din software virker muligvis ikke på standard HTTP, eller den kan kræve arbejde på flere protokoller på én gang. Hvis dit tilfælde ikke er standard, skal du sørge for at tage denne faktor i betragtning, så du ikke behøver at omkonfigurere klyngen senere. For alle controllere varierer listen over understøttede protokoller.
software i kernen
Der er flere variationer af applikationer, som controlleren er baseret på. Populære er nginx, traefik, haproxy, envoy. I det generelle tilfælde har det måske ikke meget effekt på, hvordan trafik modtages og transmitteres, men det er altid nyttigt at kende de potentielle nuancer og funktioner i det, der er "under motorhjelmen".
Trafikdirigering
På baggrund af hvad er det muligt at træffe en beslutning om retningen af trafikken til en bestemt tjeneste? Normalt er disse vært og sti, men der er yderligere muligheder.
Navneområde i en klynge
Navneområde (navneområde) - evnen til logisk at opdele ressourcer i Kubernetes (for eksempel på scenen, i produktionen osv.). Der er Ingress-controllere, der skal installeres separat i hvert navneområde (og så kan det dirigere trafik kun til bælgerne i dette rum). Og der er dem (og deres klare flertal), der arbejder globalt for hele klyngen - i dem ledes trafikken til en hvilken som helst pod i klyngen, uanset navneområdet.
Prøver til opstrøms
Hvordan ledes trafik til sunde forekomster af applikationen, tjenesterne? Der er muligheder med aktiv og passiv kontrol, genforsøg, afbrydere (For flere detaljer, se f.eks. ), egne implementeringer af sundhedstjek (brugerdefinerede sundhedstjek) mv. En meget vigtig parameter, hvis du har høje krav til tilgængelighed og rettidig fjernelse af mislykkede tjenester fra balancering.
Balanceringsalgoritmer
Der er mange muligheder: fra traditionelle til det eksotiske , samt individuelle funktioner som .
autentificering
Hvilke autorisationsordninger understøtter den registeransvarlige? Basic, digest, oauth, ekstern-auth - jeg synes, disse muligheder burde være velkendte. Dette er et vigtigt kriterium, hvis der er mange udviklere (og/eller bare private) sløjfer, der tilgås via Ingress.
Trafikfordeling
Understøtter controlleren sådanne almindeligt anvendte trafikfordelingsmekanismer som kanarie-udrulninger (kanariefugle), A/B-test, trafikspejling (spejling/skygge)? Dette er et virkelig ømt emne for applikationer, der kræver nøjagtig og præcis trafikstyring til produktiv testning, fejlretning af produktfejl offline (eller med minimalt tab), trafikanalyse og så videre.
Betalt abonnement
Er der en betalingsmulighed for controlleren med avanceret funktionalitet og/eller teknisk support?
Grafisk brugergrænseflade (Web UI)
Er der nogen GUI til at styre controller-konfigurationen? Hovedsageligt for "handiness" og/eller for dem, der har brug for at lave nogle ændringer i Ingress'a-konfigurationen, men at arbejde med "rå" skabeloner er ubelejligt. Det kan være nyttigt, hvis udviklere ønsker at udføre nogle eksperimenter med trafik i farten.
JWT validering
Tilstedeværelsen af indbygget validering af JSON-webtokens til autorisation og validering af brugeren til slutapplikationen.
Muligheder for konfigurationstilpasning
Skabelonudvidelsesmuligheder i betydningen at have mekanismer, der giver dig mulighed for at tilføje dine egne direktiver, flag osv. til standardkonfigurationsskabeloner.
Grundlæggende DDOS-beskyttelsesmekanismer
Simple hastighedsgrænsealgoritmer eller mere komplekse trafikfiltreringsmuligheder baseret på adresser, hvidlister, lande osv.
Anmod om spor
Evnen til at overvåge, spore og fejlsøge anmodninger fra Ingresses til specifikke tjenester / pods, og ideelt set også mellem tjenester / pods.
WAF
Support .
Controllere
Listen over controllere blev dannet ud fra и . Vi udelukkede nogle af dem fra gennemgangen på grund af specificitet eller lav prævalens (tidligt udviklingsstadium). Resten diskuteres nedenfor. Lad os starte med en generel beskrivelse af løsningerne og fortsætte med en oversigtstabel.
Indgang fra Kubernetes
Hjemmeside:
Licens: Apache 2.0
Dette er den officielle controller for Kubernetes og udvikles af fællesskabet. Naturligvis fra navnet er det baseret på nginx og suppleres af et andet sæt Lua-plugins, der bruges til at implementere yderligere funktioner. På grund af populariteten af nginx selv og minimale ændringer af det, når det bruges som en controller, kan denne mulighed være den nemmeste og nemmeste at konfigurere for den gennemsnitlige ingeniør (med web-erfaring).
Ingress af NGINX Inc.
Hjemmeside:
Licens: Apache 2.0
Det officielle produkt fra nginx-udviklerne. Har en betalt version baseret på . Hovedideen er et højt niveau af stabilitet, konstant bagudkompatibilitet, fraværet af eventuelle uvedkommende moduler og den erklærede øgede hastighed (sammenlignet med den officielle controller), opnået på grund af afvisningen af Lua.
Den gratis version er betydeligt reduceret, også selv sammenlignet med den officielle controller (på grund af manglen på de samme Lua-moduler). Samtidig har den betalte en ret bred ekstra funktionalitet: realtidsmålinger, JWT-validering, aktive sundhedstjek og mere. En vigtig fordel i forhold til NGINX Ingress er fuld understøttelse af TCP/UDP-trafik (og også i fællesskabsversionen!). Minus - trafikdistributionsfunktion, som dog "har højeste prioritet for udviklere", men tager tid at implementere.
Kong Ingress
Hjemmeside:
Licens: Apache 2.0
Produkt udviklet af Kong Inc. i to versioner: kommerciel og gratis. Baseret på nginx, som er blevet udvidet med en lang række Lua-moduler.
I starten var det fokuseret på behandling og routing af API-anmodninger, dvs. som en API Gateway, men i øjeblikket er den blevet en fuldgyldig Ingress-controller. Vigtigste fordele: mange ekstra moduler (inklusive dem fra tredjepartsudviklere), der er nemme at installere og konfigurere, og ved hjælp af hvilke en lang række ekstra funktioner implementeres. Indbyggede funktioner giver dog allerede mange muligheder. Jobkonfiguration udføres ved hjælp af CRD-ressourcer.
En vigtig egenskab ved produktet - at arbejde inden for samme kontur (i stedet for krydsnavneafstand) er et kontroversielt emne: for nogle vil det virke som en ulempe (du skal producere enheder for hver kontur), og for nogen er det en funktion ( bоStørre grad af isolation, som hvis en controller er i stykker, så er problemet begrænset til kredsløbet alene).
Traefik
Hjemmeside:
Licens: MIT
En proxy, der oprindeligt blev oprettet til at arbejde med anmodningsrouting for mikrotjenester og deres dynamiske miljø. Derfor mange nyttige funktioner: opdatering af konfigurationen uden overhovedet at genstarte, understøttelse af et stort antal afbalanceringsmetoder, webgrænseflade, videresendelse af metrics, understøttelse af forskellige protokoller, REST API, canary-udgivelser og meget mere. En anden fin funktion er understøttelse af Let's Encrypt-certifikater ud af boksen. Ulempen er, at for at organisere høj tilgængelighed (HA), skal controlleren installere og tilslutte sit eget KV-lager.
HAProxy
Hjemmeside:
Licens: Apache 2.0
HAProxy har længe været kendt som en proxy og trafikbalancer. Som en del af en Kubernetes-klynge tilbyder den en "blød" konfigurationsopdatering (uden tab af trafik), serviceopdagelse baseret på DNS, dynamisk konfiguration ved hjælp af API. Det kan være attraktivt fuldstændigt at tilpasse konfigurationsskabelonen ved at erstatte CM, samt muligheden for at bruge Sprig-biblioteksfunktioner i den. Generelt ligger hovedvægten af løsningen på høj hastighed, dens optimering og effektivitet i forbrugte ressourcer. Fordelen ved controlleren er understøttelsen af et rekordstort antal forskellige afbalanceringsmetoder.
Voyager
Hjemmeside:
Licens: Apache 2.0
Baseret på HAproxy controller, der er positioneret som en universel løsning, der understøtter en lang række funktioner hos en lang række udbydere. Der tilbydes mulighed for at afbalancere trafik på L7 og L4, og afbalancering af TCP L4-trafik som helhed kan kaldes et af nøglefunktionerne i løsningen.
Kontur
Hjemmeside:
Licens: Apache 2.0
Denne løsning er ikke kun baseret på Envoy: den er udviklet af fællesskab med forfatterne af denne populære proxy. En vigtig funktion er muligheden for at adskille kontrol af Ingress-ressourcer ved hjælp af IngressRoute CRD-ressourcer. For organisationer med mange udviklingsteams, der bruger den samme klynge, hjælper dette med at maksimere sikkerheden ved at arbejde med trafik i tilstødende sløjfer og beskytte dem mod fejl ved ændring af Ingress-ressourcer.
Det tilbyder også et udvidet sæt af balanceringsmetoder (der er spejling af anmodninger, auto-repeat, begrænsning af antallet af anmodninger og meget mere), detaljeret overvågning af trafikflow og fejl. Måske for nogen vil det være en væsentlig ulempe manglen på støtte til klæbrige sessioner (selvom arbejdet ).
Istio Ingress
Hjemmeside:
Licens: Apache 2.0
En omfattende service mesh-løsning, der ikke kun er en Ingress-controller, der styrer indgående trafik udefra, men også styrer al trafik i klyngen. Under motorhjelmen bruges Envoy som sidevognsproxy for hver tjeneste. I bund og grund er dette en stor mejetærsker, der "kan gøre alt", og dens hovedidé er maksimal håndterbarhed, udvidelsesmuligheder, sikkerhed og gennemsigtighed. Med den kan du finjustere trafikdirigering, få adgang til godkendelse mellem tjenester, balancering, overvågning, canary releases og meget mere. Læs mere om Istio i artikelserien "'.
Ambassadør
Hjemmeside:
Licens: Apache 2.0
En anden løsning baseret på Envoy. Det har gratis og kommercielle versioner. Det er placeret som "fuldt indbygget i Kubernetes", hvilket giver de tilsvarende fordele (stram integration med metoderne og entiteterne i K8s-klyngen).
Sammenligningstabel
Så kulminationen på artiklen er denne enorme tabel:
Den er klikbar for at se nærmere, og den er også tilgængelig i formatet .
For at opsummere
Formålet med denne artikel er at give en mere fuldstændig forståelse (dog på ingen måde udtømmende!) af, hvilket valg du skal træffe i dit særlige tilfælde. Som sædvanlig har hver controller sine egne fordele og ulemper...
Den klassiske Ingress fra Kubernetes er god for sin tilgængelighed og bevislighed, rige nok funktioner - i det generelle tilfælde burde det være "nok for øjnene". Men hvis der er øgede krav til stabilitet, niveauet af funktioner og udvikling, bør du være opmærksom på Ingress med NGINX Plus og et betalt abonnement. Kong har det rigeste sæt plug-ins (og dermed de muligheder, de giver), og i den betalte version er der endnu flere af dem. Det har rig mulighed for at arbejde som en API Gateway, dynamisk konfiguration baseret på CRD-ressourcer samt grundlæggende Kubernetes-tjenester.
Med øgede krav til balancering og autorisationsmetoder, så tag et kig på Traefik og HAProxy. Disse er Open Source-projekter, som er bevist gennem årene, meget stabile og aktivt udviklende. Contour har været ude i et par år nu, men den ser stadig for ung ud og har kun grundlæggende funktioner tilføjet oven på Envoy. Hvis der er krav til tilstedeværelsen / indlejring af WAF foran applikationen, bør du være opmærksom på den samme Ingress fra Kubernetes eller HAProxy.
Og de rigeste med hensyn til funktioner er produkter bygget oven på Envoy, især Istio. Det ser ud til at være en samlet løsning, der "kan gøre alt", hvilket dog også betyder en væsentlig højere indgangstærskel for konfiguration/lancering/administration end andre løsninger.
Vi har valgt og bruger stadig Ingress fra Kubernetes som standard controller, der dækker 80-90% af behovene. Det er ret pålideligt, nemt at konfigurere og udvide. I mangel af specifikke krav bør det generelt passe til de fleste klynger/applikationer. Af samme universelle og relativt simple produkter kan Traefik og HAProxy anbefales.
PS
Læs også på vores blog:
- "Tilbage til mikrotjenester med Istio": , , ;
- «";
- «'.
Kilde: www.habr.com