Solución de problemas del clúster High Availability

En esta tabla se enumeran los síntomas y las resoluciones comunes de un clúster.
Síntoma
Resolución
Se produce un error de conectividad SSH entre la estación de trabajo de Windows y un nodo de Ubuntu.
Corrija las credenciales SSH o la configuración de red para que la estación de trabajo pueda llegar a cada nodo.
El acceso a la interfaz de usuario web está bloqueado porque el clúster y el proyecto implementado usan puertos diferentes.
Alinee el puerto MotorDePresentaciónWeb del proyecto con el puerto web configurado del clúster, valor predeterminado 80 para HTTP o 443 para HTTPS.
La base de datos deja de aceptar escrituras.
Este problema se produce cuando fallan dos de los tres nodos y la base de datos pierde quórum.
Restaure al menos un nodo fallido para establecer el quórum y reanudar las escrituras.
Faltan datos persistentes después de desinstalar el clúster.
Desinstalar el clúster elimina el almacenamiento persistente.
Recupere los datos solo de una copia de seguridad creada antes de la desinstalación.
El panel del clúster muestra un estado que parece obsoleto o inesperado.
Actualice el panel.
Si el estado sigue pareciendo incorrecto, revise Diagnóstico y los registros exportados para confirmar el estado real del pod y del nodo.
La implementación de un proyecto grande que supera el límite de memoria del tiempo de ejecución hace que la implementación informe de que se ha realizado correctamente en Studio, pero el tiempo de ejecución se apaga inmediatamente con poca información registrada.
  1. Para realizar una copia de seguridad de los valores actuales de Helm y del historial de revisiones, ejecute:
    helm get values ftoptix -n ftoptix > pre-change-values-backup.yaml && helm history ftoptix -n ftoptix
  2. Para confirmar que la RAM del nodo puede admitir el nuevo límite de memoria, ejecute:
    kubectl describe node <node-name> | grep -A2 "Capacity:"
  3. Para aplicar la anulación, ejecute:
    helm upgrade ftoptix <chart-path> -n ftoptix --reuse-values --set resources.runtime.requests.memory=<value> --set resources.runtime.limits.memory=<value>
  4. Para verificar que los pods han adoptado el nuevo límite y están en buen estado, ejecute:
    kubectl rollout status statefulset/ftoptix-core-ha-runtime -n ftoptix
                      kubectl get pods -n ftoptix
                      kubectl describe pod ftoptix-core-ha-runtime-0 -n ftoptix | grep -A2 "Limits:"
  5. Para confirmar el cambio, implemente el proyecto de nuevo, confirme que el tiempo de ejecución alcanza un estado de ejecución o activo y confirme que se puede acceder a la interfaz web.
Kubernetes devuelve el código de estado 401 (Unauthorized), se produce un error en la recuperación de identidades del tiempo de ejecución, el tiempo de ejecución entra en modo de demostración, se produce un error intermitente en la autorización del servidor de actualización o los pods del tiempo de ejecución no se recuperan según lo esperado.
Estos síntomas suelen ser el resultado de una desviación del reloj entre los nodos del clúster.
Configure todos los nodos para que utilicen los mismos orígenes NTP aprobados, restaure la sincronización de hora, confirme que los relojes difieren en no más de 1 segundo y vuelva a intentar la operación fallida.
No continúe con el aprovisionamiento si algún nodo no está sincronizado o difiere en 5 segundos o más.
Entregue su opinión
¿Tiene dudas o comentarios acerca de esta documentación? Por favor deje su opinión aquí.
Normal