Tome mejores decisiones con un profundo conocimiento del servicio del controlador de ingreso NGINX

Lanzamos la versión 3.0 de NGINX Ingress Controller en enero de 2023 con una serie de nuevas características importantes y funcionalidades mejoradas. Una nueva característica que creemos que encontrará particularmente valiosa es Deep Service Insight, disponible con la edición NGINX Plus de NGINX Ingress Controller.

Deep Service Insight aborda una limitación que dificulta el funcionamiento óptimo cuando un sistema de decisión de enrutamiento, como un balanceador de carga, se encuentra frente a uno o más clústeres de Kubernetes, es decir, que el sistema no tiene acceso a información sobre el estado de los servicios individuales que se ejecutan en los clústeres detrás del controlador de Ingress. Esto evita que se enrute el tráfico solo a clústeres con servicios en buen estado, lo que potencialmente expone a los usuarios a interrupciones y errores como404 y500 .

Deep Service Insight elimina ese problema al exponer el estado de salud de los pods de servicio de backend (según lo recopilado por NGINX Ingress Controller) en un punto final dedicado donde sus sistemas pueden acceder y usarlo para tomar mejores decisiones de enrutamiento.

En esta publicación analizamos en profundidad el problema resuelto por Deep Service Insight, explicamos cómo funciona en algunos casos de uso comunes y mostramos cómo configurarlo.

¿Por qué Deep Service Insight?

Las sondas estándar de actividad, preparación e inicio de Kubernetes le brindan cierta información sobre los servicios de backend que se ejecutan en sus clústeres, pero no lo suficiente como para brindarle el tipo de información que necesita para tomar mejores decisiones de enrutamiento en toda la pila. La falta de la información correcta se vuelve aún más problemática a medida que sus implementaciones de Kubernetes crecen en complejidad y sus requisitos comerciales de tiempo de actividad ininterrumpido se vuelven más urgentes.

Un enfoque común para mejorar el tiempo de actividad a medida que escala su entorno de Kubernetes es implementar balanceadores de carga, administradores de DNS y otros sistemas de decisiones automatizados frente a sus clústeres. Sin embargo, debido a la forma en que funcionan los controladores de Ingress, un balanceador de carga ubicado frente a un clúster de Kubernetes normalmente no tiene acceso a la información de estado sobre los servicios detrás del controlador de Ingress en el clúster; solo puede verificar que los pods del controlador de Ingress estén en buen estado y acepten tráfico.

Por otro lado, el controlador de ingreso NGINX sí tiene información sobre el estado del servicio. Ya monitorea la salud de los pods ascendentes en un clúster enviando controles de salud pasivos periódicos para servicios HTTP , TCP , UDP y gRPC , monitoreando la capacidad de respuesta de las solicitudes y rastreando códigos de respuesta exitosos y otras métricas. Utiliza esta información para decidir cómo distribuir el tráfico entre los pods de sus servicios para brindar una experiencia de usuario consistente y predecible. Normalmente, NGINX Ingress Controller realiza toda esta magia silenciosamente en segundo plano, y es posible que nunca pienses dos veces en lo que sucede bajo el capó. Deep Service Insight “saca a la luz” esta valiosa información para que pueda usarla de manera más efectiva en otras capas de su pila.

¿Cómo funciona Deep Service Insight?

Deep Service Insight está disponible para los servicios que implementa utilizando los recursos personalizados NGINX VirtualServer y TransportServer (para HTTP y TCP/UDP respectivamente). Deep Service Insight utiliza la API NGINX Plus para compartir la vista del controlador de ingreso NGINX de los pods individuales en un servicio de backend en un punto final dedicado exclusivo de Deep Service Insight:

• Para servidores virtuales – <dirección IP> :<puerto> /sonda/<nombre de host>
• Para TransportServer – <dirección IP> :<puerto> /sonda/ts/<nombre_del_servicio>

dónde

• <dirección IP> pertenece al controlador de ingreso NGINX
• <puerto> es el número de puerto de Deep Service Insight (9114 por defecto)
• <nombre de host> es el nombre de dominio del servicio tal como se define en el host de especificación campo del recurso VirtualServer
• <nombre_del_servicio> es el nombre del servicio tal como se define en el especificación.upstreams.service campo en el recurso TransportServer

La salida incluye dos tipos de información:

1. Un código de estado HTTP para el nombre de host o nombre de servicio:

   • 200 OK – Al menos una vaina está sana
   • 418 Soy una tetera – Ninguna vaina es saludable
   • 404 No encontrado : no hay pods que coincidan con el nombre de host o el nombre de servicio especificado

2. Tres contadores para el nombre de host o nombre de servicio especificado:

   • Número total de instancias de servicio (pods)
   • Número de pods en estado activo (saludable)
   • Número de pods en estado no saludable

A continuación se muestra un ejemplo en el que los tres pods de un servicio funcionan correctamente:

HTTP/1.1 200 OKContent-Type: aplicação/json; conjunto de caracteres=utf-8 Fecha: Día , DD Lun AAAA hh : mm : ss TZ Longitud del contenido: 32 {"Total":3,"Arriba":3,"Insalubre":0}

Para obtener más detalles, consulte la documentación del controlador de ingreso NGINX.

Puede personalizar aún más los criterios que NGINX Ingress Controller utiliza para decidir si un pod está en buen estado configurando comprobaciones de estado activas. Puede configurar la ruta y el puerto al que se envía la comprobación de estado, la cantidad de comprobaciones fallidas que deben ocurrir dentro de un período de tiempo específico para que un pod se considere no saludable, el código de estado esperado, los tiempos de espera para conectarse o recibir una respuesta, y más. Incluya el campo Upstream.Healthcheck en el recurso VirtualServer o TransportServer .

