{"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\/da\/blog\/administrirovanie\/servisnaya-set-ploskost-dannyh-i-ploskosti-upravleniya-service-mesh-data-plane-vs-control-plane","title":{"rendered":"Service mesh, \"dataplan\" og \"kontrolplan\" (Service mesh data plane vs. control plane)","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"<p>Hej, Habr! Jeg pr\u00e6senterer for jer overs\u00e6ttelsen af artiklen <noindex><a rel=\"nofollow\" href=\"https:\/\/blog.envoyproxy.io\/service-mesh-data-plane-vs-control-plane-2774e720f7fc\">\u00abService mesh data plane vs control plane\u00bb<\/a><\/noindex> forfatter til <b>Matt Klein<\/b>.<\/p>\n<p><img decoding=\"async\" alt=\"Service mesh, &quot;dataplan&quot; og &quot;kontrolplan&quot; (Service mesh data plane vs. control plane)\" src=\"\/wp-content\/uploads\/2019\/08\/487456689eb832f9e3845966cb0d85d4.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nDenne gang har jeg \"v\u00e6ret n\u00f8dt til\" at overs\u00e6tte beskrivelsen af begge komponenter i service mesh, data plane og control plane. Denne beskrivelse syntes jeg var den mest forst\u00e5elige og interessante, og vigtigst af alt f\u00f8rte den til en forst\u00e5else af, \"Beh\u00f8ver vi det overhovedet?\".<\/p>\n<p>Da ideen om \"Service mesh\" er blevet mere popul\u00e6r i de seneste to \u00e5r (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\u00e6llesskab med hensyn til, hvordan man sammenligner og kontrasterer forskellige l\u00f8sninger.<br \/>\n<noindex><a rel=\"nofollow\" name=\"habracut\"><\/a><\/noindex><br \/>\nSituationen kan bedst beskrives med f\u00f8lgende serier af tweets, jeg skrev i juli:<\/p>\n<blockquote><p>Forvirring omkring service mesh nr. 1: Linkerd ~ = Nginx ~ = Haproxy ~ = Envoy. Ingen af dem er lig med Istio. Istio er noget helt andet. 1 \/<\/p><\/blockquote>\n<blockquote><p>De f\u00f8rste er blot data planes. I sig selv laver de ingenting. De skal konfigureres til noget st\u00f8rre. 2 \/<\/p><\/blockquote>\n<blockquote><p>Istio er et eksempel p\u00e5 en control plane, der binder delene sammen. Det er et andet lag. \/end<\/p><\/blockquote>\n<p>I de tidligere tweets n\u00e6vnes 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\u00e6g vil jeg tage et skridt tilbage og forklare, hvad jeg mener med termerne \"data plane\" og \"control plane\" p\u00e5 et meget h\u00f8jt niveau og derefter forklare, hvordan termerne relaterer til de n\u00e6vnte projekter i tweets.<\/p>\n<h1>Hvad er en service mesh, egentlig?<\/h1>\n<p>\n<img decoding=\"async\" alt=\"Service mesh, &quot;dataplan&quot; og &quot;kontrolplan&quot; (Service mesh data plane vs. control plane)\" src=\"\/wp-content\/uploads\/2019\/08\/63c195aa9bcb7080f6924cecbff0fbc1.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<b>Figur 1: Oversigt over service mesh<\/b><\/p>\n<p><b>Figur 1<\/b> illustrerer konceptet med service mesh p\u00e5 det mest grundl\u00e6ggende niveau. Der er fire serviceklynger (A-D). Hver instans af en service er forbundet til en lokal proxyserver. Al netv\u00e6rkstrafik (HTTP, REST, gRPC, Redis osv.) fra hver enkelt applikationsinstans g\u00e5r gennem den lokale proxyserver til de relevante eksterne serviceklynger. Dermed kender applikationsinstansen ikke hele netv\u00e6rket og kender kun sin lokale proxy. Faktisk er netv\u00e6rket af det distribuerede system blevet adskilt fra servicen.<\/p>\n<h1>Data plane<\/h1>\n<p>\nI service mesh udf\u00f8rer den lokal proxyserver, der er placeret for applikationen, f\u00f8lgende opgaver:<\/p>\n<ul>\n<li> <b>Tjenestebulking (Service discovery)<\/b>. Hvilke tjenester\/udbydere\/applikationer er tilg\u00e6ngelige for din applikation?<\/li>\n<li><b>Sundhedskontrol (Health checking)<\/b>. Er de tjenesteinstanser, der returneres ved tjenestebulking (service discovery), i stand til at modtage netv\u00e6rkstrafik? Dette kan inkludere b\u00e5de aktiv (f.eks. responskontrol \/ healthcheck) og passiv (f.eks. ved brug af 3 p\u00e5 hinanden f\u00f8lgende 5xx-fejl som indikation af en usund tilstand i tjenesten) sundhedskontrol. <\/li>\n<li><b>Ruteplanl\u00e6gning (Routing)<\/b>N\u00e5r du modtager en REST-anmodning til &#171; \/foo &#187;, hvilken serviceklynge skal anmodningen sendes til? <\/li>\n<li> <b>Lastbalancering (Load balancing)<\/b>. N\u00e5r en tjenesteklynge er valgt under ruteplanl\u00e6gning, hvilken tjenesteinstans skal anmodningen sendes til? Med hvilken timeout? Med hvilke indstillinger for circuit breaking? Hvis anmodningen mislykkes, skal den fors\u00f8ges igen?<\/li>\n<li> <b>Godkendelse og autorisation (Authentication and authorization)<\/b>. Kan den anmodende tjeneste identificeres\/autoriseres kryptografisk via mTLS eller en anden mekanisme for indkommende anmodninger? Hvis den er identificeret\/autoriseret, er den s\u00e5 tilladt at kalde den anmodede operation (endpoint) i tjenesten, eller skal der returneres et uautentificeret svar?<\/li>\n<li> <b>Overv\u00e5gelighed (Observability)<\/b>. For hver anmodning skal der genereres detaljerede statistikker, logs og data for distribueret sporing, s\u00e5 operat\u00f8rerne kan forst\u00e5 den distribuerede trafikflow og fejlretning, efterh\u00e5nden som de opst\u00e5r.<\/li>\n<\/ul>\n<p>\nFor 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\u00e6ttelse, videregivelse og overv\u00e5gning af hvert datapakke, der sendes til eller fra tjenesten.<\/p>\n<h1>Kontrolplanen (The control plane)<\/h1>\n<p>\nDen netv\u00e6rksabstraktion, som den lokale proxy leverer i dataplanen, er magisk (?). Men hvordan ved proxyserveren egentlig, hvilken rute &#171; \/foo &#187; der f\u00f8rer til service B? Hvordan kan data fra serviceopdagelse, der udfyldes af proxy-anmodninger, anvendes? Hvordan er indstillingerne for belastningsbalancering, timeout, circuit breaking osv. konfigureret? Hvordan implementeres applikationen med brug af blue\/green metoden eller metoden til gradvis trafikoverf\u00f8rsel? Hvem konfigurerer indstillingerne for systemovergribende autentificering og autorisation?<\/p>\n<p>Alle de n\u00e6vnte punkter falder ind under kontrolplanet i service-netv\u00e6rket. <i>Kontrolplanet tager et s\u00e6t isolerede proxyer,<a class=\"wpil_keyword_link\" href=\"https:\/\/prohoster.info\/da\/server\/\"   title=\"servere\" data-wpil-keyword-link=\"linked\"  data-wpil-monitor-id=\"1348\">servere<\/a> uden tilstand og forvandler dem til et distribueret system.<\/i>.<\/p>\n<p>Jeg mener, at \u00e5rsagen 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\u00e6nge arbejdet med fysiske netv\u00e6rksroutere og switche. Vi forst\u00e5r, at pakker\/anmodninger skal bev\u00e6ge 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\u00e6rkt\u00f8jer, vi har brugt i lang tid.<\/p>\n<p><img decoding=\"async\" alt=\"Service mesh, &quot;dataplan&quot; og &quot;kontrolplan&quot; (Service mesh data plane vs. control plane)\" src=\"\/wp-content\/uploads\/2019\/08\/1b512802777cbf1853c5c4f7f2f81d99.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<b>Figur 2: Menneskelig kontrolplan<\/b><\/p>\n<p>Men vi har l\u00e6nge anvendt kontrolplaner, selvom de fleste netv\u00e6rksoperat\u00f8rer m\u00e5ske ikke forbinder denne del af systemet med nogen teknologisk komponent. \u00c5rsagen til dette er enkel:<br \/>\n<b>De fleste kontrolplaner, der anvendes i dag, er... vi<\/b>.<\/p>\n<p>P\u00e5 <b>figur 2<\/b> Her vises, hvad jeg kalder den \u00abMenneskelige kontrolplan (Human control plane)\u00bb. I denne type implementering, som stadig er meget udbredt, skaber en menneskelig operat\u00f8r, sandsynligvis en, der er mindre vred, statiske konfigurationer \u2013 potentielt ved hj\u00e6lp af scripts \u2013 og implementerer dem via en eller anden speciel proces p\u00e5 alle proxy-servere. Derefter begynder proxyer at anvende denne konfiguration og g\u00e5r i gang med at behandle dataplanen (data plane) med de opdaterede indstillinger.<\/p>\n<p><img decoding=\"async\" alt=\"Service mesh, &quot;dataplan&quot; og &quot;kontrolplan&quot; (Service mesh data plane vs. control plane)\" src=\"\/wp-content\/uploads\/2019\/08\/6b12429611475e0fc4dfa9f980704e16.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<b>Figur 3: Udvidet kontrolplan for service mesh (Advanced service mesh control plane)<\/b><\/p>\n<p>P\u00e5 <b>figur 3<\/b> viser den \u00abudvidede\u00bb kontrolplan (control plane) for service mesh (service mesh). Den best\u00e5r af f\u00f8lgende dele:<\/p>\n<ul>\n<li> <b>Mennesket (The human)<\/b>: Der er stadig et menneske (forh\u00e5bentlig mindre vredt), der tr\u00e6ffer beslutninger p\u00e5 et h\u00f8jt niveau vedr\u00f8rende hele systemet som helhed.<\/li>\n<li><b>Brugergr\u00e6nseflade for kontrolplan (Control plane UI)<\/b>: Mennesket interagerer med en eller anden form for brugergr\u00e6nseflade for at styre systemet. Det kan v\u00e6re en webportal, et kommandolinjeprogram (CLI) eller en anden gr\u00e6nseflade. Gennem brugergr\u00e6nsefladen har operat\u00f8ren adgang til globale konfigurationsparametre for systemet, s\u00e5som:\n<ul>\n<li>Implementeringsstyring, bl\u00e5\/gr\u00f8n (blue\/green) og\/eller gradvis trafikoverf\u00f8rsel <\/li>\n<li>Autentifikations- og autorisationsparametre <\/li>\n<li>Specifikationer for routingtabellen, eksempelvis hvad der sker, n\u00e5r applikation A anmoder om information om &#171; \/foo &#187; <\/li>\n<li>Indstillinger for belastningsfordeler, s\u00e5som timeouts, retry fors\u00f8g, circuit breaking parametre osv. <\/li>\n<\/ul>\n<\/li>\n<li> <b>Arbejdsbyrdescheduler (Workload scheduler)<\/b>: Tjenester startes i infrastrukturen via et planl\u00e6gnings-\/orkestreringssystem af en bestemt type, s\u00e5som Kubernetes eller Nomad. Planl\u00e6ggeren er ansvarlig for at indl\u00e6se tjenesten sammen med dens lokale proxy-server.<\/li>\n<li> <b>Tjenesteopdagelse (Service discovery)<\/b>. N\u00e5r planl\u00e6ggeren starter og stopper eksempler af tjenesten, rapporterer den om driftsstatus til tjenesteopdagelsessystemet.<\/li>\n<li> <b>API'er til konfiguration af lokal proxy-server (Sidecar proxy configuration APIs) <\/b>: Lokale proxytjenester udtr\u00e6kker dynamisk tilstand fra forskellige systemkomponenter efter modellen \"eventually consistent\" uden operatorens indblanding. Hele systemet, der best\u00e5r af alle i \u00f8jeblikket k\u00f8rende instanser af tjenester og lokale proxytjenester, konvergerer til sidst til et \u00f8kosystem. API'et for den universelle dataplane i Envoy er et af eksemplerne p\u00e5, hvordan dette fungerer i praksis.<\/li>\n<\/ul>\n<p>\nI bund og grund er form\u00e5let med kontrolplanet at etablere en politik, der til sidst vil blive vedtaget af dataplanen. Mere avancerede kontrolplaner vil fjerne flere detaljer fra operat\u00f8ren om visse systemer og kr\u00e6ve mindre manuel styring, forudsat at de fungerer korrekt!..<\/p>\n<h1>Dataplan og kontrolplan. Oversigt (Data plane vs. control plane summary)<\/h1>\n<p><\/p>\n<ul>\n<li> <b>Dataplan for service mesh (Service mesh data plane)<\/b>: ber\u00f8rer hver pakke \/ anmodning i systemet. Ansvarlig for opdagelse af applikationer \/ tjenester, sundhedstjek, routing, load balancing, autentificering \/ autorisation og overv\u00e5gning.<\/li>\n<li> <b>Kontrolplan for service mesh (Service mesh control plane)<\/b>: leverer politik og konfiguration til alle k\u00f8rende dataplaner inden for service mesh. Ber\u00f8rer ikke nogen pakker \/ anmodninger i systemet. Kontrolplanet forvandler alle dataplaner til et distribueret system.<\/li>\n<\/ul>\n<p><\/p>\n<h1>Nuv\u00e6rende projektilandskab (Current project landscape)<\/h1>\n<p>\nEfter at have gennemg\u00e5et forklaringen ovenfor, lad os se p\u00e5 den nuv\u00e6rende tilstand af projektet \"service mesh\".<\/p>\n<ul>\n<li> <b>Dataplaner (Data planes)<\/b>: Linkerd, NGINX, HAProxy, Envoy, Traefik<\/li>\n<li><b>Kontrolplaner (Control planes)<\/b>: Istio, Nelson, SmartStack <\/li>\n<\/ul>\n<p>\nI stedet for at udf\u00f8re en dybdeg\u00e5ende analyse af hver af de ovenn\u00e6vnte l\u00f8sninger, vil jeg kort ber\u00f8re nogle punkter, som jeg mener skaber det meste af forvirringen i \u00f8kosystemet lige nu.<\/p>\n<p>I begyndelsen af 2016 var Linkerd en af de f\u00f8rste proxy-servere i dataplatformen (data plane) for service mesh og gjorde et fantastisk stykke arbejde med at \u00f8ge opm\u00e6rksomheden og interessen for designmodellen 'service mesh'. Cirka 6 m\u00e5neder 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\u00e6vnes i forbindelse med diskussioner om service meshes.<\/p>\n<p>Istio blev annonceret i maj 2017. Projektets m\u00e5l er meget lig det udvidede kontrolplan (control plane), der er vist p\u00e5 <b>figur 3<\/b>. Envoy for Istio fungerer som 'standard' proxy-server. Derfor er Istio kontrolplanen (control plane), mens Envoy er dataplatformen (data plane). P\u00e5 kort tid har Istio skabt meget opm\u00e6rksomhed, og andre dataplatforme (data plane) er begyndt at integrere som erstatning for Envoy (b\u00e5de Linkerd og NGINX har demonstreret integration med Istio). Det faktum, at forskellige dataplatforme (data plane) kan bruges i \u00e9n kontrolplan (control plane), betyder, at kontrolplanen (control plane) og dataplatformen (data plane) ikke n\u00f8dvendigvis er t\u00e6t forbundne. S\u00e5dan et API som det universelle API for dataplatformen (data plane) Envoy kan fungere som en bro mellem de to dele af systemet.<\/p>\n<p>Nelson og SmartStack hj\u00e6lper 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\u00e5 HashiCorp-stakken, dvs. Nomad osv. SmartStack er m\u00e5ske den f\u00f8rste af den nye b\u00f8lge 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).<\/p>\n<p>Mikrotjenestearkitektur med en service mesh tiltr\u00e6kker sig stadig mere opm\u00e6rksomhed (rigtigt!), og flere og flere projekter og leverand\u00f8rer begynder at arbejde i denne retning. I l\u00f8bet af de n\u00e6ste par \u00e5r vil vi se mange innovationer b\u00e5de i dataplanskiktet (data plane) og i kontrolplanskiktet (control plane), samt en yderligere sammenblanding af forskellige komponenter. I sidste ende b\u00f8r mikrotjenestearkitektur blive mere gennemsigtig og magisk (?) for operat\u00f8ren.<br \/>\nJeg h\u00e5ber, at alt bliver mindre og mindre irriterende.<\/p>\n<h1>Vigtige punkter (Key takeaways)<\/h1>\n<p><\/p>\n<ul>\n<li> Service mesh best\u00e5r af to forskellige dele: dataplanskiktet (data plane) og kontrolplanskiktet (control plane). Begge komponenter er n\u00f8dvendige, og uden dem fungerer systemet ikke.<\/li>\n<li>Alle kender kontrolplanskiktet (control plane), og p\u00e5 nuv\u00e6rende tidspunkt kan kontrolplanskiktet (control plane) v\u00e6re dig! <\/li>\n<li>Alle dataplanskikter (data plane) konkurrerer med hinanden om funktioner, ydeevne, konfigurerbarhed og udvidelsesmuligheder. <\/li>\n<li> Alle kontrolplanskikter (control plane) konkurrerer med hinanden om funktioner, konfigurerbarhed, udvidelsesmuligheder og brugervenlighed.<\/li>\n<li>Et kontrolplanskikt (control plane) kan indeholde de rigtige abstraktioner og API'er, s\u00e5 flere dataplanskikter (data plane) kan anvendes. <\/li>\n<\/ul>\n<p>Kilde: <a content=\"nofollow\" rel=\"nofollow\" href=\"https:\/\/habr.com\/ru\/post\/462699\/\">habr.com<\/a><\/p>","protected":false,"gt_translate_keys":[{"key":"rendered","format":"html"}]},"excerpt":{"rendered":"<p>\u041f\u0440\u0438\u0432\u0435\u0442, \u0425\u0430\u0431\u0440! \u041f\u0440\u0435\u0434\u0441\u0442\u0430\u0432\u043b\u044f\u044e \u0432\u0430\u0448\u0435\u043c\u0443 \u0432\u043d\u0438\u043c\u0430\u043d\u0438\u044e \u043f\u0435\u0440\u0435\u0432\u043e\u0434 \u0441\u0442\u0430\u0442\u044c\u0438 \u00abService mesh data plane vs control plane\u00bb \u0430\u0432\u0442\u043e\u0440\u0430 Matt Klein. \u0412 \u044d\u0442\u043e\u0442 \u0440\u0430\u0437 \u00ab\u0437\u0430\u0445\u043e\u0442\u0435\u043b\u043e\u0441\u044c \u0438 \u043f\u0435\u0440\u0435\u0432\u0435\u043b\u043e\u0441\u044c\u00bb \u043e\u043f\u0438\u0441\u0430\u043d\u0438\u0435 \u043e\u0431\u043e\u0438\u0445 \u043a\u043e\u043c\u043f\u043e\u043d\u0435\u043d\u0442\u043e\u0432 service mesh, data plane \u0438 control plane. \u042d\u0442\u043e \u043e\u043f\u0438\u0441\u0430\u043d\u0438\u0435 \u043c\u043d\u0435 \u043f\u043e\u043a\u0430\u0437\u0430\u043b\u043e\u0441\u044c \u0441\u0430\u043c\u044b\u043c \u043f\u043e\u043d\u044f\u0442\u043d\u044b\u043c \u0438 \u0438\u043d\u0442\u0435\u0440\u0435\u0441\u043d\u044b\u043c, \u0430 \u0433\u043b\u0430\u0432\u043d\u043e\u0435 \u043f\u043e\u0434\u0432\u043e\u0434\u044f\u0449\u0438\u043c \u043a \u043f\u043e\u043d\u0438\u043c\u0430\u043d\u0438\u044e \u00ab\u0410 \u043d\u0443\u0436\u043d\u043e \u043b\u0438 \u043e\u043d\u043e \u0432\u043e\u043e\u0431\u0449\u0435?\u00bb. \u041f\u043e\u0441\u043a\u043e\u043b\u044c\u043a\u0443 \u0438\u0434\u0435\u044f \u00ab\u0421\u0435\u0440\u0432\u0438\u0441\u043d\u043e\u0439 \u0441\u0435\u0442\u0438 [&hellip;]<\/p>\n","protected":false,"gt_translate_keys":[{"key":"rendered","format":"html"}]},"author":1,"featured_media":27757,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[688],"tags":[],"class_list":["post-37030","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-administrirovanie"],"aioseo_notices":[],"aioseo_head":"\n\t\t<!-- All in One SEO 5.0.3 - aioseo.com -->\n\t<meta name=\"description\" content=\"\u041f\u0440\u0438\u0432\u0435\u0442, \u0425\u0430\u0431\u0440!\" \/>\n\t<meta name=\"robots\" content=\"max-image-preview:large\" \/>\n\t<meta name=\"author\" content=\"Yuri Gagarin\"\/>\n\t<link rel=\"canonical\" href=\"https:\/\/prohoster.info\/da\/blog\/administrirovanie\/servisnaya-set-ploskost-dannyh-i-ploskosti-upravleniya-service-mesh-data-plane-vs-control-plane\" \/>\n\t\t<meta name=\"generator\" content=\"All in One SEO (AIOSEO) 5.0.3\" \/>\n\t\t<meta property=\"og:locale\" content=\"da_DK\" \/>\n\t\t<meta property=\"og:site_name\" content=\"ProHoster | \u041a\u0443\u043f\u0438\u0442\u044c \u043d\u0430\u0434\u0435\u0436\u043d\u044b\u0439 \u0445\u043e\u0441\u0442\u0438\u043d\u0433 \u0434\u043b\u044f \u0441\u0430\u0439\u0442\u043e\u0432 \u0441 \u0437\u0430\u0449\u0438\u0442\u043e\u0439 \u043e\u0442 DDoS, VPS VDS \u0441\u0435\u0440\u0432\u0435\u0440\u044b\" \/>\n\t\t<meta property=\"og:type\" content=\"article\" \/>\n\t\t<meta property=\"og:title\" content=\"\ud83e\udd47\u0421\u0435\u0440\u0432\u0438\u0441\u043d\u0430\u044f \u0441\u0435\u0442\u044c, \u00ab\u041f\u043b\u043e\u0441\u043a\u043e\u0441\u0442\u044c \u0434\u0430\u043d\u043d\u044b\u0445\u00bb \u0438 \u00ab\u041f\u043b\u043e\u0441\u043a\u043e\u0441\u0442\u0438 \u0443\u043f\u0440\u0430\u0432\u043b\u0435\u043d\u0438\u044f\u00bb (Service mesh data plane vs. control plane) | ProHoster\" \/>\n\t\t<meta property=\"og:description\" content=\"\u041f\u0440\u0438\u0432\u0435\u0442, \u0425\u0430\u0431\u0440!\" \/>\n\t\t<meta property=\"og:url\" content=\"https:\/\/prohoster.info\/da\/blog\/administrirovanie\/servisnaya-set-ploskost-dannyh-i-ploskosti-upravleniya-service-mesh-data-plane-vs-control-plane\" \/>\n\t\t<meta property=\"og:image\" content=\"https:\/\/prohoster.info\/wp-content\/uploads\/2021\/11\/logo-350.jpg\" \/>\n\t\t<meta property=\"og:image:secure_url\" content=\"https:\/\/prohoster.info\/wp-content\/uploads\/2021\/11\/logo-350.jpg\" \/>\n\t\t<meta property=\"og:image:width\" content=\"350\" \/>\n\t\t<meta property=\"og:image:height\" content=\"350\" \/>\n\t\t<meta property=\"article:published_time\" content=\"2019-10-31T19:15:23+00:00\" \/>\n\t\t<meta property=\"article:modified_time\" content=\"2019-10-31T19:15:23+00:00\" \/>\n\t\t<meta property=\"article:publisher\" content=\"https:\/\/www.facebook.com\/prohoster\" \/>\n\t\t<meta property=\"article:author\" content=\"https:\/\/www.facebook.com\/prohoster\" \/>\n\t\t<!-- All in One SEO -->\n\n","aioseo_head_json":{"title":"\ud83e\udd47Service mesh, 'Dataplanskikter' og 'Kontrolplanskikter' (Service mesh data plane vs. control plane) | ProHoster","description":"Hello, Habr!","canonical_url":"https:\/\/prohoster.info\/da\/blog\/administrirovanie\/servisnaya-set-ploskost-dannyh-i-ploskosti-upravleniya-service-mesh-data-plane-vs-control-plane","robots":"max-image-preview:large","keywords":"","webmasterTools":{"miscellaneous":""},"schema":null,"og:locale":"da_DK","og:site_name":"ProHoster | \u041a\u0443\u043f\u0438\u0442\u044c \u043d\u0430\u0434\u0435\u0436\u043d\u044b\u0439 \u0445\u043e\u0441\u0442\u0438\u043d\u0433 \u0434\u043b\u044f \u0441\u0430\u0439\u0442\u043e\u0432 \u0441 \u0437\u0430\u0449\u0438\u0442\u043e\u0439 \u043e\u0442 DDoS, VPS VDS \u0441\u0435\u0440\u0432\u0435\u0440\u044b","og:type":"article","og:title":"\ud83e\udd47\u0421\u0435\u0440\u0432\u0438\u0441\u043d\u0430\u044f \u0441\u0435\u0442\u044c, \u00ab\u041f\u043b\u043e\u0441\u043a\u043e\u0441\u0442\u044c \u0434\u0430\u043d\u043d\u044b\u0445\u00bb \u0438 \u00ab\u041f\u043b\u043e\u0441\u043a\u043e\u0441\u0442\u0438 \u0443\u043f\u0440\u0430\u0432\u043b\u0435\u043d\u0438\u044f\u00bb (Service mesh data plane vs. control plane) | ProHoster","og:description":"\u041f\u0440\u0438\u0432\u0435\u0442, \u0425\u0430\u0431\u0440!","og:url":"https:\/\/prohoster.info\/da\/blog\/administrirovanie\/servisnaya-set-ploskost-dannyh-i-ploskosti-upravleniya-service-mesh-data-plane-vs-control-plane","og:image":"https:\/\/prohoster.info\/wp-content\/uploads\/2021\/11\/logo-350.jpg","og:image:secure_url":"https:\/\/prohoster.info\/wp-content\/uploads\/2021\/11\/logo-350.jpg","og:image:width":350,"og:image:height":350,"article:published_time":"2019-10-31T19:15:23+00:00","article:modified_time":"2019-10-31T19:15:23+00:00","article:publisher":"https:\/\/www.facebook.com\/prohoster","article:author":"https:\/\/www.facebook.com\/prohoster"},"aioseo_meta_data":{"post_id":"37030","title":null,"description":null,"keywords":null,"keyphrases":null,"primary_term":null,"canonical_url":null,"og_title":null,"og_description":null,"og_object_type":"default","og_image_type":"default","og_image_url":null,"og_image_width":null,"og_image_height":null,"og_image_custom_url":null,"og_image_custom_fields":null,"og_video":null,"og_custom_url":null,"og_article_section":null,"og_article_tags":null,"twitter_use_og":false,"twitter_card":"default","twitter_image_type":"default","twitter_image_url":null,"twitter_image_custom_url":null,"twitter_image_custom_fields":null,"twitter_title":null,"twitter_description":null,"schema":{"blockGraphs":[],"customGraphs":[],"default":{"data":{"Article":[],"Course":[],"Dataset":[],"FAQPage":[],"Movie":[],"Person":[],"Product":[],"ProductReview":[],"Car":[],"Recipe":[],"Service":[],"SoftwareApplication":[],"WebPage":[]},"graphName":"","isEnabled":true},"graphs":[]},"schema_type":null,"schema_type_options":null,"pillar_content":false,"robots_default":true,"robots_noindex":false,"robots_noarchive":false,"robots_nosnippet":false,"robots_nofollow":false,"robots_noimageindex":false,"robots_noodp":false,"robots_notranslate":false,"robots_max_snippet":null,"robots_max_videopreview":null,"robots_max_imagepreview":"large","priority":null,"frequency":null,"local_seo":null,"seo_analyzer_scan_date":"2026-02-09 17:07:03","breadcrumb_settings":null,"limit_modified_date":false,"reviewed_by":null,"ai":null,"created":"2021-03-01 01:34:25","updated":"2026-02-09 17:07:03","focus_keyword":null,"additional_keywords":null,"truseo_locale":null},"gt_translate_keys":[{"key":"link","format":"url"}],"_links":{"self":[{"href":"https:\/\/prohoster.info\/da\/wp-json\/wp\/v2\/posts\/37030","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/prohoster.info\/da\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/prohoster.info\/da\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/prohoster.info\/da\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/prohoster.info\/da\/wp-json\/wp\/v2\/comments?post=37030"}],"version-history":[{"count":1,"href":"https:\/\/prohoster.info\/da\/wp-json\/wp\/v2\/posts\/37030\/revisions"}],"predecessor-version":[{"id":158592,"href":"https:\/\/prohoster.info\/da\/wp-json\/wp\/v2\/posts\/37030\/revisions\/158592"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/prohoster.info\/da\/wp-json\/wp\/v2\/media\/27757"}],"wp:attachment":[{"href":"https:\/\/prohoster.info\/da\/wp-json\/wp\/v2\/media?parent=37030"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/prohoster.info\/da\/wp-json\/wp\/v2\/categories?post=37030"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/prohoster.info\/da\/wp-json\/wp\/v2\/tags?post=37030"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}