Presentamos NGINX Plus R16

Liam CrillyDirector sénior de Gestión de Producto

[ngx_snippet name=’table-style-blog’]
Nos complace anunciar que NGINX Plus Release 16 (R16) ya está disponible. La versión de hoy es una de las más importantes para hacer realidad la visión tecnológica de NGINX. Con R16, NGINX Plus funciona ahora como una única capa elástica de entrada y salida para todas sus aplicaciones. Esto significa que puede consolidar las funciones de un balanceador de carga, una puerta de enlace de API y un WAF en un único paquete de software compatible con cualquier nube.

Muchas de las empresas con las que hablamos hoy en día cuentan con cada uno de estos componentes, pero a menudo son de distintos proveedores. Esto aumenta los costes y la complejidad, ya que los equipos de operaciones tienen que gestionar cada solución específica por separado. También reduce el rendimiento y la fiabilidad, pues cada salto adicional aumenta la latencia y añade posibles puntos de fallo.

Con las nuevas funciones de NGINX Plus R16, puede empezar a consolidar y simplificar su infraestructura y avanzar hacia el diseño de una capa elástica de entrada y salida para aplicaciones tanto heredadas como modernas. NGINX Plus R16 incluye nuevas funciones de agrupación en clústeres, balanceo de carga UDP mejorado y mitigación de ataques DDoS, lo que lo convierte en una alternativa más completa al costoso hardware F5 BIG-IP y a otras infraestructuras de balanceo de carga. La nueva compatibilidad con la limitación global de la tasa de solicitudes convierte además a NGINX Plus en una alternativa ligera a muchas soluciones de puerta de enlace de API. Por último, la nueva compatibilidad con el algoritmo de balanceo de carga «Random with Two Choices» hace de NGINX Plus la opción ideal para balancear el tráfico de microservicios en entornos escalados o distribuidos, como Kubernetes.

Resumen de las nuevas funciones de NGINX Plus R16

Las nuevas funciones de NGINX Plus R16 incluyen:

• Limitación de velocidad con reconocimiento del clúster – En NGINX Plus R15 presentamos el módulo de uso compartido del estado, que permite sincronizar datos en todo un clúster de NGINX Plus. En esta versión, el uso compartido del estado se amplía a la función de limitación de velocidad, lo que permite especificar límites de velocidad globales en todo un clúster de NGINX Plus. La limitación de velocidad global es una función importante para las puertas de enlace de API y un caso de uso extremadamente popular de NGINX Plus.
• Almacén de clave-valor compatible con clústeres – En NGINX Plus R13 presentamos un almacén de clave-valor que puede utilizarse, por ejemplo, para crear una lista dinámica de bloqueo de direcciones IP o gestionar redirecciones HTTP. En esta versión, el almacén de clave-valor ahora puede sincronizarse en todo un clúster e incluye un nuevo parámetro timeout, que permite eliminar automáticamente pares de clave-valor individuales. Gracias a la nueva compatibilidad con la sincronización, el almacén de clave-valor ahora puede utilizarse para proporcionar mitigación dinámica de ataques DDoS, distribuir tokens de sesión autenticados o crear una caché de contenido distribuida (CDN).
• Balanceo de carga aleatorio con dos opciones – Al agrupar balanceadores de carga en un clúster, es importante utilizar un algoritmo de balanceo de carga que no sobrecargue accidentalmente servidores backend concretos. El balanceo de carga aleatorio con dos opciones es extremadamente eficiente para clústeres escalables y será el método predeterminado en la próxima versión de NGINX Ingress Controller para Kubernetes.
• Equilibrado de carga UDP mejorado – En NGINX Plus R9 introdujimos por primera vez el equilibrado de carga UDP. Esta implementación inicial se limitaba a aplicaciones UDP que esperan un único paquete UDP del cliente por cada interacción con el servidor (como DNS y RADIUS). NGINX Plus R16 puede gestionar varios paquetes UDP del cliente, lo que nos permite admitir protocolos UDP más complejos, como OpenVPN, voz sobre IP (VoIP) e infraestructura de escritorios virtuales (VDI).
• Compatibilidad con AWS PrivateLink – AWS PrivateLink es la tecnología de Amazon para crear túneles VPN seguros hacia una nube privada virtual. Con esta versión, ahora puede autenticar, enrutar y equilibrar la carga del tráfico, así como optimizar su flujo dentro de un centro de datos de AWS PrivateLink. Esta funcionalidad se basa en la nueva compatibilidad con el protocolo PROXY v2.

