Configuración de NGINX Plus como balanceador de carga externo para Red Hat OCP y Kubernetes

NGINX | 24 de julio de 2020

En el mundo de la orquestación de contenedores hay dos nombres que aparecen constantemente: Red Hat OpenShift Container Platform (OCP) y Kubernetes. Como probablemente ya sepa, OpenShift utiliza Kubernetes como base, al igual que muchas otras plataformas de orquestación de contenedores. Enrutar el tráfico externo hacia un entorno de Kubernetes u OpenShift siempre ha planteado ciertas dificultades en dos aspectos:

Exponer al mundo exterior los servicios desplegados dentro de Kubernetes. La solución es un controlador Ingress como NGINX Plus Ingress Controller. Puede obtener más información en nuestro blog Primeros pasos con NGINX Ingress Operator en Red Hat OpenShift.
Equilibrado de la carga de tráfico entre los nodos de Kubernetes. Para resolver este problema, las organizaciones suelen optar por un balanceador de carga externo, ya sea físico o virtual, o por una solución nativa de la nube. Sin embargo, NGINX Plus también puede utilizarse como balanceador de carga externo, lo que mejora el rendimiento y simplifica la inversión tecnológica.

En este blog, me centro en cómo resolver el segundo problema mediante NGINX Plus de una forma sencilla y eficiente que permita a sus equipos de desarrollo de aplicaciones gestionar tanto la configuración de Ingress dentro de Kubernetes como la configuración del balanceador de carga externo. Como arquitectura de referencia para ayudarle a empezar, he creado el proyecto nginx-lb-operator en GitHub: NGINX Load Balancer Operator (NGINX-LB-Operator) es un operador basado en Ansible para NGINX Controller, creado mediante Red Hat Operator Framework y su SDK. NGINX-LB-Operator utiliza la API declarativa de NGINX Controller para actualizar la configuración del balanceador de carga externo NGINX Plus cuando se añaden nuevos servicios, cambian los pods o se escalan las implementaciones dentro del clúster de Kubernetes.

Tenga en cuenta que NGINX-LB-Operator no está cubierto por su contrato de soporte de NGINX Plus o NGINX Controller. Puede informar de errores o solicitar ayuda para solucionar problemas en GitHub.

Kubernetes y las tecnologías de NGINX: un repaso

NGINX-LB-Operator se basa en varias tecnologías de Kubernetes y NGINX, por lo que voy a hacer un breve repaso para que todos partamos de la misma base. Si ya las conoce, puede pasar directamente a El operador de balanceo de carga de NGINX.

Controladores y operadores de Kubernetes

Kubernetes es una plataforma de orquestación basada en una API central con un acoplamiento flexible. La API proporciona un conjunto de definiciones de recursos, junto con controladores (que normalmente se ejecutan como pods dentro de la plataforma) para supervisar y gestionar dichos recursos. La API de Kubernetes es extensible y se pueden utilizar operadores (un tipo de controlador) para ampliar la funcionalidad de Kubernetes.

Controladores – Una parte fundamental del sistema Kubernetes. Crean «vigilancias» para recursos específicos de Kubernetes y llevan a cabo los pasos necesarios para alcanzar el estado deseado de cada recurso a medida que cambia. En las conversaciones con clientes, el controlador de Kubernetes que se menciona con más frecuencia es el «controlador de entrada» (Ingress Controller).
Operadores – Controladores personalizados que definen y utilizan definiciones de recursos personalizados (CRD) para gestionar aplicaciones y sus componentes.

Controladores de Ingress de NGINX para Kubernetes

Hay dos opciones principales de controladores Ingress para NGINX, y puede resultar un poco confuso distinguirlas porque sus nombres en GitHub son muy similares. Tratamos este tema en detalle en una entrada anterior del blog, pero aquí tienes un breve resumen:

