{"id":37030,"date":"2019-10-31T22:15:23","date_gmt":"2019-10-31T19:15:23","guid":{"rendered":"https:\/\/prohoster.info\/blog\/servisnaya-set-ploskost-dannyh-i-ploskosti-upravleniya-service-mesh-data-plane-vs-control-plane\/"},"modified":"2019-10-31T22:15:23","modified_gmt":"2019-10-31T19:15:23","slug":"servisnaya-set-ploskost-dannyh-i-ploskosti-upravleniya-service-mesh-data-plane-vs-control-plane","status":"publish","type":"post","link":"https:\/\/prohoster.info\/sv\/blog\/administrirovanie\/servisnaya-set-ploskost-dannyh-i-ploskosti-upravleniya-service-mesh-data-plane-vs-control-plane","title":{"rendered":"Tj\u00e4nsten\u00e4tverk, \"Dataplan\" och \"Kontrollplan\" (Service mesh data plane vs. control plane)","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

Hej, Habr! Jag presenterar \u00f6vers\u00e4ttningen av artikeln \u00abService mesh data plane vs control plane\u00bb<\/a><\/noindex> f\u00f6rfattare Matt Klein<\/b>.<\/p>\n

\"Tj\u00e4nsten\u00e4tverk,
\n
\nDenna g\u00e5ng \"k\u00e4ndes det som att det beh\u00f6vdes och \u00f6versattes\" beskrivningen av b\u00e5da komponenterna i service mesh, data plane och control plane. Denna beskrivning verkade f\u00f6r mig vara den mest f\u00f6rst\u00e5eliga och intressanta, framf\u00f6r allt ledande till insikten \"\u00c4r det \u00f6verhuvudtaget n\u00f6dv\u00e4ndigt?\".<\/p>\n

Eftersom id\u00e9n om \"Service mesh\" har blivit alltmer popul\u00e4r under de senaste tv\u00e5 \u00e5ren (ursprunglig artikel fr\u00e5n 10 oktober 2017), och antalet akt\u00f6rer inom omr\u00e5det har \u00f6kat, har jag sett en motsvarande \u00f6kning av f\u00f6rvirringen inom hela det tekniska samfundet ang\u00e5ende hur man j\u00e4mf\u00f6r och st\u00e4ller olika l\u00f6sningar mot varandra.
\n<\/a><\/noindex>
\nSituationen kan b\u00e4st beskrivas med f\u00f6ljande serier av tweets som jag skrev i juli:<\/p>\n

F\u00f6rvirring kring service mesh nummer 1: Linkerd ~ = Nginx ~ = Haproxy ~ = Envoy. Ingen av dem \u00e4r lika med Istio. Istio \u00e4r n\u00e5got helt annat. 1 \/<\/p><\/blockquote>\n

De f\u00f6rsta \u00e4r bara data planes. I sig sj\u00e4lva g\u00f6r de ingenting. De m\u00e5ste konfigureras f\u00f6r n\u00e5got mer. 2 \/<\/p><\/blockquote>\n

Istio \u00e4r ett exempel p\u00e5 en control plane som kopplar ihop delarna. Det \u00e4r ett annat lager. \/ slut<\/p><\/blockquote>\n

I de tidigare tweets n\u00e4mns flera olika projekt (Linkerd, NGINX, HAProxy, Envoy och Istio), men viktigare \u00e4r att gemensamma begrepp som data plane, service mesh och control plane introduceras. I det h\u00e4r inl\u00e4gget kommer jag att ta ett steg tillbaka och f\u00f6rklara vad jag menar med termerna \"data plane\" och \"control plane\" p\u00e5 en v\u00e4ldigt h\u00f6g niv\u00e5, och sedan ska jag f\u00f6rklara hur dessa termer relaterar till projekten som n\u00e4mns i tweets.<\/p>\n

Vad \u00e4r en service mesh egentligen?<\/h1>\n

\n\"Tj\u00e4nsten\u00e4tverk,
\nBild 1: \u00d6versikt \u00f6ver service mesh<\/b><\/p>\n

Bild 1<\/b> illustrerar konceptet av service mesh p\u00e5 den mest grundl\u00e4ggande niv\u00e5n. Det finns fyra servicekluster (A-D). Varje tj\u00e4nstinstans \u00e4r kopplad till en lokal proxyserver. All n\u00e4tverkstrafik (HTTP, REST, gRPC, Redis, etc.) fr\u00e5n enskild tj\u00e4nstinstans g\u00e5r genom den lokala proxyservern till de tillh\u00f6rande externa serviceklustren. P\u00e5 s\u00e5 s\u00e4tt har inte tj\u00e4nstinstansen kunskap om n\u00e4tverket som helhet utan k\u00e4nner endast till sin lokala proxy. Faktiskt har n\u00e4tverket av det distribuerade systemet avl\u00e4gsnats fr\u00e5n tj\u00e4nsten.<\/p>\n

Data plane<\/h1>\n

\nI en service mesh utf\u00f6r proxyservern, som \u00e4r lokal f\u00f6r applikationen, f\u00f6ljande uppgifter:<\/p>\n