Når du starter en Kubernetes-klynge for en spesifikk applikasjon, må du forstå hva applikasjonen selv, virksomheten og utviklerne utgjør for denne ressursen. Med denne informasjonen kan du begynne å ta en arkitektonisk beslutning og spesielt velge en spesifikk Ingress-kontroller, som det allerede er et stort antall av i dag. For å få en grunnleggende ide om tilgjengelige alternativer uten å måtte gå gjennom mange artikler / dokumentasjon osv., har vi utarbeidet denne oversikten, inkludert de viktigste (produksjonsklare) Ingress-kontrollerne.
Vi håper at det vil hjelpe kollegaer med å velge en arkitektonisk løsning – i det minste vil det bli et utgangspunkt for å innhente mer detaljert informasjon og praktiske eksperimenter. Tidligere har vi studert andre lignende materialer på nettet, og merkelig nok fant vi ikke en eneste mer eller mindre komplett, og viktigst av alt - strukturert - anmeldelse. Så la oss fylle det gapet!
kriterier
I prinsippet, for å gjøre en sammenligning og få et nyttig resultat, må du ikke bare forstå fagområdet, men også ha en spesifikk liste over kriterier som vil sette forskningsvektoren. Uten å late som om vi analyserer alle mulige tilfeller av bruk av Ingress / Kubernetes, prøvde vi å fremheve de mest generelle kravene til kontrollere - vær forberedt på at du uansett må studere alle dine spesifikke og detaljer separat.
Men jeg starter med egenskapene som har blitt så kjent at de er implementert i alle løsninger og ikke vurderes:
- dynamisk oppdagelse av tjenester (tjenesteoppdagelse);
- SSL-oppsigelse;
- arbeider med websockets.
Nå til sammenligningspunktene:
Protokoller som støttes
Et av de grunnleggende utvelgelseskriteriene. Programvaren din fungerer kanskje ikke på standard HTTP, eller den kan kreve arbeid på flere protokoller samtidig. Hvis saken din ikke er standard, må du ta hensyn til denne faktoren slik at du ikke trenger å rekonfigurere klyngen senere. Listen over støttede protokoller varierer for alle kontrollere.
programvare i kjernen
Det er flere varianter av applikasjoner som kontrolleren er basert på. Populære er nginx, traefik, haproxy, envoy. I det generelle tilfellet har det kanskje ikke mye effekt på hvordan trafikk mottas og overføres, men det er alltid nyttig å vite de potensielle nyansene og egenskapene til det som er "under panseret".
Trafikkdirigering
På grunnlag av hva er det mulig å ta en beslutning om retningen av trafikken til en bestemt tjeneste? Vanligvis er disse vert og sti, men det er flere muligheter.
Navneområde i en klynge
Navneområde (navneområde) - muligheten til å logisk dele ressurser i Kubernetes (for eksempel på scenen, produksjon, etc.). Det er Ingress-kontrollere som må installeres separat i hvert navneområde (og så kan det dirigere trafikk bare til belgene i dette rommet). Og det er de (og deres klare flertall) som jobber globalt for hele klyngen - i dem blir trafikk dirigert til hvilken som helst pod i klyngen, uavhengig av navneområdet.
Prøver for oppstrøms
Hvordan ledes trafikk til sunne forekomster av applikasjonen, tjenestene? Det finnes alternativer med aktive og passive kontroller, gjenforsøk, effektbrytere (For mer informasjon, se f.eks. ), tilpassede helsesjekker osv. En svært viktig parameter hvis du har høye krav til tilgjengelighet og rettidig fjerning av mislykkede tjenester fra balansering.
Balanseringsalgoritmer
Det er mange alternativer: fra tradisjonelle til det eksotiske , samt individuelle funksjoner som .
Autentisering
Hvilke autorisasjonsordninger støtter behandlingsansvarlig? Basic, digest, oauth, ekstern-auth - jeg tror disse alternativene bør være kjent. Dette er et viktig kriterium hvis det er mange utviklersløyfer (og/eller bare private) som er tilgjengelig via Ingress.
Trafikkfordeling
Støtter kontrolleren slike vanlige trafikkdistribusjonsmekanismer som kanarifuglutrullinger (kanarifugl), A/B-testing, trafikkspeiling (speiling/skyggelegging)? Dette er et veldig sårt emne for applikasjoner som krever nøyaktig og presis trafikkstyring for produktiv testing, feilsøking av produktfeil off-line (eller med minimalt tap), trafikkanalyse og så videre.
Betalt abonnement
Er det et betalt alternativ for kontrolleren, med avansert funksjonalitet og/eller teknisk støtte?
Grafisk brukergrensesnitt (Web UI)
Er det noen GUI for å administrere kontrollerkonfigurasjonen? Hovedsakelig for "handiness" og / eller for de som trenger å gjøre noen endringer i Ingress'a-konfigurasjonen, men å jobbe med "rå" maler er upraktisk. Det kan være nyttig hvis utviklere ønsker å utføre noen eksperimenter med trafikk i farten.
JWT-validering
Tilstedeværelsen av innebygd validering av JSON-webtokens for autorisasjon og validering av brukeren til sluttapplikasjonen.
Muligheter for konfigurasjonstilpasning
Malutvidbarhet i betydningen å ha mekanismer som lar deg legge til dine egne direktiver, flagg osv. til standard konfigurasjonsmaler.
Grunnleggende DDOS-beskyttelsesmekanismer
Enkle frekvensgrensealgoritmer eller mer komplekse trafikkfiltreringsalternativer basert på adresser, hvitelister, land osv.
Be om sporing
Muligheten til å overvåke, spore og feilsøke forespørsler fra Ingresses til spesifikke tjenester / pods, og ideelt sett også mellom tjenester / pods.
WAF
Støtte .
Kontrollere
Listen over kontroller ble dannet basert på и . Vi ekskluderte noen av dem fra gjennomgangen på grunn av spesifisitet eller lav prevalens (tidlig utviklingsstadium). Resten diskuteres nedenfor. La oss starte med en generell beskrivelse av løsningene og fortsette med en oppsummeringstabell.
Inngang fra Kubernetes
nettside:
Lisens: Apache 2.0
Dette er den offisielle kontrolleren for Kubernetes og utvikles av fellesskapet. Tydeligvis fra navnet er det basert på nginx og er supplert med et annet sett med Lua-plugins som brukes til å implementere tilleggsfunksjoner. På grunn av populariteten til selve nginx og minimale modifikasjoner av den når den brukes som en kontroller, kan dette alternativet være det enkleste og enkleste å konfigurere for den gjennomsnittlige ingeniøren (med nettopplevelse).
Ingress av NGINX Inc.
nettside:
Lisens: Apache 2.0
Det offisielle produktet til nginx-utviklerne. Har en betalt versjon basert på . Hovedideen er et høyt nivå av stabilitet, konstant bakoverkompatibilitet, fraværet av noen fremmede moduler og den erklærte økte hastigheten (sammenlignet med den offisielle kontrolleren), oppnådd på grunn av avvisningen av Lua.
Gratisversjonen er betydelig redusert, også sammenlignet med den offisielle kontrolleren (på grunn av mangelen på de samme Lua-modulene). Samtidig har den betalte en ganske bred tilleggsfunksjonalitet: sanntidsmålinger, JWT-validering, aktive helsesjekker og mer. En viktig fordel fremfor NGINX Ingress er full støtte for TCP / UDP-trafikk (og i fellesskapsversjonen også!). Minus - trafikkdistribusjonsfunksjon, som imidlertid "har høyeste prioritet for utviklere", men som tar tid å implementere.
Kong Ingress
nettside:
Lisens: Apache 2.0
Produkt utviklet av Kong Inc. i to versjoner: kommersiell og gratis. Basert på nginx, som er utvidet med et stort antall Lua-moduler.
I utgangspunktet var det fokusert på behandling og ruting av API-forespørsler, dvs. som en API Gateway, men for øyeblikket har den blitt en fullverdig Ingress-kontroller. Hovedfordeler: mange tilleggsmoduler (inkludert de fra tredjepartsutviklere) som er enkle å installere og konfigurere og ved hjelp av disse implementeres et bredt spekter av tilleggsfunksjoner. Innebygde funksjoner gir imidlertid allerede mange muligheter. Jobbkonfigurasjon gjøres ved hjelp av CRD-ressurser.
Et viktig trekk ved produktet - å jobbe innenfor samme kontur (i stedet for kryssnavn) er et kontroversielt tema: for noen vil det virke som en ulempe (du må produsere enheter for hver kontur), og for noen er det en funksjon ( bоStørre grad av isolasjon, som hvis en kontroller er ødelagt, er problemet begrenset til kretsen alene).
Traefik
nettside:
Lisens: MIT
En proxy som opprinnelig ble opprettet for å fungere med forespørselsruting for mikrotjenester og deres dynamiske miljø. Derfor mange nyttige funksjoner: oppdatering av konfigurasjonen uten å starte på nytt i det hele tatt, støtte for et stort antall balanseringsmetoder, webgrensesnitt, videresending av beregninger, støtte for ulike protokoller, REST API, canary-utgivelser og mye mer. En annen fin funksjon er støtte for Let's Encrypt-sertifikater ut av esken. Ulempen er at for å organisere høy tilgjengelighet (HA), må kontrolleren installere og koble til sin egen KV-lagring.
HAProxy
nettside:
Lisens: Apache 2.0
HAProxy har lenge vært kjent som en proxy og trafikkbalanserer. Som en del av en Kubernetes-klynge tilbyr den en "myk" konfigurasjonsoppdatering (uten tap av trafikk), tjenesteoppdagelse basert på DNS, dynamisk konfigurasjon ved hjelp av API. Det kan være attraktivt å fullstendig tilpasse konfigurasjonsmalen ved å erstatte CM, samt muligheten til å bruke Sprig-bibliotekfunksjonene i den. Generelt er hovedvekten av løsningen på høy hastighet, dens optimalisering og effektivitet i forbrukte ressurser. Fordelen med kontrolleren er støtten til et rekordantall forskjellige balanseringsmetoder.
Voyager
nettside:
Lisens: Apache 2.0
Basert på HAproxy-kontrolleren, som er posisjonert som en universalløsning som støtter et bredt spekter av funksjoner hos et stort antall leverandører. Det tilbys en mulighet for å balansere trafikk på L7 og L4, og balansering av TCP L4-trafikk som helhet kan kalles en av nøkkelfunksjonene til løsningen.
Kontur
nettside:
Lisens: Apache 2.0
Denne løsningen er ikke bare basert på Envoy: den ble utviklet av i fellesskap med forfatterne av denne populære proxyen. En viktig funksjon er muligheten til å skille kontroll over Ingress-ressurser ved å bruke IngressRoute CRD-ressurser. For organisasjoner med mange utviklingsteam som bruker samme klynge, bidrar dette til å maksimere sikkerheten ved å jobbe med trafikk i nabosløyfer og beskytte dem mot feil ved endring av Ingress-ressurser.
Den tilbyr også et utvidet sett med balanseringsmetoder (det er forespørselsspeiling, auto-repetisjon, begrensning av forespørselshastighet og mye mer), detaljert overvåking av trafikkflyt og feil. Kanskje for noen vil det være en betydelig ulempe mangelen på støtte for klissete økter (selv om arbeidet ).
Istio Ingress
nettside:
Lisens: Apache 2.0
En omfattende service mesh-løsning som ikke bare er en Ingress-kontroller som styrer innkommende trafikk fra utsiden, men også kontrollerer all trafikk i klyngen. Under panseret brukes Envoy som en sidevogn proxy for hver tjeneste. I hovedsak er dette en stor skurtresker som "kan gjøre alt", og hovedideen er maksimal administrasjon, utvidbarhet, sikkerhet og åpenhet. Med den kan du finjustere trafikkruting, få tilgangsautorisering mellom tjenester, balansering, overvåking, kanarieutgivelser og mye mer. Les mer om Istio i artikkelserien "'.
Ambassadør
nettside:
Lisens: Apache 2.0
En annen løsning basert på Envoy. Den har gratis og kommersielle versjoner. Det er posisjonert som "helt innfødt til Kubernetes", noe som gir de tilsvarende fordelene (tett integrasjon med metodene og enhetene til K8s-klyngen).
Sammenligningstabell
Så kulminasjonen av artikkelen er denne enorme tabellen:
Den er klikkbar for å se nærmere, og er også tilgjengelig i formatet .
For å oppsummere
Hensikten med denne artikkelen er å gi en mer fullstendig forståelse (men på ingen måte uttømmende!) av hvilket valg du skal ta i ditt spesielle tilfelle. Som vanlig har hver kontroller sine egne fordeler og ulemper...
Den klassiske Ingress fra Kubernetes er bra for sin tilgjengelighet og bevisbarhet, rike nok funksjoner - i det generelle tilfellet bør det være "nok for øynene". Men hvis det er økte krav til stabilitet, funksjonsnivå og utvikling, bør du ta hensyn til Ingress med NGINX Plus og et betalt abonnement. Kong har det rikeste settet med plug-ins (og følgelig mulighetene de gir), og i den betalte versjonen er det enda flere av dem. Den har gode muligheter til å fungere som en API-gateway, dynamisk konfigurasjon basert på CRD-ressurser, samt grunnleggende Kubernetes-tjenester.
Med økte krav til balansering og autorisasjonsmetoder, ta en titt på Traefik og HAProxy. Dette er Open Source-prosjekter, bevist gjennom årene, veldig stabile og aktivt utviklende. Contour har vært ute i et par år nå, men den ser fortsatt for ung ut og har bare grunnleggende funksjoner lagt til på toppen av Envoy. Hvis det er krav til tilstedeværelse / innbygging av WAF foran applikasjonen, bør du ta hensyn til samme Ingress fra Kubernetes eller HAProxy.
Og de rikeste når det gjelder funksjoner er produkter bygget på toppen av Envoy, spesielt Istio. Det ser ut til å være en helhetlig løsning som «kan gjøre hva som helst», som imidlertid også betyr en betydelig høyere inngangsterskel for konfigurasjon/lansering/administrasjon enn andre løsninger.
Vi har valgt og bruker fortsatt Ingress fra Kubernetes som en standard kontroller, som dekker 80-90 % av behovene. Det er ganske pålitelig, enkelt å konfigurere og utvide. Generelt, i fravær av spesifikke krav, bør det passe de fleste klynger/applikasjoner. Av de samme universelle og relativt enkle produktene kan Traefik og HAProxy anbefales.
PS
Les også på bloggen vår:
- "Tilbake til mikrotjenester med Istio": , , ;
- «";
- «'.
Kilde: www.habr.com