Når man opstarter et Kubernetes-kluster for en specifik applikation, er det vigtigt at forstå, hvilke krav applikationen, virksomheden og udviklerne stiller til denne ressource. Med disse oplysninger kan man begynde at træffe arkitektoniske beslutninger, herunder valg af specifik Ingress-controller, da der i dag allerede er mange tilgængelige. For at give en grundlæggende forståelse af de tilgængelige muligheder uden at skulle gennemgå adskillige artikler/dokumentation mv., har vi udarbejdet denne oversigt, hvor vi inkluderer de vigtigste (production ready) Ingress-controllere.
Vi håber, at den vil hjælpe kollegerne i deres valg af arkitektonisk løsning — i det mindste vil den fungere som et udgangspunkt for at få mere detaljeret information og praktiske eksperimenter. Forud har vi undersøgt andre lignende materialer online og, underligt nok, fandt vi ikke ét eneste mere eller mindre fyldestgørende, og vigtigst af alt — struktureret — overblik. Så lad os udfylde denne mangel!
Kriterier
For overhovedet at kunne foretage sammenligninger og opnå et nyttigt resultat, skal man ikke blot forstå emneområdet, men også have en konkret liste over kriterier, der vil styre forskningen. Uden at påtage os at analysere alle mulige anvendelsessager for Ingress/Kubernetes, har vi stræbt efter at fremhæve de mest generelle krav til controllere — vær forberedt på, at enhver specifik detalje og nuance i alle tilfælde skal undersøges separat.
Men lad mig starte med de karakteristika, som er blevet så velkendte, at de er implementeret i alle løsninger og derfor ikke diskuteres:
- dynamisk serviceopdagelse (service discovery);
- SSL-terminering;
- arbejde med websockets.
Nu — til sammenligningspunkterne:
Understøttede protokoller
En af de grundlæggende kriterier for valg. Din software kan muligvis ikke køre på standard HTTP eller kræve drift på flere protokoller samtidigt. Hvis dit tilfælde er ikke-standard, så husk at tage denne faktor i betragtning, så du ikke senere skal omkonfigurere klustret. Listen over understøttede protokoller varierer blandt alle controllere.
Software i bunden
Der er flere applikationstyper, som controlleren er baseret på. De mest populære er nginx, traefik, haproxy, envoy. Generelt set påvirker det muligvis ikke så meget, hvordan trafikken modtages og overføres, men det er altid nyttigt at kende de potentielle nuancer og egenskaber ved det, der er "under motorhjelmen".
Trafikrouting
Hvad kan man basere beslutningen om at dirigere trafikken til en bestemt service på? Normalt er det host og path, men der kan også være yderligere muligheder.
Navnerum i klyngen
Et navnerum (namespace) giver mulighed for logisk at opdele ressourcer i Kubernetes (f.eks. i stage, production osv.). Der er Ingress-controllere, der skal installeres separat i hvert navnerum (og så kan de dirigere trafik kun til pods inden for dette rum). Og der er dem (og de er klart flertallet), der arbejder globalt på hele klyngen — trafik dirigeres til enhver pod i klyngen, uanset navnerummet.
Sundhedstjek for upstreams
Hvordan sikres det, at trafikken dirigeres til sunde instanser af applikationer og services? Der er muligheder med aktive og passive tjek, genforsøg (retries), circuit breakers (læs mere om dem f.eks. i ), egne implementationer af tilstandstjek (custom health checks) osv. Det er en meget vigtig parameter, hvis du har høje krav til tilgængelighed og rettidig ekskludering af fejlfungerende services fra balanceringen.
Balanceringsalgoritmer
Her er der mange muligheder: fra traditionelle til eksotiske som , samt unikke muligheder som .
Godkendelse
Hvilke autorisationsskemaer understøtter controlleren? Basic, digest, oauth, external-auth — jeg mener, at disse muligheder burde være velkendte. Det er et vigtigt kriterium, hvis der anvendes mange miljøer til udviklere (og/eller bare lukkede), som tilgås via Ingress.
Trafikfordeling
Understøtter controlleren sådanne ofte brugte mekanismer til trafikfordeling som kanarieforsøg (canary), A/B-testning, trafikspejling (mirroring/shadowing)? Dette er et reelt problem for applikationer, der kræver omhyggelig og præcis trafikstyring til produktionsafprøvning, fejlfinding af produktfejl uden at påvirke driften (eller med minimale tab), trafik-analyse osv.
Betalt abonnement
Er der en betalt version af controlleren med udvidede funktioner og/eller teknisk support?
Grafisk brugergrænseflade (Web UI)
Er der nogen grafisk brugergrænseflade til at håndtere konfigurationen af controlleren? Primært for bekvemmelighed og/eller for dem, der har brug for at foretage ændringer i Ingress' konfiguration, da det er besværligt at arbejde med 'rå' skabeloner. Det kan være nyttigt, hvis udviklerne ønsker at eksperimentere med trafik i realtid.
JWT-validering
Inklusion af indbygget kontrol af JSON web-tokens til autentificering og validering af brugeren på den endelige applikation.
Muligheder for tilpasning af konfiguration
Udvidelighed af skabeloner i form af mekanismer, der gør det muligt at tilføje egne direktiver, flags osv. til de standard konfigurationsskabeloner.
Basisbeskyttelsesmekanismer mod DDoS
Simple rate limit-algoritmer eller mere komplekse varianter til at filtrere trafik baseret på adresser, whitelist, lande osv.
Anmodning tracing
Muligheder for overvågning, sporing og debugging af anmodninger fra Ingress til specifikke tjenester/pod'er, og ideelt set også mellem tjenester/pod'er.
WAF
Support .
Ingress-controllers
Listen over controllere er baseret på og . Nogle af dem har vi udelukket fra oversigten på grund af deres specifikhed eller lave udbredelse (tidlig udviklingsfase). De resterende er gennemgået nedenfor. Vi starter med en generel beskrivelse af løsningerne og fortsætter med den opsummerende tabel.
Ingress fra Kubernetes
Websted:
License: Apache 2.0
Dette er den officielle controller til Kubernetes, som udvikles af fællesskabet. Som navnet antyder, er den baseret på nginx og suppleres med et forskelligt sæt Lua-plugins, der anvendes til at implementere yderligere funktioner. Takket være populariteten af nginx og de minimale modifikationer, der er lavet ved brug som controller, kan denne version være den enkleste og mest forståelige at konfigurere for en gennemsnitlig ingeniør (med erfaring i web).
Ingress fra NGINX Inc
Websted:
License: Apache 2.0
Det officielle produkt fra udviklerne af nginx. Har en betalt version baseret på Hovedideen er et højt niveau af stabilitet, konstant bagudkompatibilitet, fraværet af eksterne moduler og en påstået øget hastighed (sammenlignet med den officielle controller), opnået ved at undgå Lua.
Den gratis version er betydeligt begrænset, selv ved sammenligning med den officielle controller (på grund af fraværet af de samme Lua-moduler). Den betalte version har til gengæld en bred vifte af ekstra funktionalitet: realtidsmålinger, JWT-validering, aktive health checks og mere. En vigtig fordel i forhold til NGINX Ingress er den fulde understøttelse af TCP/UDP-trafik (også i community-versionen!). Ulempen er funktioner til trafikfordeling, som dog "har højeste prioritet for udviklerne", men som kræver tid til implementering.
Kong Ingress
Websted:
License: Apache 2.0
Produktet udvikles af Kong Inc. i to varianter: kommerciel og gratis. Det er baseret på NGINX, hvis muligheder er udvidet med et stort antal Lua-moduler.
Oprindeligt blev det designet til behandling og ruteanmodninger til API'er, dvs. som en API Gateway, men er i dag blevet en fuldgyldig Ingress-controller. De primære fordele: mange ekstra moduler (også fra tredjepartsudviklere), som nemt kan installeres og konfigureres og som muliggør et bredt spektrum af ekstra muligheder. Dog tilbyder de indbyggede funktioner allerede mange muligheder. Konfigurationen udføres ved hjælp af CRD-ressourcer.
En vigtig egenskab ved produktet er arbejdet inden for en enkelt kontur (i stedet for cross-namespaced), hvilket er et omdiskuteret emne: nogle vil finde det en mangel (da man skal oprette entiteter for hver kontur), mens andre vil se det som en funktion (højt niveau af isolation, da hvis én controller er defekt, er problemet begrænset til kun én kontur).fleste afTraefik
github.com/containous/traefik
Websted:
Licens: MIT
En proxy der oprindeligt blev designet til at håndtere anmodningsroutning for mikroservices og deres dynamiske miljø. Deraf mange nyttige funktioner: opdatering af konfigurationen uden genstart, understøttelse af et stort antal balancingmetoder, webgrænseflade, metrics-gennemløb, støtte til forskellige protokoller, REST API, kanariefuglereliser og meget mere. En behagelig funktion er også understøttelsen af Let’s Encrypt-certifikater uden yderligere konfiguration. Ulempen er, at der for at organisere høj tilgængelighed (HA) kræves et eget KV-lager til controlleren.
HAProxy
Websted:
License: Apache 2.0
HAProxy er længe blevet kendt som en proxy og balancerer trafik. I forbindelse med et Kubernetes-kluster tilbydes en "blød" opdatering af konfigurationen (uden trafiktab), service discovery baseret på DNS, dynamisk konfiguration via API. Attraktivt kan det være at have fuld tilpasning af skabelonkonfigurationer ved hjælp af substituering af CM, samt mulighederne for at bruge funktioner fra Sprig-biblioteket. Generelt fokuserer løsningen på høj hastighed, optimering og effektivitet i ressourceforbruget. Fordelen ved controlleren er understøttelse af et rekordantal forskellige balancingmetoder.
Voyager
Websted:
License: Apache 2.0
En controller baseret på HAproxy, der positioneres som en universel løsning, der understøtter brede muligheder hos mange udbydere. Muligheden for at balancere trafik på L7 og L4 tilbydes, og L4-balancering af TCP-trafik kan generelt betragtes som en af de vigtigste funktioner i løsningen.
Contour
Websted:
License: Apache 2.0
Denne løsning er ikke kun baseret på Envoy: den er udviklet sammen med skaberne af denne populære proxy. En vigtig funktion er muligheden for at adskille styringen af Ingress-ressourcer ved hjælp af CRD-ressourcer IngressRoute. For organisationer med mange udviklingsteams, der bruger et enkelt kluster, hjælper dette med at maksimere sikkerheden i arbejdet med trafikken i nabokonturer og beskytte dem mod fejl ved ændringer af Ingress-ressourcer.
Der tilbydes også et omfattende sæt metoder til belastningsfordeling (med spejling af anmodninger, automatiske gentagelser, begrænsning af anmodningsraten og meget mere), detaljeret overvågning af trafikstrømmen og fejl. For nogle kan fraværet af støtte til sticky sessions være en betydelig ulempe (selvom arbejdet allerede er i gang. ).
Istio Ingress
Websted:
License: Apache 2.0
En helhedsorienteret service mesh-løsning, der ikke blot fungerer som en Ingress-controller til at styre den indkommende trafik udefra, men også kontrollerer al trafik inden for klyngen. ‘Under motorhjelmen’ bruges Envoy som sidecar-proxy for hver tjeneste. I bund og grund er det en stor kombination, der ‘kan alt’, og dens hovedidé er maksimal styring, skalerbarhed, sikkerhed og gennemsigtighed. Ved hjælp af dette kan du detaljejustere trafikrouting, adgangsautorisering mellem tjenester, belastningsfordeling, overvågning, kanariefugleudgivelser og meget mere. Læs mere om Istio i en serie artikler ‘».
Ambassador
Websted:
License: Apache 2.0
Endnu en løsning baseret på Envoy. Den har både gratis og kommercielle versioner. Den præsenteres som ‘fuldstændig native til Kubernetes’, hvilket giver tilsvarende fordele (tæt integration med metoder og entiteter fra K8s-klusteret).
Sammenligningstabel
Så, artikelens højdepunkt — denne enorme tabel:
Den er klikbar for mulighed for en mere detaljeret visning og kan også fås i formatet .
Lad os opsummere
Formålet med artiklen er at give en mere komplet forståelse (selv om det helt klart ikke er udtømmende!) af, hvilket valg der skal træffes i din specifikke situation. Som det ofte er tilfældet, har hver controller sine fordele og ulemper…
Klassisk Ingress fra Kubernetes er godt kendt for sin tilgængelighed og pålidelighed og tilbyder rigelige muligheder - generelt set burde det være "nok". Men hvis der er forhøjede krav til stabilitet, funktionsniveau og udvikling, er det værd at overveje Ingress med NGINX Plus og et betalt abonnement. Kong har et meget rigt udvalg af plug-ins (og dermed de muligheder, de tilbyder), og i den betalte version er der endda flere. Den har store muligheder som API Gateway, dynamisk konfiguration baseret på CRD-ressourcer samt grundlæggende Kubernetes-tjenester.
Ved forhøjede krav til load balancing og autorisationsmetoder bør du kigge på Traefik og HAProxy. Disse er Open Source-projekter, der er blevet testet gennem årene, meget stabile og aktivt udviklende. Contour har været på markedet i et par år, men ser stadig for ung ud og har kun de grundlæggende funktioner tilføjet oven på Envoy. Hvis der er krav om at have/implementere WAF foran applikationen, er det værd at se nærmere på Ingress fra Kubernetes eller HAProxy.
De mest funktionsrige produkter er dem, der er bygget på Envoy, især Istio. Det fremstår som en omfattende løsning, der "kan det hele", hvilket dog også betyder en betydeligt højere indlæringskurve for konfiguration, opsætning og administration end andre løsninger.
Vi har valgt Ingress fra Kubernetes som standardcontroller, som fortsat anvendes, og som dækker 80—90% af behovene. Det er pålideligt, let at konfigurere og udvide. Generelt set, ved manglende specifikke krav, bør det være passende for de fleste klynger/applikationer. Blandt andre alsidige og relativt simple produkter kan Traefik og HAProxy anbefales.
P.S.
Læs også på vores blog:
- «Tilbage til mikrotjenester sammen med Istio»: , , ;
- «»;
- «».
Kilde: habr.com
