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

En el mundo de la orquestación de contenedores hay dos nombres con los que nos topamos todo el tiempo: Plataforma de contenedores RedHat OpenShift (OCP) y Kubernetes. OpenShift, como probablemente sepas, utiliza Kubernetes, al igual que muchas de las otras plataformas de orquestación de contenedores. Enrutar el tráfico externo a un entorno de Kubernetes u OpenShift siempre ha sido un poco desafiante, de dos maneras:

• Exponer servicios implementados dentro de Kubernetes al mundo exterior. La solución es un controlador de Ingress como NGINX Plus Ingress Controller . Puede leer más sobre esto en nuestro blog Primeros pasos con el operador de ingreso NGINX en Red Hat OpenShift .
• Equilibrio de carga del tráfico entre sus nodos de Kubernetes. Para resolver este problema, las organizaciones generalmente optan por un hardware externo o un balanceador de carga virtual o una solución nativa de la nube. Sin embargo, NGINX Plus también se puede utilizar como equilibrador de carga externo, mejorando el rendimiento y simplificando su inversión en tecnología.

En este blog, me centro en cómo resolver el segundo problema usando NGINX Plus de una manera simple, eficiente y que permita a los equipos de desarrollo de aplicaciones administrar tanto la configuración de Ingress dentro de Kubernetes como la configuración del balanceador de carga externo en el exterior. Como arquitectura de referencia para ayudarlo a comenzar, he creado el proyecto nginx-lb-operator en GitHub: el operador de balanceador de carga NGINX ( NGINX-LB-Operator ) es un operador basado en Ansible para el controlador NGINX creado utilizando Red Hat Operator Framework y SDK. NGINX-LB-Operator impulsa la API declarativa de NGINX Controller para actualizar la configuración del balanceador de carga externo NGINX Plus cuando se agregan 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 acuerdo de soporte NGINX Plus o NGINX Controller. Puede informar errores o solicitar asistencia para la resolución de problemas en GitHub .

Tecnologías Kubernetes y NGINX: una revisión

NGINX-LB-Operator se basa en varias tecnologías de Kubernetes y NGINX, por lo que proporcionaré una revisión rápida para que todos estemos en la misma página. Si ya está familiarizado con ellos, no dude en pasar a El operador del balanceador de carga NGINX .

Controladores y operadores de Kubernetes

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

• Controladores : una parte central del sistema Kubernetes. Crean “relojes” para recursos específicos de Kubernetes y realizan los pasos necesarios para alcanzar el estado deseado de cada recurso a medida que cambia. En las conversaciones con los clientes, el controlador de Kubernetes más común que se analiza es el “controlador de ingreso”.
• Operadores : controladores personalizados que definen y utilizan definiciones de recursos personalizadas (CRD) para administrar aplicações y sus componentes.

Controladores de ingreso NGINX para Kubernetes

Hay dos opciones principales de controlador de Ingress para NGINX, y puede resultar un poco confuso distinguirlas porque los nombres en GitHub son muy similares. Discutimos este tema en detalle en un blog anterior , pero aquí hay una revisión rápida:

• kubernetes/ingress-nginx : el controlador de Ingress respaldado y mantenido por la comunidad de código abierto de Kubernetes. Para facilitar su uso, lo llamamos el “controlador de Ingress de la comunidad”. Como era de esperar, se basa en NGINX de código abierto. Proporciona funciones adicionales que son habilitadas por módulos Lua de terceros, que lamentablemente tienden a perjudicar el rendimiento.

• nginxinc/kubernetes-ingress : el controlador de Ingress mantenido por el equipo NGINX en F5. Hay dos versiones: una para NGINX Open Source (diseñada para la velocidad) y otra para NGINX Plus (también diseñada para la velocidad, pero con soporte comercial y con funciones adicionales de nivel empresarial). A estos los llamamos “controladores de ingreso NGINX (o nuestros)”.

  Puede administrar ambos controladores de Ingress utilizando recursos de Ingress de Kubernetes estándar. También admitimos anotaciones y ConfigMaps para ampliar la funcionalidad limitada proporcionada por la especificación Ingress, pero ampliar los recursos de esta manera no es ideal.

  Las versiones 1.6.0 y posteriores de nuestros controladores Ingress incluyen una mejor solución: recursos Ingress NGINX personalizados llamados VirtualServer y VirtualServerRoute que amplían la API de Kubernetes y brindan funciones adicionales de manera nativa de Kubernetes. Los recursos de Ingress de NGINX exponen más funcionalidades de NGINX y le permiten usar funciones avanzadas de equilibrio de carga con Ingress, implementar versiones azul-verde y canarias y patrones de disyuntores, y más.

Para obtener un resumen de las diferencias clave entre estas tres opciones de controlador de Ingress, consulte nuestro repositorio de GitHub .

NGINX Controller

