{"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\/de\/blog\/administrirovanie\/servisnaya-set-ploskost-dannyh-i-ploskosti-upravleniya-service-mesh-data-plane-vs-control-plane","title":{"rendered":"Service-Mesh, \u201eDatenebene\u201c und \u201eSteuerungsebene\u201c (Service mesh data plane vs. control plane)","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"<p>Hallo, Habr! Ich pr\u00e4sentiere Ihnen eine \u00dcbersetzung des Artikels. <noindex><a rel=\"nofollow\" href=\"https:\/\/blog.envoyproxy.io\/service-mesh-data-plane-vs-control-plane-2774e720f7fc\">\u201eService Mesh Datenebene vs. Steuerungsebene\u201c<\/a><\/noindex> Autor <b>Matt Klein<\/b>.<\/p>\n<p><img decoding=\"async\" alt=\"Service-Mesh, \u201eDatenebene\u201c und \u201eSteuerungsebene\u201c (Service mesh data plane vs. control plane)\" src=\"\/wp-content\/uploads\/2019\/08\/487456689eb832f9e3845966cb0d85d4.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nIn dieser Ausgabe habe ich das Bed\u00fcrfnis versp\u00fcrt, die Beschreibung beider Komponenten des Service Mesh \u2013 Datenebene und Steuerungsebene \u2013 zu \u00fcbersetzen. Diese Beschreibung erschien mir am verst\u00e4ndlichsten und interessantesten und f\u00fchrt vor allem zur Frage: \u201eIst es \u00fcberhaupt notwendig?\u201c.<\/p>\n<p>Da die Idee des \u201eService Mesh\u201c in den letzten zwei Jahren zunehmend popul\u00e4r wird (der urspr\u00fcngliche Artikel stammt vom 10. Oktober 2017) und die Anzahl der Akteure in diesem Bereich gestiegen ist, habe ich ein entsprechendes Wachstum der Verwirrung innerhalb der gesamten technischen Gemeinschaft hinsichtlich des Vergleichs und der Gegen\u00fcberstellung verschiedener L\u00f6sungen beobachtet.<br \/>\n<noindex><a rel=\"nofollow\" name=\"habracut\"><\/a><\/noindex><br \/>\nDie Situation l\u00e4sst sich am besten mit den folgenden Tweets beschreiben, die ich im Juli geschrieben habe:<\/p>\n<blockquote><p>Verwirrung \u00fcber das Service Mesh Nr. 1: Linkerd ~ = Nginx ~ = Haproxy ~ = Envoy. Keiner dieser ist gleich Istio. Istio ist etwas ganz anderes. 1 \/<\/p><\/blockquote>\n<blockquote><p>Die ersten sind einfach Datenebenen. An sich tun sie nichts. Sie m\u00fcssen auf etwas Gr\u00f6\u00dferes konfiguriert werden. 2 \/<\/p><\/blockquote>\n<blockquote><p>Istio ist ein Beispiel f\u00fcr eine Steuerungsebene, die die Teile zusammenbindet. Es ist eine andere Schicht. \/ Ende<\/p><\/blockquote>\n<p>In den vorherigen Tweets werden mehrere verschiedene Projekte (Linkerd, NGINX, HAProxy, Envoy und Istio) erw\u00e4hnt, aber was noch wichtiger ist, es werden grundlegende Konzepte der Datenebene, des Service Mesh und der Steuerungsebene eingef\u00fchrt. In diesem Beitrag werde ich einen Schritt zur\u00fcckgehen und erl\u00e4utern, was ich unter den Begriffen \u201eDatenebene\u201c und \u201eSteuerungsebene\u201c auf sehr hohem Niveau verstehe, und dann erl\u00e4utern, wie diese Begriffe sich auf die in den Tweets erw\u00e4hnten Projekte beziehen.<\/p>\n<h1>Was ist ein Service Mesh (What is a service mesh, really)?<\/h1>\n<p>\n<img decoding=\"async\" alt=\"Service-Mesh, \u201eDatenebene\u201c und \u201eSteuerungsebene\u201c (Service mesh data plane vs. control plane)\" src=\"\/wp-content\/uploads\/2019\/08\/63c195aa9bcb7080f6924cecbff0fbc1.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<b>Abb. 1: \u00dcberblick \u00fcber das Service Mesh (Service mesh overview)<\/b><\/p>\n<p><b>Abb. 1<\/b> veranschaulicht das Konzept des Service Mesh auf der grundlegendsten Ebene. Es gibt vier Servicecluster (A-D). Jede Instanz des Dienstes ist mit einem lokalen Proxy-Server verbunden. Der gesamte Netzwerkverkehr (HTTP, REST, gRPC, Redis usw.) einer einzelnen Anwendungsinstanz wird \u00fcber den lokalen Proxy-Server zu den entsprechenden externen Serviceclustern geleitet. Somit kennt die Anwendungsinstanz nur ihren lokalen Proxy und nicht das gesamte Netzwerk. Tats\u00e4chlich wurde das Netzwerk des verteilten Systems von dem Dienst entfernt.<\/p>\n<h1>Datenebene (Data plane)<\/h1>\n<p>\nIm Service Mesh f\u00fchrt der lokal f\u00fcr die Anwendung eingestellte Proxy-Server folgende Aufgaben aus:<\/p>\n<ul>\n<li> <b>Service Discovery<\/b>. Welche Dienste\/Services\/Anwendungen stehen f\u00fcr Ihre Anwendung zur Verf\u00fcgung?<\/li>\n<li><b>Health Checking<\/b>. Sind die von der Service Discovery zur\u00fcckgegebenen Service-Instanzen funktionsf\u00e4hig und bereit, Netzwerktraffic zu empfangen? Dies kann sowohl aktive (z.B. Antwortpr\u00fcfung\/Healthcheck) als auch passive (z.B. durch Verwendung von 3 aufeinanderfolgenden 5xx-Fehlern als Indikator f\u00fcr einen ungesunden Zustand des Dienstes) Pr\u00fcfungen der Funktionsf\u00e4higkeit umfassen. <\/li>\n<li><b>Routing<\/b>Wenn Sie eine REST-Anfrage an &#171;\\\/foo&#187; erhalten, an welchen Service-Cluster sollte die Anfrage gesendet werden? <\/li>\n<li> <b>Load Balancing<\/b>. Nachdem w\u00e4hrend des Routings ein Service-Cluster ausgew\u00e4hlt wurde, an welche Service-Instanz sollte die Anfrage gesendet werden? Mit welcher Timeout-Dauer? Mit welchen Circuit-Breaking-Einstellungen? Sollte die Anfrage wiederholt werden, wenn sie fehlschl\u00e4gt?<\/li>\n<li> <b>Authentication and Authorization<\/b>. Kann der aufrufende Dienst f\u00fcr eingehende Anfragen kryptografisch identifiziert\/autorisiert werden, z.B. mit mTLS oder einem anderen Mechanismus? Wenn er identifiziert\/autorisiert ist, darf er die angeforderte Operation (Endpoint) im Dienst aufrufen, oder sollte eine nicht authentifizierte Antwort zur\u00fcckgegeben werden?<\/li>\n<li> <b>Observability<\/b>. F\u00fcr jede Anfrage sollten detaillierte Statistiken, Protokolle und Daten zur verteilten Nachverfolgung generiert werden, damit die Betreiber den verteilten Datenfluss und die Debugging-Probleme im Falle ihrer Entstehung verstehen k\u00f6nnen.<\/li>\n<\/ul>\n<p>\nF\u00fcr alle oben genannten Punkte ist die Datenebene (data plane) im Servicenetzwerk (service mesh) verantwortlich. Im Wesentlichen ist der lokale Service-Proxy (Sidecar) die Datenebene (data plane). Mit anderen Worten, die Datenebene (data plane) ist verantwortlich f\u00fcr die bedingte \u00dcbertragung, das Routing und die \u00dcberwachung jedes Netzwerkpakets, das an den Dienst gesendet oder von diesem gesendet wird.<\/p>\n<h1>Die Steuerungsebene (The Control Plane)<\/h1>\n<p>\nDie Netzwerkanalyse, die der lokale Proxy in der Datenebene (data plane) bereitstellt, ist magisch (?). Wie erf\u00e4hrt der Proxy-Server jedoch tats\u00e4chlich vom Pfad &#171;\\\/foo&#187; zum Service B? Wie k\u00f6nnen die durch Proxy-Anfragen generierten Serviceentdeckungsdaten genutzt werden? Wie sind die Parameter f\u00fcr Lastverteilung, Zeit\u00fcberschreitung (timeout), Circuit Breaking usw. konfiguriert? Wie erfolgt die Bereitstellung der Anwendung mittels der Blau\/Gr\u00fcn-Methode oder der schrittweisen Traffic-Umleitung? Wer konfiguriert die Parameter f\u00fcr die systemweite Authentifizierung und Autorisierung?<\/p>\n<p>All diese Punkte fallen in den Verantwortungsbereich der Steuerungsebene (control plane) des Service Mesh. <i>Die Steuerungsebene (control plane) nimmt eine Reihe isolierter Proxies ohne Zustand und verwandelt sie in ein verteiltes System.<a class=\"wpil_keyword_link\" href=\"https:\/\/prohoster.info\/de\/server\/\"   title=\"Server\" data-wpil-keyword-link=\"linked\"  data-wpil-monitor-id=\"1348\">Server<\/a> Ich denke, der Grund, warum viele Technologen die Konzepte von Datenebene (data plane) und Steuerungsebene (control plane) verwirrend finden, liegt darin, dass die Datenebene vielen vertraut ist, w\u00e4hrend die Steuerungsebene fremd\/unverst\u00e4ndlich ist. Wir arbeiten schon lange mit physischen Netzwerkrouten und Switches. Wir verstehen, dass Pakete\/Anfragen von Punkt A nach Punkt B gelangen m\u00fcssen und welches Hardware- und Softwaremittel wir daf\u00fcr verwenden k\u00f6nnen. Die neue Generation der Software-Proxies sind einfach moderne Versionen von Werkzeugen, die wir schon lange verwenden.<\/i>.<\/p>\n<p>Abbildung 2: Die menschliche Steuerungsebene (Human control plane).<\/p>\n<p><img decoding=\"async\" alt=\"Service-Mesh, \u201eDatenebene\u201c und \u201eSteuerungsebene\u201c (Service mesh data plane vs. control plane)\" src=\"\/wp-content\/uploads\/2019\/08\/1b512802777cbf1853c5c4f7f2f81d99.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<b>Allerdings verwenden wir schon lange Steuerungsebenen (control planes), auch wenn die meisten Netzwerkadministratoren diese Systemkomponente m\u00f6glicherweise nicht mit einem technologischen Element in Verbindung bringen. Der Grund daf\u00fcr ist einfach:<\/b><\/p>\n<p>Die meisten der heutigen verwendeten Steuerungsebenen (control planes) sind\u2026 wir<br \/>\n<b>in Abbildung 2.<\/b>.<\/p>\n<p>Auf <b>Abbildung 2<\/b> Hier wird das gezeigt, was ich die \u201eMenschliche Steuerungsebene (Human control plane)\u201c nenne. In dieser Art der Bereitstellung, die immer noch sehr h\u00e4ufig vorkommt, erstellt der menschliche Operator, wahrscheinlich m\u00fcrrisch, statische Konfigurationen \u2013 m\u00f6glicherweise mit Hilfe von Skripten \u2013 und implementiert sie \u00fcber einen speziellen Prozess auf allen Proxy-Servern. Dann beginnen die Proxys, diese Konfiguration zu verwenden und verarbeiten die Datenplane (data plane) mit den aktualisierten Einstellungen.<\/p>\n<p><img decoding=\"async\" alt=\"Service-Mesh, \u201eDatenebene\u201c und \u201eSteuerungsebene\u201c (Service mesh data plane vs. control plane)\" src=\"\/wp-content\/uploads\/2019\/08\/6b12429611475e0fc4dfa9f980704e16.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<b>Abbildung 3: Erweiterte Steuerungsebene des Servicenetzes (Advanced service mesh control plane)<\/b><\/p>\n<p>Auf <b>Abbildung 3<\/b> zeigt die \u201aerweiterte\u2018 Steuerungsebene (control plane) des Servicenetzes (service mesh). Sie besteht aus den folgenden Teilen:<\/p>\n<ul>\n<li> <b>Der Mensch (The human)<\/b>: Es gibt immer noch einen Menschen (hoffentlich weniger ver\u00e4rgert), der hochrangige Entscheidungen \u00fcber das Gesamtsystem trifft.<\/li>\n<li><b>Benutzeroberfl\u00e4che der Steuerungsebene (Control plane UI)<\/b>: Der Mensch interagiert mit einer Art von Benutzeroberfl\u00e4che zur Verwaltung des Systems. Dies kann ein Webportal, eine Befehlszeilenanwendung (CLI) oder eine andere Schnittstelle sein. \u00dcber die Benutzeroberfl\u00e4che hat der Operator Zugriff auf globale Systemkonfigurationsparameter wie:\n<ul>\n<li>Bereitstellungsmanagement, blau\/gr\u00fcn (blue\/green) und\/oder schrittweise \u00dcbertragung des Datenverkehrs <\/li>\n<li>Authentifizierungs- und Autorisierungsparameter <\/li>\n<li>Spezifikationen der Routingtabelle, zum Beispiel, was passiert, wenn Anwendung A Informationen \u00fcber &#171;\\\/foo&#187; anfordert. <\/li>\n<li>Einstellungen des Lastenausgleichs, z.B. Zeit\u00fcberschreitungen (timeouts), Wiederholungsversuche (retries), circuit breaking Parameter usw. <\/li>\n<\/ul>\n<\/li>\n<li> <b>Arbeitslastplaner (Workload scheduler)<\/b>: Dienste werden \u00fcber ein Planung\/Orchestrierungssystem eines bestimmten Typs, z.B. Kubernetes oder Nomad, in der Infrastruktur gestartet. Der Planer ist verantwortlich f\u00fcr die Bereitstellung des Dienstes zusammen mit seinem lokalen Proxy-Server.<\/li>\n<li> <b>Dienstentdeckung (Service discovery)<\/b>. Wenn der Planer Instanzen des Dienstes startet und stoppt, reportiert er den Betriebsstatus an das Dienstentdeckungssystem.<\/li>\n<li> <b>APIs zur Konfiguration des lokalen Proxy-Servers (Sidecar proxy configuration APIs) <\/b>: Lokale Proxy-Server ziehen dynamisch den Status aus verschiedenen Komponenten des Systems nach dem Modell der \u201eeventuell konsistenten\u201c (eventually consistent) Architektur ohne das Eingreifen eines Operators. Das gesamte System, das aus allen derzeit laufenden Instanzen von Diensten und lokalen Proxy-Servern besteht, konvergiert letztendlich zu einem Ecosystem. Die API der universellen Datenebene (data plane) in Envoy ist ein Beispiel daf\u00fcr, wie dies in der Praxis funktioniert.<\/li>\n<\/ul>\n<p>\nIm Wesentlichen besteht das Ziel der Steuerungsebene (control plane) darin, eine Richtlinie festzulegen, die letztendlich von der Datenebene (data plane) \u00fcbernommen wird. Fortgeschrittenere Steuerungsebenen (control planes) entziehen dem Operator mehr Details bestimmter Systeme und erfordern weniger manuelle Eingriffe, vorausgesetzt, sie funktionieren korrekt!.<\/p>\n<h1>Datenebene und Steuerungsebene. Zusammenfassung (Data plane vs. control plane summary)<\/h1>\n<p><\/p>\n<ul>\n<li> <b>Datenebene des Service Mesh (Service mesh data plane)<\/b>: betrifft jedes Paket \/ jede Anfrage im System. Verantwortlich f\u00fcr die Entdeckung von Anwendungen \/ Diensten, die \u00dcberpr\u00fcfung der Verf\u00fcgbarkeit, das Routing, die Lastverteilung, die Authentifizierung \/ Autorisierung und die Beobachtbarkeit.<\/li>\n<li> <b>Steuerungsebene des Service Mesh (Service mesh control plane)<\/b>: stellt Richtlinien und Konfigurationen f\u00fcr alle aktiven Datenebenen innerhalb des Service Mesh bereit. Beeinflusst keine Pakete \/ Anfragen im System. Die Steuerungsebene verwandelt alle Datenebenen in ein verteiltes System.<\/li>\n<\/ul>\n<p><\/p>\n<h1>Aktueller Stand des Projekts (Current project landscape)<\/h1>\n<p>\nNachdem wir die obige Erkl\u00e4rung verstanden haben, lassen Sie uns einen Blick auf den aktuellen Stand des Projekts \u201eService Mesh\u201c werfen.<\/p>\n<ul>\n<li> <b>Datenebenen (Data planes)<\/b>: Linkerd, NGINX, HAProxy, Envoy, Traefik<\/li>\n<li><b>Steuerungsebenen (Control planes)<\/b>: Istio, Nelson, SmartStack <\/li>\n<\/ul>\n<p>\nAnstatt eine tiefgehende Analyse jeder der oben genannten L\u00f6sungen durchzuf\u00fchren, m\u00f6chte ich kurz auf einige Punkte eingehen, die meiner Meinung nach den Gro\u00dfteil der Verwirrung im \u00d6kosystem gerade jetzt ausl\u00f6sen.<\/p>\n<p>Zu Beginn des Jahres 2016 war Linkerd einer der ersten Proxy-Server f\u00fcr die Datenebene (data plane) in einem Service-Mesh und hat hervorragende Arbeit geleistet, um das Bewusstsein und das Interesse an dem Designmodell \u201eService-Mesh\u201c zu steigern. Etwa sechs Monate sp\u00e4ter schloss sich Envoy Linkerd an (obwohl es bereits seit Ende 2015 bei Lyft t\u00e4tig war). Linkerd und Envoy sind zwei Projekte, die oft in Gespr\u00e4chen \u00fcber Service-Meshs erw\u00e4hnt werden.<\/p>\n<p>Istio wurde im Mai 2017 angek\u00fcndigt. Die Ziele des Istio-Projekts \u00e4hneln stark der erweiterten Steuerungsebene (control plane), die angezeigt wird. <b>Abbildung 3<\/b>Envoy ist der standardm\u00e4\u00dfige Proxy f\u00fcr Istio. So stellt Istio die Steuerungsebene (control plane) dar, w\u00e4hrend Envoy die Datenebene (data plane) bildet. In kurzer Zeit hat Istio f\u00fcr gro\u00dfes Aufsehen gesorgt, und andere Datenebenen (data plane) begannen ihre Integration als Ersatz f\u00fcr Envoy (sowohl Linkerd als auch NGINX haben die Integration mit Istio demonstriert). Die Tatsache, dass in einer Steuerungsebene (control plane) verschiedene Datenebenen (data plane) verwendet werden k\u00f6nnen, bedeutet, dass Steuerungsebene (control plane) und Datenebene (data plane) nicht unbedingt eng miteinander verbunden sind. Eine API, wie die universelle API der Datenebene (data plane), kann eine Br\u00fccke zwischen den beiden Teilen des Systems bilden.<\/p>\n<p>Nelson und SmartStack helfen, die Trennung zwischen Steuerungsebene (control plane) und Datenebene (data plane) weiter zu veranschaulichen. Nelson verwendet Envoy als seinen Proxy und baut eine zuverl\u00e4ssige Steuerungsebene (control plane) f\u00fcr das Service-Mesh auf der Basis des HashiCorp-Stacks auf, d.h. Nomad usw. SmartStack war vielleicht das erste aus der neuen Welle von Service-Meshs. SmartStack bildet eine Steuerungsebene (control plane) rund um HAProxy oder NGINX und zeigt die M\u00f6glichkeit der Entkopplung der Steuerungsebene (control plane) vom Service-Mesh und der Datenebene (data plane) auf.<\/p>\n<p>Mikroservice-Architekturen mit Service Mesh ziehen immer mehr Aufmerksamkeit auf sich (zu Recht!), und immer mehr Projekte und Anbieter beginnen, in diesem Bereich zu arbeiten. In den n\u00e4chsten Jahren werden wir viele Innovationen sowohl im Daten- (data plane) als auch im Steuerungsbereich (control plane) sehen, sowie eine weitere Vermischung verschiedener Komponenten. Letztendlich sollte die Mikroservice-Architektur transparenter und magischer (?) f\u00fcr den Operator werden.<br \/>\nIch hoffe, immer weniger irritiert zu sein.<\/p>\n<h1>Wichtige Punkte (Key takeaways)<\/h1>\n<p><\/p>\n<ul>\n<li> Ein Service Mesh besteht aus zwei verschiedenen Teilen: der Datenebene (data plane) und der Steuerungsebene (control plane). Beide Komponenten sind unerl\u00e4sslich, ohne sie wird das System nicht funktionieren.<\/li>\n<li>Alle sind mit der Steuerungsebene (control plane) vertraut, und im Moment k\u00f6nnte es auch Ihre Steuerungsebene (control plane) sein! <\/li>\n<li>Alle Datenebenen (data plane) konkurrieren in Bezug auf Funktionen, Leistung, Konfigurierbarkeit und Erweiterbarkeit. <\/li>\n<li> Alle Steuerungsebenen (control plane) konkurrieren in Bezug auf Funktionen, Konfigurierbarkeit, Erweiterbarkeit und Benutzerfreundlichkeit.<\/li>\n<li>Eine Steuerungsebene (control plane) kann die richtigen Abstraktionen und APIs enthalten, um mehrere Datenebenen (data plane) nutzen zu k\u00f6nnen. <\/li>\n<\/ul>\n<p>Quelle: <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.1.1 - 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\/de\/blog\/administrirovanie\/servisnaya-set-ploskost-dannyh-i-ploskosti-upravleniya-service-mesh-data-plane-vs-control-plane\" \/>\n\t<meta name=\"generator\" content=\"All in One SEO (AIOSEO) 5.0.1.1\" \/>\n\t\t<meta property=\"og:locale\" content=\"de_DE\" \/>\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\/de\/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, \u201eDatenebene\u201c und \u201eSteuerungsebenen\u201c (Service mesh data plane vs. control plane) | ProHoster","description":"Hallo, Habra!","canonical_url":"https:\/\/prohoster.info\/de\/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":"de_DE","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\/de\/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\/de\/wp-json\/wp\/v2\/posts\/37030","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/prohoster.info\/de\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/prohoster.info\/de\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/prohoster.info\/de\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/prohoster.info\/de\/wp-json\/wp\/v2\/comments?post=37030"}],"version-history":[{"count":1,"href":"https:\/\/prohoster.info\/de\/wp-json\/wp\/v2\/posts\/37030\/revisions"}],"predecessor-version":[{"id":158592,"href":"https:\/\/prohoster.info\/de\/wp-json\/wp\/v2\/posts\/37030\/revisions\/158592"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/prohoster.info\/de\/wp-json\/wp\/v2\/media\/27757"}],"wp:attachment":[{"href":"https:\/\/prohoster.info\/de\/wp-json\/wp\/v2\/media?parent=37030"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/prohoster.info\/de\/wp-json\/wp\/v2\/categories?post=37030"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/prohoster.info\/de\/wp-json\/wp\/v2\/tags?post=37030"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}