Solucionar problemas de comprobaciones del estado de Ingress

En esta página se explica cómo resolver problemas relacionados con las comprobaciones de estado de Ingress en Google Kubernetes Engine (GKE).

Cómo funcionan las comprobaciones de estado de Ingress

Antes de seguir los pasos para solucionar problemas, puede ser útil que sepas cómo funcionan las comprobaciones de estado en GKE y qué consideraciones debes tener en cuenta para que las comprobaciones de estado se realicen correctamente.

Cuando expones uno o varios servicios a través de un objeto Ingress mediante el controlador Ingress predeterminado, GKE crea un balanceador de carga de aplicaciones clásico o un balanceador de carga de aplicaciones interno. Ambos balanceadores de carga admiten varios servicios de backend en un único mapa de URLs. 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 comprobación de estado. Esta comprobación del estado es diferente de una comprobación de actividad o de disponibilidad de Kubernetes, ya que se implementa fuera del clúster.

Las comprobaciones de estado del balanceador de carga se especifican por servicio de backend. Aunque es posible usar la misma comprobación del estado para todos los servicios de backend del balanceador de carga, la referencia de la comprobación del estado no se especifica para todo el balanceador de carga (en el propio objeto Ingress).

GKE crea comprobaciones del estado basadas en uno de los siguientes métodos:

  • BackendConfig CRD: una definición de recurso personalizado (CRD) que te permite controlar con precisión cómo interactúan tus servicios con el balanceador de carga. BackendConfig Los CRDs te permiten especificar ajustes personalizados para la comprobación de estado asociada al servicio de backend correspondiente. Estos ajustes personalizados ofrecen más flexibilidad y control sobre las comprobaciones del estado tanto del balanceador de carga de aplicación clásico como del balanceador de carga de aplicación interno creado por un objeto Ingress.
  • Sondeo de disponibilidad: comprobación de diagnóstico que determina si un contenedor de un pod está listo para atender el tráfico. El controlador de Ingress de GKE crea la comprobación del estado del servicio de backend del servicio en función de la sonda de preparación que utilizan los pods de servicio de ese servicio. Puedes obtener los parámetros de comprobación de estado, como la ruta, el puerto y el protocolo, de la definición de la sonda de preparación.
  • Valores predeterminados: los parámetros que se usan cuando no se configura un CRD BackendConfig o no se definen atributos para la comprobación de disponibilidad.
Práctica recomendada:

Usa un BackendConfig CRD para tener el máximo control sobre la configuración de las comprobaciones del estado del balanceador de carga.

GKE sigue este procedimiento para crear una comprobación del estado de cada servicio de backend correspondiente a un servicio de Kubernetes:

  • Si el servicio hace referencia a un CRD de BackendConfig con información de healthCheck, GKE lo usa para crear la comprobación de estado. Tanto el controlador de Ingress de GKE Enterprise como el controlador de Ingress de GKE admiten la creación de comprobaciones de estado de esta forma.

  • Si el servicio no hace referencia a un CRD de BackendConfig:

    • GKE puede inferir algunos o todos los parámetros de una comprobación de estado si los pods de servicio usan una plantilla de pod con un contenedor cuya sonda de disponibilidad tenga atributos que se puedan interpretar como parámetros de comprobación de estado. Consulte Parámetros de una sonda de disponibilidad para obtener información sobre la implementación y Parámetros predeterminados e inferidos para ver una lista de atributos que se pueden usar para crear parámetros de comprobación del estado. Solo el controlador de Ingress de GKE admite la inferencia de parámetros a partir de una sonda de disponibilidad.

    • Si la plantilla de Pod de los Pods de servicio no tiene un contenedor con una sonda de disponibilidad cuyos atributos se puedan interpretar como parámetros de comprobación del estado, se utilizarán los valores predeterminados para crear la comprobación del estado. Tanto el controlador de entradas de GKE Enterprise como el controlador de entradas de GKE pueden crear una comprobación de estado usando solo los valores predeterminados.

Cuestiones importantes

En esta sección se describen algunas consideraciones que debes tener en cuenta al configurar un BackendConfig CRD o usar una sonda de disponibilidad.

BackendConfig CRD

Cuando configures CRDs de BackendConfig, ten en cuenta lo siguiente:

  • Si usas el balanceo de carga nativo de contenedores, comprueba que el puerto de comprobación del estado del manifiesto BackendConfig coincida con el containerPort de un pod de servicio.
  • En el caso de los backends de grupos de instancias, asegúrate de que el puerto de comprobación del estado del manifiesto BackendConfig coincida con el nodePort expuesto por el servicio.
  • Ingress no admite gRPC para configuraciones de comprobación de estado personalizadas. BackendConfig solo admite la creación de comprobaciones del estado con los protocolos HTTP, HTTPS o HTTP2. Para ver un ejemplo de cómo usar el protocolo en un CRD de BackendConfig, consulta gke-networking-recipes.

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

Comprobación de preparación

Cuando usas Ingress de GKE con el balanceo de carga HTTP o HTTPS, GKE envía las sondas de comprobación de estado para determinar si tu aplicación se está ejecutando correctamente. Estas sondas de comprobación de estado se envían al puerto específico de tus pods que hayas definido 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 de la sonda de disponibilidad 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 servicio debe coincidir con el targetPort del servicio. De esta forma, el tráfico se dirige desde el servicio al puerto correcto de tus pods.
  • La especificación del puerto de 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. Puedes hacerlo de dos formas:
    • spec.rules[].http.paths[].backend.service.port.name del Ingress coincide con spec.ports[].name definido en el Service correspondiente.
    • spec.rules[].http.paths[].backend.service.port.number del Ingress coincide con spec.ports[].port definido en el Service correspondiente.

