Nos complace compartir las últimas noticias sobre NGINX Gateway Fabric, nuestra implementación compatible con la API de Kubernetes Gateway. Recientemente la actualizamos a la versión 1.2.0, con varias nuevas funciones y mejoras interesantes. Esta versión se centra en mejorar las capacidades de la plataforma y garantizar que satisfaga las demandas de nuestros usuarios. Hemos incluido soporte F5 NGINX Plus y ampliado nuestra superficie API para cubrir los casos de uso más demandados. Creemos que estas mejoras crearán una mejor experiencia para todos nuestros usuarios y les ayudarán a alcanzar sus objetivos de manera 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:
A continuación analizaremos con más profundidad las nuevas características.
Se ha lanzado la versión 1.2.0 de NGINX Gateway Fabric con soporte para NGINX Plus, brindando a los usuarios muchos beneficios nuevos. Con la nueva actualización, los usuarios ahora pueden aprovechar las funciones avanzadas de NGINX Plus en sus implementaciones, incluidas métricas Prometheus adicionales, recargas ascendentes dinámicas y el panel de NGINX Plus. Esta actualización también le permite la opción de obtener soporte directamente de NGINX para su entorno.
Al utilizar NGINX Plus como su plano de datos, se exportarán métricas avanzadas adicionales junto con las métricas que normalmente obtendría con NGINX Open Source. Algunos aspectos destacados incluyen métricas sobre solicitudes http, transmisiones, conexiones y mucho más. Para obtener la lista completa, puede consultar el exportador Prometheus de NGINX para obtener una lista conveniente , pero tenga en cuenta que el exportador no es estrictamente necesario para NGINX Gateway Fabric. Con cualquier instalación de Prometheus o un raspador compatible con Prometheus, puede extraer estas métricas en su pila de observación y crear paneles y alertas utilizando una capa consistente 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 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 comenzar a recopilar. Alternativamente, si solo busca ver las métricas y omitir la configuración, puede usar 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 de control 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 de tejido de puerta de enlace NGINX aceptadas
¡La configuración anterior funcionará incluso si utiliza NGINX Open Source predeterminado como plano de datos! Sin embargo, no verá ninguna de las métricas adicionales que proporciona NGINX Plus. A medida que crece el tamaño y el alcance de su clúster, le recomendamos observar cómo las métricas de NGINX Plus pueden ayudar a resolver rápidamente sus problemas de planificación de capacidad, incidentes e incluso fallas de aplicação de backend.
Las recargas dinámicas ascendentes, habilitadas automáticamente por NGINX Gateway Fabric cuando se instala con NGINX Plus, permiten que NGINX Gateway Fabric realice actualizaciones en las configuraciones de NGINX sin una recarga de NGINX. Tradicionalmente, cuando se produce una recarga de NGINX, las conexiones existentes son manejadas por los procesos de trabajo antiguos, mientras que los trabajadores recientemente configurados manejan las nuevas. Cuando se completan todas las conexiones antiguas, los trabajadores antiguos se detienen y NGINX continúa solo con los trabajadores recién configurados. De esta manera, los cambios de configuración se gestionan con elegancia incluso en NGINX Open Source. Sin embargo, cuando NGINX está bajo una carga elevada, mantener tanto trabajadores antiguos como nuevos puede crear una sobrecarga de recursos que puede causar problemas, especialmente si se intenta ejecutar NGINX Gateway Fabric de la forma más eficiente posible. Las recargas dinámicas ascendentes incluidas en NGINX Plus evitan este problema al proporcionar un punto final de API para cambios de configuración que NGINX Gateway Fabric utilizará automáticamente si está presente, lo que reduce la necesidad de una sobrecarga de recursos adicional para manejar trabajadores antiguos y nuevos durante el proceso de recarga. A medida que comience a realizar cambios con más frecuencia en NGINX Gateway Fabric, las recargas se producirán con mayor frecuencia. Si tiene curiosidad sobre 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 un análisis profundo y completo del problema, consulte el artículo de Nick Shadrin aquí ! A continuación se muestra 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
Como se mencionó anteriormente, si está buscando una forma rápida de ver las métricas de NGINX Plus sin una instalación de Prometheus o una pila de observación, el panel de NGINX Plus le brinda monitoreo en tiempo real de las métricas de rendimiento que puede usar para solucionar incidentes y controlar la capacidad de los recursos. El panel le ofrece diferentes vistas para todas las métricas que NGINX Plus proporciona de inmediato y es de fácil acceso en un puerto interno. Si desea echar un vistazo rápido para ver cómo son las capacidades del panel, consulte nuestro sitio de demostración del panel en demo.nginx.com . Para acceder al panel de NGINX Plus en su instalación de NGINX Gateway Fabric, puede reenviar conexiones al puerto 8765 en su máquina local a través del 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: Descripción general del panel de NGINX Plus
Esta versión ahora viene con el tan esperado soporte para BackendTLSPolicy . BackendTLSPolicy introduce una comunicación TLS encriptada entre NGINX Gateway Fabric y la aplicação, lo que mejora enormemente la seguridad del canal de comunicación. A continuación se muestra un ejemplo que muestra cómo aplicar la política especificando configuraciones como cifrados y protocolos TLS al validar certificados de servidor frente a una autoridad de certificación (CA) confiable. BackendTLSPolicy permite a los usuarios proteger su tráfico entre NGF y sus backends. También puede configurar la versión mínima de TLS y los conjuntos de cifrado. Esto protege contra aplicações maliciosas que secuestran 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 la certificación CA que desea utilizar. Para obtener ayuda con la administración de certificados internos de Kubernetes, consulte esta guía .
amable: Mapa de configuración
Versión de API: v1
Metadatos:
Nombre: backend-cert
Datos:
ca.crt:
< -----INICIO DEL CERTIFICADO-----
-----FIN DEL CERTIFICADO-----
>
A continuación, creamos BackendTLSPolicy, que apunta a nuestro servicio de aplicación segura
y hace referencia al ConfigMap creado en el paso anterior:
Versión de API: gateway.networking.k8s.io/v1alpha2
Tipo: Política de backendTLS
Metadatos:
Nombre: backend-tls
Especificación:
ReferenciaObjetivo:
Grupo: ''
Tipo: Servicio
Nombre: secure-app
Espacio de nombres: predeterminado
TLS:
Referencias de certificado de CA:
Nombre: backend-cert
Grupo: ''
Tipo: Mapa de configuración
Nombre de host: secure-app.example.com
Con un filtro URLRewrite, puedes modificar la URL original de una solicitud entrante y redirigirla a una URL diferente sin impacto en el rendimiento. Esto es particularmente útil cuando sus aplicações backend cambian su API expuesta, pero desea mantener la compatibilidad con versiones anteriores para sus clientes existentes. También puede utilizar esta función para exponer una URL de API consistente a sus clientes mientras redirige las solicitudes a diferentes aplicações con diferentes URL de API, proporcionando una API de "experiencia" que combina la funcionalidad de varias API diferentes para la conveniencia y el rendimiento de sus clientes. Para comenzar, crearemos una puerta de enlace para la estructura de puerta de enlace NGINX. Esto nos permitirá definir oyentes HTTP y configurar el puerto 80 para un rendimiento óptimo.
Versión de API: gateway.networking.k8s.io/v1
Tipo: Puerta de enlace
Metadatos:
Nombre: Cafe
Especificación:
NombreClasePuertaDeEnlace: Nginx
Oyentes:
- Nombre: http
Puerto: 80
protocolo: HTTP
Creemos un recurso HTTPRoute y configuremos filtros de solicitud para reescribir cualquier solicitud de /coffee a /beans. También podemos proporcionar un punto final /latte que se reescribe para incluir el prefijo /latte para que lo maneje el backend (“/latte/126” se convierte en “/126”).
Versión de API: gateway.networking.k8s.io/v1
Tipo: Ruta HTTP
Metadatos:
Nombre: café
Especificación:
Referencias principales:
Nombre: café
Nombre de la sección: http
Nombres de host:
"cafe.ejemplo.com"
Reglas:
Concordancias:
Ruta:
Tipo: Prefijo de ruta
valor: /café
filtros:
-tipo: Reescritura de URL
Reescritura de URL:
ruta:
tipo: ReemplazarRutaCompleta
reemplazarRutaCompleta: /beans
ReferenciasDeServicio:
- nombre: café
puerto: 80
- coincidencias:
- ruta:
tipo: Prefijo de ruta
valor: /latte
filtros:
-tipo: Reescritura de URL
Reescritura de URL:
ruta:
tipo: ReemplazarCoincidenciaDePrefijo
reemplazarCoincidenciaDePrefijo: /
ReferenciasDeBackend:
- Nombre: Café
Puerto: 80
La función de reescritura HTTP ayuda a garantizar la flexibilidad entre los puntos finales del lado del cliente y cómo se asignan con el backend. También permite redirigir el tráfico de una URL a otra, lo que es especialmente útil al migrar contenido a un nuevo sitio web o tráfico API. Si bien NGINX Gateway Fabric admite reescrituras basadas en rutas, actualmente no admite redirecciones basadas en rutas. Háganos saber si esta es una característica que necesita para su entorno.
Hemos decidido incluir la telemetría del producto como un mecanismo para recopilar comentarios de forma pasiva como parte de la versión 1.2. Esta función recopilará una variedad de métricas de su entorno y las enviará a nuestra plataforma de recopilación de datos cada 24 horas. No se recopila ninguna información de identificación personal (PII) y puedes ver la lista completa de lo que se recopila aquí . Nos comprometemos a brindar transparencia total en torno a nuestra funcionalidad de telemetría. Si bien documentaremos cada campo que recopilemos y usted puede validar lo que recopilamos mediante nuestro código, siempre tiene la opción de deshabilitarlo por completo. Estamos planeando revisar regularmente observaciones interesantes basadas en las estadísticas que recopilemos con la comunidad en nuestras reuniones comunitarias , ¡así que asegúrese de visitarnos!
Para conocer 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, comience hoy su prueba gratuita de 30 días o contáctenos para analizar sus casos de uso . Si quieres participar, ver lo que viene a continuación o ver el código fuente de NGINX Gateway Fabric, ¡visita nuestro repositorio en GitHub ! Tenemos reuniones comunitarias quincenales los lunes a las 9 a. m., hora del Pacífico/5 p. m., hora del GMT. El enlace de la reunión, las actualizaciones, la agenda y las notas se encuentran en el Calendario de reuniones de NGINX Gateway Fabric . Los enlaces también están siempre disponibles en nuestro archivo README de GitHub.
"Esta publicación de blog puede hacer referencia a productos que ya no están disponibles o que ya no reciben soporte. Para obtener la información más actualizada sobre los productos y soluciones F5 NGINX disponibles, explore nuestra familia de productos NGINX . NGINX ahora es parte de F5. Todos los enlaces anteriores de NGINX.com redirigirán a contenido similar de NGINX en F5.com.