Anunciamos NGINX Plus R16

[ngx_snippet name='blog de estilo de tabla']
Nos complace anunciar que NGINX Plus Release 16 (R16) ya está disponible. El lanzamiento de hoy es uno de los más importantes en el avance de la visión técnica de NGINX. Con R16, NGINX Plus ahora funciona como un único nivel de ingreso y egreso elástico para todas sus aplicações. Lo que esto significa es que puede consolidar la funcionalidad de un balanceador de carga, un API gateway y un WAF en un único paquete de software que abarca cualquier nube.

Muchas de las empresas con las que hablamos hoy tienen cada uno de estos componentes, pero a menudo de diferentes proveedores. Esto aumenta los costos y la complejidad, ya que los equipos de operaciones tienen que gestionar cada solución puntual por separado. También reduce el rendimiento y la confiabilidad ya que cada salto adicional agrega latencia adicional y puntos de falla.

Con las nuevas características de NGINX Plus R16 , puede comenzar a consolidar y simplificar su infraestructura, avanzando hacia la arquitectura de un nivel de ingreso/egreso elástico tanto para aplicações antiguas como modernas. NGINX Plus R16 incluye nuevas funciones de agrupamiento, equilibrio de carga UDP mejorado y mitigación de DDoS que lo convierten en un reemplazo más completo para el costoso hardware F5 BIG-IP y otra infraestructura de equilibrio de carga. El nuevo soporte para limitación de velocidad global convierte a NGINX Plus en una alternativa liviana a muchas soluciones de puerta de enlace API. Finalmente, el nuevo soporte para equilibrio de carga aleatorio con dos opciones hace que NGINX Plus sea la opción ideal para equilibrar la carga del tráfico de microservicios en entornos escalados o distribuidos, como Kubernetes.

Resumen de las nuevas características de NGINX Plus R16

Las nuevas características de NGINX Plus R16 incluyen:

• Limitación de velocidad consciente del clúster : en NGINX Plus R15 presentamos el módulo de uso compartido de estado , que permite sincronizar datos en un clúster NGINX Plus. En esta versión, el uso compartido de estado se extiende a la función de limitación de velocidad , lo que le permite especificar límites de velocidad globales en un clúster NGINX Plus. La limitación de velocidad global es una característica importante para las puertas de enlace API y es un caso de uso extremadamente popular para NGINX Plus.
• Almacén de valores clave consciente del clúster : en NGINX Plus R13 presentamos un almacén de valores clave que se puede usar, por ejemplo, para crear una lista negra de direcciones IP dinámicas o administrar redirecciones HTTP . En esta versión, el almacén de clave-valor ahora se puede sincronizar en un clúster e incluye un nuevo parámetro de tiempo de espera , de modo que los pares clave-valor individuales se pueden eliminar automáticamente. Con el nuevo soporte de sincronización, el almacén de clave-valor ahora se puede usar para proporcionar mitigación dinámica de DDoS , distribuir tokens de sesión autenticados o crear un caché de contenido distribuido (CDN).
• Equilibrio de carga aleatorio con dos opciones : al agrupar balanceadores de carga, es importante utilizar un algoritmo de equilibrio de carga que no sobrecargue inadvertidamente servidores back-end individuales. El equilibrio de carga aleatorio con dos opciones es extremadamente eficiente para clústeres escalados y será el método predeterminado en la próxima versión de NGINX Ingress Controller para Kubernetes.
• Equilibrio de carga UDP mejorado : en NGINX Plus R9 presentamos por primera vez el equilibrio de carga UDP. Esta implementación inicial se limitó a las aplicações UDP que esperan un solo paquete UDP del cliente por cada interacción con el servidor (como DNS y RADIUS). NGINX Plus R16 puede manejar múltiples paquetes UDP del cliente, lo que nos permite admitir protocolos UDP más complejos como OpenVPN, voz sobre IP (VoIP) e infraestructura de escritorio virtual (VDI).
• Compatibilidad con AWS PrivateLink : AWS PrivateLink es la tecnología de Amazon para crear túneles VPN seguros en una nube privada virtual. Con esta versión, ahora puede autenticar, enrutar, equilibrar la carga del tráfico y optimizar el flujo del tráfico dentro de un centro de datos de AWS PrivateLink. Esta funcionalidad se basa en el nuevo soporte para el protocolo PROXY v2 .

