{"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\/fr\/blog\/administrirovanie\/netramesh-legkovesnoe-service-mesh-reshenie","title":{"rendered":"Netramesh \u2013 une solution de service mesh l\u00e9ger","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

Dans le processus de transition d'une application monolithique vers une architecture microservices, nous faisons face \u00e0 de nouveaux d\u00e9fis.<\/p>\n

<\/p>\n

Dans une application monolithique, il est g\u00e9n\u00e9ralement suffisamment simple de d\u00e9terminer quelle partie du syst\u00e8me a rencontr\u00e9 une erreur. Il est probable que le probl\u00e8me provienne du code du monolithe lui-m\u00eame ou de la base de donn\u00e9es. Mais quand nous commen\u00e7ons \u00e0 rechercher un probl\u00e8me dans une architecture microservices, ce n\u2019est plus aussi \u00e9vident. Il faut retrouver tout le chemin que la requ\u00eate a parcouru du d\u00e9but \u00e0 la fin, en le distinguant parmi des centaines de microservices. De plus, beaucoup d'entre eux disposent de leurs propres stockages, o\u00f9 des erreurs logiques, ainsi que des probl\u00e8mes de performance et de r\u00e9silience, peuvent \u00e9galement survenir.<\/p>\n

<\/p>\n

\"Netramesh<\/p>\n

<\/p>\n

J'ai longtemps cherch\u00e9 un outil qui pourrait aider \u00e0 r\u00e9soudre ces probl\u00e8mes (j'en ai parl\u00e9 sur Habr : 1<\/a><\/noindex>, 2<\/a><\/noindex>), mais j'ai finalement d\u00e9velopp\u00e9 ma propre solution open-source. Dans cet article, je parle des avantages de l'approche service mesh et je partage un nouvel outil pour sa mise en \u0153uvre. <\/p>\n

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

Le tracing distribu\u00e9 est une solution courante au probl\u00e8me de recherche d'erreurs dans les syst\u00e8mes distribu\u00e9s. Mais que se passe-t-il si cette approche pour collecter des informations sur les interactions r\u00e9seau n'est pas encore mise en \u0153uvre dans le syst\u00e8me, ou, ce qui est pire, qu'elle fonctionne correctement dans une partie du syst\u00e8me mais pas dans l'autre, car elle n'a pas \u00e9t\u00e9 ajout\u00e9e aux anciens services ? Pour d\u00e9terminer la v\u00e9ritable cause profonde du probl\u00e8me, il est essentiel d'avoir une vue d'ensemble de ce qui se passe dans le syst\u00e8me. Il est particuli\u00e8rement important de comprendre quels microservices participent aux parcours critiques pour l'entreprise.<\/p>\n

<\/p>\n

Ici, l'approche service mesh peut nous \u00eatre utile, car elle s'occupe de toute la machinerie de collecte d'informations r\u00e9seau \u00e0 un niveau inf\u00e9rieur \u00e0 celui o\u00f9 fonctionnent les services eux-m\u00eames. Cette approche nous permet d'intercepter tout le trafic et de l'analyser \u00e0 la vol\u00e9e. De plus, les applications n'ont m\u00eame pas besoin d'en \u00eatre conscientes.<\/p>\n

<\/p>\n

Approche service mesh<\/h1>\n

<\/p>\n

L'id\u00e9e principale de l'approche du service mesh est d'ajouter une couche d'infrastructure suppl\u00e9mentaire au-dessus du r\u00e9seau, ce qui nous permettra d'effectuer diverses op\u00e9rations sur l'interaction entre services. La plupart des impl\u00e9mentations fonctionnent de la mani\u00e8re suivante : \u00e0 chaque microservice, on ajoute un conteneur sidecar suppl\u00e9mentaire avec un proxy transparent, par lequel tout le trafic entrant et sortant du service transite. C'est \u00e0 cet endroit pr\u00e9cis que nous pouvons effectuer l'\u00e9quilibrage des clients, appliquer des politiques de s\u00e9curit\u00e9, imposer des limites sur le nombre de requ\u00eates, et collecter des informations importantes sur les interactions entre services en production.<\/p>\n

<\/p>\n

\"Netramesh<\/p>\n

<\/p>\n

Solutions<\/h1>\n

<\/p>\n

Il existe d\u00e9j\u00e0 plusieurs impl\u00e9mentations de cette approche : Istio<\/a><\/noindex> et linkerd2<\/a><\/noindex>. Elles offrent de nombreuses fonctionnalit\u00e9s pr\u00eates \u00e0 l'emploi. Mais en m\u00eame temps, cela entra\u00eene \u00e9galement un important overhead en termes de ressources. En effet, plus le cluster dans lequel cette syst\u00e8me fonctionne est grand, plus les ressources n\u00e9cessaires pour maintenir la nouvelle infrastructure seront \u00e9lev\u00e9es. Chez Avito, nous exploitons des clusters Kubernetes qui contiennent des milliers d'instances de services (et leur nombre continue de cro\u00eetre rapidement). Dans l'impl\u00e9mentation actuelle, Istio consomme environ 300 Mo de m\u00e9moire vive par instance de service. En raison de la multitude de fonctionnalit\u00e9s, l'\u00e9quilibrage transparent influence \u00e9galement le temps de r\u00e9ponse global des services (jusqu'\u00e0 10 ms).<\/p>\n

<\/p>\n

En fin de compte, nous avons examin\u00e9 les fonctionnalit\u00e9s dont nous avons besoin imm\u00e9diatement et avons d\u00e9cid\u00e9 que la principale raison pour laquelle nous avons commenc\u00e9 \u00e0 introduire de telles solutions \u00e9tait la capacit\u00e9 de collecter des informations de tracing de mani\u00e8re transparente \u00e0 travers l'ensemble du syst\u00e8me. Nous voulions \u00e9galement avoir le contr\u00f4le sur les interactions entre services et effectuer diff\u00e9rentes manipulations des en-t\u00eates \u00e9chang\u00e9s entre les services. <\/p>\n

<\/p>\n

Finalement, nous sommes arriv\u00e9s \u00e0 notre solution : Netramesh<\/a><\/noindex>.<\/p>\n

<\/p>\n

Netramesh<\/h1>\n

<\/p>\n

Netramesh<\/a><\/noindex> \u2014 c'est une solution service mesh l\u00e9g\u00e8re avec une capacit\u00e9 de mise \u00e0 l'\u00e9chelle infinie, peu importe le nombre de services dans le syst\u00e8me.<\/p>\n

<\/p>\n

Les principaux objectifs de cette nouvelle solution \u00e9taient un faible overhead en ressources et une haute performance. Parmi les fonctionnalit\u00e9s principales, nous voulions imm\u00e9diatement avoir la possibilit\u00e9 d'envoyer de mani\u00e8re transparente les spans de tracing dans notre syst\u00e8me Jaeger.<\/p>\n

<\/p>\n

Aujourd'hui, la plupart des solutions cloud sont mises en \u0153uvre en Golang. Et, bien s\u00fbr, il y a de bonnes raisons \u00e0 cela. \u00c9crire des applications r\u00e9seau en Golang, qui fonctionnent de mani\u00e8re asynchrone avec des entr\u00e9es-sorties et qui se mettent \u00e0 l'\u00e9chelle en fonction des besoins, est pratique et relativement simple. Et ce qui est \u00e9galement tr\u00e8s important, c'est que les performances sont suffisantes pour accomplir cette t\u00e2che. C'est pourquoi nous avons \u00e9galement choisi Golang.<\/p>\n

<\/p>\n

Performance<\/h1>\n

<\/p>\n

Nous avons concentr\u00e9 nos efforts sur l'atteinte d'une performance maximale. Pour une solution d\u00e9ploy\u00e9e \u00e0 proximit\u00e9 de chaque instance de service, une faible consommation de m\u00e9moire vive et de temps processeur est n\u00e9cessaire. Et, bien s\u00fbr, la latence de r\u00e9ponse doit \u00e9galement \u00eatre minimale.<\/p>\n

<\/p>\n

Voyons quels r\u00e9sultats nous avons obtenus. <\/p>\n

<\/p>\n

RAM<\/h2>\n

<\/p>\n

Netramesh consomme environ 10 Mo sans trafic et jusqu'\u00e0 50 Mo avec une charge allant jusqu'\u00e0 10 000 RPS sur une seule instance.<\/p>\n

<\/p>\n

Le proxy Istio envoy consomme toujours environ 300 Mo dans nos clusters avec des milliers d'instances. Cela emp\u00eache de le redimensionner \u00e0 l'\u00e9chelle du cluster.<\/p>\n

<\/p>\n

\"Netramesh<\/p>\n

<\/p>\n

\"Netramesh<\/p>\n

<\/p>\n

Avec Netramesh, nous avons r\u00e9ussi \u00e0 r\u00e9duire la consommation de m\u00e9moire d'environ 10 fois.<\/p>\n

<\/p>\n

CPU<\/h2>\n

<\/p>\n

L'utilisation du CPU est relativement \u00e9gale sous charge. Elle d\u00e9pend du nombre de requ\u00eates par unit\u00e9 de temps au sidecar. Les valeurs au pic de 3000 requ\u00eates par seconde sont :<\/p>\n

<\/p>\n

\"Netramesh<\/p>\n

<\/p>\n

\"Netramesh <\/p>\n

<\/p>\n

Il y a un autre point important : Netramesh est une solution sans plan de contr\u00f4le et ne consomme pas de temps processeur en l'absence de charge. Avec Istio, les sidecars mettent toujours \u00e0 jour les endpoints des services. En fin de compte, nous pouvons voir une telle image sans charge :<\/p>\n

<\/p>\n

\"Netramesh<\/p>\n

<\/p>\n

Nous utilisons HTTP\/1 pour l'interaction entre les services. L'augmentation du temps de r\u00e9ponse avec Istio lors du proxying via envoy \u00e9tait de 5 \u00e0 10 ms, ce qui est assez \u00e9lev\u00e9 pour des services qui sont pr\u00eats \u00e0 r\u00e9pondre en millisecondes. Avec Netramesh, ce temps a \u00e9t\u00e9 r\u00e9duit \u00e0 0,5-2 ms.<\/p>\n

<\/p>\n

Scalabilit\u00e9<\/h1>\n

<\/p>\n

Le faible nombre de ressources utilis\u00e9es par chaque proxy permet de le placer \u00e0 c\u00f4t\u00e9 de chaque service. Netramesh a \u00e9t\u00e9 d\u00e9lib\u00e9r\u00e9ment con\u00e7u sans composant de plan de contr\u00f4le pour maintenir la l\u00e9g\u00e8ret\u00e9 de chaque sidecar. Dans les solutions de service mesh, le plan de contr\u00f4le diffuse souvent les informations de d\u00e9couverte de services dans chaque sidecar. Avec cela arrivent \u00e9galement des informations sur les d\u00e9lais d'attente et les r\u00e9glages d'\u00e9quilibrage. Tout cela permet de faire beaucoup de choses utiles, mais, malheureusement, gonfle la taille des sidecars. <\/p>\n

<\/p>\n

D\u00e9couverte de services<\/h1>\n

<\/p>\n

\"Netramesh <\/p>\n

<\/p>\n

Netramesh n'ajoute aucun m\u00e9canisme suppl\u00e9mentaire pour la d\u00e9couverte de services. Tout le trafic est transparent via le sidecar netra. <\/p>\n

<\/p>\n

Netramesh prend en charge le protocole applicatif HTTP\/1. Pour sa d\u00e9finition, une liste de ports configurables est utilis\u00e9e. En g\u00e9n\u00e9ral, il existe plusieurs ports dans le syst\u00e8me qui permettent l'interaction via HTTP. Par exemple, pour l'interaction entre services et requ\u00eates externes, nous utilisons les ports 80, 8890, 8080. Dans ce cas, ils peuvent \u00eatre sp\u00e9cifi\u00e9s \u00e0 l'aide d'une variable d'environnement. NETRA_HTTP_PORTS<\/code>.<\/p>\n

<\/p>\n

Si vous utilisez Kubernetes comme orchestrateur et son m\u00e9canisme Service pour l'interaction intra-cluster entre services, le m\u00e9canisme reste exactement le m\u00eame. Le micro-service obtient d'abord l'adresse IP du service via kube-dns et ouvre une nouvelle connexion vers celle-ci. Cette connexion est \u00e9tablie d'abord avec le netra-sidecar local et tous les paquets TCP arrivent initialement dans netra. Ensuite, netra-sidecar \u00e9tablit la connexion avec le point de destination initial. Le NAT sur l'adresse IP du pod sur le n\u0153ud reste le m\u00eame que sans netra.<\/p>\n

<\/p>\n

Tra\u00e7age distribu\u00e9 et transmission de contexte<\/h1>\n

<\/p>\n

Netramesh fournit la fonctionnalit\u00e9 n\u00e9cessaire pour envoyer des spans de tra\u00e7age concernant les interactions HTTP. Netra-sidecar analyse le protocole HTTP, mesure les latences des requ\u00eates et extrait les informations n\u00e9cessaires des en-t\u00eates HTTP. Nous obtenons finalement tous les tra\u00e7ages dans un syst\u00e8me Jaeger unique. Pour une configuration fine, il est \u00e9galement possible d'utiliser les variables d'environnement fournies par la biblioth\u00e8que officielle. biblioth\u00e8que jaeger go<\/a><\/noindex>. <\/p>\n

<\/p>\n

\"Netramesh<\/p>\n

<\/p>\n

\"Netramesh <\/p>\n

<\/p>\n

Cependant, il existe un probl\u00e8me. Tant que les services ne g\u00e9n\u00e8rent pas et ne transmettent pas un en-t\u00eate uber sp\u00e9cial, nous ne verrons pas les spans de tra\u00e7age connect\u00e9s dans le syst\u00e8me. Et c'est ce qui est n\u00e9cessaire pour identifier rapidement les causes des probl\u00e8mes. Ici, Netramesh a \u00e0 nouveau une solution. Les proxies lisent les en-t\u00eates HTTP et, en l'absence de l'uber trace id, le g\u00e9n\u00e8rent. Netramesh conserve \u00e9galement des informations sur les requ\u00eates entrantes et sortantes dans le sidecar et les associe en enrichissant les n\u00e9cessit\u00e9s des en-t\u00eates des requ\u00eates sortantes. Tout ce que les services doivent faire est de transmettre un seul en-t\u00eate. X-Request-Id<\/code>, qui peut \u00eatre configur\u00e9 \u00e0 l'aide d'une variable d'environnement. NETRA_HTTP_REQUEST_ID_HEADER_NAME<\/code>. Pour g\u00e9rer la taille du contexte dans Netramesh, vous pouvez sp\u00e9cifier les variables d'environnement suivantes : NETRA_TRACING_CONTEXT_EXPIRATION_MILLISECONDS<\/code> (le temps pendant lequel le contexte sera conserv\u00e9) et NETRA_TRACING_CONTEXT_CLEANUP_INTERVAL<\/code> (la fr\u00e9quence de nettoyage du contexte).<\/p>\n

<\/p>\n

Il est \u00e9galement possible de combiner plusieurs chemins dans votre syst\u00e8me en les marquant avec un marqueur de session sp\u00e9cial. Netra permet de d\u00e9finir HTTP_HEADER_TAG_MAP<\/code> pour transformer les en-t\u00eates HTTP en balises de tracing span correspondantes. Cela peut \u00eatre particuli\u00e8rement utile pour les tests. Apr\u00e8s avoir effectu\u00e9 un test fonctionnel, vous pouvez voir quelle partie du syst\u00e8me a \u00e9t\u00e9 affect\u00e9e en filtrant par la cl\u00e9 de session correspondante.<\/p>\n

<\/p>\n

D\u00e9finition de la source de la demande<\/h1>\n

<\/p>\n

Pour d\u00e9terminer d'o\u00f9 provient la demande, vous pouvez utiliser la fonctionnalit\u00e9 d'ajout automatique d'en-t\u00eate avec la source. Gr\u00e2ce \u00e0 la variable d'environnement NETRA_HTTP_X_SOURCE_HEADER_NAME<\/code> vous pouvez d\u00e9finir le nom de l'en-t\u00eate qui sera automatiquement ajout\u00e9. Avec NETRA_HTTP_X_SOURCE_VALUE<\/code> vous pouvez d\u00e9finir la valeur qui sera attribu\u00e9e \u00e0 l'en-t\u00eate X-Source pour toutes les demandes sortantes. <\/p>\n

<\/p>\n

Cela permet d'uniformiser la diffusion de cet en-t\u00eate utile \u00e0 travers le r\u00e9seau. Ensuite, vous pouvez l'utiliser dans les services et l'ajouter aux journaux, aux m\u00e9triques.<\/p>\n

<\/p>\n

Routage du trafic et entrailles de Netramesh<\/h1>\n

<\/p>\n

Netramesh est compos\u00e9 de deux principaux composants. Le premier, netra-init, d\u00e9finit les r\u00e8gles de r\u00e9seau pour intercepter le trafic. Il utilise les r\u00e8gles iptables redirect<\/a><\/noindex> pour intercepter tout ou partie du trafic vers le sidecar, qui est le deuxi\u00e8me composant principal de Netramesh. Vous pouvez configurer les ports \u00e0 intercepter pour les sessions TCP entrantes et sortantes : INBOUND_INTERCEPT_PORTS, OUTBOUND_INTERCEPT_PORTS<\/code>.<\/p>\n

<\/p>\n

L'outil dispose \u00e9galement d'une fonctionnalit\u00e9 int\u00e9ressante \u2014 le routage probabiliste. Si vous utilisez Netramesh uniquement pour collecter des tracing spans, vous pouvez \u00e9conomiser des ressources en production en activant le routage probabiliste \u00e0 l'aide des variables NETRA_INBOUND_PROBABILITY<\/code> et NETRA_OUTBOUND_PROBABILITY<\/code> (de 0 \u00e0 1). La valeur par d\u00e9faut est 1 (tout le trafic est intercept\u00e9).<\/p>\n

<\/p>\n

Apr\u00e8s une interception r\u00e9ussie, le sidecar netra accepte une nouvelle connexion et utilise SO_ORIGINAL_DST<\/code> l'option de socket pour obtenir le point de destination d'origine. Ensuite, Netra ouvre une nouvelle connexion \u00e0 l'adresse IP d'origine et \u00e9tablit une communication TCP bidirectionnelle entre les parties, \u00e9coutant tout le trafic passant. Si le port est d\u00e9fini comme HTTP, Netra tente de l'analyser et de le tracer. Si l'analyse HTTP \u00e9choue, Netra effectue un fallback sur TCP et proxy les octets de mani\u00e8re transparente.<\/p>\n

<\/p>\n

Construction d'un graphique de d\u00e9pendances<\/h1>\n

<\/p>\n

Apr\u00e8s avoir obtenu une grande quantit\u00e9 d'informations de tracing dans Jaeger, on souhaite obtenir un graphique complet des interactions dans le syst\u00e8me. Mais si votre syst\u00e8me est suffisamment charg\u00e9 et qu'au cours de la journ\u00e9e des milliards de spans de tracing s'accumulent, leur agr\u00e9gation devient une t\u00e2che compliqu\u00e9e. Il existe une m\u00e9thode officielle pour cela : spark-dependencies<\/a><\/noindex>. Cependant, cela prendra des heures pour construire le graphique complet et n\u00e9cessitera de t\u00e9l\u00e9charger l'ensemble du dataset de Jaeger pour les derni\u00e8res 24 heures. <\/p>\n

<\/p>\n

Si vous utilisez Elasticsearch pour stocker les spans de tracing, vous pouvez utiliser un utilitaire simple en Golang<\/a><\/noindex>, qui construira un graphique similaire en quelques minutes, en exploitant les caract\u00e9ristiques et les fonctionnalit\u00e9s d'Elasticsearch.<\/p>\n

<\/p>\n

\"Netramesh<\/p>\n

<\/p>\n

Comment utiliser Netramesh<\/h1>\n

<\/p>\n

Netra peut \u00eatre facilement ajout\u00e9 \u00e0 n'importe quel service ex\u00e9cut\u00e9 sous un orchestrateur quelconque. Vous pouvez consulter un exemple ici<\/a><\/noindex>.<\/p>\n

<\/p>\n

Actuellement, Netra ne dispose pas de possibilit\u00e9 d'injection automatique du sidecar dans les services, mais des plans pour sa mise en \u0153uvre sont en cours. <\/p>\n

<\/p>\n

L'avenir de Netramesh<\/h1>\n

<\/p>\n

L'objectif principal Netramesh<\/a><\/noindex> est d'atteindre des co\u00fbts minimaux en ressources et de fournir des performances \u00e9lev\u00e9es, en offrant des fonctionnalit\u00e9s cl\u00e9s pour l'observabilit\u00e9 et le contr\u00f4le des interactions interservices. <\/p>\n

<\/p>\n

\u00c0 l'avenir, Netramesh prendra en charge d'autres protocoles de niveau application en plus de HTTP. Bient\u00f4t, une fonction de routage L7 sera disponible.<\/p>\n

<\/p>\n

Utilisez Netramesh si vous \u00eates confront\u00e9 \u00e0 des probl\u00e8mes similaires, et \u00e9crivez-nous vos questions et suggestions.<\/p>\n

Source : 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 une solution l\u00e9g\u00e8re de service mesh | ProHoster","description":"Lors du passage d'une application monolithique \u00e0 une architecture microservices, nous rencontrons de nouveaux probl\u00e8mes. Dans une application monolithique, il est g\u00e9n\u00e9ralement suffisant de d\u00e9terminer dans quelle partie du syst\u00e8me cela s'est produit.","canonical_url":"https:\/\/prohoster.info\/fr\/blog\/administrirovanie\/netramesh-legkovesnoe-service-mesh-reshenie","robots":"max-image-preview:large","keywords":"","webmasterTools":{"miscellaneous":""},"schema":null,"og:locale":"fr_FR","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\/fr\/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\/fr\/wp-json\/wp\/v2\/posts\/32777","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/prohoster.info\/fr\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/prohoster.info\/fr\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/prohoster.info\/fr\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/prohoster.info\/fr\/wp-json\/wp\/v2\/comments?post=32777"}],"version-history":[{"count":0,"href":"https:\/\/prohoster.info\/fr\/wp-json\/wp\/v2\/posts\/32777\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/prohoster.info\/fr\/wp-json\/wp\/v2\/media\/24554"}],"wp:attachment":[{"href":"https:\/\/prohoster.info\/fr\/wp-json\/wp\/v2\/media?parent=32777"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/prohoster.info\/fr\/wp-json\/wp\/v2\/categories?post=32777"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/prohoster.info\/fr\/wp-json\/wp\/v2\/tags?post=32777"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}