🥇Översikt och jämförelse av Ingress-kontroller för Kubernetes

När man startar ett Kubernetes-kluster för en specifik applikation är det viktigt att förstå vilka krav applikationen, verksamheten och utvecklarna ställer på denna resurs. Med denna information kan man gå vidare med att fatta arkitektoniska beslut och, specifikt, välja en specifik Ingress-kontroller, av vilka det idag finns många. För att ge en grundläggande översikt av de tillgängliga alternativen utan att behöva studera många artiklar/dokumentation med mera, har vi förberett denna översikt och inkluderat de främsta (produktionsklara) Ingress-kontrollerna.

Vi hoppas att detta kommer att hjälpa kollegor i valet av arkitektoniskt beslut - åtminstone kommer det att fungera som utgångspunkt för att få mer detaljerad information och praktiska experiment. Vi har på förhand studerat andra liknande material på nätet och, märkligt nog, hittade vi inte en enda mer eller mindre komplett, och framför allt - strukturerad - översikt. Låt oss fylla detta gap!

Kriterier

För att överhuvudtaget kunna göra en jämförelse och få något nyttigt resultat behöver man inte bara förstå ämnesområdet, utan också ha en specifik lista med kriterier som kommer att styra forskningen. Utan att påstå att vi analyserar alla möjliga användningsfall för Ingress/Kubernetes har vi försökt att lyfta fram de mest allmänna kraven på kontrollerna - var redo att du i alla fall kommer att behöva studera din egen specifika information separat.

Men jag börjar med de egenskaper som blivit så vanliga att de finns i alla lösningar och därför inte diskuteras:

dynamisk tjänstigenkänning (service discovery);
SSL-terminering;
support för WebSocket.

Nu - om jämförelsepunkterna:

Stödda protokoll

En av de grundläggande kriterierna för val. Din programvara kanske inte fungerar via standard HTTP eller kan kräva att man arbetar med flera protokoll samtidigt. Om ditt fall är icke-standard, se till att ta hänsyn till denna faktor, så du inte behöver justera klustret senare. Listan över stödda protokoll varierar mellan alla kontroller.

Programvaran i grunden

Det finns flera typer av applikationer som kontrollern är baserad på. De populäraste är nginx, traefik, haproxy, envoy. Generellt sätt påverkar dessa kanske inte direkt hur trafiken tas emot och skickas, men det är alltid bra att känna till eventuella nyanser och särdrag av vad som "döljer sig bakom kulisserna".

Trafikrouting

Vad baserar man beslutet om riktning av trafiken till en viss tjänst? Vanligtvis handlar det om host och path, men det finns även ytterligare möjligheter.

Namnrymd inom klustret

Namnrymden (namespace) ger möjlighet att logiskt dela upp resurser i Kubernetes (t.ex. på stage, production m.m.). Det finns Ingress-kontroller som behöver installeras separat i varje namespace (och kan då styra trafiken bara till pods i denna namnrymd). Men det finns även sådana (och dessa är uppenbarligen i majoritet) som fungerar globalt för hela klustret — trafiken dirigeras till vilken pod som helst i klustret, oavsett namnrymd.

Prober för upstreams

Hur säkerställs att trafiken dirigeras till friska instanser av applikationen och tjänster? Det finns alternativ med aktiva och passiva kontroller, omstar försök (retries), circuit breakers (mer om dem kan man se, t.ex., i artikeln om Istio), egna implementationer av hälsokontroller (custom health checks) osv. Detta är en mycket viktig parameter om ni har höga krav på tillgänglighet och snabb utsortering av tjänster som har fallit.

Lastbalanseringsalgoritmer

Här finns många alternativ: från traditionella round-robin till mer exotiska som rdp-cookie, samt särskilda möjligheter som sticky sessions.

Autentisering

Vilka autentiseringsscheman stöder kontrollern? Basic, digest, oauth, external-auth — jag tror att dessa alternativ bör vara bekanta. Detta är en viktig kriterium om man använder många konturer för utvecklare (och/eller helt enkelt stängda), vars åtkomst sker via Ingress.

Trafikdistribution

Stöder kontrollern vanliga metoder för trafikdistribution, såsom canary releases, A/B-testning, trafikspeglinig (mirroring/shadowing)? Detta är ett verkligt problematiskt ämne för applikationer som kräver noggrann och exakt trafikhantering för produktiv testning, avkodning av produktfel utanför produktionsmiljön (eller med minimala förluster), trafikanalys m.m.

Betald prenumeration

Finns det en betald version av kontrollern med utökade funktioner och/eller teknisk support?

Grafiskt gränssnitt (Web UI)

Finns det något grafiskt gränssnitt för att hantera konfigurationen av kontrollern? Detta är främst för "bekvämlighet" och/eller för dem som behöver göra vissa förändringar i Ingress-konfigurationen, men det är obekvämt att arbeta med "råa" mallar. Det kan vara användbart om utvecklarna vill genomföra experiment med trafiken i realtid.

JWT-validering

