Una comparación de la malla de servicios de Kubernetes

Cuando se habla de arquitectura de microservicios y contenedorización, un conjunto de herramientas probadas en producción ha captado la mayor parte de la atención en los últimos años: la red de servicios.

De hecho, la arquitectura de microservicios y Kubernetes (a menudo estilizados como "K8") se han convertido rápidamente en la norma para las aplicaciones escalables, lo que convierte el problema de administrar las comunicaciones entre servicios en un tema candente y las mallas de servicios en una solución atractiva. Yo mismo he usado mallas de servicio en la producción, específicamente Linkerd, Istio y una forma anterior de Ambassador. Pero, ¿qué hacen exactamente las mallas de servicio? ¿Cuál es el mejor para usar? ¿Cómo sabes si debes usar uno?

Para responder a estas preguntas, es útil comprender por qué se desarrollaron las mallas de servicios. Históricamente, la infraestructura de TI tradicional tenía aplicaciones que se ejecutaban como monolitos. Un servicio se ejecutó en un servidor; si necesitaba más capacidad, la solución era escalarla verticalmente aprovisionando una máquina más grande.

Alcanzando los límites de este enfoque, las grandes empresas de tecnología adoptaron rápidamente una arquitectura de tres niveles, separando un equilibrador de carga de los servidores de aplicaciones y un nivel de base de datos. Si bien esta arquitectura siguió siendo algo escalable, decidieron dividir el nivel de la aplicación en microservicios. La comunicación entre estos servicios se volvió crítica para monitorear y asegurar para que las aplicaciones escalaran.

Para permitir la comunicación entre servicios, estas empresas desarrollaron bibliotecas internas: Finagle en Twitter, Hystrix en Netflix y Stubby en Google (que se convirtió en gRPC en 2016). Estas bibliotecas tenían como objetivo solucionar los problemas planteados por la arquitectura de microservicios: seguridad entre servicios, latencia, monitoreo y balanceo de carga. Pero administrar una gran biblioteca como una dependencia, en varios idiomas, es complejo y requiere mucho tiempo.

Al final, ese tipo de biblioteca fue reemplazada por un proxy liviano y más fácil de usar. Dichos proxies eran externamente independientes de la capa de la aplicación (potencialmente transparentes para la aplicación) y más fáciles de actualizar, mantener e implementar. Así nació la malla de servicios.

¿Qué es una malla de servicios?

Una red de servicios es una capa de infraestructura de software para controlar la comunicación entre servicios; generalmente está hecho de dos componentes:

1. El plano de datos , que maneja las comunicaciones cerca de la aplicación. Por lo general, esto se implementa con la aplicación como un conjunto de servidores proxy de red, como se ilustró anteriormente.
2. El plano de control, que es el “cerebro” de la malla de servicios. El plano de control interactúa con los proxies para impulsar configuraciones, garantizar el descubrimiento de servicios y centralizar la observabilidad.

Las mallas de servicio tienen tres objetivos principales en torno a la comunicación entre servicios:

1. Conectividad
2. Seguridad
3. Observabilidad

Conectividad

Este aspecto de la arquitectura de malla de servicios permite el descubrimiento de servicios y el enrutamiento dinámico. También cubre la resiliencia de la comunicación , como reintentos, tiempos de espera, ruptura de circuitos y limitación de velocidad.

Una característica básica de las mallas de servicio es el equilibrio de carga . Todos los servicios interconectados por proxies permiten la implementación de políticas de equilibrio de carga entre servicios, como round robin, aleatorio y menos solicitudes. Esas políticas son la estrategia utilizada por la red de servicios para decidir qué réplica recibirá la solicitud original, como si tuviera pequeños balanceadores de carga frente a cada servicio.

Finalmente, las mallas de servicio ofrecen control de enrutamiento en forma de transferencia y duplicación de tráfico.

Seguridad

En la arquitectura tradicional de microservicios, los servicios se comunican entre sí con tráfico sin cifrar. El tráfico interno sin cifrar se considera hoy en día una mala práctica en términos de seguridad, en particular para la infraestructura de nube pública y las redes de confianza cero.

Además de proteger la privacidad de los datos del cliente donde no hay control directo sobre el hardware, el cifrado del tráfico interno agrega una capa bienvenida de complejidad adicional en caso de una violación del sistema. Por lo tanto, todas las mallas de servicios utilizan cifrado TLS mutuo (mTLS) para la comunicación entre servicios, es decir, todas las comunicaciones entre servidores proxy.

Las mallas de servicios pueden incluso aplicar matrices complejas de políticas de autorización , permitiendo o rechazando el tráfico en función de políticas dirigidas a entornos y servicios particulares.

Observabilidad

El objetivo de las mallas de servicio es brindar visibilidad a las comunicaciones entre servicios. Al controlar la red, una red de servicios impone la observabilidad, proporcionando métricas de capa siete , que a su vez permiten alertas automáticas cuando el tráfico alcanza un umbral personalizable.

Por lo general, con el respaldo de herramientas o complementos de terceros como Jaeger o Zipkin, dicho control también permite el seguimiento mediante la inyección de encabezados de seguimiento HTTP .

Beneficios de la red de servicios

La red de servicios se creó para compensar parte de la carga operativa creada por una arquitectura de microservicios. Aquellos con experiencia en arquitecturas de microservicios saben que requieren una cantidad significativa de trabajo para operar diariamente. Aprovechar al máximo el potencial de los microservicios normalmente requiere herramientas externas para manejar el registro centralizado, la gestión de la configuración y los mecanismos de escalabilidad, entre otros. El uso de una red de servicios estandariza estas capacidades y su configuración e integración .

La observabilidad de la malla de servicio, en particular, proporciona métodos de depuración y optimización extremadamente versátiles. Gracias a la visibilidad granular y completa de los intercambios entre servicios, los ingenieros, en particular los SRE, pueden solucionar más rápidamente posibles errores y configuraciones incorrectas del sistema. Con el seguimiento de la malla de servicios, pueden seguir una solicitud desde su entrada en el sistema (en un equilibrador de carga o un proxy externo) hasta los servicios privados dentro de la pila. Pueden usar el registro para mapear una solicitud y registrar la latencia que encuentra en cada servicio. El resultado final: información detallada sobre el rendimiento del sistema .

La gestión del tráfico brinda poderosas posibilidades antes de pasar a un lanzamiento completo de nuevas versiones de un servicio:

1. Redirigir pequeños porcentajes de solicitudes.
2. Aún mejor, refleje las solicitudes de producción en una nueva versión para probar su comportamiento con el tráfico en tiempo real.
3. Prueba A/B de cualquier servicio o combinación de servicios.

Las mallas de servicio simplifican todos los escenarios anteriores, lo que facilita evitar y/o mitigar cualquier sorpresa en la producción.

Comparación de mallas de servicios de Kubernetes

En muchos sentidos, las mallas de servicios son el último conjunto de herramientas para la arquitectura de microservicios; muchos de ellos se ejecutan en una de las principales herramientas de orquestación de contenedores, Kubernetes. Seleccionamos tres de las redes de servicios principales que se ejecutan en Kubernetes hoy: Linkerd (v2), Istio y Consul Connect. También hablaremos sobre otras mallas de servicios: Kuma, Traefik Mesh y AWS App Mesh. Si bien actualmente son menos prominentes en términos de uso y comunidad, son lo suficientemente prometedores como para revisarlos aquí y seguirlos en general.

Una nota rápida sobre los proxies Sidecar

No todas las mallas de servicios de Kubernetes adoptan el mismo enfoque arquitectónico, pero uno común es aprovechar el patrón sidecar. Esto implica adjuntar un proxy (sidecar) a la aplicación principal para interceptar y regular el tráfico de red entrante y saliente de la aplicación. En la práctica, esto se hace en Kubernetes a través de un contenedor secundario en cada módulo de aplicación que seguirá el ciclo de vida del contenedor de la aplicación.

Hay dos ventajas principales en el enfoque de sidecar para las mallas de servicio:

• Los proxies sidecar son independientes del tiempo de ejecución e incluso del lenguaje de programación de la aplicación.
  • Esto significa que es fácil habilitar todas las funciones de una red de servicios donde sea que se use, en toda la pila.
• Un sidecar tiene el mismo nivel de permisos y acceso a los recursos que la aplicación.
  • El sidecar puede ayudar a monitorear los recursos utilizados por la aplicación principal, sin necesidad de integrar el monitoreo en el código base de la aplicación principal.

Pero los sidecars son una bendición a medias debido a cómo impactan directamente en una aplicación:

• La inicialización de Sidecar puede bloquear el mecanismo de inicio de una aplicación.
• Los proxies sidecar agregan una latencia potencial además de su aplicación.
• Los proxies sidecar también agregan una huella de recursos que puede costar una cantidad significativa de dinero a escala.

Dadas esas ventajas y desventajas, el enfoque de sidecar es con frecuencia un tema de debate en la comunidad de redes de servicios. Dicho esto, cuatro de las seis mallas de servicios que se comparan aquí usan el proxy sidecar de Envoy, y Linkerd usa su propia implementación sidecar; Traefik Mesh no utiliza sidecars en su diseño.

Revisión de Linkerd

Linkerd, que debutó en 2017, es la red de servicios más antigua del mercado. Creado por Buoyant (una compañía iniciada por dos ex-ingenieros de Twitter), Linkerd v1 se basó en Finagle y Netty.

Linkerd v1 se describió como adelantado a su tiempo, ya que era una malla de servicio completa y lista para la producción. Al mismo tiempo, era un poco pesado en términos de uso de recursos. Además, las brechas significativas en la documentación dificultaron la configuración y el funcionamiento en producción.

Con eso, Buoyant tuvo la oportunidad de trabajar con un modelo de producción completo, ganar experiencia y aplicar esa sabiduría. El resultado fue Conduit, la reescritura completa de Linkerd que la compañía lanzó en 2018 y rebautizada como Linkerd v2 ese mismo año. Linkerd v2 trajo consigo varias mejoras convincentes; Dado que el desarrollo activo de Linkerd v1 de Buoyant cesó hace mucho tiempo, nuestras menciones de "Linkerd" en el resto de este artículo se refieren a v2.