Otras mejoras incluyen compatibilidad con tokens de sesión opacos de OpenID Connect, el módulo dinámico Encrypted Session, actualizaciones del módulo NGINX JavaScript y mucho más. NGINX Plus R16 se basa en NGINX Open Source 1.15.2 e incluye todas las funcionalidades de la versión de código abierto.

Durante el desarrollo de NGINX Plus R16, también añadimos varias mejoras importantes al controlador Ingress oficial de NGINX para Kubernetes, uno de los casos de uso más destacados de NGINX Plus.

Obtén más información sobre NGINX Plus R16 y todo lo relacionado con NGINX en NGINX Conf 2018. Contaremos con sesiones específicas, demostraciones y expertos disponibles para profundizar en todas las nuevas funcionalidades.

Cambios importantes en el comportamiento

• Se han eliminado las API Upstream Conf y Status, sustituidas y declaradas obsoletas por la API unificada de NGINX Plus. En agosto de 2017, NGINX Plus R13 presentó la nueva API de NGINX Plus para la reconfiguración dinámica de grupos de servidores upstream y la supervisión de métricas, en sustitución de las API Upstream Conf y Status que anteriormente implementaban esas funciones. Tal como se anunció en su momento, las API obsoletas siguieron estando disponibles y recibiendo soporte durante un periodo considerable, que ya ha finalizado. Si su configuración incluye las directivas upstream_conf o status, debe sustituirlas por la directiva api como parte de la actualización a R16. Para obtener orientación y ayuda para migrar a la nueva API de NGINX Plus, consulte la guía de transición en nuestro blog o póngase en contacto con nuestro equipo de soporte.
• Fin de la compatibilidad con versiones de sistemas operativos que han llegado al final de su vida útil – NGINX Plus ya no es compatible con Ubuntu 17.10 (Artful), FreeBSD 10.3 ni FreeBSD 11.0. Para obtener más información sobre las plataformas compatibles, consulte las especificaciones técnicas de NGINX Plus y los módulos dinámicos.
• El complemento NGINX New Relic se ha actualizado para utilizar la nueva API de NGINX Plus y ahora es un proyecto de código abierto. El complemento actualizado funciona con todas las versiones de NGINX Plus a partir de la R13, pero NGINX, Inc. ya no ofrece soporte ni mantenimiento para él.

Nuevas funcionalidades en detalle

Limitación de frecuencia con reconocimiento del clúster

NGINX Plus R15 incorporó el módulo zone_sync, que permite compartir el estado en tiempo de ejecución entre todos los nodos de NGINX Plus de un clúster.

La primera función sincronizada fue la persistencia de sesión sticky‑learn. NGINX Plus R16 amplía el uso compartido del estado a la función de limitación de velocidad. Cuando se implementa en un clúster, NGINX Plus ahora puede aplicar un límite de velocidad uniforme a las solicitudes entrantes, independientemente del nodo miembro del clúster al que llegue la solicitud. Esta técnica, conocida habitualmente como limitación de velocidad global, resulta especialmente relevante para los casos de uso de puertas de enlace de API, ya que permite ofrecer API conforme a un acuerdo de nivel de servicio (SLA) que impide que los clientes superen un límite de velocidad especificado.

El uso compartido del estado de NGINX Plus no requiere ni utiliza un nodo principal: todos los nodos son pares e intercambian datos mediante una topología de malla completa. Un clúster de NGINX Plus con uso compartido del estado debe cumplir tres requisitos:

• Conectividad de red entre todos los nodos del clúster
• Relojes sincronizados
• Configuración en cada nodo que habilite el módulo «zone_sync», como en el siguiente fragmento.

