Hej, Habr! Jag presenterar översättningen av artikeln «Service mesh data plane vs control plane» författare Matt Klein.

Denna gång "kändes det som att det behövdes och översattes" beskrivningen av båda komponenterna i service mesh, data plane och control plane. Denna beskrivning verkade för mig vara den mest förståeliga och intressanta, framför allt ledande till insikten "Är det överhuvudtaget nödvändigt?".

Eftersom idén om "Service mesh" har blivit alltmer populär under de senaste två åren (ursprunglig artikel från 10 oktober 2017), och antalet aktörer inom området har ökat, har jag sett en motsvarande ökning av förvirringen inom hela det tekniska samfundet angående hur man jämför och ställer olika lösningar mot varandra.

Situationen kan bäst beskrivas med följande serier av tweets som jag skrev i juli:

Förvirring kring service mesh nummer 1: Linkerd ~ = Nginx ~ = Haproxy ~ = Envoy. Ingen av dem är lika med Istio. Istio är något helt annat. 1 /

De första är bara data planes. I sig själva gör de ingenting. De måste konfigureras för något mer. 2 /

Istio är ett exempel på en control plane som kopplar ihop delarna. Det är ett annat lager. / slut

I de tidigare tweets nämns flera olika projekt (Linkerd, NGINX, HAProxy, Envoy och Istio), men viktigare är att gemensamma begrepp som data plane, service mesh och control plane introduceras. I det här inlägget kommer jag att ta ett steg tillbaka och förklara vad jag menar med termerna "data plane" och "control plane" på en väldigt hög nivå, och sedan ska jag förklara hur dessa termer relaterar till projekten som nämns i tweets.

Vad är en service mesh egentligen?

Bild 1: Översikt över service mesh

Bild 1 illustrerar konceptet av service mesh på den mest grundläggande nivån. Det finns fyra servicekluster (A-D). Varje tjänstinstans är kopplad till en lokal proxyserver. All nätverkstrafik (HTTP, REST, gRPC, Redis, etc.) från enskild tjänstinstans går genom den lokala proxyservern till de tillhörande externa serviceklustren. På så sätt har inte tjänstinstansen kunskap om nätverket som helhet utan känner endast till sin lokala proxy. Faktiskt har nätverket av det distribuerade systemet avlägsnats från tjänsten.

Data plane

I en service mesh utför proxyservern, som är lokal för applikationen, följande uppgifter:

Tjänstupptäckning (Service discovery). Vilka tjänster/program är tillgängliga för din applikation?
Hälsokontroll (Health checking). Är instanserna av tjänsterna som returnerats av tjänstupptäckningen fungerande och beredda att ta emot nätverkstrafik? Detta kan inkludera både aktiv (t.ex. svarskontroll / healthcheck) och passiv (t.ex. genom att använda 3 på varandra följande 5xx-fel som en indikator på en ohälsosam tjänst) hälsokontroll.
Ruttning (Routing). När en REST-förfrågan kommer in till "\/foo", vilken tjänstkluster ska förfrågan skickas till?
Lastbalansering (Load balancing). Efter att ha valt ett tjänstkluster under ruttningen, till vilken instans av tjänsten ska förfrågan skickas? Med vilken tidsgräns? Med vilka inställningar för kretsbrytning? Om förfrågan misslyckades, ska den upprepas?
Autentisering och auktorisering (Authentication and authorization). Kan den anropande tjänsten identifieras/autentiseras kryptografiskt för inkommande förfrågningar via mTLS eller någon annan mekanism? Om den är identifierad/autentiserad, är den tillåten att anropa den begärda operationen (endpoint) i tjänsten eller ska ett icke-autentiserat svar returneras?
Observerbarhet (Observability). För varje förfrågan ska detaljerade statistikdata, loggar och data för distribuerad spårning genereras så att operatörerna kan förstå det distribuerade trafikflödet och problem vid felsökning när de uppstår.

Alla föregående punkter i tjänstenätverket (service mesh) övervakas av dataplanen (data plane). I grunden är den lokala sidokar- proxyn dataplanen (data plane). Med andra ord ansvarar dataplanen (data plane) för villkorlig översättning, vidarebefordran och övervakning av varje nätverkspaket som skickas till eller från tjänsten.

Kontrollplanen (The control plane)

