Hej, Habr! Jag presenterar för din uppmärksamhet en översättning av artikeln "Service mesh dataplan vs kontrollplan" författare Matt Klein.

Den här gången "ville och översätta" jag beskrivningen av både service mesh-komponenter, dataplan och styrplan. Denna beskrivning föreföll mig som den mest förståeliga och intressanta, och viktigast av allt att leda till förståelsen av "Är det nödvändigt överhuvudtaget?"

Eftersom idén med ett "Service mesh" har blivit allt mer populärt under de senaste två åren (Originalartikel 10 oktober 2017) och antalet deltagare i utrymmet har ökat, har jag sett en proportionell ökning av förvirring bland hela teknikgemenskap om hur man jämför och kontrasterar olika lösningar.

Situationen sammanfattas bäst av följande serie tweets jag skrev i juli:

Servicenätförvirring #1: Linkerd ~ = Nginx ~ = Haproxy ~ = Envoy. Ingen av dem är lika med Istio. Istio är något helt annat. 1 /

De första är helt enkelt dataplan. Av sig själva gör de ingenting. De måste vara på humör för något mer. 2/

Istio är ett exempel på ett kontrollplan som binder samman delarna. Detta är ett annat lager. /slutet

De tidigare tweetarna nämner flera olika projekt (Linkerd, NGINX, HAProxy, Envoy och Istio), men ännu viktigare introducerar de allmänna begreppen dataplan, servicenät och kontrollplan. I det här inlägget ska jag ta ett steg tillbaka och prata om vad jag menar med termerna "dataplan" och "kontrollplan" på väldigt hög nivå, och sedan prata om hur termerna gäller för de projekt som nämns i tweets.

Vad är ett servicenät egentligen?

Figur 1: Servicenätöversikt

Figur 1 illustrerar konceptet med ett servicenät på dess mest grundläggande nivå. Det finns fyra tjänstekluster (AD). Varje tjänsteinstans är associerad med en lokal proxyserver. All nätverkstrafik (HTTP, REST, gRPC, Redis, etc.) från en enda applikationsinstans skickas via en lokal proxy till lämpliga externa tjänstekluster. På så sätt är applikationsinstansen omedveten om nätverket som helhet och bara medveten om dess lokala proxy. I själva verket togs det distribuerade systemnätverket bort från tjänsten.

Dataplan

I ett tjänstnätverk utför en proxyserver lokalt för applikationen följande uppgifter:

• Service upptäckt. Vilka tjänster/applikationer finns tillgängliga för din applikation?
• Hälsokontroll. Är tjänsteinstanserna som returneras av tjänsteupptäckt sunda och redo att acceptera nätverkstrafik? Detta kan inkludera både aktiva (t.ex. svar/hälsokontroll) och passiva (t.ex. att använda 3 på varandra följande 5xx-fel som en indikation på ett ohälsosamt servicetillstånd) hälsokontroller.
• Routing. När man tar emot en begäran till "/foo" från en REST-tjänst, vilket tjänstekluster ska begäran skickas till?
• Lastbalansering. När ett tjänstekluster har valts under routing, till vilken tjänsteinstans ska begäran skickas? Med vilken timeout? Med vilka strömbrytningsinställningar? Om begäran misslyckas, ska den försökas igen?
• Autentisering och auktorisering. För inkommande förfrågningar, kan den anropande tjänsten identifieras/auktoriseras kryptografiskt med hjälp av mTLS eller någon annan mekanism? Om det känns igen/auktoriserat, är det tillåtet att anropa den begärda operationen (slutpunkten) på tjänsten eller ska ett oautentiserat svar returneras?
• Observerbarhet. Detaljerad statistik, loggar/loggar och distribuerade spårningsdata bör genereras för varje begäran så att operatörer kan förstå distribuerat trafikflöde och felsökningsproblem när de uppstår.

Dataplanet ansvarar för alla tidigare punkter i servicenätet. Faktum är att proxyn som är lokal för tjänsten (sidecar) är dataplanet. Med andra ord är dataplanet ansvarigt för att villkorligt sända, vidarebefordra och övervaka varje nätverkspaket som skickas till eller från en tjänst.