kubernetes/ingress-nginx – El controlador de Ingress respaldado y mantenido por la comunidad de código abierto de Kubernetes. Para simplificar, lo llamamos «controlador de Ingress de la comunidad». Como era de esperar, se basa en NGINX Open Source. Ofrece funcionalidades adicionales habilitadas mediante módulos Lua de terceros que, por desgracia, suelen perjudicar el rendimiento.
nginxinc/kubernetes-ingress – El controlador Ingress mantenido por el equipo de NGINX en F5. Hay dos versiones: una para NGINX Open Source (diseñada para ofrecer velocidad) y otra para NGINX Plus (también diseñada para ofrecer velocidad, pero con soporte comercial y funciones adicionales de nivel empresarial). Los denominamos «controladores Ingress de NGINX (o nuestros)». Puede gestionar ambos controladores Ingress mediante recursos Ingress estándar de Kubernetes. También admitimos anotaciones y ConfigMaps para ampliar la funcionalidad limitada que ofrece la especificación de Ingress, aunque ampliar los recursos de esta forma no es lo ideal.La versión 1.6.0 y las versiones posteriores de nuestros controladores Ingress incluyen una solución mejor: recursos Ingress de NGINX personalizados denominados VirtualServer y VirtualServerRoute, que amplían la API de Kubernetes y proporcionan funciones adicionales de forma nativa para Kubernetes. Los recursos Ingress de NGINX exponen más funcionalidades de NGINX y permiten utilizar funciones avanzadas de equilibrio de carga con Ingress, implementar despliegues azul-verde y canary, patrones de disyuntor y mucho más.

Para consultar un resumen de las principales diferencias entre estas tres opciones de controlador de Ingress, visite nuestro repositorio de GitHub.

Controlador NGINX

NGINX Controller es nuestro plano de control independiente de la nube para gestionar sus instancias de NGINX Plus en múltiples entornos y aprovechar información clave sobre el rendimiento y los estados de error. Sus módulos proporcionan una gestión centralizada de la configuración para la entrega de aplicaciones (equilibrio de carga) y la gestión de API. NGINX Controller permite gestionar la configuración de instancias de NGINX Plus en multitud de entornos: físicos, virtuales y en la nube. Se basa en una API declarativa con coherencia eventual y ofrece una vista de sus aplicaciones y sus componentes centrada en las aplicaciones. Está diseñado para integrarse fácilmente con sus canalizaciones de CI/CD, abstraer la infraestructura del código y permitir que los desarrolladores se centren en su trabajo.

En lo que respecta a Kubernetes, NGINX Controller puede gestionar instancias de NGINX Plus desplegadas en el frontal como proxy inverso o puerta de enlace de API. Sin embargo, no tiene sentido que NGINX Controller gestione el propio NGINX Plus Ingress Controller, ya que este desempeña la función de bucle de control de un recurso esencial de Kubernetes (Ingress) y debe gestionarse mediante herramientas de la plataforma Kubernetes, ya sean recursos Ingress estándar o recursos NGINX Ingress.

Balanceadores de carga externos

NGINX Plus Ingress Controller para Kubernetes es una excelente forma de exponer al exterior los servicios de Kubernetes, pero a menudo se necesita una capa externa de balanceo de carga para gestionar el tráfico que llega a los nodos o clústeres de Kubernetes. Si utiliza una nube pública, el balanceador de carga externo puede ser NGINX Plus, F5 BIG-IP LTM Virtual Edition o una solución nativa de la nube. Si realiza la implementación en sus propias instalaciones o en una nube privada, puede utilizar NGINX Plus o un dispositivo BIG-IP LTM (físico o virtual). Me han dicho que hay otros balanceadores de carga disponibles, pero no me lo creo 😉 .

En lo que respecta a la gestión de los balanceadores de carga externos, puede gestionar directamente las instancias externas de NGINX Plus mediante NGINX Controller. Su API declarativa se ha diseñado para integrarse con su canalización de CI/CD y permite desplegar cada uno de los componentes de su aplicación. Pero ¿qué ocurre si su capa de Ingress es escalable, utiliza NodePorts de Kubernetes asignados dinámicamente o sus rutas de OpenShift pueden cambiar?