Las mejoras adicionales incluyen soporte para tokens de sesión opacos de OpenID Connect, el módulo dinámico de sesión cifrada, actualizaciones del módulo JavaScript de NGINX y mucho más. NGINX Plus R16 se basa en NGINX Open Source 1.15.2 e incluye todas las características de la versión de código abierto.

Durante el desarrollo de NGINX Plus R16 , también agregamos una serie de mejoras significativas al controlador de ingreso NGINX oficial para Kubernetes, un caso de uso destacado para NGINX Plus.

Obtenga más información sobre NGINX Plus R16 y todo lo relacionado con NGINX en NGINX Conf 2018 . Tendremos sesiones dedicadas, demostraciones y expertos disponibles para profundizar en todas las nuevas capacidades.

Cambios importantes en el comportamiento

• Se han eliminado las API Upstream Conf y Status, reemplazadas y obsoletas por la API unificada NGINX Plus . En agosto de 2017, NGINX Plus R13 introdujo la nueva API NGINX Plus para la reconfiguración dinámica de grupos ascendentes y métricas de monitoreo, reemplazando las API Upstream Conf y Status que anteriormente implementaban esas funciones. Como se anunció en su momento , las API obsoletas continuaron estando disponibles y recibiendo soporte durante un período de tiempo significativo, que ya ha finalizado. Si su configuración incluye las directivas upstream_conf y/o status , debe reemplazarlas con la directiva api como parte de la actualización a R16.

  Para obtener asesoramiento y asistencia para migrar a la nueva API NGINX Plus , consulte la guía de transición en nuestro blog o comuníquese con nuestro equipo de soporte.

• Soporte discontinuado para versiones de SO al final de su vida útil : NGINX Plus ya no recibe soporte en Ubuntu 17.10 (Artful) , FreeBSD 10.3 o 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 NGINX Plus y ahora es un proyecto de código abierto. El complemento actualizado funciona con todas las versiones de NGINX Plus desde R13 en adelante, pero NGINX, Inc. ya no lo soporta ni lo mantiene.

Nuevas funciones en detalle

Limitación de velocidad con reconocimiento de clústeres

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

La primera característica sincronizada fue la persistencia de la sesión de aprendizaje continuo . NGINX Plus R16 extiende la compartición de 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 consistente a las solicitudes entrantes independientemente del nodo miembro del clúster al que llegue la solicitud. Comúnmente conocido como limitación de velocidad global , la aplicación de un límite de velocidad consistente en un clúster es particularmente relevante para los casos de uso de API Gateway, que entregan API a un acuerdo de nivel de servicio (SLA) que evita que los clientes excedan un límite de velocidad específico.

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

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

stream { resolver 10.0.0.53 válido=20s; servidor { escuchar 10.0.0.1:9000; sincronización_de_zona ; servidor_de_sincronización_de_zona nginx-cluster.example.com:9000 resolver; } }

La directiva zone_sync habilita la sincronización de zonas de memoria compartida en un clúster. La directiva zone_sync_server identifica las otras instancias de NGINX Plus en el clúster. NGINX Plus admite el descubrimiento de servicios DNS para que los nodos del clúster puedan identificarse por nombre de host, lo que hace que la configuración sea idéntica en todos los nodos. Tenga en cuenta que esta es una configuración mínima, sin los controles de seguridad necesarios para la implementación de producción. Para obtener más detalles, consulte el anuncio de NGINX Plus R15 y la documentación de referencia del módulo zone_sync .

