{"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\/es\/blog\/administrirovanie\/netramesh-legkovesnoe-service-mesh-reshenie","title":{"rendered":"Netramesh \u2013 una soluci\u00f3n de service mesh ligera","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

En el proceso de transici\u00f3n de una aplicaci\u00f3n monol\u00edtica a una arquitectura de microservicios, nos enfrentamos a nuevos problemas.<\/p>\n

<\/p>\n

En una aplicaci\u00f3n monol\u00edtica, generalmente es suficiente con determinar en qu\u00e9 parte del sistema ocurri\u00f3 el error. Lo m\u00e1s probable es que el problema est\u00e9 en el c\u00f3digo del propio monolito o en la base de datos. Pero cuando comenzamos a buscar un problema en una arquitectura de microservicios, ya no es tan obvio. Necesitamos encontrar todo el camino que ha seguido la solicitud de principio a fin, despej\u00e1ndolo entre cientos de microservicios. Adem\u00e1s, muchos de ellos tienen sus propios almacenes, donde pueden surgir tanto errores l\u00f3gicos como problemas de rendimiento y disponibilidad.<\/p>\n

<\/p>\n

\"Netramesh<\/p>\n

<\/p>\n

Busqu\u00e9 durante mucho tiempo una herramienta que me ayudara a enfrentar tales problemas (escrib\u00ed sobre esto en \u0425\u0430\u0431\u0440: 1<\/a><\/noindex>, 2<\/a><\/noindex>), pero al final hice mi propia soluci\u00f3n de c\u00f3digo abierto. En el art\u00edculo, hablo sobre las ventajas del enfoque de service mesh y comparto una nueva herramienta para su implementaci\u00f3n. <\/p>\n

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

El tracing distribuido es una soluci\u00f3n com\u00fan al problema de la b\u00fasqueda de errores en sistemas distribuidos. Pero, \u00bfqu\u00e9 sucede si en el sistema a\u00fan no se ha implementado este enfoque para recolectar informaci\u00f3n sobre las interacciones de red, o, peor a\u00fan, en parte del sistema ya funciona correctamente y en otra no, porque no se ha agregado a los servicios antiguos? Para determinar la causa ra\u00edz exacta del problema, es necesario tener una imagen completa de lo que est\u00e1 sucediendo en el sistema. Es especialmente importante entender qu\u00e9 microservicios participan en los caminos cr\u00edticos para el negocio.<\/p>\n

<\/p>\n

Aqu\u00ed es donde nos puede ayudar el enfoque de service mesh, que se encargar\u00e1 de toda la maquinaria para recolectar informaci\u00f3n de red a un nivel m\u00e1s bajo que el de los propios servicios. Este enfoque nos permite interceptar todo el tr\u00e1fico y analizarlo en tiempo real. Adem\u00e1s, las aplicaciones no necesitan saber nada al respecto.<\/p>\n

<\/p>\n

Enfoque de service mesh<\/h1>\n

<\/p>\n

La idea principal del enfoque de service mesh es a\u00f1adir una capa de infraestructura adicional sobre la red, que nos permitir\u00e1 realizar cualquier acci\u00f3n relacionada con la interacci\u00f3n entre servicios. La mayor\u00eda de las implementaciones funcionan de la siguiente manera: a cada microservicio se le a\u00f1ade un contenedor sidecar adicional con un proxy transparente, a trav\u00e9s del cual se redirige todo el tr\u00e1fico entrante y saliente del servicio. Y es justo en este punto donde podemos hacer balanceo del cliente, aplicar pol\u00edticas de seguridad, introducir restricciones en la cantidad de solicitudes y recopilar informaci\u00f3n importante sobre la interacci\u00f3n de los servicios en producci\u00f3n.<\/p>\n

<\/p>\n

\"Netramesh<\/p>\n

<\/p>\n

Soluciones<\/h1>\n

<\/p>\n

Ya existen varias implementaciones de este enfoque: Istio<\/a><\/noindex> y linkerd2<\/a><\/noindex>. Proporcionan muchas funcionalidades listas para usar. Pero al mismo tiempo, esto conlleva un gran overhead de recursos. Y cuanto mayor es el cl\u00faster en el que opera tal sistema, m\u00e1s recursos se requieren para mantener la nueva infraestructura. En Avito, operamos cl\u00fasteres de Kubernetes en los que hay miles de instancias de servicios (y su n\u00famero sigue creciendo r\u00e1pidamente). En la implementaci\u00f3n actual, Istio consume ~300 Mb de memoria RAM por cada instancia de servicio. Debido a la gran cantidad de funcionalidades, el balanceo transparente tambi\u00e9n afecta al tiempo total de respuesta de los servicios (incluso hasta 10 ms).<\/p>\n

<\/p>\n

Al final, analizamos cu\u00e1les eran exactamente las funcionalidades que necesit\u00e1bamos en este momento, y decidimos que lo principal, por lo que comenzamos a implementar este tipo de soluciones, era la capacidad de recopilar informaci\u00f3n de tracing de todo el sistema de manera transparente. Tambi\u00e9n quer\u00edamos tener control sobre la interacci\u00f3n de los servicios y realizar diversas manipulaciones con los encabezados que se transmiten entre ellos. <\/p>\n

<\/p>\n

Finalmente, llegamos a nuestra soluci\u00f3n:\u200a Netramesh<\/a><\/noindex>.<\/p>\n

<\/p>\n

Netramesh<\/h1>\n

<\/p>\n

Netramesh<\/a><\/noindex> \u2014 es una soluci\u00f3n de service mesh ligera con la posibilidad de escalado infinito independientemente de la cantidad de servicios en el sistema.<\/p>\n

<\/p>\n

Los principales objetivos de la nueva soluci\u00f3n eran un bajo overhead de recursos y un alto rendimiento. De las funcionalidades principales, quer\u00edamos desde el principio poder enviar de manera transparente los spans de tracing a nuestro sistema Jaeger.<\/p>\n

<\/p>\n

Hoy en d\u00eda, la mayor\u00eda de las soluciones en la nube se implementan en Golang. Y, por supuesto, hay razones para ello. Es conveniente y bastante simple escribir aplicaciones de red en Golang que funcionen de manera as\u00edncrona con entrada\/salida y se escalen seg\u00fan sea necesario en n\u00facleos. Y, lo que tambi\u00e9n es muy importante, el rendimiento es suficiente para abordar esta tarea. Por eso tambi\u00e9n elegimos Golang.<\/p>\n

<\/p>\n

Rendimiento<\/h1>\n

<\/p>\n

Nos hemos enfocado en lograr un rendimiento \u00f3ptimo. Para una soluci\u00f3n que se despliega junto a cada instancia del servicio, es necesario un bajo consumo de memoria y tiempo de CPU. Y, por supuesto, la latencia de respuesta debe ser igualmente baja.<\/p>\n

<\/p>\n

Veamos qu\u00e9 resultados hemos obtenido. <\/p>\n

<\/p>\n

RAM<\/h2>\n

<\/p>\n

Netramesh consume ~10Mb sin tr\u00e1fico y hasta 50Mb con una carga m\u00e1xima de 10000 RPS en una instancia.<\/p>\n

<\/p>\n

El proxy Istio envoy siempre consume ~300Mb en nuestros cl\u00fasteres con miles de instancias. Esto impide escalarlo a todo el cl\u00faster.<\/p>\n

<\/p>\n

\"Netramesh<\/p>\n

<\/p>\n

\"Netramesh<\/p>\n

<\/p>\n

Con Netramesh hemos logrado reducir el consumo de memoria en ~10 veces.<\/p>\n

<\/p>\n

CPU<\/h2>\n

<\/p>\n

El uso de CPU es relativamente constante bajo carga. Depende del n\u00famero de solicitudes por unidad de tiempo al sidecar. Los valores a 3000 solicitudes por segundo en el pico son:<\/p>\n

<\/p>\n

\"Netramesh<\/p>\n

<\/p>\n

\"Netramesh <\/p>\n

<\/p>\n

Hay otro aspecto importante: Netramesh es una soluci\u00f3n sin plano de control y no consume tiempo de CPU sin carga. Con Istio, los sidecars siempre actualizan los endpoints de los servicios. Como resultado, podemos ver esta situaci\u00f3n sin carga:<\/p>\n

<\/p>\n

\"Netramesh<\/p>\n

<\/p>\n

Utilizamos HTTP\/1 para la interacci\u00f3n entre servicios. El aumento en el tiempo de respuesta de Istio al proxy a trav\u00e9s de envoy fue de hasta 5-10ms, lo cual es bastante para servicios que est\u00e1n listos para responder en un milisegundo. Con Netramesh, este tiempo se ha reducido a 0.5-2ms.<\/p>\n

<\/p>\n

Escalabilidad<\/h1>\n

<\/p>\n

La peque\u00f1a cantidad de recursos que consume cada proxy permite que se ubique cerca de cada servicio. Netramesh fue intencionalmente dise\u00f1ado sin un componente de plano de control para mantener la ligereza de cada sidecar. A menudo, en soluciones de service mesh, el plano de control distribuye informaci\u00f3n de descubrimiento de servicios a cada sidecar. Esto viene acompa\u00f1ado de informaci\u00f3n sobre timeouts y configuraciones de balanceo. Todo esto permite hacer muchas cosas \u00fatiles, pero, desafortunadamente, inflado el tama\u00f1o de los sidecars. <\/p>\n

<\/p>\n

Descubrimiento de servicios<\/h1>\n

<\/p>\n

\"Netramesh <\/p>\n

<\/p>\n

Netramesh no a\u00f1ade mecanismos adicionales para el descubrimiento de servicios. Todo el tr\u00e1fico se proxinea de manera transparente a trav\u00e9s del sidecar de netra. <\/p>\n

<\/p>\n

Netramesh admite el protocolo de aplicaci\u00f3n HTTP\/1. Para su definici\u00f3n, se utiliza una lista de puertos configurable. Normalmente hay varios puertos en el sistema a trav\u00e9s de los cuales se realiza la interacci\u00f3n HTTP. Por ejemplo, para la interacci\u00f3n entre servicios y solicitudes externas, utilizamos los puertos 80, 8890, 8080. En este caso, se pueden definir mediante una variable de entorno. NETRA_HTTP_PORTS<\/code>.<\/p>\n

<\/p>\n

Si utilizas Kubernetes como orquestador y su mecanismo Service para la interacci\u00f3n entre servicios dentro del cl\u00faster, el mecanismo sigue siendo el mismo. Primero, el microservicio obtiene la direcci\u00f3n IP del servicio a trav\u00e9s de kube-dns y establece una nueva conexi\u00f3n con ella. Esta conexi\u00f3n se establece primero con el netra-sidecar local, y todos los paquetes TCP llegan inicialmente a netra. Luego, netra-sidecar establece la conexi\u00f3n con el destino original. El NAT en la IP del pod en el nodo sigue siendo el mismo que sin netra.<\/p>\n

<\/p>\n

Trazado distribuido y propagaci\u00f3n de contexto<\/h1>\n

<\/p>\n

Netramesh proporciona la funcionalidad necesaria para enviar spans de trazado sobre la interacci\u00f3n HTTP. Netra-sidecar analiza el protocolo HTTP, mide las latencias de las solicitudes y extrae la informaci\u00f3n necesaria de los encabezados HTTP. Al final, obtenemos todos los trazos en un \u00fanico sistema Jaeger. Para una configuraci\u00f3n m\u00e1s detallada, tambi\u00e9n se pueden utilizar las variables de entorno que proporciona la biblioteca oficial. biblioteca jaeger go<\/a><\/noindex>. <\/p>\n

<\/p>\n

\"Netramesh<\/p>\n

<\/p>\n

\"Netramesh <\/p>\n

<\/p>\n

Pero hay un problema. Mientras los servicios no generen y propaguen un encabezado uber especial, no veremos los spans de trazado conectados en el sistema. Y eso es lo que necesitamos para buscar r\u00e1pidamente la ra\u00edz de los problemas. Aqu\u00ed Netramesh vuelve a tener la soluci\u00f3n. Los proxies leen los encabezados HTTP y, si no contienen el uber trace id, lo generan. Netramesh tambi\u00e9n almacena informaci\u00f3n sobre las solicitudes entrantes y salientes en el sidecar y las empareja enriqueciendo las solicitudes salientes con los encabezados necesarios. Todo lo que los servicios deben hacer es propagar solo un encabezado. X-Request-Id<\/code>, que se puede configurar mediante una variable de entorno. NETRA_HTTP_REQUEST_ID_HEADER_NAME<\/code>. Para gestionar el tama\u00f1o del contexto en Netramesh, se pueden definir las siguientes variables de entorno: NETRA_TRACING_CONTEXT_EXPIRATION_MILLISECONDS<\/code> (el tiempo durante el cual se almacenar\u00e1 el contexto) y NETRA_TRACING_CONTEXT_CLEANUP_INTERVAL<\/code> (la frecuencia de limpieza del contexto).<\/p>\n

<\/p>\n

Tambi\u00e9n es posible combinar varias rutas en su sistema mediante la marcaci\u00f3n con un marcador de sesi\u00f3n especial. Netra permite establecer HTTP_HEADER_TAG_MAP<\/code> para convertir las cabeceras HTTP en etiquetas de tracing span correspondientes. Esto puede ser especialmente \u00fatil para pruebas. Despu\u00e9s de pasar la prueba funcional, se puede ver qu\u00e9 parte del sistema fue afectada, filtrando por la clave de sesi\u00f3n correspondiente.<\/p>\n

<\/p>\n

Determinaci\u00f3n de la fuente de la solicitud<\/h1>\n

<\/p>\n

Para determinar de d\u00f3nde proviene la solicitud, se puede utilizar la funcionalidad de adici\u00f3n autom\u00e1tica de cabecera con la fuente. Con la variable de entorno NETRA_HTTP_X_SOURCE_HEADER_NAME<\/code> se puede establecer el nombre de la cabecera que se fijar\u00e1 autom\u00e1ticamente. Con NETRA_HTTP_X_SOURCE_VALUE<\/code> se puede establecer el valor en el que se fijar\u00e1 la cabecera X-Source para todas las solicitudes salientes. <\/p>\n

<\/p>\n

Esto permite la difusi\u00f3n unificada de esta valiosa cabecera en toda la red. Luego, se puede utilizar en servicios y agregar a los registros y m\u00e9tricas.<\/p>\n

<\/p>\n

Enrutamiento de tr\u00e1fico y aspectos internos de Netramesh<\/h1>\n

<\/p>\n

Netramesh consta de dos componentes principales. El primero, netra-init, establece reglas de red para la interceptaci\u00f3n de tr\u00e1fico. Utiliza reglas de redirecci\u00f3n de iptables<\/a><\/noindex> para interceptar todo o parte del tr\u00e1fico hacia un sidecar, que es el segundo componente principal de Netramesh. Se pueden configurar qu\u00e9 puertos interceptar para las sesiones TCP entrantes y salientes: INBOUND_INTERCEPT_PORTS, OUTBOUND_INTERCEPT_PORTS<\/code>.<\/p>\n

<\/p>\n

Adem\u00e1s, la herramienta tiene una funcionalidad interesante: el enrutamiento probabil\u00edstico. Si se utiliza Netramesh exclusivamente para la recopilaci\u00f3n de tracing span, se pueden ahorrar recursos en un entorno de producci\u00f3n y habilitar el enrutamiento probabil\u00edstico mediante las variables NETRA_INBOUND_PROBABILITY<\/code> y NETRA_OUTBOUND_PROBABILITY<\/code> (de 0 a 1). El valor predeterminado es 1 (se intercepta todo el tr\u00e1fico).<\/p>\n

<\/p>\n

Despu\u00e9s de interceptar con \u00e9xito, el sidecar de netra acepta una nueva conexi\u00f3n y utiliza SO_ORIGINAL_DST<\/code> la opci\u00f3n de socket para obtener el destino original. Luego, Netra abre una nueva conexi\u00f3n con la direcci\u00f3n IP original y establece comunicaci\u00f3n TCP bidireccional entre las partes, escuchando todo el tr\u00e1fico que pasa. Si el puerto se define como HTTP, Netra intenta analizarlo y rastrearlo. Si el an\u00e1lisis HTTP no tiene \u00e9xito, Netra hace un fallback a TCP y proxy de manera transparente los bytes.<\/p>\n

<\/p>\n

Construcci\u00f3n del grafo de dependencias<\/h1>\n

<\/p>\n

Despu\u00e9s de obtener una gran cantidad de informaci\u00f3n de tracing en Jaeger, es deseable obtener un grafo completo de interacciones en el sistema. Pero si su sistema est\u00e1 muy cargado y se acumulan miles de millones de spans de tracing en un d\u00eda, agregarlos se convierte en una tarea bastante complicada. Hay un m\u00e9todo oficial para hacerlo: spark-dependencies<\/a><\/noindex>. Sin embargo, tomar\u00e1 horas construir el grafo completo y obligar\u00e1 a descargar de Jaeger todo el conjunto de datos de las \u00faltimas 24 horas. <\/p>\n

<\/p>\n

Si utiliza Elasticsearch para almacenar los spans de tracing, puede aprovechar una utilidad simple en Golang<\/a><\/noindex>, que construir\u00e1 un grafo similar en minutos, utilizando las caracter\u00edsticas y capacidades de Elasticsearch.<\/p>\n

<\/p>\n

\"Netramesh<\/p>\n

<\/p>\n

C\u00f3mo utilizar Netramesh<\/h1>\n

<\/p>\n

Netra se puede agregar f\u00e1cilmente a cualquier servicio que opere bajo cualquier orquestador. Puede ver un ejemplo aqu\u00ed<\/a><\/noindex>.<\/p>\n

<\/p>\n

En este momento, Netra no tiene la capacidad de implementar autom\u00e1ticamente sidecar en los servicios, pero hay planes para su implementaci\u00f3n. <\/p>\n

<\/p>\n

Futuro de Netramesh<\/h1>\n

<\/p>\n

El objetivo principal Netramesh<\/a><\/noindex> es lograr un m\u00ednimo costo de recursos y un alto rendimiento, proporcionando funcionalidades clave para observabilidad y control de la interacci\u00f3n entre servicios. <\/p>\n

<\/p>\n

En el futuro, Netramesh tendr\u00e1 soporte para otros protocolos de nivel de aplicaci\u00f3n adem\u00e1s de HTTP. En un futuro cercano, habr\u00e1 una funcionalidad de enrutamiento L7.<\/p>\n

<\/p>\n

Utilice Netramesh si enfrenta problemas similares y env\u00edenos sus preguntas y sugerencias.<\/p>\n

Fuente: 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 soluci\u00f3n de service mesh ligera | ProHoster","description":"En el proceso de transici\u00f3n de una aplicaci\u00f3n monol\u00edtica a una arquitectura de microservicios, nos encontramos con nuevos problemas. En una aplicaci\u00f3n monol\u00edtica, generalmente es suficiente definir en qu\u00e9 parte del sistema ocurri\u00f3.","canonical_url":"https:\/\/prohoster.info\/es\/blog\/administrirovanie\/netramesh-legkovesnoe-service-mesh-reshenie","robots":"max-image-preview:large","keywords":"","webmasterTools":{"miscellaneous":""},"schema":null,"og:locale":"es_ES","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\/es\/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\/es\/wp-json\/wp\/v2\/posts\/32777","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/prohoster.info\/es\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/prohoster.info\/es\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/prohoster.info\/es\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/prohoster.info\/es\/wp-json\/wp\/v2\/comments?post=32777"}],"version-history":[{"count":0,"href":"https:\/\/prohoster.info\/es\/wp-json\/wp\/v2\/posts\/32777\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/prohoster.info\/es\/wp-json\/wp\/v2\/media\/24554"}],"wp:attachment":[{"href":"https:\/\/prohoster.info\/es\/wp-json\/wp\/v2\/media?parent=32777"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/prohoster.info\/es\/wp-json\/wp\/v2\/categories?post=32777"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/prohoster.info\/es\/wp-json\/wp\/v2\/tags?post=32777"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}