Cómo mejorar la resiliencia en Kubernetes con la gestión avanzada del tráfico

Editor : Esta publicación es parte de una serie de 10 partes:

1. Reduzca la complejidad con Kubernetes de nivel de producción
2. Cómo mejorar la resiliencia en Kubernetes con la gestión avanzada del tráfico (esta publicación)
3. Cómo mejorar la visibilidad en Kubernetes
4. Seis formas de proteger Kubernetes mediante herramientas de gestión del tráfico
5. Guía para elegir un controlador de entrada, parte 1: Identifique sus requisitos
6. Guía para elegir un controlador de entrada, parte 2: Riesgos y preparación para el futuro
7. Guía para elegir un controlador de entrada, parte 3: Código abierto vs. Predeterminado vs. Comercial
8. Guía para elegir un controlador de entrada, parte 4: Opciones del controlador de ingreso NGINX
9. Cómo elegir una malla de servicios
10. Pruebas de rendimiento de controladores de ingreso NGINX en un entorno dinámico de nube de Kubernetes

También puede descargar el conjunto completo de blogs como un libro electrónico gratuito: Cómo llevar Kubernetes de la prueba a la producción .

Hay una forma muy fácil de saber que una empresa no está utilizando con éxito las tecnologías modernas de desarrollo de aplicaciones: sus clientes se apresuran a quejarse en las redes sociales. Se quejan cuando no pueden transmitir el último lanzamiento que merece la pena ver. O acceder a la banca en línea. O hacer una compra, porque el carrito está agotando el tiempo.

Incluso si los clientes no se quejan públicamente, eso no significa que su mala experiencia no tenga consecuencias. Uno de nuestros clientes, una gran compañía de seguros, nos dijo que pierden clientes cuando su página de inicio no se carga en 3 segundos .

Todas esas quejas de los usuarios sobre bajo rendimiento o interrupciones apuntan a un culpable común: la resiliencia... o la falta de ella. La belleza de las tecnologías de microservicios, incluidos los contenedores y Kubernetes, es que pueden mejorar significativamente la experiencia del cliente al mejorar la resiliencia de sus aplicaciones. ¿Cómo? Todo es cuestión de arquitectura.

Me gusta explicar la diferencia fundamental entre las arquitecturas monolíticas y de microservicios utilizando la analogía de una cadena de luces navideñas. Cuando se funde una bombilla en una tira de luces de estilo antiguo, toda la tira se oscurece. Si no puedes reemplazar la bombilla, lo único que vale la pena decorar con esa tira es el interior de tu bote de basura. Este viejo estilo de luces es como una aplicación monolítica, que también tiene componentes estrechamente acoplados y falla si se rompe un componente.

Pero la industria de la iluminación, al igual que la industria del software, detectó este problema. Cuando una bombilla se funde en una serie de luces modernas, las demás siguen brillando intensamente, de la misma manera que una aplicación de microservicios bien diseñada sigue funcionando incluso cuando falla una instancia de servicio.

Gestión del tráfico de Kubernetes

Los contenedores son una opción popular en las arquitecturas de microservicios porque son ideales para crear una aplicação utilizando componentes más pequeños y discretos: son livianos, portátiles y fáciles de escalar. Kubernetes es el estándar de facto para la orquestación de contenedores, pero existen muchos desafíos para lograr que Kubernetes esté listo para producción . Un elemento que mejora tanto el control sobre las aplicaciones de Kubernetes como su resiliencia es una estrategia de gestión de tráfico madura que permite controlar servicios en lugar de paquetes y adaptar las reglas de gestión de tráfico dinámicamente o con la API de Kubernetes. Si bien la gestión de tráfico es importante en cualquier arquitectura, para las aplicaciones de alto rendimiento dos herramientas de gestión de tráfico son esenciales: el control de tráfico y la división de tráfico .

Control de tráfico

El control del tráfico (a veces llamado enrutamiento del tráfico o modelado del tráfico ) se refiere al acto de controlar hacia dónde va el tráfico y cómo llega allí. Es una necesidad al ejecutar Kubernetes en producción porque le permite proteger su infraestructura y aplicaciones de ataques y picos de tráfico. Dos técnicas para incorporar a su ciclo de desarrollo de aplicaciones son la limitación de velocidad y la interrupción del circuito .

• CASO DE USO:Quiero proteger los servicios para que no reciban demasiadas solicitudes
  Solución: Limitación de velocidad

  Ya sean maliciosos (por ejemplo, adivinación de contraseñas por fuerza bruta y ataques DDoS) o benignos (como clientes que acuden en masa a una venta), un gran volumen de solicitudes HTTP puede saturar sus servicios y provocar que sus aplicaciones fallen. La limitación de velocidad restringe la cantidad de solicitudes que un usuario puede realizar en un período de tiempo determinado. Las solicitudes pueden incluir algo tan simple como una solicitud GET para la página de inicio de un sitio web o una solicitud POST en un formulario de inicio de sesión. Cuando se sufre un ataque DDoS, por ejemplo, se puede utilizar la limitación de velocidad para limitar la tasa de solicitudes entrantes a un valor típico para usuarios reales.

