{"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\/nl\/blog\/administrirovanie\/servisnaya-set-ploskost-dannyh-i-ploskosti-upravleniya-service-mesh-data-plane-vs-control-plane","title":{"rendered":"Service mesh, 'data plane' en 'control plane' (Service mesh data plane vs. control plane)","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"<p>Hallo, Habr! Ik presenteer u de vertaling van het artikel <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> auteur <b>Matt Klein<\/b>.<\/p>\n<p><img decoding=\"async\" alt=\"Service mesh, &#039;data plane&#039; en &#039;control plane&#039; (Service mesh data plane vs. control plane)\" src=\"\/wp-content\/uploads\/2019\/08\/487456689eb832f9e3845966cb0d85d4.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nDit keer heb ik de beschrijving van beide componenten van de service mesh, data plane en control plane, vertaald. Deze beschrijving lijkt me het meest begrijpelijk en interessant, en vooral helpt het te begrijpen: \u00abIs het \u00fcberhaupt nodig?\u00bb.<\/p>\n<p>Aangezien het idee van de \u00abService mesh\u00bb steeds populairder wordt in de afgelopen twee jaar (origineel artikel van 10 oktober 2017), en het aantal deelnemers in dit domein is toegenomen, zie ik een overeenkomstige toename van verwarring binnen de technische gemeenschap over hoe verschillende oplossingen te vergelijken en te contrasteren.<br \/>\n<noindex><a rel=\"nofollow\" name=\"habracut\"><\/a><\/noindex><br \/>\nDe situatie kan het beste worden beschreven met de volgende series tweets die ik in juli heb geschreven:<\/p>\n<blockquote><p>Verwarring over service mesh \u2116 1: Linkerd ~ = Nginx ~ = Haproxy ~ = Envoy. Geen van deze is gelijk aan Istio. Istio is iets heel anders. 1\/<\/p><\/blockquote>\n<blockquote><p>De eerste zijn gewoon data planes. Op zichzelf doen ze niets. Ze moeten worden ingesteld voor iets groters. 2\/<\/p><\/blockquote>\n<blockquote><p>Istio is een voorbeeld van een control plane, die de verschillende delen samenbrengt. Dit is een andere laag. \/einde<\/p><\/blockquote>\n<p>In de eerdere tweets worden verschillende projecten genoemd (Linkerd, NGINX, HAProxy, Envoy en Istio), maar belangrijker is dat er algemene concepten worden ge\u00efntroduceerd voor data planes, service mesh en control planes. In deze post neem ik een stap terug en leg ik uit wat ik bedoel met de termen \u00abdata plane\u00bb en \u00abcontrol plane\u00bb op een hoog niveau, en hoe deze termen verband houden met de projecten die in de tweets worden genoemd.<\/p>\n<h1>Wat is een service mesh, echt?<\/h1>\n<p>\n<img decoding=\"async\" alt=\"Service mesh, &#039;data plane&#039; en &#039;control plane&#039; (Service mesh data plane vs. control plane)\" src=\"\/wp-content\/uploads\/2019\/08\/63c195aa9bcb7080f6924cecbff0fbc1.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<b>Figuur 1: Overzicht van service mesh<\/b><\/p>\n<p><b>Afbeelding 1<\/b> Illustreert het concept van een service mesh op het meest basale niveau. Er zijn vier serviceclustern (A-D). Elke service-instantie is verbonden met een lokale proxyserver. Al het netwerkverkeer (HTTP, REST, gRPC, Redis, enz.) van een afzonderlijke applicatie-instantie wordt via de lokale proxyserver naar de respectieve externe serviceclustern gestuurd. Op deze manier weet de applicatie-instantie niets van het netwerk als geheel en weet alleen van zijn lokale proxy. In feite is het netwerk van het gedistribueerde systeem verwijderd van de service.<\/p>\n<h1>Data plane<\/h1>\n<p>\nIn een service mesh voert een lokaal proxyserver voor de applicatie de volgende taken uit:<\/p>\n<ul>\n<li> <b>Service ontdekking<\/b>. Welke services\/toepassingen zijn beschikbaar voor uw applicatie?<\/li>\n<li><b>Gezondheidscontrole<\/b>. Zijn de service-exemplaren die door service ontdekking zijn teruggegeven, gezond en klaar om netwerkverkeer te ontvangen? Dit kan zowel actieve (bijvoorbeeld een responscontrole) als passieve (bijvoorbeeld met behulp van 3 opeenvolgende 5xx-fouten als indicatie voor een ongezonde service) controles omvatten. <\/li>\n<li><b>Routering<\/b>Na welke servicecluster moet het verzoek worden verzonden na het ontvangen van een REST-verzoek aan &#171;\\\/foo&#187;? <\/li>\n<li> <b>Load balancing<\/b>. Na het selecteren van de servicecluster tijdens de routering, naar welk service-exemplaar moet het verzoek dan worden gestuurd? Met welke timeout? Met welke circuit breaking-instellingen? Als het verzoek niet slaagt, moet het dan opnieuw worden geprobeerd?<\/li>\n<li> <b>Authenticatie en autorisatie<\/b>. Voor binnenkomende verzoeken kan de oproepende service cryptografisch worden ge\u00efdentificeerd\/geverifieerd met behulp van mTLS of een ander mechanisme? Als het is ge\u00efdentificeerd\/geverifieerd, mag deze dan de gevraagde actie (endpoint) in de service aanroepen of moet een niet-geauthenticeerd antwoord worden teruggegeven?<\/li>\n<li> <b>Observabiliteit<\/b>. Voor elk verzoek moeten gedetailleerde statistieken, logs en gegevens van gedistribueerde tracing worden gegenereerd, zodat operators de gedistribueerde verkeersstroom en foutopsporingsproblemen kunnen begrijpen zodra ze zich voordoen.<\/li>\n<\/ul>\n<p>\nVoor al deze punten in de service mesh is het datavlak verantwoordelijk. In wezen is de lokale (sidecar) proxy het datavlak. Met andere woorden, het datavlak is verantwoordelijk voor de conditionele translatie, verzending en observatie van elk netwerkpakket dat naar de service wordt verzonden of eruit wordt verzonden.<\/p>\n<h1>Het beheervlak<\/h1>\n<p>\nDe netwerkaansluiting die de lokale proxy in het datavlak (data plane) biedt, is magisch (?). Hoe komt de proxy-server er echter achter welk pad &#171;\\\/foo&#187; naar service B gaat? Hoe kunnen de gegevens van serviceontdekking (service discovery), die worden ingevuld door proxyverzoeken, worden gebruikt? Hoe zijn de parameters voor load balancing, time-out (timeout), circuit breaking, enzovoort geconfigureerd? Hoe wordt de applicatie uitgerold met behulp van de blue\\\/green-methode of een methode voor het geleidelijk overdragen van verkeer? Wie stelt de parameters voor systeemwijde authenticatie en autorisatie in?<\/p>\n<p>Al deze punten vallen onder de controlevlak (control plane) van het servicenetwerk (service mesh). <i>Het controlevlak (control plane) neemt een reeks ge\u00efsoleerde proxy's<a class=\"wpil_keyword_link\" href=\"https:\/\/prohoster.info\/nl\/server\/\"   title=\"servers\" data-wpil-keyword-link=\"linked\"  data-wpil-monitor-id=\"1348\">servers<\/a> zonder status en transformeert ze in een gedistribueerd systeem<\/i>.<\/p>\n<p>Ik denk dat de reden waarom veel technici de gescheiden concepten van datavlak (data plane) en controlevlak (control plane) verwarrend vinden, is dat het datavlak voor de meesten vertrouwd is, terwijl het controlevlak vreemd\/unbekend is. We werken al lange tijd met fysieke netwerkrouter en switches. We begrijpen dat pakketten\/aanvragen van punt A naar punt B moeten gaan en wat we daarvoor kunnen gebruiken qua hardware en software. De nieuwe generatie softwareproxy's zijn gewoon trendy versies van de tools die we al heel lang gebruiken.<\/p>\n<p><img decoding=\"async\" alt=\"Service mesh, &#039;data plane&#039; en &#039;control plane&#039; (Service mesh data plane vs. control plane)\" src=\"\/wp-content\/uploads\/2019\/08\/1b512802777cbf1853c5c4f7f2f81d99.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<b>Figuur 2: Menselijk controlevlak (Human control plane)<\/b><\/p>\n<p>We gebruiken al geruime tijd controlevlakken (control plane), hoewel de meeste netwerka operators deze kant van het systeem misschien niet met een technologisch component associ\u00ebren. De reden hiervoor is eenvoudig:<br \/>\n<b>De meeste controlevlakken (control plane) die vandaag de dag worden gebruikt, zijn\u2026 wij<\/b>.<\/p>\n<p>Op <b>in Figuur 2<\/b> Wat ik noem de 'Menselijke besturingslaag (Human control plane)'. In dit type implementatie, dat nog steeds zeer vaak voorkomt, maakt de menselijke operator, waarschijnlijk met enige frustratie, statische configuraties \u2014 mogelijk met behulp van scripts \u2014 en implementeert deze via een speciaal proces op alle proxyservers. Vervolgens beginnen de proxies deze configuratie te gebruiken en verwerken ze de gegevenslaag (data plane) met de bijgewerkte instellingen.<\/p>\n<p><img decoding=\"async\" alt=\"Service mesh, &#039;data plane&#039; en &#039;control plane&#039; (Service mesh data plane vs. control plane)\" src=\"\/wp-content\/uploads\/2019\/08\/6b12429611475e0fc4dfa9f980704e16.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<b>Figuur 3: Geavanceerde besturingslaag van het service-mesh (Advanced service mesh control plane)<\/b><\/p>\n<p>Op <b>figuur 3<\/b> geeft de 'geavanceerde' besturingslaag (control plane) van het service-mesh (service mesh) weer. Deze bestaat uit de volgende onderdelen:<\/p>\n<ul>\n<li> <b>De mens (The human)<\/b>: Er is nog steeds een mens (hopelijk minder boos) die op hoog niveau beslissingen neemt over het hele systeem.<\/li>\n<li><b>Gebruikersinterface van de besturingslaag (Control plane UI)<\/b>: De mens communiceert met een soort gebruikersinterface om het systeem te beheren. Dit kan een webportaal zijn, een command-line interface (CLI) of een andere interface. Via de gebruikersinterface heeft de operator toegang tot globale configuratie-instellingen van het systeem, zoals:\n<ul>\n<li>Implementatiebeheer, blauw\/groen (blue\/green) en\/of geleidelijk verkeersoverdracht <\/li>\n<li>Authenticatie- en autorisatie-instellingen <\/li>\n<li>Specificaties van de routeringtabel, bijvoorbeeld wanneer applicatie A informatie over &#171;\\\/foo&#187; opvraagt, wat gebeurt er dan? <\/li>\n<li>Instellingen van de load balancer, zoals time-outs (timeouts), herhalingspogingen (retries), circuit-breakerparameters enz. <\/li>\n<\/ul>\n<\/li>\n<li> <b>Werklastplanner (Workload scheduler)<\/b>: Diensten worden in de infrastructuur gestart via een planningssysteem\/orchestratie van een bepaald type, zoals Kubernetes of Nomad. De planner is verantwoordelijk voor het laden van de service samen met zijn lokale proxy.<\/li>\n<li> <b>Serviceontdekking (Service discovery)<\/b>. Wanneer de planner instanties van de service start en stopt, rapporteert hij de status van de beschikbaarheid aan het systeem voor serviceontdekking.<\/li>\n<li> <b>API's voor de configuratie van de lokale proxyserver (Sidecar proxy configuration APIs) <\/b>: Lokale proxyservers extraheren dynamisch de status van verschillende systeemcomponenten volgens het 'eventueel consistente' model zonder tussenkomst van de operator. Het volledige systeem, bestaande uit alle momenteel actieve service-instanties en lokale proxyservers, convergeert uiteindelijk naar \u00e9\u00e9n ecosysteem. De API van het universele dataplane in Envoy is een voorbeeld van hoe dit in de praktijk werkt.<\/li>\n<\/ul>\n<p>\nIn wezen is het doel van het controlevlak (control plane) om beleid vast te stellen dat uiteindelijk door het dataplane (data plane) zal worden aangenomen. Geavanceerdere controlevlakken (control planes) zullen de operator meer details van sommige systemen ontzegen en minder handmatige bediening vereisen, mits ze correct functioneren!..<\/p>\n<h1>Data plane versus controlevlak. Samenvatting (Data plane vs. control plane summary)<\/h1>\n<p><\/p>\n<ul>\n<li> <b>Dataplane van het service mesh (Service mesh data plane)<\/b>: raakt elk pakket \/ verzoek in het systeem. Verantwoordelijk voor het ontdekken van applicaties \/ diensten, controle van de beschikbaarheid, routering, load balancing, authenticatie \/ autorisatie en observatie.<\/li>\n<li> <b>Controlevlak van het service mesh (Service mesh control plane)<\/b>: biedt beleid en configuratie voor alle actieve dataplanen binnen het service mesh. Be\u00efnvloedt geen pakketten \/ verzoeken in het systeem. Het controlevlak transformeert alle dataplanen in een gedistribueerd systeem.<\/li>\n<\/ul>\n<p><\/p>\n<h1>Huidige status van het project (Current project landscape)<\/h1>\n<p>\nLaten we, na de bovenstaande uitleg, kijken naar de huidige status van het project 'service mesh'.<\/p>\n<ul>\n<li> <b>Dataplanen (Data planes)<\/b>: Linkerd, NGINX, HAProxy, Envoy, Traefik<\/li>\n<li><b>Controlevlakken (Control planes)<\/b>: Istio, Nelson, SmartStack <\/li>\n<\/ul>\n<p>\nIn plaats van een diepgaande analyse van elk van de bovenstaande oplossingen uit te voeren, zal ik kort stilstaan bij enkele punten die, naar mijn mening, momenteel de meeste verwarring in het ecosysteem veroorzaken.<\/p>\n<p>Begin 2016 was Linkerd een van de eerste proxyservers voor de datavlakte (data plane) in service mesh en heeft het fantastisch werk verricht om het bewustzijn te vergroten en de aandacht voor het ontwerpmodel \u2018service mesh\u2019 te bevorderen. Ongeveer zes maanden later voegde Envoy zich bij Linkerd (hoewel het al aan het werk was bij Lyft sinds eind 2015). Linkerd en Envoy zijn twee projecten die het vaakst worden genoemd in discussies over service meshes.<\/p>\n<p>Istio werd aangekondigd in mei 2017. De doelstellingen van het Istio-project zijn zeer vergelijkbaar met de uitgebreide beheervlakte (control plane) die wordt getoond op <b>figuur 3<\/b>. Envoy fungeert als de standaard proxy voor Istio. Hierdoor fungeert Istio als de beheervlakte (control plane), terwijl Envoy de datavlakte (data plane) vertegenwoordigt. In korte tijd veroorzaakte Istio veel ophef, en andere datavlaktes (data planes) begonnen integratie als vervanging voor Envoy (zowel Linkerd als NGINX hebben integratie met Istio gedemonstreerd). Het feit dat verschillende datavlaktes (data planes) binnen dezelfde beheervlakte (control plane) kunnen worden gebruikt, betekent dat de beheervlakte (control plane) en de datavlakte (data plane) niet noodzakelijkerwijs nauw met elkaar verbonden zijn. Een API zoals de universele API van de datavlakte (data plane) kan een brug vormen tussen de twee delen van het systeem.<\/p>\n<p>Nelson en SmartStack helpen bovendien het onderscheid tussen de beheervlakte (control plane) en de datavlakte (data plane) te illustreren. Nelson gebruikt Envoy als zijn proxy en bouwt een betrouwbare beheervlakte (control plane) voor de service mesh op basis van de HashiCorp-stack, d.w.z. Nomad, enz. SmartStack was waarschijnlijk de eerste van de nieuwe generatie service meshes. SmartStack vormt een beheervlakte (control plane) rond HAProxy of NGINX, en toont de mogelijkheid om de beheervlakte (control plane) van de service mesh los te koppelen van de datavlakte (data plane).<\/p>\n<p>Microservicesarchitectuur met een service mesh trekt steeds meer aandacht (juist!), en steeds meer projecten en leveranciers beginnen in deze richting te werken. In de komende jaren zullen we veel innovaties zien zowel op het gebied van gegevens (data plane) als op het gebied van beheer (control plane), en bovendien een verdere vermenging van verschillende componenten. Uiteindelijk moet de microservicesarchitectuur transparanter en magischer (?) worden voor de operator.<br \/>\nIk hoop dat het steeds minder irritant wordt.<\/p>\n<h1>Belangrijke punten (Key takeaways)<\/h1>\n<p><\/p>\n<ul>\n<li> Een service mesh bestaat uit twee verschillende delen: de gegevenslaag (data plane) en de beheerslaag (control plane). Beide componenten zijn essentieel, en zonder hen zal het systeem niet functioneren.<\/li>\n<li>Iedereen is bekend met de beheerslaag (control plane), en op dit moment kunt u zelf de beheerslaag (control plane) zijn! <\/li>\n<li>Alle gegevenslagen (data plane) concurreren met elkaar op functies, prestaties, configureerbaarheid en schaalbaarheid. <\/li>\n<li> Alle beheerslagen (control plane) concurreren met elkaar op functies, configureerbaarheid, schaalbaarheid en gebruiksvriendelijkheid.<\/li>\n<li>Een beheerslaag (control plane) kan de juiste abstracties en API's bevatten, zodat meerdere gegevenslagen (data plane) kunnen worden gebruikt. <\/li>\n<\/ul>\n<p>Bron: <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\/nl\/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=\"nl_NL\" \/>\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\/nl\/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, \u2018Gegevenslaag\u2019 en \u2018Beheerslagen\u2019 (Service mesh data plane vs. control plane) | ProHoster","description":"Hallo, Habr!","canonical_url":"https:\/\/prohoster.info\/nl\/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":"nl_NL","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\/nl\/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\/nl\/wp-json\/wp\/v2\/posts\/37030","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/prohoster.info\/nl\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/prohoster.info\/nl\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/prohoster.info\/nl\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/prohoster.info\/nl\/wp-json\/wp\/v2\/comments?post=37030"}],"version-history":[{"count":1,"href":"https:\/\/prohoster.info\/nl\/wp-json\/wp\/v2\/posts\/37030\/revisions"}],"predecessor-version":[{"id":158592,"href":"https:\/\/prohoster.info\/nl\/wp-json\/wp\/v2\/posts\/37030\/revisions\/158592"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/prohoster.info\/nl\/wp-json\/wp\/v2\/media\/27757"}],"wp:attachment":[{"href":"https:\/\/prohoster.info\/nl\/wp-json\/wp\/v2\/media?parent=37030"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/prohoster.info\/nl\/wp-json\/wp\/v2\/categories?post=37030"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/prohoster.info\/nl\/wp-json\/wp\/v2\/tags?post=37030"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}