NGINX Controller es nuestro plano de control independiente de la nube para administrar sus instancias NGINX Plus en múltiples entornos y aprovechar información crítica sobre el rendimiento y los estados de error. Sus módulos proporcionan gestión de configuración centralizada para la entrega de aplicação (equilibrio de carga) y gestión de API . NGINX Controller puede administrar la configuración de instancias NGINX Plus en una multitud de entornos: físicos, virtuales y en la nube. Está construido alrededor de una API declarativa eventualmente consistente y proporciona una vista centrada en la aplicación de sus aplicaciones y sus componentes. Está diseñado para interactuar fácilmente con sus pipelines CI/CD, abstraer la infraestructura del código y permitir que los desarrolladores continúen con su trabajo.

Cuando se trata de Kubernetes, NGINX Controller puede administrar instancias de NGINX Plus implementadas de manera frontal como un proxy inverso o una puerta de enlace de API. Sin embargo, no tiene sentido que el controlador NGINX administre por sí mismo el controlador de ingreso NGINX Plus; debido a que el controlador de ingreso realiza la función de bucle de control para un recurso central de Kubernetes (el ingreso), debe administrarse utilizando herramientas de la plataforma Kubernetes, ya sean recursos de ingreso estándar o recursos de ingreso NGINX.

Balanceadores de carga externos

El controlador de ingreso NGINX Plus para Kubernetes es una excelente manera de exponer servicios dentro de Kubernetes al mundo exterior, pero a menudo se necesita una capa de equilibrio de carga externa para administrar el tráfico hacia los nodos o clústeres de Kubernetes. Si está trabajando en 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 está implementando en las instalaciones o en una nube privada, puede usar NGINX Plus o un dispositivo BIG-IP LTM (físico o virtual). Me han dicho que hay otros balanceadores de carga disponibles, pero no lo creo 😉.

Cuando se trata de administrar sus balanceadores de carga externos, puede administrar instancias externas de NGINX Plus utilizando directamente el controlador NGINX. Su API declarativa ha sido diseñada con el propósito de interactuar con su canalización CI/CD, y usted puede implementar cada uno de los componentes de su aplicação usándola. ¿Pero qué sucede si su capa de Ingress es escalable, utiliza NodePorts de Kubernetes asignados dinámicamente o sus rutas OpenShift pueden cambiar?

En casos como estos, probablemente desee fusionar la configuración del balanceador de carga externo con el estado de Kubernetes y ejecutar la API del controlador NGINX a través de un operador de Kubernetes. El diagrama muestra una implementación de muestra que incluye exactamente ese operador ( NGINX-LB-Operator ) para administrar el balanceador de carga externo y resalta las diferencias entre el controlador de ingreso NGINX Plus y el controlador NGINX.

DÓNDE: 

• Recursos de Ingress (cuadro azul) : un recurso de Ingress estándar y un recurso de NGINX VirtualServer se definen en el espacio de nombres del proyecto.
• Flechas azules : los recursos de ingreso se crean en la API de Kubernetes y son recogidos por el controlador de ingreso NGINX Plus, que se ejecuta en un espacio de nombres diferente.
• Recursos personalizados (cuadro verde) : los recursos personalizados, que son instancias de CRD instalados con NGINX-LB-Operator , se definen en el espacio de nombres de su proyecto y son consumidos por NGINX-LB-Operator que se ejecuta en el mismo espacio de nombres.
• Flechas verdes : los recursos se crean en la API y luego son recogidos por NGINX-LB-Operator . A diferencia del controlador de ingreso que configura una instancia local de NGINX Plus que se ejecuta en el mismo pod, NGINX-LB-Operator realiza una llamada API al controlador de NGINX.
• Flechas naranjas : el controlador NGINX configura la instancia externa NGINX Plus para equilibrar la carga en el controlador de ingreso NGINX Plus.

En esta topología, los recursos personalizados contienen el estado deseado del balanceador de carga externo y configuran el flujo ascendente (grupo de carga de trabajo) para que sea el controlador de ingreso NGINX Plus. NGINX-LB-Operator recopila información sobre los pods de ingreso y fusiona esa información con el estado deseado antes de enviarla a la API del controlador NGINX.

El operador del balanceador de carga NGINX

Al principio, escribir un operador para Kubernetes puede parecer una tarea abrumadora, pero Red Hat y la comunidad de código abierto de Kubernetes mantienen el Operator Framework , lo que hace que la tarea sea relativamente fácil. El SDK del operador permite a cualquier persona 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 administrar instancias externas de NGINX Plus e interactuar con NGINX Controller es bastante sencillo.

Utilicé el SDK del operador para crear el operador del balanceador de carga NGINX, NGINX-LB-Operator , que se puede implementar con un espacio de nombres o un ámbito de clúster y supervisa un puñado de recursos personalizados. Los recursos personalizados se asignan directamente a los objetos del controlador NGINX (certificado, puerta de enlace, aplicação y componente) y, por lo tanto, representan el modelo centrado en la aplicação del controlador NGINX directamente en Kubernetes. Los recursos personalizados configurados en Kubernetes son recogidos por NGINX-LB-Operator , que luego 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, obtiene las ventajas adicionales de monitorización y alertas, así como la información detallada de la aplicação que proporciona NGINX Controller.