Nätverksabstraktionen som tillhandahålls av den lokala proxy-servern i dataplatsen är magisk (?). Men hur får proxy-servern egentligen reda på vägen "\/foo" till tjänst B? Hur kan data för tjänstupptäckten (service discovery), som fylls på med proxy-förfrågningar, användas? Hur konfigureras parametrarna för belastningsbalansering, tidsgränser (timeout), kretsbrytare (circuit breaking) osv.? Hur sker distributionen av applikationen med hjälp av blå\/grön (blue\/green) metod eller metod för stegvis trafiköverföring? Vem konfigurerar parametrarna för systemövergripande autentisering och auktorisering?

Alla ovanstående punkter faller under kontrollplanet (control plane) i tjänstenätverket (service mesh). Kontrollplanet (control plane) tar en uppsättning isolerade proxy-servrar utan tillstånd och förvandlar dem till ett distribuerat system.

Jag tror att anledningen till att många teknologer finner de separerade begreppen dataplans (data plane) och kontrollplans (control plane) förvirrande är att dataplans är bekant för de flesta människor, medan kontrollplans är främmande\/oförståeligt. Vi har länge arbetat med fysiska nätverksroutrar och switchar. Vi förstår att paket\/förfrågningar måste gå från punkt A till punkt B, och vad vi kan använda för detta både hårdvara och mjukvara. Den nya generationens programvaru-proxyer är helt enkelt modevarianter av verktyg som vi har använt länge.

Figur 2: Mänskligt kontrollplan (Human control plane)

Men vi har redan länge använt kontrollplan (control plane), även om de flesta nätverksoperatörer kanske inte kopplar denna del av systemet till någon teknologisk komponent. Anledningen är enkel:
De flesta av de kontrollplaner (control plane) som används idag är… vi.

På figur 2 Det som jag kallar för "Mänskligt kontrollplan (Human control plane)" visas. I denna typ av distribution, som fortfarande är mycket vanlig, skapar en mänsklig operatör, förhoppningsvis mindre grinig, statiska konfigurationer – potentiellt med skript – och distribuerar dem med en specifik process till alla proxyservrar. Sedan börjar proxyservrarna använda denna konfiguration och hanterar dataplanen (data plane) med hjälp av de uppdaterade inställningarna.

Figur 3: Utvidgat kontrollplan för servicenetverk (Advanced service mesh control plane)

På figur 3 visar det "utvidgade" kontrollplanet (control plane) för servicenetverket (service mesh). Det består av följande delar:

Människa (The human): Det finns fortfarande en människa (förhoppningsvis mindre arg) som fattar övergripande beslut om hela systemet.
Användargränssnitt för kontrollplanet (Control plane UI): Människan interagerar med någon form av användargränssnitt för att styra systemet. Det kan vara en webbportal, kommandoradsapplikation (CLI) eller något annat gränssnitt. Genom användargränssnittet har operatören tillgång till globala systemkonfigurationsparametrar såsom:
- Distribution Management, blå/grön (blue/green) och/eller gradvis trafiköverföring
- Autentisering- och behörighetsinställningar
- Routingtabellsspecifikationer, till exempel vad som händer när applikation A begär information om "\/foo"
- Inställningar för belastningsutjämnare, till exempel timeout, retries, circuit breaking-parametrar etc.
Arbetslastplanerare (Workload scheduler): Tjänster startas i infrastrukturen genom ett schemaläggnings-/orkestreringssystem av något slag, till exempel Kubernetes eller Nomad. Schemaläggaren ansvarar för att lasta tjänsten tillsammans med dess lokala proxyserver.
Tjänstupptäckte (Service discovery). När schemaläggaren startar och stoppar tjänsteexemplar rapporterar den statusen till systemet för tjänstupptäckte.
API:er för konfiguration av lokal proxyserver (Sidecar proxy configuration APIs) : Lokala proxyservrar extraherar dynamiskt status från olika systemkomponenter med modellen "eventuellt konsekvent" utan operatörens deltagande. Hela systemet, som består av alla för närvarande körda instanser av tjänster och lokala proxyservrar, konvergerar till slut i ett ekosystem. API:et för den universella dataplanen i Envoy är ett exempel på hur detta fungerar i praktiken.

I grunden syftar kontrollplanet till att etablera en policy som slutligen kommer att antas av dataplanen. Mer avancerade kontrollplaner kommer att ta bort fler detaljer från operatören i vissa system och kräva mindre manuell hantering, förutsatt att de fungerar korrekt!..

