{"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 soluzione di service mesh leggera","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

Nel processo di transizione da un'applicazione monolitica a un'architettura a microservizi ci troviamo di fronte a nuove sfide.<\/p>\n

<\/p>\n

In un'applicazione monolitica di solito \u00e8 sufficiente identificare in quale parte del sistema si \u00e8 verificato un errore. Probabilmente, il problema \u00e8 nel codice stesso del monolite o nel database. Ma quando iniziamo a cercare problemi in un'architettura a microservizi, le cose non sono pi\u00f9 cos\u00ec ovvie. \u00c8 necessario risalire all'intero percorso del richiesto dall'inizio alla fine, isolandolo tra centinaia di microservizi. Inoltre, molti di essi hanno anche i propri archivi, nei quali possono sorgere errori logici, problemi di prestazioni e di tolleranza ai guasti.<\/p>\n

<\/p>\n

\"Netramesh<\/p>\n

<\/p>\n

Ho cercato a lungo uno strumento che aiutasse a risolvere tali problemi (ne ho parlato su Habr: 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 tracing 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 un approccio di raccolta delle informazioni sulle interazioni di rete, o, peggio ancora, se in parte del sistema funziona gi\u00e0 bene ma in altre no, perch\u00e9 non \u00e8 stato aggiunto ai vecchi servizi? Per determinare la causa radice esatta di un problema, \u00e8 necessario avere una visione completa di cosa sta accadendo nel sistema. \u00c8 particolarmente importante capire quali microservizi sono coinvolti nei principali percorsi critici per il business.<\/p>\n

<\/p>\n

Qui pu\u00f2 aiutarci l'approccio service mesh, che gestisce tutta la meccanica della raccolta delle informazioni di rete a un livello inferiore rispetto a quello in cui operano i servizi stessi. Questo approccio ci consente di intercettare tutto il traffico e di analizzarlo in tempo reale. Inoltre, le applicazioni non devono nemmeno essere a conoscenza di questo.<\/p>\n

<\/p>\n

Approccio service mesh<\/h1>\n

<\/p>\n

L'idea principale dell'approccio service mesh \u00e8 quella di aggiungere un ulteriore livello infrastrutturale sopra la rete, che ci permetter\u00e0 di gestire qualsiasi aspetto dell'interazione tra i servizi. La maggior parte delle implementazioni funziona nel seguente modo: a ogni microservizio viene aggiunto un contenitore sidecar aggiuntivo con un proxy trasparente, attraverso il quale passa tutto il traffico in entrata e in uscita del servizio. Ed \u00e8 proprio in questo punto che possiamo effettuare bilanciamenti client, applicare politiche di sicurezza, introdurre limiti sul numero di richieste e raccogliere informazioni importanti relative all'interazione 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, maggiore \u00e8 il cluster in cui opera un tale sistema, maggiore sar\u00e0 la richiesta di risorse per mantenere la nuova infrastruttura. In Avito, sfruttiamo i cluster Kubernetes, in cui si trovano migliaia di istanze di servizi (e il loro numero continua a crescere rapidamente). Nella configurazione attuale, Istio consuma circa 300 Mb di memoria RAM per ogni istanza di servizio. A causa del gran numero 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 funzioni ci servono al momento e abbiamo deciso che la ragione principale per cui abbiamo iniziato a implementare soluzioni simili era la possibilit\u00e0 di raccogliere in modo trasparente le informazioni di tracciamento da tutto il sistema. Inoltre, desideravamo avere controllo sulle interazioni tra i servizi e fare varie manipolazioni con le intestazioni trasmesse tra di essi. <\/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 service mesh leggera con capacit\u00e0 di scalabilit\u00e0 illimitata, indipendentemente dal numero di servizi nel sistema.<\/p>\n

<\/p>\n

Le principali aspettative della nuova soluzione erano un basso overhead di risorse e alte prestazioni. Tra le funzionalit\u00e0 desiderate, volevamo sin da subito la possibilit\u00e0 di inviare in modo trasparente i tracing span al nostro sistema Jaeger.<\/p>\n

<\/p>\n

Oggi, la maggior parte delle soluzioni cloud \u00e8 realizzata in Golang. E, naturalmente, ci sono delle buone ragioni per questo. Scrivere applicazioni di rete in Golang, che operano in modo asincrono con input-output e che si scalano secondo necessit\u00e0 sui core, \u00e8 comodo e abbastanza semplice. E, ci\u00f2 che \u00e8 molto importante, le prestazioni risultano adeguate per risolvere questo compito. Pertanto, abbiamo scelto anche noi Golang.<\/p>\n

<\/p>\n

Prestazioni<\/h1>\n

<\/p>\n

Ci siamo concentrati sui nostri sforzi per raggiungere prestazioni massime. Per una soluzione che viene distribuita accanto a ogni istanza del servizio, \u00e8 necessaria una bassa assunzione di memoria e tempo di CPU. E, naturalmente, il ritardo nella risposta deve essere anche molto ridotto.<\/p>\n

<\/p>\n

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

<\/p>\n

RAM<\/h2>\n

<\/p>\n

Netramesh consuma circa 10Mb senza traffico e 50Mb al massimo con un carico fino a 10000 RPS su un'istanza.<\/p>\n

<\/p>\n

Il proxy Istio envoy consuma sempre circa 300Mb nelle nostre aree clustering con migliaia di istanze. Questo non consente 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 al secondo sul sidecar. I valori a 3000 richieste al secondo in picco:<\/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 vedere 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 in Istio durante il proxying tramite envoy era fino a 5-10ms, il che \u00e8 abbastanza per i servizi pronti a rispondere in un millisecondo. Con Netramesh questo tempo \u00e8 diminuito a 0,5-2ms.<\/p>\n

<\/p>\n

Scalabilit\u00e0<\/h1>\n

<\/p>\n

La limitata quantit\u00e0 di risorse utilizzate da ogni proxy consente di posizionarlo vicino a ciascun servizio. Netramesh \u00e8 stato volutamente creato senza un componente di control plane per mantenere leggeri ciascun sidecar. Spesso, in soluzioni di service mesh, il control plane diffonde informazioni di service discovery in ogni sidecar. Insieme a queste si trasmettono anche informazioni sui timeout e sulle impostazioni di bilanciamento. Tutto ci\u00f2 rende possibile molte operazioni utili, ma, sfortunatamente, gonfia le dimensioni dei sidecar. <\/p>\n

<\/p>\n

Service discovery<\/h1>\n

<\/p>\n

\"Netramesh <\/p>\n

<\/p>\n

Netramesh non aggiunge ulteriori meccanismi per la service discovery. Tutto il traffico viene proxyato in modo trasparente attraverso il sidecar netra. <\/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 attraverso le quali avviene l'interazione tramite HTTP. Ad esempio, per l'interazione tra servizi e richieste esterne utilizziamo le porte 80, 8890, 8080. In questo 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 per le entit\u00e0 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. Questa connessione viene stabilita inizialmente con il netra-sidecar locale e tutti i pacchetti TCP arrivano inizialmente a netra. Successivamente, netra-sidecar stabilisce la connessione con il punto di destinazione originale. Il NAT sull'indirizzo IP del pod nel nodo rimane esattamente lo stesso come senza netra.<\/p>\n

<\/p>\n

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

<\/p>\n

Netramesh offre funzionalit\u00e0 necessarie per inviare tracing span riguardanti l'interazione HTTP. Netra-sidecar analizza il protocollo HTTP, misura i ritardi delle richieste ed estrae le informazioni necessarie dagli header HTTP. Alla fine, otteniamo tutti i trace all'interno di un'unica sistema Jaeger. Per una configurazione fine, \u00e8 possibile utilizzare anche variabili d'ambiente fornite dalla libreria ufficiale jaeger go library<\/a><\/noindex>. <\/p>\n

<\/p>\n

\"Netramesh<\/p>\n

<\/p>\n

\"Netramesh <\/p>\n

<\/p>\n

Ma c'\u00e8 un problema. Finch\u00e9 i servizi non generano e propagano un'intestazione uber speciale, non vedremo gli span di tracing connessi nel sistema. E questo \u00e8 ci\u00f2 di cui abbiamo bisogno per trovare rapidamente la causa dei problemi. Qui Netramesh ha di nuovo una soluzione. I proxy leggono gli header HTTP e, se non trovano l'uber trace id, lo generano. Netramesh memorizza anche informazioni su richieste in entrata e in uscita nel sidecar e le associa arricchendo le necessarie intestazioni delle richieste in uscita. Tutto ci\u00f2 che \u00e8 necessario fare nei servizi \u00e8 propagare solo un'intestazione X-Request-Id<\/code>, che pu\u00f2 essere configurata 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 il contesto sar\u00e0 conservato) e NETRA_TRACING_CONTEXT_CLEANUP_INTERVAL<\/code> (la frequenza di pulizia del contesto).<\/p>\n

<\/p>\n

\u00c8 anche possibile combinare diversi percorsi nel sistema contrassegnandoli con un apposito marcatore di sessione. Netra consente di impostare HTTP_HEADER_TAG_MAP<\/code> per trasformare le intestazioni HTTP nei corrispondenti tag tracing span. Questo pu\u00f2 essere particolarmente utile per i test. Dopo aver eseguito un test funzionale, \u00e8 possibile vedere quale parte del sistema \u00e8 stata interessata filtrando in base al relativo chiave di sessione.<\/p>\n

<\/p>\n

Identificazione 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 della fonte. Con la variabile d'ambiente NETRA_HTTP_X_SOURCE_HEADER_NAME<\/code> \u00e8 possibile specificare il nome dell'intestazione che verr\u00e0 impostato automaticamente. Utilizzando NETRA_HTTP_X_SOURCE_VALUE<\/code> \u00e8 possibile definire il valore in cui verr\u00e0 impostata l'intestazione X-Source per tutte le richieste in uscita. <\/p>\n

<\/p>\n

Questo consente di diffondere uniformemente questa utile intestazione a tutta la rete. Si pu\u00f2 quindi utilizzarla nei servizi e aggiungerla ai log e alle metriche.<\/p>\n

<\/p>\n

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

<\/p>\n

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

<\/p>\n

Inoltre, lo strumento offre un'interessante possibilit\u00e0: il routing probabilistico. Se si utilizza Netramesh esclusivamente per raccogliere tracing span, si possono risparmiare risorse in ambiente di produzione e attivare il routing probabilistico utilizzando le 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 sidecar di netra accetta una nuova connessione e utilizza SO_ORIGINAL_DST<\/code> l'opzione socket per ottenere il punto di destinazione originale. Successivamente, 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 tenta di analizzarla e tracciarla. Se l'analisi HTTP non ha successo, Netra effettua un fallback su TCP eproxy trasparentemente i byte.<\/p>\n

<\/p>\n

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

<\/p>\n

Dopo aver ricevuto una grande quantit\u00e0 di informazioni di tracing in Jaeger, si desidera ottenere un grafo completo delle interazioni nel sistema. Ma se il vostro sistema \u00e8 abbastanza carico e nel corso di un giorno si accumulano miliardi di span di tracing, aggregarli diventa un compito piuttosto complesso. Esiste un modo ufficiale per farlo: spark-dependencies<\/a><\/noindex>. Tuttavia, richieder\u00e0 ore per costruire il grafo completo e costringer\u00e0 a scaricare da Jaeger l'intero dataset degli ultimi giorni. <\/p>\n

<\/p>\n

Se utilizzate Elasticsearch per archiviare gli span di tracing, potete sfruttare una semplice utility in Golang<\/a><\/noindex>, che costruir\u00e0 un grafo simile in pochi minuti, utilizzando le caratteristiche e le potenzialit\u00e0 di Elasticsearch.<\/p>\n

<\/p>\n

\"Netramesh<\/p>\n

<\/p>\n

Come utilizzare Netramesh<\/h1>\n

<\/p>\n

Netra pu\u00f2 essere semplicemente aggiunto a qualsiasi servizio gestito da qualsiasi orchestration tool. Potete vedere un esempio qui<\/a><\/noindex>.<\/p>\n

<\/p>\n

Attualmente, Netra non ha la possibilit\u00e0 di implementare automaticamente un sidecar ai servizi, ma ci sono piani per la sua realizzazione. <\/p>\n

<\/p>\n

Futuro di Netramesh<\/h1>\n

<\/p>\n

L'obiettivo principale Netramesh<\/a><\/noindex> \u00e8 raggiungere costi minimi in termini di risorse e elevate prestazioni, 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 protocolli di livello applicativo oltre all'HTTP. Nei prossimi sviluppi sar\u00e0 disponibile la possibilit\u00e0 di routing L7.<\/p>\n

<\/p>\n

Utilizzate Netramesh se incontrate problemi simili e contattateci per domande e proposte.<\/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 una soluzione service mesh leggera | ProHoster","description":"Nel processo di transizione da un'applicazione monolitica a un'architettura a microservizi, ci troviamo di fronte a nuove sfide. In un'applicazione monolitica, di solito \u00e8 sufficiente determinare in quale parte del sistema \u00e8 avvenuto.","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}]}}