En casos como estos, probablemente le interese combinar la configuración del equilibrador de carga externo con el estado de Kubernetes y controlar la API de NGINX Controller mediante un operador de Kubernetes. El diagrama muestra un ejemplo de implementación que incluye precisamente un operador de este tipo (NGINX-LB-Operator) para gestionar el equilibrador de carga externo y destaca las diferencias entre NGINX Plus Ingress Controller y NGINX Controller.

donde:

Recursos de Ingress (recuadro azul) – En el espacio de nombres del proyecto se definen un recurso Ingress estándar y un recurso VirtualServer de NGINX.
Flechas azules – Los recursos de Ingress se crean en la API de Kubernetes y el controlador de Ingress NGINX Plus, que se ejecuta en un espacio de nombres diferente, los detecta.
Recursos personalizados (recuadro verde) – Los recursos personalizados, que son instancias de las CRD instaladas con NGINX-LB-Operator, se definen en el espacio de nombres de su proyecto y los utiliza NGINX-LB-Operator, que se ejecuta en el mismo espacio de nombres.
Flechas verdes – Los recursos se crean en la API y, a continuación, NGINX-LB-Operator los recoge. A diferencia del controlador de Ingress, que configura una instancia local de NGINX Plus que se ejecuta en el mismo pod, NGINX-LB-Operator realiza una llamada a la API de NGINX Controller.
Flechas naranjas – NGINX Controller configura la instancia externa de NGINX Plus para equilibrar la carga en el controlador de entrada NGINX Plus.

En esta topología, los recursos personalizados contienen el estado deseado del equilibrador de carga externo y establecen NGINX Plus Ingress Controller como upstream (grupo de cargas de trabajo). NGINX-LB-Operator recopila información sobre los pods de Ingress y la combina con el estado deseado antes de enviarla a la API de NGINX Controller.

El operador de balanceo de carga de NGINX

Escribir un operador para Kubernetes puede parecer una tarea abrumadora al principio, pero Red Hat y la comunidad de código abierto de Kubernetes mantienen el Operator Framework, que facilita bastante la tarea. El Operator SDK permite a cualquiera crear un operador de Kubernetes utilizando Go, Ansible o Helm. En F5 ya publicamos colecciones de Ansible para muchos de nuestros productos, incluida la colección certificada para NGINX Controller, por lo que crear un operador para gestionar instancias externas de NGINX Plus e interactuar con NGINX Controller resulta bastante sencillo.

Utilicé el SDK de Operator para crear el operador de balanceo de carga de NGINX, NGINX-LB-Operator, que puede implementarse con ámbito de espacio de nombres o de clúster y supervisa varios recursos personalizados. Estos recursos se corresponden directamente con objetos de NGINX Controller (certificado, puerta de enlace, aplicación y componente), por lo que representan el modelo centrado en las aplicaciones de NGINX Controller directamente en Kubernetes. NGINX-LB-Operator detecta los recursos personalizados configurados en Kubernetes y, a continuación, crea recursos equivalentes en NGINX Controller.

NGINX-LB-Operator le permite gestionar la configuración de una instancia externa de NGINX Plus mediante la API declarativa de NGINX Controller. Dado que NGINX Controller gestiona la instancia externa, también puede beneficiarse de las funciones de supervisión y alertas, así como de la información detallada sobre las aplicaciones que proporciona NGINX Controller.

Este diagrama ilustra cómo:

Crea recursos personalizados en el espacio de nombres del proyecto, que se envían a la API de Kubernetes.
NGINX-LB-Operator detecta los recursos recién configurados y recopila el estado deseado del componente y la información de despliegue del controlador Ingress en el espacio de nombres de Ingress.
Se envía a NGINX Controller una configuración combinada a partir de su definición y del estado actual del controlador Ingress.
La configuración se envía a las instancias de NGINX Plus solicitadas y NGINX Controller comienza a recopilar métricas de la nueva aplicación.