Finns det inbyggd kontroll av JSON web-token för autentisering och validering av användare i slappapplikationen.

Möjligheter till anpassning av konfigurationen

Utvidgbarhet av mallar i termer av mekanismer för att lägga till egna direktiv, flaggor etc. i standardkonfigurationsmallarna.

Grundläggande skyddsmekanismer mot DDOS

Enkla rate limit-algoritmer eller mer komplexa alternativ för att filtrera trafik baserat på adresser, vitlistor, länder etc.

Begärningstracering

Möjligheter för övervakning, spårning och felsökning av begärningar från Ingress till specifika tjänster/poddar, och i idealfallet även mellan tjänster/poddar.

WAF

Support applikationsfirewall.

Ingress-kontrollrar

Listan över kontrollrar har sammanställts utifrån den officiella Kubernetes-dokumentationen och denna tabell. Några av dem har vi uteslutit från översikten på grund av deras specifikhet eller låga spridning (i ett tidigt utvecklingsstadium). De återstående har granskats nedan. Vi börjar med en allmän beskrivning av lösningarna och fortsätter med en sammanställning.

Ingress från Kubernetes

Webbplats: github.com/kubernetes/ingress-nginx
Licens: Apache 2.0

Detta är den officiella kontrollern för Kubernetes, som utvecklas av gemenskapen. Som namnet antyder är den baserad på nginx och kompletterad med en uppsättning Lua-plugin-program som används för att implementera ytterligare funktioner. Tack vare populariteten hos nginx och de minimala modifieringarna som görs på den vid användning som kontrollern, kan detta alternativ vara det enklaste och mest lättförståeliga för en genomsnittlig ingenjör (med erfarenhet av webben).

Ingress från NGINX Inc

Webbplats: github.com/nginxinc/kubernetes-ingress
Licens: Apache 2.0

En officiell produkt från utvecklarna av nginx. Har en betald version baserad på NGINX Plus. Huvudidéen är en hög nivå av stabilitet, konstant bakåtkompatibilitet, avsaknad av externa moduler och utlovad ökad hastighet (jämfört med den officiella kontrollern), som uppnåtts genom att avstå från Lua.

Den kostnadsfria versionen är kraftigt nedskuren, också jämfört med den officiella kontrollern (på grund av avsaknaden av just Lua-modulerna). Den betalda versionen däremot har en ganska omfattande extra funktionalitet: realtidsmetrik, JWT-validering, aktiva hälsokontroller och mer. En viktig fördel jämfört med NGINX Ingress är fullt stöd för TCP/UDP-trafik (även i community-versionen!). Nackdelen är bristen på funktioner för trafikfördelning, vilket dock "har högsta prioritet för utvecklarna", men kräver tid för implementering.

Kong Ingress

Webbplats: github.com/Kong/kubernetes-ingress-controller
Licens: Apache 2.0

Produkten utvecklas av Kong Inc. i två varianter: kommersiell och gratis. Byggd på nginx, vars möjligheter utvidgas med ett stort antal Lua-moduler.

Initialt var den inriktad på hantering och routing av API-förfrågningar, d.v.s. som API Gateway, men har nu blivit en fullvärdig Ingress-kontroller. Huvudfördelarna: många extra moduler (inklusive från tredjepartsutvecklare) som är lätta att installera och konfigurera och med hjälp av vilka ett brett spektrum av ytterligare funktioner kan implementeras. Dock erbjuder de inbyggda funktionerna redan många möjligheter. Konfigurationen görs med hjälp av CRD-resurser.

En viktig egenskap hos produkten är att den arbetar inom en enda kontur (istället för cross-namespaced), vilket är ett omdiskuterat ämne: vissa kanske tycker att det är en nackdel (man måste skapa enheter för varje kontur), medan andra ser det som en funktion (högre nivå av isolering, eftersom om en kontroll misslyckas, så är problemet begränsat till bara en kontur).bästa resultatet (subjektiv åsikt).större nivå av isolering, eftersom om en controller går sönder, så är problemet begränsat till endast en kontur).

Traefik

Webbplats: github.com/containous/traefik
Licens: MIT

En proxy som ursprungligen skapades för att arbeta med routing av förfrågningar för mikrotjänster och deras dynamiska miljö. Därifrån kommer många användbara funktioner: konfigurationsuppdateringar utan omstart, stöd för många lastbalanseringsmetoder, webbgränssnitt, mätpunktsgenomgång, stöd för olika protokoll, REST API, kanariefunktioner och mycket mer. En trevlig funktion är också stöd för Let’s Encrypt-certifikat direkt ur lådan. Nackdelen är att för att organisera hög tillgänglighet (HA) krävs det att kontrollern installerar och kopplar ett eget KV-lager.

HAProxy

Webbplats: github.com/jcmoraisjr/haproxy-ingress
Licens: Apache 2.0

