Tome mejores decisiones gracias a la información detallada sobre los servicios que ofrece NGINX Ingress Controller

Akash AnanthanarayananResponsable de marketing técnico | F5 NGINX

Lanzamos la versión 3.0 de NGINX Ingress Controller en enero de 2023, con numerosas funciones nuevas importantes y mejoras de funcionalidad. Una nueva función que creemos que le resultará especialmente útil es Deep Service Insight, disponible con la edición NGINX Plus de NGINX Ingress Controller.

Deep Service Insight soluciona una limitación que impide un funcionamiento óptimo cuando un sistema de decisión de enrutamiento, como un equilibrador de carga, se sitúa delante de uno o varios clústeres de Kubernetes: concretamente, el sistema no tiene acceso a información sobre el estado de los servicios individuales que se ejecutan en los clústeres situados detrás del controlador de Ingress. Esto le impide dirigir el tráfico únicamente a clústeres con servicios en buen estado, lo que puede exponer a los usuarios a interrupciones y errores como 404 y 500.

Deep Service Insight elimina ese problema al exponer el estado de salud de los pods del servicio de backend (recopilado por NGINX Ingress Controller) en un endpoint específico al que sus sistemas pueden acceder y cuyos datos pueden utilizar para tomar mejores decisiones de enrutamiento.

En este artículo analizamos en profundidad el problema que resuelve Deep Service Insight, explicamos cómo funciona en algunos casos de uso habituales y mostramos cómo configurarlo.

¿Por qué Deep Service Insight?

Las sondas estándar de actividad, disponibilidad e inicio de Kubernetes proporcionan cierta información sobre los servicios de backend que se ejecutan en sus clústeres, pero no la suficiente para obtener la visibilidad necesaria para tomar mejores decisiones de enrutamiento en todos los niveles de su pila. La falta de información adecuada se vuelve aún más problemática a medida que aumenta la complejidad de sus despliegues de Kubernetes y se hacen más exigentes los requisitos empresariales de disponibilidad ininterrumpida.

Un enfoque habitual para mejorar el tiempo de actividad a medida que se amplía el entorno de Kubernetes consiste en implementar balanceadores de carga, gestores de DNS y otros sistemas automatizados de toma de decisiones delante de los clústeres. Sin embargo, debido al funcionamiento de los controladores Ingress, un balanceador de carga situado delante de un clúster de Kubernetes normalmente no tiene acceso a la información de estado de los servicios que se encuentran detrás del controlador Ingress del clúster; solo puede comprobar que los propios pods del controlador Ingress estén en buen estado y acepten tráfico.

NGINX Ingress Controller, en cambio, sí dispone de información sobre el estado de los servicios. Ya supervisa el estado de los pods ascendentes de un clúster mediante comprobaciones pasivas periódicas del estado de los servicios HTTP, TCP, UDP y gRPC, además de supervisar la capacidad de respuesta de las solicitudes y realizar un seguimiento de los códigos de respuesta correctos y otras métricas. Utiliza esta información para decidir cómo distribuir el tráfico entre los pods de sus servicios y ofrecer una experiencia de usuario uniforme y predecible. Normalmente, NGINX Ingress Controller hace toda esta magia de forma silenciosa en segundo plano, por lo que quizá nunca se plantee qué ocurre entre bastidores. Deep Service Insight «saca a la luz» esta valiosa información para que pueda utilizarla de forma más eficaz en otras capas de su stack.

¿Cómo funciona Deep Service Insight?

Deep Service Insight está disponible para los servicios que despliega mediante los recursos personalizados VirtualServer y TransportServer de NGINX (para HTTP y TCP/UDP, respectivamente). Deep Service Insight utiliza la API de NGINX Plus para compartir la vista que NGINX Ingress Controller tiene de los pods individuales de un servicio de backend en un endpoint específico y exclusivo de Deep Service Insight:

• Para VirtualServer – <IP_address> :<port> /probe/<hostname>
• Para TransportServer – <IP_address> :<port> /probe/ts/<service_name>

donde

• <IP_address> pertenece al controlador de entrada NGINX
• <port> es el número de puerto de Deep Service Insight (9114 de forma predeterminada)
• <hostname> es el nombre de dominio del servicio, tal como se define en el campo spec.host del recurso VirtualServer
• <service_name> es el nombre del servicio tal como se define en el campo spec.upstreams.service del recurso TransportServer

La salida incluye dos tipos de información:

1. Un código de estado HTTP para el nombre de host o el nombre del servicio:
   • 200 OK – Al menos un pod está en buen estado
   • 418 Soy una tetera – Ningún pod está en buen estado
   • 404 No encontrado – No hay ningún pod que coincida con el nombre de host o el nombre de servicio especificado
2. Tres contadores para el nombre de host o nombre de servicio especificado:
   • Total de instancias de servicio (pods)
   • Número de pods en estado Up (correcto)
   • Número de pods en estado Unhealthy state

Este es un ejemplo en el que los tres pods de un servicio están en buen estado:

HTTP/1.1 200 OKContent-Type: application/json; charset=utf-8
Date: Day, DD Mon YYYY hh:mm:ss TZ
Content-Length: 32
{"Total":3,"Up":3,"Unhealthy":0}

Para obtener más información, consulta la documentación de NGINX Ingress Controller.