Una vez que esta configuración esté implementada en todos los nodos, se pueden aplicar límites de velocidad en todo un clúster simplemente agregando el nuevo parámetro de sincronización a la directiva limit_req_zone . Con la siguiente configuración, NGINX Plus impone un límite de velocidad de 100 solicitudes por segundo a cada cliente, según la dirección IP del cliente.

limit_req_zone $remote_addr zone=per_ip:1M rate=100r/s sync ; # Servidor compatible con clústeres { listen 80; location / { limit_req zone=per_ip; # Aplicar límite de velocidad aquí proxy_pass http://my_backend; } }

Además, la solución de agrupamiento con intercambio de estados es independiente de la solución de alta disponibilidad basada en keepalived para la resiliencia de la red. Por lo tanto, a diferencia de esa solución, un clúster que comparte estados puede abarcar ubicaciones físicas.

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

NGINX Plus R13 introdujo un almacén de valores clave liviano y en memoria como un módulo nativo de NGINX. Este módulo se entrega con NGINX Plus, lo que permite configurar soluciones que requieren un almacenamiento de base de datos simple sin instalar componentes de software adicionales. Además, el almacén de valores clave se controla a través de la API NGINX Plus, de modo que las entradas se pueden crear, modificar y eliminar a través de una interfaz REST.

Los casos de uso del almacén de clave-valor NGINX Plus incluyen listas negras de direcciones IP dinámicas , limitación dinámica del ancho de banda y almacenamiento en caché de tokens de autenticación .

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

En cuanto a las demás funciones compatibles con clústeres, puede configurar la sincronización del almacén de valores clave simplemente agregando el parámetro sync a la directiva keyval_zone para un clúster que ya se ha configurado para compartir estado (con las directivas zone_sync y zone_sync_server ).

El almacén de clave-valor también se ha ampliado con la capacidad de establecer un valor de tiempo de espera para cada par clave-valor agregado al almacén de clave-valor. Estas entradas expiran automáticamente y se eliminan del almacén de valores clave cuando transcurre el período de tiempo de espera especificado. El parámetro de tiempo de espera es obligatorio cuando se configura un almacén de clave-valor sincronizado.

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

Puede combinar las nuevas capacidades de agrupación en clústeres de NGINX Plus para crear una solución sofisticada para protegerse contra ataques DDoS. Cuando un grupo de instancias de NGINX Plus se implementa en un clúster activo-activo, o se distribuye a través de una red de área amplia, el tráfico malicioso puede llegar a cualquiera de esas instancias. Esta solución utiliza un límite de velocidad sincronizado y un almacén de valores clave sincronizado para responder dinámicamente a los ataques DDoS y mitigar su efecto, de la siguiente manera.

• Un límite de velocidad que reconoce el clúster detecta a los clientes que envían más de 100 solicitudes por segundo, independientemente de qué nodo NGINX Plus reciba la solicitud.
• Cuando un cliente supera el límite de velocidad, su dirección IP se añade a un almacén de clave-valor "sin bin" mediante una llamada a la API de NGINX Plus . El sin bin se sincroniza en todo el clúster.
• Las solicitudes adicionales de clientes en el contenedor sin están sujetas a un límite de ancho de banda muy bajo, independientemente de qué nodo NGINX Plus las reciba. Es preferible limitar el ancho de banda que rechazar las solicitudes directamente, porque no indica claramente al cliente que la mitigación de DDoS está en vigor.
• Después de diez minutos el cliente es eliminado automáticamente de la lista de castigos.

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; # Velocidad compatible con clústeres limit_req_status 429;

keyval_zone zone=sinbin:1M timeout=600 sync; # "Sinbin" compatible con clústeres con
# TTL de 10 minutos
keyval $remote_addr $in_sinbin zone=sinbin; # Rellenar $in_sinbin con
# direcciones IP de cliente coincidentes

