El término service mesh se utiliza para describir la red de microservicios que componen dichas aplicaciones y las interacciones entre ellas. A medida que una malla de servicios crece en tamaño y complejidad, puede volverse más difícil de entender y administrar. Sus requisitos pueden incluir descubrimiento, equilibrio de carga, recuperación de fallas, métricas y monitoreo. Una malla de servicios también suele tener requisitos operativos más complejos, como pruebas A / B, implementaciones de Canary, limitación de velocidad, control de acceso y autenticación de un extremo a otro.
Istio proporciona conocimientos de comportamiento y control operativo sobre la malla de servicios en su conjunto, ofreciendo una solución completa para satisfacer los diversos requisitos de las aplicaciones de microservicio. A medida que las organizaciones adoptan cada vez más plataformas en la nube, los desarrolladores deben diseñar la portabilidad utilizando servicios, mientras que los operadores deben administrar grandes implementaciones distribuidas que abarcan implementaciones híbridas y de múltiples nubes. Istio reduce la complejidad de la gestión de implementaciones de servicios al proporcionar una forma uniforme de proteger, conectar y supervisar microservicios, incluso en todos los entornos.
¿Por qué usar Istio?
- Equilibrio de carga automático para tráfico HTTP, gRPC, WebSocket y TCP.
- Control detallado del comportamiento del tráfico con reglas de enrutamiento enriquecidas, reintentos, conmutaciones por error e inyección de errores.
- Una capa de políticas conectable y una API de configuración que admite controles de acceso, límites de velocidad y cuotas.
- Métricas, registros y seguimientos automáticos para todo el tráfico dentro de un clúster, incluida la entrada y salida del clúster.
- Comunicación segura de servicio a servicio en un clúster con autenticación y autorización sólidas basadas en identidad.
Caracteristicas
- La gestión del tráfico
- Seguridad
- Observabilidad
- Soporte de plataforma
- Integración y personalización
- Arquitectura
¿Cómo se comunicarán los servicios entre clústeres, regiones y entornos?
Para aplicaciones de hasta cierto tamaño, todos los microservicios que componen la aplicación se pueden ejecutar en una única plataforma de orquestación (por ejemplo, el clúster de Kubernetes). Sin embargo, por muchas razones, como la escalabilidad, la redundancia, el cumplimiento, etc., la mayoría de las aplicaciones eventualmente necesitarán distribuirse y algunos de sus servicios se ejecutarán en otro lugar. Algunas de las razones pueden ser múltiples propietarios de servicios que utilizan sus propios clústeres, requisitos de gobierno de datos que restringen una parte de la lógica empresarial y el procesamiento de datos a una ubicación específica, o mantener la independencia del proveedor mediante la implementación. Una malla de servicios multiclúster es una malla compuesta por servicios que se ejecutan dentro de más de un clúster subyacente, pero con todos los servicios que se ejecutan bajo un único control administrativo.
Panel de control compartido
En esta configuración, un panel de control de Kubernetes, ejecutándose en una configuración remota, se conecta a un solo panel de control de Istio. Una vez que uno o más clústeres de Kubernetes remotos se conectan al panel de control de Istio, los Envoys remotos pueden comunicarse con el panel de control único y formar una única malla de servicios en varios clústeres.
Plano de control múltiple
En lugar de utilizar un panel de control de Istio compartido para administrar la malla, en esta configuración cada clúster tiene su propia instalación del panel de control de Istio, cada uno administrando sus propios endpoints. Todos los clústeres están bajo control administrativo compartido con el propósito de hacer cumplir las políticas y la seguridad.
Se logra una sola malla de servicios de Istio entre los clústeres replicando los servicios compartidos y los espacios de nombres y utilizando una CA raíz común en todos los clústeres. La comunicación entre clústeres se produce a través de los gateways Istio de los respectivos clústeres.
En una configuración de panel de control múltiple, cada clúster tiene su propia instalación de panel de Istio y cada uno gestiona su propia malla de servicio local.
Los Servicios que se ejecutan fuera del clúster se definen mediante nombres DNS que pertenecen a un dominio .global. Los servicios que se ejecutan dentro del clúster de Kubernetes utilizan el nombre DNS que termina en un dominio .local.
Seguridad en toda la malla
Si deseas establecer confianza/seguridad entre los servicios en todos los clústeres, ambos certificados de firma (CA) de Citadel deben estar firmados por una autoridad de certificación raíz común (CA raíz). Las cargas de trabajo también necesitan un archivo de cadena de certificados para verificar la cadena de confianza de todas las CA intermedias entre el certificado de firma (CA) de Citadel y la CA raíz. Esta configuración se realiza mediante un secreto en el clúster de Kubernetes.
Gracias
Gracias por compartir, espero que sea de provecho el contenido. Con Anthos e Instio puedes sufrir menos en temas relacionados con la comunicación de servicios entre clusteres.
Te comparto algunos medios donde regularmente publico y organizo actividades:
Oldest comments (0)