Linkerd, totalmente de código abierto, se basa en un proxy casero escrito en Rust para el plano de datos y en el código fuente escrito en Go para el plano de control.

Conectividad

Los proxies de Linkerd tienen funciones de reintento y tiempo de espera, pero no tienen interrupción de circuito ni inyección de demora a partir de este escrito. El soporte de ingreso es extenso; Linkerd cuenta con integración con los siguientes controladores de entrada:

• Traefik
• Nginx
• CME
• Embajador
• gloo
• Contorno
• Kong

Los perfiles de servicio en Linkerd ofrecen capacidades de enrutamiento mejoradas, brindando al usuario métricas, ajuste de reintentos y configuraciones de tiempo de espera, todo por ruta. En cuanto al balanceo de carga, Linkerd ofrece inyección automática de proxy, su propio tablero y soporte nativo para Grafana.

Seguridad

El soporte de mTLS en Linkerd es conveniente porque su configuración inicial es automática, al igual que su rotación diaria automática de claves.

Observabilidad

Fuera de la caja, las estadísticas y rutas de Linkerd se pueden observar a través de una CLI. En el lado de la GUI, las opciones incluyen tableros Grafana prefabricados y un tablero Linkerd nativo.

Linkerd puede conectarse a una instancia de Prometheus.

El seguimiento se puede habilitar a través de un complemento con OpenTelemetry (anteriormente OpenCensus) como recopilador y Jaeger haciendo el seguimiento por sí mismo.

Instalación

La instalación de Linkerd se realiza inyectando un proxy sidecar, que se realiza agregando una anotación a sus recursos en Kubernetes. Hay dos maneras de hacer esto:

1. Usando un gráfico de Helm. (Para muchos, Helm es el administrador de plantillas y configuración de referencia para los recursos de Kubernetes).
2. Instalar la CLI de Linkerd y luego usarla para instalar Linkerd en un clúster.

El segundo método comienza con la descarga y ejecución de un script de instalación:

 curl -sL https://run.linkerd.io/install | sh

A partir de ahí, la herramienta Linkerd CLI linkerd proporciona un conjunto de herramientas útil que ayuda a instalar el resto de Linkerd e interactuar con el clúster de aplicaciones y el plano de control.

linkerd check --pre ejecutará todas las comprobaciones preliminares necesarias para su instalación de Linkerd, proporcionando registros claros y precisos sobre por qué una posible instalación de Linkerd podría no funcionar todavía. Sin --pre , este comando se puede usar para la depuración posterior a la instalación.

El siguiente paso es instalar Linkerd en el clúster ejecutando:

 linkerd install | kubectl apply -f -

Linkerd luego instalará muchos componentes diferentes con una huella de recursos muy pequeña; por lo tanto, ellos mismos tienen un enfoque de microservicios:

• linkerd-controller , que proporciona la API pública con la que interactúan la CLI y el panel
• linkerd-identity , que proporciona la autoridad de certificación para implementar mTLS
• linkerd-proxy-injector , que maneja la inyección del proxy mutando la configuración de un pod
• linkerd-web , que sirve un tablero que permite el monitoreo de implementaciones y pods, así como componentes internos de Linkerd

Linkerd basa la mayor parte de su configuración en CustomResourceDefinitions (CRD). Esta se considera la mejor práctica al desarrollar software complementario de Kubernetes: es como instalar un complemento de forma duradera en un clúster de Kubernetes.

Agregar seguimiento distribuido, que puede o no ser lo que los usuarios de Linkerd realmente buscan, debido a algunos mitos comunes, requiere otro paso con linkerd-collector y linkerd-jaeger. Para eso, primero crearíamos un archivo de configuración:

 cat >> config.yaml << EOF tracing: enabled: true EOF

Para habilitar el rastreo, ejecutaríamos:

 linkerd upgrade --config config.yaml | kubectl apply -f -

Al igual que con cualquier red de servicios basada en proxies sidecar, deberá modificar el código de su aplicación para habilitar el seguimiento. La mayor parte de esto es simplemente agregar una biblioteca de cliente para propagar encabezados de seguimiento; luego debe incluirse en cada servicio.

La función de división de tráfico de Linkerd, expuesta a través de su API compatible con Service Mesh Interface (SMI), ya permite versiones canary. Pero para automatizarlos y gestionar el tráfico, también necesitará herramientas externas como Flagger.

Flagger es una herramienta de entrega progresiva que evaluará lo que Linkerd llama las métricas "doradas" : "volumen de solicitudes, tasa de éxito y distribuciones de latencia". (Originalmente, los SRE de Google usaban el término señales doradas e incluían una cuarta, saturación, pero Linkerd no lo cubre porque eso requeriría métricas a las que no se puede acceder directamente, como el uso de CPU y memoria). Flagger las rastrea mientras divide el tráfico usando un circuito de retroalimentación; por lo tanto, puede implementar lanzamientos controlados automatizados y con métricas.