Puede personalizar aún más los criterios que utiliza NGINX Ingress Controller para determinar si un pod está en buen estado configurando comprobaciones de estado activas. Puede configurar la ruta y el puerto a los que se envía la comprobación de estado, el número de comprobaciones fallidas que deben producirse en un periodo de tiempo determinado para que un pod se considere en mal estado, el código de estado esperado, los tiempos de espera para establecer la conexión o recibir una respuesta, entre otras opciones. Incluya el campo «Upstream.Healthcheck» en el recurso «VirtualServer» o «TransportServer».

Ejemplos de casos de uso de Deep Service Insight

Un caso de uso en el que Deep Service Insight resulta especialmente útil es cuando un equilibrador de carga dirige el tráfico a un servicio que se ejecuta en dos clústeres, por ejemplo, para garantizar una alta disponibilidad. Dentro de cada clúster, NGINX Ingress Controller supervisa el estado de los pods ascendentes tal como se ha descrito anteriormente. Al habilitar Deep Service Insight, la información sobre el número de pods ascendentes en buen y mal estado también se expone en un endpoint específico. El sistema de decisión de enrutamiento puede acceder al endpoint y utilizar esta información para desviar el tráfico de la aplicación de los pods en mal estado a los que se encuentran en buen estado.

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

También puede aprovechar Deep Service Insight al realizar tareas de mantenimiento en un clúster en un entorno de alta disponibilidad. Basta con reducir a cero el número de pods de un servicio en el clúster en el que esté realizando el mantenimiento. La ausencia de pods en buen estado se refleja automáticamente en el endpoint de Deep Service Insight, y el sistema de decisión de enrutamiento utiliza esa información para enviar el tráfico a los pods en buen estado del otro clúster. De este modo, obtiene una conmutación por error automática sin tener que modificar la configuración de NGINX Ingress Controller ni la del sistema, y sus clientes no sufren ninguna interrupción del servicio.

Habilitación de Deep Service Insight

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

Hay dos argumentos opcionales que puede incluir para ajustar el endpoint a su entorno:

• -service-insight-listen-port <port> – Cambia el número de puerto de Deep Service Insight respecto al valor predeterminado, 9114 (<port> es un número entero comprendido entre 1024 y 65535). El equivalente en Helm es el parámetro serviceInsight.port.
• -service-insight-tls-string <secret> – Un secreto de Kubernetes (certificado y clave TLS) para la terminación TLS del endpoint de Deep Service Insight (<secret> es una cadena de caracteres con el formato <namespace>/<secret_name>). El equivalente en Helm es el parámetro serviceInsight.secret.

Ejemplo: Habilitar Deep Service Insight para la aplicación Cafe

Para ver Deep Service Insight en acción, puede habilitarlo para la aplicación Cafe que se utiliza a menudo como ejemplo en la documentación de NGINX Ingress Controller.

1. Instale la edición NGINX Plus de NGINX Ingress Controller con compatibilidad con los recursos personalizados de NGINX y habilite Deep Service Insight:
   • Si utiliza Helm, establezca el parámetro serviceInsight.create en true.
   • Si utiliza un manifiesto de Kubernetes (Deployment o DaemonSet), incluya el argumento -enable-service-insight en el archivo de manifiesto.
2. Compruebe que NGINX Ingress Controller esté en ejecución:

$ kubectl get pods -n nginx-ingressNAME                                          READY ...
ingress-plus-nginx-ingress-6db8dc5c6d-cb5hp   1/1   ...  

    ...  STATUS   RESTARTS   AGE
    ...  Running   0          9d

1. Despliega la aplicación Cafe siguiendo las instrucciones del archivo README.
2. Compruebe que el recurso personalizado VirtualServer de NGINX esté implementado para la aplicación Cafe (se omite la dirección IP para facilitar la lectura):

$ kubectl get vs NAME   STATE   HOST               IP    PORTS      AGE
cafe   Valid   cafe.example.com   ...   [80,443]   7h1m

1. Compruebe que haya tres pods de upstream para el servicio Cafe ejecutándose en cafe.example.com:

$ kubectl get pods NAME                     READY   STATUS    RESTARTS   AGE
coffee-87cf76b96-5b85h   1/1     Running   0          7h39m
coffee-87cf76b96-lqjrp   1/1     Running   0          7h39m
tea-55bc9d5586-9z26v     1/1     Running   0          111m

1. Accede al endpoint de Deep Service Insight:

$ curl -i <NIC_IP_address>:9114/probe/cafe.example.com

1. El código de respuesta 200 OK 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 Up.

HTTP/1.1 200 OK
Content-Type: application/json; charset=utf-8
Date: Day, DD Mon YYYY hh:mm:ss TZ
Content-Length: 32
{"Total":3,"Up":3,"Unhealthy":0}

1. El código de estado 418 I’m a teapot indica que el servicio no está disponible (todos los pods tienen problemas de estado).

HTTP/1.1 418 I'm a teapotContent-Type: application/json; charset=utf-8
Date: Day, DD Mon YYYY hh:mm:ss TZ
Content-Length: 32
{"Total":3,"Up":0,"Unhealthy":3}

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

HTTP/1.1 404 Not FoundDate: Day, DD Mon YYYY hh:mm:ss TZ
Content-Length: 0

Recursos

Para consultar 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, inicie hoy mismo su prueba gratuita de 30 días o póngase en contacto con nosotros para hablar sobre sus casos de uso.

Sobre el autor

Akash AnanthanarayananResponsable de marketing técnico | F5 NGINX

Más artículos de Akash Ananthanarayanan