Malla de servicio: control de tráfico de Istio (Parte 2)
Artículo anterior:
Conceptos básicos de Ingress:
Implemente el servicio httpbin. De manera similar, la demostración oficial ha proporcionado este archivo de configuración. Simplemente ejecute el siguiente comando. para aplicar:
Configure la puerta de enlace de Ingress para el servicio httpbin y defina la puerta de enlace de Ingress de la siguiente manera:
Luego defina las reglas de enrutamiento de configuración del Servicio Virtual y asocie la puerta de enlace:
Utilice el siguiente comando para obtener la dirección de solicitud real y el número de puerto del servicio istio-ingressgateway (pero este método se utiliza cuando la IP EXTERNA del servicio está pendiente o no existe, consulte: documentación oficial para obtener más detalles):
A continuación, use el comando curl para probar si se puede acceder normalmente a la interfaz httpbin:
Acceder a una interfaz que no está expuesta devolverá 404:
Si hay tráfico que ingresa a la red, también habrá tráfico que sale de la red. Este tráfico de entrada y salida es lo que a menudo llamamos tráfico norte-sur. En Istio, podemos controlar el tráfico de entrada y salida de la red.
Métodos para acceder a servicios externos en Istio:
Concepto de salida:
En esta sección, practicaremos la creación de una puerta de enlace de salida para permitir servicios internos (suspensión). Acceda a servicios externos (httpbin.org) a través de él. Ambos servicios se han demostrado en los ejemplos del capítulo anterior:
Compruebe si el componente istio-egressgateway existe:
Confirme que el servicio de suspensión está. ya se está ejecutando normalmente:
Defina ServiceEntry para el servicio externo httpbin.org:
Confirme que la creación se realizó correctamente:
Defina la puerta de enlace de salida:
Defina la ruta y dirija el tráfico a istio-egressgateway:
Pruebe la interfaz para acceder al servicio httpbin.org:
Verifique el registro para verificar si el tráfico de salida pasa a través de la puerta de enlace de salida, salida La siguiente información de registro indica que la puerta de enlace de salida se configuró correctamente y que el tráfico de salida pasa a través de la puerta de enlace de salida:
En este momento, el proceso de acceso del servicio de suspensión a servicios externos es el siguiente: siguiente:
Para un sistema distribuido Se dice que las fallas de la red son inevitables, por lo que cómo mejorar la flexibilidad del sistema y mejorar las capacidades de procesamiento del sistema frente a fallas es un tema muy importante en la arquitectura distribuida. Entre ellos, el tiempo de espera y el reintento son mecanismos muy importantes y comúnmente utilizados para mejorar la resiliencia del sistema.
Conceptos básicos
A continuación, usaremos la aplicación Bookinfo como demostración para agregar estrategias de tiempo de espera y estrategias de reintento a algunos de los servicios.
Apuntaremos la solicitud a la versión v2 del servicio de revisiones y agregaremos configuraciones de retraso al servicio de calificaciones para simular una falla y verificar si las estrategias de tiempo de espera y reintento que configuramos son efectivas:
Primero, cree un Servicio para enrutar solicitudes a la versión v2 del servicio de revisiones:
Inyectar retrasos en el servicio de calificaciones y simular fallas:
Agregar una política de tiempo de espera al servicio de revisiones:
Actualice la página de la aplicación en este momento y podrá ver que aparece el mensaje de error:
Cancele la política de tiempo de espera del servicio de revisiones y luego agregue una política de reintento al servicio de calificaciones:
Ver el registro de Service Sidecar de calificaciones y luego actualizar la página de la aplicación. En circunstancias normales, puede ver en el resultado del registro que la solicitud se volvió a intentar dos veces:
Opciones de configuración:
¿Qué es un disyuntor (Circuit Breaking))?
En esta sección, practicaremos cómo agregar una configuración de disyuntor al servicio httpbin y luego activaremos el fusible a través de la herramienta de prueba de carga. La configuración relacionada con el disyuntor se configura en la regla de destino del servicio, como se muestra a continuación:
Instale fortio y use la herramienta de prueba de carga para activar el disyuntor:
Primero intente enviar una sola solicitud, confirme que la herramienta puede funcionar normalmente:
Después de que no haya ningún problema, use el siguiente comando para realizar una prueba de estrés concurrente. El número de concurrencia es 3 y se ejecuta 30 veces:
Si desea ver indicadores específicos, puede utilizar el siguiente comando:
Opciones de configuración:
Comprender la inyección de fallas:
Después de configurar el red (incluida la estrategia de recuperación de fallas), podemos usar el mecanismo de inyección de fallas de Istio para probar la capacidad general de recuperación de fallas de la aplicación. La inyección de fallas es un método de prueba que introduce errores en un sistema para garantizar que el sistema pueda resistir y recuperarse de condiciones de error.
Por lo tanto, el mecanismo de inyección de fallas es particularmente útil. Puede exponer de antemano algunos problemas en los que la estrategia de recuperación de fallas es incompatible o demasiado restrictiva, lo que puede conducir a la indisponibilidad de servicios críticos.
Ejemplos del desarrollo y aplicación de la inyección de fallas en la industria:
De hecho, ya hemos demostrado la configuración de inyección de fallas de Istio en la sección anterior, en la sección sobre tiempo de espera y reintento, la hemos inyectado. en el servicio de calificaciones Una falla de retraso:
Utilice los siguientes comandos para configurar la información de enrutamiento de cada servicio de la aplicación Bookinfo a sus respectivas versiones v1:
Luego apunte el tráfico de. el servicio de revisiones a su versión v2, porque solo las versiones v2 y v3 llamarán al servicio de calificaciones:
Inyecte falla de retraso en el servicio de calificaciones:
Contenido del servicio-virtual- Archivo ratings-test-delay.yaml:
Opciones de configuración:
Creo que muchos desarrolladores han encontrado un problema de este tipo, es decir, una función que se ejecuta bien en el entorno de desarrollo/prueba. tiene problemas tan pronto como se conecta. Incluso si ha realizado suficientes pruebas unitarias y de integración y la cobertura de la prueba es muy alta, este tipo de problema seguirá existiendo y es difícil de reproducir en el entorno de desarrollo/prueba.
Una de las principales razones de este problema es que el entorno en línea, especialmente el entorno de datos, como la cantidad de datos, la cantidad de solicitudes simultáneas y la forma en que los usuarios usan los datos, son muy diferentes del entorno en línea. El entorno de desarrollo/pruebas no es el mismo. Debido a esta inconsistencia, nos resulta difícil encontrar problemas en línea en el entorno de desarrollo/prueba.
Entonces, una muy buena solución es utilizar el mecanismo de duplicación de tráfico para copiar el tráfico en línea al entorno de desarrollo/prueba para realizar pruebas.
Comprenda la duplicación de tráfico:
La duplicación de tráfico (también conocida como sombreado) es un concepto poderoso que permite a los equipos de desarrollo introducir cambios en el entorno de producción. Un mecanismo de duplicación de tráfico envía una copia del tráfico en vivo a un servicio de duplicación. La duplicación del tráfico se produce fuera de la ruta de solicitud crítica del servicio principal.
A continuación, practiquemos cómo configurar el mecanismo de duplicación de tráfico en Istio. El requisito es reflejar el tráfico enviado a la versión v1 a la versión v2. Por lo tanto, primero implementamos las versiones v1 y v2 del servicio httpbin.
La configuración de la versión v1 es la siguiente:
Implemente la versión v2 del servicio httpbin:
Cree un recurso de servicio para httpbin para que el Pod pueda exponerse a través del servicio:
Cree un servicio virtual predeterminado y una regla de destino para el servicio httpbin:
Pruebe si se puede acceder normalmente a la interfaz del servicio httpbin:
Después de completar el En los preparativos anteriores, podemos en el servicio virtual configurar la duplicación del tráfico de la versión v1 para la versión v2 del servicio httpbin:
Intente solicitar la interfaz del servicio httpbin ya que hemos configurado las reglas de enrutamiento. , la solicitud debe enrutarse a la versión v1:
En este momento, observe el registro de la versión v2. En la salida del registro, puede encontrar que la versión v2 también recibió la misma solicitud. significa que nuestra configuración de duplicación de tráfico ha entrado en vigor:
Opciones de configuración: