{"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\/it\/blog\/administrirovanie\/servisnaya-set-ploskost-dannyh-i-ploskosti-upravleniya-service-mesh-data-plane-vs-control-plane","title":{"rendered":"Rete di servizio, \u00abPiano dati\u00bb e \u00abPiani di controllo\u00bb (Service mesh data plane vs. control plane)","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"<p>Ciao, Habr! Vi presento la traduzione dell'articolo <noindex><a rel=\"nofollow\" href=\"https:\/\/blog.envoyproxy.io\/service-mesh-data-plane-vs-control-plane-2774e720f7fc\">\u00abPiano dati vs piano di controllo del service mesh\u00bb<\/a><\/noindex> autore <b>Matt Klein<\/b>.<\/p>\n<p><img decoding=\"async\" alt=\"Rete di servizio, \u00abPiano dati\u00bb e \u00abPiani di controllo\u00bb (Service mesh data plane vs. control plane)\" src=\"\/wp-content\/uploads\/2019\/08\/487456689eb832f9e3845966cb0d85d4.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nQuesta volta ho \u00abvoluto e tradotto\u00bb la descrizione di entrambi i componenti del service mesh, piano dati e piano di controllo. Questa descrizione mi \u00e8 sembrata la pi\u00f9 chiara e interessante, e soprattutto conduce alla comprensione di \u00ab\u00c8 davvero necessario?\u00bb.<\/p>\n<p>Poich\u00e9 l'idea del \u00abService mesh\u00bb \u00e8 diventata sempre pi\u00f9 popolare negli ultimi due anni (articolo originale del 10 ottobre 2017), e il numero di partecipanti nello spazio \u00e8 aumentato, ho notato una crescente confusione tra tutta la comunit\u00e0 tecnica su come confrontare e contrapporre le diverse soluzioni.<br \/>\n<noindex><a rel=\"nofollow\" name=\"habracut\"><\/a><\/noindex><br \/>\nLa situazione pu\u00f2 essere meglio descritta dalle seguenti serie di tweet che ho scritto a luglio:<\/p>\n<blockquote><p>Confusione sul service mesh n. 1: Linkerd ~ = Nginx ~ = Haproxy ~ = Envoy. Nessuno di essi \u00e8 uguale a Istio. Istio \u00e8 qualcosa di completamente diverso. 1 \/<\/p><\/blockquote>\n<blockquote><p>I primi sono semplici piani dati. Da soli non fanno nulla. Devono essere configurati per qualcosa di pi\u00f9 grande. 2 \/<\/p><\/blockquote>\n<blockquote><p>Istio \u00e8 un esempio di piano di controllo che collega le parti insieme. \u00c8 un altro livello. \/fine<\/p><\/blockquote>\n<p>Nei tweet precedenti vengono menzionati diversi progetti (Linkerd, NGINX, HAProxy, Envoy e Istio), ma, cosa pi\u00f9 importante, vengono introdotti concetti comuni di piano dati, service mesh e piano di controllo. In questo post far\u00f2 un passo indietro e spiegher\u00f2 cosa intendo con i termini \u00abpiano dati\u00bb e \u00abpiano di controllo\u00bb a un livello molto alto, e poi parler\u00f2 di come i termini si riferiscono ai progetti menzionati nei tweet.<\/p>\n<h1>Che cos'\u00e8 davvero un service mesh?<\/h1>\n<p>\n<img decoding=\"async\" alt=\"Rete di servizio, \u00abPiano dati\u00bb e \u00abPiani di controllo\u00bb (Service mesh data plane vs. control plane)\" src=\"\/wp-content\/uploads\/2019\/08\/63c195aa9bcb7080f6924cecbff0fbc1.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<b>Figura 1: Panoramica del service mesh<\/b><\/p>\n<p><b>Figura 1<\/b> illustra il concetto di service mesh a un livello molto basico. Ci sono quattro cluster di servizi (A-D). Ogni istanza di servizio \u00e8 collegata a un proxy locale. Tutto il traffico di rete (HTTP, REST, gRPC, Redis, ecc.) da ciascuna istanza dell'applicazione viene instradato attraverso il proxy locale ai corrispondenti cluster di servizi esterni. In questo modo, l'istanza dell'applicazione non \u00e8 a conoscenza della rete nel suo complesso e sa solo del proprio proxy locale. In effetti, la rete del sistema distribuito \u00e8 stata rimossa dal servizio.<\/p>\n<h1>Piano dati<\/h1>\n<p>\nNel service mesh, il proxy situato localmente per l'applicazione svolge le seguenti funzioni:<\/p>\n<ul>\n<li> <b>Scoperta dei servizi (Service discovery)<\/b>. Quali servizi\/misure\/applicazioni sono disponibili per la tua applicazione?<\/li>\n<li><b>Controllo della salute (Health checking)<\/b>. Gli esemplari dei servizi restituiti dalla scoperta dei servizi (service discovery) sono operativi e pronti a ricevere traffico di rete? Questo pu\u00f2 includere controlli sia attivi (ad esempio, verifica della risposta \/ health check) che passivi (ad esempio, utilizzando 3 errori consecutivi 5xx come indicazione dello stato non sano del servizio). <\/li>\n<li><b>Instradamento (Routing)<\/b>Ricevendo una richiesta REST al servizio &#171;\\\/foo&#187;, in quale cluster di servizi dovrebbe essere inviata la richiesta? <\/li>\n<li> <b>Bilanciamento del carico (Load balancing)<\/b>. Dopo che \u00e8 stato scelto un cluster di servizio durante l'instradamento, a quale esemplare di servizio deve essere inviata la richiesta? Con quale timeout? Con quali impostazioni di interruzione del circuito (circuit breaking)? Se la richiesta non riesce, deve essere ripetuta?<\/li>\n<li> <b>Autenticazione e autorizzazione (Authentication and authorization)<\/b>. Per le richieste in entrata, il servizio chiamante pu\u00f2 essere identificato\/autorizzato crittograficamente utilizzando mTLS o qualche altro meccanismo? Se \u00e8 identificato\/autorizzato, gli \u00e8 permesso invocare l'operazione richiesta (endpoint) nel servizio o deve essere restituita una risposta non autenticata?<\/li>\n<li> <b>Osservabilit\u00e0 (Observability)<\/b>. Per ogni richiesta devono essere generati dettagli statistici, log e dati di tracciamento distribuito in modo che gli operatori possano comprendere il flusso di traffico distribuito e i problemi di debug mentre si presentano.<\/li>\n<\/ul>\n<p>\nPer tutti i punti precedenti nella rete di servizio (service mesh), \u00e8 responsabile il piano dati (data plane). In sostanza, un proxy locale per il servizio (sidecar) \u00e8 il piano dati (data plane). In altre parole, il piano dati (data plane) \u00e8 responsabile della trasmissione condizionale, dell'inoltro e dell'osservazione di ogni pacchetto di rete che viene inviato al servizio o da esso.<\/p>\n<h1>Il piano di controllo (The control plane)<\/h1>\n<p>\nL'astrazione di rete fornita dal proxy locale nel piano dati \u00e8 magica (?). Tuttavia, come fa il proxy a conoscere il percorso &#171;\\\/foo&#187; verso il servizio B? Come possono essere utilizzati i dati di scoperta dei servizi (service discovery), che vengono popolati dalle richieste del proxy? Come sono configurati i parametri di bilanciamento del carico, timeout, interruzione del circuito e altro? Come avviene il deployment dell'applicazione utilizzando il metodo blu\/verdi (blue\/green) o il metodo di trasferimento graduale del traffico? Chi configura i parametri di autenticazione e autorizzazione a livello di sistema?<\/p>\n<p>Tutti i punti sopra menzionati sono sotto la responsabilit\u00e0 del piano di controllo della rete dei servizi. <i>Il piano di controllo prende un insieme di proxy isolati<a class=\"wpil_keyword_link\" href=\"https:\/\/prohoster.info\/it\/server\/\"   title=\"server\" data-wpil-keyword-link=\"linked\"  data-wpil-monitor-id=\"1348\">server<\/a> senza stato e li trasforma in un sistema distribuito.<\/i>.<\/p>\n<p>Penso che il motivo per cui molti tecnici trovino complicati i concetti separati del piano dei dati e del piano di controllo sia che per la maggior parte delle persone il piano dei dati \u00e8 familiare, mentre il piano di controllo \u00e8 estraneo\/incomprensibile. Lavoriamo con router e switch di rete fisici da molto tempo. Sappiamo che i pacchetti\/richeste devono andare da un punto A a un punto B, e che possiamo utilizzare hardware e software per questo. La nuova generazione di proxy software \u00e8 solo una versione alla moda degli strumenti che abbiamo usato per lungo tempo.<\/p>\n<p><img decoding=\"async\" alt=\"Rete di servizio, \u00abPiano dati\u00bb e \u00abPiani di controllo\u00bb (Service mesh data plane vs. control plane)\" src=\"\/wp-content\/uploads\/2019\/08\/1b512802777cbf1853c5c4f7f2f81d99.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<b>Figura 2: Piano di controllo umano<\/b><\/p>\n<p>Tuttavia, utilizziamo i piani di controllo da molto tempo, anche se la maggior parte degli operatori di rete potrebbe non associare questa parte del sistema a un componente tecnologico. Il motivo \u00e8 semplice:<br \/>\n<b>La maggior parte dei piani di controllo utilizzati oggi \u00e8\u2026 noi<\/b>.<\/p>\n<p>A <b>nella figura 2<\/b> viene mostrato quello che chiamo \u00abPiano di controllo umano (Human control plane)\u00bb. In questo tipo di distribuzione, che \u00e8 ancora molto comune, un operatore umano, probabilmente brontolone, crea configurazioni statiche \u2014 potenzialmente con script \u2014 e le distribuisce attraverso un qualche processo speciale su tutti i server proxy. I proxy poi iniziano ad utilizzare questa configurazione e iniziano a elaborare il piano dati (data plane) utilizzando le impostazioni aggiornate.<\/p>\n<p><img decoding=\"async\" alt=\"Rete di servizio, \u00abPiano dati\u00bb e \u00abPiani di controllo\u00bb (Service mesh data plane vs. control plane)\" src=\"\/wp-content\/uploads\/2019\/08\/6b12429611475e0fc4dfa9f980704e16.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<b>Figura 3: Piano di controllo avanzato della rete di servizio (Advanced service mesh control plane)<\/b><\/p>\n<p>A <b>nella figura 3<\/b> viene mostrato il \u00abpiano di controllo\u00bb (control plane) avanzato della rete di servizio (service mesh). Esso \u00e8 composto dalle seguenti parti:<\/p>\n<ul>\n<li> <b>Umano (The human)<\/b>: C'\u00e8 ancora un umano (spero meno arrabbiato) che prende decisioni ad alto livello riguardo all'intero sistema.<\/li>\n<li><b>Interfaccia utente del piano di controllo (Control plane UI)<\/b>: L'umano interagisce con un qualche tipo di interfaccia utente per gestire il sistema. Questo pu\u00f2 essere un portale web, un'applicazione della riga di comando (CLI) o un altro tipo di interfaccia. Utilizzando l'interfaccia utente, l'operatore ha accesso a impostazioni globali di configurazione di sistema come:\n<ul>\n<li>Gestione delle distribuzioni, blu\/verde (blue\/green) e\/o il passaggio graduale del traffico <\/li>\n<li>Impostazioni di autenticazione e autorizzazione <\/li>\n<li>Specifiche della tabella di routing, ad esempio, quando l'applicazione A chiede informazioni su &#171;\\\/foo&#187;, cosa succede <\/li>\n<li>Impostazioni del bilanciatore di carico, come timeout, ritentativi, parametri di interruzione circuitale e cos\u00ec via. <\/li>\n<\/ul>\n<\/li>\n<li> <b>Pianificatore di carico di lavoro (Workload scheduler)<\/b>: I servizi vengono avviati nell'infrastruttura tramite un sistema di pianificazione\/orchestrazione di un certo tipo, come Kubernetes o Nomad. Il pianificatore \u00e8 responsabile dell'avvio del servizio insieme al suo proxy locale.<\/li>\n<li> <b>Scoperta dei servizi (Service discovery)<\/b>. Quando il pianificatore avvia e ferma le istanze di servizio, comunica lo stato di disponibilit\u00e0 nel sistema di scoperta dei servizi.<\/li>\n<li> <b>API di configurazione del proxy locale (Sidecar proxy configuration APIs) <\/b>: I proxy locali estraggono dinamicamente lo stato da vari componenti del sistema secondo il modello di \u00abcoerenza alla fine\u00bb (eventually consistent) senza intervento dell'operatore. L'intero sistema, composto da tutte le istanze di servizio e i proxy locali attualmente in esecuzione, converge infine in un'unica ecosistema. L'API del piano dati (data plane) universale in Envoy \u00e8 un esempio di come ci\u00f2 funzioni nella pratica.<\/li>\n<\/ul>\n<p>\nIn sostanza, l'obiettivo del piano di controllo (control plane) \u00e8 quello di stabilire una politica che alla fine sar\u00e0 accettata dal piano dati (data plane). Piani di controllo (control plane) pi\u00f9 avanzati rimuoveranno pi\u00f9 dettagli da alcuni sistemi dall'operatore e richiederanno meno gestione manuale, a condizione che funzionino correttamente!..<\/p>\n<h1>Piano dati e piano di controllo. Riepilogo (Data plane vs. control plane summary)<\/h1>\n<p><\/p>\n<ul>\n<li> <b>Piano dati della rete di servizi (Service mesh data plane)<\/b>: riguarda ogni pacchetto \/ richiesta nel sistema. Responsabile della scoperta delle applicazioni \/ servizi, del controllo della disponibilit\u00e0, della routing, del bilanciamento del carico, dell'autenticazione \/ autorizzazione e dell'osservabilit\u00e0.<\/li>\n<li> <b>Piano di controllo della rete di servizi (Service mesh control plane)<\/b>: fornisce politiche e configurazioni per tutti i piani dati funzionanti all'interno della rete di servizi. Non tocca nessun pacchetto \/ richiesta nel sistema. Il piano di controllo trasforma tutti i piani dati in un sistema distribuito.<\/li>\n<\/ul>\n<p><\/p>\n<h1>Stato attuale del progetto (Current project landscape)<\/h1>\n<p>\nDopo aver esaminato la spiegazione sopra, diamo un'occhiata allo stato attuale del progetto \u00abrete di servizi (service mesh)\u00bb.<\/p>\n<ul>\n<li> <b>Piani dati (Data planes)<\/b>: Linkerd, NGINX, HAProxy, Envoy, Traefik<\/li>\n<li><b>Piani di controllo (Control planes)<\/b>: Istio, Nelson, SmartStack <\/li>\n<\/ul>\n<p>\nInvece di condurre un'analisi approfondita di ciascuna delle soluzioni sopra elencate, mi fermer\u00f2 brevemente su alcuni punti che, secondo me, suscitano la maggior parte della confusione nell'ecosistema in questo momento.<\/p>\n<p>All'inizio del 2016, Linkerd era uno dei primi server proxy per il piano dati (data plane) per le reti di servizi (service mesh) e ha fatto un lavoro fantastico nel aumentare la consapevolezza e l'attenzione sul modello di progettazione \u00abrete di servizi\u00bb (service mesh). Circa sei mesi dopo, Envoy si un\u00ec a Linkerd (anche se lavorava in Lyft dalla fine del 2015). Linkerd ed Envoy sono i due progetti pi\u00f9 frequentemente menzionati quando si parla di reti di servizi (service mesh).<\/p>\n<p>Istio \u00e8 stato annunciato a maggio 2017. Gli obiettivi del progetto Istio sono molto simili a quelli di un piano di controllo (control plane) avanzato, mostrato su <b>nella figura 3<\/b>. Envoy per Istio \u00e8 il server proxy \u00abdi default\u00bb. Pertanto, Istio \u00e8 un piano di controllo (control plane) e Envoy \u00e8 un piano dati (data plane). In poco tempo, Istio ha suscitato molto interesse e altri piani dati (data plane) hanno iniziato a integrarsi come sostituti di Envoy (sia Linkerd che NGINX hanno dimostrato integrazione con Istio). Il fatto che in un piano di controllo (control plane) si possano utilizzare diversi piani dati (data plane) significa che il piano di controllo (control plane) e il piano dati (data plane) non sono necessariamente strettamente legati. Un API come l'API universale del piano dati (data plane) Envoy pu\u00f2 fungere da ponte tra le due parti del sistema.<\/p>\n<p>Nelson e SmartStack aiutano a illustrare ulteriormente la separazione tra piano di controllo (control plane) e piano dati (data plane). Nelson utilizza Envoy come suo proxy e costruisce un affidabile piano di controllo (control plane) per la rete di servizi (service mesh) basata su stack HashiCorp, cio\u00e8 Nomad, ecc. SmartStack \u00e8 probabilmente stato il primo di una nuova ondata di reti di servizi (service mesh). SmartStack forma un piano di controllo (control plane) attorno a HAProxy o NGINX, dimostrando la possibilit\u00e0 di disaccoppiare il piano di controllo (control plane) dalla rete di servizi (service mesh) e dal piano dati (data plane).<\/p>\n<p>L'architettura a microservizi con una rete di servizi (service mesh) sta attirando sempre pi\u00f9 attenzione (giustamente!), e sempre pi\u00f9 progetti e fornitori stanno iniziando a lavorare in questa direzione. Nei prossimi anni vedremo molte innovazioni sia nel piano dati (data plane) che nel piano di controllo (control plane), cos\u00ec come una continua mescolanza di diversi componenti. In definitiva, l'architettura a microservizi deve diventare pi\u00f9 trasparente e magica (?) per l'operatore.<br \/>\nSpero che sempre meno irritato.<\/p>\n<h1>Punti chiave (Key takeaways)<\/h1>\n<p><\/p>\n<ul>\n<li> La rete di servizi (service mesh) \u00e8 composta da due parti diverse: il piano dati (data plane) e il piano di controllo (control plane). Entrambi i componenti sono essenziali, e senza di essi il sistema non funzioner\u00e0.<\/li>\n<li>Tutti sono familiari con il piano di controllo (control plane), e in questo momento il piano di controllo (control plane) potresti essere tu! <\/li>\n<li>Tutti i piani dati (data plane) competono tra loro per funzionalit\u00e0, prestazioni, configurabilit\u00e0 ed espandibilit\u00e0. <\/li>\n<li> Tutti i piani di controllo (control plane) competono tra loro per funzionalit\u00e0, configurabilit\u00e0, espandibilit\u00e0 e facilit\u00e0 d'uso.<\/li>\n<li>Un piano di controllo (control plane) pu\u00f2 contenere le giuste astrazioni e API per consentire l'utilizzo di pi\u00f9 piani dati (data plane). <\/li>\n<\/ul>\n<p>Fonte: <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\/it\/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=\"it_IT\" \/>\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\/it\/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\udd47Rete di servizi, \u00abPiano dati\u00bb e \u00abPiani di controllo\u00bb (Service mesh data plane vs. control plane) | ProHoster","description":"Ciao, Habr!","canonical_url":"https:\/\/prohoster.info\/it\/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":"it_IT","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\/it\/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\/it\/wp-json\/wp\/v2\/posts\/37030","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/prohoster.info\/it\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/prohoster.info\/it\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/prohoster.info\/it\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/prohoster.info\/it\/wp-json\/wp\/v2\/comments?post=37030"}],"version-history":[{"count":1,"href":"https:\/\/prohoster.info\/it\/wp-json\/wp\/v2\/posts\/37030\/revisions"}],"predecessor-version":[{"id":158592,"href":"https:\/\/prohoster.info\/it\/wp-json\/wp\/v2\/posts\/37030\/revisions\/158592"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/prohoster.info\/it\/wp-json\/wp\/v2\/media\/27757"}],"wp:attachment":[{"href":"https:\/\/prohoster.info\/it\/wp-json\/wp\/v2\/media?parent=37030"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/prohoster.info\/it\/wp-json\/wp\/v2\/categories?post=37030"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/prohoster.info\/it\/wp-json\/wp\/v2\/tags?post=37030"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}