Anunciamos el lanzamiento de NGINX Gateway Fabric 1.2.0

Akash AnanthanarayananResponsable de marketing técnico | F5 NGINX

Mike StefaniakResponsable sénior de producto | F5 NGINX

Nos complace compartir las últimas novedades sobre NGINX Gateway Fabric, nuestra implementación conforme con la API Gateway de Kubernetes. Recientemente la hemos actualizado a la versión 1.2.0, que incorpora varias funciones nuevas y mejoras muy interesantes. Esta versión se centra en ampliar las capacidades de la plataforma y garantizar que satisfaga las necesidades de nuestros usuarios. Hemos añadido compatibilidad con F5 NGINX Plus y ampliado la cobertura de nuestra API para abarcar los casos de uso más demandados. Creemos que estas mejoras ofrecerán una experiencia más satisfactoria a todos nuestros usuarios y les ayudarán a alcanzar sus objetivos de forma más eficiente.

Figura 1: Descripción general del diseño y la arquitectura de NGINX Gateway Fabric

NGINX Gateway Fabric 1.2.0 de un vistazo:

• Compatibilidad con NGINX Plus – NGINX Gateway Fabric ahora admite NGINX Plus para el plano de datos, lo que ofrece una mayor disponibilidad, métricas detalladas y paneles de observabilidad en tiempo real.
• BackendTLSPolicy – La verificación TLS permite a NGINX Gateway Fabric confirmar la identidad de la aplicación de backend, lo que evita que aplicaciones maliciosas puedan secuestrar la conexión. Además, TLS cifra el tráfico dentro del clúster, garantizando una comunicación segura entre el cliente y la aplicación de backend.
• URLRewrite – NGINX Gateway Fabric ahora admite la reescritura de URL en objetos Route. Con esta función, puede modificar fácilmente la URL de la solicitud original y redirigirla a un destino más adecuado. De este modo, aunque las API de sus aplicaciones de backend cambien, puede mantener la coherencia de las API que ofrece a sus clientes.
• Telemetría del producto – Ahora que NGINX Gateway Fabric incorpora telemetría del producto, podemos contribuir a mejorar aún más la eficiencia operativa de su infraestructura al conocer cómo utiliza el producto en su entorno. Además, tenemos previsto compartir periódicamente esta información con la comunidad durante nuestras reuniones.

A continuación, analizaremos en detalle las nuevas funcionalidades.

¿Qué novedades incluye NGINX Gateway Fabric 1.2.0?

Compatibilidad con NGINX Plus

Se ha publicado la versión 1.2.0 de NGINX Gateway Fabric con compatibilidad con NGINX Plus, lo que ofrece numerosas ventajas nuevas a los usuarios. Con esta nueva actualización, los usuarios ya pueden aprovechar las funciones avanzadas de NGINX Plus en sus implementaciones, como métricas adicionales de Prometheus, recargas dinámicas de servidores ascendentes y el panel de NGINX Plus. Esta actualización también permite obtener asistencia directamente de NGINX para su entorno.

Métricas adicionales de Prometheus

Al utilizar NGINX Plus como plano de datos, se exportarán métricas avanzadas adicionales junto con las que normalmente obtendría con NGINX Open Source. Entre ellas se incluyen métricas sobre solicitudes HTTP, flujos, conexiones y muchas más. Para consultar todas las métricas, puede revisar el exportador de Prometheus de NGINX, que ofrece una práctica lista, aunque debe tener en cuenta que el exportador no es estrictamente necesario para NGINX Gateway Fabric. Con cualquier instalación de Prometheus o un recopilador compatible con Prometheus, puede incorporar estas métricas a su plataforma de observabilidad y crear paneles y alertas mediante una capa uniforme dentro de su arquitectura. Las métricas de Prometheus están disponibles automáticamente en NGINX Gateway Fabric a través del puerto HTTP 9113. También puede cambiar el puerto predeterminado actualizando la plantilla del pod. Si busca una configuración sencilla, puede visitar nuestra página de GitHub para obtener más información sobre cómo implementar y configurar Prometheus para que empiece a recopilar métricas. Como alternativa, si solo desea consultar las métricas y omitir la configuración, puede utilizar el panel de NGINX Plus, que se explica en la siguiente sección. Después de instalar Prometheus en su clúster, puede acceder a su panel ejecutando el reenvío de puertos en segundo plano. kubectl -n monitoring port-forward svc/prometheus-server 9090:80

Figura 2: Gráfico de Prometheus que muestra las conexiones aceptadas de NGINX Gateway Fabric