• CASO DE USO:Quiero evitar fallos en cascada
  Solución: interrupción del circuito

  Cuando un servicio no está disponible o experimenta una latencia alta, puede llevar mucho tiempo hasta que las solicitudes entrantes expiren y los clientes reciban una respuesta de error. Los tiempos de espera prolongados pueden provocar potencialmente una falla en cascada, en la que la interrupción de un servicio provoca tiempos de espera en otros servicios y la falla final de la aplicação en su totalidad.

  Los disyuntores evitan fallas en cascada al monitorear fallas en el servicio. Cuando la cantidad de solicitudes fallidas a un servicio excede un umbral preestablecido, el disyuntor se dispara y comienza a devolver una respuesta de error a los clientes tan pronto como llegan las solicitudes, lo que limita de manera efectiva el tráfico del servicio.

  El disyuntor continúa interceptando y rechazando solicitudes durante un período de tiempo definido antes de permitir que pase una cantidad limitada de solicitudes a modo de prueba. Si esas solicitudes son exitosas, el disyuntor deja de restringir el tráfico. De lo contrario, el reloj se reinicia y el disyuntor vuelve a rechazar las solicitudes para el tiempo definido.

División del tráfico

La división del tráfico (a veces llamada prueba de tráfico ) es una subcategoría del control de tráfico y se refiere al acto de controlar la proporción de tráfico entrante dirigido a diferentes versiones de una aplicación de backend que se ejecuta simultáneamente en un entorno (generalmente la versión de producción actual y una versión actualizada). Es una parte esencial del ciclo de desarrollo de aplicaciones porque permite a los equipos probar la funcionalidad y la estabilidad de nuevas características y versiones sin afectar negativamente a los clientes. Los escenarios de implementación útiles incluyen enrutamiento de depuración , implementaciones canarias , pruebas A/B e implementaciones azul-verde . (Existe una gran cantidad de inconsistencia en el uso de estos cuatro términos en la industria. Aquí los utilizamos tal como entendemos sus definiciones).

• CASO DE USO:Estoy listo para probar una nueva versión en producción.
  Solución: Enrutamiento de depuración

  Digamos que tienes una aplicación bancaria y quieres agregar una función de puntuación crediticia. Antes de realizar pruebas con clientes, probablemente quieras ver cómo funciona en producción. El enrutamiento de depuración permite implementarlo públicamente, pero "ocultarlo" a los usuarios reales, permitiendo que solo ciertos usuarios accedan a él, según atributos de capa 7, como una cookie de sesión, un ID de sesión o un ID de grupo. Por ejemplo, puede permitir el acceso solo a los usuarios que tienen una cookie de sesión de administrador; sus solicitudes se enrutan a la nueva versión con la función de puntuación de crédito, mientras que el resto continúa con la versión estable.

  

• CASO DE USO:Necesito asegurarme de que mi nueva versión sea estable.
  Solución: Despliegue de Canary

  El concepto de despliegue de canarios proviene de una práctica minera histórica, en la que los mineros llevaban un canario enjaulado a una mina de carbón para que sirviera como advertencia temprana de gases tóxicos. El gas mató al canario antes de matar a los mineros, lo que les permitió escapar rápidamente del peligro. ¡En el mundo de las aplicaciones no se daña a ningún pájaro! Las implementaciones Canary proporcionan una forma segura y ágil de probar la estabilidad de una nueva característica o versión. Una implementación canaria típica comienza con una gran proporción (digamos, el 99 %) de sus usuarios en la versión estable y mueve un grupo pequeño (el otro 1 %) a la nueva versión. Si la nueva versión falla, por ejemplo si se bloquea o devuelve errores a los clientes, puede mover inmediatamente el grupo de prueba a la versión estable. Si tiene éxito, puede cambiar los usuarios de la versión estable a la nueva, ya sea todos a la vez o (como es más común) en una migración gradual y controlada.

  

• CASO DE USO:Necesito saber si a los clientes les gusta más una nueva versión que la versión actual.
  Solución: Pruebas A/B

  Ahora que ha confirmado que su nueva función funciona en producción, es posible que desee obtener comentarios de los clientes sobre el éxito de la función, en función de indicadores clave de rendimiento (KPI), como la cantidad de clics, usuarios repetidos o calificaciones explícitas. La prueba A/B es un proceso utilizado en muchas industrias para medir y comparar el comportamiento de los usuarios con el fin de determinar el éxito relativo de diferentes versiones de productos o aplicaciones en toda la base de clientes. En una prueba A/B típica, el 50% de los usuarios obtiene la versión A (la versión actual de la aplicación), mientras que el 50% restante obtiene la versión B (la versión con la característica nueva, pero estable). El ganador es el que tiene el mejor conjunto de KPI.

  