stream {    resolver 10.0.0.53 valid=20s;

    server {
        listen 10.0.0.1:9000;
        zone_sync;
        zone_sync_server nginx-cluster.example.com:9000 resolve;
    }
}

The zone_sync directive enables synchronization of shared memory zones in a cluster. The zone_sync_server directive identifies the other NGINX Plus instances in the cluster. NGINX Plus supports DNS service discovery so cluster nodes can be identified by hostname, making the configuration identical on all nodes. Note that this is a minimal configuration, without the necessary security controls for production deployment. For more details, see the NGINX Plus R15 announcement and the reference documentation for the zone_sync module.

Una vez aplicada esta configuración en todos los nodos, se pueden establecer límites de solicitudes en todo el clúster simplemente añadiendo el nuevo parámetro sync a la directiva limit_req_zone. Con la siguiente configuración, NGINX Plus impone un límite de 100 solicitudes por segundo a cada cliente en función de su dirección IP.

limit_req_zone $remote_addr zone=per_ip:1M rate=100r/s sync; # Cluster-aware
server {
    listen 80;
    location / {
        limit_req zone=per_ip; # Apply rate limit here
        proxy_pass http://my_backend;
    }
}

Además, la solución de clúster con uso compartido del estado es independiente de la keepalivedsolución de alta disponibilidad basada en para garantizar la resiliencia de la red. Por lo tanto, a diferencia de dicha solución, un clúster con uso compartido del estado puede abarcar varias ubicaciones físicas.

Almacén de clave-valor compatible con clústeres

NGINX Plus R13 incorporó un almacén de clave-valor ligero y en memoria como módulo nativo de NGINX. Este módulo se incluye con NGINX Plus, lo que permite configurar soluciones que requieren un almacenamiento sencillo de bases de datos sin instalar componentes de software adicionales. Además, el almacén de clave-valor se controla mediante la API de NGINX Plus, por lo que las entradas se pueden crear, modificar y eliminar a través de una interfaz REST.

Entre los casos de uso del almacén de clave-valor de NGINX Plus se incluyen la inclusión dinámica de direcciones IP en listas de bloqueo, la limitación dinámica del ancho de banda, y el almacenamiento en caché de tokens de autenticación.

Con NGINX Plus R16, el almacén de pares clave-valor ahora es compatible con clústeres, por lo que las entradas se sincronizan en todos los nodos de un clúster. Esto significa que las soluciones que utilizan el almacén de pares clave-valor de NGINX Plus pueden implementarse en todo tipo de entornos en clúster: activo-pasivo, activo-activo y también ampliamente distribuidos.

Al igual que con las demás funciones compatibles con clústeres, puede configurar la sincronización del almacén de clave-valor simplemente añadiendo el parámetro sync a la directiva keyval_zone para un clúster que ya se haya configurado para compartir el estado (con las directivas zone_sync y zone_sync_server).

El almacén de clave-valor también se ha ampliado con la posibilidad de establecer un tiempo de espera para cada par de clave-valor que se añada. Estas entradas caducan automáticamente y se eliminan del almacén de clave-valor cuando transcurre el tiempo de espera especificado. El parámetro «timeout» es obligatorio al configurar un almacén de clave-valor sincronizado.

Uso del almacén de clave-valor de NGINX Plus para la protección dinámica contra ataques DDoS

Puede combinar las nuevas capacidades de agrupación en clúster de NGINX Plus para crear una solución avanzada de protección contra ataques DDoS. Cuando se implementa un conjunto de instancias de NGINX Plus en un clúster activo-activo o se distribuye a través de una red de área extensa, el tráfico malicioso puede llegar a cualquiera de esas instancias. Esta solución utiliza un límite de solicitudes sincronizado y un almacén de clave-valor sincronizado para responder dinámicamente a los ataques DDoS y mitigar sus efectos de la siguiente manera.

