Controles dinámicos de equilibrio de carga A/B y seguridad en varios clústeres de Kubernetes con NGINX Plus

Chris Akker

Eres un ingeniero moderno de operaciones de plataforma o DevOps. Utilizas un conjunto de herramientas de código abierto (y quizá algunas comerciales) para probar, desplegar y gestionar nuevas aplicaciones y contenedores para tu equipo de desarrollo. Has elegido Kubernetes para ejecutar estos contenedores y pods en entornos de desarrollo, pruebas, preproducción y producción. Has adoptado las arquitecturas y los conceptos de los microservicios y, en general, funcionan bastante bien. Sin embargo, te has encontrado con algunos obstáculos por el camino.

Por ejemplo, a medida que crea e implementa nuevos clústeres, servicios y aplicaciones, ¿cómo puede integrar o migrar fácilmente estos nuevos recursos a producción sin interrumpir el tráfico? Los dispositivos de red tradicionales requieren recargas o reinicios al aplicar cambios de configuración en los registros DNS, los balanceadores de carga, los cortafuegos y los proxies. Estos ajustes no pueden reconfigurarse sin provocar tiempo de inactividad, ya que se necesita una «interrupción del servicio» o una «ventana de mantenimiento» para actualizar las reglas de DNS, del balanceador de carga y del cortafuegos. La mayoría de las veces, tiene que enviar el temido ticket de servicio y esperar a que otro equipo apruebe y aplique los cambios.

Las ventanas de mantenimiento pueden sacar a tu equipo de la carretera, frenar la entrega de aplicaciones y hacerte exclamar: «¡Tiene que haber una forma mejor de gestionar el tráfico!». Así que veamos una solución que te permita volver al carril rápido.

Equilibrado de carga activo-activo entre varios clústeres

Si tiene varios clústeres de Kubernetes, lo ideal es dirigir el tráfico a ambos clústeres al mismo tiempo. Una opción aún mejor es dividir el tráfico mediante pruebas A/B, despliegues canary o blue-green y enviar un pequeño porcentaje del tráfico a modo de prueba. Para ello, puede utilizar NGINX Plus con ngx_http_split_clients_module.

El módulo HTTP Split Clients está desarrollado por NGINX Open Source y permite distribuir las solicitudes en una proporción determinada en función de una clave. En este caso de uso, los clústeres son los «upstreams» de NGINX. Así, a medida que llegan las solicitudes de los clientes, el tráfico se reparte entre dos clústeres. La clave utilizada para determinar la solicitud del cliente puede ser cualquier $variable de cliente de NGINX disponible. Dicho esto, para controlar cada solicitud, utilice la variable $request_id, que es un número único que NGINX asigna a cada solicitud entrante.

Para configurar las proporciones de distribución, determine qué porcentaje desea dirigir a cada clúster. En este ejemplo, usamos K8s Cluster1 como «clúster grande» para producción y Cluster2 como «clúster pequeño» para las pruebas de preproducción. Si tuviera un clúster pequeño para el entorno de ensayo, podría usar una proporción de 90:10 y probar el 10 % del tráfico en el clúster pequeño para asegurarse de que todo funciona antes de implementar nuevos cambios en el clúster grande. Si le parece demasiado arriesgado, puede cambiar la proporción a 95:5. En realidad, puede elegir cualquier proporción entre el 0 y el 100 %.

Para la mayor parte del tráfico de producción en tiempo real, probablemente le convenga una proporción de 50:50, con dos clústeres del mismo tamaño. No obstante, puede establecer fácilmente otras proporciones en función del tamaño de los clústeres u otros factores. Puede establecer una proporción de 0:100 (o 100:0) y actualizar, aplicar parches, reparar o incluso sustituir un clúster entero sin tiempo de inactividad. Deje que NGINX split_clients dirija las solicitudes al clúster activo mientras resuelve los problemas del otro.

# Nginx Multi Cluster Load Balancing
# HTTP Split Clients Configuration for Cluster1:Cluster2 ratios
# Provide 100, 99, 50, 1, 0% ratios  (add/change as needed)
# Based on
# https://www.nginx.com/blog/dynamic-a-b-testing-with-nginx-plus/
# Chris Akker – Jan 2024
#
 
split_clients $request_id $split100 {
   * cluster1-cafe;                     # All traffic to cluster1
   } 

