Soluciona problemas de verificaciones de estado de Ingress

Si fallan las verificaciones de estado de Ingress en Google Kubernetes Engine (GKE), se puede impedir que el tráfico llegue a tu aplicación, incluso si los Pods se están ejecutando.

Usa este documento para aprender cómo funcionan las verificaciones de estado de Ingress, comprender las consideraciones de BackendConfig y los sondeos de preparación, y diagnosticar problemas como aplicaciones que no responden o reglas de firewall faltantes.

Esta información es importante para los operadores y administradores de plataformas, y los desarrolladores de aplicaciones que configuran y administran recursos de Ingress, y deben asegurarse de que sus aplicaciones informen correctamente el estado al balanceador de cargas. Para obtener más información sobre los roles comunes y las tareas de ejemplo a las que hacemos referencia en Google Cloud el contenido de, consulta Roles y tareas comunes del usuario de GKE.

Comprende cómo funcionan las verificaciones de estado de Ingress

Antes de continuar con los pasos de solución de problemas, puede ser útil comprender cómo funcionan las verificaciones de estado en GKE y qué consideraciones debes tener en cuenta para garantizar que las verificaciones de estado se realicen correctamente.

Cuando expones uno o más objetos de servicio a través de un Ingress mediante el controlador de Ingress predeterminado, GKE crea un balanceador de cargas de aplicaciones clásico o un balanceador de cargas de aplicaciones interno. Ambos balanceadores de cargas admiten varios servicios de backend en un solo mapa de URL. Cada uno de los servicios de backend corresponde a un servicio de Kubernetes, y cada servicio de backend debe hacer referencia a una Google Cloud verificación de estado. Esta verificación de estado es diferente de una prueba de funcionamiento o disponibilidad de Kubernetes porque la verificación de estado se implementa fuera del clúster.

Las verificaciones de estado del balanceador de cargas se especifican por servicio de backend. Si bien es posible usar la misma verificación de estado para todos los servicios de backend del balanceador de cargas, la referencia de verificación de estado no se especifica para todo el balanceador de cargas (en el objeto Ingress).

GKE crea verificaciones de estado según uno de los siguientes métodos:

  • CRD de BackendConfig: Es una definición de recurso personalizado (CRD) que te brinda un control preciso sobre cómo interactúan tus servicios con el balanceador de cargas. Las CRD de BackendConfig te permiten especificar parámetros personalizados para la verificación de estado asociada con el servicio de backend correspondiente. Estos parámetros personalizados proporcionan mayor flexibilidad y control sobre las verificaciones de estado para el balanceador de cargas de aplicaciones clásico y el balanceador de cargas de aplicaciones interno creados por un Ingress.
  • Sondeo de preparación: Es una verificación de diagnóstico que determina si un contenedor dentro de un Pod está listo para entregar tráfico. El controlador de Ingress de GKE crea la verificación de estado para el servicio de backend del servicio según el sondeo de preparación que usan los Pods de entrega de ese servicio. Puedes derivar los parámetros de verificación de estado, como la ruta de acceso, el puerto y el protocolo, de la definición del sondeo de preparación.
  • Valores predeterminados: Son los parámetros que se usan cuando no configuras una BackendConfig CRD ni defines atributos para el sondeo de preparación.
Práctica recomendada:

Usa una CRD de BackendConfig para tener el mayor control sobre la configuración de la verificación de estado del balanceador de cargas.

GKE usa el siguiente procedimiento a fin de crear una verificación de estado para cada servicio de backend que corresponda a un Service de Kubernetes:

  • Si el Service hace referencia a una CRD de BackendConfig con información healthCheck, GKE usa esa información para crear la verificación de estado. Tanto el controlador de Ingress de GKE Enterprise como el controlador de Ingress de GKE admiten la creación de verificaciones de estado de esta manera.

  • Si el Service no hace referencia a una CRD de BackendConfig, haz lo siguiente:

    • GKE puede inferir algunos o todos los parámetros para una verificación de estado si los Pod de entrega usan una plantilla de Pod con un contenedor cuya prueba de disponibilidad tiene atributos que se pueden interpretar como parámetros de verificación de estado. Consulta Parámetros de una prueba de disponibilidad para obtener detalles sobre la implementación y Parámetros inferidos y predeterminados a fin de obtener una lista de atributos que se pueden usar con el fin de crear una verificación de estado. Solo el controlador de Ingress de GKE admite la inferencia de parámetros de una prueba de disponibilidad.

    • Si la plantilla de pod para los pods de entrega del Service no tiene un contenedor con un sondeo de preparación cuyos atributos se pueden interpretar como parámetros de una verificación de estado, se usan los valores predeterminados para crear la verificación de estado. Tanto el controlador de Ingress de GKE Enterprise como el controlador de Ingress de GKE pueden crear una verificación de estado solo con los valores predeterminados.

Consideraciones

