Implementación de BIG-IP y NGINX Ingress Controller en la misma arquitectura

Micheál KingstonResponsable sénior de producto

En nuestra anterior serie de artículos, «Despliegue de servicios de aplicaciones en Kubernetes», analizamos un patrón que observamos en muchos clientes durante sus procesos de transformación digital. La mayoría de estos procesos comienzan con el modelo tradicional de creación y despliegue de aplicaciones (normalmente monolíticas), en el que la responsabilidad de ambas funciones se reparte entre equipos aislados de Desarrollo y Operaciones. A medida que las organizaciones adoptan un modelo más moderno, crean aplicaciones basadas en microservicios y las despliegan mediante prácticas de DevOps que difuminan la separación entre los silos tradicionales.

Aunque los equipos de DevOps y los propietarios de las aplicaciones están asumiendo un control más directo sobre cómo se despliegan, gestionan y entregan sus aplicaciones, a menudo no resulta práctico derribar de una sola vez los muros que separan los silos, ni consideramos que sea necesario. En cambio, observamos que sigue siendo válida una división lógica de responsabilidades:

• Los equipos de redes y seguridad siguen centrándose en la seguridad, el rendimiento y la disponibilidad generales de la infraestructura corporativa. Su principal prioridad son los servicios globales, que suelen implementarse en la «puerta de entrada» de dicha infraestructura. Estos equipos recurren a F5 BIG-IP para casos de uso como el equilibrio de carga global de servidores (GSLB), la resolución DNS y el equilibrio de carga, así como la gestión avanzada del tráfico. BIG‑IQ y NGINX Controller [ahora F5 NGINX Management Suite] proporcionan métricas y alertas en el formato que mejor se adapta a los equipos de NetOps y, en el caso de los equipos de SecOps, ofrecen la visibilidad y el control de la seguridad que estos necesitan para proteger los activos de la organización y cumplir la normativa del sector.
• Los equipos de operaciones (DevOps con especial énfasis en Ops) crean y gestionan aplicaciones individuales según las necesidades de sus respectivas líneas de negocio. Se centran principalmente en servicios como la automatización y las canalizaciones de CI/CD, que les permiten iterar más rápidamente sobre las funcionalidades actualizadas; estos servicios suelen desplegarse «más cerca» de la aplicación, por ejemplo, dentro de un entorno de Kubernetes. Estos equipos utilizan productos de NGINX como NGINX Plus, NGINX App Protect, NGINX Ingress Controller y NGINX Service Mesh para equilibrar la carga y gestionar el tráfico de aplicaciones distribuidas basadas en microservicios y alojadas en varios entornos, incluidos clústeres de Kubernetes. Entre los casos de uso se incluyen la terminación TLS, el enrutamiento basado en hosts, la reescritura de URI, la autenticación JWT, la persistencia de sesiones, la limitación de solicitudes, las comprobaciones de estado, la seguridad (con NGINX App Protect como WAF integrado) y muchos más.

NetOps y DevOps en entornos de Kubernetes

Las distintas prioridades de los equipos de NetOps y DevOps se reflejan en las funciones que desempeñan en los entornos de Kubernetes y en las herramientas que utilizan para llevarlas a cabo. A riesgo de simplificar en exceso, podemos decir que los equipos de NetOps se ocupan principalmente de la infraestructura y las funciones de red situadas fuera del clúster de Kubernetes, mientras que los equipos de DevOps se ocupan de esas funciones dentro del clúster.

Para dirigir el tráfico a los clústeres de Kubernetes, los equipos de NetOps pueden utilizar BIG‑IP como equilibrador de carga externo compatible con las funciones y la variedad de tecnologías de redes superpuestas con las que ya están familiarizados. Sin embargo, por sí solo, BIG‑IP no puede realizar un seguimiento de los cambios en el conjunto de pods del clúster de Kubernetes (por ejemplo, cambios en el número de pods o en sus direcciones IP). Para sortear esta limitación, F5 Container Ingress Services (CIS) se implementa como operador dentro del clúster. CIS supervisa los cambios en el conjunto de pods y modifica automáticamente las direcciones del grupo de equilibrio de carga del sistema BIG‑IP según corresponda. También detecta la creación de nuevos recursos Ingress, Route y personalizados, y actualiza la configuración de BIG‑IP en consecuencia.

Aunque puede utilizar la combinación de BIG‑IP y CIS para equilibrar la carga del tráfico directamente hacia los pods de aplicaciones, en la práctica, NGINX Ingress Controller es la solución ideal para detectar y seguir los cambios dinámicos de las aplicaciones en los pods y las cargas de trabajo que representan un gran número de servicios; por ejemplo, durante el escalado horizontal de los pods de aplicaciones para adaptarse a los cambios en los niveles de demanda.

Otra ventaja de implementar NGINX Ingress Controller es que transfiere el control del balanceo de carga de las aplicaciones a los equipos de DevOps responsables de dichas aplicaciones. Su plano de control de alto rendimiento y su diseño centrado en DevOps lo hacen especialmente eficaz para admitir casos de uso de DevOps que cambian rápidamente —como las reconfiguraciones in situ y las actualizaciones graduales— en servicios de Kubernetes distribuidos en varios espacios de nombres. NGINX Ingress Controller utiliza la API nativa de Kubernetes para detectar los pods a medida que se escalan.

Cómo funcionan conjuntamente BIG-IP y NGINX Ingress Controller

Como quizá sepa, BIG‑IP y NGINX Ingress Controller fueron diseñados originalmente por dos empresas distintas (F5 y NGINX, respectivamente). Desde que F5 adquirió NGINX, nuestros clientes nos han indicado que mejorar la interoperabilidad entre ambas herramientas simplificaría la gestión de su infraestructura. En respuesta, hemos desarrollado un nuevo recurso de Kubernetes al que llamamos IngressLink.

El recurso IngressLink es una sencilla mejora que utiliza una CustomResourceDefinition (CRD) de Kubernetes para «vincular» NGINX Ingress Controller y BIG‑IP. En pocas palabras, permite que CIS «informe» a BIG‑IP cada vez que cambia el conjunto de pods de NGINX Ingress Controller. Con esta información, BIG‑IP puede adaptar rápidamente sus correspondientes políticas de equilibrio de carga.

Con BIG‑IP implementado para equilibrar la carga de los clústeres de Kubernetes y NGINX Ingress Controller gestionando el tráfico de entrada y salida, el flujo de tráfico es el siguiente:

1. BIG‑IP dirige el tráfico externo a las instancias de NGINX Ingress Controller.
2. NGINX Ingress Controller distribuye el tráfico entre los servicios adecuados dentro del clúster.
3. Dado que NGINX Ingress Controller es excepcionalmente eficiente, un conjunto estable de instancias puede gestionar cambios frecuentes y de gran magnitud en el conjunto de pods de aplicaciones. Sin embargo, cuando NGINX Ingress Controller necesita escalar horizontalmente hacia fuera o hacia dentro (para gestionar aumentos y disminuciones del tráfico), CIS informa a BIG‑IP de los cambios (mediante el recurso IngressLink), lo que permite que BIG‑IP se adapte rápidamente.

Primeros pasos

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

Empiece solicitando su prueba gratuita de 30 días de NGINX Ingress Controller con NGINX App Protect WAF y DoS. Si aún no utiliza BIG‑IP, seleccione la prueba en F5.com que mejor se adapte a su equipo.

Sobre el autor

Micheál KingstonResponsable sénior de producto

Más artículos de Micheál Kingston