split_clients $request_id $split99 {
   99% cluster1-cafe;                   # 99% cluster1, 1% cluster2
   * cluster2-cafe;
   } 
 
split_clients $request_id $split50 { 
   50% cluster1-cafe;                   # 50% cluster1, 50% cluster2
   * cluster2-cafe;
   }
    
split_clients $request_id $split1 { 
   1.0% cluster1-cafe;                  # 1% to cluster1, 99% to cluster2
   * cluster2-cafe;
   }

split_clients $request_id $split0 { 
   * cluster2-cafe;                     # All traffic to cluster2
   }
 
# Choose which cluster upstream based on the ratio
 
map $split_level $upstream { 
   100 $split100; 
   99 $split99; 
   50 $split50; 
   1.0 $split1; 
   0 $split0;
   default $split50;
}

Puede añadir o editar la configuración anterior para adaptarla a las proporciones que necesite (por ejemplo, 90:10, 80:20, 60:40, etc.).

Nota: NGINX también dispone de un módulo Split Clients para conexiones TCP en el contexto de flujo, que puede utilizarse para tráfico que no sea HTTP. Este módulo divide el tráfico en función de las nuevas conexiones TCP, en lugar de las solicitudes HTTP.

Almacén de pares clave-valor de NGINX Plus

La siguiente función que puede utilizar es el almacén de clave-valor de NGINX Plus. Se trata de un objeto de clave-valor ubicado en una zona de memoria compartida de NGINX que puede utilizarse para muchos casos de uso diferentes de almacenamiento de datos. En este caso, lo utilizamos para almacenar el valor de la proporción de división mencionado en la sección anterior. NGINX Plus permite modificar cualquier registro de clave-valor sin necesidad de recargar NGINX. De este modo, puede cambiar este valor de división mediante una llamada a la API, lo que permite crear la función de división dinámica.

Según nuestro ejemplo, tendría este aspecto:

{“cafe.example.com”:90}

Este registro KeyVal se interpreta así:
La clave es el nombre de host «cafe.example.com»
El valor es «90» para la proporción de distribución

En lugar de codificar de forma fija la proporción de distribución en los archivos de configuración de NGINX, puede utilizar la memoria de clave-valor. De este modo, no es necesario recargar NGINX para cambiar un valor de distribución estático.

En este ejemplo, NGINX está configurado para usar una proporción de 90:10, asignando el 90 % al clúster grande Cluster1 y el 10 % restante al clúster pequeño Cluster2. Como se trata de un registro de clave-valor, puede cambiar esta proporción mediante la API de NGINX Plus dinámicamente sin necesidad de recargar la configuración. El módulo Split Clients utilizará el nuevo valor de la proporción en cuanto lo cambie, a partir de la siguiente solicitud.

Cree el registro de clave-valor, comenzando con una proporción de 50/50:

Añada un nuevo registro al almacén KeyValue enviando un comando de API a NGINX Plus:

curl -iX POST -d '{"cafe.example.com":50}' http://nginxlb:9000/api/8/http/keyvals/split

Cambie el registro KV para establecer una proporción de 90/10:

Cambie la proporción de división de KeyVal a 90 mediante un método HTTP PATCH para actualizar el registro de KeyVal en memoria:

curl -iX PATCH -d '{"cafe.example.com":90}' http://nginxlb:9000/api/8/http/keyvals/split

A continuación, el equipo de pruebas de preproducción verifica que el nuevo código de la aplicación está listo, usted lo implementa en el clúster de gran tamaño Cluster1 y cambia la proporción al 100 %. Esto envía inmediatamente todo el tráfico a Cluster1 y su nueva aplicación queda «activa» sin interrumpir el tráfico, sin cortes del servicio, ventanas de mantenimiento, reinicios, recargas ni multitud de incidencias. Basta con una llamada a la API para cambiar esta proporción de distribución cuando usted decida.

Por supuesto, si es tan fácil pasar del 90 % al 100 %, también puede cambiar fácilmente la proporción de 100:0 a 50:50 (o incluso a 0:100). De este modo, puede disponer de un clúster de respaldo activo o escalar horizontalmente sus clústeres con nuevos recursos. Yendo aún más lejos, puede incluso crear desde cero un nuevo clúster con el software y el hardware más recientes y los últimos parches de software, desplegar la aplicación y migrar el tráfico de forma gradual sin interrumpir ni una sola conexión.

Casos de uso