Kontrollplanet

Nätverksabstraktionen som en lokal proxy tillhandahåller i dataplanet är magisk(?). Men hur vet proxyn egentligen om "/foo"-vägen till tjänst B? Hur kan tjänstupptäcktsdata som fylls i av proxyförfrågningar användas? Hur är parametrarna konfigurerade för lastbalansering, timeout, kretsbrott, etc.? Hur distribuerar du en applikation med den blå/gröna metoden eller den graciösa trafikövergångsmetoden? Vem konfigurerar systemomfattande autentiserings- och auktoriseringsinställningar?

Alla ovanstående föremål är under kontroll av kontrollplanet för servicenätet. Kontrollplanet tar en uppsättning isolerade tillståndslösa proxyservrar och förvandlar dem till ett distribuerat system.

Jag tror att anledningen till att många teknologer tycker att de separata begreppen dataplan och kontrollplan är förvirrande är att för de flesta människor är dataplanet bekant medan kontrollplanet är främmande/oförstått. Vi har arbetat med fysiska nätverksroutrar och switchar under lång tid. Vi förstår att paket/förfrågningar måste gå från punkt A till punkt B och att vi kan använda hårdvara och mjukvara för att göra detta. Den nya generationen av mjukvaruproxyer är helt enkelt snygga versioner av de verktyg vi har använt under lång tid.

Figur 2: Mänskligt kontrollplan

Däremot har vi använt kontrollplan under lång tid, även om de flesta nätoperatörer kanske inte associerar denna del av systemet med någon teknikkomponent. Anledningen är enkel:
De flesta kontrollplan som används idag är... vi.

På figur 2 visar vad jag kallar det "mänskliga kontrollplanet". I den här typen av distribution, som fortfarande är mycket vanlig, skapar en förmodligen grinig mänsklig operatör statiska konfigurationer - potentiellt via skript - och distribuerar dem genom någon speciell process till alla proxyservrar. Proxyerna börjar sedan använda denna konfiguration och börjar bearbeta dataplanet med de uppdaterade inställningarna.

Figur 3: Avancerat kontrollplan för servicenät

På figur 3 visar det "förlängda" kontrollplanet för servicenätet. Den består av följande delar:

• Människan: Det finns fortfarande en person (förhoppningsvis mindre arg) som fattar beslut på hög nivå när det gäller hela systemet som helhet.
• Kontrollplans UI: En person interagerar med någon typ av användargränssnitt för att styra systemet. Detta kan vara en webbportal, en kommandoradsapplikation (CLI) eller något annat gränssnitt. Genom att använda användargränssnittet har operatören tillgång till globala systemkonfigurationsparametrar som:
  • Utbyggnadskontroll, blå/grön och/eller gradvis trafikövergång
  • Autentiserings- och auktoriseringsalternativ
  • Rutningstabellspecifikationer, till exempel när applikation A begär information om "/foo" vad som händer
  • Inställningar för belastningsutjämnare, såsom timeouts, återförsök, kretsbrytningsinställningar, etc.
• Arbetsbelastningsschemaläggare: Tjänster körs på infrastrukturen genom någon typ av schemaläggning/orkestreringssystem, som Kubernetes eller Nomad. Schemaläggaren ansvarar för att ladda tjänsten tillsammans med dess lokala proxy.
• Service upptäckt. När schemaläggaren startar och stoppar tjänsteinstanser rapporterar den hälsostatusen till tjänsteupptäcktssystemet.
• Sidecar proxy-konfigurations-API:er : Lokala proxyservrar extraherar dynamiskt tillstånd från olika systemkomponenter med hjälp av en så småningom konsekvent modell utan operatörsingripande. Hela systemet, bestående av alla tjänsteinstanser som för närvarande körs och lokala proxyservrar, konvergerar slutligen till ett ekosystem. Envoys universella dataplans-API är ett exempel på hur detta fungerar i praktiken.

