Hey Habr! Ech presentéieren Iech d'Iwwersetzung vum Artikel "Service Mesh Dataplane vs Kontrollplane" Auteur Matt Klein.

Dës Kéier hunn ech "wëll an iwwersat" d'Beschreiwung vu béide Service Mesh Komponenten, Dataplan a Kontrollplan. Dës Beschreiwung war fir mech déi verständlech an interessant, an am wichtegsten féiert zum Verständnis vun "Ass et iwwerhaapt néideg?"

Wéi d'Iddi vun engem "Service Mesh" an de leschten zwee Joer ëmmer méi populär ginn ass (Original Artikel 10. Oktober 2017) an d'Zuel vun de Participanten am Raum eropgaang ass, hunn ech eng entspriechend Erhéijung vun der Verwirrung ënner der ganzer gesinn. Tech Communautéit iwwer wéi verschidde Léisungen ze vergläichen a kontrastéieren.

D'Situatioun ass am beschten zesummegefaasst vun der folgender Serie vun Tweets, déi ech am Juli geschriwwen hunn:

Service Mesh Duercherneen #1: Linkerd ~ = Nginx ~ = Haproxy ~ = Envoy. Keen vun hinnen sinn gläich ze Istio. Istio ass eppes ganz anescht. 1 /

Déi éischt sinn einfach Daten Fligeren. Eleng maachen se näischt. Si mussen an der Stëmmung fir eppes méi. 2/

Istio ass e Beispill vun engem Kontrollplan deen d'Deeler matenee verbënnt. Dëst ass eng aner Schicht. / Enn

Déi viregt Tweets ernimmen verschidde verschidde Projeten (Linkerd, NGINX, HAProxy, Envoy, an Istio), awer méi wichteg d'allgemeng Konzepter vum Dateplang, Service Mesh a Kontrollplan aféieren. An dësem Beitrag wäert ech e Schrëtt zréck huelen a schwätzen iwwer wat ech mat de Begrëffer "Dateplane" a "Kontrollplan" op engem ganz héijen Niveau mengen, a schwätzen dann iwwer wéi d'Konditioune fir d'Projeten an Tweets ernimmt gëllen.

Wat ass e Service Mesh, wierklech?

Figur 1: Service Mesh gemaach Iwwersiicht

1 Figur illustréiert d'Konzept vun engem Service Mesh op sengem meescht Basisniveau. Et gi véier Servicecluster (AD). All Service Instanz ass mat engem lokalen Proxy Server assoziéiert. All Netzverkéier (HTTP, REST, gRPC, Redis, etc.) vun enger eenzeger Applikatiounsinstanz gëtt duerch e lokale Proxy un déi entspriechend extern Servicecluster weidergeleet. Op dës Manéier ass d'Applikatioun Instanz net bewosst vum Netz als e Ganzt a bewosst nëmme vu sengem lokale Proxy. Tatsächlech gouf de verdeelt Systemnetz aus dem Service geläscht.

Daten Fliger

An engem Service Mesh mécht e Proxy Server lokal lokal fir d'Applikatioun déi folgend Aufgaben:

• Service Entdeckung. Wéi eng Servicer / Uwendungen sinn fir Är Uwendung verfügbar?
• Gesondheet Iwwerpréiwung. Sinn d'Serviceinstanzen déi duerch Service Entdeckung zréckginn gesond a prett fir den Netzverkéier ze akzeptéieren? Dëst kann souwuel aktiv (zB Äntwert / Gesondheetscheck) wéi och passiv (zB benotzt 3 konsekutiv 5xx Feeler als Indikatioun fir en ongesonde Servicezoustand) Gesondheetschecken enthalen.
• Routing. Wann Dir eng Ufro un "/ foo" vun engem REST-Service kritt, wéi en Servicecluster soll d'Ufro geschéckt ginn?
• Last Equiliber. Wann e Servicecluster wärend der Routing ausgewielt gouf, a wéi eng Serviceinstanz soll d'Ufro geschéckt ginn? Mat wéi enger Zäit? Mat wéi engem Circuit Break Astellungen? Wann d'Demande feelt, soll se nach eng Kéier probéiert ginn?
• Authentifikatioun an Autorisatioun. Fir erakommen Ufroen, kann den Uruffservice kryptografesch identifizéiert / autoriséiert ginn mat mTLS oder engem anere Mechanismus? Wann et unerkannt / autoriséiert ass, ass et erlaabt déi ugefrote Operatioun (Endpunkt) um Service ze ruffen oder soll eng onauthentifizéiert Äntwert zréckginn?
• Observabilitéit. Detailléiert Statistiken, Logbicher / Logbicher, a verdeelt Spuerdaten solle fir all Ufro generéiert ginn, sou datt d'Betreiber verdeelt Trafficflow an Debuggingprobleemer kënne verstoen wéi se entstinn.