• CASO DE USO:Quiero mover a mis usuarios a una nueva versión sin tiempo de inactividad
  Solución: Despliegue azul-verde

  Ahora digamos que su aplicación bancaria está a punto de sufrir un cambio de versión importante… ¡felicitaciones! En el pasado, actualizar versiones generalmente implicaba tiempo de inactividad para los usuarios porque era necesario eliminar la versión anterior antes de trasladar la nueva a producción. Pero en el entorno competitivo actual, el tiempo de inactividad para realizar actualizaciones es inaceptable para la mayoría de los usuarios. Las implementaciones azul-verde reducen en gran medida, o incluso eliminan, el tiempo de inactividad por actualizaciones. Simplemente mantenga la versión anterior (azul) en producción mientras implementa simultáneamente la nueva versión (verde) en el mismo entorno de producción.

  La mayoría de las organizaciones no quieren trasladar el 100 % de sus usuarios de azul a verde a la vez; después de todo, ¿qué pasa si falla la versión verde? La solución es utilizar una implementación canaria para mover usuarios en los incrementos que mejor se adapten a su estrategia de mitigación de riesgos. Si la nueva versión es un desastre, puedes revertir fácilmente todos a la versión estable con sólo un par de pulsaciones de teclas.

  

Cómo puede ayudar NGINX

Puede lograr un control de tráfico avanzado y división con la mayoría de los controladores de Ingress y mallas de servicio . La tecnología a utilizar dependerá de la arquitectura de su aplicación y de los casos de uso. Por ejemplo, usar un controlador Ingress tiene sentido en estos tres escenarios:

• Sus aplicaciones tienen solo un punto final, al igual que las aplicaciones simples o monolíticas que ha "elevado y trasladado" a Kubernetes.
• No hay comunicación de servicio a servicio en su clúster.
• Hay comunicación de servicio a servicio, pero todavía no se utiliza una malla de servicios.

Si su implementación es lo suficientemente compleja como para necesitar una malla de servicios, un caso de uso común es dividir el tráfico entre servicios para probar o actualizar microservicios individuales. Por ejemplo, es posible que desee realizar una implementación canaria detrás de su interfaz móvil, entre dos versiones diferentes de su API de microservicio de ubicación geográfica.

Sin embargo, configurar la división del tráfico con algunos controladores de Ingress y mallas de servicio puede consumir mucho tiempo y ser propenso a errores, por diversos motivos:

• Los controladores de ingreso y las mallas de servicios de varios proveedores implementan las características de Kubernetes de diferentes maneras.
• Kubernetes no está realmente diseñado para administrar y comprender el tráfico de capa 7.
• Algunos controladores de Ingress y mallas de servicio no admiten una gestión de tráfico sofisticada.

Con NGINX Ingress Controller y NGINX Service Mesh , puede configurar fácilmente políticas robustas de enrutamiento y división de tráfico en segundos. Vea esta demostración en vivo con nuestros expertos y siga leyendo para descubrir cómo le ahorramos tiempo con configuraciones más sencillas, personalizaciones avanzadas y visibilidad mejorada.

Configuración más sencilla con los recursos de ingreso de NGINX y la especificación SMI

Estas características de NGINX facilitan la configuración:

• Recursos de ingreso de NGINX para el controlador de ingreso de NGINX : si bien el recurso de ingreso de Kubernetes estándar facilita la configuración de la terminación SSL/TLS, el equilibrio de carga HTTP y el enrutamiento de capa 7, no incluye el tipo de funciones de personalización necesarias para la interrupción de circuitos, las pruebas A/B y la implementación azul-verde. En cambio, los usuarios que no utilizan NGINX tienen que usar anotaciones, ConfigMaps y plantillas personalizadas, que carecen de un control detallado, son inseguras, propensas a errores y difíciles de usar.

  El controlador de Ingress NGINX viene con recursos de Ingress NGINX como alternativa al recurso de Ingress estándar (que también admite). Proporcionan un estilo de configuración nativo, seguro en cuanto a tipos y sangrado que simplifica la implementación del equilibrio de carga de Ingress. Los recursos de Ingress de NGINX tienen un beneficio adicional para los usuarios existentes de NGINX: facilitan la reutilización de configuraciones de equilibrio de carga de entornos que no son Kubernetes, de modo que todos sus equilibradores de carga de NGINX puedan usar las mismas configuraciones.