I huvudsak är syftet med kontrollplanet att ställa in den policy som i slutändan kommer att accepteras av dataplanet. Mer avancerade styrplan kommer att ta bort fler delar av vissa system från operatören och kräver mindre manuell drift, förutsatt att de fungerar korrekt!...

Dataplan och kontrollplan. Sammanfattning av dataplan kontra kontrollplan

• Service mesh dataplan: Påverkar varje paket/begäran i systemet. Ansvarig för applikation/tjänstupptäckt, hälsokontroll, routing, lastbalansering, autentisering/auktorisering och observerbarhet.
• Kontrollplan för servicenät: Tillhandahåller policy och konfiguration för alla dataplan som körs inom servicenätverket. Rör inte några paket/förfrågningar på systemet. Kontrollplanet förvandlar alla dataplan till ett distribuerat system.

Aktuellt projektlandskap

Efter att ha förstått förklaringen ovan, låt oss titta på det nuvarande tillståndet för servicenätprojektet.

• Dataplan: Linkerd, NGINX, HAProxy, Envoy, Traefik
• Styrplan: Istio, Nelson, SmartStack

Istället för att gå in på en djupgående analys av var och en av lösningarna ovan, kommer jag kort att ta upp några av de punkter som jag tror orsakar mycket av förvirringen i ekosystemet just nu.

Linkerd var en av de första dataplanets proxyservrar för servicenätverket i början av 2016 och har gjort ett fantastiskt jobb med att öka medvetenheten och uppmärksamheten kring designmodellen för servicenätverk. Ungefär 6 månader efter det gick Envoy med i Linkerd (även om han hade varit med Lyft sedan slutet av 2015). Linkerd och Envoy är de två projekt som oftast nämns när man diskuterar servicenät.

Istio tillkännagavs i maj 2017. Målen för Istio-projektet är mycket lika det utökade kontrollplanet som visas i figur 3. Envoy för Istio är standardproxy. Således är Istio kontrollplanet och Envoy är dataplanet. På kort tid genererade Istio mycket spänning och andra dataplan började integreras som ersättning för Envoy (både Linkerd och NGINX demonstrerade integration med Istio). Det faktum att olika dataplan kan användas inom samma kontrollplan innebär att kontrollplanet och dataplanet inte nödvändigtvis är tätt kopplade. Ett API som Envoys generiska dataplans API kan bilda en brygga mellan två delar av systemet.

Nelson och SmartStack hjälper till att ytterligare illustrera separationen mellan kontrollplanet och dataplanet. Nelson använder Envoy som sin proxy och bygger ett pålitligt kontrollplan för servicenätet baserat på HashiCorp-stacken, d.v.s. Nomad osv. SmartStack var kanske den första av en ny våg av servicenät. SmartStack bygger ett kontrollplan runt HAProxy eller NGINX, vilket visar förmågan att koppla bort kontrollplanet från servicenätet från dataplanet.

Mikrotjänstarkitektur med ett servicenät får mer och mer uppmärksamhet (med rätta!), och fler och fler projekt och leverantörer börjar arbeta i denna riktning. Under de närmaste åren kommer vi att se mycket innovation inom både dataplanet och kontrollplanet, samt ytterligare blandning av olika komponenter. I slutändan bör mikrotjänstarkitekturen bli mer transparent och magisk (?) för operatören.
Förhoppningsvis mindre och mindre irriterad.

Nyckel takeaways

• Ett servicenät består av två olika delar: dataplanet och kontrollplanet. Båda komponenterna krävs, och utan dem fungerar inte systemet.
• Alla är bekanta med kontrollplanet, och vid det här laget kan kontrollplanet vara du!
• Alla dataplan konkurrerar med varandra när det gäller funktioner, prestanda, konfigurerbarhet och utbyggbarhet.
• Alla kontrollplan konkurrerar med varandra i funktioner, konfigurerbarhet, utbyggbarhet och användarvänlighet.
• Ett kontrollplan kan innehålla rätt abstraktioner och API:er så att flera dataplan kan användas.

Källa: will.com