La configuración anterior funcionará incluso si también utiliza NGINX Open Source de forma predeterminada como plano de datos. Sin embargo, no podrá ver ninguna de las métricas adicionales que proporciona NGINX Plus. A medida que aumenten el tamaño y el alcance de su clúster, le recomendamos analizar cómo las métricas de NGINX Plus pueden ayudarle a resolver rápidamente problemas de planificación de capacidad, incidentes e incluso fallos de las aplicaciones de backend.

Recargas dinámicas de servidores upstream

Las recargas dinámicas de los servidores ascendentes, que NGINX Gateway Fabric habilita automáticamente cuando se instala con NGINX Plus, permiten que NGINX Gateway Fabric actualice las configuraciones de NGINX sin necesidad de recargar NGINX. Tradicionalmente, cuando se produce una recarga de NGINX, los procesos de trabajo antiguos gestionan las conexiones existentes, mientras que los recién configurados gestionan las nuevas. Cuando finalizan todas las conexiones antiguas, se detienen los procesos de trabajo antiguos y NGINX continúa funcionando únicamente con los recién configurados. De este modo, los cambios de configuración se gestionan sin interrupciones incluso en NGINX Open Source. Sin embargo, cuando NGINX está sometido a una carga elevada, mantener tanto los procesos de trabajo antiguos como los nuevos puede generar una sobrecarga de recursos que podría causar problemas, especialmente si se intenta ejecutar NGINX Gateway Fabric con el menor consumo de recursos posible. Las recargas dinámicas de los servidores ascendentes incluidas en NGINX Plus evitan este problema al proporcionar un endpoint de API para los cambios de configuración, que NGINX Gateway Fabric utilizará automáticamente si está disponible. Esto reduce la sobrecarga adicional de recursos necesaria para gestionar los procesos de trabajo antiguos y nuevos durante el proceso de recarga. A medida que realice cambios en NGINX Gateway Fabric con mayor frecuencia, las recargas también serán más frecuentes. Si desea saber con qué frecuencia o cuándo se producen las recargas en su instalación actual de NGF, puede consultar la métrica de Prometheus nginx_gateway_fabric_nginx_reloads_total. Para obtener un análisis exhaustivo del problema, consulte el artículo de Nick Shadrin aquí. Este es un ejemplo de la métrica en un entorno con dos implementaciones de NGINX Gateway Fabric en el panel de Prometheus:

Figura 3: Gráfico de Prometheus que muestra el total de recargas de NGINX Gateway Fabric

Panel de control de NGINX Plus

Como se ha mencionado anteriormente, si busca una forma rápida de consultar las métricas de NGINX Plus sin instalar Prometheus ni una plataforma de observabilidad, el panel de NGINX Plus le permite supervisar en tiempo real las métricas de rendimiento que puede utilizar para solucionar incidencias y controlar la capacidad de los recursos. El panel ofrece de inmediato distintas vistas de todas las métricas que proporciona NGINX Plus y se puede acceder fácilmente a él a través de un puerto interno. Si desea echar un vistazo rápido a las funciones del panel, visite nuestro sitio de demostración en demo.nginx.com. Para acceder al panel de NGINX Plus en su instalación de NGINX Gateway Fabric, puede redirigir las conexiones al puerto 8765 de su equipo local mediante el reenvío de puertos: kubectl port-forward -n nginx-gateway 8765:8765 A continuación, abra su navegador preferido y escriba http://localhost:8765/dashboard.html en la barra de direcciones.

Figura 4: Vista general del panel de NGINX Plus

BackendTLSPolicy

Esta versión incluye por fin la esperada compatibilidad con BackendTLSPolicy. BackendTLSPolicy introduce la comunicación TLS cifrada entre NGINX Gateway Fabric y la aplicación, lo que mejora considerablemente la seguridad del canal de comunicación. Este ejemplo muestra cómo aplicar la política especificando ajustes como los cifrados y protocolos TLS al validar los certificados del servidor con una autoridad de certificación (CA) de confianza. BackendTLSPolicy permite a los usuarios proteger el tráfico entre NGF y sus backends. También se pueden establecer la versión mínima de TLS y los conjuntos de cifrado. Esto evita que aplicaciones maliciosas secuestren la conexión y cifra el tráfico dentro del clúster. Para configurar la terminación TLS del backend, primero cree un ConfigMap con el certificado de la CA que quiera utilizar. Si necesita ayuda para gestionar certificados internos de Kubernetes, consulte esta guía.

kind: ConfigMap
apiVersion: v1
metadata:
  name: backend-cert
data:
  ca.crt: 
         < -----BEGIN CERTIFICATE-----
	   -----END CERTIFICATE-----
          >

A continuación, creamos la BackendTLSPolicy, que se aplica a nuestro servicio secure-app y hace referencia al ConfigMap creado en el paso anterior:

apiVersion: gateway.networking.k8s.io/v1alpha2
kind: BackendTLSPolicy
metadata:
  name: backend-tls