server {
list 80;
location / {
if ($in_sinbin) {
set $limit_rate 50; # Restringir el ancho de banda de clientes maliciosos
}

limit_req zone=per_ip; # Aplicar el límite de velocidad aquí
error_page 429 = @send_to_sinbin; # Se mueven demasiados clientes a
# esta ubicación
proxy_pass http://my_backend;
}

location @send_to_sinbin {
rewrite ^ /api/3/http/keyvals/sinbin break; # Establece la URI del valor clave "sin bin"
proxy_method POST;
proxy_set_body '{"$remote_addr":"1"}';
proxy_pass http://127.0.0.1:80;
}

location /api/ {
api write=on;
# Directivas para controlar el acceso a la API
}
}

Equilibrio de carga aleatorio con dos opciones

Es cada vez más común que los entornos de entrega de aplicação y de API utilicen un nivel de equilibrio de carga distribuido o escalado para recibir solicitudes de clientes y pasarlas a un entorno de aplicação compartido. Cuando varios balanceadores de carga pasan solicitudes al mismo conjunto de servidores back-end, es importante utilizar un método de balanceo de carga que no sobrecargue inadvertidamente los servidores back-end individuales.

Los clústeres NGINX Plus implementados en una configuración activa-activa, o entornos distribuidos con múltiples puntos de entrada, son escenarios comunes que pueden desafiar los métodos de equilibrio de carga tradicionales porque cada equilibrador de carga no puede tener conocimiento completo de todas las solicitudes que se han enviado a los servidores back-end.

El equilibrio de carga dentro de un clúster en contenedores tiene las mismas características que una implementación activa-activa escalada horizontalmente. Los controladores de ingreso de Kubernetes implementados en un conjunto de réplicas con múltiples instancias del recurso de ingreso también enfrentan el desafío de cómo distribuir eficazmente la carga a los pods que brindan cada uno de los servicios en el clúster.

La variación de la carga de trabajo tiene un impacto enorme en la eficacia del equilibrio de carga distribuido. Cuando cada solicitud impone la misma carga en el servidor backend, medir la rapidez con la que cada servidor ha respondido a las solicitudes anteriores es una forma efectiva de decidir dónde enviar la próxima solicitud. Exclusivo de NGINX Plus es el método de equilibrio de carga de menor tiempo , que hace exactamente eso. Pero cuando la carga en el servidor backend es variable (porque incluye operaciones de lectura y escritura, por ejemplo), el rendimiento pasado es un mal 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 promedia, pero es un enfoque rudimentario que probablemente envíe picos de tráfico a servidores individuales de vez en cuando.

Una variación simple del equilibrio de carga aleatorio, pero que ha demostrado mejorar la distribución de la carga, es seleccionar dos servidores back-end al azar y luego enviar la solicitud al que tenga la carga más baja. El objetivo de comparar dos opciones aleatorias es evitar tomar una mala decisión de equilibrio de carga, incluso si la decisión tomada no es óptima. Al evitar el servidor back-end con mayor carga, cada balanceador de carga puede operar independientemente y aún así evitar enviar picos de tráfico a servidores back-end individuales. Como resultado, este método tiene los beneficios y la eficiencia computacional del equilibrio de carga aleatorio pero con una distribución de carga demostrablemente mejor.

NGINX Plus R16 presenta dos nuevos métodos de equilibrio de carga: aleatorio y aleatorio con dos opciones. Para esto ú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. La siguiente tabla enumera las métricas disponibles.

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

El siguiente fragmento muestra un ejemplo simple de configuración de equilibrio de carga aleatorio con dos opciones con la directiva aleatoria dos ( HTTP , Stream ).