Después de profundizar en el proceso de instalación, queda claro que para tener una malla de servicios de Linkerd operativa y explotar las capacidades comúnmente deseadas, es fácil terminar con al menos una docena de servicios en ejecución. Dicho esto, Linkerd suministra más de ellos en el momento de la instalación que con otras mallas de servicio.

Resumen de la red de servicios de Linkerd

ventajas:

Linkerd se beneficia de la experiencia de sus creadores, dos ex-ingenieros de Twitter que trabajaron en la herramienta interna, Finagle, y luego aprendieron de Linkerd v1. Como una de las primeras redes de servicios, Linkerd tiene una comunidad próspera (su Slack tiene más de 5000 usuarios, además tiene una lista de correo activa y un servidor Discord) y un amplio conjunto de documentación y tutoriales. Linkerd está maduro con el lanzamiento de la versión 2.9, como lo demuestra su adopción por parte de grandes corporaciones como Nordstrom, eBay, Strava, Expedia y Subspace. El soporte de pago de nivel empresarial de Buoyant está disponible para Linkerd.

Inconvenientes:

Hay una curva de aprendizaje bastante fuerte para usar las mallas de servicios de Linkerd en todo su potencial. Linkerd solo es compatible con los contenedores de Kubernetes (es decir, no hay un modo "universal" basado en VM). El proxy sidecar de Linkerd no es Envoy. Si bien esto permite que Buoyant lo ajuste como mejor le parezca, elimina la extensibilidad inherente que ofrece Envoy. También significa que a Linkerd le falta soporte para interrupción de circuitos, inyección de retardo y limitación de velocidad. No se expone ninguna API en particular para controlar fácilmente el plano de control de Linkerd. (Sin embargo, puede encontrar el enlace de la API de gRPC).

Linkerd ha hecho un gran progreso desde v1 en su usabilidad y facilidad de instalación. La falta de una API expuesta oficialmente es una omisión notable. Pero gracias a la documentación bien pensada, la funcionalidad lista para usar en Linkerd es fácil de probar.

Revisión de Consul Connect

Nuestro próximo competidor de malla de servicios, Consul Connect, es un híbrido único. Consul de HashiCorp es más conocido por su almacenamiento de valor clave para arquitecturas distribuidas, que existe desde hace muchos años. Después de la evolución de Consul a un conjunto completo de herramientas de servicio, HashiCorp decidió construir una red de servicios encima: Consul Connect.

Para ser precisos sobre su naturaleza híbrida:

El plano de datos de Consul Connect se basa en Envoy, que está escrito en C++. El plano de control de Consul Connect está escrito en Go. Esta es la parte respaldada por Consul KV, una tienda de clave-valor.

Como la mayoría de las otras mallas de servicios, Consul Connect funciona inyectando un proxy sidecar dentro de su módulo de aplicaciones. En términos de arquitectura, Consul Connect se basa en agentes y servidores . Fuera de la caja, Consul Connect está diseñado para tener alta disponibilidad (HA) utilizando tres o cinco servidores como un StatefulSet que especifica la antiafinidad del pod. La antiafinidad de pods es la práctica de asegurarse de que los pods de un sistema de software distribuido no terminen en el mismo nodo (servidor), lo que garantiza la disponibilidad en caso de que falle un solo nodo.

Conectividad

No hay mucho que haga que Consul Connect se destaque en esta área; proporciona lo que hace cualquier red de servicios (que es bastante), además de funciones de capa siete para el enrutamiento basado en rutas, el cambio de tráfico y el equilibrio de carga.

Seguridad

Al igual que con las otras mallas de servicio, Consul Connect proporciona capacidades básicas de mTLS. También cuenta con integración nativa entre Consul y Vault (también de HashiCorp), que se puede usar como proveedor de CA para administrar y firmar certificados en un clúster.

Observabilidad

Consul Connect adopta el enfoque de observabilidad más común al incorporar Envoy como un proxy sidecar para proporcionar capacidades de capa siete. Configurar la interfaz de usuario de Consul Connect para obtener métricas implica cambiar un archivo de configuración integrado y también habilitar un proveedor de métricas como Prometheus. También es posible configurar algunos paneles de Grafana para mostrar métricas relevantes específicas del servicio.

Instalación

Consul Connect se instala en un clúster de Kubernetes mediante un gráfico de Helm:

 helm repo add hashicorp https://helm.releases.hashicorp.com

Deberá modificar los values.yaml predeterminados.yaml si desea habilitar la interfaz de usuario o hacer que el módulo Consul Connect inyecte su proxy sidecar:

 helm install -f consul-values.yml hashicorp hashicorp/consul

Para consultar a los miembros y verificar los distintos nodos, Consul recomienda exec en uno de los contenedores y luego usar la herramienta CLI consul .

Para servir la interfaz de usuario web lista para usar que proporciona Consul, ejecute kubectl port-forward service/hashicorp-consul-ui 18500:80 .