Este diagrama ilustra cómo:

1. Crea recursos personalizados en el espacio de nombres del proyecto que se envían a la API de Kubernetes.
2. NGINX-LB-Operator ve los recursos recién configurados y recopila el estado deseado del componente y la información de implementación del controlador de Ingress en el espacio de nombres de Ingress.
3. Se envía una configuración fusionada de su definición y el estado actual del controlador de Ingress al controlador NGINX.
4. La configuración se entrega a las instancias NGINX Plus solicitadas y NGINX Controller comienza a recopilar métricas para la nueva aplicação.

Se proporcionan instrucciones de implementación detalladas y una aplicação de muestra en GitHub . Si no te gustan los juegos de rol o viniste aquí por la versión TL;DR, dirígete allí ahora.

Una implementación de muestra

Entonces, vamos a hacer un juego de roles. Yo seré Susan y tú puedes ser Dave.

Como Dave, diriges una línea de negocios en tu conglomerado imaginario favorito. Estás al tanto de los niños y tienes el control de todo, etc., por lo que implementas todas tus aplicações y microservicios en OpenShift y para Ingress utilizas el controlador de ingreso NGINX Plus para Kubernetes. Todas sus aplicações se implementan como proyectos OpenShift (espacios de nombres) y el controlador de Ingress NGINX Plus se ejecuta en su propio espacio de nombres de Ingress.

Nunca estuvo satisfecho con las características disponibles en la especificación de Ingress predeterminada y siempre pensó que ConfigMaps y Annotations eran un poco torpes. Este es el motivo por el que estabas muy contento cuando NGINX anunció que el controlador de ingreso NGINX Plus comenzaría a soportar sus propios CRD. Hoy en día, los desarrolladores de aplicação utilizan los recursos VirtualServer y VirtualServerRoutes para administrar la implementación de aplicações en el controlador de ingreso NGINX Plus y para configurar el enrutamiento interno y el manejo de errores dentro de OpenShift.

A veces incluso se exponen servicios que no son HTTP, todo gracias a los recursos personalizados de TransportServer también disponibles con el controlador de ingreso NGINX Plus. Los desarrolladores pueden definir recursos personalizados en sus propios espacios de nombres de proyecto, que luego son recogidos por NGINX Plus Ingress Controller y aplicados inmediatamente. Es fantástico, pero desearía que fuera posible administrar el balanceador de carga de red externo en el borde de su clúster OpenShift con la misma facilidad. Las ocasiones en las que necesitas escalar la capa de Ingress siempre provocan que tu lumbago se resienta.

Es sábado por la noche y deberías estar en la discoteca, pero ayer tuviste que escalar de nuevo la capa de Ingress y ahora tienes un dolor en la espalda baja. ¡Sin silbido! En una nube de humo aparece tu hada madrina Susan.

“Hola, Dave”, dice ella.

"¿Quién eres? “Mira lo que has hecho con mi alfombra persa”, respondes.

Ignorando tu actitud, Susan procede a contarte sobre NGINX-LB-Operator, ahora disponible en GitHub. Ella explica que con un clúster NGINX Plus en el borde de OpenShift y un controlador NGINX para administrarlo desde una perspectiva centrada en la aplicação, se pueden crear recursos personalizados que definen cómo configurar el balanceador de carga NGINX Plus.

El operador NGINX-LB supervisa estos recursos y los utiliza para enviar la configuración centrada en la aplicação al controlador NGINX. A su vez, NGINX Controller genera la configuración NGINX Plus requerida y la envía al balanceador de carga NGINX Plus externo.

¡Sus usuarios finales obtienen acceso inmediato a sus aplicações y usted obtiene control sobre los cambios que requieren modificaciones en el balanceador de carga externo NGINX Plus!

El controlador NGINX recopila métricas del balanceador de carga externo NGINX Plus y se las presenta desde la misma perspectiva centrada en la aplicação que ya disfruta. Y la próxima vez que escale la capa de ingreso de NGINX Plus, NGINX-LB-Operator actualizará automáticamente el controlador NGINX y el balanceador de carga externo NGINX Plus para usted. ¡No más dolor de espalda!

CONCLUSIÓN

Kubernetes es una plataforma creada para gestionar aplicações en contenedores. NGINX Controller proporciona un modelo centrado en la aplicação para pensar y gestionar el equilibrio de carga de las aplicação . NGINX-LB-Operator combina ambos y le permite administrar la pila completa de extremo a extremo sin necesidad de preocuparse por ninguna infraestructura subyacente. Visita GitHub para obtener más información técnica sobre NGINX-LB-Operator y un tutorial de muestra completo.

Conozca más sobre nuestras soluciones:

• Solicite una prueba gratuita de NGINX Controller
• Contáctenos para discutir sus casos de uso
• Obtenga el operador de ingreso NGINX para OpenShift
• Regístrese para un curso dirigido por un instructor