upstream my_backend { zona my_backend 64k; servidor 10.0.0.1; servidor 10.0.0.2; servidor 10.0.0.3; #... aleatorio dos least_time=last_byte; # Elija el tiempo de respuesta más rápido entre dos opciones aleatorias } servidor { escuchar 80; ubicación / { proxy_pass http://my_backend; # Balance de carga al grupo upstream } }

Tenga en cuenta que el método aleatorio con dos opciones solo es adecuado para entornos distribuidos donde varios balanceadores de carga pasan solicitudes al mismo conjunto de backends. No lo utilice cuando NGINX Plus esté implementado en un solo host o en una implementación activa-pasiva. En esos casos, el balanceador de carga único tiene una vista completa de todas las solicitudes, y los métodos Round Robin, Least Connections y Least Time brindan los mejores resultados.

Equilibrio de carga UDP mejorado

NGINX Plus R9 introdujo soporte para proxy y balanceo de carga de tráfico UDP , lo que le permite a NGINX Plus ubicarse frente a aplicações UDP populares como DNS, syslog, NTP y RADIUS para brindar alta disponibilidad y escalabilidad de los servidores de aplicação . La implementación inicial se limitó a las aplicações UDP que esperan un solo paquete UDP del cliente por cada interacción con el servidor.

Con NGINX Plus R16 , se admiten múltiples paquetes entrantes, lo que significa que se pueden utilizar como proxy y equilibrar la carga aplicações UDP más complejas. Estos incluyen OpenVPN, VoIP, soluciones de escritorio virtual y sesiones de seguridad de la capa de transporte de datagramas (DTLS). Además, el manejo de todas las aplicações UDP, simples o complejas, por parte de NGINX Plus también es significativamente más rápido.

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

Compatibilidad con el protocolo PROXY v2

NGINX Plus R16 agrega soporte para el encabezado del protocolo PROXY v2 (PPv2) y la capacidad de inspeccionar valores de tipo-longitud-valor (TLV) personalizados en el encabezado.

El protocolo PROXY es utilizado por servidores proxy de capa 7 como NGINX Plus y los balanceadores de carga de Amazon para transmitir información de conexión a servidores ascendentes que se encuentran detrás de otro conjunto de servidores proxy de capa 7 o dispositivos NAT. Es necesario porque cierta información de conexión, como la dirección IP de origen y el puerto, se puede perder cuando los servidores proxy retransmiten conexiones, y no siempre es posible confiar en la inyección del encabezado HTTP para transmitir esta información. Las versiones anteriores de NGINX Plus admitían el encabezado PPv1; NGINX Plus R16 agrega soporte para el encabezado PPv2.

Uso de PPv2 con Amazon Network Load Balancer

Un caso de uso del encabezado PPv2 son las conexiones retransmitidas por el balanceador de carga de red (NLB) de Amazon, que pueden parecer originarse desde una dirección IP privada en el balanceador de carga. NLB antepone a cada conexión un encabezado PPv2 que identifica la verdadera dirección IP de origen y el puerto de la conexión del cliente. La fuente verdadera se puede obtener de la variable $proxy_protocol_addr y puede usar el módulo realip para sobrescribir las variables de fuente internas de NGINX con los valores del encabezado PPv2.

Uso de PPv2 con AWS PrivateLink

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

En muchos casos, el Servicio de Proveedor necesita saber el origen de cada conexión, pero la dirección IP de origen en el encabezado PPv2 carece de significado, ya que corresponde a una dirección interna no enrutable en la VPC del Cliente. El NLB de AWS PrivateLink añade el ID de la VPC de origen al encabezado mediante el registro TLV PPv2 0xEA .

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

Otras nuevas funciones de NGINX Plus R16

Tokens de sesión opacos de OpenID Connect

La implementación de referencia de NGINX Plus OpenID Connect 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, ésta se intercambia por el JWT y se valida. Este caso de uso se ha actualizado de prototipo/experimental a nivel de producción, ahora que las entradas en el almacén de valores clave pueden tener un valor de tiempo de espera y sincronizarse en un clúster.

Módulo dinámico de sesión cifrada

El módulo de comunidad Sesión Cifrada proporciona compatibilidad con el cifrado y descifrado de variables NGINX basadas en AES-256 con MAC. Ya 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 una serie de extensiones al alcance del soporte del lenguaje JavaScript. El módulo JavaScript HTTP se ha simplificado de modo que ahora un solo objeto ( r ) accede a los atributos de solicitud y respuesta asociados con cada solicitud. Anteriormente había objetos de solicitud ( req ) y respuesta ( res ) separados. Esta simplificación hace que el módulo JavaScript HTTP sea coherente con el módulo JavaScript Stream, que tiene un único objeto de sesión ( s ). Este cambio es totalmente compatible con versiones anteriores: el código JavaScript existente seguirá funcionando como está, pero le recomendamos que modifique el código JavaScript existente para aprovechar esta simplificación, además de usarlo en el 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 en el módulo JavaScript está documentada en el registro de cambios .

Nueva variable $ssl_preread_protocol

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

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

Mejoras del controlador de ingreso de Kubernetes

NGINX Plus puede administrar el tráfico en una amplia gama de entornos y un caso de uso importante es como balanceador de carga de ingreso para Kubernetes . NGINX desarrolla una solución de controlador Ingress que configura automáticamente NGINX Plus, y esta integración es totalmente compatible con 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 realizan lanzamientos formales ).