• Un límite de solicitudes con reconocimiento del clúster detecta a los clientes que envían más de 100 solicitudes por segundo, independientemente del nodo de NGINX Plus que reciba la solicitud.
• Cuando un cliente supera el límite de solicitudes, su dirección IP se añade a un almacén de pares clave-valor de «penalización» mediante una llamada a la API de NGINX Plus. Este almacén se sincroniza en todo el clúster.
• Las solicitudes posteriores de los clientes incluidos en la lista de penalización están sujetas a un límite de ancho de banda muy bajo, independientemente del nodo de NGINX Plus que las reciba. Es preferible limitar el ancho de banda que rechazar las solicitudes directamente, ya que así no se indica claramente al cliente que se están aplicando medidas de mitigación de DDoS.
• Transcurridos diez minutos, el cliente se elimina automáticamente de la lista de bloqueo.

La siguiente configuración muestra una implementación simplificada de esta solución dinámica de mitigación de DDoS.

limit_req_zone   $remote_addr zone=per_ip:1M rate=100r/s sync; # Cluster-aware rate limitlimit_req_status 429;

keyval_zone zone=sinbin:1M timeout=600 sync; # Cluster-aware "sin bin" with 
                                             # 10-minute TTL
keyval $remote_addr $in_sinbin zone=sinbin;  # Populate $in_sinbin with 
                                             # matched client IP addresses

server {
    listen 80;
    location / {
        if ($in_sinbin) {
            set $limit_rate 50; # Restrict bandwidth of bad clients
        }

        limit_req zone=per_ip;            # Apply the rate limit here
        error_page 429 = @send_to_sinbin; # Excessive clients are moved to 
                                          # this location
        proxy_pass http://my_backend;
    }

    location @send_to_sinbin {
        rewrite ^ /api/3/http/keyvals/sinbin break; # Set the URI of the 
                                                    # "sin bin" key-val
        proxy_method POST;
        proxy_set_body '{"$remote_addr":"1"}';
        proxy_pass http://127.0.0.1:80;
    }

    location /api/ {
        api write=on;
        # directives to control access to the API
    }
}

Balanceo de carga aleatorio con dos opciones

Cada vez es más habitual que tanto los entornos de entrega de aplicaciones como los de entrega de API utilicen una capa de balanceo de carga escalada o distribuida para recibir las solicitudes de los clientes y dirigirlas a un entorno de aplicaciones compartido. Cuando varios balanceadores de carga envían solicitudes al mismo conjunto de servidores backend, es importante utilizar un método de balanceo de carga que no sobrecargue involuntariamente los servidores backend individuales.

Los clústeres de NGINX Plus implementados en una configuración activo-activo, así como los entornos distribuidos con varios puntos de entrada, son escenarios habituales que pueden plantear dificultades a los métodos tradicionales de balanceo de carga, ya que cada balanceador de carga no puede conocer todas las solicitudes que se han enviado a los servidores backend.

El balanceo de carga dentro de un clúster en contenedores presenta las mismas características que un despliegue activo-activo escalado horizontalmente. Los controladores de Ingress de Kubernetes desplegados en un conjunto de réplicas con varias instancias del recurso Ingress también se enfrentan al reto de distribuir eficazmente la carga entre los pods que proporcionan cada uno de los servicios del clúster.

Topologías de clúster que se benefician del balanceo de carga aleatorio con dos opciones

La variabilidad de la carga de trabajo tiene un enorme impacto en la eficacia del balanceo de carga distribuido. Cuando cada solicitud impone la misma carga al servidor backend, medir la rapidez con la que cada servidor ha respondido a solicitudes anteriores es una forma eficaz de decidir adónde enviar la siguiente solicitud. NGINX Plus ofrece en exclusiva el método de balanceo de carga Menor tiempo («Least Time»), que hace precisamente eso. Sin embargo, cuando la carga del servidor backend es variable (por ejemplo, porque incluye operaciones tanto de lectura como de escritura), el rendimiento anterior no es un buen indicador del rendimiento futuro.

La forma más sencilla de equilibrar la carga en un entorno distribuido es elegir un servidor backend al azar. Con el tiempo, la carga se acaba compensando, pero es un enfoque rudimentario que probablemente provoque picos de tráfico ocasionales en servidores concretos.