En esta sección, se describen algunas consideraciones que debes tener en cuenta cuando configuras una CRD de BackendConfig o usas un sondeo de preparación.

CRD de BackendConfig

Cuando configures CRD de BackendConfig, ten en cuenta las siguientes consideraciones:

  • Si usas el balanceo de cargas nativo del contenedor, asegúrate de que el puerto de verificación de estado en el manifiesto de BackendConfig coincida con el containerPort de un Pod de entrega.
  • Para los backends de grupos de instancias, asegúrate de que el puerto de verificación de estado en el manifiesto de BackendConfig coincida con el nodePort expuesto por el servicio.
  • Ingress no admite gRPC para la configuración de verificación de estado personalizada. BackendConfig solo admite la creación de verificaciones de estado mediante los protocolos HTTP, HTTPS o HTTP2. Para obtener un ejemplo de cómo usar el protocolo en una BackendConfig CRD, consulta gke-networking-recipes.

Para obtener más información, consulta Cuándo usar BackendConfig CRD.

Sondeo de preparación

Cuando usas Ingress de GKE con balanceo de cargas HTTP o HTTPS, GKE envía los sondeos de verificación de estado para determinar si tu aplicación se ejecuta correctamente. Estos sondeos de verificación de estado se envían al puerto específico de tus Pods que definiste en la sección spec.containers[].readinessProbe.httpGet.port de la configuración YAML de tu Pod, siempre que se cumplan las siguientes condiciones:

  • El número de puerto del sondeo de preparación especificado en spec.containers[].readinessProbe.httpGet.port debe coincidir con el puerto real en el que escucha tu aplicación dentro del contenedor, que se define en el campo containers[].spec.ports.containerPort de la configuración de tu Pod.
  • El containerPort del Pod de entrega debe coincidir con el targetPort del servicio. Esto garantiza que el tráfico se dirija desde el servicio al puerto correcto de tus Pods.
  • La especificación del puerto del backend del servicio de Ingress debe hacer referencia a un puerto válido de la sección spec.ports[] de la configuración del servicio. Esto se puede hacer de dos maneras:
    • spec.rules[].http.paths[].backend.service.port.name en el Ingress coincide con spec.ports[].name definido en el Service correspondiente.
    • spec.rules[].http.paths[].backend.service.port.number en el Ingress coincide con spec.ports[].port definido en el Service correspondiente.

Soluciona problemas comunes de verificación de estado

Usa el siguiente diagrama de flujo de solución de problemas para identificar cualquier problema de verificación de estado:

Soluciona problemas de verificaciones de estado de Ingress.
Figura: Solución de problemas de verificaciones de estado

En este diagrama de flujo, la siguiente guía de solución de problemas ayuda a determinar dónde está el problema:

  1. Investiga el estado del Pod: Si falla la verificación de estado, examina el estado de los Pods de entrega de tu servicio. Si los Pods no se ejecutan y no están en buen estado, haz lo siguiente:

    • Consulta los registros de Pod en busca de errores o problemas que impidan que se ejecuten.
    • Verifica el estado de los sondeos de preparación y funcionamiento.

  2. Registro de verificación de estado: Asegúrate de haber habilitado el registro de verificación de estado.

  3. Verifica la configuración del firewall: Asegúrate de que las reglas de firewall permitan que los sondeos de verificación de estado lleguen a tus Pods. Si la respuesta es “No”, haz lo siguiente:

    • Verifica las reglas de firewall para confirmar que permitan el tráfico entrante de los rangos de direcciones IP del sondeo de verificación de estado.
    • Ajusta las reglas de firewall según sea necesario para adaptarse a estos rangos de direcciones IP.

  4. Analiza la captura de paquetes: Si el firewall está configurado correctamente, realiza una captura de paquetes para ver si tu aplicación responde a las verificaciones de estado. Si la captura de paquetes muestra una respuesta correcta, comunícate con el equipo de Asistencia Google Cloud para obtener más ayuda.

  5. Soluciona problemas de la aplicación: Si la captura de paquetes no muestra una respuesta correcta, investiga por qué tu aplicación no responde correctamente a las solicitudes de verificación de estado. Verifica que la verificación de estado esté orientada a la ruta de acceso y el puerto correctos en los Pods, y examina los registros de la aplicación, los archivos de configuración y las dependencias. Si no encuentras el error, comunícate con el equipo de Asistencia Google Cloud .

La aplicación no responde a las verificaciones de estado

La aplicación no responde con el código de estado esperado (200 OK para HTTP o SYN, ACK para TCP) durante las verificaciones de estado en la ruta de acceso y el puerto configurados.

Si tu aplicación no responde correctamente a las verificaciones de estado, puede deberse a uno de los siguientes motivos:

  • Grupos de extremos de red(NEG):
    • La aplicación no se ejecuta correctamente dentro del Pod.
    • La aplicación no escucha en el puerto o la ruta de acceso configurados.
    • Hay problemas de conectividad de red que impiden que la verificación de estado llegue al Pod.
  • Grupo de instancias:
    • Los nodos del grupo de instancias no están en buen estado.
    • La aplicación no se ejecuta correctamente en los nodos.
    • Las solicitudes de verificación de estado no llegan a los nodos.

Si fallan las verificaciones de estado, según tu configuración, soluciona el problema de la siguiente manera:

Para los NEG:

  1. Accede a un Pod con kubectl exec:

    kubectl exec -it pod-name -- command

    La marca -it proporciona una sesión de terminal interactiva (i para interactiva, t para TTY).

    Reemplaza lo siguiente:

    • pod-name: es el nombre del Pod.
    • command: es el comando que deseas ejecutar dentro del Pod. El comando más común es bash o sh para obtener un shell interactivo.

  2. Ejecuta comandos curl para probar la conectividad y la capacidad de respuesta de la aplicación:

    • curl localhost:<Port>/<Path>
    • curl -v http://<POD_IP>/[Path configured in HC]
    • curl http://localhost/[Path configured in HC]

Para los grupos de instancias:

  1. Asegúrate de que los nodos estén en buen estado y respondan a los sondeos de verificación de estado predeterminados.
  2. Si los nodos están en buen estado, pero el Pod de la aplicación no responde, investiga más la aplicación.
  3. Si las solicitudes no llegan a los Pods, es posible que se trate de un problema de redes de GKE. Comunícate con el equipo de Asistencia Google Cloud para obtener ayuda.

Error al editar el sondeo de preparación en el Pod

Cuando intentas editar el sondeo de preparación en un Pod para cambiar los parámetros de verificación de estado, se produce un error similar al siguiente:

Pod "pod-name" is invalid: spec: Forbidden: pod updates may not change fields

Si modificas el sondeo de preparación de los Pods asociados con un servicio que ya está vinculado a un Ingress (y su balanceador de cargas correspondiente), GKE no actualiza automáticamente la configuración de verificación de estado en el balanceador de cargas. Esto genera una falta de coincidencia entre la verificación de preparación del Pod y la verificación de estado del balanceador de cargas, lo que hace que falle la verificación de estado.

Para resolver este problema, vuelve a implementar los Pods y el recurso Ingress. Esto obliga a GKE a volver a crear el balanceador de cargas y sus verificaciones de estado, y a incorporar la nueva configuración del sondeo de preparación.

No se pudo iniciar la Deployment ni el balanceador de cargas

Si no se inicia la implementación y los servicios de backend detrás del balanceador de cargas de tu controlador de Ingress están marcados como en mal estado, es posible que el motivo sea una falla en el sondeo de preparación.

Es posible que veas el siguiente mensaje de error en el que se menciona una falla en el sondeo de preparación:

Readiness probe failed: connection refused

La aplicación dentro del Pod no responde correctamente al sondeo de preparación configurado en la configuración YAML del Pod. Esto puede deberse a varios motivos, como que la aplicación no se inicie correctamente, escuche en el puerto incorrecto o encuentre un error durante la inicialización.

Para resolver este problema, investiga y corrige cualquier discrepancia en la configuración o el comportamiento de tu aplicación haciendo lo siguiente:

  • Asegúrate de que la aplicación esté configurada correctamente y responda en la ruta de acceso y el puerto especificados en los parámetros del sondeo de preparación.
  • Revisa los registros de la aplicación y soluciona cualquier problema o error de inicio.
  • Verifica que el containerPort en la configuración del Pod coincida con el targetPort en el servicio y el puerto de backend especificado en el Ingress.

Faltan reglas de firewall de Ingress automáticas

Creaste un recurso Ingress, pero el tráfico no llega al servicio de backend.

Faltan las reglas de firewall de Ingress automáticas, que GKE suele crear cuando se crea un recurso Ingress, o se borraron de forma accidental.

Para restablecer la conectividad a tu servicio de backend, sigue estos pasos:

  • Verifica la existencia de las reglas de firewall de Ingress automáticas en tu red de VPC.
  • Si faltan las reglas, puedes volver a crearlas de forma manual o borrar y volver a crear el recurso Ingress para activar su creación automática.
  • Asegúrate de que las reglas de firewall permitan el tráfico en los puertos y protocolos adecuados, como se define en tu recurso Ingress.

Se usó un protocolo incorrecto en el manifiesto de BackendConfig

Si configuras una CRD de BackendConfig con un protocolo de tipo TCP, verás el siguiente error:

Error syncing to GCP: error running backend syncing routine:
error ensuring health check: Protocol "TCP" is not valid, must be one of ["HTTP","HTTPS","HTTP2"]'

BackendConfig admite la creación de verificaciones de estado solo con los protocolos HTTP, HTTPS o HTTP/2. Si quieres obtener más información, consulta los criterios de éxito para HTTP, HTTPS y HTTP/2.

¿Qué sigue?