En GitHub se proporcionan instrucciones detalladas de implementación y una aplicación de ejemplo. Si no te gustan los juegos de rol o has venido buscando la versión resumida, ve allí ahora.

Un despliegue de ejemplo

Hagamos un juego de rol. Yo seré Susan y tú puedes ser Dave.

Como Dave, diriges una línea de negocio en tu conglomerado imaginario favorito. Estás a la última y al tanto de todo, así que despliegas todas tus aplicaciones y microservicios en OpenShift y, para Ingress, utilizas NGINX Plus Ingress Controller para Kubernetes. Todas tus aplicaciones se despliegan como proyectos de OpenShift (espacios de nombres) y NGINX Plus Ingress Controller se ejecuta en su propio espacio de nombres de Ingress.

Nunca estuvo satisfecho con las funcionalidades disponibles en la especificación Ingress predeterminada y siempre consideró que los ConfigMaps y las anotaciones eran algo engorrosos. Por eso se alegró enormemente cuando NGINX anunció que NGINX Plus Ingress Controller empezaría a admitir sus propios CRD. Actualmente, los desarrolladores de sus aplicaciones utilizan los recursos VirtualServer y VirtualServerRoutes para gestionar el despliegue de aplicaciones en NGINX Plus Ingress Controller y configurar el enrutamiento interno y la gestión de errores en OpenShift.

A veces incluso expones servicios que no son HTTP, todo gracias a los recursos personalizados TransportServer que también están disponibles con NGINX Plus Ingress Controller. Los desarrolladores pueden definir los recursos personalizados en los espacios de nombres de sus propios proyectos; NGINX Plus Ingress Controller los detecta y los aplica de inmediato. Es fantástico, pero te gustaría poder gestionar con la misma facilidad el balanceador de carga de red externo situado en el perímetro de tu clúster de OpenShift. Cada vez que necesitas escalar la capa de Ingress, el lumbago vuelve a darte guerra.

Es sábado por la noche y deberías estar en la discoteca, pero ayer tuviste que volver a escalar la capa de Ingress y ahora te duele la zona lumbar. ¡Ping! En medio de una nube de humo aparece Susan, tu hada madrina.

«Hola, Dave» —dice ella.

«¿Quién eres? Mira lo que le has hecho a mi alfombra persa» respondes.

Ignorando tu actitud, Susan continúa hablándote de NGINX-LB-Operator, que ya está disponible en GitHub. Te explica que, con un clúster de NGINX Plus en el perímetro de OpenShift y NGINX Controller para gestionarlo desde una perspectiva centrada en las aplicaciones, puedes crear recursos personalizados que definan cómo configurar el balanceador de carga NGINX Plus.

NGINX-LB-Operator supervisa estos recursos y los utiliza para enviar la configuración centrada en la aplicación a NGINX Controller. A su vez, NGINX Controller genera la configuración necesaria de NGINX Plus y la envía al balanceador de carga externo NGINX Plus.

Sus usuarios finales obtienen acceso inmediato a sus aplicaciones, mientras que usted mantiene el control sobre los cambios que requieren modificar el balanceador de carga externo NGINX Plus.

NGINX Controller recopila métricas del balanceador de carga externo NGINX Plus y se las presenta desde la misma perspectiva centrada en las aplicaciones de la que ya disfruta. Además, la próxima vez que escale la capa de entrada de NGINX Plus, NGINX-LB-Operator actualizará automáticamente NGINX Controller y el balanceador de carga externo NGINX Plus. ¡Se acabaron los quebraderos de cabeza!

Conclusión

Kubernetes es una plataforma diseñada para gestionar aplicaciones en contenedores. NGINX Controller proporciona un modelo centrado en las aplicaciones para abordar y gestionar el equilibrio de carga de las aplicaciones. NGINX-LB-Operator combina ambos y permite gestionar toda la pila de extremo a extremo sin tener que preocuparse por la infraestructura subyacente. Visita GitHub para obtener más información técnica sobre NGINX-LB-Operator y consultar un tutorial práctico completo.

Obtenga más información sobre nuestras soluciones: