Hej Habr! Jeg præsenterer for din opmærksomhed oversættelsen af ​​artiklen "Service mesh dataplan vs kontrolplan" forfatter Matt Klein.

Denne gang "ønskede og oversatte" jeg beskrivelsen af ​​både service mesh-komponenter, dataplan og kontrolplan. Denne beskrivelse forekom mig den mest forståelige og interessante, og vigtigst af alt førte den til forståelsen af ​​"Er det overhovedet nødvendigt?"

Da ideen om et "Service mesh" er blevet mere og mere populær i løbet af de sidste to år (Original artikel 10. oktober 2017), og antallet af deltagere i rummet er steget, har jeg set en tilsvarende stigning i forvirring blandt hele tech community om, hvordan man sammenligner og kontrasterer forskellige løsninger.

Situationen opsummeres bedst af følgende serie af tweets, jeg skrev i juli:

Tjenestenetforvirring #1: Linkerd ~ = Nginx ~ = Haproxy ~ = Envoy. Ingen af ​​dem er lig med Istio. Istio er noget helt andet. 1 /

De første er simpelthen datafly. I sig selv gør de ikke noget. De skal være i humør til noget mere. 2/

Istio er et eksempel på et kontrolplan, der binder delene sammen. Dette er endnu et lag. /ende

De tidligere tweets nævner flere forskellige projekter (Linkerd, NGINX, HAProxy, Envoy og Istio), men endnu vigtigere introducerer de generelle begreber dataplan, servicemesh og kontrolplan. I dette indlæg vil jeg træde et skridt tilbage og tale om, hvad jeg mener med begreberne "dataplan" og "kontrolplan" på et meget højt niveau, og derefter tale om, hvordan vilkårene gælder for de projekter, der er nævnt i tweets.

Hvad er et servicenet egentlig?

Figur 1: Oversigt over servicenet

Figur 1 illustrerer konceptet med et servicenet på dets mest grundlæggende niveau. Der er fire serviceklynger (AD). Hver tjenesteinstans er knyttet til en lokal proxyserver. Al netværkstrafik (HTTP, REST, gRPC, Redis osv.) fra en enkelt applikationsforekomst sendes gennem en lokal proxy til de relevante eksterne tjenesteklynger. På denne måde er applikationsforekomsten uvidende om netværket som helhed og kun opmærksom på dets lokale proxy. Faktisk blev det distribuerede systemnetværk fjernet fra tjenesten.

Dataplan

I et servicenetværk udfører en proxyserver, der er lokaliseret til applikationen, følgende opgaver:

• Service opdagelse. Hvilke tjenester/applikationer er tilgængelige for din applikation?
• Sundhedstjek. Er de tjenesteforekomster, der returneres af serviceopdagelse, sunde og klar til at acceptere netværkstrafik? Dette kan omfatte både aktive (f.eks. svar/sundhedstjek) og passive (f.eks. brug af 3 på hinanden følgende 5xx fejl som en indikation på en usund servicetilstand) sundhedstjek.
• Routing. Når du modtager en anmodning til "/foo" fra en REST-tjeneste, hvilken tjenesteklynge skal anmodningen sendes til?
• Lastbalancering. Når en serviceklynge er blevet valgt under routing, til hvilken serviceinstans skal anmodningen sendes? Med hvilken timeout? Med hvilke strømafbryderindstillinger? Hvis anmodningen mislykkes, skal den så prøves igen?
• Autentificering og autorisation. For indgående anmodninger, kan den opkaldende tjeneste identificeres/autoriseres kryptografisk ved hjælp af mTLS eller en anden mekanisme? Hvis det er genkendt/autoriseret, er det så tilladt at kalde den anmodede operation (slutpunkt) på tjenesten, eller skal et ikke-godkendt svar returneres?
• Observerbarhed. Detaljerede statistikker, logfiler/logfiler og distribuerede sporingsdata bør genereres for hver anmodning, så operatører kan forstå distribueret trafikflow og fejlfindingsproblemer, efterhånden som de opstår.

