Hej, Habr! Jeg præsenterer for jer oversættelsen af artiklen «Service mesh data plane vs control plane» forfatter til Matt Klein.

Denne gang har jeg "været nødt til" at oversætte beskrivelsen af begge komponenter i service mesh, data plane og control plane. Denne beskrivelse syntes jeg var den mest forståelige og interessante, og vigtigst af alt førte den til en forståelse af, "Behøver vi det overhovedet?".

Da ideen om "Service mesh" er blevet mere populær i de seneste to år (oprindelig artikel fra den 10. oktober 2017), og antallet af deltagere i rummet er steget, har jeg set en tilsvarende stigning i forvirringen blandt det tekniske fællesskab med hensyn til, hvordan man sammenligner og kontrasterer forskellige løsninger.

Situationen kan bedst beskrives med følgende serier af tweets, jeg skrev i juli:

Forvirring omkring service mesh nr. 1: Linkerd ~ = Nginx ~ = Haproxy ~ = Envoy. Ingen af dem er lig med Istio. Istio er noget helt andet. 1 /

De første er blot data planes. I sig selv laver de ingenting. De skal konfigureres til noget større. 2 /

Istio er et eksempel på en control plane, der binder delene sammen. Det er et andet lag. /end

I de tidligere tweets nævnes flere forskellige projekter (Linkerd, NGINX, HAProxy, Envoy og Istio), men vigtigere er, at der introduceres de generelle begreber om data plane, service mesh og control plane. I dette indlæg vil jeg tage et skridt tilbage og forklare, hvad jeg mener med termerne "data plane" og "control plane" på et meget højt niveau og derefter forklare, hvordan termerne relaterer til de nævnte projekter i tweets.

Hvad er en service mesh, egentlig?

Figur 1: Oversigt over service mesh

Figur 1 illustrerer konceptet med service mesh på det mest grundlæggende niveau. Der er fire serviceklynger (A-D). Hver instans af en service er forbundet til en lokal proxyserver. Al netværkstrafik (HTTP, REST, gRPC, Redis osv.) fra hver enkelt applikationsinstans går gennem den lokale proxyserver til de relevante eksterne serviceklynger. Dermed kender applikationsinstansen ikke hele netværket og kender kun sin lokale proxy. Faktisk er netværket af det distribuerede system blevet adskilt fra servicen.

Data plane

I service mesh udfører den lokal proxyserver, der er placeret for applikationen, følgende opgaver:

• Tjenestebulking (Service discovery). Hvilke tjenester/udbydere/applikationer er tilgængelige for din applikation?
• Sundhedskontrol (Health checking). Er de tjenesteinstanser, der returneres ved tjenestebulking (service discovery), i stand til at modtage netværkstrafik? Dette kan inkludere både aktiv (f.eks. responskontrol / healthcheck) og passiv (f.eks. ved brug af 3 på hinanden følgende 5xx-fejl som indikation af en usund tilstand i tjenesten) sundhedskontrol.
• Ruteplanlægning (Routing). Hvilken tjenesteklynge skal en REST-forespørgsel til «/foo» sendes til?
• Lastbalancering (Load balancing). Når en tjenesteklynge er valgt under ruteplanlægning, hvilken tjenesteinstans skal anmodningen sendes til? Med hvilken timeout? Med hvilke indstillinger for circuit breaking? Hvis anmodningen mislykkes, skal den forsøges igen?
• Godkendelse og autorisation (Authentication and authorization). Kan den anmodende tjeneste identificeres/autoriseres kryptografisk via mTLS eller en anden mekanisme for indkommende anmodninger? Hvis den er identificeret/autoriseret, er den så tilladt at kalde den anmodede operation (endpoint) i tjenesten, eller skal der returneres et uautentificeret svar?
• Overvågelighed (Observability). For hver anmodning skal der genereres detaljerede statistikker, logs og data for distribueret sporing, så operatørerne kan forstå den distribuerede trafikflow og fejlretning, efterhånden som de opstår.

For alle de tidligere punkter i tjenestenettet (service mesh) er dataplansplanen (data plane) ansvarlig. Dybest set er den lokale sidecar-proxy for tjenesten dataplansplanen (data plane). Med andre ord er dataplansplanen (data plane) ansvarlig for den betingede oversættelse, videregivelse og overvågning af hvert datapakke, der sendes til eller fra tjenesten.