Una variante sencilla del balanceo de carga aleatorio, pero que se ha demostrado que mejora la distribución de la carga, consiste en seleccionar al azar dos servidores backend y enviar la solicitud al que tenga menos carga. El objetivo de comparar dos opciones aleatorias es evitar una mala decisión de balanceo de carga, aunque la decisión tomada no sea óptima. Al descartar el servidor backend con mayor carga, cada balanceador de carga puede funcionar de forma independiente y, aun así, evitar enviar picos de tráfico a servidores backend concretos. Como resultado, este método ofrece las ventajas y la eficiencia computacional del balanceo de carga aleatorio, pero con una distribución de la carga demostrablemente mejor.

NGINX Plus R16 incorpora dos nuevos métodos de balanceo de carga: Aleatorio y Aleatorio con dos opciones. Para este último, puede especificar además qué métrica indicadora de carga compara NGINX Plus para decidir cuál de los dos backends seleccionados recibe la solicitud. En la siguiente tabla se enumeran las métricas disponibles.

* Todas las métricas basadas en el tiempo son exclusivas de NGINX Plus

El siguiente fragmento muestra un ejemplo sencillo de configuración de balanceo de carga «Random with Two Choices» con la directiva random two (HTTP, Stream).

upstream my_backend {    zone my_backend 64k;
    server 10.0.0.1;
    server 10.0.0.2;
    server 10.0.0.3;
    #...
    random two least_time=last_byte; # Choose the quicker response time from two random choices
}

server {
    listen 80;
    location / {
        proxy_pass http://my_backend; # Load balance to upstream group
    }
}

Tenga en cuenta que el método Aleatorio con dos opciones solo es adecuado para entornos distribuidos en los que varios balanceadores de carga envían solicitudes al mismo conjunto de servidores backend. No lo utilice cuando NGINX Plus esté implementado en un único host o en una configuración activo-pasivo. En esos casos, el único balanceador de carga tiene una visión completa de todas las solicitudes, y los métodos Round Robin, Menos conexiones y Menor tiempo ofrecen los mejores resultados.

Equilibrado de carga UDP mejorado

NGINX Plus R9 incorporó compatibilidad con el proxy y el balanceo de carga del tráfico UDP, lo que permite situar NGINX Plus delante de aplicaciones UDP populares, como DNS, syslog, NTP y RADIUS, para proporcionar alta disponibilidad y escalabilidad a los servidores de aplicaciones. La implementación inicial se limitaba a las aplicaciones UDP que esperan un único paquete UDP del cliente por cada interacción con el servidor.

Con NGINX Plus R16, se admiten varios paquetes entrantes, lo que permite utilizar un proxy y equilibrar la carga de aplicaciones UDP más complejas. Entre ellas se incluyen OpenVPN, VoIP, soluciones de escritorio virtual y sesiones de seguridad de la capa de transporte de datagramas (DTLS). Además, el procesamiento de todas las aplicaciones UDP por parte de NGINX Plus, ya sean simples o complejas, también es considerablemente más rápido.

NGINX Plus es el único balanceador de carga de software que permite balancear la carga de cuatro de los protocolos web más populares —UDP, TCP, HTTP y HTTP/2— en una misma instancia y al mismo tiempo.

Compatibilidad con el protocolo PROXY v2

NGINX Plus R16 incorpora compatibilidad con la cabecera del protocolo PROXY v2 (PPv2), así como la capacidad de inspeccionar valores personalizados de tipo-longitud-valor (TLV) en la cabecera.

El protocolo PROXY se utiliza en proxies de capa 7, como NGINX Plus y los balanceadores de carga de Amazon, para transmitir información de conexión a servidores ascendentes situados detrás de otro conjunto de proxies de capa 7 o de dispositivos NAT. Es necesario porque cierta información de conexión, como la dirección IP y el puerto de origen, puede perderse cuando los proxies retransmiten las conexiones, y no siempre es posible recurrir a la inserción de cabeceras HTTP para transmitir esta información. Las versiones anteriores de NGINX Plus admitían la cabecera PPv1; NGINX Plus R16 añade compatibilidad con la cabecera PPv2.