Dataplanet er ansvarlig for alle tidligere punkter i servicenettet. Faktisk er den lokale proxy for tjenesten (sidecar) dataplanet. Med andre ord er dataplanet ansvarlig for betinget udsendelse, videresendelse og overvågning af hver netværkspakke, der sendes til eller fra en tjeneste.

Kontrolplanet

Netværksabstraktionen, som en lokal proxy giver i dataplanet, er magisk(?). Men hvordan ved proxyen egentlig om "/foo"-ruten til service B? Hvordan kan tjenestegenkendelsesdata, der er udfyldt af proxy-anmodninger, bruges? Hvordan er parametrene konfigureret til belastningsbalancering, timeout, kredsløbsbrud osv.? Hvordan implementerer du en applikation ved hjælp af den blå/grønne metode eller den yndefulde trafikovergangsmetode? Hvem konfigurerer systemdækkende godkendelses- og autorisationsindstillinger?

Alle de ovennævnte elementer er under kontrol af servicenettets kontrolplan. Kontrolplanet tager et sæt af isolerede statsløse proxyer og forvandler dem til et distribueret system.

Jeg tror, ​​at grunden til, at mange teknologer finder de separate begreber dataplan og kontrolplan forvirrende, er fordi dataplanet for de fleste mennesker er velkendt, mens kontrolplanet er fremmed/uforstået. Vi har arbejdet med fysiske netværksroutere og switche i lang tid. Vi forstår, at pakker/anmodninger skal gå fra punkt A til punkt B, og at vi kan bruge hardware og software til at gøre dette. Den nye generation af softwareproxyer er simpelthen smarte versioner af de værktøjer, vi har brugt i lang tid.

Figur 2: Menneskelig kontrolplan

Vi har dog brugt kontrolfly i lang tid, selvom de fleste netværksoperatører måske ikke forbinder denne del af systemet med nogen teknologikomponent. Årsagen er enkel:
De fleste kontrolfly i brug i dag er... vi.

On Figur 2 viser det, jeg kalder "det menneskelige kontrolfly". I denne type implementering, som stadig er meget almindelig, skaber en sandsynligvis gnaven menneskelig operatør statiske konfigurationer - potentielt via scripts - og implementerer dem gennem en speciel proces til alle proxyerne. Proxyerne begynder derefter at bruge denne konfiguration og begynder at behandle dataplanet ved hjælp af de opdaterede indstillinger.

Figur 3: Avanceret service mesh kontrolplan

On Figur 3 viser det "udvidede" kontrolplan for servicenettet. Den består af følgende dele:

• Mennesket: Der er stadig en person (forhåbentlig mindre vred), der træffer beslutninger på højt niveau vedrørende hele systemet som helhed.
• Kontrolplan UI: En person interagerer med en form for brugergrænseflade for at styre systemet. Dette kan være en webportal, en kommandolinjeapplikation (CLI) eller en anden grænseflade. Ved hjælp af brugergrænsefladen har operatøren adgang til globale systemkonfigurationsparametre såsom:
  • Implementeringskontrol, blå/grøn og/eller gradvis trafikovergang
  • Godkendelses- og autorisationsmuligheder
  • Rutingtabelspecifikationer, for eksempel når applikation A anmoder om information om "/foo", hvad der sker
  • Load balancer-indstillinger, såsom timeouts, genforsøg, kredsløbsafbrydelsesindstillinger osv.
• Arbejdsbelastningsplanlægger: Tjenester kører på infrastrukturen gennem en eller anden form for planlægning/orkestreringssystem, såsom Kubernetes eller Nomad. Planlæggeren er ansvarlig for at indlæse tjenesten sammen med dens lokale proxy.
• Service opdagelse. Når planlæggeren starter og stopper serviceforekomster, rapporterer den sundhedsstatus til serviceopdagelsessystemet.
• Sidecar proxy-konfigurations-API'er : Lokale proxyer udtrækker dynamisk tilstand fra forskellige systemkomponenter ved hjælp af en til sidst konsistent model uden operatørindblanding. Hele systemet, der består af alle aktuelt kørende serviceinstanser og lokale proxyservere, konvergerer i sidste ende til ét økosystem. Envoys universelle dataplan API er et eksempel på, hvordan dette fungerer i praksis.