Kontrolplanen (The control plane)

Den netværksabstraktion, som den lokale proxy leverer i dataplanen, er magisk (?). Men hvordan opdager proxy-serveren egentlig ruten "/foo" til service B? Hvordan kan data fra serviceopdagelse, der fyldes ud af proxy-anmodninger, anvendes? Hvordan er indstillingerne for load balancing, timeouts, circuit breaking osv. konfigureret? Hvordan udføres applikationsudrulning ved hjælp af blue/green-metoden eller metoden til gradvis trafikoverførsel? Hvem konfigurerer indstillingerne for systemomfattende autentificering og autorisation?

Alle de nævnte punkter falder ind under kontrolplanet i service-netværket. Kontrolplanet tager et sæt isolerede proxyer,servere uden tilstand og forvandler dem til et distribueret system..

Jeg mener, at årsagen til, at mange teknologer finder de adskilte begreber dataplan og kontrolplan forvirrende, skyldes, at dataplanen er velkendt for de fleste, mens kontrolplanen er fremmed/uklar. Vi har længe arbejdet med fysiske netværksroutere og switche. Vi forstår, at pakker/anmodninger skal bevæge sig fra punkt A til punkt B, og hvad vi kan bruge til dette hardware og software. Den nye generation af softwareproxyer er bare modige versioner af de værktøjer, vi har brugt i lang tid.

Figur 2: Menneskelig kontrolplan

Men vi har længe anvendt kontrolplaner, selvom de fleste netværksoperatører måske ikke forbinder denne del af systemet med nogen teknologisk komponent. Årsagen til dette er enkel:
De fleste kontrolplaner, der anvendes i dag, er... vi.

På figur 2 Her vises, hvad jeg kalder den «Menneskelige kontrolplan (Human control plane)». I denne type implementering, som stadig er meget udbredt, skaber en menneskelig operatør, sandsynligvis en, der er mindre vred, statiske konfigurationer – potentielt ved hjælp af scripts – og implementerer dem via en eller anden speciel proces på alle proxy-servere. Derefter begynder proxyer at anvende denne konfiguration og går i gang med at behandle dataplanen (data plane) med de opdaterede indstillinger.

Figur 3: Udvidet kontrolplan for service mesh (Advanced service mesh control plane)

På figur 3 viser den «udvidede» kontrolplan (control plane) for service mesh (service mesh). Den består af følgende dele:

• Mennesket (The human): Der er stadig et menneske (forhåbentlig mindre vredt), der træffer beslutninger på et højt niveau vedrørende hele systemet som helhed.
• Brugergrænseflade for kontrolplan (Control plane UI): Mennesket interagerer med en eller anden form for brugergrænseflade for at styre systemet. Det kan være en webportal, et kommandolinjeprogram (CLI) eller en anden grænseflade. Gennem brugergrænsefladen har operatøren adgang til globale konfigurationsparametre for systemet, såsom:
  • Implementeringsstyring, blå/grøn (blue/green) og/eller gradvis trafikoverførsel
  • Autentifikations- og autorisationsparametre
  • Routingtabelspecifikationer, for eksempel hvad der sker, når applikation A anmoder om information om «/foo»
  • Indstillinger for belastningsfordeler, såsom timeouts, retry forsøg, circuit breaking parametre osv.
• Arbejdsbyrdescheduler (Workload scheduler): Tjenester startes i infrastrukturen via et planlægnings-/orkestreringssystem af en bestemt type, såsom Kubernetes eller Nomad. Planlæggeren er ansvarlig for at indlæse tjenesten sammen med dens lokale proxy-server.
• Tjenesteopdagelse (Service discovery). Når planlæggeren starter og stopper eksempler af tjenesten, rapporterer den om driftsstatus til tjenesteopdagelsessystemet.
• API'er til konfiguration af lokal proxy-server (Sidecar proxy configuration APIs) : Lokale proxytjenester udtrækker dynamisk tilstand fra forskellige systemkomponenter efter modellen "eventually consistent" uden operatorens indblanding. Hele systemet, der består af alle i øjeblikket kørende instanser af tjenester og lokale proxytjenester, konvergerer til sidst til et økosystem. API'et for den universelle dataplane i Envoy er et af eksemplerne på, hvordan dette fungerer i praksis.