Den Datefliger ass verantwortlech fir all virdrun Punkten am Service Mesh. Tatsächlech ass de Proxy lokal fir de Service (Sidecar) den Datefliger. An anere Wierder, den Datefliger ass verantwortlech fir bedingt Sendung, Forwarding an Iwwerwaachung vun all Netzwierkpaket deen an oder vun engem Service geschéckt gëtt.

Kontroll Fliger

D'Netzwierkabstraktioun, déi e lokale Proxy am Dateplang ubitt, ass magesch (?). Wéi och ëmmer, wéi weess de Proxy eigentlech iwwer den "/foo" Wee zum Service B? Wéi kënnen d'Service-Entdeckungsdaten, déi duerch Proxy-Ufroe populéiert sinn, benotzt ginn? Wéi sinn d'Parameteren konfiguréiert fir Belaaschtung, Timeout, Circuit Break, etc.? Wéi benotzt Dir eng Applikatioun mat der blo / grénger Method oder der graziéiser Traffic Iwwergangsmethod? Wien konfiguréiert System-breet Authentifikatioun an Autorisatioun Astellunge?

All déi uewe genannte Saachen sinn ënner der Kontroll vun der Kontrollfläch vum Service Mesh. D'Kontrollfliger hëlt eng Rei vun isoléierten stateless Proxyen a verwandelt se an e verdeelt System.

Ech denken, datt de Grond firwat vill Technologen déi getrennte Konzepter vun Datefliger a Kontrollfliger konfus fannen ass well fir déi meescht Leit d'Datefliger vertraut ass, während d'Kontrollplan auslännesch / onverständlech ass. Mir hunn eng laang Zäit mat kierperlechen Netzwierkrouter a Schalter geschafft. Mir verstinn datt Päckchen / Ufroe vum Punkt A op de Punkt B musse goen an datt mir Hardware a Software benotze fir dëst ze maachen. Déi nei Generatioun vu Software Proxies sinn einfach ausgefalene Versioune vun den Tools déi mir scho laang benotzt hunn.

Figur 2: Mënsch Kontroll Fliger

Allerdéngs hu mir Kontroll Fligeren fir eng laang Zäit benotzt, obwuel déi meescht Reseau Opérateuren kann dësen Deel vum System net mat all Technologie Komponent Associé. De Grond ass einfach:
Meescht Kontroll Fligeren am Gebrauch haut sinn ... mir.

op Figur 2 weist wat ech de "Mënschleche Kontrollfliger" nennen. An dëser Aart vun Détachement, déi nach ëmmer ganz heefeg ass, erstellt e wahrscheinlech grumpy mënschleche Bedreiwer statesch Konfiguratiounen - potenziell iwwer Scripten - an deployéiert se duerch e spezielle Prozess un all Proxyen. D'Proxyen fänken dann un dës Konfiguratioun ze benotzen a fänken un d'Datefliger ze veraarbecht mat den aktualiséierten Astellungen.

Figur 3: Fortgeschratt Service Mesh Kontroll Fliger

op Figur 3 weist de "verlängerten" Kontrollebene vum Service Mesh. Et besteet aus de folgenden Deeler:

• De Mënsch: Et gëtt nach eng Persoun (hoffentlech manner rosen) déi Entscheedungen op héijem Niveau iwwer de ganze System als Ganzt mécht.
• Kontroll Fliger UI: Eng Persoun interagéiert mat enger Zort User Interface fir de System ze kontrolléieren. Dëst kéint e Webportal, eng Kommandozeilapplikatioun (CLI) oder eng aner Interface sinn. Mat der User-Interface huet de Bedreiwer Zougang zu globale Systemkonfiguratiounsparameter wéi:
  • Ofbau Kontroll, blo / gréng an / oder graduell Verkéier Transitioun
  • Authentifikatioun an Autorisatioun Optiounen
  • Routing Dësch Spezifikatioune, zum Beispill wann Applikatioun A Ufro Informatiounen iwwert "/ foo" wat geschitt
  • Lueden Balancer Astellunge, wéi Timeouts, Wiederverspriechen, Circuit Break Astellungen, etc.
• Workload Scheduler: D'Servicer lafen op der Infrastruktur duerch eng Aart vu Scheduling / Orchestratiounssystem, wéi Kubernetes oder Nomad. De Scheduler ass verantwortlech fir de Service zesumme mat sengem lokale Proxy ze lueden.
• Service Entdeckung. Wann de Scheduler ufänkt a Serviceinstanzen stoppt, bericht de Gesondheetszoustand un de Service Entdeckungssystem.
• Sidecar Proxy Konfiguratioun APIen : Lokal Proxyen extrahéieren dynamesch Staat aus verschiddene Systemkomponenten mat engem schliisslech konsequente Modell ouni Operatorinterventioun. De ganze System, besteet aus all aktuell lafenden Serviceinstanzen a lokale Proxy Serveren, konvergéiert schlussendlech an een Ökosystem. Envoy's universal Data Plane API ass e Beispill vu wéi dëst an der Praxis funktionnéiert.

