{"id":32777,"date":"2019-10-31T21:48:52","date_gmt":"2019-10-31T18:48:52","guid":{"rendered":"https:\/\/prohoster.info\/blog\/netramesh-legkovesnoe-service-mesh-reshenie\/"},"modified":"2019-10-31T21:48:52","modified_gmt":"2019-10-31T18:48:52","slug":"netramesh-legkovesnoe-service-mesh-reshenie","status":"publish","type":"post","link":"https:\/\/prohoster.info\/it\/blog\/administrirovanie\/netramesh-legkovesnoe-service-mesh-reshenie","title":{"rendered":"Netramesh \u2013 una soluzione service mesh leggera","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

Durante il passaggio da un'applicazione monolitica a un'architettura a microservizi, ci troviamo ad affrontare nuove sfide.<\/p>\n

<\/p>\n

In un'applicazione monolitica, \u00e8 solitamente sufficiente identificare in quale parte del sistema si \u00e8 verificato un errore. Molto probabilmente, il problema risiede nel codice del monolito stesso o nel database. Tuttavia, quando iniziamo a cercare un problema in un'architettura a microservizi, le cose non sono cos\u00ec evidenti. \u00c8 necessario rintracciare il percorso completo che ha seguito la richiesta dall'inizio alla fine, isolandola tra centinaia di microservizi. Inoltre, molti di questi hanno i propri archivi, nei quali possono sorgere errori logici, problemi di prestazioni e di resilienza.<\/p>\n

<\/p>\n

\"Netramesh<\/p>\n

<\/p>\n

Ho cercato a lungo uno strumento che potesse aiutarmi a risolvere tali problemi (ne ho parlato su Habrahabr: 1<\/a><\/noindex>, 2<\/a><\/noindex>), ma alla fine ho creato una mia soluzione open source. In questo articolo, parlo dei vantaggi dell'approccio service mesh e condivido un nuovo strumento per la sua implementazione. <\/p>\n

<\/a><\/noindex><\/p>\n

Il tracciamento distribuito \u00e8 una soluzione comune per il problema della ricerca di errori nei sistemi distribuiti. Ma cosa succede se in un sistema non \u00e8 ancora stato implementato questo approccio alla raccolta delle informazioni sulle interazioni di rete, o, cosa peggiore, se in parte del sistema funziona correttamente, mentre in un'altra parte no, perch\u00e9 non \u00e8 stato aggiunto ai vecchi servizi? Per determinare la causa radice esatta del problema, \u00e8 necessario avere un quadro completo di ci\u00f2 che accade nel sistema. \u00c8 particolarmente importante capire quali microservizi siano coinvolti nei percorsi critici per il business.<\/p>\n

<\/p>\n

Qui arriva in nostro soccorso l'approccio del service mesh, che si occupa di tutta la macchina per la raccolta delle informazioni di rete a un livello pi\u00f9 basso rispetto a quello in cui operano i servizi stessi. Questo approccio ci consente di intercettare tutto il traffico e di analizzarlo al volo. Inoltre, le applicazioni non devono nemmeno sapere nulla di esso.<\/p>\n

<\/p>\n

Approccio del service mesh<\/h1>\n

<\/p>\n

L'idea principale dell'approccio del service mesh \u00e8 l'aggiunta di un ulteriore strato infrastrutturale sopra la rete, che ci permetter\u00e0 di gestire in modo pi\u00f9 efficace l'interazione tra i servizi. La maggior parte delle implementazioni funziona aggiungendo a ciascun microservizio un container sidecar con un proxy trasparente, attraverso il quale viene instradato tutto il traffico in entrata e in uscita del servizio. \u00c8 proprio in questo punto che possiamo effettuare il bilanciamento del carico lato client, applicare politiche di sicurezza, imporre limiti sul numero di richieste e raccogliere informazioni importanti sul funzionamento dei servizi in produzione.<\/p>\n

<\/p>\n

\"Netramesh<\/p>\n

<\/p>\n

Soluzioni<\/h1>\n

<\/p>\n

Esistono gi\u00e0 diverse implementazioni di questo approccio: Istio<\/a><\/noindex> e linkerd2<\/a><\/noindex>. Offrono molte funzionalit\u00e0 pronte all'uso. Tuttavia, ci\u00f2 comporta anche un grande overhead sulle risorse. Inoltre, pi\u00f9 grande \u00e8 il cluster in cui opera tale sistema, maggiore sar\u00e0 la necessit\u00e0 di risorse per mantenere la nuova infrastruttura. In Avito utilizziamo cluster Kubernetes che ospitano migliaia di istanze di servizi (e il loro numero continua a crescere rapidamente). Nella nostra attuale implementazione, Istio consuma circa 300 MB di memoria operativa per ogni istanza del servizio. A causa della vasta gamma di funzionalit\u00e0, il bilanciamento trasparente influisce anche sul tempo di risposta totale dei servizi (fino a 10 ms).<\/p>\n

<\/p>\n

Di conseguenza, abbiamo esaminato quali funzionalit\u00e0 ci servissero immediatamente e abbiamo concluso che la principale motivazione per cui abbiamo avviato l'implementazione di tali soluzioni era la possibilit\u00e0 di raccogliere informazioni di tracing da tutto il sistema in modo trasparente. Volevamo anche avere il controllo sulle interazioni tra i servizi e eseguire diverse manipolazioni con gli header trasmessi tra i servizi. <\/p>\n

<\/p>\n

Alla fine, siamo giunti alla nostra soluzione:\u200a Netramesh<\/a><\/noindex>.<\/p>\n

<\/p>\n

Netramesh<\/h1>\n

<\/p>\n

Netramesh<\/a><\/noindex> \u2014 \u00e8 una soluzione di service mesh leggera con possibilit\u00e0 di scalabilit\u00e0 infinita indipendentemente dal numero di servizi nel sistema.<\/p>\n

<\/p>\n

Gli obiettivi principali della nuova soluzione erano un basso overhead delle risorse e alte prestazioni. Tra le funzionalit\u00e0 fondamentali volevamo poter inviare in modo trasparente le span di tracing al nostro sistema Jaeger.<\/p>\n

<\/p>\n

Oggi la maggior parte delle soluzioni cloud \u00e8 implementata in Golang. E ovviamente ci sono buone ragioni per questo. Scrivere applicazioni di rete in Golang, che lavorano in modo asincrono con input\/output e scalano automaticamente sulle CPU, \u00e8 comodo e relativamente semplice. E, cosa altrettanto importante, le prestazioni sono adeguate a questo compito. Pertanto, abbiamo anche scelto Golang.<\/p>\n

<\/p>\n

Prestazioni<\/h1>\n

<\/p>\n

Abbiamo concentrato i nostri sforzi per ottenere le massime prestazioni. Per una soluzione che viene distribuita accanto a ogni istanza di servizio, \u00e8 necessario un basso consumo di memoria e tempo di CPU. E, naturalmente, anche la latenza delle risposte deve essere ridotta al minimo.<\/p>\n

<\/p>\n

Diamo un'occhiata ai risultati ottenuti. <\/p>\n

<\/p>\n

RAM<\/h2>\n

<\/p>\n

Netramesh consuma ~10Mb senza traffico e fino a 50Mb con un carico massimo di 10000 RPS per singolo instance.<\/p>\n

<\/p>\n

Il proxy Istio envoy consuma sempre ~300Mb nei nostri cluster con migliaia di instance. Questo impedisce di scalare su tutto il cluster.<\/p>\n

<\/p>\n

\"Netramesh<\/p>\n

<\/p>\n

\"Netramesh<\/p>\n

<\/p>\n

Con Netramesh abbiamo ottenuto una riduzione del consumo di memoria di circa 10 volte.<\/p>\n

<\/p>\n

CPU<\/h2>\n

<\/p>\n

L'uso della CPU \u00e8 relativamente costante sotto carico. Dipende dal numero di richieste per unit\u00e0 di tempo inviate al sidecar. Valori durante picchi di 3000 richieste al secondo:<\/p>\n

<\/p>\n

\"Netramesh<\/p>\n

<\/p>\n

\"Netramesh <\/p>\n

<\/p>\n

C'\u00e8 un altro aspetto importante: Netramesh \u00e8 una soluzione senza control plane e senza carico non consuma tempo di CPU. Con Istio, i sidecar aggiornano sempre gli endpoint dei servizi. Di conseguenza, possiamo osservare questa situazione senza carico:<\/p>\n

<\/p>\n

\"Netramesh<\/p>\n

<\/p>\n

Utilizziamo HTTP\/1 per l'interazione tra i servizi. L'aumento del tempo di risposta di Istio durante il proxying tramite envoy \u00e8 stato fino a 5-10ms, il che \u00e8 piuttosto significativo per i servizi che sono pronti a rispondere in millisecondi. Con Netramesh questo tempo \u00e8 diminuito a 0.5-2ms.<\/p>\n

<\/p>\n

Scalabilit\u00e0<\/h1>\n

<\/p>\n

La piccola quantit\u00e0 di risorse utilizzate da ciascun proxy consente di collocarlo accanto a ogni servizio. Netramesh \u00e8 stato volutamente creato senza un componente di control plane per mantenere la leggerezza di ciascun sidecar. Spesso, nelle soluzioni di service mesh, il control plane distribuisce le informazioni di service discovery a ciascun sidecar. Con esse arrivano anche informazioni sui timeout e sulle configurazioni di bilanciamento. Tutto ci\u00f2 consente di realizzare molte cose utili, ma purtroppo appesantisce i sidecar. <\/p>\n

<\/p>\n

Service discovery<\/h1>\n

<\/p>\n

\"Netramesh <\/p>\n

<\/p>\n

Netramesh non aggiunge meccanismi aggiuntivi per la service discovery. Tutto il traffico \u00e8 instradato in modo trasparente attraverso il netra sidecar. <\/p>\n

<\/p>\n

Netramesh supporta il protocollo applicativo HTTP\/1. Per la sua definizione viene utilizzato un elenco di porte configurabile. Di solito, nel sistema ci sono diverse porte per l'interazione tramite HTTP. Ad esempio, utilizziamo le porte 80, 8890, 8080 per l'interazione tra servizi e richieste esterne. In tal caso, possono essere definite tramite una variabile d'ambiente. NETRA_HTTP_PORTS<\/code>.<\/p>\n

<\/p>\n

Se utilizzi Kubernetes come orchestratore e il suo meccanismo Service per l'interazione intra-cluster tra i servizi, il meccanismo rimane esattamente lo stesso. Inizialmente, il microservizio ottiene l'indirizzo IP del servizio tramite kube-dns e apre una nuova connessione ad esso. Questa connessione viene stabilita inizialmente con il netra-sidecar locale e tutti i pacchetti TCP arrivano inizialmente a netra. Successivamente, il netra-sidecar stabilisce la connessione con il punto di destinazione originale. NAT sull'IP del pod sul nodo rimane esattamente lo stesso di prima senza netra.<\/p>\n

<\/p>\n

Tracciamento distribuito e propagazione del contesto<\/h1>\n

<\/p>\n

Netramesh offre la funzionalit\u00e0 necessaria per inviare span di tracciamento sulle interazioni HTTP. Il netra-sidecar analizza il protocollo HTTP, misura i ritardi delle richieste e estrae le informazioni necessarie dagli header HTTP. Alla fine, otteniamo tutti i trace in un'unica sistema Jaeger. Per una configurazione fine, si possono anche utilizzare le variabili d'ambiente fornite dalla biblioteca ufficiale. jaeger go library<\/a><\/noindex>. <\/p>\n

<\/p>\n

\"Netramesh<\/p>\n

<\/p>\n

\"Netramesh <\/p>\n

<\/p>\n

C'\u00e8 un problema. Fintanto che i servizi non genereranno e inoltreranno un'intestazione uber speciale, non vedremo gli span di tracing connessi nel sistema. E questo \u00e8 ci\u00f2 di cui abbiamo bisogno per individuare rapidamente le cause dei problemi. Qui Netramesh ha di nuovo una soluzione. I proxy leggono le intestazioni HTTP e, se non contengono l'uber trace id, lo generano. Netramesh memorizza anche le informazioni sulle richieste in entrata e in uscita nel sidecar e le associa arricchendole con le intestazioni necessarie delle richieste in uscita. Tutto ci\u00f2 che \u00e8 necessario fare nei servizi \u00e8 inoltrare soltanto un'intestazione X-Request-Id<\/code>, che pu\u00f2 essere configurato tramite una variabile d'ambiente NETRA_HTTP_REQUEST_ID_HEADER_NAME<\/code>. Per gestire la dimensione del contesto in Netramesh, \u00e8 possibile impostare le seguenti variabili d'ambiente: NETRA_TRACING_CONTEXT_EXPIRATION_MILLISECONDS<\/code> (il tempo durante il quale verr\u00e0 memorizzato il contesto) e NETRA_TRACING_CONTEXT_CLEANUP_INTERVAL<\/code> (la frequenza di pulizia del contesto).<\/p>\n

<\/p>\n

\u00c8 anche possibile combinare pi\u00f9 percorsi nel proprio sistema contrassegnandoli con un marcatore di sessione speciale. Netra consente di impostare HTTP_HEADER_TAG_MAP<\/code> per trasformare le intestazioni HTTP in corrispondenti tag di tracing span. Questo pu\u00f2 essere particolarmente utile per i test. Dopo aver completato un test funzionale, \u00e8 possibile verificare quale parte del sistema \u00e8 stata coinvolta filtrando in base alla chiave di sessione corrispondente.<\/p>\n

<\/p>\n

Definizione della fonte della richiesta<\/h1>\n

<\/p>\n

Per determinare da dove proviene la richiesta, \u00e8 possibile utilizzare la funzionalit\u00e0 di aggiunta automatica dell'intestazione con la fonte. Utilizzando la variabile d'ambiente NETRA_HTTP_X_SOURCE_HEADER_NAME<\/code> \u00e8 possibile impostare il nome dell'intestazione che verr\u00e0 impostato automaticamente. Con NETRA_HTTP_X_SOURCE_VALUE<\/code> \u00e8 possibile specificare il valore da assegnare all'intestazione X-Source su tutte le richieste in uscita. <\/p>\n

<\/p>\n

Questo consente di diffondere in modo uniforme questo utile intestazione su tutta la rete. Successivamente, pu\u00f2 essere utilizzata nei servizi e aggiunta ai log, alle metriche.<\/p>\n

<\/p>\n

Routing del traffico e dettagli interni di Netramesh<\/h1>\n

<\/p>\n

Netramesh \u00e8 composto da due componenti principali. Il primo, netra-init, stabilisce le regole di rete per l'intercettazione del traffico. Utilizza regole di reindirizzamento iptables<\/a><\/noindex> per intercettare tutto o parte del traffico su sidecar, che \u00e8 il secondo componente principale di Netramesh. \u00c8 possibile configurare quali porte intercettare per le sessioni TCP in entrata e in uscita: INBOUND_INTERCEPT_PORTS, OUTBOUND_INTERCEPT_PORTS<\/code>.<\/p>\n

<\/p>\n

C'\u00e8 anche un'interessante funzionalit\u00e0 nello strumento: il routing probabilistico. Se si utilizza Netramesh esclusivamente per raccogliere tracing span, \u00e8 possibile risparmiare risorse in un ambiente di produzione attivando il routing probabilistico tramite variabili NETRA_INBOUND_PROBABILITY<\/code> e NETRA_OUTBOUND_PROBABILITY<\/code> (da 0 a 1). Il valore predefinito \u00e8 1 (viene intercettato tutto il traffico).<\/p>\n

<\/p>\n

Dopo un'intercettazione riuscita, il netra sidecar stabilisce una nuova connessione e utilizza SO_ORIGINAL_DST<\/code> l'opzione del socket per ottenere l'originale punto di destinazione. Quindi Netra apre una nuova connessione all'indirizzo IP originale e stabilisce una comunicazione TCP bidirezionale tra le parti, ascoltando tutto il traffico in transito. Se la porta \u00e8 definita come HTTP, Netra cerca di analizzarla e tracciarla. Se l'analisi HTTP fallisce, Netra effettua un fallback su TCP e proxy trasparentemente i byte.<\/p>\n

<\/p>\n

Costruzione del grafo delle dipendenze<\/h1>\n

<\/p>\n

Dopo aver ottenuto una grande quantit\u00e0 di informazioni di tracing in Jaeger, si desidera visualizzare il grafico completo delle interazioni nel sistema. Tuttavia, se il vostro sistema \u00e8 sufficientemente carico e si accumulano miliardi di tracing span in un giorno, aggregarli diventa una sfida non cos\u00ec semplice. Esiste un modo ufficiale per farlo: spark-dependencies<\/a><\/noindex>. Tuttavia, ci vorranno ore per costruire il grafico completo e costringer\u00e0 a scaricare da Jaeger l'intero dataset delle ultime 24 ore. <\/p>\n

<\/p>\n

Se utilizzate Elasticsearch per memorizzare i tracing span, potete avvalervi di una semplice utilit\u00e0 in Golang<\/a><\/noindex>, che costruir\u00e0 un grafico simile in pochi minuti, sfruttando le caratteristiche e le capacit\u00e0 di Elasticsearch.<\/p>\n

<\/p>\n

\"Netramesh<\/p>\n

<\/p>\n

Come utilizzare Netramesh<\/h1>\n

<\/p>\n

Netra pu\u00f2 essere facilmente aggiunto a qualsiasi servizio che opera sotto un qualsiasi orchestratore. \u00c8 possibile vedere un esempio qui<\/a><\/noindex>.<\/p>\n

<\/p>\n

Attualmente, Netra non ha la possibilit\u00e0 di implementare automaticamente il sidecar nei servizi, ma ci sono piani per farlo. <\/p>\n

<\/p>\n

Futuro di Netramesh<\/h1>\n

<\/p>\n

L'obiettivo principale Netramesh<\/a><\/noindex> \u00e8 raggiungere il minimo consumo di risorse e un'alta prestazione, fornendo funzionalit\u00e0 fondamentali per l'osservabilit\u00e0 e il controllo delle interazioni tra i servizi. <\/p>\n

<\/p>\n

In futuro, Netramesh supporter\u00e0 altri protocolli di livello applicativo oltre all'HTTP. Presto sar\u00e0 disponibile la possibilit\u00e0 di routing L7.<\/p>\n

<\/p>\n

Utilizza Netramesh se ti trovi di fronte a problemi simili e scrivici per domande e suggerimenti.<\/p>\n

Fonte: habr.com<\/a><\/p>","protected":false,"gt_translate_keys":[{"key":"rendered","format":"html"}]},"excerpt":{"rendered":"

\u0412 \u043f\u0440\u043e\u0446\u0435\u0441\u0441\u0435 \u043f\u0435\u0440\u0435\u0445\u043e\u0434\u0430 \u043e\u0442 \u043c\u043e\u043d\u043e\u043b\u0438\u0442\u043d\u043e\u0433\u043e \u043f\u0440\u0438\u043b\u043e\u0436\u0435\u043d\u0438\u044f \u043a \u043c\u0438\u043a\u0440\u043e\u0441\u0435\u0440\u0432\u0438\u0441\u043d\u043e\u0439 \u0430\u0440\u0445\u0438\u0442\u0435\u043a\u0442\u0443\u0440\u0435 \u043c\u044b \u0441\u0442\u0430\u043b\u043a\u0438\u0432\u0430\u0435\u043c\u0441\u044f \u0441 \u043d\u043e\u0432\u044b\u043c\u0438 \u043f\u0440\u043e\u0431\u043b\u0435\u043c\u0430\u043c\u0438. \u0412 \u043c\u043e\u043d\u043e\u043b\u0438\u0442\u043d\u043e\u043c \u043f\u0440\u0438\u043b\u043e\u0436\u0435\u043d\u0438\u0438 \u043e\u0431\u044b\u0447\u043d\u043e \u0434\u043e\u0441\u0442\u0430\u0442\u043e\u0447\u043d\u043e \u043f\u0440\u043e\u0441\u0442\u043e \u043e\u043f\u0440\u0435\u0434\u0435\u043b\u0438\u0442\u044c, \u0432 \u043a\u0430\u043a\u043e\u0439 \u0447\u0430\u0441\u0442\u0438 \u0441\u0438\u0441\u0442\u0435\u043c\u044b \u043f\u0440\u043e\u0438\u0437\u043e\u0448\u043b\u0430 \u043e\u0448\u0438\u0431\u043a\u0430. \u0421\u043a\u043e\u0440\u0435\u0435 \u0432\u0441\u0435\u0433\u043e, \u043f\u0440\u043e\u0431\u043b\u0435\u043c\u0430 \u0432 \u043a\u043e\u0434\u0435 \u0441\u0430\u043c\u043e\u0433\u043e \u043c\u043e\u043d\u043e\u043b\u0438\u0442\u0430, \u043b\u0438\u0431\u043e \u0432 \u0431\u0430\u0437\u0435 \u0434\u0430\u043d\u043d\u044b\u0445. \u041d\u043e \u043a\u043e\u0433\u0434\u0430 \u043c\u044b \u043d\u0430\u0447\u0438\u043d\u0430\u0435\u043c \u0438\u0441\u043a\u0430\u0442\u044c \u043f\u0440\u043e\u0431\u043b\u0435\u043c\u0443 \u0432 \u043c\u0438\u043a\u0440\u043e\u0441\u0435\u0440\u0432\u0438\u0441\u043d\u043e\u0439 \u0430\u0440\u0445\u0438\u0442\u0435\u043a\u0442\u0443\u0440\u0435, \u0432\u0441\u0451 \u0443\u0436\u0435 \u043d\u0435 \u0442\u0430\u043a \u043e\u0447\u0435\u0432\u0438\u0434\u043d\u043e. \u041d\u0443\u0436\u043d\u043e \u043d\u0430\u0439\u0442\u0438 \u0432\u0435\u0441\u044c […]<\/p>\n","protected":false,"gt_translate_keys":[{"key":"rendered","format":"html"}]},"author":1,"featured_media":24554,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[688],"tags":[],"class_list":["post-32777","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-administrirovanie"],"aioseo_notices":[],"aioseo_head":"\n\t\t\n\t\n\t\n\t\n\t\n\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\n","aioseo_head_json":{"title":"\ud83e\udd47Netramesh \u2013 soluzione lightweight di service mesh | ProHoster","description":"Durante il passaggio da un'applicazione monolitica a un'architettura a microservizi, ci troviamo ad affrontare nuove sfide. In un'applicazione monolitica, di solito \u00e8 sufficiente identificare quale parte del sistema ha subito modifiche.","canonical_url":"https:\/\/prohoster.info\/it\/blog\/administrirovanie\/netramesh-legkovesnoe-service-mesh-reshenie","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\udd47Netramesh \u2013 \u043b\u0435\u0433\u043a\u043e\u0432\u0435\u0441\u043d\u043e\u0435 service mesh \u0440\u0435\u0448\u0435\u043d\u0438\u0435 | ProHoster","og:description":"\u0412 \u043f\u0440\u043e\u0446\u0435\u0441\u0441\u0435 \u043f\u0435\u0440\u0435\u0445\u043e\u0434\u0430 \u043e\u0442 \u043c\u043e\u043d\u043e\u043b\u0438\u0442\u043d\u043e\u0433\u043e \u043f\u0440\u0438\u043b\u043e\u0436\u0435\u043d\u0438\u044f \u043a \u043c\u0438\u043a\u0440\u043e\u0441\u0435\u0440\u0432\u0438\u0441\u043d\u043e\u0439 \u0430\u0440\u0445\u0438\u0442\u0435\u043a\u0442\u0443\u0440\u0435 \u043c\u044b \u0441\u0442\u0430\u043b\u043a\u0438\u0432\u0430\u0435\u043c\u0441\u044f \u0441 \u043d\u043e\u0432\u044b\u043c\u0438 \u043f\u0440\u043e\u0431\u043b\u0435\u043c\u0430\u043c\u0438. \u0412 \u043c\u043e\u043d\u043e\u043b\u0438\u0442\u043d\u043e\u043c \u043f\u0440\u0438\u043b\u043e\u0436\u0435\u043d\u0438\u0438 \u043e\u0431\u044b\u0447\u043d\u043e \u0434\u043e\u0441\u0442\u0430\u0442\u043e\u0447\u043d\u043e \u043f\u0440\u043e\u0441\u0442\u043e \u043e\u043f\u0440\u0435\u0434\u0435\u043b\u0438\u0442\u044c, \u0432 \u043a\u0430\u043a\u043e\u0439 \u0447\u0430\u0441\u0442\u0438 \u0441\u0438\u0441\u0442\u0435\u043c\u044b \u043f\u0440\u043e\u0438\u0437\u043e\u0448\u043b\u0430.","og:url":"https:\/\/prohoster.info\/it\/blog\/administrirovanie\/netramesh-legkovesnoe-service-mesh-reshenie","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-31T18:48:52+00:00","article:modified_time":"2019-10-31T18:48:52+00:00","article:publisher":"https:\/\/www.facebook.com\/prohoster","article:author":"https:\/\/www.facebook.com\/prohoster"},"aioseo_meta_data":{"post_id":"32777","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-01-21 12:29:19","breadcrumb_settings":null,"limit_modified_date":false,"reviewed_by":null,"ai":null,"created":"2021-02-28 10:20:44","updated":"2026-01-21 12:29:19","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\/32777","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=32777"}],"version-history":[{"count":0,"href":"https:\/\/prohoster.info\/it\/wp-json\/wp\/v2\/posts\/32777\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/prohoster.info\/it\/wp-json\/wp\/v2\/media\/24554"}],"wp:attachment":[{"href":"https:\/\/prohoster.info\/it\/wp-json\/wp\/v2\/media?parent=32777"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/prohoster.info\/it\/wp-json\/wp\/v2\/categories?post=32777"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/prohoster.info\/it\/wp-json\/wp\/v2\/tags?post=32777"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}