När du startar ett Kubernetes-kluster för en specifik applikation måste du förstå vad själva applikationen, verksamheten och utvecklarna ställer till med denna resurs. Med denna information kan du börja fatta ett arkitektoniskt beslut och i synnerhet välja en specifik Ingress-kontroller, som det redan idag finns ett stort antal av. För att få en grundläggande uppfattning om de tillgängliga alternativen utan att behöva gå igenom en massa artiklar/dokumentation etc., har vi förberett denna översikt, inklusive de viktigaste (produktionsklara) Ingress-kontrollerna.
Vi hoppas att det ska hjälpa kollegor att välja en arkitektonisk lösning – åtminstone blir det en utgångspunkt för att få mer detaljerad information och praktiska experiment. Tidigare har vi studerat andra liknande material på nätet och märkligt nog hittade vi inte en enda mer eller mindre komplett, och viktigast av allt - strukturerad - recension. Så låt oss fylla den luckan!
kriterier
I princip, för att göra en jämförelse och få ett användbart resultat, måste du förstå inte bara ämnesområdet, utan också ha en specifik lista med kriterier som kommer att sätta forskningsvektorn. Utan att låtsas analysera alla möjliga fall av användning av Ingress / Kubernetes, försökte vi lyfta fram de mest allmänna kraven för kontroller - var beredd på att du i alla fall måste studera alla dina detaljer och detaljer separat.
Men jag börjar med de egenskaper som har blivit så bekanta att de implementeras i alla lösningar och inte beaktas:
- dynamisk upptäckt av tjänster (tjänstupptäckt);
- SSL uppsägning;
- arbetar med websockets.
Nu till jämförelsepunkterna:
Protokoll som stöds
Ett av de grundläggande urvalskriterierna. Din programvara kanske inte fungerar på standard HTTP, eller så kan den kräva arbete på flera protokoll samtidigt. Om ditt fall inte är standard, se till att ta hänsyn till denna faktor så att du inte behöver konfigurera om klustret senare. För alla styrenheter varierar listan över protokoll som stöds.
programvara i kärnan
Det finns flera varianter av applikationer som styrenheten är baserad på. Populära är nginx, traefik, haproxy, envoy. I det allmänna fallet kanske det inte har så stor effekt på hur trafik tas emot och sänds, men det är alltid användbart att känna till de potentiella nyanserna och funktionerna i vad som finns "under huven".
Trafikdirigering
På grundval av vad är det möjligt att fatta ett beslut om trafikriktningen till en viss tjänst? Vanligtvis är dessa värd och väg, men det finns ytterligare möjligheter.
Namnutrymme i ett kluster
Namnområde (namnutrymme) - förmågan att logiskt dela resurser i Kubernetes (till exempel på scen, produktion, etc.). Det finns Ingress-kontroller som måste installeras separat i varje namnområde (och då kan den dirigera trafik endast till baljorna i detta utrymme). Och det finns de (och deras klara majoritet) som fungerar globalt för hela klustret - i dem dirigeras trafiken till vilken pod som helst i klustret, oavsett namnutrymmet.
Prover för uppströms
Hur dirigeras trafik till hälsosamma instanser av applikationen, tjänsterna? Det finns alternativ med aktiva och passiva kontroller, återförsök, strömbrytare (För mer information, se t.ex. ), egna implementeringar av hälsokontroller (anpassade hälsokontroller) m.m. En mycket viktig parameter om du har höga krav på tillgänglighet och snabb borttagning av misslyckade tjänster från balansering.
Balanseringsalgoritmer
Det finns många alternativ: från traditionella till det exotiska , såväl som individuella funktioner som .
autentisering
Vilka auktoriseringssystem stöder den registeransvarige? Basic, digest, oauth, extern-auth - jag tror att dessa alternativ borde vara bekanta. Detta är ett viktigt kriterium om det finns många utvecklare (och/eller bara privata) loopar som nås via Ingress.
Trafikfördelning
Stöder styrenheten sådana vanliga trafikdistributionsmekanismer som kanariefågelutrullningar (kanariefågel), A/B-testning, trafikspegling (spegling/skuggning)? Detta är ett riktigt ömt ämne för applikationer som kräver exakt och exakt trafikhantering för produktiv testning, felsökning av produktbuggar offline (eller med minimal förlust), trafikanalys och så vidare.
Betalt abonnemang
Finns det ett betalalternativ för kontrollern, med avancerad funktionalitet och/eller teknisk support?
Grafiskt användargränssnitt (webbgränssnitt)
Finns det något GUI för att hantera kontrollerkonfigurationen? Främst för "handiness" och/eller för de som behöver göra några ändringar i Ingress'a-konfigurationen, men att arbeta med "rå" mallar är obekvämt. Det kan vara användbart om utvecklare vill utföra några experiment med trafik i farten.
JWT-validering
Förekomsten av inbyggd validering av JSON-webbtokens för auktorisering och validering av användaren till slutapplikationen.
Möjlighet till konfigurationsanpassning
Mallutvidgningsbarhet i betydelsen att ha mekanismer som låter dig lägga till dina egna direktiv, flaggor etc. till standardkonfigurationsmallar.
Grundläggande DDOS-skyddsmekanismer
Enkla hastighetsgränsalgoritmer eller mer komplexa trafikfiltreringsalternativ baserade på adresser, vitlistor, länder etc.
Begär spår
Möjligheten att övervaka, spåra och felsöka förfrågningar från ingresser till specifika tjänster/poddar, och helst även mellan tjänster/pods.
WAF
Support .
Styrenheter
Listan över kontrollanter bildades utifrån и . Vi uteslöt några av dem från granskningen på grund av specificitet eller låg prevalens (tidigt utvecklingsstadium). Resten diskuteras nedan. Låt oss börja med en allmän beskrivning av lösningarna och fortsätta med en sammanfattningstabell.
Ingress från Kubernetes
webbplats:
Licens: Apache 2.0
Detta är den officiella kontrollern för Kubernetes och utvecklas av communityn. Uppenbarligen från namnet är den baserad på nginx och kompletteras av en annan uppsättning Lua-plugins som används för att implementera ytterligare funktioner. På grund av populariteten för själva nginx och minimala modifieringar av den när den används som en kontroller, kan det här alternativet vara det enklaste och enklaste att konfigurera för den genomsnittliga ingenjören (med webberfarenhet).
Ingress av NGINX Inc.
webbplats:
Licens: Apache 2.0
Den officiella produkten från nginx-utvecklarna. Har en betalversion baserad på . Huvudidén är en hög nivå av stabilitet, konstant bakåtkompatibilitet, frånvaron av några främmande moduler och den deklarerade ökade hastigheten (jämfört med den officiella kontrollern), uppnådd på grund av avslaget av Lua.
Den fria versionen är avsevärt reducerad, även jämfört med den officiella kontrollern (på grund av bristen på samma Lua-moduler). Samtidigt har den betalda en ganska bred ytterligare funktionalitet: realtidsmätvärden, JWT-validering, aktiva hälsokontroller och mer. En viktig fördel gentemot NGINX Ingress är fullt stöd för TCP/UDP-trafik (och i communityversionen också!). Minus - trafikdistributionsfunktion, som dock "har högsta prioritet för utvecklare", men tar tid att implementera.
Kong Ingress
webbplats:
Licens: Apache 2.0
Produkt utvecklad av Kong Inc. i två versioner: kommersiell och gratis. Baserat på nginx, som har utökats med ett stort antal Lua-moduler.
Inledningsvis var det fokuserat på att bearbeta och dirigera API-förfrågningar, d.v.s. som en API Gateway, men för tillfället har den blivit en fullfjädrad Ingress-kontroller. Huvudfördelar: många extra moduler (inklusive de från tredjepartsutvecklare) som är enkla att installera och konfigurera och med hjälp av vilka ett brett utbud av ytterligare funktioner implementeras. Men inbyggda funktioner erbjuder redan många möjligheter. Jobbkonfiguration görs med hjälp av CRD-resurser.
En viktig egenskap hos produkten - att arbeta inom samma kontur (istället för kors-namnavstånd) är ett kontroversiellt ämne: för vissa kommer det att verka som en nackdel (du måste producera enheter för varje kontur), och för någon är det en funktion ( bоStörre nivå av isolering, som om en styrenhet är trasig, är problemet begränsat till enbart kretsen).
Traefik
webbplats:
Licens: MIT
En proxy som ursprungligen skapades för att fungera med begäran om routing för mikrotjänster och deras dynamiska miljö. Därför många användbara funktioner: uppdatering av konfigurationen utan att starta om alls, stöd för ett stort antal balanseringsmetoder, webbgränssnitt, vidarebefordran av mätvärden, stöd för olika protokoll, REST API, canary-utgåvor och mycket mer. En annan trevlig funktion är stöd för Let's Encrypt-certifikat direkt. Nackdelen är att för att organisera hög tillgänglighet (HA) måste styrenheten installera och ansluta sin egen KV-lagring.
haproxy
webbplats:
Licens: Apache 2.0
HAProxy har länge varit känt som en proxy och trafikbalanserare. Som en del av ett Kubernetes-kluster erbjuder det en "mjuk" konfigurationsuppdatering (utan förlust av trafik), tjänsteupptäckt baserad på DNS, dynamisk konfiguration med API. Det kan vara attraktivt att helt anpassa konfigurationsmallen genom att ersätta CM, liksom möjligheten att använda Sprigs biblioteksfunktioner i den. I allmänhet ligger huvudvikten i lösningen på hög hastighet, dess optimering och effektivitet i förbrukade resurser. Fördelen med styrenheten är stödet av ett rekordantal olika balanseringsmetoder.
Voyager
webbplats:
Licens: Apache 2.0
Baserad på HAproxy controller, som är positionerad som en universell lösning som stöder ett brett utbud av funktioner hos ett stort antal leverantörer. En möjlighet erbjuds för att balansera trafik på L7 och L4, och att balansera TCP L4-trafik som helhet kan kallas en av lösningens nyckelfunktioner.
Contour
webbplats:
Licens: Apache 2.0
Denna lösning är inte bara baserad på Envoy: den har utvecklats av gemensamt med författarna till denna populära proxy. En viktig funktion är möjligheten att separera kontroll av Ingress-resurser med IngressRoute CRD-resurser. För organisationer med många utvecklingsteam som använder samma kluster hjälper detta till att maximera säkerheten för att arbeta med trafik i angränsande slingor och skydda dem från fel vid byte av Ingress-resurser.
Den erbjuder också en utökad uppsättning balanseringsmetoder (det finns begäransspegling, automatisk upprepning, begränsning av begäranden och mycket mer), detaljerad övervakning av trafikflöden och fel. Kanske för någon kommer det att vara en betydande nackdel bristen på stöd för klibbiga sessioner (även om arbetet ).
Istio Ingress
webbplats:
Licens: Apache 2.0
En omfattande service mesh-lösning som inte bara är en Ingress-kontroller som hanterar inkommande trafik utifrån, utan också styr all trafik inom klustret. Under huven används Envoy som sidovagnsproxy för varje tjänst. I grund och botten är detta en stor kombination som "kan göra vad som helst", och dess huvudidé är maximal hanterbarhet, utbyggbarhet, säkerhet och transparens. Med den kan du finjustera trafikdirigering, åtkomstbehörighet mellan tjänster, balansering, övervakning, kanariefågelsläpp och mycket mer. Läs mer om Istio i artikelserien "".
Ambassadör
webbplats:
Licens: Apache 2.0
En annan lösning baserad på Envoy. Den har gratis och kommersiella versioner. Det är positionerat som "helt inbyggt i Kubernetes", vilket ger motsvarande fördelar (snäv integration med metoderna och enheterna i K8s-klustret).
Jämförelsetabell
Så kulmen på artikeln är denna enorma tabell:
Den är klickbar för en närmare bild och finns även i formatet .
för att sammanfatta
Syftet med den här artikeln är att ge en mer fullständig förståelse (dock inte på något sätt uttömmande!) av vilket val du ska göra i just ditt fall. Som vanligt har varje styrenhet sina egna fördelar och nackdelar...
Den klassiska Ingress från Kubernetes är bra för sin tillgänglighet och bevisbarhet, tillräckligt rika funktioner - i det allmänna fallet borde det vara "tillräckligt för ögonen". Men om det finns ökade krav på stabilitet, nivå på funktioner och utveckling bör du vara uppmärksam på Ingress med NGINX Plus och ett betalabonnemang. Kong har den rikaste uppsättningen plug-ins (och följaktligen de möjligheter de ger), och i den betalda versionen finns det ännu fler av dem. Den har stora möjligheter att arbeta som en API-gateway, dynamisk konfiguration baserad på CRD-resurser, samt grundläggande Kubernetes-tjänster.
Med ökade krav på balansering och auktoriseringsmetoder, ta en titt på Traefik och HAProxy. Dessa är Open Source-projekt, beprövade genom åren, mycket stabila och aktivt utvecklande. Contour har varit ute i ett par år nu, men det ser fortfarande för ungt ut och har bara grundläggande funktioner som lagts till ovanpå Envoy. Om det finns krav på närvaro/inbäddning av WAF framför applikationen bör du vara uppmärksam på samma Ingress från Kubernetes eller HAProxy.
Och de rikaste när det gäller funktioner är produkter byggda ovanpå Envoy, särskilt Istio. Det verkar vara en heltäckande lösning som "kan göra vad som helst", vilket dock också innebär en betydligt högre ingångströskel för konfiguration/lansering/administration än andra lösningar.
Vi har valt och använder fortfarande Ingress från Kubernetes som en standardkontroller, som täcker 80-90% av behoven. Det är ganska pålitligt, lätt att konfigurera och utöka. I allmänhet, i avsaknad av specifika krav, bör det passa de flesta kluster/applikationer. Av samma universella och relativt enkla produkter kan Traefik och HAProxy rekommenderas.
PS
Läs även på vår blogg:
- "Tillbaka till mikrotjänster med Istio": , , ;
- «";
- «".
Källa: will.com