Wesentlech ass den Zweck vum Kontrollfliger d'Politik ze setzen déi schlussendlech vum Datefliger ugeholl gëtt. Méi fortgeschratt Kontrollfliger wäerte méi Deeler vun e puer Systemer vum Bedreiwer ewechhuelen a manner manuell Operatioun erfuerderen, virausgesat datt se richteg funktionnéieren!...

Donnéeën Fliger a Kontroll Fliger. Donnéeën Fliger vs Kontroll Fliger Resumé

• Service Mesh gemaach Daten Fliger: Afloss op all Paket / Ufro am System. Verantwortlech fir Applikatioun / Service Entdeckung, Gesondheetsprüfung, Routing, Belaaschtung, Authentifikatioun / Autorisatioun an Observabilitéit.
• Service Mesh Kontroll Fliger: Bitt Politik a Konfiguratioun fir all Lafen Datefliger am Servicenetz. Beréiert keng Packagen / Ufroen um System. D'Kontrollplaner verwandelt all Datefliger an e verdeelt System.

Aktuelle Projet Landschaft

Nodeems Dir d'Erklärung hei uewen verstanen hutt, kucke mer den aktuellen Zoustand vum Service Mesh Projet.

• Daten Fligeren: Linkerd, NGINX, HAProxy, Envoy, Traefik
• Kontroll Fligeren: Istio, Nelson, SmartStack

Anstatt an eng déif Analyse vun all eenzel vun de Léisungen hei uewen ze goen, wäert ech kuerz e puer vun de Punkten adresséieren, déi ech gleewen, datt de Moment vill vun der Duercherneen am Ökosystem verursaacht.

Linkerd war ee vun den éischten Dateplan Proxy Server fir de Service Mesh am fréien 2016 an huet eng fantastesch Aarbecht gemaach fir d'Sensibiliséierung an d'Opmierksamkeet op de Service Mesh Design Modell ze erhéijen. Ongeféier 6 Méint duerno ass den Envoy bei Linkerd bäikomm (obwuel hien zënter Enn 2015 mam Lyft war). Linkerd an Envoy sinn déi zwee Projeten déi am meeschten ernimmt ginn wann Dir Service Meshes diskutéiert.

Istio gouf am Mee 2017 ugekënnegt. D'Ziler vum Istio-Projet si ganz ähnlech wéi déi erweidert Kontrollplane gewisen Figur 3. Envoy fir Istio ass de Standard Proxy. Also, Istio ass de Kontrollfliger, an Envoy ass den Datefliger. A kuerzer Zäit generéiert Istio vill Opreegung, an aner Datefliger hunn ugefaang als Ersatz fir Envoy z'integréieren (béid Linkerd an NGINX hunn Integratioun mat Istio demonstréiert). D'Tatsaach, datt verschidden Datefliger an deemselwechte Kontrollplang kënne benotzt ginn, heescht datt d'Kontrollplan an d'Datefliger net onbedéngt enk gekoppelt sinn. Eng API wéi Envoy's generesch Dateplang API kann eng Bréck tëscht zwee Deeler vum System bilden.

Nelson an SmartStack hëllefen weider d'Trennung vun der Kontroll Fliger an Daten Fliger ze illustréieren. Nelson benotzt Envoy als säi Proxy a baut en zouverléissege Kontrollplang fir de Service Mesh baséiert op dem HashiCorp Stack, d.h. Nomad, etc. SmartStack war vläicht déi éischt vun enger neier Welle vu Service Meshes. SmartStack baut e Kontrollebene ronderëm HAProxy oder NGINX, wat d'Fähigkeit beweist fir d'Kontrollplan aus dem Service Mesh aus dem Datefliger ze trennen.

Microservice Architektur mat engem Service Mesh kritt ëmmer méi Opmierksamkeet (zu Recht!), A méi a méi Projeten an Ubidder fänken un dës Richtung ze schaffen. An den nächste Jore wäerte mir vill Innovatioun souwuel am Dateplang wéi och am Kontrollplan gesinn, wéi och weider Vermëschung vu verschiddene Komponenten. Schlussendlech soll d'Mikroservicearchitektur méi transparent a magesch (?) fir den Bedreiwer ginn.
Hoffentlech ëmmer manner irritéiert.

Schlëssel Takeaways

• E Service Mesh besteet aus zwee verschiddenen Deeler: den Dateplang an d'Kontrollplan. Béid Komponente sinn erfuerderlech, an ouni si funktionnéiert de System net.
• Jiddereen ass Gewunnecht mat der Kontroll Fliger, an op dësem Punkt, de Kontroll Fliger kéint Dir sinn!
• All Datefliger konkurréiere mateneen iwwer Features, Leeschtung, Konfigurabilitéit an Erweiterbarkeet.
• All Kontrollfliger konkurréiere mateneen a Featuren, Konfigurabilitéit, Erweiterbarkeet an einfacher Benotzung.
• Ee Kontrollebene kann déi richteg Abstraktiounen an APIen enthalen, sou datt verschidde Datepläng kënne benotzt ginn.

Source: will.com