Grundlæggende er formålet med kontrolplanet at sætte den politik, der i sidste ende vil blive accepteret af dataplanet. Mere avancerede kontrolfly vil fjerne flere dele af nogle systemer fra operatøren og kræver mindre manuel betjening, forudsat at de fungerer korrekt!...

Dataplan og kontrolplan. Opsummering af dataplan vs. kontrolplan

• Service mesh dataplan: Påvirker hver pakke/anmodning i systemet. Ansvarlig for applikations-/serviceopdagelse, sundhedstjek, routing, belastningsbalancering, autentificering/autorisation og observerbarhed.
• Servicenet kontrolplan: Giver politik og konfiguration for alle kørende dataplaner i servicenetværket. Rører ikke nogen pakker/anmodninger på systemet. Kontrolplanet gør alle dataplaner til et distribueret system.

Aktuelt projektlandskab

Efter at have forstået forklaringen ovenfor, lad os se på den aktuelle tilstand af service mesh-projektet.

• Data fly: Linkerd, NGINX, HAProxy, Envoy, Traefik
• Kontrol fly: Istio, Nelson, SmartStack

I stedet for at gå ind i en dybdegående analyse af hver af løsningerne ovenfor, vil jeg kort tage fat på nogle af de punkter, som jeg mener forårsager meget af forvirringen i økosystemet lige nu.

Linkerd var en af ​​de første dataplan-proxy-servere til servicenetværket i begyndelsen af ​​2016 og har gjort et fantastisk stykke arbejde med at øge bevidstheden om og opmærksomheden på servicemesh-designmodellen. Omkring 6 måneder efter det sluttede Envoy sig til Linkerd (selvom han havde været hos Lyft siden slutningen af ​​2015). Linkerd og Envoy er de to projekter, der oftest nævnes, når man diskuterer servicemasker.

Istio blev annonceret i maj 2017. Målene for Istio-projektet ligner meget det udvidede kontrolplan vist i Figur 3. Envoy for Istio er standard proxy. Således er Istio kontrolplanet, og Envoy er dataplanet. På kort tid skabte Istio en masse spænding, og andre datafly begyndte at blive integreret som erstatning for Envoy (både Linkerd og NGINX demonstrerede integration med Istio). Det faktum, at forskellige dataplaner kan bruges inden for det samme kontrolplan betyder, at kontrolplanet og dataplanet ikke nødvendigvis er tæt forbundet. En API såsom Envoys generiske dataplan API kan danne en bro mellem to dele af systemet.

Nelson og SmartStack hjælper yderligere med at illustrere adskillelsen af ​​kontrolplanet og dataplanet. Nelson bruger Envoy som sin proxy og bygger et pålideligt kontrolplan til servicenetværket baseret på HashiCorp-stakken, dvs. Nomade osv. SmartStack var måske den første af en ny bølge af servicenet. SmartStack bygger et kontrolplan omkring HAProxy eller NGINX, hvilket demonstrerer evnen til at afkoble kontrolplanet fra servicenettet fra dataplanet.

Mikroservicearkitektur med et servicemesh får mere og mere opmærksomhed (med rette!), og flere og flere projekter og leverandører begynder at arbejde i denne retning. I løbet af de næste par år vil vi se en masse innovation i både dataplanet og kontrolplanet, samt yderligere blanding af forskellige komponenter. I sidste ende bør mikroservicearkitektur blive mere gennemsigtig og magisk (?) for operatøren.
Forhåbentlig mindre og mindre irriteret.

Nøgle takeaways

• Et servicenet består af to forskellige dele: dataplanet og kontrolplanet. Begge komponenter er påkrævet, og uden dem fungerer systemet ikke.
• Alle er bekendt med kontrolplanet, og på dette tidspunkt kan kontrolplanet være dig!
• Alle dataplaner konkurrerer med hinanden om funktioner, ydeevne, konfigurerbarhed og udvidelsesmuligheder.
• Alle kontrolplaner konkurrerer med hinanden i funktioner, konfigurerbarhed, udvidelsesmuligheder og brugervenlighed.
• Et kontrolplan kan indeholde de rigtige abstraktioner og API'er, så flere dataplaner kan bruges.

Kilde: www.habr.com