Resumen de malla de servicios de Consul Connect

ventajas:

• Consul está respaldado por HashiCorp; como producto freemium, también hay una versión empresarial con funciones adicionales que ofrece soporte de nivel empresarial. En términos de experiencia del equipo de desarrollo, Consul es una de las herramientas más antiguas del mercado.
• Consul tiene una comunidad empresarial sólida y se sabe que se ejecuta en una infraestructura con 50 000 nodos. Además, existe desde 2014, lo que lo convierte en un producto maduro en relación con el mercado.
• Consul Connect funciona bien dentro de una VM, gracias al soporte nativo.
• Con Consul Connect, es posible lograr integraciones de aplicaciones tan profundas como las implementaciones de malla previas al servicio en empresas tecnológicas de primer nivel. Esto es gracias a la exposición de una API de nivel de biblioteca totalmente documentada.

Inconvenientes:

• Consul Connect tiene una curva de aprendizaje más pronunciada que las otras mallas de servicios y necesitará más ajustes para ejecutar métricas y paneles visuales.
• La documentación de HashiCorp no es sencilla, lo que deja a los usuarios cavar y experimentar para configurarla correctamente.
• La documentación de gestión de tráfico es difícil de encontrar y consiste principalmente en enlaces a la documentación de Envoy, que no proporciona detalles sobre la gestión de tráfico de Consul Connect en particular.
• La interfaz SMI de Consul Connect aún es experimental.

Consul Connect puede ser una muy buena opción para aquellos que buscan un producto de nivel empresarial. HashiCorp es conocida por la calidad de sus productos y Consul Connect no es una excepción. Puedo ver dos fuertes ventajas aquí en comparación con otras redes de servicios: un fuerte soporte de la empresa con la versión empresarial y una herramienta lista para todo tipo de arquitecturas (no solo Kubernetes).

Reseña de Istio

En mayo de 2017, Google, IBM y Lyft anunciaron Istio. Cuando Istio entró en la carrera de las herramientas de malla de servicio, obtuvo una muy buena exposición en el espacio tecnológico. Sus autores han agregado funciones basadas en los comentarios de los usuarios hasta la versión 1.9.

Istio prometió nuevas características importantes sobre sus competidores en ese momento: balanceo de carga automático, inyección de fallas y muchas más. Esto ganó mucha atención de la comunidad, pero como detallaremos a continuación, usar Istio está lejos de ser trivial: Istio ha sido reconocido como particularmente complejo para poner en producción.

Históricamente, el proyecto Istio ha dado vueltas con frecuencia en términos de cambios en el código fuente. Una vez que adoptó una arquitectura de microservicio para el plano de control, Istio ahora (desde la versión 1.5) ha regresado a una arquitectura monolítica. La justificación de Istio para volver a la centralización fue que los microservicios eran difíciles de monitorear para los operadores, la base de código era demasiado redundante y el proyecto había alcanzado la madurez organizacional: ya no necesitaba tener muchos equipos pequeños trabajando en silos.

Sin embargo, en el camino, Istio ganó notoriedad por tener uno de los mayores volúmenes de problemas abiertos de GitHub. En el momento de escribir este artículo, el recuento asciende a unos 800 temas abiertos y unos 12.000 cerrados. Si bien los recuentos de problemas pueden ser engañosos, en este caso representan una mejora significativa en términos de funciones previamente rotas y uso de recursos fuera de control.

Conectividad

Istio es bastante fuerte en la gestión del tráfico en comparación con Consul Connect y Linkerd. Esto se debe a una amplia oferta de subcaracterísticas: enrutamiento de solicitudes, inyección de fallas, cambio de tráfico, tiempos de espera de solicitudes, ruptura de circuitos y control del tráfico de entrada y salida a la red de servicios. La noción de servicios virtuales y reglas de destino lo hace muy completo en términos de gestión de tráfico.

Sin embargo, todas esas posibilidades vienen con una curva de aprendizaje, además de la gestión de esos nuevos recursos en su clúster de Kubernetes.

Seguridad

Istio cuenta con un conjunto completo de herramientas relacionadas con la seguridad, con dos ejes principales: autenticación y autorización. Istio puede aplicar diferentes niveles de políticas en distintos ámbitos: específico de la carga de trabajo, en todo el espacio de nombres o en toda la malla. Todos estos recursos de seguridad se administran a través de CRD de Istio, como AuthorizationPolicy o PeerAuthentication .

Más allá de la compatibilidad con mTLS estándar, Istio también se puede configurar para aceptar o rechazar tráfico sin cifrar.

Observabilidad

Aquí, Istio es bastante avanzado, con varios tipos de telemetría que ofrecen información sólida sobre la red de servicios. Las métricas se basan en las cuatro señales doradas (latencia, tráfico, errores y, hasta cierto punto, saturación).

En particular, Istio proporciona métricas para el propio plano de control. También sirve seguimientos distribuidos y registros de acceso, con compatibilidad explícita con Jaeger, Lightstep y Zipkin para habilitar el seguimiento.

