{"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\/sl\/blog\/administrirovanie\/netramesh-legkovesnoe-service-mesh-reshenie","title":{"rendered":"Netramesh \u2013 lahka re\u0161itev za service mesh","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

Pri prehodu iz monolitne aplikacije na mikroservisno arhitekturo se soo\u010damo z novimi te\u017eavami.<\/p>\n

<\/p>\n

V monolitni aplikaciji je ponavadi dovolj enostavno dolo\u010diti, v katerem delu sistema je pri\u0161lo do napake. Verjetno je te\u017eava v samem kodeku monolita ali v podatkovni bazi. Toda ko za\u010dnemo iskati te\u017eave v mikroservisni arhitekturi, to ni ve\u010d tako o\u010ditno. Treba je najti celotno pot, ki jo je zahtevek pre\u0161el od za\u010detka do konca, jo lo\u010diti od stotin mikroservisov. \u0160e posebej, ker imajo \u0161tevilni od njih tudi lastne shrambe, kjer se lahko pojavijo tako logi\u010dne napake kot tudi te\u017eave z zmogljivostjo in odpornostjo na napake.<\/p>\n

<\/p>\n

\"Netramesh<\/p>\n

<\/p>\n

Dolg \u010dasa sem iskal orodje, ki bi mi pomagalo obvladovati take te\u017eave (o tem sem pisal na Habr: 1<\/a><\/noindex>, 2<\/a><\/noindex>), a na koncu sem ustvaril lastno odprtokodno re\u0161itev. V \u010dlanku opisujem prednosti pristopa service mesh in delim novo orodje za njegovo izvajanje. <\/p>\n

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

Distribuirano sledenje je raz\u0161irjena re\u0161itev te\u017eave iskanja napak v distribuiranih sistemih. Ampak kaj, \u010de v sistemu \u0161e ni uveden tak pristop zbiranja informacij o omre\u017enih interakcijah, ali, kar je \u0161e huje, del sistema ga \u017ee uspe\u0161no uporablja, v drugem delu pa ne, ker ni bil dodan starim storitvam? Za dolo\u010ditev natan\u010dnega koreninskega vzroka te\u017eave je nujno imeti celotno sliko tega, kar se dogaja v sistemu. Zelo pomembno je razumeti, kateri mikroservisi sodelujejo v glavnih poslovno kriti\u010dnih poteh.<\/p>\n

<\/p>\n

Sem nam lahko pomaga pristop service mesh, ki se bo ukvarjal z vso mehaniko zbiranja omre\u017enih informacij na ravni, ki je ni\u017eja od dela samih storitev. Ta pristop nam omogo\u010da zajemanje celotnega prometa in njegovo analizo v realnem \u010dasu. In aplikacije o tem pravzaprav ne smejo ni\u010desar vedeti.<\/p>\n

<\/p>\n

Pristop service mesh<\/h1>\n

<\/p>\n

Glavna ideja pristopa service mesh je dodajanje \u0161e enega infrastrukturnega sloja nad omre\u017ejem, ki nam omogo\u010da izvajanje razli\u010dnih nalog z medservisnim interakcijam. Ve\u010dina implementacij deluje na naslednji na\u010din: vsakemu mikroservisu se doda dodaten sidecar kontejner s prosojnim proxyjem, preko katerega poteka ves vhodni in izhodni promet storitve. In tu je to\u010dno mesto, kjer lahko izvajamo klientsko uravnote\u017eenje, uporabljamo varnostne politike, uvajamo omejitve glede \u0161tevila poizvedb in zbiramo pomembne informacije o interakcijah storitev v produkciji.<\/p>\n

<\/p>\n

\"Netramesh<\/p>\n

<\/p>\n

Re\u0161itve<\/h1>\n

<\/p>\n

Obstaja \u017ee ve\u010d implementacij tega pristopa: Istio<\/a><\/noindex> in linkerd2<\/a><\/noindex>. Ponuja \u0161tevilne mo\u017enosti \u017ee iz \u0161katle. A hkrati s tem pride tudi velika obremenitev virov. Bolj kot je klaster, v katerem deluje tak sistem, ve\u010d virov bo potrebno za vzdr\u017eevanje nove infrastrukture. Na Avitu uporabljamo Kubernetes klastre, ki vsebujejo tiso\u010de primerkov storitev (in njihovo \u0161tevilo se \u0161e naprej hitro pove\u010duje). V trenutni implementaciji Istio porabi ~300Mb delovne pomnilnika na vsak primer storitve. Zaradi velikega \u0161tevila mo\u017enosti prosojno uravnote\u017eenje vpliva tudi na skupni \u010das odziva storitev (do 10ms).<\/p>\n

<\/p>\n

Na koncu smo se osredoto\u010dili na to, katere mo\u017enosti potrebujemo prav zdaj, in se odlo\u010dili, da je glavni razlog, zaradi katerega smo za\u010deli uvajati tak\u0161ne re\u0161itve, bila sposobnost prozornega zbiranja tracing informacij iz celotnega sistema. Prav tako smo \u017eeleli imeti nadzor nad interakcijami storitev in izvajati razli\u010dne manipulacije z glavo, ki se prena\u0161ajo med storitvami. <\/p>\n

<\/p>\n

Na koncu smo pri\u0161li do svoje re\u0161itve:\u200a Netramesh<\/a><\/noindex>.<\/p>\n

<\/p>\n

Netramesh<\/h1>\n

<\/p>\n

Netramesh<\/a><\/noindex> \u2014 to je lahka re\u0161itev service mesh z mo\u017enostjo neskon\u010dnega skaliranja ne glede na \u0161tevilo storitev v sistemu.<\/p>\n

<\/p>\n

Glavni cilji nove re\u0161itve so bili majhna obremenitev virov in visoka zmogljivost. Med glavnimi mo\u017enostmi smo \u017ee \u017eeleli imeti sposobnost prosojnega po\u0161iljanja tracing span'ov v na\u0161 sistem Jaeger.<\/p>\n

<\/p>\n

Danes ve\u010dina obla\u010dnih re\u0161itev temelji na Golangu. In seveda so za to razlogi. Pisanje omre\u017enih aplikacij v Golangu, ki delujejo asinhrono z vhodom-izhodom in se po potrebi raz\u0161irjajo na jedra, je priro\u010dno in dovolj preprosto. In kar je prav tako zelo pomembno, je, da je zmogljivost zadostna za re\u0161evanje te naloge. Zato smo tudi mi izbrali Golang.<\/p>\n

<\/p>\n

Performansa<\/h1>\n

<\/p>\n

Osredoto\u010dili smo svoje napore na dosego najve\u010dje zmogljivosti. Za re\u0161itev, ki se name\u0161\u010da poleg vsake instance storitve, sta potrebna majhna poraba pomnilnika in procesorskega \u010dasa. In seveda, zakasnitev pri odgovoru mora biti prav tako majhna.<\/p>\n

<\/p>\n

Poglejmo, kak\u0161ni so rezultati. <\/p>\n

<\/p>\n

RAM<\/h2>\n

<\/p>\n

Netramesh porabi ~10Mb brez prometa in 50Mb maksimalno pod obremenitvijo do 10000 RPS na eno instanco.<\/p>\n

<\/p>\n

Istio envoy proxy vedno porabi ~300Mb v na\u0161ih grozdi z ve\u010d tiso\u010d instancami. To onemogo\u010da njegovo \u0161iritev na celoten grozd.<\/p>\n

<\/p>\n

\"Netramesh<\/p>\n

<\/p>\n

\"Netramesh<\/p>\n

<\/p>\n

S Netramesh smo dosegli zmanj\u0161anje porabe pomnilnika za ~10-krat.<\/p>\n

<\/p>\n

CPU<\/h2>\n

<\/p>\n

Uporaba CPU je relativno enaka pod obremenitvijo. Odvisna je od \u0161tevila zahtevkov na enoto \u010dasa do sidecar. Vrednosti pri 3000 zahtevkih na sekundo v vrhuncu:<\/p>\n

<\/p>\n

\"Netramesh<\/p>\n

<\/p>\n

\"Netramesh <\/p>\n

<\/p>\n

Obstaja \u0161e en pomemben vidik: Netramesh je re\u0161itev brez kontrolne plo\u0161\u010de in brez obremenitve ne porabi procesorskega \u010dasa. Pri Istio sidecarji vedno osve\u017eujejo kon\u010dne to\u010dke storitev. Na koncu vidimo tak\u0161no sliko brez obremenitve:<\/p>\n

<\/p>\n

\"Netramesh<\/p>\n

<\/p>\n

Uporabljamo HTTP\/1 za interakcijo med storitvami. Pove\u010danje \u010dasa odgovora pri Istio med posredovanjem preko envoy je bilo do 5-10ms, kar je precej veliko za storitve, ki so pripravljene odgovoriti v milisekundi. S Netramesh se je ta \u010das zmanj\u0161al na 0.5-2ms.<\/p>\n

<\/p>\n

\u0160irljivost<\/h1>\n

<\/p>\n

Majhna koli\u010dina virov, ki jih porabi vsak proxy, omogo\u010da njegovo postavitev poleg vsake storitve. Netramesh je bil namenoma ustvarjen brez komponenta kontrolne plo\u0161\u010de za enostavno vzdr\u017eevanje lahkotnosti vsakega sidecarja. Pogosto pri re\u0161itvah service mesh kontrolna plo\u0161\u010da \u0161iri informacije o odkrivanju storitev v vsak sidecar. Skupaj z njimi prihajajo tudi informacije o \u010dasovnih omejitvah in nastavitvah uravnote\u017eenja. Vse to omogo\u010da veliko koristnih stvari, a \u017eal pove\u010duje velikost sidecarjev. <\/p>\n

<\/p>\n

Service discovery<\/h1>\n

<\/p>\n

\"Netramesh <\/p>\n

<\/p>\n

Netramesh ne dodaja nobenih dodatnih mehanizmov za odkrivanje storitev. Vsi tokovi se prosto proxyujejo preko netra sidecar. <\/p>\n

<\/p>\n

Netramesh podpira HTTP\/1 aplikacijski protokol. Za njegovo dolo\u010ditev se uporablja konfigurabilni seznam vrat. Obi\u010dajno ima sistem ve\u010d vrat, preko katerih poteka interakcija po HTTP. Na primer, za interakcijo storitev in zunanjih poizvedb uporabljamo 80, 8890, 8080. V tem primeru jih lahko dolo\u010dimo s pomo\u010djo okoljske spremenljivke. NETRA_HTTP_PORTS<\/code>.<\/p>\n

<\/p>\n

\u010ce uporabljate Kubernetes kot orkestrator in njegov mehanizem Service za notranje delovanje med storitvami, ostaja mehanizem tak\u0161en kot prej. Najprej mikroservis pridobi service IP naslov preko kube-dns in odpre novo povezavo nanj. Ta povezava se najprej vzpostavi z lokalnim netra-sidecarjem in vsi TCP paketi sprva priletijo prav v netra. Potem netra-sidecar vzpostavi povezavo z izvorno destinacijo. NAT na pod IP na nodu ostaja prav tak kot brez netra.<\/p>\n

<\/p>\n

Porazdeljeno sledenje in prenos konteksta<\/h1>\n

<\/p>\n

Netramesh zagotavlja funkcionalnost, potrebno za po\u0161iljanje tracing spanov o HTTP interakciji. Netra-sidecar obdeluje HTTP protokol, meri zakasnitve poizvedb, pridobi potrebne informacije iz HTTP glave. Na koncu dobimo vse trace v enotni sistem Jaeger. Za fino konfiguracijo lahko uporabite tudi okoljske spremenljivke, ki jih ponuja uradna knji\u017enica. jaeger go library<\/a><\/noindex>. <\/p>\n

<\/p>\n

\"Netramesh<\/p>\n

<\/p>\n

\"Netramesh <\/p>\n

<\/p>\n

Ampak obstaja te\u017eava. Dokler storitve ne bodo generirale in prena\u0161ale posebne uber glave, ne bomo videli povezanih tracing spanov v sistemu. In to je tisto, kar potrebujemo za hitro iskanje vzrokov te\u017eav. Tukaj ima Netramesh spet re\u0161itev. Proxyji berejo HTTP glave in, \u010de v njih ni uber trace id, ga generirajo. Netramesh prav tako shranjuje informacije o prihajajo\u010dih in odhajajo\u010dih poizvedbah v sidecarju in jih povezuje z obogatitvijo z potrebnimi glavami odhajajo\u010dih poizvedb. Vse, kar morajo storitve storiti, je prena\u0161ati eno samo glavo. X-Request-Id<\/code>, ki jo lahko konfigurirate s pomo\u010djo okoljske spremenljivke. NETRA_HTTP_REQUEST_ID_HEADER_NAME<\/code>. Za nadzor velikosti konteksta v Netramesh lahko dolo\u010dite naslednje okoljske spremenljivke: NETRA_TRACING_CONTEXT_EXPIRATION_MILLISECONDS<\/code> (\u010das, v katerem bo kontekst shranjen) in NETRA_TRACING_CONTEXT_CLEANUP_INTERVAL<\/code> (periodi\u010dnost \u010di\u0161\u010denja konteksta).<\/p>\n

<\/p>\n

Mo\u017eno je kombinova\u0165 viacero ciest vo va\u0161om syst\u00e9me ozna\u010den\u00edm \u0161peci\u00e1lnym seden\u00edm. Netra umo\u017e\u0148uje nastavi\u0165 HTTP_HEADER_TAG_MAP<\/code> na transform\u00e1ciu HTTP hlavi\u010diek na pr\u00edslu\u0161n\u00e9 tracing span tagy. To m\u00f4\u017ee by\u0165 obzvl\u00e1\u0161\u0165 u\u017eito\u010dn\u00e9 pri testovan\u00ed. Po \u00faspe\u0161nom funk\u010dnom teste, je mo\u017en\u00e9 skontrolova\u0165, ktor\u00e1 \u010das\u0165 syst\u00e9mu bola ovplyvnen\u00e1, filtrovan\u00edm pod\u013ea pr\u00edslu\u0161n\u00e9ho session k\u013e\u00fa\u010da.<\/p>\n

<\/p>\n

Ur\u010denie zdroja po\u017eiadavky<\/h1>\n

<\/p>\n

Na ur\u010denie toho, odkia\u013e po\u017eiadavka poch\u00e1dza, je mo\u017en\u00e9 vyu\u017ei\u0165 funkciu automatick\u00e9ho prid\u00e1vania hlavi\u010dky so zdrojom. Pomocou premennej prostredia NETRA_HTTP_X_SOURCE_HEADER_NAME<\/code> je mo\u017en\u00e9 nastavi\u0165 n\u00e1zov hlavi\u010dky, ktor\u00fd bude automaticky prid\u00e1van\u00fd. Pomocou NETRA_HTTP_X_SOURCE_VALUE<\/code> je mo\u017en\u00e9 nastavi\u0165 hodnotu, ktorou sa X-Source hlavi\u010dka nastav\u00ed na v\u0161etky odch\u00e1dzaj\u00face po\u017eiadavky. <\/p>\n

<\/p>\n

To umo\u017e\u0148uje jednotn\u00e9 \u0161\u00edrenie tejto u\u017eito\u010dnej hlavi\u010dky v celej sieti. \u010ealej ju je mo\u017en\u00e9 vyu\u017e\u00edva\u0165 v slu\u017eb\u00e1ch a prid\u00e1va\u0165 do logov, metrik.<\/p>\n

<\/p>\n

Routing traffic and internals of Netramesh<\/h1>\n

<\/p>\n

Netramesh pozost\u00e1va z dvoch hlavn\u00fdch komponentov. Prv\u00fd, netra-init, nastavuje sie\u0165ov\u00e9 pravidl\u00e1 na zachytenie prev\u00e1dzky. Vyu\u017e\u00edva iptables redirect pravidl\u00e1<\/a><\/noindex> na zachytenie celej alebo \u010dasti prev\u00e1dzky na sidecar, ktor\u00fd je druh\u00fdm hlavn\u00fdm komponentom Netramesh. Je mo\u017en\u00e9 nastavi\u0165, ktor\u00e9 porty treba zachyt\u00e1va\u0165 pre prich\u00e1dzaj\u00face a odch\u00e1dzaj\u00face TCP rel\u00e1cie: INBOUND_INTERCEPT_PORTS, OUTBOUND_INTERCEPT_PORTS<\/code>.<\/p>\n

<\/p>\n

N\u00e1stroj tie\u017e pon\u00faka zauj\u00edmav\u00fa funkciu \u2014 pravdepodobnostn\u00e9 smerovanie. Ak sa pou\u017e\u00edva Netramesh v\u00fdhradne na zbieranie tracing span'ov, v produk\u010dnom prostred\u00ed je mo\u017en\u00e9 u\u0161etri\u0165 prostriedky a zapn\u00fa\u0165 pravdepodobnostn\u00e9 smerovanie pomocou premenn\u00fdch NETRA_INBOUND_PROBABILITY<\/code> in NETRA_OUTBOUND_PROBABILITY<\/code> (od 0 do 1). Predvolen\u00e1 hodnota je 1 (zachyt\u00e1va sa cel\u00e1 prev\u00e1dzka).<\/p>\n

<\/p>\n

Po \u00faspe\u0161nom zachyten\u00ed netra sidecar nadob\u00fada nov\u00e9 pripojenie a vyu\u017e\u00edva SO_ORIGINAL_DST<\/code> mo\u017enos\u0165 socketu na z\u00edskanie p\u00f4vodn\u00e9ho cie\u013ea. Potom Netra otv\u00e1ra nov\u00e9 pripojenie k p\u00f4vodnej IP adrese a nastavuje obojsmern\u00fa TCP komunik\u00e1ciu medzi stranami, sleduj\u00fac cel\u00fa prech\u00e1dzaj\u00facu prem\u00e1vku. Ak je port definovan\u00fd ako HTTP, Netra sa pok\u00fa\u0161a o parsovanie a traceovanie. Ak sa parsovanie HTTP nezadar\u00ed, Netra prech\u00e1dza na TCP a transparentne proxyuje bajty.<\/p>\n

<\/p>\n

Izgradnja grafa zavisnosti<\/h1>\n

<\/p>\n

Nakon \u0161to dobijete veliku koli\u010dinu tracing informacija u Jaeger-u, \u017eelite dobiti potpuni graf interakcija u sistemu. Me\u0111utim, ako je va\u0161 sistem dovoljno optere\u0107en i tokom dana se akumuliraju milijarde tracing span-ova, njihova agregacija postaje prili\u010dno slo\u017eena stvar. Postoji zvani\u010dni na\u010din za to: spark-dependencies<\/a><\/noindex>. Ipak, to \u0107e trajati sate da se izgradi potpuni graf i zahteva\u0107e preuzimanje celog dataset-a iz Jaeger-a za prethodnih 24 sata. <\/p>\n

<\/p>\n

Ako koristite Elasticsearch za skladi\u0161tenje tracing span-ova, mo\u017eete se poslu\u017eiti jednostavnom alatkom napisanom u Golang-u<\/a><\/noindex>, koja \u0107e izgraditi sli\u010dan graf za par minuta, koriste\u0107i posebnosti i mogu\u0107nosti Elasticsearch-a.<\/p>\n

<\/p>\n

\"Netramesh<\/p>\n

<\/p>\n

Kako koristiti Netramesh<\/h1>\n

<\/p>\n

Netra se mo\u017ee jednostavno dodati bilo kojoj usluzi koja radi pod upravljanjem bilo kojeg orkestratora. Mo\u017eete pogledati primer tukaj<\/a><\/noindex>.<\/p>\n

<\/p>\n

Trenutno Netra nema mogu\u0107nost automatskog uvo\u0111enja sidecar-a u usluge, ali postoje planovi za implementaciju. <\/p>\n

<\/p>\n

Buduc\u0301nost Netramesh-a<\/h1>\n

<\/p>\n

Glavni cilj Netramesh<\/a><\/noindex> je postizanje minimalnih tro\u0161kova resursa i visoke performanse, pru\u017eaju\u0107i osnovne mogu\u0107nosti za observability i kontrolu me\u0111uservisne interakcije. <\/p>\n

<\/p>\n

U budu\u0107nosti Netramesh \u0107e dobiti podr\u0161ku za druge protokole aplikacionog nivoa osim HTTP-a. U skoroj budu\u0107nosti bi\u0107e dostupna mogu\u0107nost L7 rutiranja.<\/p>\n

<\/p>\n

Koristite Netramesh ako se suo\u010davate sa sli\u010dnim problemima i pi\u0161ite nam pitanja i predloge.<\/p>\n

Izvor: 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 lagano service mesh re\u0161enje | ProHoster","description":"Tokom prelaska sa monolitne aplikacije na mikroservisnu arhitekturu, susre\u0107emo se sa novim problemima. U monolitnoj aplikaciji obi\u010dno je dovoljno samo odrediti u kojem delu sistema je do\u0161lo do","canonical_url":"https:\/\/prohoster.info\/sl\/blog\/administrirovanie\/netramesh-legkovesnoe-service-mesh-reshenie","robots":"max-image-preview:large","keywords":"","webmasterTools":{"miscellaneous":""},"schema":null,"og:locale":"sl_SI","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\/sl\/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\/sl\/wp-json\/wp\/v2\/posts\/32777","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/prohoster.info\/sl\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/prohoster.info\/sl\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/prohoster.info\/sl\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/prohoster.info\/sl\/wp-json\/wp\/v2\/comments?post=32777"}],"version-history":[{"count":0,"href":"https:\/\/prohoster.info\/sl\/wp-json\/wp\/v2\/posts\/32777\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/prohoster.info\/sl\/wp-json\/wp\/v2\/media\/24554"}],"wp:attachment":[{"href":"https:\/\/prohoster.info\/sl\/wp-json\/wp\/v2\/media?parent=32777"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/prohoster.info\/sl\/wp-json\/wp\/v2\/categories?post=32777"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/prohoster.info\/sl\/wp-json\/wp\/v2\/tags?post=32777"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}