Soluciona problemas de verificaciones de estado de Ingress

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

Si necesitas asistencia adicional, comunícate con Atención al cliente de Cloud.

Comprende cómo funcionan las verificaciones de estado de Ingress

Antes de continuar con los pasos para solucionar problemas, puede ser útil comprender cómo funcionan las verificaciones de estado en GKE y qué consideraciones debes tener en cuenta para garantizar que 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 verificación de estado deGoogle Cloud . 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 recursos personalizados (CRD) que te brinda un control preciso sobre la forma en que tus servicios interactúan con el balanceador de cargas. Las CRD de BackendConfig te permiten especificar parámetros de configuración personalizados para la verificación de estado asociada con el servicio de backend correspondiente. Esta configuración personalizada proporciona mayor flexibilidad y control sobre las verificaciones de estado del balanceador de cargas de aplicaciones clásico y el balanceador de cargas de aplicaciones interno que crea 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 CRD de BackendConfig 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 configures una CRD de BackendConfig o uses una prueba de preparación.

CRD de BackendConfig

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

  • Si usas el balanceo de cargas nativo del contenedor, asegúrate de que el puerto de verificación de estado en el manifiesto 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 BackendConfig coincida con el nodePort que expone el servicio.
  • Ingress no admite gRPC para la configuración de verificación de estado personalizadas. BackendConfig solo admite la creación de verificaciones de estado mediante los protocolos HTTP, HTTPS o HTTP2. Para ver un ejemplo de cómo usar el protocolo en una CRD de BackendConfig, consulta gke-networking-recipes.

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

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 de 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 tu aplicación está escuchando 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 Service. Esto garantiza que el tráfico se dirija desde el servicio al puerto correcto en 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 una de las siguientes 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 la 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: Cómo solucionar problemas relacionados con las 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 la verificación de estado falla, examina el estado de los Pods de entrega de tu servicio. Si los Pods no se están ejecutando y no están en buen estado, haz lo siguiente:

    • Revisa los registros del Pod en busca de errores o problemas que impidan su ejecución.
    • Verifica el estado de los sondeos de preparación y funcionamiento.

  2. Registro de verificaciones 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 del firewall permitan que los sondeos de verificación de estado lleguen a tus pods. De lo contrario, 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 admitir 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 al cliente deGoogle Cloud para obtener más ayuda.

  5. Solución de problemas de la aplicación: Si la captura de paquetes no muestra una respuesta correcta, investiga por qué la aplicación no responde correctamente a las solicitudes de verificación de estado. Verifica que la verificación de estado se dirija a la ruta de acceso y al puerto correctos en los pods, y examina los registros, los archivos de configuración y las dependencias de la aplicación. Si no encuentras el error, comunícate con el equipo de asistencia al cliente de 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 y el puerto configurados.

Si tu aplicación no responde correctamente a las verificaciones de estado, es posible que se deba a uno de los siguientes motivos:

  • Grupos de extremos de red(NEG):
    • La aplicación no se ejecuta correctamente en el Pod.
    • La aplicación no está escuchando 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 tus verificaciones de estado fallan, según tu configuración, soluciona el problema de la siguiente manera:

Para 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 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]

Para 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 la aplicación con más detalle.
  3. Si las solicitudes no llegan a los pods, es posible que se trate de un problema de red de GKE. Comunícate con el equipo de asistencia de Google Cloud para obtener ayuda.

Se produce un error cuando se edita la prueba 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 la verificación de estado en el balanceador de cargas. Esto genera una discrepancia entre la verificación de preparación del Pod y la verificación de estado del balanceador de cargas, lo que hace que esta falle.

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 pueden iniciar la Deployment ni el balanceador de cargas

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

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

Readiness probe failed: connection refused

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

Para resolver este problema, investiga y corrige las discrepancias en la configuración o el comportamiento de tu aplicación. Para ello, haz 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 los problemas o errores 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 entrada automáticas

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

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

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

  • Verifica la existencia de las reglas de firewall de entrada automáticas en tu red de VPC.
  • Si faltan las reglas, puedes volver a crearlas de forma manual o borrar y recrear el recurso de 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 de Ingress.

Se usó un protocolo incorrecto en el manifiesto 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. Para obtener más información, consulta Criterios de éxito para HTTP, HTTPS y HTTP/2.

¿Qué sigue?

Para configurar verificaciones de estado personalizadas para Ingress en un solo clúster, consulta Recetas de redes de GKE.