Solucionar problemas habituales de comprobación del estado

Sigue el siguiente diagrama de flujo para identificar los problemas de comprobación del estado:

Solucionar problemas de las comprobaciones del estado de Ingress.
Imagen: Solucionar problemas de comprobaciones de estado

En este diagrama de flujo, las siguientes indicaciones para solucionar problemas ayudan a determinar dónde se produce el problema:

  1. Investiga el estado de los pods: si la comprobación de estado falla, examina el estado de los pods de servicio. Si los pods no se están ejecutando y no están en buen estado:

    • Consulta los registros de los pods para ver si hay errores o problemas que impidan que se ejecuten.
    • Comprueba el estado de las sondas de preparación y de actividad.

  2. Registro de comprobación del estado: asegúrate de que has habilitado el registro de comprobación del estado.

  3. Verifica la configuración del cortafuegos: asegúrate de que las reglas del cortafuegos permiten que las sondas de comprobación del estado lleguen a tus pods. En caso negativo:

    • Comprueba las reglas de tu cortafuegos para confirmar que permiten el tráfico entrante de los intervalos de direcciones IP de la sonda de comprobación del estado.
    • Ajusta las reglas de cortafuegos según sea necesario para adaptarlas a estos intervalos de direcciones IP.

  4. Analizar la captura de paquetes: si el cortafuegos está configurado correctamente, realiza una captura de paquetes para ver si tu aplicación responde a las comprobaciones de estado. Si la captura de paquetes muestra una respuesta correcta, ponte en contacto con elGoogle Cloud equipo de Asistencia para obtener más ayuda.

  5. Solucionar 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 comprobación del estado. Verifica que la comprobación del estado se dirija a la ruta 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, ponte en contacto con el equipo de Asistencia de Google Cloud .

La aplicación no responde a las comprobaciones del estado

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

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

  • Grupos de puntos finales de red(NEGs):
    • La aplicación no se está ejecutando correctamente en el pod.
    • La aplicación no está escuchando en el puerto o la ruta configurados.
    • Hay problemas de conectividad de red que impiden que la comprobació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 comprobación del estado no llegan a los nodos.

Si las comprobaciones del estado fallan, en función de tu configuración, soluciona el problema de la siguiente manera:

Para NEGs:

  1. Acceder a un pod mediante kubectl exec:

    kubectl exec -it pod-name -- command

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

    Haz los cambios siguientes:

    • pod-name: el nombre de tu Pod.
    • command: el comando que quieres ejecutar en el pod. El comando más habitual es bash o sh para obtener un shell interactivo.

  2. Ejecuta los 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]

Grupos de instancias:

  1. Asegúrate de que los nodos estén en buen estado y respondan a las comprobaciones de estado predeterminadas.
  2. Si los nodos están en buen estado, pero el pod de la aplicación no responde, investiga la aplicación.
  3. Si las solicitudes no llegan a los pods, puede que haya un problema de red de GKE. Ponte en contacto con el equipo de asistencia de Google Cloud para recibir ayuda.

Error al editar la sonda de preparación en el pod

Cuando intentas editar la sonda de preparación de un Pod para cambiar los parámetros de comprobación del estado, se produce un error similar al siguiente:

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

Si modificas la sonda de disponibilidad de los pods asociados a un servicio que ya está vinculado a un Ingress (y a su balanceador de carga correspondiente), GKE no actualizará automáticamente la configuración de la comprobación del estado en el balanceador de carga. Esto provoca un desajuste entre la comprobación de disponibilidad del pod y la comprobación del estado del balanceador de carga, lo que hace que la comprobación del estado falle.

Para solucionar este problema, vuelve a implementar los pods y el recurso Ingress. De esta forma, GKE recrea el balanceador de carga y sus comprobaciones de estado, e incorpora los nuevos ajustes de la sonda de disponibilidad.

No se pueden iniciar la implementación ni el balanceador de carga

Si tu implementación no se inicia y los servicios backend que hay detrás del balanceador de carga de tu controlador Ingress están marcados como no saludables, puede que el motivo sea un fallo en la prueba de disponibilidad.

Es posible que veas el siguiente mensaje de error en el que se menciona un fallo en la prueba de disponibilidad:

Readiness probe failed: connection refused

La aplicación del pod no responde correctamente a la sonda de disponibilidad configurada en el archivo YAML del pod. Esto puede deberse a varios motivos, como que la aplicación no se inicie correctamente, que esté escuchando en el puerto incorrecto o que se produzca un error durante la inicialización.

Para solucionar este problema, investiga y corrige las discrepancias en la configuración o el comportamiento de tu aplicación siguiendo estos pasos:

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

Faltan reglas de cortafuegos de entrada automáticas

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

Faltan las reglas de cortafuegos de Ingress automáticas, que normalmente crea GKE cuando se crea un recurso Ingress, o se han eliminado por error.

Para restaurar la conectividad con tu servicio backend, sigue estos pasos:

  • Verifica que las reglas de cortafuegos de Ingress automáticas estén en tu red de VPC.
  • Si faltan las reglas, puedes volver a crearlas manualmente o eliminar y volver a crear el recurso Ingress para activar su creación automática.
  • Asegúrate de que las reglas del cortafuegos permitan el tráfico en los puertos y protocolos adecuados, tal como se define en tu recurso Ingress.

Se ha usado un protocolo incorrecto en el manifiesto de BackendConfig

Si configuras un BackendConfig CRD 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 solo permite crear comprobaciones de estado con los protocolos HTTP, HTTPS o HTTP/2. Para obtener más información, consulta Criterios de éxito de HTTP, HTTPS y HTTP/2.

Siguientes pasos