{"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\/sv\/blog\/administrirovanie\/netramesh-legkovesnoe-service-mesh-reshenie","title":{"rendered":"Netramesh \u2013 en l\u00e4ttviktsl\u00f6sning f\u00f6r service mesh","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

Vid \u00f6verg\u00e5ngen fr\u00e5n en monolitisk applikation till en mikrotj\u00e4nstarkitektur st\u00f6ter vi p\u00e5 nya problem.<\/p>\n

<\/p>\n

I en monolitisk applikation \u00e4r det vanligtvis tillr\u00e4ckligt att helt enkelt fastst\u00e4lla var felet intr\u00e4ffade i systemet. Troligen ligger problemet i monolitens kod eller i databasen. Men n\u00e4r vi b\u00f6rjar s\u00f6ka efter problemet i mikrotj\u00e4nstarkitekturen \u00e4r det inte l\u00e4ngre s\u00e5 uppenbart. Vi m\u00e5ste hitta hela v\u00e4gen som en beg\u00e4ran har tagit fr\u00e5n b\u00f6rjan till slut och s\u00e4rskilja den fr\u00e5n hundratals mikrotj\u00e4nster. M\u00e5nga av dem har dessutom egna datalagringsl\u00f6sningar d\u00e4r det ocks\u00e5 kan uppst\u00e5 b\u00e5de logiska fel och problem med prestanda och tillf\u00f6rlitlighet.<\/p>\n

<\/p>\n

\"Netramesh<\/p>\n

<\/p>\n

Jag har l\u00e4nge letat efter ett verktyg som skulle hj\u00e4lpa till att hantera s\u00e5dana problem (jag skrev om detta p\u00e5 Habr\u00e9: 1<\/a><\/noindex>, 2<\/a><\/noindex>), men i slut\u00e4ndan gjorde jag en egen \u00f6ppen k\u00e4llkods-l\u00f6sning. I artikeln ber\u00e4ttar jag om f\u00f6rdelarna med service mesh-ansatsen och delar med mig av ett nytt verktyg f\u00f6r dess implementering. <\/p>\n

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

Distribuerad sp\u00e5rning \u00e4r en vanlig l\u00f6sning p\u00e5 problemet med att hitta fel i distribuerade system. Men vad h\u00e4nder om ett s\u00e5dant tillv\u00e4gag\u00e5ngss\u00e4tt f\u00f6r att samla in information om n\u00e4tverksinteraktioner \u00e4nnu inte har implementerats i systemet, eller, \u00e4nnu v\u00e4rre, om det fungerar bra i en del av systemet men inte i en annan, eftersom det inte har lagts till i de \u00e4ldre tj\u00e4nsterna? F\u00f6r att best\u00e4mma den exakta grundorsaken till problemet m\u00e5ste vi ha en fullst\u00e4ndig bild av vad som h\u00e4nder i systemet. Det \u00e4r s\u00e4rskilt viktigt att f\u00f6rst\u00e5 vilka mikrotj\u00e4nster som \u00e4r involverade i de mest kritiska aff\u00e4rsv\u00e4garna.<\/p>\n

<\/p>\n

H\u00e4r kan service mesh-ansatsen hj\u00e4lpa oss, som tar hand om hela maskineriet f\u00f6r att samla in n\u00e4tverksinformation p\u00e5 en niv\u00e5 under d\u00e4r sj\u00e4lva tj\u00e4nsterna arbetar. Denna ansats g\u00f6r att vi kan avlyssna all trafik och analysera den i realtid. Dessutom beh\u00f6ver sj\u00e4lva applikationerna inte ens veta n\u00e5got om det.<\/p>\n

<\/p>\n

Service mesh-ansatsen<\/h1>\n

<\/p>\n

Huvudid\u00e9n med service mesh-ansatsen \u00e4r att l\u00e4gga till \u00e4nnu ett infrastrukturlager ovanf\u00f6r n\u00e4tverket, vilket g\u00f6r att vi kan hantera interaktionen mellan mikrotj\u00e4nster. De flesta implementationer fungerar p\u00e5 f\u00f6ljande s\u00e4tt: varje mikrotj\u00e4nst f\u00e5r en extra sidecar-container med en transparent proxy, genom vilken all inkommande och utg\u00e5ende trafik fr\u00e5n tj\u00e4nsten passerar. Och det \u00e4r just h\u00e4r vi kan utf\u00f6ra klientsidebalansering, till\u00e4mpa s\u00e4kerhetspolicyer, inf\u00f6ra begr\u00e4nsningar p\u00e5 antalet f\u00f6rfr\u00e5gningar och samla in viktig information om hur tj\u00e4nster interagerar i produktion.<\/p>\n

<\/p>\n

\"Netramesh<\/p>\n

<\/p>\n

L\u00f6sningar<\/h1>\n

<\/p>\n

Det finns redan flera implementationer av detta tillv\u00e4gag\u00e5ngss\u00e4tt: Istio<\/a><\/noindex> och linkerd2<\/a><\/noindex>. De erbjuder m\u00e5nga funktioner direkt ur boxen. Men samtidigt kommer det med en stor overhead av resurser. Ju st\u00f6rre klustret d\u00e4r ett s\u00e5dant system k\u00f6rs, desto mer resurser kr\u00e4vs f\u00f6r att uppr\u00e4tth\u00e5lla den nya infrastrukturen. P\u00e5 Avito anv\u00e4nder vi Kubernetes-kluster d\u00e4r tusentals tj\u00e4nsteexemplar finns (och antalet forts\u00e4tter att v\u00e4xa snabbt). I den nuvarande implementationen anv\u00e4nder Istio cirka 300 Mb RAM per tj\u00e4nsteexemplar. P\u00e5 grund av det stora antalet funktioner p\u00e5verkar den transparenta balanseringen ocks\u00e5 den totala svarstiden f\u00f6r tj\u00e4nsterna (upp till 10 ms).<\/p>\n

<\/p>\n

Till slut tittade vi p\u00e5 vilka specifika funktioner vi beh\u00f6ver just nu och beslutade att en av de viktigaste anledningarna till att vi b\u00f6rjade implementera s\u00e5dana l\u00f6sningar var m\u00f6jligheten att transparent samla in sp\u00e5rningsinformation fr\u00e5n hela systemet. Vi ville ocks\u00e5 ha kontroll \u00f6ver tj\u00e4nsternas interaktioner och kunna g\u00f6ra olika manipulationer med de rubriker som skickas mellan tj\u00e4nster. <\/p>\n

<\/p>\n

Som ett resultat kom vi fram till v\u00e5r l\u00f6sning: Netramesh<\/a><\/noindex>.<\/p>\n

<\/p>\n

Netramesh<\/h1>\n

<\/p>\n

Netramesh<\/a><\/noindex> \u2014 en l\u00e4ttviktig service mesh-l\u00f6sning med m\u00f6jlighet till o\u00e4ndlig skalbarhet oavsett antal tj\u00e4nster i systemet.<\/p>\n

<\/p>\n

M\u00e5len med den nya l\u00f6sningen var att ha l\u00e5g resurs\u00f6verhead och h\u00f6g prestanda. Vi ville omedelbart ha m\u00f6jligheten att transparent skicka sp\u00e5rningsspaningar till v\u00e5rt Jaeger-system.<\/p>\n

<\/p>\n

Idag implementeras de flesta molnl\u00f6sningarna i Golang. Och det finns sj\u00e4lvklart sk\u00e4l till detta. Att skriva n\u00e4tverksapplikationer i Golang som arbetar asynkront med in- och utmatning och som kan skalas upp efter behov \u00e4r b\u00e5de bekv\u00e4mt och ganska enkelt. Dessutom \u00e4r prestandan tillr\u00e4cklig f\u00f6r att l\u00f6sa denna uppgift. D\u00e4rf\u00f6r valde vi ocks\u00e5 Golang.<\/p>\n

<\/p>\n

Performance<\/h1>\n

<\/p>\n

Vi har fokuserat v\u00e5ra anstr\u00e4ngningar p\u00e5 att uppn\u00e5 maximal prestanda. F\u00f6r en l\u00f6sning som implementeras n\u00e4ra varje tj\u00e4nsteinstans kr\u00e4vs en liten m\u00e4ngd minne och processortid. Sj\u00e4lvklart b\u00f6r \u00e4ven svarstiden vara s\u00e5 kort som m\u00f6jligt.<\/p>\n

<\/p>\n

L\u00e5t oss se vilka resultat vi har f\u00e5tt. <\/p>\n

<\/p>\n

RAM<\/h2>\n

<\/p>\n

Netramesh anv\u00e4nder ~10Mb utan trafik och 50Mb maximalt under belastning upp till 10000 RPS p\u00e5 en instans.<\/p>\n

<\/p>\n

Istio envoy proxy anv\u00e4nder alltid ~300Mb i v\u00e5ra kluster med tusentals instanser. Detta f\u00f6rhindrar att det kan skalas \u00f6ver hela klustret.<\/p>\n

<\/p>\n

\"Netramesh<\/p>\n

<\/p>\n

\"Netramesh<\/p>\n

<\/p>\n

Med Netramesh har vi f\u00e5tt en minskning av minnesanv\u00e4ndningen p\u00e5 ~10 g\u00e5nger.<\/p>\n

<\/p>\n

CPU<\/h2>\n

<\/p>\n

CPU-anv\u00e4ndningen f\u00f6rblir relativt konstant under belastning. Den beror p\u00e5 antalet f\u00f6rfr\u00e5gningar per tidsenhet till sidecar. V\u00e4rden vid 3000 f\u00f6rfr\u00e5gningar per sekund i topparna:<\/p>\n

<\/p>\n

\"Netramesh<\/p>\n

<\/p>\n

\"Netramesh <\/p>\n

<\/p>\n

Det finns en annan viktig punkt: Netramesh \u00e4r en l\u00f6sning utan control plane och utan belastning anv\u00e4nder den ingen processortid. Med Istio uppdaterar sidecars alltid tj\u00e4nsternas endpoints. Resultatet \u00e4r att vi kan se f\u00f6ljande situation utan belastning:<\/p>\n

<\/p>\n

\"Netramesh<\/p>\n

<\/p>\n

Vi anv\u00e4nder HTTP\/1 f\u00f6r interaktion mellan tj\u00e4nster. \u00d6kningen av svarstiden hos Istio vid proxying genom envoy var upp till 5-10ms, vilket \u00e4r ganska mycket f\u00f6r tj\u00e4nster som \u00e4r beredda att svara inom en millisekund. Med Netramesh minskade denna tid till 0,5-2ms.<\/p>\n

<\/p>\n

Skalbarhet<\/h1>\n

<\/p>\n

Den lilla m\u00e4ngd resurser som varje proxy anv\u00e4nder g\u00f6r det m\u00f6jligt att placera den n\u00e4ra varje tj\u00e4nst. Netramesh skapades medvetet utan en control plane-komponent f\u00f6r att enkelt uppr\u00e4tth\u00e5lla l\u00e4ttvikten av varje sidecar. Ofta i service mesh-l\u00f6sningar sprider control plane service discovery-information till varje sidecar. Med den kommer ocks\u00e5 information om timeouter och balansinst\u00e4llningar. Allt detta g\u00f6r det m\u00f6jligt att utf\u00f6ra m\u00e5nga anv\u00e4ndbara saker, men tyv\u00e4rr \u00f6kar det storleken p\u00e5 sidecars. <\/p>\n

<\/p>\n

Tj\u00e4nstuppt\u00e4ckning<\/h1>\n

<\/p>\n

\"Netramesh <\/p>\n

<\/p>\n

Netramesh l\u00e4gger inte till n\u00e5gra extra mekanismer f\u00f6r service discovery. All trafik proxyas transparent genom netra sidecar. <\/p>\n

<\/p>\n

Netramesh st\u00f6djer HTTP\/1 applikationsprotokollet. F\u00f6r att definiera det anv\u00e4nds en konfigurerbar lista \u00f6ver portar. Vanligtvis finns det flera portar i systemet som anv\u00e4nds f\u00f6r HTTP-interaktion. Till exempel anv\u00e4nder vi 80, 8890, 8080 f\u00f6r interaktion mellan tj\u00e4nster och externa f\u00f6rfr\u00e5gningar. I s\u00e5 fall kan de anges med hj\u00e4lp av en milj\u00f6variabel. NETRA_HTTP_PORTS<\/code>.<\/p>\n

<\/p>\n

Om du anv\u00e4nder Kubernetes som orkestrator och dess Service-mekanismer f\u00f6r interna klusterinteraktioner mellan tj\u00e4nster, f\u00f6rblir mekanismen densamma. F\u00f6rst f\u00e5r mikrotj\u00e4nsten service IP-adressen via kube-dns och \u00f6ppnar en ny anslutning till den. Denna anslutning etableras f\u00f6rst med den lokala netra-sidecaren och alla TCP-paket kommer f\u00f6rst till netra. D\u00e4refter etablerar netra-sidecaren anslutningen till den ursprungliga destinationen. NAT p\u00e5 pod IP p\u00e5 noden f\u00f6rblir densamma som utan netra.<\/p>\n

<\/p>\n

Distribuerad sp\u00e5rning och vidarebefordran av kontext<\/h1>\n

<\/p>\n

Netramesh tillhandah\u00e5ller funktionalitet som beh\u00f6vs f\u00f6r att skicka sp\u00e5rningsspann om HTTP-interaktion. Netra-sidecaren parsar HTTP-protokollet, m\u00e4ter f\u00f6rdr\u00f6jningar p\u00e5 f\u00f6rfr\u00e5gningar och h\u00e4mtar n\u00f6dv\u00e4ndig information fr\u00e5n HTTP-headers. I slut\u00e4ndan f\u00e5r vi alla sp\u00e5r i ett enhetligt Jaeger-system. F\u00f6r detaljerad konfiguration kan milj\u00f6variablerna som tillhandah\u00e5lls av det officiella biblioteket ocks\u00e5 anv\u00e4ndas. jaeger go library<\/a><\/noindex>. <\/p>\n

<\/p>\n

\"Netramesh<\/p>\n

<\/p>\n

\"Netramesh <\/p>\n

<\/p>\n

Men det finns ett problem. S\u00e5 l\u00e4nge tj\u00e4nsterna inte genererar och vidarebefordrar en s\u00e4rskild uber-header, kommer vi inte att se de sammanl\u00e4nkade sp\u00e5rningsspann i systemet. Och det \u00e4r vad vi beh\u00f6ver f\u00f6r att snabbt identifiera problemens orsaker. H\u00e4r har Netramesh \u00e5terigen en l\u00f6sning. Proxy l\u00e4ser HTTP-headers och, om de inte inneh\u00e5ller uber trace id, genererar den. Netramesh lagrar ocks\u00e5 information om inkommande och utg\u00e5ende f\u00f6rfr\u00e5gningar i sidecaren och matchar dem genom att berika dem med n\u00f6dv\u00e4ndiga headers f\u00f6r utg\u00e5ende f\u00f6rfr\u00e5gningar. Allt som beh\u00f6vs i tj\u00e4nsterna \u00e4r att vidarebefordra en enda header. X-Request-Id<\/code>, som kan konfigureras med hj\u00e4lp av en milj\u00f6variabel. NETRA_HTTP_REQUEST_ID_HEADER_NAME<\/code>. F\u00f6r att hantera storleken p\u00e5 kontexten i Netramesh kan f\u00f6ljande milj\u00f6variabler st\u00e4llas in: NETRA_TRACING_CONTEXT_EXPIRATION_MILLISECONDS<\/code> (tiden under vilken kontexten kommer att lagras) och NETRA_TRACING_CONTEXT_CLEANUP_INTERVAL<\/code> (frekvensen f\u00f6r st\u00e4dning av kontext).<\/p>\n

<\/p>\n

Det \u00e4r ocks\u00e5 m\u00f6jligt att kombinera flera v\u00e4gar i ditt system genom att m\u00e4rka dem med en speciell sessionsmark\u00f6r. Netra till\u00e5ter att st\u00e4lla in HTTP_HEADER_TAG_MAP<\/code> f\u00f6r att omvandla HTTP-rubriker till motsvarande tracing span-taggar. Detta kan vara s\u00e4rskilt anv\u00e4ndbart f\u00f6r testning. Efter att ha genomf\u00f6rt ett funktionellt test kan du se vilken del av systemet som p\u00e5verkades genom att filtrera med hj\u00e4lp av den aktuella sessionsnyckeln.<\/p>\n

<\/p>\n

Identifiering av f\u00f6rfr\u00e5gningsk\u00e4lla<\/h1>\n

<\/p>\n

F\u00f6r att avg\u00f6ra varifr\u00e5n f\u00f6rfr\u00e5gan kom kan funktionaliteten f\u00f6r automatisk till\u00e4ggning av rubrik med k\u00e4lla anv\u00e4ndas. Med hj\u00e4lp av milj\u00f6variabeln NETRA_HTTP_X_SOURCE_HEADER_NAME<\/code> kan du ange namnet p\u00e5 rubriken som automatiskt kommer att st\u00e4llas in. Med NETRA_HTTP_X_SOURCE_VALUE<\/code> kan du st\u00e4lla in v\u00e4rdet som X-Source-rubriken ska ha f\u00f6r alla utg\u00e5ende f\u00f6rfr\u00e5gningar. <\/p>\n

<\/p>\n

Detta g\u00f6r det m\u00f6jligt att enhetligt sprida denna anv\u00e4ndbara rubrik \u00f6ver hela n\u00e4tverket. Du kan sedan anv\u00e4nda den i tj\u00e4nster och l\u00e4gga till den i loggar och metrik.<\/p>\n

<\/p>\n

Ruttning av trafik och intern funktionalitet i Netramesh<\/h1>\n

<\/p>\n

Netramesh best\u00e5r av tv\u00e5 huvudkomponenter. Den f\u00f6rsta, netra-init, st\u00e4ller in n\u00e4tverksregler f\u00f6r att f\u00e5nga trafik. Den anv\u00e4nder iptables redirect-regler<\/a><\/noindex> f\u00f6r att f\u00e5nga all eller delar av trafiken till sidecar, som \u00e4r den andra huvudkomponenten i Netramesh. Du kan konfigurera vilka portar som ska f\u00e5ngas f\u00f6r inkommande och utg\u00e5ende TCP-sessioner: INBOUND_INTERCEPT_PORTS, OUTBOUND_INTERCEPT_PORTS<\/code>.<\/p>\n

<\/p>\n

Verktyget har ocks\u00e5 en intressant funktion \u2013 sannolikhetsbaserad ruttning. Om du anv\u00e4nder Netramesh enbart f\u00f6r att samla tracing spans kan du spara resurser i produktionsmilj\u00f6n och aktivera sannolikhetsbaserad ruttning med hj\u00e4lp av variablerna NETRA_INBOUND_PROBABILITY<\/code> och NETRA_OUTBOUND_PROBABILITY<\/code> (fr\u00e5n 0 till 1). Standardv\u00e4rdet \u00e4r 1 (all trafik f\u00e5ngas).<\/p>\n

<\/p>\n

Efter en lyckad f\u00e5ngst tar netra sidecar emot en ny anslutning och anv\u00e4nder SO_ORIGINAL_DST<\/code> socket-alternativet f\u00f6r att f\u00e5 den ursprungliga destinationspunkten. Sedan \u00f6ppnar Netra en ny anslutning till den ursprungliga IP-adressen och uppr\u00e4ttar en tv\u00e5v\u00e4gs TCP-kommunikation mellan parterna, och lyssnar p\u00e5 all passerande trafik. Om porten \u00e4r definierad som HTTP, f\u00f6rs\u00f6ker Netra att parsa den och sp\u00e5ra. Om HTTP-parsing inte \u00e4r framg\u00e5ngsrik, faller Netra tillbaka p\u00e5 TCP och transparent proxyar byte.<\/p>\n

<\/p>\n

Byggande av beroendegraf<\/h1>\n

<\/p>\n

Efter att ha f\u00e5tt en stor m\u00e4ngd tracinginformation i Jaeger vill man g\u00e4rna f\u00e5 en fullst\u00e4ndig graf \u00f6ver interaktionerna i systemet. Men om ditt system \u00e4r tillr\u00e4ckligt belastat och det samlas miljarder tracing spans under en dag, blir det inte s\u00e5 enkelt att aggreggera dem. Det finns ett officiellt s\u00e4tt att g\u00f6ra detta: spark-dependencies<\/a><\/noindex>. Det kommer dock att ta timmar att bygga en fullst\u00e4ndig graf och tvinga dig att ladda ner hela datasetet fr\u00e5n Jaeger f\u00f6r de senaste 24 timmarna. <\/p>\n

<\/p>\n

Om du anv\u00e4nder Elasticsearch f\u00f6r att lagra tracing spans kan du anv\u00e4nda en enkel nyttighet skriven i Golang<\/a><\/noindex>, som bygger en liknande graf p\u00e5 n\u00e5gra minuter, genom att anv\u00e4nda funktionerna och m\u00f6jligheterna i Elasticsearch.<\/p>\n

<\/p>\n

\"Netramesh<\/p>\n

<\/p>\n

Hur man anv\u00e4nder Netramesh<\/h1>\n

<\/p>\n

Netra kan enkelt l\u00e4ggas till i vilken tj\u00e4nst som helst som k\u00f6rs under n\u00e5gon orkestrat\u00f6r. Du kan se ett exempel ). Ett typiskt exempel p\u00e5 anv\u00e4ndning:<\/a><\/noindex>.<\/p>\n

<\/p>\n

F\u00f6r tillf\u00e4llet har Netra ingen m\u00f6jlighet till automatisk implementering av sidecar i tj\u00e4nster, men det finns planer p\u00e5 att genomf\u00f6ra detta. <\/p>\n

<\/p>\n

Framtiden f\u00f6r Netramesh<\/h1>\n

<\/p>\n

Huvudm\u00e5let Netramesh<\/a><\/noindex> \u00e4r att uppn\u00e5 minimala resurskostnader och h\u00f6g prestanda, samtidigt som man erbjuder grundl\u00e4ggande funktioner f\u00f6r observabilitet och kontroll \u00f6ver mellanserviceinteraktioner. <\/p>\n

<\/p>\n

I framtiden kommer Netramesh att f\u00e5 st\u00f6d f\u00f6r andra applikationsprotokoll ut\u00f6ver HTTP. Snart kommer m\u00f6jligheten f\u00f6r L7-routing att finnas.<\/p>\n

<\/p>\n

Anv\u00e4nd Netramesh om du st\u00f6ter p\u00e5 liknande problem, och skicka oss dina fr\u00e5gor och f\u00f6rslag.<\/p>\n

K\u00e4lla: 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 l\u00e4ttviktig service mesh-l\u00f6sning | ProHoster","description":"I processen med att \u00f6verg\u00e5 fr\u00e5n monolitiska applikationer till mikrotj\u00e4nstarkitektur st\u00f6ter vi p\u00e5 nya problem. I en monolitisk applikation r\u00e4cker det oftast med att bara definiera var i systemet det intr\u00e4ffade.","canonical_url":"https:\/\/prohoster.info\/sv\/blog\/administrirovanie\/netramesh-legkovesnoe-service-mesh-reshenie","robots":"max-image-preview:large","keywords":"","webmasterTools":{"miscellaneous":""},"schema":null,"og:locale":"sv_SE","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\/sv\/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\/sv\/wp-json\/wp\/v2\/posts\/32777","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/prohoster.info\/sv\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/prohoster.info\/sv\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/prohoster.info\/sv\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/prohoster.info\/sv\/wp-json\/wp\/v2\/comments?post=32777"}],"version-history":[{"count":0,"href":"https:\/\/prohoster.info\/sv\/wp-json\/wp\/v2\/posts\/32777\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/prohoster.info\/sv\/wp-json\/wp\/v2\/media\/24554"}],"wp:attachment":[{"href":"https:\/\/prohoster.info\/sv\/wp-json\/wp\/v2\/media?parent=32777"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/prohoster.info\/sv\/wp-json\/wp\/v2\/categories?post=32777"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/prohoster.info\/sv\/wp-json\/wp\/v2\/tags?post=32777"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}