{"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\/da\/blog\/administrirovanie\/netramesh-legkovesnoe-service-mesh-reshenie","title":{"rendered":"Netramesh \u2013 letv\u00e6gtigt service mesh l\u00f8sning","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

I overgangen fra en monolitisk applikation til en mikrotjenestearkitektur st\u00f8der vi p\u00e5 nye udfordringer.<\/p>\n

<\/p>\n

I en monolitisk applikation er det normalt tilstr\u00e6kkeligt blot at identificere, hvor i systemet fejlen opstod. Problemet ligger sandsynligvis i selve monolitens kode eller i databasen. Men n\u00e5r vi begynder at lede efter problemer i en mikrotjenestearkitektur, er det ikke s\u00e5 indlysende. Vi skal finde hele den vej, som foresp\u00f8rgslen har taget fra start til slut, og isolere den blandt hundreder af mikrotjenester. Mange af disse har ogs\u00e5 deres egne lagre, hvor der kan opst\u00e5 b\u00e5de logiske fejl samt problemer med ydeevne og fejltolerance.<\/p>\n

<\/p>\n

\"Netramesh<\/p>\n

<\/p>\n

Jeg har l\u00e6nge ledt efter et v\u00e6rkt\u00f8j, der kunne hj\u00e6lpe med at tackle s\u00e5danne problemer (jeg skrev om dette p\u00e5 Habr: 1<\/a><\/noindex>, 2<\/a><\/noindex>), men endte med at lave en egen open source-l\u00f8sning. I artiklen fort\u00e6ller jeg om fordelene ved service mesh-tilgangen og deler et nyt v\u00e6rkt\u00f8j til dets implementering. <\/p>\n

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

Distribueret tracing er en almindelig l\u00f8sning p\u00e5 problemet med at finde fejl i distribuerede systemer. Men hvad hvis et s\u00e5dant tilgang til indsamling af information om netv\u00e6rk interaktioner endnu ikke er implementeret i systemet, eller, hvad der er v\u00e6rre, i en del af systemet fungerer det allerede korrekt, mens det i en anden del ikke er tilf\u00f8jet, da det ikke er implementeret i de \u00e6ldre tjenester? For at bestemme den pr\u00e6cise rod\u00e5rsag til problemet er det n\u00f8dvendigt at have et klart billede af, hvad der sker i systemet. Det er is\u00e6r vigtigt at forst\u00e5, hvilke mikrotjenester der deltager i de prim\u00e6re forretningskritiske veje.<\/p>\n

<\/p>\n

Her kan service mesh-tilgangen komme os til hj\u00e6lp, som tager sig af hele maskineriet til indsamling af netv\u00e6rksinformation p\u00e5 et niveau, der er lavere end der, hvor selve tjenesterne opererer. Denne tilgang giver os mulighed for at interceptere al trafik og analysere den i realtid. Desuden beh\u00f8ver applikationerne slet ikke at vide noget om det.<\/p>\n

<\/p>\n

Service mesh-tilgangen<\/h1>\n

<\/p>\n

Den prim\u00e6re id\u00e9 bag service mesh-tilgangen er at tilf\u00f8je et ekstra infrastrukturlag over netv\u00e6rket, som g\u00f8r det muligt for os at udf\u00f8re forskellige opgaver med inter-service interaktion. De fleste implementeringer fungerer ved, at der tilf\u00f8jes en yderligere sidecar-container med en gennemsigtig proxy til hver mikrotjeneste, som al indg\u00e5ende og udg\u00e5ende trafik til tjenesten passerer igennem. Og det er her, vi kan udf\u00f8re klientbalancering, anvende sikkerhedspolitikker, s\u00e6tte begr\u00e6nsninger for antallet af foresp\u00f8rgsler og indsamle vigtig information om serviceinteraktioner i produktion.<\/p>\n

<\/p>\n

\"Netramesh<\/p>\n

<\/p>\n

L\u00f8sninger<\/h1>\n

<\/p>\n

Der er allerede flere implementeringer af denne tilgang: Istio<\/a><\/noindex> og linkerd2<\/a><\/noindex>. De tilbyder mange funktioner ud af boksen. Men samtidig med dette kommer der ogs\u00e5 en stor overhead p\u00e5 ressourcer. Jo st\u00f8rre klyngen er, hvor et s\u00e5dant system opererer, desto flere ressourcer kr\u00e6ves der for at opretholde den nye infrastruktur. Hos Avito udnytter vi Kubernetes-klynger, hvor der er tusindvis af tjenesteeksemplarer (og antallet forts\u00e6tter med at vokse hurtigt). I den nuv\u00e6rende implementering bruger Istio ~300Mb RAM pr. tjenesteeksemplar. P\u00e5 grund af det store antal funktioner p\u00e5virker den gennemsigtige balancering ogs\u00e5 den samlede svartid for tjenesterne (op til 10 ms).<\/p>\n

<\/p>\n

I sidste ende s\u00e5 vi p\u00e5, hvilke pr\u00e6cise muligheder vi har brug for lige nu, og besluttede, at hoved\u00e5rsagen til, at vi begyndte at implementere s\u00e5danne l\u00f8sninger, var muligheden for gennemsigtigt at indsamle tracing-information fra hele systemet. Vi \u00f8nskede ogs\u00e5 at have kontrol over serviceinteraktioner og udf\u00f8re forskellige manipulationer med de overskrifter, der sendes mellem tjenesterne. <\/p>\n

<\/p>\n

Som resultat kom vi frem til vores l\u00f8sning:\u200a Netramesh<\/a><\/noindex>.<\/p>\n

<\/p>\n

Netramesh<\/h1>\n

<\/p>\n

Netramesh<\/a><\/noindex> \u2014 en letv\u00e6gts service mesh-l\u00f8sning med mulighed for uendelig skalering, uanset antallet af tjenester i systemet.<\/p>\n

<\/p>\n

De prim\u00e6re m\u00e5l for den nye l\u00f8sning var lav overhead p\u00e5 ressourcer og h\u00f8j ydeevne. Af de grundl\u00e6ggende funktioner \u00f8nskede vi straks at have muligheden for gennemsigtigt at sende tracing spans til vores Jaeger-system.<\/p>\n

<\/p>\n

I dag implementeres de fleste cloud-l\u00f8sninger p\u00e5 Golang. Og selvf\u00f8lgelig er der gode grunde til det. At skrive netv\u00e6rksapplikationer i Golang, som arbejder asynkront med input-output og skalerer efter behov p\u00e5 kerner, er b\u00e5de praktisk og relativt enkelt. Og hvad der ogs\u00e5 er meget vigtigt, er, at ydeevnen er tilstr\u00e6kkelig til at l\u00f8se denne opgave. Derfor har vi ogs\u00e5 valgt Golang.<\/p>\n

<\/p>\n

Ydeevne<\/h1>\n

<\/p>\n

Vi har fokuseret vores bestr\u00e6belser p\u00e5 at opn\u00e5 maksimal ydeevne. For en l\u00f8sning, der implementeres t\u00e6t p\u00e5 hver tjenesteinstans, er det n\u00f8dvendigt med et lavt forbrug af RAM og processor-tid. Og selvf\u00f8lgelig b\u00f8r forsinkelsen i svaret ogs\u00e5 v\u00e6re minimal.<\/p>\n

<\/p>\n

Lad os se p\u00e5, hvilke resultater vi har opn\u00e5et. <\/p>\n

<\/p>\n

RAM<\/h2>\n

<\/p>\n

Netramesh bruger ~10Mb uden trafik og 50Mb maksimalt under belastning op til 10000 RPS p\u00e5 \u00e9n instans.<\/p>\n

<\/p>\n

Istio envoy proxy bruger altid ~300Mb i vores klynger med tusindvis af instanser. Dette g\u00f8r det umuligt at skalere det til hele klyngen.<\/p>\n

<\/p>\n

\"Netramesh<\/p>\n

<\/p>\n

\"Netramesh<\/p>\n

<\/p>\n

Med Netramesh har vi opn\u00e5et en reduktion i hukommelsesforbruget p\u00e5 ~10 gange.<\/p>\n

<\/p>\n

CPU<\/h2>\n

<\/p>\n

CPU-brugen er relativt ligeligt fordelt under belastning. Den afh\u00e6nger af antallet af foresp\u00f8rgsler pr. tidsenhed til sidecar. V\u00e6rdierne ved 3000 foresp\u00f8rgsler pr. sekund ved topniveau:<\/p>\n

<\/p>\n

\"Netramesh<\/p>\n

<\/p>\n

\"Netramesh <\/p>\n

<\/p>\n

Der er endnu en vigtig pointe: Netramesh er en l\u00f8sning uden kontrolplan, og uden belastning bruger den ikke processor-tid. I Istio opdaterer sidecar altid endpoint'erne for tjenesterne. Resultatet er, at vi kan se s\u00e5dan et billede uden belastning:<\/p>\n

<\/p>\n

\"Netramesh<\/p>\n

<\/p>\n

Vi bruger HTTP\/1 til interaktionen mellem tjenester. For\u00f8gelsen i svartid hos Istio ved proxyering gennem envoy var op til 5-10ms, hvilket er ret meget for tjenester, der er klar til at svare p\u00e5 millisekunder. Med Netramesh blev denne tid reduceret til 0.5-2ms.<\/p>\n

<\/p>\n

Skalering<\/h1>\n

<\/p>\n

Det lille antal ressourcer, som hver proxy bruger, giver mulighed for at placere den t\u00e6t p\u00e5 hver tjeneste. Netramesh blev bevidst designet uden komponenten kontrollplan for at opretholde letv\u00e6gten af hver sidecar. Ofte i service mesh-l\u00f8sninger spreder kontrolplanen information om serviceopdagelse til hver sidecar. Sammen med dette kommer ogs\u00e5 information om timeout og belastningsindstillinger. Alt dette muligg\u00f8r mange nyttige funktioner, men desv\u00e6rre opbl\u00e6ser det st\u00f8rrelsen p\u00e5 sidecars. <\/p>\n

<\/p>\n

Serviceopdagelse<\/h1>\n

<\/p>\n

\"Netramesh <\/p>\n

<\/p>\n

Netramesh tilf\u00f8jer ikke nogen ekstra mekanismer til serviceopdagelse. Al trafik proxieres transparent gennem netra sidecar. <\/p>\n

<\/p>\n

Netramesh underst\u00f8tter HTTP\/1 applikationsprotokollen. Til dens definition anvendes en konfigurerbar liste over porte. Normalt er der flere porte i systemet, som interagerer via HTTP. For eksempel bruger vi 80, 8890, 8080 til interaktion mellem tjenester og eksterne foresp\u00f8rgsler. I s\u00e5 fald kan de angives ved hj\u00e6lp af en milj\u00f8variabel. NETRA_HTTP_PORTS<\/code>.<\/p>\n

<\/p>\n

Hvis du bruger Kubernetes som orkestrator og dens Service-mekanismer til intern clusterinteraktion mellem tjenester, forbliver mekanismen lige s\u00e5dan. F\u00f8rst f\u00e5r mikrotjenesten en service IP-adresse via kube-dns og \u00e5bner en ny forbindelse til den. Denne forbindelse etableres f\u00f8rst med den lokale netra-sidecar og alle TCP-pakker kommer oprindeligt til netra. Derefter etablerer netra-sidecar forbindelsen til den oprindelige destinationspunkt. NAT p\u00e5 pod IP p\u00e5 noden forbliver pr\u00e6cis som uden netra.<\/p>\n

<\/p>\n

Distribueret tracing og kontekstgennemtr\u00e6k<\/h1>\n

<\/p>\n

Netramesh leverer funktionaliteten n\u00f8dvendig for at sende tracing spans om HTTP-interaktion. Netra-sidecar parser HTTP-protokollen, m\u00e5ler foresp\u00f8rgselsforsinkelser, henter n\u00f8dvendig information fra HTTP-headere. I sidste ende opn\u00e5r vi alle traces i et enhedligt Jaeger-system. For finjustering kan der ogs\u00e5 bruges milj\u00f8variabler, som den officielle biblioteksleverand\u00f8r giver. jaeger go library<\/a><\/noindex>. <\/p>\n

<\/p>\n

\"Netramesh<\/p>\n

<\/p>\n

\"Netramesh <\/p>\n

<\/p>\n

Men der er et problem. Indtil tjenesterne genererer og overf\u00f8rer en s\u00e6rlig uber-header, vil vi ikke se de sammenkoblede tracing spans i systemet. Og det er det, vi har brug for til hurtig fejlfinding. Her har Netramesh endnu en l\u00f8sning. Proxyer l\u00e6ser HTTP-headere, og hvis de ikke har uber trace id, genererer de det. Netramesh opbevarer ogs\u00e5 information om indg\u00e5ende og udg\u00e5ende foresp\u00f8rgsler i sidecar og matcher dem ved at berige de n\u00f8dvendige headere for udg\u00e5ende foresp\u00f8rgsler. Alt, hvad der skal g\u00f8res i tjenesterne, er at overf\u00f8re kun \u00e9n header. X-Request-Id<\/code>, som kan konfigureres med en milj\u00f8variabel. NETRA_HTTP_REQUEST_ID_HEADER_NAME<\/code>. For at styre st\u00f8rrelsen af konteksten i Netramesh kan du angive f\u00f8lgende milj\u00f8variabler: NETRA_TRACING_CONTEXT_EXPIRATION_MILLISECONDS<\/code> (tiden, i hvilken konteksten vil blive opbevaret) og NETRA_TRACING_CONTEXT_CLEANUP_INTERVAL<\/code> (hyppigheden af oprydning af konteksten).<\/p>\n

<\/p>\n

Det er ogs\u00e5 muligt at kombinere flere stier i dit system ved at m\u00e6rke dem med en s\u00e6rlig sessionsmarker. Netra g\u00f8r det muligt at oprette HTTP_HEADER_TAG_MAP<\/code> for at omdanne HTTP-overskrifter til de relevante tracing span-tags. Dette kan is\u00e6r v\u00e6re nyttigt ved testning. Efter at have gennemf\u00f8rt en funktionel test kan man se, hvilken del af systemet der blev ber\u00f8rt ved at filtrere efter den relevante sessionsn\u00f8gle.<\/p>\n

<\/p>\n

Bestemmelse af anmodningskilden<\/h1>\n

<\/p>\n

For at bestemme, hvor anmodningen kom fra, kan man bruge funktionen til automatisk at tilf\u00f8je en header med kilden. Ved hj\u00e6lp af milj\u00f8variablen NETRA_HTTP_X_SOURCE_HEADER_NAME<\/code> kan man angive navnet p\u00e5 headeren, der automatisk vil blive indstillet. Med NETRA_HTTP_X_SOURCE_VALUE<\/code> kan man angive v\u00e6rdien, som X-Source-headeren vil blive sat til p\u00e5 alle udg\u00e5ende anmodninger. <\/p>\n

<\/p>\n

Dette g\u00f8r det muligt at ensartet sprede denne nyttige header p\u00e5 tv\u00e6rs af netv\u00e6rket. Herefter kan den anvendes i tjenester og tilf\u00f8jes til logs og metrics.<\/p>\n

<\/p>\n

Routing af trafik og indre funktioner i Netramesh<\/h1>\n

<\/p>\n

Netramesh best\u00e5r af to hovedkomponenter. Den f\u00f8rste, netra-init, ops\u00e6tter netv\u00e6rksregler for at opsnappe trafik. Den anvender iptables redirect-regler<\/a><\/noindex> til at opsnappe al eller en del af trafikken til sidecar, som er den anden hovedkomponent i Netramesh. Det er muligt at konfigurere, hvilke specifikke porte der skal opsnappes for indg\u00e5ende og udg\u00e5ende TCP-sessioner: INBOUND_INTERCEPT_PORTS, OUTBOUND_INTERCEPT_PORTS<\/code>.<\/p>\n

<\/p>\n

Derudover har v\u00e6rkt\u00f8jet en interessant funktion \u2013 sandsynlighedsbaseret routing. Hvis Netramesh kun bruges til at indsamle tracing spans, kan man spare ressourcer i et production-milj\u00f8 ved at aktivere sandsynlighedsbaseret routing ved hj\u00e6lp af variablerne NETRA_INBOUND_PROBABILITY<\/code> og NETRA_OUTBOUND_PROBABILITY<\/code> (fra 0 til 1). Standardv\u00e6rdien er 1 (al trafik opsnappes).<\/p>\n

<\/p>\n

Efter en vellykket opsnapning accepterer netra sidecar en ny forbindelse og bruger SO_ORIGINAL_DST<\/code> socketmuligheden til at f\u00e5 den oprindelige destinationsadresse. Derefter \u00e5bner Netra en ny forbindelse til den oprindelige IP-adresse og etablerer en tovej TCP-kommunikation mellem parterne, mens den lytter til al den passerende trafik. Hvis porten er angivet som HTTP, fors\u00f8ger Netra at analysere den og trace det. Hvis HTTP-analyse mislykkes, falder Netra tilbage til TCP og proxyer bytes gennemsigtigt.<\/p>\n

<\/p>\n

Opbygning af afh\u00e6ngighedsgraf<\/h1>\n

<\/p>\n

Efter at have modtaget en stor m\u00e6ngde tracing-information i Jaeger, \u00f8nsker man at f\u00e5 det fulde interaktionsgraf i systemet. Men hvis dit system er tilstr\u00e6kkeligt belastet, og der opsamles milliarder af tracing spans p\u00e5 en dag, bliver aggregering af dem ikke s\u00e5 enkel. Der er en officiel metode til dette: spark-dependencies<\/a><\/noindex>. Alligevel vil det tage timer at opbygge det fulde graf og kr\u00e6ve, at du downloader hele datas\u00e6ttet fra Jaeger for de sidste 24 timer. <\/p>\n

<\/p>\n

Hvis du bruger Elasticsearch til at gemme tracing spans, kan du udnytte et simpelt v\u00e6rkt\u00f8j skrevet i Golang<\/a><\/noindex>, som kan opbygge et tilsvarende graf p\u00e5 f\u00e5 minutter ved at anvende funktionerne og mulighederne i Elasticsearch.<\/p>\n

<\/p>\n

\"Netramesh<\/p>\n

<\/p>\n

Hvordan man bruger Netramesh<\/h1>\n

<\/p>\n

Netra kan nemt tilf\u00f8jes til enhver tjeneste, der k\u00f8rer under en hvilken som helst orkestrator. Du kan se et eksempel her<\/a><\/noindex>.<\/p>\n

<\/p>\n

P\u00e5 nuv\u00e6rende tidspunkt har Netra ikke muligheden for automatisk at implementere en sidecar til tjenester, men der er planer om implementering. <\/p>\n

<\/p>\n

Fremtiden for Netramesh<\/h1>\n

<\/p>\n

Hovedm\u00e5let Netramesh<\/a><\/noindex> er at opn\u00e5 minimale ressourceomkostninger og h\u00f8j ydeevne, samtidig med at de grundl\u00e6ggende muligheder for observabilitet og kontrol af tjenesteinteraktioner tilbydes. <\/p>\n

<\/p>\n

I fremtiden vil Netramesh f\u00e5 st\u00f8tte til andre applikationslag-protokoller ud over HTTP. Snart vil muligheden for L7-routing v\u00e6re tilg\u00e6ngelig.<\/p>\n

<\/p>\n

Brug Netramesh, hvis du oplever lignende problemer, og send os sp\u00f8rgsm\u00e5l og forslag.<\/p>\n

Kilde: 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\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 en letv\u00e6gts service mesh-l\u00f8sning | ProHoster","description":"I processen med at skifte fra monolitisk applikation til mikrotjenestearkitektur st\u00f8der vi p\u00e5 nye problemer. I en monolitisk applikation er det normalt tilstr\u00e6kkeligt blot at fastsl\u00e5, hvilket omr\u00e5de af systemet der er p\u00e5virket.","canonical_url":"https:\/\/prohoster.info\/da\/blog\/administrirovanie\/netramesh-legkovesnoe-service-mesh-reshenie","robots":"max-image-preview:large","keywords":"","webmasterTools":{"miscellaneous":""},"schema":null,"og:locale":"da_DK","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\/da\/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\/da\/wp-json\/wp\/v2\/posts\/32777","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/prohoster.info\/da\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/prohoster.info\/da\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/prohoster.info\/da\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/prohoster.info\/da\/wp-json\/wp\/v2\/comments?post=32777"}],"version-history":[{"count":0,"href":"https:\/\/prohoster.info\/da\/wp-json\/wp\/v2\/posts\/32777\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/prohoster.info\/da\/wp-json\/wp\/v2\/media\/24554"}],"wp:attachment":[{"href":"https:\/\/prohoster.info\/da\/wp-json\/wp\/v2\/media?parent=32777"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/prohoster.info\/da\/wp-json\/wp\/v2\/categories?post=32777"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/prohoster.info\/da\/wp-json\/wp\/v2\/tags?post=32777"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}