Uso de PPv2 con Amazon Network Load Balancer

Un caso de uso de la cabecera PPv2 son las conexiones que se retransmiten mediante Network Load Balancer (NLB) de Amazon, que pueden parecer proceder de una dirección IP privada del balanceador de carga. NLB antepone a cada conexión una cabecera PPv2 que identifica la dirección IP de origen real y el puerto de la conexión del cliente. El origen real se puede obtener de la variable $proxy_protocol_addr, y puede utilizar el módulo realip para sobrescribir las variables de origen internas de NGINX con los valores de la cabecera PPv2.

Uso de PPv2 con AWS PrivateLink

AWS PrivateLink es la tecnología de Amazon para crear túneles VPN seguros hacia una nube privada virtual (VPC). Se utiliza habitualmente para publicar un servicio de proveedor (que se ejecuta en la VPC del proveedor) y ponerlo a disposición de una o varias VPC de clientes. Las conexiones al servicio de proveedor se originan en un NLB que se ejecuta en la VPC del proveedor.

En muchos casos, el servicio del proveedor necesita saber de dónde procede cada conexión, pero la dirección IP de origen de la cabecera PPv2 carece prácticamente de significado, ya que corresponde a una dirección interna no enrutable de la VPC del cliente. El NLB de AWS PrivateLink añade el ID de la VPC de origen a la cabecera mediante el registro TLV de PPv2 0xEA.

NGINX Plus puede inspeccionar los registros TLV de PPv2 y extraer el ID de la VPC de origen de las conexiones de AWS PrivateLink mediante la variable $proxy_protocol_tlv_0xEA. Esto permite autenticar, enrutar y controlar el tráfico en un centro de datos de AWS PrivateLink.

Otras novedades de NGINX Plus R16

Tokens de sesión opacos de OpenID Connect

La implementación de referencia de OpenID Connect de NGINX Plus se ha ampliado para admitir tokens de sesión opacos. En este caso de uso, el token de identidad JWT no se envía al cliente. En su lugar, se almacena en el almacén de clave-valor de NGINX Plus y se envía una cadena aleatoria en su lugar. Cuando el cliente presenta la cadena aleatoria, esta se intercambia por el JWT y se valida. Este caso de uso ha pasado de ser un prototipo o una función experimental a estar listo para producción, ahora que las entradas del almacén de clave-valor pueden tener un tiempo de espera y sincronizarse en todo un clúster.

Módulo dinámico de sesión cifrada

El módulo comunitario Encrypted Session ofrece compatibilidad con el cifrado y descifrado de variables de NGINX mediante AES‑256 con MAC. Ahora está disponible en el repositorio de NGINX Plus como módulo dinámico compatible con NGINX Plus.

Mejoras del módulo JavaScript de NGINX

Los módulos JavaScript de NGINX en R16 incluyen varias ampliaciones del alcance de la compatibilidad con el lenguaje JavaScript. El módulo JavaScript de HTTP se ha simplificado para que un único objeto (r) permita ahora acceder tanto a los atributos de solicitud como a los de respuesta asociados a cada solicitud. Anteriormente había objetos independientes para la solicitud (req) y la respuesta (res). Esta simplificación hace que el módulo JavaScript de HTTP sea coherente con el módulo JavaScript de Stream, que tiene un único objeto de sesión (s). Este cambio es totalmente retrocompatible —el código JavaScript existente seguirá funcionando sin modificaciones—, pero recomendamos modificarlo para aprovechar esta simplificación, así como aplicarla al código que escriba en el futuro.

La compatibilidad con el lenguaje JavaScript ahora incluye:

• Métodos de cadena: bytesFrom(), padStart(), y padEnd()
• Métodos adicionales: getrandom() y getentropy()
• Literales binarios

La lista completa de cambios del módulo de JavaScript está documentada en el registro de cambios.

Nueva variable $ssl_preread_protocol Variable