I bund og grund er formålet med kontrolplanet at etablere en politik, der til sidst vil blive vedtaget af dataplanen. Mere avancerede kontrolplaner vil fjerne flere detaljer fra operatøren om visse systemer og kræve mindre manuel styring, forudsat at de fungerer korrekt!..

Dataplan og kontrolplan. Oversigt (Data plane vs. control plane summary)

• Dataplan for service mesh (Service mesh data plane): berører hver pakke / anmodning i systemet. Ansvarlig for opdagelse af applikationer / tjenester, sundhedstjek, routing, load balancing, autentificering / autorisation og overvågning.
• Kontrolplan for service mesh (Service mesh control plane): leverer politik og konfiguration til alle kørende dataplaner inden for service mesh. Berører ikke nogen pakker / anmodninger i systemet. Kontrolplanet forvandler alle dataplaner til et distribueret system.

Nuværende projektilandskab (Current project landscape)

Efter at have gennemgået forklaringen ovenfor, lad os se på den nuværende tilstand af projektet "service mesh".

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

I stedet for at udføre en dybdegående analyse af hver af de ovennævnte løsninger, vil jeg kort berøre nogle punkter, som jeg mener skaber det meste af forvirringen i økosystemet lige nu.

I begyndelsen af 2016 var Linkerd en af de første proxy-servere i dataplatformen (data plane) for service mesh og gjorde et fantastisk stykke arbejde med at øge opmærksomheden og interessen for designmodellen 'service mesh'. Cirka 6 måneder senere sluttede Envoy sig til Linkerd (selvom det havde arbejdet hos Lyft siden slutningen af 2015). Linkerd og Envoy er to projekter, der ofte nævnes i forbindelse med diskussioner om service meshes.

Istio blev annonceret i maj 2017. Projektets mål er meget lig det udvidede kontrolplan (control plane), der er vist på figur 3. Envoy for Istio fungerer som 'standard' proxy-server. Derfor er Istio kontrolplanen (control plane), mens Envoy er dataplatformen (data plane). På kort tid har Istio skabt meget opmærksomhed, og andre dataplatforme (data plane) er begyndt at integrere som erstatning for Envoy (både Linkerd og NGINX har demonstreret integration med Istio). Det faktum, at forskellige dataplatforme (data plane) kan bruges i én kontrolplan (control plane), betyder, at kontrolplanen (control plane) og dataplatformen (data plane) ikke nødvendigvis er tæt forbundne. Sådan et API som det universelle API for dataplatformen (data plane) Envoy kan fungere som en bro mellem de to dele af systemet.

Nelson og SmartStack hjælper yderligere med at illustrere opdelingen mellem kontrolplanen (control plane) og dataplatformen (data plane). Nelson bruger Envoy som sin proxy og bygger en solid kontrolplan (control plane) for service mesh baseret på HashiCorp-stakken, dvs. Nomad osv. SmartStack er måske den første af den nye bølge af service meshes. SmartStack danner en kontrolplan (control plane) omkring HAProxy eller NGINX, hvilket demonstrerer muligheden for at adskille kontrolplanen (control plane) for service mesh og dataplatformen (data plane).

Mikrotjenestearkitektur med en service mesh tiltrækker sig stadig mere opmærksomhed (rigtigt!), 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 mange innovationer både i dataplanskiktet (data plane) og i kontrolplanskiktet (control plane), samt en yderligere sammenblanding af forskellige komponenter. I sidste ende bør mikrotjenestearkitektur blive mere gennemsigtig og magisk (?) for operatøren.
Jeg håber, at alt bliver mindre og mindre irriterende.

Vigtige punkter (Key takeaways)

• Service mesh består af to forskellige dele: dataplanskiktet (data plane) og kontrolplanskiktet (control plane). Begge komponenter er nødvendige, og uden dem fungerer systemet ikke.
• Alle kender kontrolplanskiktet (control plane), og på nuværende tidspunkt kan kontrolplanskiktet (control plane) være dig!
• Alle dataplanskikter (data plane) konkurrerer med hinanden om funktioner, ydeevne, konfigurerbarhed og udvidelsesmuligheder.
• Alle kontrolplanskikter (control plane) konkurrerer med hinanden om funktioner, konfigurerbarhed, udvidelsesmuligheder og brugervenlighed.
• Et kontrolplanskikt (control plane) kan indeholde de rigtige abstraktioner og API'er, så flere dataplanskikter (data plane) kan anvendes.

Kilde: habr.com