El uso del módulo Split Clients de HTTP con el almacén de pares clave-valor dinámico permite implementar los siguientes casos de uso:

• Equilibrado de carga activo-activo – Para equilibrar la carga entre varios clústeres.
• Equilibrado de carga activo-pasivo – Para equilibrar la carga entre clústeres y aplicaciones principales, de respaldo y de recuperación ante desastres.
• Pruebas A/B, blue-green y canary – Se utilizan con nuevas aplicaciones de Kubernetes.
• Escalado horizontal del clúster – Añade más recursos al clúster y modifica la proporción cuando esté listo.
• Actualizaciones de clúster sin interrupciones – Permite utilizar un clúster mientras se actualiza, parchea o repara el otro.
• Conmutación por error instantánea – Si uno de los clústeres tiene un problema grave, puede cambiar la proporción para utilizar el otro clúster.

Ejemplos de configuración

Este es un ejemplo de la configuración de clave-valor:

# Define Key Value store, backup state file, timeout, and enable sync 
keyval_zone zone=split:1m state=/var/lib/nginx/state/split.keyval timeout=365d sync;

keyval $host $split_level zone=split;

Y este es un ejemplo de la configuración de la aplicación cafe.example.com:

# Define server and location blocks for cafe.example.com, with TLS
server {
   listen 443 ssl;
   server_name cafe.example.com; 

   status_zone https://cafe.example.com;
      
   ssl_certificate /etc/ssl/nginx/cafe.example.com.crt; 
   ssl_certificate_key /etc/ssl/nginx/cafe.example.com.key;
   
   location / {
   status_zone /;
   
   proxy_set_header Host $host;
   proxy_http_version 1.1;
   proxy_set_header "Connection" "";
   proxy_pass https://$upstream;   # traffic split to upstream blocks
   
   }

# Define 2 upstream blocks – one for each cluster
# Servers managed dynamically by NLK, state file backup

# Cluster1 upstreams
 
upstream cluster1-cafe {
   zone cluster1-cafe 256k;
   least_time last_byte;
   keepalive 16;
   #servers managed by NLK Controller
   state /var/lib/nginx/state/cluster1-cafe.state; 
}
 
# Cluster2 upstreams
 
upstream cluster2-cafe {
   zone cluster2-cafe 256k;
   least_time last_byte;
   keepalive 16;
   #servers managed by NLK Controller
   state /var/lib/nginx/state/cluster2-cafe.state; 
}

Las direcciones IP y los puertos de los servidores upstream son gestionados por NGINX Loadbalancer for Kubernetes, un nuevo controlador que también utiliza la API de NGINX Plus para configurar NGINX Plus dinámicamente. Encontrará más información en la siguiente sección.

Veamos la evolución del tráfico HTTP dividido a lo largo del tiempo con Grafana, una popular herramienta de monitorización y visualización. Se utiliza NGINX Prometheus Exporter (basado en njs) para exportar todas las métricas de NGINX Plus, que posteriormente Grafana recopila y representa gráficamente. Puede consultar los detalles para configurar Prometheus y Grafana aquí.

En el gráfico hay cuatro servidores upstream: dos para Cluster1 y dos para Cluster2. Utilizamos una herramienta de generación de carga HTTP para crear solicitudes HTTP y enviarlas a NGINX Plus.

En los tres gráficos siguientes, se puede observar que la proporción de distribución es de 50:50 al principio del gráfico.

A continuación, la proporción cambia a 10:90 a las 12:56:30.

Después, cambia a 90:10 a las 13:00:00.

Puedes encontrar configuraciones funcionales de Prometheus y Grafana en el repositorio de GitHub de NGINX Loadbalancer for Kubernetes.

Upstreams HTTP dinámicos: balanceador de carga NGINX para Kubernetes

Puede cambiar la configuración estática de NGINX Upstream por upstreams dinámicos del clúster mediante la API de NGINX Plus y el controlador NGINX Loadbalancer for Kubernetes. Este proyecto gratuito es un controlador de Kubernetes que supervisa NGINX Ingress Controller y actualiza automáticamente una instancia externa de NGINX Plus configurada para el balanceo de carga TCP/HTTP. Su diseño es muy sencillo y resulta fácil de instalar y utilizar. Con esta solución, puede implementar el balanceo de carga TCP/HTTP en entornos de Kubernetes, lo que garantiza que las nuevas aplicaciones y servicios se detecten de inmediato y estén disponibles para recibir tráfico, sin necesidad de recargar la configuración.

Arquitectura y flujo

NGINX Loadbalancer for Kubernetes se ejecuta dentro de un clúster de Kubernetes. Está registrado en Kubernetes para supervisar el servicio NGINX Ingress Controller (nginx-ingress). Cuando se produce un cambio en los controladores de Ingress, NGINX Loadbalancer for Kubernetes recopila las direcciones IP de los nodos de trabajo y los números de puerto TCP de NodePort y, a continuación, envía las direcciones IP y los puertos a NGINX Plus a través de la API de NGINX Plus.

Los servidores ascendentes de NGINX se actualizan sin necesidad de recargar la configuración, y NGINX Plus distribuye el tráfico entre los servidores ascendentes y los NodePorts de Kubernetes adecuados. Se pueden añadir más instancias de NGINX Plus para lograr una alta disponibilidad.

Una instantánea del balanceador de carga NGINX para Kubernetes en acción

En la siguiente captura de pantalla, se muestran dos ventanas que demuestran que NGINX Loadbalancer para Kubernetes está desplegado y funcionando:

1. Tipo de servicio – LoadBalancer para nginx-ingress
2. IP externa – Se conecta a los servidores NGINX Plus
3. Puertos – NodePort se asigna a 443:30158 con los servidores upstream de NGINX correspondientes (como se muestra en el panel de control en tiempo real)
4. Registros – Indica que el balanceador de carga NGINX para Kubernetes está enviando datos correctamente a NGINX Plus

Nota: En este ejemplo, los nodos de trabajo de Kubernetes son 10.1.1.8 y 10.1.1.10

Añadir funciones de seguridad de NGINX Plus

A medida que aumenta el número de aplicaciones que se ejecutan en Kubernetes y están expuestas a la Internet pública, la seguridad se vuelve imprescindible. Afortunadamente, NGINX Plus cuenta con funciones de seguridad de nivel empresarial que permiten crear una arquitectura por capas con defensa en profundidad.

Con NGINX Plus delante de sus clústeres y ejecutando la función split_clients, ¿por qué no aprovechar su presencia para añadir algunas funciones de seguridad útiles? Estas son algunas de las funciones de NGINX Plus que podrían utilizarse para mejorar la seguridad, junto con enlaces y referencias a otra documentación que puede servir para configurarlas, probarlas e implementarlas.

• Listas de bloqueo/permitidos de IP – Controlan el acceso en función de la dirección IP de origen. Puede consultar una guía de configuración sobre el uso del almacén de clave-valor de NGINX Plus para gestionar listas dinámicas de bloqueo/permitidos de IP mediante la API de Plus en la página Bloqueo dinámico de direcciones IP de la documentación de NGINX.
• Limitación de velocidad – Controla el número de conexiones TCP, las solicitudes HTTP y el uso del ancho de banda de aplicaciones, endpoints de API y descargas multimedia. Para obtener más información sobre la limitación de velocidad con NGINX, consulte Limitación del acceso a recursos HTTP mediante proxy en la documentación de NGINX y las entradas del blog Limitación de velocidad con NGINX y NGINX Plus y Límites dinámicos de ancho de banda mediante el almacén de clave-valor de NGINX Plus.
• Módulo dinámico GeoIP2 – Recopila metadatos de ubicación basándose en la dirección IP de origen. Obtenga más información al respecto en la página Restricción del acceso por ubicación geográfica de la documentación de NGINX.
• Módulo JWT y OpenID Connect (OIDC) – Controla el acceso de los usuarios mediante protocolos estándar del sector. Encontrará más información al respecto en la página Configuración de la autenticación JWT de la documentación de NGINX.
• NGINX App Protect – Un firewall de aplicaciones web ligero y de baja latencia que protege frente a amenazas existentes y emergentes.

Empieza hoy mismo

Si te frustran los problemas de red en el perímetro de tu clúster de Kubernetes, te recomendamos probar esta solución multiclúster de NGINX. Prueba el software NGINX Loadbalancer for Kubernetes y cuéntanos qué te parece. El código fuente es de código abierto (bajo la licencia Apache 2.0) y todas las instrucciones de instalación están disponibles en GitHub.

Para enviarnos tus comentarios, deja un comentario en el repositorio o escríbenos en el Slack de la comunidad de NGINX.

Sobre el autor

Chris Akker

Más artículos de Chris Akker