La nueva variable $ssl_preread_protocol permite distinguir entre SSL/TLS y otros protocolos al reenviar tráfico mediante un proxy TCP (de flujo). La variable contiene la versión más reciente del protocolo SSL/TLS compatible con el cliente. Esto resulta útil si desea evitar las restricciones del cortafuegos ejecutando, por ejemplo, servicios SSL/TLS y SSH en el mismo puerto.

Para obtener más información, consulte «Ejecución de protocolos SSL y no SSL en el mismo puerto» en nuestro blog.

Mejoras del controlador de Ingress de Kubernetes

NGINX Plus puede gestionar el tráfico en una amplia variedad de entornos, y uno de sus principales casos de uso es como balanceador de carga de entrada para Kubernetes. NGINX desarrolla una solución de controlador de entrada que configura automáticamente NGINX Plus, y esta integración cuenta con soporte completo para todos los suscriptores de NGINX Plus. (Todos los usuarios de NGINX Open Source y los clientes de NGINX Plus pueden encontrar la implementación de código abierto en GitHub, y periódicamente se publican versiones oficiales.)

NGINX Plus puede terminar SSL, enrutar y equilibrar la carga del tráfico de Kubernetes

Durante el desarrollo de NGINX Plus R16, se han incorporado varias mejoras importantes al controlador de entrada NGINX oficial para Kubernetes:

• Compatibilidad con Prometheus permite a los usuarios exportar las métricas de NGINX y NGINX Plus directamente a Prometheus en Kubernetes.
• La compatibilidad con los gráficos de Helm simplifica la instalación y la gestión del controlador Ingress.
• Compatibilidad con el balanceo de carga del tráfico gRPC proporciona alta disponibilidad y escalabilidad para aplicaciones basadas en gPRC. (Añadido en la versión 1.2.0.)
• Las comprobaciones de estado activas de los pods de Kubernetes detectan rápidamente fallos en los pods y en la conectividad de red.
• Configuración multiinquilino y combinable permite separar responsabilidades, de modo que los equipos puedan gestionar de forma independiente distintas rutas de una misma aplicación web, mientras que el equipo de operaciones mantiene el control del listener del frontend y de la configuración SSL.
• Autenticación JWT granular, aplicada a cada ruta, ofrece un mayor control sobre la autenticación en aplicaciones avanzadas.
• La gestión directa de las plantillas de configuración facilita considerablemente el desarrollo y las pruebas de cambios personalizados en la configuración de NGINX.

NGINX Ingress Controller se puede ampliar aún más mediante ConfigMaps (para integrar la configuración de NGINX) o editando las plantillas base, lo que permite a los usuarios acceder a todas las funcionalidades de NGINX al crear políticas de gestión del tráfico para sus aplicaciones que se ejecutan en Kubernetes.

Para obtener más información, consulte Anuncio de NGINX Ingress Controller para Kubernetes, versión 1.3.0 en nuestro blog.

Actualice o pruebe NGINX Plus

NGINX Plus R16 incluye funciones adicionales de agrupación en clústeres, limitación global de la tasa de solicitudes, un nuevo algoritmo de balanceo de carga y varias correcciones de errores. Si utiliza NGINX Plus, le recomendamos encarecidamente que actualice a R16 lo antes posible. Obtendrá diversas correcciones y mejoras, y facilitará que NGINX, Inc. pueda ayudarle cuando necesite abrir una incidencia de soporte.

Revise detenidamente las nuevas funcionalidades y los cambios de comportamiento descritos en esta entrada del blog antes de proceder con la actualización.

Si aún no ha probado NGINX Plus, le animamos a hacerlo, ya sea para acelerar sitios web, equilibrar la carga y distribuir aplicaciones, o como servidor web con soporte completo y API avanzadas de supervisión y gestión. Puede empezar hoy mismo de forma gratuita con una prueba gratuita de 30 días. Compruebe por sí mismo cómo NGINX Plus puede ayudarle a distribuir y escalar sus aplicaciones.

Sobre el autor

Liam CrillyDirector sénior de Gestión de Producto

Más artículos de Liam Crilly