No hay un tablero nativo, pero hay soporte oficial para la consola de administración de Kiali.

Instalación

La instalación es tan sencilla como seguir los pasos oficiales. Istio también está integrado de forma nativa en GKE como una función beta, pero GKE usa Istio 1.4.X, la versión anterior de microservicios en lugar de la última versión monolítica.

Una instalación nativa comienza con la descarga de la última versión:

 curl -L https://istio.io/downloadIstio | sh -

Después de hacer cd en la carpeta istio-* recién creada, puede agregarla a su ruta para poder usar la herramienta de utilidad istioctl :

 export PATH=$PWD/bin:$PATH

Desde allí, puede instalar Istio en su clúster de Kubernetes a través istioctl :

 istioctl install

Esto instalará Istio con un perfil default . Los perfiles de istioctl le permiten crear diferentes configuraciones de instalación y cambiar entre ellas si es necesario. Pero incluso en un escenario de un solo perfil, puede personalizar profundamente la instalación de Istio modificando algunos CRD.

Los recursos de Istio serán más difíciles de administrar, ya que necesitará administrar varios tipos de CRD ( VirtualService , DestinationRule y Gateway como mínimo) para asegurarse de que la administración del tráfico esté en su lugar.

• Un recurso VirtualService es una configuración que declara un servicio y las diferentes reglas de enrutamiento que se aplican a las solicitudes.
• Un recurso DestinationRule se utiliza para agrupar y aplicar políticas de tráfico específicas de destino.
• Se crea un recurso de Gateway de enlace para administrar el tráfico de malla de servicio entrante y saliente (es decir, proxies de Envoy adicionales, pero que se ejecutan en el borde en lugar de como sidecars).

Los detalles semánticos están más allá del alcance de esta revisión, pero veamos un ejemplo rápido que muestra cada uno de estos trabajando juntos. Supongamos que tenemos un sitio web de comercio electrónico con un servicio llamado products . Nuestro VirtualService podría verse así:

 apiVersion: networking.istio.io/v1alpha3 kind: VirtualService metadata: name: products-route namespace: ecommerce spec: hosts: - products # interpreted as products.ecommerce.svc.cluster.local http: - match: - uri: prefix: "/listv1" - uri: prefix: "/catalog" rewrite: uri: "/listproducts" route: - destination: host: products # interpreted as products.ecommerce.svc.cluster.local subset: v2 - route: - destination: host: products # interpreted asproducts.ecommerce.svc.cluster.local subset: v1

La regla de DestinationRule correspondiente podría ser:

 apiVersion: networking.istio.io/v1alpha3 kind: DestinationRule metadata: name: products spec: host: products trafficPolicy: loadBalancer: simple: RANDOM # or LEAST_CONN or ROUND_ROBIN subsets: - name: v1 labels: version: v1 - name: v2 labels: version: v2 - name: v3 labels: version: v3

Por último, nuestra Gateway de enlace:

 apiVersion: networking.istio.io/v1alpha3 kind: Gateway metadata: name: cert-manager-gateway namespace: istio-system spec: selector: istio: ingressgateway servers: - port: number: 80 name: http protocol: HTTP hosts: - "*"

Con estos tres archivos en su lugar, una instalación de Istio estaría lista para manejar el tráfico básico.

Resumen de malla de servicios de Istio

ventajas:

• Entre las diferentes mallas de servicios, Istio es la que tiene la comunidad en línea más grande al momento de escribir este artículo. Con más de 10 veces los resultados de Stack Overflow como cualquiera de sus principales competidores, es la red de servicios de la que más se habla en la web; sus colaboradores de GitHub también están un orden de magnitud más allá de los de Linkerd.
• Istio es compatible con los modos Kubernetes y VM; este último está en beta a partir de la versión 1.9.

Inconvenientes:

• Istio no es gratis, en dos sentidos:
  • Sus requisitos son elevados en cuanto al tiempo necesario para leer la documentación, configurarla, hacer que funcione correctamente y mantenerla. Según el tamaño de la infraestructura y la cantidad de servicios, Istio requerirá de varias semanas a varios meses de trabajo a tiempo completo para que sea completamente funcional e integrado en la producción.
  • También agrega una cantidad significativa de sobrecarga de recursos: se necesitarán 350 milicores (mCPU) para el contenedor Envoy por cada 1000 solicitudes por segundo (RPS). Incluso el propio plano de control puede consumir muchos recursos. (Anteriormente, el uso de recursos sería difícil de predecir, pero después de algunos esfuerzos, istiod se ha estabilizado usando 1 vCPU y 1,5 GB de memoria).
• No tiene un panel de administración nativo, a diferencia de Linkerd.
• Istio requiere el uso de su propia puerta de enlace de ingreso.
• El plano de control de Istio solo se admite dentro de los contenedores de Kubernetes (es decir, no hay modo de máquina virtual, a diferencia del plano de datos de Istio).