Durante el desarrollo de NGINX Plus R16 , se agregaron varias mejoras importantes al controlador de ingreso NGINX oficial para Kubernetes:

• La compatibilidad con Prometheus permite a los usuarios exportar métricas de NGINX y NGINX Plus directamente a Prometheus en Kubernetes.
• La compatibilidad con los gráficos Helm simplifica la instalación y la administración del controlador Ingress.
• La compatibilidad con el equilibrio de carga del tráfico gRPC proporciona alta disponibilidad y escalabilidad para aplicações basadas en gPRC. (Agregado en la versión 1.2.0.)
• Las comprobaciones de estado activas de los pods de Kubernetes detectan rápidamente fallas en los pods y en la conectividad de la red.
• La configuración fusionable y multiinquilino permite la separación de preocupaciones, lo que permite que los equipos administren de forma independiente diferentes rutas de la misma aplicação web, mientras que las operaciones conservan el control del oyente del frontend y la configuración de SSL.
• La autenticación JWT de grano fino , por ruta, brinda un control más profundo sobre la autenticación para aplicações enriquecidas.
• La gestión directa de plantillas de configuración hace que sea mucho más fácil desarrollar y probar cambios personalizados en la configuración de NGINX.

El controlador de ingreso NGINX se puede ampliar aún más utilizando ConfigMaps (para integrar la configuración de NGINX) o mediante la edición de las plantillas base , lo que permite a los usuarios acceder a todas las capacidades de NGINX cuando crean políticas de administración de tráfico para sus aplicações que se ejecutan en Kubernetes.

Para obtener más detalles, consulte Anuncio del controlador de ingreso NGINX para Kubernetes versión 1.3.0 en nuestro blog.

Actualice o pruebe NGINX Plus

NGINX Plus R16 incluye capacidades de agrupamiento adicionales, limitación de velocidad global, un nuevo algoritmo de equilibrio de carga y varias correcciones de errores . Si está utilizando NGINX Plus, le recomendamos encarecidamente que actualice a R16 lo antes posible. Recibirá una serie de correcciones y mejoras, y ayudará a NGINX, Inc. a ayudarlo cuando necesite generar un ticket de soporte.

Revise atentamente las nuevas características y los cambios de comportamiento descritos en esta publicación del blog antes de continuar con la actualización.

Si aún no ha probado NGINX Plus , le recomendamos que lo haga para aceleración web, equilibrio de carga y entrega de aplicação , o como un servidor web totalmente compatible con API de administración y monitoreo mejoradas. Puedes comenzar hoy mismo de forma gratuita con una prueba gratuita de 30 días . Vea usted mismo cómo NGINX Plus puede ayudarle a entregar y escalar sus aplicações.