Implementación de BIG-IP y el controlador de ingreso NGINX en la misma arquitectura

En nuestra serie de blogs anterior, Implementación de servicios de aplicação en Kubernetes , analizamos un patrón que observamos en muchos clientes durante sus recorridos de transformación digital . La mayoría de los viajes comienzan con el modelo tradicional de creación e implementación de aplicaciones (generalmente monolitos), dividiendo la responsabilidad de esas dos funciones entre equipos aislados de Desarrollo y Operaciones. A medida que las organizaciones avanzan hacia un modelo más moderno, crean aplicaciones basadas en microservicios y las implementan utilizando prácticas de DevOps que difuminan la división entre los silos tradicionales.

Si bien los equipos de DevOps y los propietarios de aplicação están tomando un control más directo sobre cómo se implementan, administran y entregan sus aplicações , a menudo no es práctico derribar los muros de los silos de una sola vez, ni tampoco creemos que sea necesario. Más bien, observamos que todavía se aplica una división lógica de responsabilidades:

• Los equipos de redes y seguridad continúan concentrándose en la seguridad general, el rendimiento y la disponibilidad de la infraestructura corporativa. Lo que más les preocupa son los servicios globales, que generalmente se implementan en la “puerta principal” de esa infraestructura.

  Estos equipos confían en F5 BIG-IP para casos de uso como equilibrio de carga de servidor global (GSLB), resolución de DNS y equilibrio de carga, y modelado de tráfico sofisticado. BIG‑IQ y NGINX Controller [ahora F5 NGINX Management Suite ] brindan métricas y alertas en un formato que se adapta mejor a los equipos de NetOps, y para los equipos de SecOps brindan la visibilidad y el control sobre la seguridad que SecOps debe tener para proteger los activos de la organización y cumplir con las regulaciones de la industria.

• Los equipos de operaciones (DevOps con énfasis en Ops) crean y administran aplicações individuales según lo requieran sus líneas de negocio asociadas. Lo que más les importa son servicios como la automatización y los pipelines de CI/CD que les ayudan a iterar más rápidamente en funciones actualizadas; dichos servicios generalmente se implementan "más cerca" de la aplicación, por ejemplo, dentro de un entorno de Kubernetes.

  Estos equipos confían en productos NGINX como NGINX Plus , NGINX App Protect , NGINX Ingress Controller y NGINX Service Mesh para equilibrar la carga y modelar el tráfico de aplicações distribuidas basadas en microservicios alojadas en múltiples entornos, incluidos clústeres de Kubernetes. Los casos de uso incluyen terminación TLS, enrutamiento basado en host, reescritura de URI, autenticación JWT, persistencia de sesión, limitación de velocidad, verificación de estado, seguridad (con NGINX App Protect como WAF integrado) y muchos más.

NetOps y DevOps en entornos Kubernetes

Las diferentes preocupaciones de los equipos de NetOps y DevOps se reflejan en los roles que desempeñan en los entornos de Kubernetes y las herramientas que utilizan para cumplirlos. Corriendo el riesgo de simplificar demasiado, podemos decir que los equipos de NetOps se ocupan principalmente de la infraestructura y la funcionalidad de red fuera del clúster de Kubernetes, y los equipos de DevOps de esa funcionalidad dentro del clúster.

Para dirigir el tráfico hacia los clústeres de Kubernetes, los equipos de NetOps pueden usar BIG-IP como un equilibrador de carga externo que admite las capacidades y la gama de tecnologías de redes superpuestas con las que ya están familiarizados. Sin embargo, por sí solo, BIG-IP no tiene forma de rastrear los cambios en el conjunto de pods dentro del clúster de Kubernetes (por ejemplo, cambios en la cantidad de pods o sus direcciones IP). Para sortear esta restricción, F5 Container Ingress Services (CIS) se implementa como un operador dentro del clúster. CIS observa los cambios en el conjunto de pods y modifica automáticamente las direcciones en el grupo de equilibrio de carga del sistema BIG-IP en consecuencia. También busca la creación de nuevos recursos de ingreso, ruta y personalizados y actualiza la configuración de BIG-IP en consecuencia.

Si bien puede utilizar la combinación de BIG-IP con CIS para equilibrar la carga de tráfico hacia los pods de aplicação directamente , en la práctica, NGINX Ingress Controller es la solución ideal para descubrir y mantenerse al día con los cambios dinámicos de las aplicação en los pods y las cargas de trabajo que representan una gran cantidad de servicios; por ejemplo, durante el escalamiento horizontal de sus pods de aplicação para satisfacer los niveles cambiantes de demanda.

Otra ventaja de implementar NGINX Ingress Controller es que transfiere el control del equilibrio de carga de las aplicação a los equipos de DevOps que están a cargo de las aplicações en sí. Su plano de control de alto rendimiento y su diseño centrado en DevOps lo hacen particularmente fuerte para soportar casos de uso de DevOps que cambian rápidamente (como reconfiguraciones locales y actualizaciones continuas) en servicios de Kubernetes en múltiples espacios de nombres. El controlador de ingreso NGINX utiliza la API nativa de Kubernetes para descubrir pods a medida que se escalan.

Cómo funcionan juntos BIG-IP y el controlador de ingreso NGINX

Como usted sabe, BIG‑IP y NGINX Ingress Controller fueron diseñados originalmente por dos empresas independientes (F5 y NGINX respectivamente). Desde que F5 adquirió NGINX, los clientes nos han dicho que mejorar la interoperabilidad entre las dos herramientas simplificaría la gestión de su infraestructura. En respuesta, hemos desarrollado un nuevo recurso de Kubernetes que llamamos IngressLink.

El recurso IngressLink es una mejora simple que utiliza una CustomResourceDefinition (CRD) de Kubernetes para “vincular” NGINX Ingress Controller y BIG-IP. En pocas palabras, permite a CIS “decirle” a BIG-IP cada vez que el conjunto de pods del controlador de ingreso NGINX ha cambiado. Con esta información, BIG-IP puede cambiar de manera ágil sus políticas de equilibrio de carga correspondientes para que coincidan.

Con BIG-IP implementado para equilibrar la carga en los clústeres de Kubernetes y NGINX Ingress Controller manejando el tráfico de entrada y salida, el flujo de tráfico se ve así:

1. BIG‑IP dirige el tráfico externo a las instancias del controlador de ingreso NGINX.
2. El controlador de ingreso NGINX distribuye el tráfico a los servicios apropiados dentro del clúster.
3. Debido a que NGINX Ingress Controller es excepcionalmente eficiente, un conjunto estable de instancias puede manejar cambios frecuentes y grandes en el conjunto de pods de aplicação . Pero cuando su controlador de ingreso NGINX necesita escalar horizontalmente hacia adentro o hacia afuera (para manejar aumentos y disminuciones de tráfico), CIS informa a BIG-IP sobre los cambios (a través del recurso IngressLink), lo que permite que BIG-IP se adapte rápidamente a los cambios.

Introducción

Para obtener más detalles sobre cómo funciona el recurso IngressLink, incluida una guía de implementación, visita F5 CloudDocs .

Comience solicitando su prueba gratuita de 30 días de NGINX Ingress Controller con NGINX App Protect WAF y DoS. Si aún no es usuario de BIG‑IP, seleccione la versión de prueba en F5.com que funcione mejor para su equipo.