spec:
  targetRef:
    group: ''
    kind: Service
    name: secure-app
    namespace: default
  tls:
    caCertRefs:
    - name: backend-cert
      group: ''
      kind: ConfigMap
    hostname: secure-app.example.com

Reescritura de URL

Con un filtro URLRewrite, puede modificar la URL original de una solicitud entrante y redirigirla a otra URL sin que ello afecte al rendimiento. Esto resulta especialmente útil cuando sus aplicaciones de backend cambian la API que exponen, pero desea mantener la compatibilidad con versiones anteriores para sus clientes actuales. También puede utilizar esta función para ofrecer a sus clientes una URL de API coherente y, al mismo tiempo, redirigir las solicitudes a distintas aplicaciones con diferentes URL de API. De este modo, proporciona una API de «experiencia» que combina las funcionalidades de varias API para mejorar la comodidad y el rendimiento de sus clientes. Para empezar, vamos a crear una puerta de enlace para NGINX Gateway Fabric. Esto nos permitirá definir agentes de escucha HTTP y configurar el puerto 80 para obtener un rendimiento óptimo.

apiVersion: gateway.networking.k8s.io/v1
kind: Gateway
metadata:
  name: cafe
spec:
  gatewayClassName: nginx
  listeners:
  - name: http
    port: 80
    protocol: HTTP

Vamos a crear un recurso HTTPRoute y configurar filtros de solicitudes para reescribir todas las solicitudes de /coffee a /beans. También podemos proporcionar un endpoint /latte que se reescriba para eliminar el prefijo /latte antes de que lo procese el backend («/latte/126» se convierte en «/126»).

apiVersion: gateway.networking.k8s.io/v1
kind: HTTPRoute
metadata:
  name: coffee
spec:
  parentRefs:
  - name: cafe
    sectionName: http
  hostnames:
  - "cafe.example.com"
  rules:
  - matches:
    - path:
        type: PathPrefix
        value: /coffee
    filters:
    - type: URLRewrite
      urlRewrite:
        path:
          type: ReplaceFullPath
          replaceFullPath: /beans
    backendRefs:
    - name: coffee
      port: 80
  - matches:
    - path:
        type: PathPrefix
        value: /latte
    filters:
    - type: URLRewrite
      urlRewrite:
        path:
          type: ReplacePrefixMatch
          replacePrefixMatch: /
    backendRefs:
    - name: coffee
      port: 80

La función de reescritura HTTP ayuda a garantizar la flexibilidad entre los endpoints del lado del cliente y su correspondencia con el backend. También permite redirigir el tráfico de una URL a otra, lo que resulta especialmente útil al migrar contenido a un nuevo sitio web o al migrar tráfico de API. Aunque NGINX Gateway Fabric admite reescrituras basadas en rutas, actualmente no admite redirecciones basadas en rutas. Háganoslo saber si necesita esta función en su entorno.

Telemetría del producto

Hemos decidido incluir la telemetría del producto como mecanismo para recopilar comentarios de forma pasiva en la versión 1.2. Esta función recopilará diversas métricas de su entorno y las enviará a nuestra plataforma de recopilación de datos cada 24 horas. No se recopila información de identificación personal (PII), y puede consultar la lista completa de los datos recopilados aquí. Nos comprometemos a ofrecer una transparencia total sobre nuestra funcionalidad de telemetría. Aunque documentaremos todos los campos que recopilamos y podrá comprobar en nuestro código qué datos se recopilan, siempre tendrá la opción de desactivarla por completo. Tenemos previsto analizar periódicamente con la comunidad observaciones interesantes basadas en las estadísticas recopiladas durante nuestras reuniones de la comunidad. ¡No deje de asistir!

Recursos

Para consultar el registro de cambios completo de NGINX Gateway Fabric 1.2.0, consulte las Notas de la versión. Para probar NGINX Gateway Fabric para Kubernetes con NGINX Plus, inicie hoy mismo su prueba gratuita de 30 días o póngase en contacto con nosotros para hablar sobre sus casos de uso. Si desea colaborar, conocer las próximas novedades o consultar el código fuente de NGINX Gateway Fabric, visite nuestro repositorio en GitHub. Celebramos reuniones de la comunidad cada dos semanas, los lunes a las 9:00 (hora del Pacífico)/17:00 (GMT). El enlace de la reunión, las novedades, el orden del día y las notas están disponibles en el calendario de reuniones de NGINX Gateway Fabric. Los enlaces también están siempre disponibles en el archivo README de GitHub.

Sobre los autores

Akash AnanthanarayananResponsable de marketing técnico | F5 NGINX

Más artículos de Akash Ananthanarayanan

Mike StefaniakResponsable sénior de producto | F5 NGINX

Más artículos de Mike Stefaniak