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).

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 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 verificación de estado deTrusted 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 recurso personalizado (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 personalizados para la verificación de estado asociada al servicio de backend correspondiente. Estos parámetros de configuración personalizados brindan mayor flexibilidad y control sobre las verificaciones de estado tanto para el balanceador de cargas de aplicaciones clásico como para 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 Service según el sondeo de preparación que usan los Pods de entrega de ese Service. 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 un CRD de BackendConfig o no defines atributos para el sondeo de preparación.
Práctica recomendada:

Usa un 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 un CRD de BackendConfig o usas una sonda de preparación.

BackendConfig CRD

Cuando configures los 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. El BackendConfig solo admite la creación de verificaciones de 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.

Sondeo de preparación

Cuando usas Ingress de GKE con el 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 los Pods que definiste en la sección spec.containers[].readinessProbe.httpGet.port de la configuración en YAML del 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 del Pod.
  • El containerPort del Pod de entrega debe coincidir con el targetPort del Service. Esto garantiza que el tráfico se dirija desde el Service 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 las verificación de estado

Usa el siguiente diagrama de flujo para solucionar problemas y ayudarte a identificar cualquier problema verificación de estado:

Soluciona problemas de verificaciones de estado de Ingress.
Figura: Soluciona problemas de verificaciones de estado

En este diagrama de flujo, la siguiente guía para solucionar problemas te ayuda a determinar dónde se encuentra 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 tus reglas de firewall para confirmar que permiten el tráfico entrante de los rangos de direcciones IP de 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 deTrusted Cloud by S3NS 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 apunte 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 de Trusted Cloud by S3NS .

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, 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 está escuchando en el puerto o la ruta 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 las verificaciones de estado fallan, según tu configuración, soluciona el problema de la siguiente manera:

Para los NEGs:

  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 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 a fondo la aplicación.
  3. Si las solicitudes no llegan a los Pods, es posible que haya un problema de redes de GKE. Comunícate con el equipo de asistencia de Trusted Cloud by S3NS para recibir ayuda.

Se produjo un error al editar la sonda 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 a un Service que ya está vinculado a un Ingress (y a su balanceador de cargas correspondiente), GKE no actualizará 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 provoca que la verificación de estado 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 de la sonda de disponibilidad.

No se inician 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 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 que menciona una falla en la sonda de preparación:

Readiness probe failed: connection refused

La aplicación dentro del Pod no responde correctamente a la sonda de preparación configurada en la configuración 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 resolver este problema, investiga y corrige cualquier discrepancia 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 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 Service 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 volver a crear 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 de BackendConfig

Si configuras un 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"]'

El 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 Criterios de éxito para HTTP, HTTPS y HTTP/2.

¿Qué sigue?