HAProxy har länge varit känt som proxy och lastbalanserare. Inom ett Kubernetes-kluster erbjuder den "mjuka" konfigurationsuppdateringar (utan trafikförlust), service discovery baserat på DNS, dynamisk konfiguration via API. En attraktiv aspekt kan vara fullständig anpassning av konfigurationsmallar genom att byta ut CM:et, samt möjligheten att använda funktioner från Sprig-biblioteket. Sammanfattningsvis läggs huvudvikten på hög hastighet, optimering och effektivitet i resursanvändning. Kontrollerns fördel är stödet för ett rekordmånga olika lastbalanseringsmetoder.

Voyager

Webbplats: github.com/appscode/voyager
Licens: Apache 2.0

En controller baserad på HAproxy, som positionerar sig som en universallösning, som stöder omfattande funktionalitet hos många leverantörer. Den erbjuder möjlighet till lastbalansering på L7 och L4, där lastbalansering av TCP L4-trafik i allmänhet kan kallas en av nyckelfunktionerna i lösningen.

Contour

Webbplats: github.com/heptio/contour
Licens: Apache 2.0

Detta lösningskoncept bygger inte bara på Envoy: det har utvecklats tillsammans med författarna till denna populära proxy. En viktig funktion är möjligheten att separera hanteringen av Ingress-resurser med hjälp av CRD-resurser IngressRoute. För organisationer med många utvecklingsteam som använder ett kluster hjälper detta till att maximalt säkra hanteringen av trafik i angränsande konturer och skydda dem från fel vid ändring av Ingress-resurser.

En utvidgad uppsättning av balanseringsmetoder erbjuds (det finns möjlighet för begärningsspegeling, automatiska omförsök, begränsning av begärningsfrekvens och mycket mer), detaljerad övervakning av trafikflödet och avbrott. Avsaknaden av stöd för sticky sessions kan vara en betydande nackdel för vissa (även om arbete redan pågår).

Istio Ingress

Webbplats: istio.io/docs/tasks/traffic-management/ingress
Licens: Apache 2.0

En komplett service mesh-lösning som inte bara fungerar som en Ingress-kontroller för inkommande trafik utifrån, utan också kontrollerar all trafik inom klustret. "Under huven" används Envoy som en sidecar-proxy för varje tjänst. I grund och botten är detta en stor maskin som "kan allt", med den centrala idén att maximera hanterbarhet, skalbarhet, säkerhet och transparens. Med hjälp av detta kan du noggrant konfigurera trafikdirigering, åtkomstautorisering mellan tjänster, lastbalansering, övervakning, kanarrelease och mycket mer. Läs mer om Istio i serien av artiklar "Tillbaka till mikrotjänster med Istio».

Ambassador

Webbplats: github.com/datawire/ambassador
Licens: Apache 2.0

En annan lösning baserad på Envoy. Har både gratis och kommersiella versioner. Positioneras som "helt nativ för Kubernetes", vilket ger motsvarande fördelar (snabb integration med metoder och entiteter i K8s-klustret).

Jämförelsetabell

Så, kulmen av artikeln är denna stora tabell:

Den är klickbar för möjlighet till mer detaljerad granskning och finns också tillgänglig i formatet Google Sheets.

Låt oss sammanfatta

Syftet med artikeln är att ge en mer komplett förståelse (även om det i sig inte är uttömmande!) om vilket val som bör göras i ditt specifika fall. Som vanligt har varje kontroller sina fördelar och nackdelar...

Den klassiska Ingress från Kubernetes är bra på grund av sin tillgänglighet och testbarhet, med tillräckligt rika funktioner — i allmänhet bör den "räcka till". Men om det finns ökade krav på stabilitet, funktionsnivå och utveckling, bör man överväga Ingress med NGINX Plus och en betalprenumeration. Kong har ett omfattande utbud av plugins (och därmed möjligheterna som de erbjuder), och i den betalversionen finns det till och med fler. Den har stora möjligheter att fungera som API Gateway, dynamisk konfiguration baserat på CRD-resurser, samt grundläggande Kubernetes-tjänster.

Vid högre krav på belastningsbalansering och autentiseringsmetoder, kolla på Traefik och HAProxy. Dessa är Open Source-projekt, beprövade genom åren, mycket stabila och aktivt utvecklade. Contour har funnits ett par år nu, men ser fortfarande för ungt ut och har endast de grundläggande funktionerna, tillagda ovanpå Envoy. Om det finns krav på integration av WAF före applikationen, bör man överväga samma Ingress från Kubernetes eller HAProxy.

De mest funktionella produkterna är de byggda på Envoy, särskilt Istio. Det framstår som en heltäckande lösning som "kan allt", vilket dock innebär en betydligt högre tröskel för konfiguration/startadministration än för andra lösningar.

Vi har valt Ingress från Kubernetes som standardkontroller och används fortfarande, vilket täcker 80–90% av behoven. Den är ganska pålitlig, lätt att konfigurera och utöka. Generellt, vid avsaknad av specifika krav, bör den passa de flesta kluster/applikationer. Från liknande universella och relativt enkla produkter kan Traefik och HAProxy rekommenderas.