Ejemplos de casos de uso para un conocimiento profundo de los servicios

Un caso de uso en el que Deep Service Insight es particularmente valioso es cuando un balanceador de carga enruta el tráfico a un servicio que se ejecuta en dos clústeres, por ejemplo, para alta disponibilidad. Dentro de cada clúster, NGINX Ingress Controller rastrea el estado de los pods ascendentes como se describe anteriormente. Cuando habilita Deep Service Insight, la información sobre la cantidad de pods ascendentes en buen estado y en mal estado también se expone en un punto final dedicado. Su sistema de decisión de enrutamiento puede acceder al punto final y usar la información para desviar el tráfico de aplicação desde los pods no saludables a favor de los saludables.

El diagrama ilustra cómo funciona Deep Service Insight en este escenario.

También puede aprovechar Deep Service Insight al realizar mantenimiento en un clúster en un escenario de alta disponibilidad. Simplemente reduzca la cantidad de pods para un servicio a cero en el clúster donde realiza el mantenimiento. La falta de pods en buen estado se muestra automáticamente en el punto final de Deep Service Insight y su sistema de decisión de enrutamiento utiliza esa información para enviar tráfico a los pods en buen estado en el otro clúster. Obtendrá efectivamente una conmutación por error automática sin tener que cambiar la configuración ni en el controlador de ingreso NGINX ni en el sistema, y sus clientes nunca experimentarán una interrupción del servicio.

Habilitación de un conocimiento profundo del servicio

Para habilitar Deep Service Insight, incluya el argumento de línea de comandos -enable-service-insight en el manifiesto de Kubernetes o configure el parámetro serviceInsight.create como verdadero si usa Helm.

Hay dos argumentos opcionales que puedes incluir para ajustar el punto final a tu entorno:

• -puerto de escucha de información de servicio <puerto> – Cambie el número de puerto de Deep Service Insight del predeterminado, 9114 (<puerto> es un número entero en el rango 1024–65535). El equivalente de Helm es el parámetro serviceInsight.port .
• -cadena-tls-de-service-insight <secreto> – Un secreto de Kubernetes (certificado y clave TLS) para la terminación TLS del punto final de Deep Service Insight (<secreto> es una cadena de caracteres con formato <espacio de nombres>/<nombre_secreto>). El equivalente de Helm es el parámetro serviceInsight.secret .

Example: Habilitar Deep Service Insight para la aplicação Cafe

Para ver Deep Service Insight en acción, puede habilitarlo para la aplicação Cafe que a menudo se usa como ejemplo en la documentación del controlador de ingreso NGINX.

1. Instale la edición NGINX Plus de NGINX Ingress Controller con soporte para recursos personalizados de NGINX y habilitación de Deep Service Insight:

   • Si usa Helm , configure el parámetro serviceInsight.create en verdadero .
   • Si usa un manifiesto de Kubernetes (Implementación o DaemonSet), incluya el argumento -enable-service-insight en el archivo de manifiesto.

2. Verifique que el controlador de ingreso NGINX se esté ejecutando:

   $ kubectl get pods -n nginx-ingress NOMBRE LISTO ... ingress-plus-nginx-ingress-6db8dc5c6d-cb5hp 1/1 ... ...  ESTADO REINICIO EDAD...  Corriendo 0 9d

3. Implemente la aplicação Cafe según las instrucciones del archivo README .

4. Verifique que el recurso personalizado NGINX VirtualServer esté implementado para la aplicação Cafe (la dirección IP se omite para mayor legibilidad):

   $ kubectl get vs NOMBRE ESTADO HOST IP PUERTOS EDAD cafe Válido cafe.example.com ... [80,443] 7h1m

5. Verifique que haya tres pods ascendentes para el servicio Cafe que se ejecuta en cafe.example.com :

   $ kubectl get pods NOMBRE LISTO ESTADO REINICIO EDAD coffee-87cf76b96-5b85h 1/1 En ejecución 0 7h39m coffee-87cf76b96-lqjrp 1/1 En ejecución 0 7h39m tea-55bc9d5586-9z26v 1/1 En ejecución 0 111m

6. Acceda al punto final de Deep Service Insight:

   $ rizo -i <Dirección IP de la NIC>:9114/sonda/cafe.ejemplo.com

   El 200 DE ACUERDO El código de respuesta indica que el servicio está listo para aceptar tráfico (al menos un pod está en buen estado). En este caso, los tres pods están en estado activo.

   HTTP/1.1 200 OK Tipo de contenido: aplicação/json; conjunto de caracteres=utf-8 Fecha: Día , DD Lun AAAA hh : mm : ss TZ Longitud del contenido: 32 {"Total":3,"Arriba":3,"Insalubre":0}

   El 418 Soy a tetera El código de estado indica que el servicio no está disponible (todos los pods no funcionan correctamente).

   HTTP/1.1 418 Soy una teteraContent-Type: aplicação/json; charset=utf-8 Fecha: Día , DD Lun AAAA hh : mm : ss TZ Longitud del contenido: 32 {"Total":3,"Arriba":0,"Insalubre":3}

   El 404 No Encontró El código de estado indica que no hay ningún servicio ejecutándose en el nombre de host especificado.

   HTTP/1.1 404 No encontrado Fecha: Día , DD Lun AAAA hh : mm : ss TZ Longitud del contenido: 0

Recursos

Para conocer el registro de cambios completo de la versión 3.0.0 de NGINX Ingress Controller, consulte las Notas de la versión .

Para probar NGINX Ingress Controller con NGINX Plus y NGINX App Protect, comience hoy su prueba gratuita de 30 días o contáctenos para analizar sus casos de uso .