Arquitecturas de microservicios Resuelve algunos problemas pero introduce otros. Dividir las aplicaciones en servicios independientes simplifica el desarrollo, las actualizaciones y el escalado. Pero también le ofrece muchas más piezas móviles para conectar y asegurar. La gestión de todos los servicios de red (equilibrio de carga, gestión del tráfico, autenticación y autorización, etc.) puede volverse tremendamente compleja.
El término para este espacio en red entre los servicios en su Kubernetes el grupo es malla de servicio. Un proyecto de Google, Istio, tiene como objetivo proporcionar una forma de gestionar la malla de servicios de su clúster antes de que se convierta en una maraña de zarzas.
¿Qué es una malla de servicios?
Ciertos comportamientos comunes tienden a surgir en torno a cualquier grupo de aplicaciones en red. Por ejemplo, la necesidad de equilibrar la carga entre instancias de servicio, o poder realizar pruebas A/B de diferentes combinaciones de servicios, o configurar la autenticación de un extremo a otro en cadenas de servicios. Estos comportamientos, y la forma en que se llevan a cabo, se conocen colectivamente como malla de servicio.
La gestión de la red de servicios no debe dejarse en manos de los propios servicios. Ningún servicio por sí solo está en buena posición para hacer algo tan de arriba hacia abajo y, de todos modos, ese no debería ser el trabajo del servicio. Es mejor tener un sistema que se encuentre entre los servicios y la red. Este sistema proporcionaría dos funciones clave: gestión y abstracción.
- Gestión evita que los propios servicios tengan que ocuparse del meollo de la cuestión de gestionar el tráfico de red (cosas como equilibrio de carga, enrutamiento, reintentos, etc.).
- Abstracción proporciona una capa de abstracción para los administradores, lo que facilita la implementación de decisiones de alto nivel sobre el tráfico de red en el clúster: controles de políticas, métricas y registros, descubrimiento de servicios, comunicaciones seguras entre servicios a través de TLS, etc.
Componentes de la malla de servicios de Istio
Istio funciona como una malla de servicios al proporcionar dos piezas básicas de arquitectura para su clúster: un plano de datos y un plano de control.
El plano de datos maneja el tráfico de red entre los servicios en la malla, a través de un grupo de servidores proxy de red. El proxy de Istio se realiza a través de un proyecto de código abierto llamado Enviado.
El plano de controlun servicio llamado Istiodmaneja el descubrimiento y la gestión de servicios. También genera los certificados utilizados para la comunicación segura en el plano de datos.
Istio también proporciona API para controlar estos servicios, que se dividen en varias categorías.
Servicios virtuales
A servicio virtual le permite crear reglas sobre cómo se enruta el tráfico. Cada servicio virtual se puede utilizar para enrutar el tráfico a un servicio real en la malla. Por ejemplo, si está probando A/B dos implementaciones diferentes de una API determinada, podría enrutar la mitad del tráfico a una versión de la API. O podría asignar llamadas a diferentes puntos finales de API en un dominio determinado a diferentes servidores físicos.
Reglas de destino
Reglas de destino controlar lo que sucede con el tráfico después ha sido enrutado a través de un servicio virtual. Por ejemplo, el tráfico que llega a diferentes puertos podría tener diferentes políticas de equilibrio de carga.
Puertas de enlace
Puertas de enlace administre el tráfico dentro y fuera de la malla en su conjunto, con capacidades de equilibrio de carga y controles de protocolo de red L4-L6. También puede vincular un servicio virtual a una puerta de enlace para controlar hacia dónde se dirige el tráfico después de eso.
El servidor web NGINX y el sistema de proxy se pueden utilizar como controlador de ingreso en Istio. De esta manera, las funciones de NGINX para el equilibrio de carga avanzado y el enrutamiento del tráfico se pueden utilizar para enrutar el tráfico a la malla de Istio, incluidas las funciones disponibles solo en NGINX. versión comercial. Si ya está familiarizado con las funciones de enrutamiento de NGINX, puede aprovecharlas en una malla Istio de esta manera.
Entradas de servicio
Entradas de servicio le permite agregar una entrada al registro de servicios conocidos de Istio. Un servicio registrado, como una API externa, se trata como si fuera parte de la malla de Istio, incluso si no lo es.
sidecares
Los proxies de Envoy están configurados de forma predeterminada para permitir el tráfico entrante desde todos los puertos y para permitir el tráfico saliente a todas las demás cargas de trabajo en la malla. Puedes usar un configuración del sidecar para cambiar este comportamiento.
Ese es el modo ambiente.
A relativamente nuevo Característica de Istio, «modo ambiente,» le permite implementar Istio sin ejecutar un proxy Envoy junto con cada pod de aplicaciones de Kubernetes. En cambio, cada nodo del clúster de Kubernetes (en lugar de cada pod de aplicaciones) tiene un agente de Istio, lo que significa menos procesamiento general para el enrutamiento del tráfico. También permite una mayor enfoque de transición para implementar Istio en un clúster de Kubernetes. Sin embargo, tenga en cuenta que el modo ambiente todavía es extremadamente nuevo y aún no se recomienda para uso en producción.
Capacidades de malla de servicios de Istio
El primer y más valioso beneficio que ofrece Istio es abstracción—una forma de mantener las complejidades de una red de servicios a distancia. Puede realizar cualquier cambio en la malla mediante programación ordenando a Istio, en lugar de configurar una gran cantidad de componentes a mano y esperar que los cambios surtan el efecto adecuado. Los servicios conectados a la malla no necesitan ser reprogramados desde adentro para seguir nuevas políticas o cuotas de red, y tampoco es necesario tocar directamente los espacios de red entre ellos.
Istio también te permite realizar cambios no destructivos o tentativos a la configuración de red del clúster. Si desea implementar un nuevo diseño de red, total o parcialmente, o probar A/B la configuración actual con una nueva, Istio le permite hacerlo de arriba hacia abajo. También puede revertir esos cambios si resultan no ser saludables.
Una tercera ventaja es observabilidad. Istio proporciona estadísticas e informes detallados sobre lo que sucede entre los contenedores y los nodos del clúster. Si hay un problema imprevisto, si algo no cumple con la política o si los cambios que realizó resultan contraproducentes, podrá descubrirlo en poco tiempo.
Istio también proporciona formas de cumplir con patrones comunes que se ven en una malla de servicios. Un ejemplo es el patrón de disyuntor, una forma de evitar que un servicio sea bombardeado con solicitudes si el back-end informa problemas y no puede cumplir con las solicitudes de manera oportuna. Istio proporciona un patrón de disyuntor como parte de su biblioteca estándar de aplicación de políticas.
Finalmente, aunque Istio trabaja más directa y profundamente con Kubernetes, está diseñado para ser independiente de la plataforma. Istio se conecta a los mismos estándares abiertos en los que se basa Kubernetes. Istio también puede funcionar de forma independiente en sistemas individuales o en otros sistemas de orquestación como Mesos y Nomad.
Cómo empezar con Istio
Si ya tiene experiencia con Kubernetes, una buena forma de aprender Istio es utilizar un clúster de Kubernetes.no ¡uno ya en producción!—y instale Istio usando su método de implementación preferido. Entonces tú puedes implementar una aplicación de muestra que demuestra características comunes de Istio como la gestión del tráfico y observabilidad. Esto debería brindarle cierta experiencia básica con Istio antes de implementarlo para tareas de malla de servicios en su clúster de aplicaciones.
Red Hat, que ha invertido en Istio como parte del proyecto OpenShift de la empresa impulsado por Kubernetes, ofrece tutoriales que lo guiarán a través de escenarios comunes de implementación y administración de Istio.
Copyright © 2024 IDG Communications, Inc.