Istio es un gran ejemplo de gigantes tecnológicos que se unen para crear un proyecto de código abierto para abordar un desafío que todos enfrentan. Tomó algún tiempo para que el proyecto Istio en su conjunto se estructurara (recordando el cambio de arquitectura de microservicios a monolito) y resolviera sus muchos problemas iniciales. En la actualidad, Istio está haciendo absolutamente todo lo que uno esperaría de una red de servicios y puede ampliarse considerablemente. Pero todas estas posibilidades vienen con requisitos estrictos en términos de conocimiento, horas de trabajo y recursos informáticos para respaldar su uso en un entorno de producción.

Revisión rápida de Kuma

Creado por Kong y luego de código abierto, Kuma alcanzó la versión 1.0 a fines de 2020. Hasta cierto punto, se creó en respuesta a que las primeras mallas de servicio eran bastante pesadas y difíciles de operar.

Su lista de características sugiere que sea muy modular; la idea detrás de Kuma es orientarlo hacia la integración con aplicaciones que ya se ejecutan en Kubernetes u otra infraestructura.

• En el área de la gestión del tráfico , Kuma ofrece funciones comunes de malla de servicios, como inyección de fallas y ruptura de circuitos.
• Más allá del cifrado mTLS entre servicios, los intercambios entre el plano de datos y el plano de control están protegidos en Kuma a través de un token de proxy de plano de datos .
• La observabilidad se define en Kuma a través de diferentes políticas de tráfico en torno a métricas, seguimiento y registro.
• El descubrimiento de servicios está disponible a través de Kuma gracias a su propia resolución de DNS que se ejecuta en el puerto 5653 del plano de control.
• Kuma tiene un fuerte énfasis en la funcionalidad multimalla : puede combinar fácilmente varios clústeres de Kubernetes o entornos de VM en un clúster de Kuma común con su tipo de implementación multizona.
• Kuma se integra fácilmente con Kong Gateway para los usuarios de Kong existentes.

La versión universal (no Kubernetes) de Kuma requiere PostgreSQL como una dependencia, y el CTO de Kong ha estado notablemente en contra de admitir SMI. Pero Kuma se desarrolló con la idea de implementaciones multinube y multiclúster desde el principio, y su tablero lo refleja.

Si bien Kuma aún es joven en el espacio de la red de servicios, con pocos casos de uso en producción hasta el momento, es un competidor interesante y prometedor.

Revisión rápida de la malla Traefik

Originalmente llamado Maesh, Traefik Mesh (de Traefik Labs) es otro recién llegado en la carrera de herramientas de malla de servicio. La misión del proyecto es democratizar la red de servicios haciéndola fácil de usar y configurar; la experiencia de los desarrolladores con Traefik Proxy bien pensado los colocó en una posición privilegiada para lograrlo.

• Las funciones de gestión del tráfico en Traefik Mesh incluyen interrupción de circuitos y limitación de velocidad.
• En términos de observabilidad , Traefik Mesh presenta compatibilidad nativa con OpenTracing y métricas listas para usar (la instalación estándar incluye automáticamente Prometheus y Grafana), lo que ahorra tiempo de configuración.
• Por seguridad, además de mTLS, las especificaciones son compatibles con SMI y Traefik Mesh permite el ajuste fino de los permisos de tráfico a través del control de acceso.

Traefik Mesh necesita que CoreDNS esté instalado en el clúster. (Aunque Azure ha usado CoreDNS de forma predeterminada desde 1.12, GKE tiene como valor predeterminado kube-dns a partir de este escrito, lo que significa que hay un paso adicional significativo involucrado en ese caso). También carece de capacidades de múltiples clústeres.

Dicho esto, Traefik Mesh es único dentro de nuestra comparación de mallas de servicio en el sentido de que no utiliza inyección de sidecar. En su lugar, se implementa como un DaemonSet en todos los nodos para actuar como un proxy entre los servicios, lo que lo hace no invasivo. En general, Traefik Mesh es fácil de instalar y usar.

Revisión rápida de AWS App Mesh

En el mundo de los proveedores de la nube, AWS es el primero en implementar una malla de servicios nativa conectable con Kubernetes (o EKS en particular), pero también con sus otros servicios. AWS App Mesh se lanzó en noviembre de 2018 y AWS lo ha estado iterando desde entonces. La principal ventaja de AWS App Mesh es el ecosistema de AWS preexistente y su posición en el mercado; la gran comunidad detrás de AWS en general continuará impulsando su uso y facilidad de uso.

• La administración del tráfico en AWS App Mesh incluye ruptura de circuitos además de características comunes.
• Since AWS App Mesh is hosted by AWS, it's a fully managed service , which means not having to worry about resource usage or control plane availability.
• Observability in AWS App Mesh can be done through Prometheus or AWS X-Ray.

The project is not open source, doesn't support SMI, and there's not much info online about HA standards for the control plane. AWS App Mesh is more complex to set up than other Kubernetes-native service meshes and has very little community online (24 answers on Stack Overflow, 400 stars on GitHub) but that's because users are meant to benefit from AWS support.

AWS App Mesh has native integration with AWS, starting with EKS and extending to other AWS services like ECS (Fargate) and EC2. Unlike Traefik Mesh, it has multicluster support. Plus, like most service meshes, it's based on injecting Envoy, the battle-tested sidecar proxy.

