{"id":37030,"date":"2019-10-31T22:15:23","date_gmt":"2019-10-31T19:15:23","guid":{"rendered":"https:\/\/prohoster.info\/blog\/servisnaya-set-ploskost-dannyh-i-ploskosti-upravleniya-service-mesh-data-plane-vs-control-plane\/"},"modified":"2019-10-31T22:15:23","modified_gmt":"2019-10-31T19:15:23","slug":"servisnaya-set-ploskost-dannyh-i-ploskosti-upravleniya-service-mesh-data-plane-vs-control-plane","status":"publish","type":"post","link":"https:\/\/prohoster.info\/es\/blog\/administrirovanie\/servisnaya-set-ploskost-dannyh-i-ploskosti-upravleniya-service-mesh-data-plane-vs-control-plane","title":{"rendered":"Red de servicio, \u2018Plano de datos\u2019 y \u2018Planos de control\u2019 (Service mesh data plane vs. control plane)","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

\u00a1Hola, Habr! Les presento la traducci\u00f3n del art\u00edculo \u00abPlano de datos del service mesh vs plano de control\u00bb<\/a><\/noindex> autor Matt Klein<\/b>.<\/p>\n

\"Red
\n
\nEsta vez se ha \u2018deseado y traducido\u2019 la descripci\u00f3n de ambos componentes del service mesh, el plano de datos y el plano de control. Esta descripci\u00f3n me pareci\u00f3 la m\u00e1s clara e interesante, y lo m\u00e1s importante, nos lleva a comprender \u2018\u00bfrealmente es necesario?\u2019.<\/p>\n

Dado que la idea de \u2018Service Mesh\u2019 se ha vuelto cada vez m\u00e1s popular en los \u00faltimos dos a\u00f1os (art\u00edculo original del 10 de octubre de 2017), y el n\u00famero de participantes en el espacio ha crecido, he visto un crecimiento proporcional de la confusi\u00f3n dentro de toda la comunidad t\u00e9cnica con respecto a c\u00f3mo comparar y contrastar diferentes soluciones.
\n<\/a><\/noindex>
\nLa situaci\u00f3n se describe mejor con las siguientes series de tuits que escrib\u00ed en julio:<\/p>\n

Confusi\u00f3n con el service mesh n\u00ba 1: Linkerd ~ = Nginx ~ = Haproxy ~ = Envoy. Ninguno de ellos es igual a Istio. Istio es algo completamente diferente. 1 \/<\/p><\/blockquote>\n

Los primeros son simplemente planos de datos. Por s\u00ed mismos no hacen nada. Deben configurarse para algo m\u00e1s. 2 \/<\/p><\/blockquote>\n

Istio es un ejemplo de un plano de control que conecta las piezas juntas. Es una capa diferente. \/fin<\/p><\/blockquote>\n

En los tuits anteriores se mencionan varios proyectos diferentes (Linkerd, NGINX, HAProxy, Envoy e Istio), pero, m\u00e1s importante a\u00fan, se introducen conceptos generales como plano de datos, service mesh y plano de control. En esta publicaci\u00f3n, dar\u00e9 un paso atr\u00e1s y explicar\u00e9 lo que quiero decir con \u2018plano de datos\u2019 y \u2018plano de control\u2019 a un nivel muy alto, y luego discutir\u00e9 c\u00f3mo se relacionan estos t\u00e9rminos con los proyectos mencionados en los tuits.<\/p>\n

\u00bfQu\u00e9 es realmente un service mesh?<\/h1>\n

\n\"Red
\nFigura 1: Resumen del service mesh<\/b><\/p>\n

Figura 1<\/b> ilustra la concepci\u00f3n de un service mesh a un nivel muy b\u00e1sico. Hay cuatro cl\u00fasteres de servicio (A-D). Cada instancia del servicio est\u00e1 conectada a un proxy local. Todo el tr\u00e1fico de red (HTTP, REST, gRPC, Redis, etc.) de cada instancia de aplicaci\u00f3n se env\u00eda a trav\u00e9s del proxy local a los cl\u00fasteres de servicio externos correspondientes. As\u00ed, la instancia de la aplicaci\u00f3n no conoce toda la red y solo sabe de su proxy local. De hecho, la red del sistema distribuido se ha abstra\u00eddo del servicio.<\/p>\n

Plano de datos<\/h1>\n

\nEn un service mesh, el proxy ubicado localmente para la aplicaci\u00f3n realiza las siguientes tareas:<\/p>\n