Configurar la verificación de estado activa para servicios - Microservices Engine

Las verificaciones de estado activas desactivan automáticamente los nodos de servicio en mal estado y los reactivan cuando se recuperan. Esto mejora la disponibilidad de las rutas hacia las interfaces de servicio en despliegues con múltiples réplicas.

Procedimiento

Nota

Si la versión de la puerta de enlace es 1.2.1 o posterior, la función de verificación de estado TCP se habilita automáticamente al crear un servicio.

Inicie sesión en la consola de MSE. En la barra de navegación superior, seleccione una región.
En el panel de navegación izquierdo, vaya a Cloud-native Gateway > Gateways. En la página Gateways, haga clic en el ID de la puerta de enlace.
En el panel de navegación izquierdo, haga clic en Routes. A continuación, haga clic en la pestaña Services.
En la pestaña Services, localice el servicio deseado y haga clic en Health Check Settings en la columna Actions. En el panel Configure Health Check, active Enable Health Check, configure los parámetros y haga clic en OK.

Solucionar fallos en la verificación de estado

Solucionar un fallo de verificación de estado en escenarios comunes

Determine si el fallo corresponde a una verificación de estado TCP o HTTP:

Si falla una verificación de estado TCP, no se puede establecer la conexión con el nodo de la puerta de enlace. Compruebe lo siguiente:
- Compruebe si el nodo existe.
- Compruebe si hay demasiadas conexiones simultáneas establecidas.
Si falla una verificación de estado HTTP, primero compruebe que la verificación de estado TCP sea correcta. De ser así, valide si la ruta de verificación de estado configurada es válida mediante herramientas como curl o Postman.
Si docker está instalado en la instancia ECS del backend, compruebe si la red bridge de docker entra en conflicto con la red VPC. La red bridge predeterminada de docker (por ejemplo, 172.17.0.0/16) podría superponerse con la red VPC a la que pertenece la instancia ECS (por ejemplo, 172.16.0.0/12). Esta superposición provoca que las solicitudes de verificación de estado de la puerta de enlace se enruten incorrectamente. Ejecute el comando route -n en la instancia ECS para revisar la tabla de rutas y confirmar si la red bridge de docker se superpone con la red VPC. Para resolver el conflicto, modifique el parámetro bip en el archivo /etc/docker/daemon.json y cambie la red bridge de docker (por ejemplo, a 192.168.0.1/24). Luego, reinicie el servicio de docker y confirme que el conflicto se resolvió.

Solucionar un fallo de verificación de estado al agregar un servicio por primera vez

Realice las siguientes operaciones en orden:

Compruebe si la VPC del servicio es la misma que la VPC de la puerta de enlace, o si el entorno del servicio está conectado a la VPC de la puerta de enlace mediante Cloud Enterprise Network (CEN) o conexiones físicas. Si las VPC son diferentes y no están conectadas, la dirección IP de la puerta de enlace no será accesible.

Nota
La puerta de enlace no admite servicios locales registrados en instancias de Nacos y ZooKeeper.
Compruebe si la VPC del servicio coincide con la VPC de la puerta de enlace. Si las VPC son distintas y no existe conexión entre ellas, no se podrá acceder a la dirección IP de la puerta de enlace.
Compruebe si la autorización del security group está configurada. Si el origen del servicio es un clúster de Container Service for Kubernetes (ACK), compruebe que la puerta de enlace esté agregada al security group del clúster ACK. Para obtener más información, consulte Perform security group authorization.
Si la puerta de enlace en mal estado utiliza una dirección IP pública, compruebe si hay una NAT Gateway de Internet habilitada para la VPC de la puerta de enlace.

El estado de la verificación muestra Checking, o la sonda inicial falla pero las siguientes tienen éxito

Para un servicio en la puerta de enlace nativa de la nube, esto suele ser un estado transitorio normal y no un fallo. Las causas comunes incluyen:

La respuesta del servicio backend tiene retraso y la primera sonda tarda casi tanto como el umbral de tiempo de espera (por ejemplo, 2 segundos), por lo que el estado no se actualiza a tiempo.
El Pod o la puerta de enlace tienen una carga alta, por lo que la verificación de estado no obtiene el resultado esperado a tiempo.
La verificación de estado se acaba de habilitar o el servicio se acaba de registrar, y el ciclo de sondeo no ha terminado. Un servicio se marca como saludable solo después de varias sondas exitosas consecutivas.

Observe el estado durante un momento. Si la verificación de estado continúa siendo anómala, siga solucionando el problema con los otros métodos descritos en este tema.

Solucionar un fallo de verificación de estado causado por una configuración de protocolo incorrecta, donde la verificación pasa pero el acceso falla

Si la verificación de estado upstream para un MSE Ingress en la puerta de enlace nativa de la nube es correcta pero aún no puede acceder al servicio, compruebe si el tipo de protocolo de la aplicación correspondiente en Container Service for Kubernetes (ACK) está configurado correctamente. Por ejemplo, una solicitud HTTP debe usar el protocolo TCP. Si el protocolo se configura erróneamente como UDP, el acceso fallará aunque la verificación de estado sea correcta.

Realice las siguientes comprobaciones:

Guarde nuevamente y vuelva a publicar la configuración de la ruta.
Compruebe si la escucha automática está habilitada para el origen del servicio.
Ejecute el comando kubectl describe endpoints para consultar los detalles del endpoint del servicio.

Preguntas frecuentes sobre direcciones IPv6 que causan fallos en la verificación de estado

P: ¿Por qué sigue fallando la verificación de estado de la puerta de enlace MSE aunque el Pod ya esté escuchando en un puerto IPv6?

R: La puerta de enlace MSE no admite el proxy de recursos IPv6. Para resolver este problema, modifique la configuración del Service backend y establezca ipFamilies en IPv4 para que el tráfico se transmita mediante IPv4.