Dataplan och kontrollplan. Sammanfattning (Data plane vs. control plane summary)

Dataplan för tjänstenätverk (Service mesh data plane): berör varje paket / begäran i systemet. Ansvarar för upptäckten av applikationer / tjänster, hälsokontroller, routing, lastbalansering, autentisering / auktorisering och observabilitet.
Kontrollplan för tjänstenätverk (Service mesh control plane): tillhandahåller policy och konfiguration för alla aktiva dataplaner inom tjänstenätverket. Rör inga paket / begärningar i systemet. Kontrollplanet omvandlar alla dataplaner till ett distribuerat system.

Aktuellt projektlandskap (Current project landscape)

Efter att ha behandlat ovanstående förklaring, låt oss titta på det aktuella tillståndet för projektet "tjänstenätverk (service mesh)."

Dataplaner (Data planes): Linkerd, NGINX, HAProxy, Envoy, Traefik
Kontrollplaner (Control planes): Istio, Nelson, SmartStack

Istället för att göra en djupgående analys av var och en av de ovanstående lösningarna, kommer jag kort att beröra några punkter som, enligt min mening, orsakar mycket av förvirringen i ekosystemet just nu.

I början av 2016 var Linkerd en av de första proxyservrarna för dataplansystemet (data plane) inom service mesh och gjorde ett fantastiskt jobb med att öka medvetenheten och intresset för designmodellen "service mesh". Ungefär sex månader senare anslöt sig Envoy till Linkerd (även om det arbetade på Lyft sedan slutet av 2015). Linkerd och Envoy är de två projekten som oftast nämns när man diskuterar service mesh.

Istio tillkännagavs i maj 2017. Målen för Istio-projektet är mycket liknande den utvidgade kontrollplanen (control plane) som visas på figur 3. Envoy för Istio är standardproxyservern. På så sätt är Istio kontrollplanen (control plane) och Envoy dataplanssystemet (data plane). På kort tid har Istio skapat mycket upphetsning, och andra dataplanssystem (data plane) har påbörjat integration som ett alternativ till Envoy (både Linkerd och NGINX har demonstrerat integration med Istio). Att olika dataplanssystem (data plane) kan användas inom en och samma kontrollplan (control plane) innebär att kontrollplanen (control plane) och dataplanssystemet (data plane) inte nödvändigtvis är nära kopplade. Ett API som det universella API:t för dataplanssystemet (data plane) Envoy kan skapa en bro mellan de två delarna av systemet.

Nelson och SmartStack hjälper ytterligare till att illustrera separationen mellan kontrollplanen (control plane) och dataplanssystemet (data plane). Nelson använder Envoy som sin proxy och bygger en pålitlig kontrollplan (control plane) för service mesh baserat på HashiCorp-stacken, d.v.s. Nomad osv. SmartStack har blivit, i stort sett, den första av den nya vågen av service mesh. SmartStack formar kontrollplanen (control plane) kring HAProxy eller NGINX, vilket visar möjligheten att lossa kopplingen mellan kontrollplanen (control plane) för service mesh och dataplanssystemet (data plane).

Mikrotjänstarkitektur med en servicemesh får allt mer uppmärksamhet (rätt!), och fler och fler projekt och leverantörer börjar arbeta i detta område. Under de kommande åren kommer vi att se många innovationer både inom dataplan (data plane) och styrplan (control plane), samt en fortsättning av blandningen av olika komponenter. I slutändan ska mikrotjänstarkitekturen bli mer transparent och magisk (?) för operatören.
Jag hoppas att alla blir mindre och mindre irriterade.

Nyckelpunkter (Key takeaways)

Servicemesh (service mesh) består av två olika delar: dataplan (data plane) och styrplan (control plane). Båda komponenterna är nödvändiga, och utan dem kommer systemet inte att fungera.
Alla känner till styrplan (control plane), och just nu kan det vara du som har styrplan (control plane)!
Alla dataplan (data plane) konkurrerar med varandra vad gäller funktionalitet, prestanda, konfigurerbarhet och skalbarhet.
Alla styrplan (control plane) konkurrerar med varandra vad gäller funktionalitet, konfigurerbarhet, skalbarhet och användarvänlighet.
Ett styrplan (control plane) kan innehålla rätt abstraktioner och API:er så att flera dataplan (data plane) kan användas.

Källa: habr.com