Kubernetes Service Mesh Comparison Tables

The six Kubernetes service mesh options presented here have a few things in common:

• Protocol support : They all work with HTTP, HTTP/2, gRPC, TCP, and WebSockets.
• They all have basic security in the form of mTLS between proxies by default.
• Service meshes, by design, provide some form of load balancing .
• These six, at least, also include a request retrying option among their traffic management features.
• Lastly, service discovery is a core feature of any service mesh.

But there are certainly differences worth highlighting when it comes to service mesh infrastructure, traffic management, observability, deployment, and other aspects.

Infraestructura

Traffic Management

Observability

* OpenCensus and OpenTracing merged into OpenTelemetry in 2019, but you might find Linkerd articles referring to OpenCensus, as well as Istio and Traefik Mesh articles referring to OpenTracing.

Despliegue

Other Service Mesh Considerations

Should We Use a Kubernetes Service Mesh?

Now that we have seen what service meshes are, how they work, and the multitude of differences between them, we can ask: Do we need a service mesh?

That's the big question for SREs and cloud engineers these past few years. Indeed, microservices bring operational challenges in network communication that a service mesh can solve. But service meshes, for the most part, bring their own challenges when it comes to installation and operation.

One problem we can see emerging in many projects is that with service meshes, there is a gap between the proof-of-concept stage and the production stage. That is, it's unfortunately rare for companies to achieve staging environments that are identical to production in every aspect; with service meshes involving crucial infrastructure, scale- and edge-related effects can bring deployment surprises.

Service meshes are still under heavy development and improvement. This could actually be attractive for teams with high deployment velocities—those who have mastered “the art of staying state-of-the-art” and can closely follow the development cycle of cloud-native tools.

For others, though, the pace of service mesh evolution could be more of a pitfall. It would be easy enough to set up a service mesh but then forget about the need to maintain it. Security patches may go unapplied or, even if remembered, may carry with them unplanned issues in the form of deprecated features or a modified set of dependencies.

There's also a notable cost in terms of manpower to set up a service mesh in production. It would be a sensible goal for any team to evaluate this and understand if the benefits from a service mesh would outweigh the initial setup time. Service meshes are hard, no matter what the “easy” demo installations show.

In short, service meshes can solve some of the problems typical to projects deployed at scale but may introduce others, so be prepared to invest time and energy. In a hypothetical infrastructure involving 25 microservices and load of five queries per second, I would recommend having at least one person (preferably two) dedicated for at least a month to preparing a proof of concept and validating key aspects before thinking about running it in production. Once it's set up, anticipate the need for frequent upgrades—they will impact a core component of your infrastructure, namely network communications.

Kubernetes Service Meshes: A (Complex) Evolution in Scalable App Architecture

We've seen what service meshes are: a suite of tooling to answer new challenges introduced by microservices architecture. Through traffic management, observability, service discovery, and enhanced security, service meshes can reveal deep insights into app infrastructure.

There are multiple actors on the market, sometimes promoted by GAFAM et al., that have in some cases open-sourced or promoted their own internal tooling. Despite two different implementation types, service meshes will always have a control plane—the brain of the system—and a data plane, made of proxies that will intercept the requests of your application.

Reviewing the three biggest service meshes (Linkerd, Consul Connect, and Istio) we have seen the different strategies they've chosen to implement and the advantages they bring. Linkerd, being the oldest service mesh on the market, benefits from its creators' experience at Twitter. HashiCorp, for its part, offers the enterprise-ready Consul Connect, backed by a high level of expertise and support. Istio, which initially garnered ample attention online, has evolved into a mature project, delivering a feature-complete platform in the end.

But these actors are far from being the only ones, and some less-talked-about service meshes have emerged: Kuma, Traefik Mesh, and AWS App Mesh, among others. Kuma, from Kong, was created with the idea of making the service mesh idea “simple” and pluggable into any system, not just Kubernetes. Traefik Mesh benefited from experience with the preexisting Traefik Proxy and made the rare decision to eschew sidecar proxies. Last but not least, AWS decided to develop its own version of the service mesh, but one that relies on the dependable Envoy sidecar proxy.

In practice, service meshes are still hard to implement. Although service mesh benefits are compelling, their impact, critically, cuts both ways: Failure of a service mesh could render your microservices unable to communicate with each other, possibly bringing down your entire stack. A notorious example of this: Incompatibility between a Linkerd version and a Kubernetes version created a complete production outage at Monzo, an online bank.

Nonetheless, the whole industry is structuring itself around Kubernetes and initiatives like the Microsoft-spearheaded SMI, a standard interface for service meshes on Kubernetes. Among numerous other projects, the Cloud Native Computing Foundation (CNCF) has the Envoy-based Open Service Mesh (OSM) initiative, which was also originally introduced by Microsoft. The service mesh ecosystem remains abuzz, and I predict a champion emerging in the coming years, the same way Kubernetes became the de facto container orchestration tool.