Unhealthy services after cluster restore or rollback

Recuperar servicios en mal estado después de una restauración o reversión de clúster en Automation Suite cuando hay errores de pod RabbitMQ.

Descripción

Después de la restauración o reversión de un clúster, AI Center, Orchestrator, la plataforma, Document Understanding o Task Mining pueden no estar correctos y los registros del pod RabbitMQ muestran el siguiente error:

[root@server0 UiPathAutomationSuite]# k -n rabbitmq logs rabbitmq-server-0
2022-10-29 07:38:49.146614+00:00 [info] <0.9223.362> accepting AMQP connection <0.9223.362> (10.42.1.161:37524 -> 10.42.0.228:5672)
2022-10-29 07:38:49.147411+00:00 [info] <0.9223.362> Connection <0.9223.362> (10.42.1.161:37524 -> 10.42.0.228:5672) has a client-provided name: rabbitConnectionFactory#77049094:2100
2022-10-29 07:38:49.147644+00:00 [erro] <0.9223.362> Error on AMQP connection <0.9223.362> (10.42.1.161:37524 -> 10.42.0.228:5672, state: starting):
2022-10-29 07:38:49.147644+00:00 [erro] <0.9223.362> PLAIN login refused: user 'aicenter-service' - invalid credentials
2022-10-29 07:38:49.147922+00:00 [info] <0.9223.362> closing AMQP connection <0.9223.362> (10.42.1.161:37524 -> 10.42.0.228:5672 - rabbitConnectionFactory#77049094:2100)
2022-10-29 07:38:55.818447+00:00 [info] <0.9533.362> accepting AMQP connection <0.9533.362> (10.42.0.198:45032 -> 10.42.0.228:5672)
2022-10-29 07:38:55.821662+00:00 [info] <0.9533.362> Connection <0.9533.362> (10.42.0.198:45032 -> 10.42.0.228:5672) has a client-provided name: rabbitConnectionFactory#2100d047:4057
2022-10-29 07:38:55.822058+00:00 [erro] <0.9533.362> Error on AMQP connection <0.9533.362> (10.42.0.198:45032 -> 10.42.0.228:5672, state: starting):
2022-10-29 07:38:55.822058+00:00 [erro] <0.9533.362> PLAIN login refused: user 'aicenter-service' - invalid credentials
2022-10-29 07:38:55.822447+00:00 [info] <0.9533.362> closing AMQP connection <0.9533.362> (10.42.0.198:45032 -> 10.42.0.228:5672 - rabbitConnectionFactory#2100d047:4057)

Solución

Para solucionar el problema, comprueba si algunos o todos los pods de RabbitMQ están en estado CrashLoopBackOff debido al problema de escritura de datos de la tabla Mnesia.

Si todos los pods se están ejecutando, siga los siguientes pasos:

1. Eliminar los usuarios en RabbitMQ:

   kubectl -n rabbitmq exec rabbitmq-server-0 -c rabbitmq -- rabbitmqctl  list_users -s --formatter json | jq '.[]|.user' | grep -v default_user | xargs -I{} kubectl -n rabbitmq exec rabbitmq-server-0 -c rabbitmq -- rabbitmqctl delete_user {}
   

2. Elimina los secretos de la aplicación RabbitMQ en el espacio de nombres de UiPath:

   kubectl -n uipath get secret --template '{{range .items}}{{.metadata.name}}{{"\n"}}{{end}}' | grep -i rabbitmq-secret | xargs -I{} kubectl -n uipath delete secret {}
   

3. Elimina los secretos de la aplicación RabbitMQ en el espacio de nombres de RabbitMQ:

   kubectl -n rabbitmq get secret --template '{{range .items}}{{.metadata.name}}{{"\n"}}{{end}}' | grep -i rabbitmq-secret | xargs -I{} kubectl -n rabbitmq delete secret {}
   

4. Sincronice la aplicación sfcore a través de ArgoCD y espere a que se complete la sincronización:

   

5. Realiza un reinicio de implementación en todas las aplicaciones del espacio de nombres de UiPath:

   kubectl -n uipath rollout restart deploy
   

Si algunos pods están en estado CrashLoopBackOff, siga los siguientes pasos:

1. Identifica qué pods de Ra ConejoMQ están atascados en el estado CrashLoopBackOff CrashLoopBackOff comprueba los registros de pods

   kubectl -n rabbitmq get pods
   kubectl -n rabbitmq logs <CrashLoopBackOff-Pod-Name>
   

2. Compruebe la salida de los comandos anteriores. Si el problema está relacionado con la escritura de datos de la tabla de Mnesia, debería ver un mensaje de error similar al siguiente:

   Mnesia('[e-mail]'): ** ERROR ** (could not write core file: eacces)
    ** FATAL ** Failed to merge schema: Bad cookie in table definition rabbit_user_permission: '[e-mail]' = {cstruct,rabbit_user_permission,set,[],['[e-mail]','[e-mail]','[e-mail]'],[],[],0,read_write,false,[],[],false,user_permission,[user_vhost,permission],[],[],[],{{1667351034020261908,-576460752303416575,1},'[e-mail]'},{{4,0},{'[e-mail]',{1667,351040,418694}}}}, '[e-mail]' = {cstruct,rabbit_user_permission,set,[],['[e-mail]'],[],[],0,read_write,false,[],[],false,user_permission,[user_vhost,permission],[],[],[],{{1667372429216834387,-576460752303417087,1},'[e-mail]'},{{2,0},[]}}
   

3. Para solucionar el problema, realiza los siguientes pasos:
   1. Encuentre el número de réplicas de RabbitMQ:

rabbitmqReplicas=$(kubectl -n rabbitmq get rabbitmqcluster rabbitmq -o json | jq -r '.spec.replicas') 2. Reduce las réplicas de RabbitMQ:

kubectl -n rabbitmq patch rabbitmqcluster rabbitmq -p "{\"spec\":{\"replicas\": 0}}" --type=merge

kubectl -n rabbitmq scale sts rabbitmq-server --replicas=0 3. Espera hasta que todos los pods de RabbitMQ hayan terminado:

kubectl -n rabbitmq get pod 4. Comprueba si hay instantáneas de volumen pendientes: kubectl get volumesnapshot -n rabbitmq <crashloopbackupoff_pod_pvc_name> | grep false 5. Si existe alguna instantánea de volumen pendiente, elimínala: kubectl delete volumesnapshot -n rabbitmq <pending_volume_snapshot_name> 6. Busca y elimina el PVC del pod RabbitMQ que está atascado en el estado CrashLoopBackOff :

kubectl -n rabbitmq get pvc

kubectl -n rabbitmq delete pvc <crashloopbackupoff_pod_pvc_name> 7. Escala las réplicas de RabbitMQ:

kubectl -n rabbitmq patch rabbitmqcluster rabbitmq -p "{\"spec\":{\"replicas\": $rabbitmqReplicas}}" --type=merge 8. Comprueba si todos los pods de RabbitMQ están en buen estado:

kubectl -n rabbitmq get pod