• NGINX Service Mesh con SMI : NGINX Service Mesh implementa la interfaz de malla de servicio (SMI), una especificación que define una interfaz estándar para mallas de servicio en Kubernetes, con recursos tipificados como TrafficSplit , TrafficTarget y HTTPRouteGroup . Mediante el uso de métodos de configuración estándar de Kubernetes, NGINX Service Mesh y las extensiones NGINX SMI hacen que las políticas de división de tráfico, como la implementación canaria, sean fáciles de implementar con una interrupción mínima del tráfico de producción. Por ejemplo, aquí se explica cómo definir una implementación canaria con NGINX Service Mesh:

  apiVersion: split.smi-spec.io/v1alpha2tipo: División de tráfico
  Metadatos:
  Nombre: target-ts
  Especificación:
  Servicio: target-svc
  Backends:
  - Servicio: target-v1-0
  Peso: 90
  - servicio: objetivo-v2-0
  peso: 10

  Nuestro tutorial, Implementaciones que utilizan división de tráfico , recorre patrones de implementación de muestra que aprovechan la división de tráfico, incluidas las implementaciones canarias y azul-verde.

Control de tráfico más sofisticado y división con personalizaciones avanzadas

Estas características de NGINX facilitan el control y la división del tráfico de formas sofisticadas:

• El almacén de valores clave para implementaciones canarias : cuando realiza pruebas A/B o implementaciones azul-verde, es posible que desee realizar la transición del tráfico a la nueva versión en incrementos específicos, por ejemplo, 0 %, 5 %, 10 %, 25 %, 50 % y 100 %. Con la mayoría de las herramientas, este es un proceso muy manual porque hay que editar el porcentaje y volver a cargar el archivo de configuración para cada incremento. Con esa cantidad de gastos generales, usted podría decidir correr el riesgo de pasar directamente del 5% al 100%. Sin embargo, con la versión de NGINX Ingress Controller basada en NGINX Plus , puede aprovechar el almacén de valores clave para cambiar los porcentajes sin necesidad de recargar .

• Ruptura de circuitos con el controlador de ingreso NGINX : los sofisticados interruptores de circuitos ahorran tiempo y mejoran la resiliencia al detectar fallas y conmutaciones por error más rápidamente, e incluso al activar páginas de error formateadas y personalizadas para los upstreams que no funcionan correctamente. Por ejemplo, un disyuntor para un servicio de búsqueda podría configurarse para devolver un conjunto de resultados de búsqueda vacío pero con formato correcto. Para obtener este nivel de sofisticación, la versión basada en NGINX Plus de NGINX Ingress Controller utiliza controles de estado activos que monitorean de manera proactiva el estado de sus servidores ascendentes TCP y UDP. Debido a que el monitoreo se realiza en tiempo real, es menos probable que sus clientes experimenten aplicaciones que devuelvan errores.

• Disyuntor con NGINX Service Mesh : la especificación del disyuntor de NGINX Service Mesh tiene tres campos personalizados:

  • errores – El número de errores antes de que se dispare el circuito
  • timeoutSeconds : la ventana en la que se producen errores antes de disparar el circuito, así como el tiempo de espera antes de cerrar el circuito.
  • fallback : el nombre y el puerto del servicio de Kubernetes al que se redirige el tráfico después de que se haya activado el circuito

  Si bien los errores y los tiempos de espera son funciones estándar de protección, la función de respaldo aumenta aún más la resiliencia al permitirle definir un servidor de respaldo. Si las respuestas de su servidor de respaldo son únicas, pueden ser un indicador temprano de problemas en su clúster, lo que le permitirá comenzar a solucionar problemas de inmediato.

Interpretar los resultados de la división del tráfico con paneles

Has implementado la división del tráfico... ¿y ahora qué? Es hora de analizar el resultado. Esta puede ser la parte más difícil porque muchas organizaciones carecen de información clave sobre el rendimiento de su tráfico y sus aplicaciones de Kubernetes. NGINX facilita la obtención de información con el panel NGINX Plus y los paneles Grafana prediseñados que visualizan las métricas expuestas por Prometheus Exporter. Para obtener más información sobre cómo mejorar la visibilidad y obtener información, lea Cómo mejorar la visibilidad en Kubernetes en nuestro blog.

Domine los microservicios con NGINX

El controlador de ingreso NGINX basado en NGINX Plus está disponible para una prueba gratuita de 30 días que incluye NGINX App Protect para proteger sus aplicaciones en contenedores.

Para probar NGINX Ingress Controller con NGINX Open Source, puede obtener el código fuente de la versión o descargar un contenedor prediseñado desde DockerHub .

El servicio Mesh NGINX, siempre gratuito, está disponible para descargar en f5.com .